[Css-csts] Comments about Service Type Identifiers

[John Pietras]

Yves,

Section D2.2 of the R-0.17 Framework defines the service type
identifiers for the CSTSes. I have a few comments about the content of
this section.

 

1. I don't believe that the individual service identifiers should be
documented in the Framework book. As the NOTE to the section itself
points out, the Framework would have to be updated to include new
services. This is really not the job of the Framework document, which is
supposed to define the Toolkit procedures. 

 

   One alternative is to have a distributed approach - the CSTS
Guidelines require that the service type identifier be defined as part
of the new service specification. Thus any CSTS, if it is developed in
conformance with the guidelines, will have its service type identifier
defined as part of its specification. I can add material to the
Guidelines requirements specifying that the identifiers must be in the
CCSDS-CSTS-TRANSFER-SERVICE-SERVICE-TYPE-ID space.

 

  The second alternative is to create a stand-alone Recommended Standard
the just contains the service type identifiers. It will be easier to
update this document every time a new CSTS is defined than it would be
to put the whole Framework into the Pink Sheet process. However, I
personally don't see the need for such a stand-alone specification - I
believe that defining the type identifiers as part of the CSTS Service
Specification is sufficient.

 

If there is some desire to "bookmark" the service instance identifiers
of CSTSes that are planned for the future (e.g.,rtnSpacePkt), this could
be done in an Annex of the Concept book.

 

2. "space-link-extension (3)" should not be part of any CSTS object
identifiers. For example, the
CCSDS-CSTS-TRANSFER-SERVICE-SERVICE-TYPE-ID should be  

{iso identified-organization (3) standards-producing-organization(112)
ccsds(4) csts (2) framework (1) modules(1) service-type(2) ({iso 3  112
4 2 1 1 2})

 instead of  

{iso identified-organization (3) standards-producing-organization(112)
ccsds(4) space-link-extension(3) csts (2) framework (1)modules(1)
service-type(2) ({iso 3  112 4 3 2 1 1 2}).

 

3. If the service type identifiers *do* remain in the Framework
specification or moved to a stand-alone document, the list should not
include serviced type identifiers for the existing SLE transfer
services. The SLE services do not use these service type identifiers in
their BIND operations (rather, they use integer-valued
ApplicationIdentifiers). The SLE transfer services do not conform to the
Framework procedures and to include them in the Framework specification
is misleading.

 

4. Are the object identifiers within a module supposed to be extensions
of the object identifiers of the modules themselves? If so, then there
are differences throughout the ASN.1. For example, the OID for the
Service Type ID module is {iso 3  112 4 3 2 1 1 2}, but the OID of the
cstsMonitoring service type ID is {iso 3 112 4 3 2 2 19}. That is, they
match through the "csts" element but diverge after that.

 

5. Finally, an editorial note - there is a lot of redundancy in the
ASN.1 module names, which all begin with "CCSDS-CSTS-TRANSFER-SERVICE".
Since the "TS" in "CSTS" stands for "Transfer Service", these names
could be shortened or changed to "CCSDS-CSTS-..." or
"CCSDS-CROSS-SUPPORT-TRANSFER-SERVICE-..." This is not a major issue.

 

Best regards,

John

 

 

 

John Pietras

GST, Inc. 

7855 Walker Drive, Suite 200

Greenbelt, MD 20770

240-542-1155

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20090224/a321f702/attachment.html