[Css-csts] CSTS - ASN.1 Updates (A#04-0609)

[Yves.Doat at esa.int]

Dear all,

I uploaded to the CCSDS Web Site the text file of the new ASN.1 (Syntax
checked) in the directory: "CSS-CSTS/CWE Private/ CSTS Framework an Concept"
with the name: "CSTS asn1 0.20 20090716".

The main change is related to the definition of one CstsFrameworkPdu module
(the last one in the ASN.1).
This new module imports all CSTS PDUs defined in the Framework and builds
this new PDU.
With this approach you will noticed:
   All PDUs visible in one place;
   Decoding should be eased as it's now concentrated as per the developer
   request;
   Tagging of PDU is now concentrated in a single place and is easier to
   understand.
   The procedure allowed PDUs are now defined in the procedure modules by
   means of subtyping of the main PDU (using "WITH COMPONENTS" feature).
   Note: Considering that it is the first time I use this subtyping, I would
   appreciate if developers could give me feed back.

You will find below the answers to the comments/questions from Martin and Tim
with my answers.

I have not yet produced the draft 0.20 of the Framework and I would
appreciate to get your ASN.1 comments before I proceed.

Best regards
Yves Doat

================================================
20090606 - Mail from M.Goetzelmann:
(1) The PDU NotifyInvocation is missing in the structure
UnbufferedDataDeliveryPdu
YD> The Unbuffered Data Delivery procedure does not have a notification
capability.

(2)  In the structure UnbufferedDataDeliveryPdu the individual PDUs are
re-tagged. This is not done for the other procedures and I believe this is
not intentional.
 YD> Removed

(3) The type AssociationPdu should be exported such that it can be included
into a general PDU specification type.
 YD> Done

The following points are for further discussion - I do not intend to
recommend a specific approach:

(4) The current specification of the association control procedure types
differs from the specification of other procedures. The association control
operations are not specified in the common operations module and imported but
in the association control module. Furthermore the PDU tags are not defined
at top level but only within the structure AssociationPdu.

For the SLE service specifications separate handling of the Bind types was
essential as these were the only ones for which communality between services
was guaranteed. Special handling for the framework can still be justified
because of the special role of association control but because all common
operations are common, one could also justify handling all common operations
and all common procedures in the same way. That would be more in line with
the main part of the specification.

Independent of that decision, tagging association control PDUs on top level
would allow implementations to include them individually into PDU
specifications (see above) without re-specifying the tags.

YD> Considering that in the main part of the document we considered the
Association procedure as a special case, the ASN.1 definition does not follow
the same structure as the other procedures.
YD> The tagging is now concentrated in the "CSTS Protocol Data Unit" (section
D.2.13). No additional change.


(5) The SLE specifications used tags above 100 for the association control
PDUs in order to reserve the tags below 100 for service specific PDUs. This
does not seem to be necessary for the Framework - tagging of association
control PDUs could be aligned with other common operations.
 YD> The tagging is now concentrated in the "CSTS Protocol Data Unit"
(section D.2.13) and reallocation will be very easy. We can discuss and I am
open to any change. See new proposed tagging.

(6) Splitting of the PDU specification types into "incoming PDUs" and
"outgoing PDUs" would allow implementations of provider and user applications
to restrict top level PDUs for encoding and decoding to those really needed
for the provider or for the user. Personally I do not consider this very
important as the only drawback of using types with all PDUs is that ASN.1
compilers would generate more code than needed.
YD> originally I splitted the incoming and outgoing. It turned out that we
ended with many small modules. This points was discussed and it was agreed
not to differentiate. No change.

(7) If we want to include a type specification that could be used by all
implementations, we could add a type definition CstsFrameworkPdus, that
contains a choice of all common operation invocations, returns, and
acknowledgements. As noted above, the implication of using such a structure
would be that an invalid incoming PDU for a given service would not result in
a decoding error but would have to be detected by the implementation
YD> Please have a look to the proposed approach which is based on subtyping
of the main PDU for the procedure PDUs.

=============================================
20090701 - Mail from T.Ray
Are there two typos on the second page of the Framework ASN.1 version 0.19?
There are two object identifiers whose names are "protoIdentifiers" and
"servicesIdentifiers".  I think their definitions should be extensions of the
OBJECT IDENTIFIER "services" rather than "framework".  i.e. {framework 1} and
{framework 2} are already used previously; I think you intended to say
{services 1} and {services 2} instead.
YD> Corrected