[Css-csts] Object Identifier and Examples of Service Specifications

[Yves.Doat at esa.int]

Dear John,

Please find below your comments and my answers. I will update the document
accordingly.

Best regards
Yves


1. Given that we now have a formal ASN.1 module for object identifiers, it
seems unnecessary to have the Service Identifiers section (2.3.1 and 3.3.1 in
the technical note) and Procedure Type Identifier section (2.3.4.2.2 and
3.3.4.1.2 in the technical note).
I agree with your proposal for 2.3.1 and 3.3.1.
Regarding the procedure type identifier, this cross reference should help the
implementors to find the correct OID. We can discuss the needs.

2. Your examples raise some questions about either the revised concepts for
dealing with refinement or my understanding of those concepts. According to
the Minutes of the Meeting, "A refinement of a procedure does not require a
redefinition (uses the procedure as is)." >From this, I believe that the "1"
in the Version/Buffered Data Delivery cell of table 2-1 should be a "-"
instead, signifying that the BDD procedure the one from the Framework and not
a new one particular to the Concrete Data Refinement CSTS.
 I agree with you. The text will be updated.

3. Also, from my understanding of the discussion that had occurred within the
CSTSWG, the set of possible values for the "Specification of Approach" row of
the service composition table (e.g., table 2-1 in the technical note) has
been expanded from the set (adopted, derived, service-specific)
to (adopted, refined only, extended only, refined and extended,
service-original*). So the entry in the Specification Approach/Buffered Data
Delivery cell of table 2-1 should be "refined only".
[*NOTE - In response to Tim Ray's observation that "service-specific" was not
a good descriptor for procedures that newly-created for a service, I'm
proposing to change it to "service-original", and will use that term
throughout these comments.]
 I agree with you. The text will be updated.

4. Table 2-1 shows Version "1" for the Notification procedure, which is
adopted. I believe that this should be "-" instead, because it adopts the
procedure from the Framework.
 I agree with you. The text will be updated.

5. In section 2.3.4.2.4.1 (TRANSFER-DATA), in accordance with the Guidelines
(and keeping in the style of the FW procedures) there should be an
"Invocation and Parameters" subsection that contains a "data refinement"
subsection with something like the following "The data parameter shall
contain a transfer frame using the octet-string value."
 I agree with you. The text will be updated.

6. It is my understanding that we talked about moving the ASN.1 specifics to
a normative annex, rather than specifying it in the main body of the text as
is implied by sections 2.4 and 3.4 of the technical note.
 I agree with you. However as this is not a formal document and that it
includes OID explanation and two services I did not specify that it was an
Annex. I will add Annex in the chapter number..

7. The module CCSDS-CONCRETEDATAREFINEMENT-OBJECT-IDENTIFIERS has the leaf
node "concreteDataRefinementServiceModules (4)", which is not consistent with
the FW ASN.1, in which the name of the leaf node was some form of the module
name. This is also inconsistent with section 3.4, in which the object
identifiers leaf node is under the modules node. For consistency,
CCSDS-CONCRETEDATAREFINEMENT-OBJECT-IDENTIFIERS should end with
"… concreteDataRefinementServiceModules (4)   identifiers (1)"
[QUESTION - is it sufficient to leave it a generic "identifiers" or should it
be something like "concreteDataRefinementServiceIdentifiers"?]
 "concreteDataRefinementServiceModules (4)". By using this naming we are not
in line with a non-written requirement but in line with the item (d) of C.5.3
of the Framework.
The root OID of the service is 'concreteDataRefinementService (99)' and is
located under 'serviceIdentifiers'.
The 4 OID located under the service OID are:
1. 'concreteDataRefinementDerivedService (1)'
2. 'concreteDataRefinementExtServiceParameter (2)'
3. 'concreteDataRefinementServiceProcedures (3)'
Thie following new OID is required: "… concreteDataRefinementServiceModules
(4)   objectIdentifiers (1)" .

On the other hand, do we need to have separate Object Identifier and
Extension modules for each new service. Is it possible to have a single
"service data" module that would contain all service-specific ASN.1, e.g.
CCSDS-CONCRETEDATAREFINEMENT-SERVICE-DATA? Within this one module the object
identifiers and extensions could be separated by comments. That would also
make the registration tree a little bit flatter, because it could eliminate
the intermediate modules node (since there is only one module).

If there is only one module per service, that might also eliminate the need
to export the extension service parameter and service procedure OIDs.
 I prefer to handle small ASN.1 modules to large ASN.1 modules. I would not
have a strong objection to have in simple cases only one module. We would
still have to export the derived service OID that would be required for
future derived services..

8. It seems a bit awkward that the Object Identifiers module is defined in
the context of the service, the object identifier for which is defined in
that module. I assume that it's legal ASN.1, and I can't think of a way
around it anyway, so I'm not suggesting any changes. I'm just noting that it
seems a little strange.
 Hummm !!! Not entirely clear to me.

9. I think that the explicit identification of exactly which CSTSFW
parameters are being refined or extended by the service still needs more.
What aout following the example of the numerous statements in Annex D of the
FW that are like the following:
"-- START Invocation extension with start and stop generation times
 -- Extended type: StartInvocation defined in the module
CCSDS-CSTS-COMMON-OPERATIONS-PDUS in [1]
 -- StartInvocation:extensionParameter"
  I added a clear reference as proposed (for the TRANSFER DATA operation).
