[CMC] Comments on SANA Discussion, 17 Sept 2018

Thu Sep 20 09:53:05 UTC 2018

Thank you for the very good summary Peter
Best Regards
Osvaldo

Von: CMC [mailto:cmc-bounces at mailman.ccsds.org] Im Auftrag von Shames, Peter M (312B)
Gesendet: Dienstag, 18. September 2018 23:23
An: CMC
Cc: SANA Steering Group (SSG)
Betreff: [CMC] Comments on SANA Discussion, 17 Sept 2018
Wichtigkeit: Hoch

Dear CMC,

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.

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.

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).

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 " 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)".

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.

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.

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.

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.

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.

Thanks for listening.  Peter

________________________________________________________

Peter Shames
CCSDS Systems Engineering Area Director

Jet Propulsion Laboratory, MS 301-490
California Institute of Technology
Pasadena, CA 91109 USA

Telephone: +1 818 354-5740,  Fax: +1 818 393-6871

Internet:  Peter.M.Shames at jpl.nasa.gov
________________________________________________________

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.

Niklaus Wirth

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cmc/attachments/20180920/5744935e/attachment.html>