[Css-csts] more procedure identifier questions

[Yves.Doat at esa.int]

Dear John,

Please find below some answers:

1. Section C.4.2 of the R-0.19 Framework states:
Whenever a new service (non-derived) is specified a new object identifier is
allocated directly under one of the branches “prototypesIdentifiers” or
“servicesIdentifiers”. The allocated number shall be complemented with three
sub-numbers:
                                                      i.             (service
               name)DerivedServices:  to  register  services derived from the
               specified service;
                                                     ii.             (service
               name)ExtServiceParameters to register parameters syntax;
                                                   iii.              (service
               name)ExtServiceProcedures  to  register derived procedures for
               this service.

The name of the last sub-number, “(service name)ExtServiceProcedures”, and
its definition, “to register derived procedures for this service”, imply that
this sub-number is to be used only for procedures that are derived from other
procedures. What sub-number should be used for service-specific procedures
that are not derived from other procedures? If the intent is for this
sub-number to be used for any procedures for the new service, it might be
more clear to call it “(service name)serviceProcedures” and define it as “to
register procedures for this service”. If the intent is for this sub-number
to be used only for derived procedures, then an additional sub-number needs
to be defined, e.g., “(service name)serviceSpecificProcedures”, defined as
“to register procedures that are created for this service without
derivation.” I personally don’t see any reason to use two sub-numbers here,
and so suggest taking the “(service name)serviceProcedures” approach.

Answer:
Your comment brings us back to a question that has been discussed a number of
time: How do we treat services that bring their own new procedure(s)?
Just to keep my answer short, the simplest way to define and in the future
maintain is your proposed approach. I will update the document accordingly
using “(service name)serviceProcedures”


2. The same ambiguity exists in section C.4.3, regarding procedures for
derived services.
Same answer as previous one.

3. The object identifiers for both new and derived services (sections C.4.2
and C.4.3, respectively) “shall be complimented with three sub-numbers”. No
actual values are specified for those sub-numbers, e.g., the XYZ service may
assign its derived services the object identifier
      xyzDerivedServices   OBJECT IDENTIFIER ::= {xyz  7}
and the MNO service may assign its derived services the object identifier
      mnoDerivedServices   OBJECT IDENTIFIER ::= {mno  13}

For simplification in explanation (especially in the Guidelines), can we
simply assign these sub-numbers? That is, for example, DerivedServices will
always get “1”, ExtServiceParameters will always get “2”, and
ExtServiceProcedures (ServiceProcedures?) will always get “3”. Some of the
sub-numbers may not get used for a given service (I would expect
DerivedServices to be used the least frequently, so maybe we should assign it
“3”) but I don’t think that is any problem.
Answer:
In the annex J, the OID tree includes a template with the following
pre-allocation of numbers:
   derivedServices:                 1
   extServiceParameters:            2
   serviceProcedures:               3
I will add these numbers in the Annex C.

Best regards

Yves DOAT
__________________________________________________
Head of the Stations and M&C Integration Section (OPS-GSI)
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/
__________________________________________________