[Css-csts] SANA considerations - continued

[John Pietras]

CSTSWG colleagues ---
In email that I sent yesterday (see below), I concluded by asking the question of whether the Tracking Data CSTS book should be modified before publication to remove the specification of the Functional Resource Type from the book and instead have the book defer the allocation of that value to the SANA FR Registry. I had forgotten that Holger's MoM for the Workshop states that the SANA Registry values currently 46 for MD-CSTS and 38 for TD-CSTS) will be aligned with the values specified in the books themselves (MD: 17, TD:19) (Section 7, FR Tech Note and FR Model).

However, we had also discussed at the workshop a new numbering scheme for SANA FR Registry, in which the values would be offset by 1,000 or 10,000. If we use this new numbering scheme it will not be possible to continue to use the 2-digit values currently assigned to MD and TD. Unfortunately , this part of the discussion was not recorded in the MoM. But if the new numbering scheme is adopted, then the TD and MD books will have to be modified in any case. Because the TD book is still awaiting publication, the change can be made in that book to have the assignment deferred to the SANA Registry. It would not be so easy to modify the MD book because it has already been published, but in the meeting we mentioned the possibility of publishing a Technical Corrigendum to make the change.

Best regards,
John

From: John Pietras
Sent: Thursday, November 07, 2019 11:01 AM
To: CCSDS_CSTSWG (css-csts at mailman.ccsds.org) <css-csts at mailman.ccsds.org>; Wolfgang Hell <wo_._he at t-online.de>
Subject: SANA considerations

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/20191108/ec619648/attachment.html>