[Css-csts] Procedures Identifier Observations/Questions

[John Pietras]

CSTSWG colleagues ---

I have a few observations/questions about the Procedures Identifiers in
the CCSDS-CSTS-TRANSFER-SYNTAX and CCSDS-CSTS-SERVICE-INSTANCE-ID
modules. Some of these may have already surfaced in WG discussions while
I was not present, and if so I apologize for bringing them up again.

 

1.	For a new service with a derived procedure, it is my
understanding that the identifier for that derived procedure is "under"
the object identifier of that new service. So, for example, for the the
Tracking Data CSTS, which has the OID 

trkDataService    OBJECT IDENTIFIER ::= {servicesIdentifiers 2}

 

The Buffered Tracking Data Message Delivery procedure, derived from the
CSTSFW Buffered Data Delivery procedure, might have the OID

btdmd      OBJECT IDENTIFIER   ::= {trkDataExtServiceProcedures 1}

where 

trkDataExtServiceProcedures   OBJECT IDENTIFIER   ::= {trkDataService 3}

(This is just an observation, not a question)

 

2.	For the procedures defined in the CSTSFW, the
CCSDS-CSTS-TRANSFER-SYNTAX module contains a list of
xxxDerivedProcedures OIDs, where xxx is an acronym for the FW procedure,
e.g., bddDerivedProcedures. There is one of these xxxDerivedProcedures
for each of the procedures defined in the CSTSFW. However, there is only
one actual use of any one of these OIDs:

cyclicReport      OBJECT IDENTIFIER ::= { uddDerivedProcedures 1}

 

Are the rest of these OIDs here only as structural placeholders, in case
the CSTSFW is extended in the future with procedures that are derived
from other procedures (such as Cyclic Report is derived from Unbuffered
Data Delivery?)

 

3.	When a new service needs a procedure that is derived from an
existing CSTSFW procedure, one of two paths can be taken:

a)     While the service is being formulated, the CSTSWG can recognize
that the derived procedure has general applicability and incorporated it
into the CSTSFW. In that case, the procedure will get an
xxxDerivedProcedures OID, and the new service will adopt this new
procedure from the CSTSFW;

b)     The new procedure will be created in the context of the new
service, in which case the procedure will get a 
(service name)ExtServiceProcedures OID. If the CSTSWG subsequently
decides that the procedure has general applicability, the procedure will
be added to the CSTSWG, the OID will be changed from (service
name)ExtServiceProcedures to xxxDerivedProcedures, and (presumably) the
"new" service specification will be revised to reflect the new procedure
OID. There is a slight disadvantage in this process (besides the
"paperwork" to revise the service spec) in that it will render "version
1" implementations of the service non-interoperable with version-2+
implementations purely on the basis of the changed procedure OID. I
can't think of a solution, and maybe it's not that big of a problem, but
it is not very elegant.

 

4.	Should the procedure version number be somehow reflected in the
OID? We have decided that as a service evolves, its derived procedures
may also evolve, and thus a given derived procedure may have multiple
version numbers (which are identified in the Version row of the Service
Composition Table of the service specification). Assuming that the
versions should somehow be reflected in the OID, it could be explicitly
represented in the OID tree or simply enforced through IOD name syntax
rules in the Guidelines. For example, explicit representation in the OID
tree of the different versions of Buffered Tracking Data Message
Delivery procedure would look something like 

btdmd  OBJECT IDENTIFIER  ::= {trkDataExtServiceProcedures 1} 

 

btdmdV1  OBJECT IDENTIFIER  ::= {btdmd 1} 

 

btdmdV2  OBJECT IDENTIFIER  ::= {btdmd 2} 

 

Simply having an OID naming convention (e.g., every procedure version
must have a unique OID, and the name of that OID must end with
"V<version number>") would result in OIDs like 

btdmdV1   OBJECT IDENTIFIER  ::= {trkDataExtServiceProcedures 1}

for version 1, and 

 

btdmdV2   OBJECT IDENTIFIER  ::= {trkDataExtServiceProcedures 2}

for version 2.

 

Do we (CSTSWG) have a preference, or should it be left to the creator of
each new service? 

 

5.	CCSDS-CSTS-SERVICE-INSTANCE-ID module contains OIDs for both
"servicesIdentifiers" (for actual CSTSes) and "protoIdentifiers" (for
prototype services. Explicit protoIdentifiers are specified for the
Framework prototype services, Monitored Data Service, and the Tracking
Data service. I understand the separate protoIdentifier for the
Framework prototype, since it's not, and never will be, an actual CSTS.
However, for the MD-CSTS and TD-CSTS (services that are destined to be
Recommended Standards), would it not be better to define their OIDs (and
the OIDs of their derived procedures, derived parameters, and derived
services) under the actual serviceIdentifiers branch? 

 

Perhaps the problem that I'm anticipating here results for the fact that
there are two kinds of "prototypes" - the first kind is used to test
subsets of, or preliminary versions of, CSTS specifications, and for
those the use of protoIdentifiers is probably okay. But for the
interoperability testing required for CCSDS acceptance as a Recommended
Standard, the OIDs under the serviceIdentifiers branch should be used.
Perhaps this should be addressed in the Guidelines.

 

6.	Finally, I think that the material in the CSTSFW related to
defining service-related OIDs is more appropriate to the Guidelines, and
even there it should not be the normative specification of the specific
service OIDs (and their derived procedures, derived parameters, and
derived services), although the ones given in the current CSTSFW can be
cited as examples and of course will actually be used in the respective
Recommended Standards.

 

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/20090813/e472e39a/attachment-0001.html