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

Mon May 17 15:48:31 EDT 2010

Yves,

I'm very impressed by the way that you were able to produce this
document so quickly after the conclusion of the meeting. 

The biggest concern that I have is that the specification of non-ASN.1
transfer syntaxes is still ambiguous.

Here are some more-detailed comments:

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). 

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. 

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.]

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.

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."

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. 

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"?]

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.

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.

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"

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?

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.

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. 

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?

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.

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. 

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. 

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?

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.

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).

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

-----Original Message-----
From: css-csts-bounces at mailman.ccsds.org
[mailto:css-csts-bounces at mailman.ccsds.org] On Behalf Of
Yves.Doat at esa.int
Sent: Tuesday, May 11, 2010 10:32 PM
To: css-csts at mailman.ccsds.org
Subject: [Css-csts] Object Identifier and Examples of Service
Specifications

Dear all,

As agreed during last week meeting I drafted a technical note covering:

   Object Identifiers: definition and use by CSTS: for the concept;

   Example of a service refining Framework procedures (transfer of
frames);

   Example of a service extending Framework procedures (Service Instance

   monitoring).

   In order to be complete I included the syntax definition of the
extensions

   (ASN.1)

The examples follow the Guidelines (and add some subsections) should be

considered for the Guidelines. Once agreed (format and content) and if
needed

I could prepare an example of abstract service with  a derived concrete

service.

I would appreciate

   to get comments/questions for improvements.

   if  somebody could have a look to the extensions and see if it clear
which

   Framework ASN.1 extensions are to be used . If not clear I will think

   about how to clarify the matter.

I uploaded the technical note to the CWE: "CWE Private / CSTS Framework
and

Concept /  Object Identifiers and Examples of Services i1.0.doc".

Best regards

Yves

__________________________________________________

Head of the Ground Facilities Infrastructure Section  (OPS-ONI)

in the Ground Facilities Operations Division

ESA/ESOC Robert-Bosch Strasse 5

D-64293 Darmstadt, Germany

Tel.: +49 (6151) 90.2288               Fax:+49 (6151) 90.3046

Internet: http://www.esa.int/

__________________________________________________

_______________________________________________

Css-csts mailing list

Css-csts at mailman.ccsds.org

http://mailman.ccsds.org/cgi-bin/mailman/listinfo/css-csts

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