[Sls-slp] CCSDS SANA and Silver Book references

Thu Feb 6 16:19:39 UTC 2020

Dear SLP Colleagues,

Thank you for the discussion that we just had about the SPP secondary header registry additions that are in approval within the SPP revision.  While it is clear that there are some differences of opinion about just how to handle this case, and apparently about the handling of SANA registries in general, I think we came to a resolution that is acceptable, at least to me.

I do invite you to look at the current DRAFT revision of the CCSDS Procedures for SANA Registry Specification, CCSDS 313.2-Y-2, that is now out for Agency review (attached).  This is a revision of the current procedure, version 1, that brings together into one intentionally concise, but still precise, spec all of the details and procedures that a WG must be aware of in order to create any new registry or to modify an existing registry.  It also clearly spells out (at least I think it is clear, but you please tell me if that is not so) the requirements on what you must specify (registry structure and rules), where it is to be specified (in the SANA Annex to any Blue or Magenta book), and when it must be done (prior to the first agency review).  We have tried to clarify the process for the WG so that this is unambiguous.

I will point out that all of this has been required of WGs since the SANA was created in 2004.  The SANA rules and procedures were published in 2011, and this is where the required structure and contents of the SANA Annex in each BB or MB that required a registry was first specified.  And all of the re-engineered registries and process for the WGs has been documented since the Registry Management Policy, CCSDS 313.1-Y-1, and the initial WG Procedures, CCSDS 313.2-Y-1, were published in May 2016.

I mentioned during the telecon that the core of the concepts for the actual format, structure, and process for these registries had been around for quite a while.  Matt asked for a link.  There were actually two documents, one now Silver (retired), that were the source of the Organizations Registry, the Contacts Registry, and the SCID Registry that we have today.  The re-engineered registries and procedures documented in the CCSDS Registry Management Policy (RMP), CCSDS 313.1-Y-1, published May 2016, were lifted essentially verbatim from a merge of the key concepts in these two original documents:

  1.  CCSDS 320.0-B-1, Oct 1993, Global Spacecraft Identifier (GSCID) Field Code Assignment Procedures,  https://public.ccsds.org/Pubs/320x0b1s.pdf.  Defines the GSCID procedures, who could do it, how it was to be done, and provided the (quickly out of date) list of the then current Heads of Delegation (HoD) for the then current CCSDS agencies.  At that time there were nine agencies, not eleven.  Some of the existing agencies have changed their names, and only one of the nine Agency HoD is still participating in CCSDS.  Recognizing this flux was one of the reasons for creating separate Organizations and Contacts Registries in the SANA.  The other one was that at least seven other CCSDS standards had created "Organizations Registries" with various levels of specificity and accuracy.  And there were four Contacts registries with a similarly varied set of contents.
  2.  CCSDS 630.0-B-1, June 1993, Standard Formatted Data Units — Control Authority Procedures, https://public.ccsds.org/Pubs/630x0b1.pdf.  This is still a current document, even though it has in part been superseded by the RMP.  The DAI WG has not yet allocated the resources to fix it.  This nominally current document defines the Control Authority (CA) procedures, the MACAO procedures, and defines the procedures and data structures for registering organizations, contact persons, and data descriptions.  It specifies the who, how, what, where, when for MACAO registries and its notion of registering data descriptors is not substantially different in kind from the concept of registering packet secondary header data structures.  The fields for their registries were carefully specified, but not the types.  The process is explicit and was adopted in the RMP.

I do tend to run on, but I wanted you all to be aware that what we are asking for is not new and it has been a formal part of CCSDS procedures since at least 2011 when the first SANA policy was documented in the now Silver CCSDS 313.0-Y-1 dated 2011 (https://public.ccsds.org/Pubs/313x0y1s.pdf).  In Annex B of that document was the following requirement:

B3 NEW REGISTRY TO BE CREATED
When a new registry is requested to be created by the SANA operator, the following information should be included into the CCSDS standards track document. SANA Considerations for each new registry should contain:
–the name of the registry
–the structure of the registry (column names, ...)
–a precise data type for each data, including boundaries
–registration rule governing how the SANA operator will assign new parameters to that registry

That document also says:

3.15 SOURCE REGISTRY FILES
The SANA operator is responsible for maintaining the source of the CCSDS registry files. The SANA operator shall publish the CCSDS registries as well as related documents and objects to the appropriate places and services defined by the CESG, nominally by a web interface.

While the SANA operator will follow the instructions in the CCSDS documents on how to structure a registry, a registry should normally have strong data typing. Currently, it is envisioned that the native format of the SANA source registries will be XML. However, presentation formats such as XHTML might also be provided by the SANA operator. Related files such as schemas and style sheets are to be designed and provided by the SANA operator.

All the work we have done since 2011, in creating the RMP and the WG procedures, has been intended to clarify what is required of the WG and of the SANA in order to make this whole notion of registries both viable and implementable.  There are presently 50 approved registries and another 21 candidate registries.  Many of these registries pre-date the publication of CCSDS 313.0-Y-1, Space Assigned Numbers Authority (SANA)—Role, Responsibilities, Policies, and Procedures.  All of them have been re-engineered, starting in 2016, to conform to the SANA RMP and to eliminate the eight separate Organizations registries and four separate Contacts registries in favor of just one of each, aligned as just described.  All of those registries created since 2011 have adhered to the CCSDS 313.0-Y-1 SANA Role, etc document.  All of those since 2016 have adhered to the SANA RMP and used the SANA WG procedures.

As noted earlier, if you all feel strongly that some other process should be followed for creating and documenting registries now is the time to try and affect that.  The RMP and SANA WG Procedures have been revised and are now in the CESG approval cycle.  That review period ends on 19 Feb 2020.

Best regards, Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20200206/9cbcbd22/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 313x2y11_CESG_Approval.pdf
Type: application/pdf
Size: 115504 bytes
Desc: 313x2y11_CESG_Approval.pdf
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20200206/9cbcbd22/attachment-0001.pdf>