[Css-csts] Object Identifier and Examples of ServiceSpecifications - continued

[John Pietras]

Yves,

Here are some more questions and comments, most (but not all) of which
deal with the specification of the extensions.

 

1. In the example Service Instance service specification (section 3),
there is a "service-instance-identifier" parameter in the TRANSFER-DATA
extenison parameters. This is a bit confusing, because the service
instance has alrady been identified by the BIND. I realize that this is
a made-up exampe, but I found it a bit distracting. 

 

2. In section 3, the "load-status" parameter in the TRANSFER-DATA
extenison parameters table is indicated as being conditional. However,
the definition of the parameter  doesn't mention it's being conditional,
and the ASN.1 specification in section 3.4.2 shows it as always present
in the SiStatusReport type.

 

3.   In the example Extensions module in section 3, the module imports
siDerivedService, siExtServiceParamter, and siServiceProcedures.
siExtServiceParameter is needed by the module to form the OIDs for the
extensions, but the other two are not used in this example module, and I
can't think of a case where the derived service subtree would ever be
used .

 

4.  In the example Extensions module, there is a section labeled
"common types used by the extensions", but the types listed under there
are all associated with the TRANSFER-DATA extension only. Perhaps I'm
being too picky, but the word "common" led me to believe that theses
types were shared among two or more extensions. Is there a purpose for
including the word "common", or can we delete it and just label the
section "common types used by the extensions"?

 

5.  For the SI service in section 2, there is only one extended
procedure, so the Extensions module doesn't have to differentiate
between tow or more extended procedures. But if there are two or more
extended procedures, should all of the extensions be in one module, or
should each procedure have its own module (as is done in the Framework
itself)? I tend to like the one-module-per-extended-procedure approach,
because it makes what extension go with what operations of what
procedures unambiguous and the Framework procedure modules provide a
nice pattern that can be followed by all CSTSes. 

 

However, if we do that, then each extension module will have to be
identified with the procedure.  in the case of the SI service example,
the OID for the extensions module for the service currenly looks like

CCSDS-SI-CSTS-EXTENSIONS

{     iso identified-organization (3)
standards-producing-organization(112)

      ccsds(4) csts(4)services (2) serviceIdentifiers(2) siService (999)


      siServiceModules (4) extensions (2)

}

 

If we follow the style of the Framework, the extensions would be in a
"PDUs" module for the SI Status procedure, which might look like:

CCSDS-SI-CSTS-SI-STATUS-PDUs

{     iso identified-organization (3)
standards-producing-organization(112)

      ccsds(4) csts(4)services (2) serviceIdentifiers(2) siService (999)


      siServiceModules (4) extensions (2) siStatusPdus (1)

}

 

Having a separate module per procedure will also make it easier to
address service-original procedures, in which not just operation
extensions have to be formally defined, but the content of the PDU for
that new procedure (expressed as a selection of components from the
CstsFrameworkPdu type).

 

5.  Consider the case of a procedure that is derived from another
procedure by adding another operation, e.g.,  a Controllable Unbuffered
Data Delivery procedure for an XYZ service that extends the Framework
UDD procedure with an EXECUTE-DIRECTIVE operation that is extended for
the derived procedure. I think the resulting "PDUs" module would look
something like what is in the attached. Do you agree?

 

6. Now consider the same service and procedure, but  we'd like the
EXECUTE-DIRECTIVE operation to be the one that is defined for the Throw
Event procedure. As the Framework is currently structured, I think we
have to redefine the same extension as part of the XYZ service
specification and give it a new OID, since the Throw Event procedure
doesn't export the extension type
TeExecuteDirectiveNegReturnDiagnosticsExt. Do we want to be able to
import extension types and not just the common operations? If so, this
would be a RID on the CSTS FW Red Book. Would  the extension syntax OID
have to be exported/imported as well as the type itself?

 

The more I work on this, the deeper the hole seems t get. I look forward
to your responses. Hopefully you will at least get the chance to read
through these and the previous comments that I sent befeor next week's
telecon.

 

Best regards,

John

 

.  

________________________________

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20100708/5f1d386a/attachment.htm