[cssm] Comments re registry procedures update

Barkley, Erik J (US 3970) erik.j.barkley at jpl.nasa.gov
Tue Dec 10 00:04:33 UTC 2019


CSSM Colleagues

Following up from our teleconference last month, below please find a forwarded email of the exchange between myself and the SE AD with regard to our look at the updated SANA registry procedures. If you wish to take a look and comment attached is the updated procedures -- both with change tracking and also the "clean" version.  I propose to introduce this at the teleconference tomorrow and then perhaps we could have any comments ready at a subsequent teleconference.

Best regards,
-Erik

From: Shames, Peter M (US 312B)
Sent: Friday, November 22, 2019 10:37
To: Barkley, Erik J (US 3970) <erik.j.barkley at jpl.nasa.gov>
Subject: Re: Registry process slides

Hi Erik,

Thanks for the feedback.  I'll insert my comments <<inline>>.   As I worked through the mods to these three docs I arrived at the conclusion that some modest deltas would be useful and those are reflected in the draft docs, particularly 313.2-Y-2.  Keep in mind that this is intended for use by all WG that need to create registries, and that its new form is intended to put all that a WG needs to know to create, describe, submit, get them reviewed, and approved in one place.  I hope it is now both "short enough" and also complete enough.

Since your CSS guys make a lot of use of registries it would be great to get them to look at the doc, not just a one page summary of changes.  Is that possible?  I've attached the raw edited version and a clean one with "accept changes" applied.  Feel free to send either to your team. The feedback would be useful.

Thanks, Peter


From: Erik Barkley <erik.j.barkley at jpl.nasa.gov<mailto:erik.j.barkley at jpl.nasa.gov>>
Date: Thursday, November 21, 2019 at 5:59 PM
To: Peter Shames <peter.m.shames at jpl.nasa.gov<mailto:peter.m.shames at jpl.nasa.gov>>
Subject: RE: Registry process slides

Peter,  here are notes from walking through the slides at the CSSM WG telecon this past Tuesday.  I think they are fairly self-evident, but if you need more input please let me know.  I think some definitions and or adoption of the traditional CCSDS color codes would help.

-Erik


a.       Can a “beta registry” be essentially a “correct” structure with garbage values?  <<The initial Beta can be empty and the contents and structure can be modified over time.  But the WG ought to use this development time to populate the Beta with at least some representative data as examples.>>

b.       Does a “candidate registry” mean at least some “real” values are present?  <<Since the intent is that the initial CESG review, prior to first release for Agency review, verify Candidate registry structure and forms, it would be useful to have at least some real or representative values.  In Sec 2.3, which is the process flow, it now says this:

h) The Working Group should populate the Beta registry with initial values and make any adjustments to registry structure, formats, fields, and related references (such as references to Organizations or Contacts registries, or adding new Roles) prior to requesting initial Red Book Agency review.

>>.

c.       Does “approved registry” mean only “real” values are present?  <<That is the intent.  An Approved registry occurs only after the doc is published.   Nominally this migrates the Candidate registry from the Beta website to the Production website and marks it as Approved.  I guess that if there is not "real" data then a WG has two choices at that point:  1) Migrate it but leave it in the Candidate list until it has vetted real data, or 2) Migrate it and mark it as Approved, but mark any data that is not "Approved" as "Provisional".  Do you guys have any opinions about those options, or do you want both to be spelled out?  >>

d.       Could these also be considered to be the equivalent of a white registry versus a red registry versus a blue registry?  <<I had not thought to map them in that way, but I think you could make the following equivalences:  1) Initial Candidate registry in Beta website == White; 2) Updated Candidate registry in Beta website that is approved by CESG == Red; 3) Approved registry in Production website == Blue (even if it has some Provisional content).  I do not know what color would be the equivalent for a registry that is Migrated to the Production website after the doc is approved, but left in Candidate status.  That is essentially what I proposed for any registry that is in a published Orange Book, so maybe that would be == Orange. >>

e.       Suggested that agency reviews should emphasize more reviewing of the registry structure and content <<That sounds like something that belongs in the Org & Proc updates that Tom needs to do>>.

f.        noted that the procedures discussed in the presentation did not really address checking a bigger picture information model for reuse and/or augmentation of existing registries rather than creation of new registries  <<That topic is (and has been) explicitly included in the 313.2-Y-2 doc, in sec 2.3.b and also in 3.2.3.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20191210/8ffbe187/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 313x2y2_draft_v1-accept.doc
Type: application/msword
Size: 172544 bytes
Desc: 313x2y2_draft_v1-accept.doc
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20191210/8ffbe187/attachment-0002.doc>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 313x2y2_draft_v1.doc
Type: application/msword
Size: 190976 bytes
Desc: 313x2y2_draft_v1.doc
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20191210/8ffbe187/attachment-0003.doc>


More information about the SMWG mailing list