.
Note that I cross-referenced to the module name and not the specific annex
section (D2.5) of the FW. This should make the service specifications
insensitive to numbering changes in the FW.

If the service-specific ASN.1 module(s) were to include such linkages, should
they be formally imported, or is that unnecessary because the references
appear only in comments and not in the normative ASN.1?
 We do not need any import as:
1. The refinement will be on an existing parameter;
2. The extension will be on an EMBEDDED PDV which will be defined outside the
module..

10. Consider the case of a service that changes an extended procedure and
thus results in a new version of that service. The changed procedure also
gets a new version number. How is the fact that a different version of the
procedure is in effect conveyed by the service? It is not carried in any
information that is exchanged by the service, nor is it encoded in any
modules. The only way for both side to "know" that (e.g.) version 2 of the
procedure is in effect is that version 2 of the procedure is defined in the
version-2 service specification. In other words, there appears to be no
reason to specify the procedure version number. I know that we have discussed
this in the past, and perhaps I am forgetting the reason, but I can't see a
reason for specifying the procedure version numbers.
  You are fully correct, the version number of a procedure is not exchanged
between the user and the provider. It was introduced as a mechanism to
control the versions of  the procedures to be in line with the service that
has a version number. The only information that really travels are the
service type and the service number as well as the procedure type.

11. Thinking about the technical note brought this comment to mind, even
though it is not rasied directly by the technical note, but. Consider the
case of a service that merely refines the values that parameter AA of the FW
procedure XYZ can take. By our current understanding, the original FW
procedure is cited, and no service-specific version number is assigned to it.
 In my view the refinement still creates a new service (with its own version
number and service type number).

Now let's assume that a child service is derived from that service, and the
only change that the child service makes is to refine a parameter BB of the
XYZ procedure. How does the implementer of the child service know that the
refinements of AA as well as BB must be applied?
 Same as before: the derivation creates a new service (with its own version
number and service type number).

One way to do this is by making the Source entry the name of the parent
service procedure as opposed to the name of the FW procedure, even though in
both cases it is the same (FW) version of the procedure. The citation of the
parent service is the clue that is is not purely the same as the FW
procedure, even though it is ultimately adopted from the FW.
   As each service is properly defined I do not see any confusion..

12. In table 3-1, there are several mutual contradictions for the "Extended
Notification" procedure. The name of the procedure implies that it is an
extended procedure, but the Specificatio Approach is "adopted", and there is
no extended procedure specification in the remainder of the example.
  The notification is not extended. I will rename to "Notification".

13. In section 3.3.4.1.4.1.3 (Syntax), the name of the OID should be
"siStatusStartInvocExt" instead of "siSvcStatusStartExt". The first part
should be simply "siStatus", not "siSvcStatus" because the name of the
procedure is SI Status. The name should have "Invoc" embedded in it to be
consistent with the naming convention that we adopted for the FW. Similarly,
"siSvcStatusStartDiagExt" should be "siStatusStartDiagExt" (3.3.4.1.4.1.5.2)
and "siSvcStatusTDExt" should be "siStatusTDInvocExt" (3.3.4.1.4.2.1.1).

Given that the OID is defined in the ASN.1 module, I'm not sure that it is
necessary to have the OID named in the body of the text. We don't have
similar text in the specifciation of the FW procedures.

   The terminology I used is incorrect as the syntax is not an OID but an
ASN.1 type. I will rephrase the sentence accordingly.
      The renaming of the type is Ok and I will use your proposed new names.

14. In section 3.3.4.1.4.1.3 (Syntax), the OID name is given but not the
syntax. That's probably okay, since the abstract syntax is given in the
module and its name is close enough to that of the OID to make the connection
(Note - the syntax name should be "SiStatusStartInvocExt"). However, there is
no specification of the transfer syntax. Is it a BER encoding of the abstract
syntax, or some other syntax (e.g., XML schema)? Where is the best place to
define the transfer syntax - in the main body of the text (in this case, in
section 3.3.4.1.4.1.3, or in the annex that contains the module?
    The SiStatusStartInvocExt definition refers to an ASN.1 type and not to
an OID. This type is to be used with the EMBEDDED PDV.
Looking at the Framework I could not find any standard definition of the
EMBEDDED PDV syntax OID.
MoM:
Colorado Spring (May 2005): "Identification of Extended shall be done with
OID specific to individual extension". This
ESTEC (Oct.2009):  "Considering that the extensions are defined by a
pre-defined syntax, the word “transfer syntax” shall be replaced by “syntax”
(Note: “transfer syntax” would refer to ASN.1 or XML or …)."


15. The same can be said for the syntax for the START diagnostic extension
(which should be labelled "SiStatusStartDiagnosticExt") - there is no
transfer syntax defined. The same questions about where the best place would
be to define the transfer syntax also apply.
 Your proposed label is Ok to me.
The OID are defined immediately after the extension definition. The OID name
is siSvcStatusStartDiagExt. This OID defines the syntax of the extension

16. Section 3.3.4.1.4.2.1.1 refers to siSvcStatusTDext as the syntax
extension, but isn't this really the name of the OID of the syntax extension?
This is confusing terminology. Also, In keeping with previous comments, the
names should be SiStatusTransferDataExt and siStatusTDext (the procedure is
SI-Status, not SI Service Status).
The I changed the name so that it refers to the ASN.1 type and not to the OID

17. Section 3.3.4.1.4.2.9 is an exact repeat of section 3.3.4.1.4.2.1.1.
Requirement removed.