[CESG] Follow up on CESG discussion of SANA and registry changes

Nestor.Peccia at esa.int Nestor.Peccia at esa.int
Wed Jun 10 13:06:11 UTC 2015

Dear all

Rick is the only one who commented Peter's updates.

Please send comments to Peter at the latest by end June 2015

>From 1st July 2015, the ADs, who own the docs, need to issue resolutions 
for the CESG reviews.


----- Forwarded by Nestor Peccia/esoc/ESA on 10/06/2015 15:00 -----

From:   "Shames, Peter M (312B)" <peter.m.shames at jpl.nasa.gov>
To:     CCSDS Engineering Steering Group - CESG Exec 
<cesg at mailman.ccsds.org>, 
Date:   03/06/2015 21:58
Subject:        [CESG] Follow up on CESG discussion of SANA and registry 
Sent by:        cesg-bounces at mailman.ccsds.org

Dear CESG colleagues,

Attached please find three draft sets of document edits to the following:
1.      The SANA Yellow Book, CCSDS 313xoy1 SEA edits
2.      The SCID Blue Book, CCSDS 320x0b6c1_mods
3.      The MACAO Blue Book, CCSDS 630x0b1_mods
As I pointed out during the CESG telecon, we do already have a set of 
agency and point of contact registries defined in a couple of CCSDS 
documents, dating back to 1993.   These registries were designed to serve 
a specific purpose, I.e. registering spacecraft IDs, and registering SFDU 
identifiers.   And they were defined prior to the existence of the SANA, 
so they make no reference to the SANA nor even to each other.  But they 
do, taken together, a pretty credible job of defining the needed 
structures, rules, and info models for the key  CCSDS "organization" and 
"contact" registries.

Here is what they currently have defined:

SCID Blue Book, CCSDS 320x0b6c1, currently contains:
1.      A SCID registration process
2.      A set of rules for who can request SCID changes, which references: 

1.      A "CCSDS agency" may be a member or observer agency
2.      An Agency Head of Delegation
3.      An Agency Representative who can make changes, appointed by the 
Agency HoD
4.      The Secretariat which does issue resolution and handles requests 
for agencies not affiliated with CCSDS
3.      None of these registries were specified, nor were references to 
other sources provided
4.      There is not even a spec for what the structure of the SCID 
registry should be
5.      A form for submitting requests / return of SCIDs
What is in the proposed revisions:
1.      A SANA registry considerations section formally defining the SCID 
registry, structure, and contents
2.      SANA rules and registration authority for this registry, as 
requested in the SANA YB
3.      Addition of a unique OID assignment along with the SCID which must 
be "re-cycled" when no longer needed
4.      A few new fields in the SCID registry, for S/C names, aliases, and 
the OID
5.      References to the agency, agency HoD, and agency representative 
registries that the MACAO describes
6.      Extensiosn to the SCID form to add OID and optional S/C name & 
MACAO Blue Book, CCSDS 630x0b1, currently contains:
1.      MACAO creation and extension procedures
2.      A set of rules for creating and operating the MACAO, including the 
CA Agent as the top level
3.      Definitions for: 
1.      CA RP originator info model (assigned agent to make registrations)
2.      CA Reviser info model (assigned agent to change registrations)
3.      References to the Agency, Agency Representaive, and Agency Head of 
4.      Definition for MACAO creation request info model, including agency 
& AR references and MACAO info model
5.      Agency and MACAO info model
4.      Several of these info model structures are quite well specified, 
but there is no specificaiton of registries
5.      There is no full agency specification, nor a full agency HoD or AR 
specification, and none of the info models include accurate field 
What is in the proposed revisions:
1.      A SANA Registry considerations section formally defining the MACAO 
agency registry, a CCSDS Contacts registry (for all persons, HoD, AR, 
MACAO originator & reviser, with full info model & extensible role set), 
and a CCSDS Organization registry (agency, observer, affiliate, with full 
info model (MACAO, etc) and extensible role set)
2.      SANA rules and registration authorities for each registry, as 
requested in the SANA YB
3.      Complete specification of the relationships among Secretariat, 
agency, HoD, AR, and MACAO structures
4.      Clarification of the SANA role as the CA Agent to replace the 
defunct WDC-A
5.      A few new fields in the Orgnization and Contacts registries, for 
the OIDs
6.      Roles fields for both Organization and Contacts registries that 
support assignment of roles like AR, MACAO originator, member / observer 
agency, service provider and that define a process for extension by other 
standards as needed (SCCM, etc).
SANA Yellow Book, CCSDS 313xoy1, currently contains:
1.      SANA Role, responsibilities and policies, speifically focused on 
what the SANA and the operator must do, less about the users of SANA
2.      SANA / WG relationship (which has some inaccuracies that need 
3.      Simple rules for creating new registries and changing existing 
What is in the proposed revisions:
1.      Clarification of SANA role in providing on-line, web accessible, 
2.      Clarification of SANA / WG relationship
3.      References to the organization, person, OID, and other registries 
that are intended for adoption and re-use
4.      A WG procedure for creating new reqistries and modifying existing 
ones that requires use (or extension) of existing registries, such as 
agency, org, persons, etc.
5.      Definition of the Expert Group and policy 
Some further comments for consideration

The adoption and extension of the existing SCID and MACAO registires was 
proposed because these already exist.  In spite of their not being fully 
specified, these two documents, taken together, do describe a quite 
commplete set of registires for agency, HoD, PoC, AR, and related 
structures.  Taken together with how these have actually been implemented 
by the SANA Operator, using a real database to manage the data and with 
web accessible interfaces, we already have a very good start in the right 
direction.  What is missing is a set of policies for re-using and 
extending these registries, and others, as the need arises instead of just 
creating new, overlapping, partially (or weakly) specified registries and 

But what this approach does is it requires  anyone who tries to understand 
these registries and how we intend them to be used and extended to read 
all three of these documents.  The SANA has to point to the SCID and the 
MACAO docs, and the SCID and MACAO each must point to each other, because 
one defines some of the info model and the other defines the rest.  It is 
workable, but awkward at best.  These mods accomplish this.

I have the belief that we could substantially improve this by creating one 
new "CCSDS registry Management Polciy" document that puts all of these 
core infrastructure, and the related policies and info models, into one 
coherent document.  If we take that approach then the changes to these two 
documents would just have to say "Use the procedures and information 
defined over there." and add the one or two unique pieces for their own 
specificly defined roles or fields.

Either approach can be made to work, let's first try to get agreement on 
the overall concept of a single, unified, set of organization and contacts 
registries, and a set of rules for extending them.

I will be meeting with the Secretariat and SANA operator to discuss these 
changes as well.  Out of that discussion should come some understanding of 
whether they agree that these changes are feasible and what the impact is 
likely to be.  I have the belief that going from 10 "organization" 
registries and 4 "people" registries down to one of each has to be a net 
benefit in on-going effort, but it will take some effort to get there.

Thanks, Peter

CESG mailing list
CESG at mailman.ccsds.org

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20150610/9f0d45ac/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 320x0b6c1_mods_2-2Jun15.docx.hqx
Type: application/mac-binhex40
Size: 694020 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20150610/9f0d45ac/attachment.hqx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SANA YB 313x0y1 SEA edits 13Apr15.pdf
Type: application/octet-stream
Size: 516689 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20150610/9f0d45ac/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 320x0b6c1_mods_2-2Jun15.docx
Type: application/octet-stream
Size: 170068 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20150610/9f0d45ac/attachment-0001.obj>

More information about the CESG mailing list