[Sls-slp] CCSDS SANA and Silver Book references
Gian.Paolo.Calzolari at esa.int
Gian.Paolo.Calzolari at esa.int
Mon Feb 17 10:19:48 UTC 2020
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.
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>
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.
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
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
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...
More information about the SLS-SLP