[Css-csts] RE: Procedures Identifier Observations/Questions
Yves.Doat at esa.int
Yves.Doat at esa.int
Tue Aug 18 06:20:25 EDT 2009
Dear John,
Please find below your original mail with my comments in blus.
Best regards
Yves
===============================================================================
[NOTE – another typo on page 1-1: section 1.1 is “PURPOSE AND SCOPE” and
section 1.2 is “SCOPE”].
>>YD: Corrected
----
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.
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 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)
>>YD: This is correct
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?)
>>YD: This is correct, the tree defines under the “procedures” branch,
one sub-branch per procedure. Each sub-branch is in turn subdivided
with xxDerivedProcedures and xxExtendedProcedureParams
sub-sub-branches. The structure is the same for all procedures but as
you noted not all sub-branches are used.
When a new service needs a procedure that is derived from an existing
CSTSFW procedure, one of two paths can be taken:
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;
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.
YD>> Your description is correct. In my view the approach is in line
with our WG meetings. A new service defines on its own what it
needs. In case a derived procedure is for interest at Framework
level, a similar procedure will be created in the Framework (OID
branch: framework/procedures). Your conclusion on
non-interoperability is correct.
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?
>>YD. If we consider that the procedure has changed and get a new
version, we then get a new procedure and of course a new OID. Based on
this point the conclusion would be that the new version of the
procedure gets a new OID.
However we have to be careful and understand that, as the OID are
exchanged between User and Provider, having a new OID may imply
interoperability issues.
To be discussed.
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.
>>YD. This is ti be discussed, my proposal was really to differentiate
prototype from real implementation. I admit this is somehow artificial.
The prototype sub-branch could also be removed to avoid confusion and
later interoperability problems.
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.
Note: The following comment is a add-on to above comment:
I just sent out the message, in which in point (6) I suggested that the
OID tree for service identifiers be moved from the Framework to the
Guidelines. I just realized that this would not be necessary if the
document were truly scoped to be the Framework for CSTSes (as its name
implies) and not just the definition of the standard procedures (as is
currently constrained in the Purpose and Scope sections, and by file
name of the document itself). Should the Purpose and Scope (and file
name) be expanded to let this be truly the Framework for CSTSes, which
would include not just definition of the procedures but also
infrastructure (such the service identifier OID subtree) for the
services themselves? Such a larger scope would also allow the FW to be
the home for the normative material regarding the service state
machines that is currently in the Guidelines.
>>YD. To be discussed
"John Pietras"
<john.pietras at gst.
com> To
Sent by: <css-csts at mailman.ccsds.org>
css-csts-bounces at m cc
ailman.ccsds.org
Subject
[Css-csts] RE: Procedures Identifier
13/08/2009 16:42 Observations/Questions
CSTSWG colleagues –
I just sent out the message below, in which in point (6) I suggested that the
OID tree for service identifiers be moved from the Framework to the
Guidelines. I just realized that this would not be necessary if the document
were truly scoped to be the Framework for CSTSes (as its name implies) and
not just the definition of the standard procedures (as is currently
constrained in the Purpose and Scope sections, and by file name of the
document itself). Should the Purpose and Scope (and file name) be expanded to
let this be truly the Framework for CSTSes, which would include not just
definition of the procedures but also infrastructure (such the service
identifier OID subtree) for the services themselves? Such a larger scope
would also allow the FW to be the home for the normative material regarding
the service state machines that is currently in the Guidelines.
[NOTE – another typo on page 1-1: section 1.1 is “PURPOSE AND SCOPE” and
section 1.2 is “SCOPE”].
Best regards,
John
From: John Pietras
Sent: Thursday, August 13, 2009 10:11 AM
To: css-csts at mailman.ccsds.org
Subject: Procedures Identifier Observations/Questions
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
_______________________________________________
Css-csts mailing list
Css-csts at mailman.ccsds.org
http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts
More information about the Css-csts
mailing list