[CESG] [EXTERNAL] OID repository: Updated

[Marc Blanchet]

On 15 Sep 2020, at 12:56, 'Shames, Peter M (US 312B)' via Engineering 
wrote:

> Dear SANA, et al,
>
> A recent question came up relating to the use of the ISO Object 
> Identifiers (OID) that we have built into the SANA revisions.  The 
> question was related to the use of SCIDs as a unique identifier for 
> spacecraft.  Since SCIDs are not unique (and never were) my suggestion 
> was that the ISO OIDs that we assigned to spacecraft when they request 
> SCIDs should be used.  These are truly globally unique identifiers and 
> persist once assigned.  They can also be assigned by the SANA even if 
> a SCID is not requested.  How wide this use will be remains to be 
> seen, but that is a separate topic.
>
> When I went looking for an Internet link to the OIDs that we have 
> defined I realized that while CCSDS has an OID assigned [1.3.112.4], 
> and that could be looked up in an on-line OID registry 
> (http://oid-info.com), there was no connection from this CCSDS OID 
> entry to the SANA registries where these detailed CCSDS OIDs were 
> documented.  This was a gap and expecting users to navigate from this 
> OID registry, to the CCSDS website, to the SANA, seemed to be too much 
> to expect.
>
> Yesterday I reached out to this OID registry and asked if they could 
> remedy this.  They have done that, and in spades.  They not only 
> updated the CCSDS registry entry, and added a link to the SANA 
> registries, but they also included references to the SANA Yellow Books 
> that document the registries.  I have attached a snapshot of the 
> current entry in their oid-info.com registry and also one of the SANA 
> page that their link now takes the user to.
>
> As you can see from their reply, we have control over this information 
> and could, if we wished, send them the whole set of OIDs.  We could do 
> this, or we could just send them the top level decomposition, and use 
> that as a driver of users to our site, which is the authoritative 
> source.  I see no benefit is sending them the whole OID set,

yes. given that our OIDs are generated automatically and often, it makes 
no sense to regularly copy the whole tree to them.

> but do see a potential benefit in sending them the first level decomp, 
> which is the names of the sets: organizations, contacts, spacecraft, 
> SLE, CSS, S/C, Service Site & Aperture, etc.  See CCSDS OID 
> screenshot.

the problem here is that we will still need to send them new versions 
whenever a new first level is added. I think manual duplication like 
that is just a recipe for failure. If there was a distributed resolution 
system (like the DNS), then we would not need to do copies and 
everything will be connected. Hence, I suggest we just have the entry of 
our root into their tree.

To me, what you just did with them is very good and enough: have them 
point to the root of our tree and let us handle the sub-tree.

my 2 cents,

Marc.

>
> Wanted you all to be aware of this and to have an opportunity to 
> review, comment, and request changes if any appear to be needed.
>
> And BTW, there are also some Wikipedia web pages for OID that I intend 
> to update as well.  Might as well get some added visibility for this.  
> It is public and it is, or could be, of value to others.
>
> Cheers, Peter
>
>
> From: "olivier.dubuisson at orange.com" <olivier.dubuisson at orange.com>
> Organization: Orange
> Date: Tuesday, September 15, 2020 at 1:36 AM
> To: Peter Shames <peter.m.shames at jpl.nasa.gov>
> Subject: [EXTERNAL] Re: OID repository: Question from a user
>
> Hi,
>
> I've updated the description of your OID at 
> http://oid-info.com/get/1.3.112.4<https://urldefense.us/v3/__http:/oid-info.com/get/1.3.112.4__;!!PvBDto6Hs4WbVuu7!a9ORvqdJWwag-cdrWvdRHi4QIUshrQVCXBivv_myv3nY9x6gxxmZ48zT0szYylQTlSAF6Qfk$>
> You can Modify this 
> OID<https://urldefense.us/v3/__http:/www.oid-info.com/cgi-bin/manage?oid=1.3.112.4&a=modify__;!!PvBDto6Hs4WbVuu7!a9ORvqdJWwag-cdrWvdRHi4QIUshrQVCXBivv_myv3nY9x6gxxmZ48zT0szYylQTlatOpQTN$> 
> at any time.
>
> We don't have a resolution system per se which could be interconnected 
> with other resolution systems. But you can submit a large set of OIDs 
> in an XML file as explained at 
> http://www.oid-info.com/submit.htm<https://urldefense.us/v3/__http:/www.oid-info.com/submit.htm__;!!PvBDto6Hs4WbVuu7!a9ORvqdJWwag-cdrWvdRHi4QIUshrQVCXBivv_myv3nY9x6gxxmZ48zT0szYylQTlSAEbDrX$>
> but we'll implement a tool that will automatically add your OIDs to 
> our OID repository with a hyperlink to their description in the SANA 
> registry. (If you have any issue with this, please reply quickly :-) )
>
> Thanks,
> OID repository admin
>
> On 14/09/2020 23:55, Shames, Peter M (US 312B) wrote:
> Dear OID Admin,
>
> I represent an organization, CCSDS, ISO OID [1.3.112.4].  We, have an 
> on-line registry called the Space Assigned Numbers Authority (SANA), 
> https://sanaragistry.org<https://urldefense.us/v3/__https:/sanaragistry.org__;!!PvBDto6Hs4WbVuu7!a9ORvqdJWwag-cdrWvdRHi4QIUshrQVCXBivv_myv3nY9x6gxxmZ48zT0szYylQTla2BgFLI$>, 
> that will accept all CCSDS full OIDs and resolve them to their proper, 
> lower level,  entries.
>
> How can we connect our registry, which has the ability to do fully 
> qualified OID resolution, to this tool?   Can we at least put a URL 
> link to the SANA in the CCSDS "Description" field that shows up on 
> your pages?  Or is there some other a way to reference this on-line 
> registry?
>
> Thanks, Peter Shames
>
>
> ________________________________________________________
>
> 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
> ________________________________________________________
>
>
> _________________________________________________________________________________________________________________________
>
>
>
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez 
> recu ce message par erreur, veuillez le signaler
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
>
> Orange decline toute responsabilite si ce message a ete altere, 
> deforme ou falsifie. Merci.
>
>
>
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;
>
> they should not be distributed, used or copied without authorisation.
>
> If you have received this email in error, please notify the sender and 
> delete this message and its attachments.
>
> As emails may be altered, Orange is not liable for messages that have 
> been modified, changed or falsified.
>
> Thank you.