[Sls-slp] CCSDS SANA and Silver Book references

Mon Feb 17 10:19:48 UTC 2020

Dear SLPers,
        note that you cannot reply to CESG Polls for SANA Documents, 
therefore comments should be provided to SLS Area AD/DAD to allow 
conversion into PIDs to the CESG Polls.
Regards
Gian Paolo

From:   "Shames, Peter M\(US 312B\) via SLS-SLP" 
<sls-slp at mailman.ccsds.org>
To:     "Kazz, Greg J (US 312B)" <greg.j.kazz at jpl.nasa.gov>, "Gian Paolo 
Calzolari" <Gian.Paolo.Calzolari at esa.int>, "Matthew Cosby" 
<Matt.Cosby at Goonhilly.org>, "Wilmot, Jonathan J. (GSFC-5820)" 
<jonathan.j.wilmot at nasa.gov>, "Marco.Rovatti at esa.int" 
<Marco.Rovatti at esa.int>
Cc:     "Kazz, Greg J\(US 312B\) via SLS-SLP" <sls-slp at mailman.ccsds.org>
Date:   13-02-20 18:24
Subject:        Re: [Sls-slp] CCSDS SANA and Silver Book references
Sent by:        "SLS-SLP" <sls-slp-bounces at mailman.ccsds.org>

Hi Guys,

This is just a reminder that the SANA YB review is on-going and that now 
is the time to review these (all three, or at least the WG procedures 
CCSDS 313x2y2) and weigh in on them. 

Thanks, Peter

From: Peter Shames <peter.m.shames at jpl.nasa.gov>
Date: Thursday, February 6, 2020 at 8:19 AM
To: Greg Kazz <greg.j.kazz at jpl.nasa.gov>, Gian Paolo Calzolari 
<Gian.Paolo.Calzolari at esa.int>, Matthew Cosby <Matt.Cosby at Goonhilly.org>, 
"Wilmot, Jonathan J. (GSFC-5820)" <jonathan.j.wilmot at nasa.gov>, 
"Marco.Rovatti at esa.int" <Marco.Rovatti at esa.int>
Cc: "Kazz, Greg J (US 312B) via SLS-SLP" <sls-slp at mailman.ccsds.org>
Subject: CCSDS SANA and Silver Book references

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
 _______________________________________________
SLS-SLP mailing list
SLS-SLP at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sls-slp

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls-slp/attachments/20200217/173d789e/attachment-0001.htm>