<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EstiloDeEmail18
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EstiloDeEmail19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="PT-BR" link="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">Dear Peter,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">I do appreciate the comprehensive, ontological approach you used in your “summary”, in respect to SANA.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">Just an historical addition on how it all began. Still by the mid ‘80s when with the (“old” CCSDS Panel 2) advancement of the SFDU and related concepts (Control Authority,
MACAO etc.) the need of the <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">SCID like information and procedure, related to the SFDU header eventually came up into the scene and was born, for good. Unfortunately the, then, enthusiasm with the
SCID emerging concept, led <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">to the definition of a not long enough field of definition, in the associated headers, after somewhat conservative, but heated discussions. In any case, gradually, it
became more and more clear that a<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">considerable sophistication in the management of the SCID assignments became more and more demanding. Eventually, far away later, the SANA concept came up as the solution
for such a management, <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">together with the many other new aspects that naturally came along, enforcing a fundamental need for good management over an increasingly wider number of items as part
of the process. Good to <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">learn that the SANA concept fortunately did mature in a remarkable fashion along the time, as you mentioned, and naturally, is here with us, to stay. My respect for
the work already done, in spite of<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">constant need for reviews and improvements. A natural part of this process.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">Sincerely,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">Eduardo Bergamini<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">INPE/CCSDS<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US">___________________________________________________________________________________________________________________________________________________________________<o:p></o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:11.0pt">De:</span></b><span style="font-size:11.0pt"> CMC <cmc-bounces@mailman.ccsds.org>
<b>Em nome de </b>Shames, Peter M (312B)<br>
<b>Enviada em:</b> terça-feira, 18 de setembro de 2018 18:23<br>
<b>Para:</b> CMC <cmc@mailman.ccsds.org><br>
<b>Cc:</b> SANA Steering Group (SSG) <ssg@mailman.ccsds.org><br>
<b>Assunto:</b> [CMC] Comments on SANA Discussion, 17 Sept 2018<br>
<b>Prioridade:</b> Alta<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">Dear CMC,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">If I were to summarize what I think the direction was from yesterday's telecon it is to preserve the SANA Registries that are "used to fly missions" and that are "technical registries", but to
consider removing others. There also seemed to be general support that we "not backtrack". The CMC wanted to be "in the loop" on approvals and that we all do a better job of reviewing the SANA Considerations sections of documents to evaluate any new registries
that are being proposed. Since SANA Considerations, along with Security and Patents, are required sections in any new Blue and Magenta Books, and we have both CESG and CMC approval processes in place prior to any document going outside of CCSDS for review,
it does appear that we already have a document approval flow that would support this. We just need to exercise this with due diligence.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">The other message I came away with was a desire to have the Organizations (and organization roles) and Contacts (and contacts roles) only maintained in one place. The stated preference was to
have this be in the CCSDS website and not the SANA. The biggest concern seemed to be that we use a cost effective approach to managing the required information. I do not think that anyone would argue with being cost effective, as long as the implementation
is consistent with maintaining and providing access to the information we need to make all of the supported registries continue to work as intended. In fact, I believe that all the work that we did on the Registry Management Policy, and consequent registry
re-engineering, was motivated by these same kinds of cost effective, and also technically effective, concerns.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">After thinking about this some more I realized that during the discussion about doing this in a cost effective way that we overlooked exactly what had already been done, and why. To make this
point I'd like to draw your attention to a couple of pages in the presentation I gave during the 22 Aug telecon (attached). On page 6 I pointed out the biggest motivation for this effort, that by 2013 our various working groups had already created ten (10)
separate "organizations" registries, four (4) separate "contacts" registries, and were on the way to creating two separate RF asset registries. Some of these were well formed, with carefully defined fields for names, addresses, phone numbers, etc and some
really just had rough place holders of the form "organization is a 1024 character field". Some of these existing registries, particularly the SCID registry (agencies, Agency Representatives (AR) and contact info), and the MACAO registry (agencies, Agency
Representatives (AR) and contact info), had been in existence forever (as two separate, but well formed, registries). Others were relatively new, added over time to support standards like the Conjunction Data Message (service providers and contacts), navigation
data and pointing messages (service providers and contacts), Service Management (service providers, contacts, and services), SOIS (provider organizations and contacts), and D-DOR (service providers and contacts).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">It was when two more WG proposed two new "organization" and "contact" registries that I finally took a serious look at what we had done and called a halt to "business as usual". This was the
genesis of the RMP work and the registry re-engineering that has already been done. There is now one well formed Organizations registry and one well formed Contacts registry. Every entity in these registries has well formed name, address, phone number, email,
web site fields. And every entity has a completely unique identifier that is globally unambiguous. If you know that globally unique identifier (called an OID) you can access the data for that entity. Also, each Organization and each Contact may have one
or more Roles. These Organization Roles may be "member agency", or "SM Service Provider" or "</span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:11.0pt">Conjunction Data Message Originator", or "D-DOR Service Provider". The list of Organization Roles is in a SANA registry and it may be added to. One set of Organizations, but many possible roles. The same
is true of Contacts, one set of well formed Contact information, many possible Contact Roles. For instance, all of you have the "CMC Member" role. Some of you, like Osvaldo, have multiple roles, such as "CMC Member", "WG Chair", and "SCID Assignor (AR or
OR)". <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">We designed and created these new registries, with their carefully defined fields and relationships, to make the process of managing them as efficient as possible. Instead of ten Organizations
registries we now have one. Instead of four Contacts registries we now have one. Instead of many places to go to make updates we now have one. This is efficient and cost effective. See pg 11 for the set of relationships that are built into these registries.
These designed-in relationships among the registries, and the use of globally unique identifiers (OID), also makes this efficient since navigating from one registry to another is trivial. Put the identifier for the "owning" organization into a service registry
and you get immediate access to that organization, and the contact person, when that is needed. And all of this is accessible electronically, either from the website or using a programmable interface built on the Internet standard HTTP/REST web protocol.
This is as simple as it can be and it is now very efficient.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">I'm taking the time to point this out so that we do not lose track of what is in place and has already been created. These registry structures are now completely adopted by the existing standards
and all new standards are being aligned with these registries. Older standards, such as the SCID and MACAO, have already been edited to point to these unified registries instead of the old, unique, ones they had previously defined. In this process we lost
no functionality and gained efficiency and cost effectiveness. This is fast, efficient, flexible, and very cost effective from a number of different points of view. It also moves CCSDS, and the information we provide to our users, solidly into the 21'st
century information age. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">All of that said, if the CMC decides to move these registries to the CCSDS Website I do want to point out that this is certainly possible. The CCSDS Website, maintained by the Secretariat, is
indeed the first point of contact for many users and new organizations. And the Secretariat has the responsibility for managing Agency, Observer, Associate, etc membership. No one has ever suggested otherwise, that is our policy and it ought to be maintained.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">It was suggested during the telecon that there should be a study about if and how to do this more efficiently in the future. I hope you keep in mind that we have already taken giant steps in
that direction. Along those lines, I do want to strongly recommend that when any "move it to the CCSDS Website" study is undertaken that this move be required to align with the Registry Management Policy (RMP), CCSDS 313.1-Y-1, and to utilize, wherever they
are implemented, the exact same kinds of registries and unique identifiers (OIDs) as those that are already implemented. All of this is specified in the RMP. The RMP should continue to be treated as requirements on all of the Registries that CCSDS manages,
wherever they are hosted, and on CCSDS Working Groups. The same kinds of access and sort features, and HTTP/REST interfaces, should be provided. These Organizations and Contacts registries can certainly be hosted by the Secretariat on the CCSDS.ORG website,
but I urge that we not break what has been created and is already operating well.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">I've gone on long enough. Probably longer than many of you can really countenance. This is something I am passionate about and I think it would be a real loss to CCSDS, to our member agencies,
and to our user community if we move backwards or lose ground. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">Thanks for listening. Peter<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Helvetica",sans-serif">________________________________________________________<br>
<br>
Peter Shames<br>
CCSDS Systems Engineering Area Director<br>
<br>
Jet Propulsion Laboratory, MS 301-490<br>
California Institute of Technology<br>
Pasadena, CA 91109 USA <br>
<br>
Telephone: +1 818 354-5740, Fax: +1 818 393-6871<br>
<br>
Internet: <a href="Peter.M.Shames@jpl.nasa.gov"><span style="color:blue">Peter.M.Shames@jpl.nasa.gov</span></a><br>
________________________________________________________<br>
<br>
We must recognize the strong and undeniable influence that our language exerts on our ways of thinking and, in fact, delimits the abstract space in which we can formulate - give form to - our thoughts.<br>
<br>
Niklaus Wirth</span><span lang="EN-US" style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
</body>
</html>