[Css-csts] SANA considerations

[John Pietras]

CSTSWG colleagues ---
In the process of preparing the Modified Parameters Examples annex for the SFW, I had the opportunity to review the SANA Considerations in the SFW, which led to a few issues:

1.       Regarding Service-Specific OIDs (SFW H2.3), the second paragraph states "The recommendations in those Recommended Standards that specify CSTSes based on this document request SANA to update the CCSDS OID registry by adding the OIDs and labels contained in the CSTS type specific part of the above identified subtree." As noted in previous emails, there are serious problems with the version of the OID tree that is currently posted in SANA, and there is an action item to get this straightened out. It would be desirable to have the SANA registry corrected(and populated)  before the publication of SFW Blue-2 so that CSTSes could actually be implemented.



Also, I find the phrasing "The recommendations in those Recommended Standards that specify CSTSes based on this document request SANA to update ..." confusing. Are the recommendation in the Recommended Standards making the request, or are the Recommended Standards themselves making the request? And in either case, none of the current published or draft CSTS specification (MD, TD, or FF) explicitly "make a request" to SANA to update the registry - they simply state what the values are in their respective normative Object Identifiers sections. Should we add paragraph(s) to the CSTS Blue Book SANA Considerations sections to explicitly make this request of SANA?



2.       Regarding the Functional Resource Registry (SFW H2.4), we have gone from the CSTS service specification Blue Books normatively specifying the root object identifiers in the Object Identifiers annex (as was done in the MD Blue Book and the TD Red Book) to deferring assignment of these values to the SANA FR Registry (as is done in the FF service book). To reflect this change in approach, the FF SANA Considerations sections contain the following paragraphs, which have no equivalent in the MD or TD books:


The FF-CSTS relies on the SANA Functional Resource registry to register the following:

-        the FF-CSTS Provider Functional Resource Type, registered under the crossSupportFunctionalities with the classifier ffCstsProvider;

-        the first node of the ffCstsProvider subtree ({ffCstsProvider 1}), registered with the classifier ffCstsProviderParametersId;

-        the second node of the ffCstsProvider subtree ({ffCstsProvider 2}), registered with the classifier ffCstsProviderEventsId;

-        the third node of the ffCstsProvider subtree ({ffCstsProvider 3}), registered with the classifier ffCstsProviderDirectivesId.



However, unless I am mistaken, the XML files that are sent to the SANA FR registry do not actually register the parametersId, EventsId, and DirectivesId nodes directly under the service classifier, but instead immediately jump over those nodes directly to the parameters, events, and directives themselves.  If my understanding is correct, then it seems like the above lines are *not* correct, and maybe all that we should be asking SANA to register is the FR Type and assume that the first-subnode OIDs will be intrinsically derived from them based on the rules specified in the SFW. I say "intrinsically" because no one will be able to query the SANA Registry for (for example)  ffCstsProviderParametersId  - the relative OID will just be embedded in all of the registered parameter OIDs. Comments?


Finally, the TD Book has not yet been published. Should we consider making the change to defer assignment of the FR Type before it is published as Blue-1, or not "rock the boat" and publish it as-is with the understanding that the FR Type in the SANA Registry will be "forced" to match the value assigned in the TD Book (19)?



I'm looking forward to your comments.



Best regards,

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20191107/154567e8/attachment.html>