[Css-csts] RE: MD-CSTS "RIDs" resulting from Guidelines comparison - part 2

[John Pietras]

Dear Yves,
Here is the completion of my attempt to address the issues that were raised by you after your analysis of the MD-CSTS vis-à-vis the Guidelines. Since my previous email (part 1) listed 2 topics, this note picks up with topic #3.

3.    In my review of the previous version of the Guidelines, I had asked if the Imported Identifiers module (see section 4.10.4 of the Guidelines) should also import the procedure identifiers of the procedure identifiers that are directly adopted or refined-only. Under section 10.4.6 of the Guidelines, I asked a similar question - should the new service's object identifier module annex specify the procedures that the service directly adopts or simply refines. Your response to both questions was that the import would only be required if the original procedure or procedure ID  would be reused to build a new OID, and that we do not need to import the SFW procedure IDs otherwise. I concur with that response.

Taking that logic one step further, it should not be necessary to import in the service's object identifier module annex any service-generic parameter OIDs (as defined in E3.17 of the CSTS SFW) or the OIDs of parameters, events, or directives that belong to the Framework procedures used by the service (as defined in E3.16 of the CSTS SFW). The assumption should be that all service-generic parameters and  parameters, events, or directives that belong to the Framework procedures used by the service are automatically included in the service, and can only be excluded by explicitly excluding them. At the London meeting, the WG agreed that any refinements of the definitions of the service-generic parameters would be documented in a separate section, as has been done in the version of the TD-CSTS that was posted to the CWE before the London meeting. I propose that we generalize this new section to also include refinement of the definition of any framework procedure parameter, event, or directive, and to also include the exclusion of any service-generic parameter or any framework procedure parameter, event, or directive. To the degree that such refinements and/or exclusions will not take place, the new section will only rarely be needed. If the WG agrees to this approach, I offer to try to generate some text for the Guidelines.

In the spirit of not needing to add the OIDs for the service-generic parameters and framework procedure parameters, events, and directives to a service's object identifier module annex, I have deleted the import of those parameters from the MD-CSTS Service Object Identifier Module (annex B).


4.    I had asked another question on the Guidelines' Service Procedure Identifiers section (4.10.6). I asked "Since the procedure IDs are used only in the context of the service, is it necessary to register them with SANA?", to which you responded "In principle this is not required. I personally find a good practice to centralize the registration with SANA so that one can get a clear view of the OID. The WG should decide."

As you know, I was not in the meeting when the Guidelines document was discussed. Was this question brought up, and did the WG make a decision? The answer to this question does not affect the MD-CSTS (because the MD-CSTS does not extend any procedures), but I thought I would ask the question since it was identified in the comments as something the WG would have to decide on.

I believe that this concludes the list of questions and issues that you raised regarding the Guidelines as they apply to the MD-CSTS. I look forward to your responses.


Best regards,
John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20141124/9610dbc8/attachment.html>