<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Hi Rick,</div>
<div><br>
</div>
<div>Thanks for taking the time to read through and comment on this stuff. I'll put the answers in-line, below.</div>
<div><br>
</div>
<div>Cheers, Peter</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span><Barton>, Richard Barton <<a href="mailto:richard.j.barton@nasa.gov">richard.j.barton@nasa.gov</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, June 9, 2015 at 7:43 AM<br>
<span style="font-weight:bold">To: </span>Peter Shames <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>>, CCSDS Engineering Steering Group - CESG Exec <<a href="mailto:cesg@mailman.ccsds.org">cesg@mailman.ccsds.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [CESG] Follow up on CESG discussion of SANA and registry changes<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div>Peter,</div>
<div><br>
</div>
<div>I have finished reviewing the draft changes to the SANA Yellow Book, and I think your changes will improve the current book considerably and address the issues that you have previously identified with the creation and maintenance of the registries. There
were only two things that remain unclear to me:</div>
<div><br>
</div>
<ol>
<li>Can an expert group consist of a single person? In many cases, as for example with the new RFID Data Encoding Blue Book registry, it seems likely that at any time, a single point of contact will be identified (possibly with a back-up) to approve all changes
to this registry. Is that acceptable?</li></ol>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div>The text should read "expert or expert group". In all cases you need one person to be the "belly button", usually with a back-up. In some cases just a single expert PoC is all that is needed. In other cases, such as with XML or ontologies, we would,
I think, be best served by an informal team of experts who would analyze issues and render judgements.</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<ol>
<li>I’m not sure I agree with your contention that existing registries should be revised or referenced whenever possible rather than creating new registries. As new registries can only be created in new Blue Books or new Magenta Books, as specified in one of
your edits, it seems logical to me that someone who wants to know what has been registered with respect to that particular Blue Book or Magenta Book would find it more convenient to have a single registry to check that is explicitly identified with that book.
I understand the SANA Considerations section of the book will always specify which registries are related to the book in question (or it should, I guess), but wouldn’t it be cleaner and less confusing if all new recommended standards or practices had a similarly
numbered or named registry automatically associated with them that one could look for? It could be empty, of course, if it was not really needed, but it would still have place holder and could be created or revised without causing any confusion with other
registries.</li></ol>
</div>
</div>
</div>
</div>
</blockquote>
</span>
<div>In many cases I think that there will indeed be singular registries that associate with singular standards. The RFID registry itself is a good case in point. And if you look we have quite a few of those already and there will be more in the future.
So if the question is asked "is there another RFID registry I can use or extend?" the answer is "No". </div>
<div><br>
</div>
<div>However, and this is really the motivator, if I want to create an RFID registry, and in that registry I need a field for the agency that registered it, and that agency must have a PoC (the belly button) who gets to manage the registry, and the list of
all the RFID Agency PoCs needs to be registered somewhere …</div>
<div><br>
</div>
<div>That is where I say:</div>
<ol>
<li>Use the agency registry that exists</li><li>Use the agency appointment process to create the new RFID PoC</li><li>Put the RFID PoC into the CCSDS Persons registry</li><li>Add a role to the CCSDS Persons registry for "RFID PoC"</li></ol>
<div>We just do not need a whole lot more weakly specified agency, persons roles, registries and that is what is happening already. We need a nice clean way to extend the registries that we have. So if you are in the RFID registry and you see "agency x" and
want to know who to talk to you go look in the Organization registry for that agency, and in that agency for the RFID PoC person. Using OIDs you could even have an OID entry in the RFID Registry for "agency contact" that would take yopu right to that person
in the Person registry.</div>
<div><br>
</div>
<div>Can you see you this makese sense instead of each new standard creating its own "agency list" and "PoC list"?</div>
<div><br>
</div>
<div>Thanks, Peter</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>
<div>Just my two cents worth.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Rick</div>
<div><br>
</div>
<div>
<div>Richard J. Barton, Ph.D.</div>
<div>Wireless and Communication Systems Branch</div>
<div>NASA Johnson Space Center</div>
<div>2101 NASA Parkway</div>
<div>Mail Code EV811</div>
<div>Houston, TX 77058</div>
<div>281-483-1444 (office)</div>
<div>281-483-5830 (fax)</div>
<div>713-818-4076 (cell)</div>
<div><br>
</div>
</div>
</div>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span><Shames>, "Peter M (312B)" <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>><br>
<span style="font-weight:bold">Date: </span>Wednesday, June 3, 2015 at 2:56 PM<br>
<span style="font-weight:bold">To: </span>CCSDS Engineering Steering Group - CESG Exec <<a href="mailto:cesg@mailman.ccsds.org">cesg@mailman.ccsds.org</a>><br>
<span style="font-weight:bold">Subject: </span>[CESG] Follow up on CESG discussion of SANA and registry changes<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Dear CESG colleagues,</div>
<div><br>
</div>
<div>Attached please find three <b><i>draft</i></b> sets of document edits to the following:</div>
<ol>
<li>The SANA Yellow Book, CCSDS 313xoy1 SEA edits</li><li>The SCID Blue Book, CCSDS 320x0b6c1_mods</li><li>The MACAO Blue Book, CCSDS 630x0b1_mods</li></ol>
<div>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.</div>
<div><br>
</div>
<div>Here is what they currently have defined:</div>
<div><br>
</div>
<div><b>SCID Blue Book, CCSDS 320x0b6c1, currently contains:</b></div>
<ol>
<li>A SCID registration process</li><li>A set of rules for who can request SCID changes, which references:
<ol>
<li>A "CCSDS agency" may be a member or observer agency</li><li>An Agency Head of Delegation</li><li>An Agency Representative who can make changes, appointed by the Agency HoD</li><li>The Secretariat which does issue resolution and handles requests for agencies not affiliated with CCSDS</li></ol>
</li><li>None of these registries were specified, nor were references to other sources provided</li><li>There is not even a spec for what the structure of the SCID registry should be</li><li>A form for submitting requests / return of SCIDs</li></ol>
<div>What is in the proposed revisions:</div>
<ol>
<li>A SANA registry considerations section formally defining the SCID registry, structure, and contents</li><li>SANA rules and registration authority for this registry, as requested in the SANA YB</li><li>Addition of a unique OID assignment along with the SCID which must be "re-cycled" when no longer needed</li><li>A few new fields in the SCID registry, for S/C names, aliases, and the OID</li><li>References to the agency, agency HoD, and agency representative registries that the MACAO describes</li><li>Extensiosn to the SCID form to add OID and optional S/C name & aliases</li></ol>
<div><b>MACAO Blue Book, CCSDS 630x0b1, currently contains:</b></div>
<ol>
<li>MACAO creation and extension procedures</li><li>A set of rules for creating and operating the MACAO, including the CA Agent as the top level</li><li>Definitions for:
<ol>
<li>CA RP originator info model (assigned agent to make registrations)</li><li>CA Reviser info model (assigned agent to change registrations)</li><li>References to the Agency, Agency Representaive, and Agency Head of Delegation</li><li>Definition for MACAO creation request info model, including agency & AR references and MACAO info model</li><li>Agency and MACAO info model</li></ol>
</li><li>Several of these info model structures are quite well specified, but there is no specificaiton of registries</li><li>There is no full agency specification, nor a full agency HoD or AR specification, and none of the info models include accurate field specifications </li></ol>
<div>What is in the proposed revisions:</div>
<ol>
<li>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)</li><li>SANA rules and registration authorities for each registry, as requested in the SANA YB</li><li>Complete specification of the relationships among Secretariat, agency, HoD, AR, and MACAO structures</li><li>Clarification of the SANA role as the CA Agent to replace the defunct WDC-A</li><li>A few new fields in the Orgnization and Contacts registries, for the OIDs</li><li>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).</li></ol>
<div><b>SANA Yellow Book, CCSDS 313xoy1, currently contains:</b></div>
<ol>
<li>SANA Role, responsibilities and policies, speifically focused on what the SANA and the operator must do, less about the users of SANA</li><li>SANA / WG relationship (which has some inaccuracies that need fixing)</li><li>Simple rules for creating new registries and changing existing ones</li></ol>
<div>What is in the proposed revisions:</div>
<ol>
<li>Clarification of SANA role in providing on-line, web accessible, registries</li><li>Clarification of SANA / WG relationship</li><li>References to the organization, person, OID, and other registries that are intended for adoption and re-use</li><li>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.</li><li>Definition of the Expert Group and policy </li></ol>
<div><b>Some further comments for consideration</b></div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks, Peter</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
</div>
</span></div>
</div>
</blockquote>
</span>
</body>
</html>