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

[Shames, Peter M (312B)]

Erik has seen this stuff, but this will keep the rest of you in the loop since you are part of the "SANA re-engineering guinea pig" group.

These docs include the proposed mods to the three specs and also the explicit info model changes.  They are a little rough yet, but should be readable.

Peter


From: <Shames>, Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Date: Wednesday, June 3, 2015 at 12:56 PM
To: CCSDS Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org<mailto:cesg at mailman.ccsds.org>>
Subject: Follow up on CESG discussion of SANA and registry changes

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:
     *   A "CCSDS agency" may be a member or observer agency
     *   An Agency Head of Delegation
     *   An Agency Representative who can make changes, appointed by the Agency HoD
     *   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 & aliases

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:
     *   CA RP originator info model (assigned agent to make registrations)
     *   CA Reviser info model (assigned agent to change registrations)
     *   References to the Agency, Agency Representaive, and Agency Head of Delegation
     *   Definition for MACAO creation request info model, including agency & AR references and MACAO info model
     *   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 specifications

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 fixing)
  3.  Simple rules for creating new registries and changing existing ones

What is in the proposed revisions:

  1.  Clarification of SANA role in providing on-line, web accessible, registries
  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 policies.

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







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150603/532eeaa5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 320x0b6c1_mods_2-2Jun15.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 125662 bytes
Desc: 320x0b6c1_mods_2-2Jun15.docx
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150603/532eeaa5/attachment.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 630x0b1_mods-2Jun15.docx
Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document
Size: 389616 bytes
Desc: 630x0b1_mods-2Jun15.docx
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150603/532eeaa5/attachment-0001.docx>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SANA YB 313x0y1 SEA edits 13Apr15.pdf
Type: application/pdf
Size: 516689 bytes
Desc: SANA YB 313x0y1 SEA edits 13Apr15.pdf
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150603/532eeaa5/attachment.pdf>