[CESG] [EXTERNAL] OID repository: Updated

Marc Blanchet info at sanaregistry.org
Tue Sep 15 18:28:52 UTC 2020

On 15 Sep 2020, at 14:25, 'Shames, Peter M (US 312B)' via Engineering 

> Hi Marc,
> Thanks for that feedback and glad that you think this is a good 
> outcome.   I was pleased and surprised by how quickly  and adroitly 
> they responded.
> Marc, I would be content to leave it as it is, with just a top level 
> pointer to SANA, for all the reasons you identified.  What I really 
> had in mind with that "first level OID" comment was just to ask them 
> to insert a list of a few items, like the ones I identified.  It did 
> not even need to include the OID pointers, just the names, as a sort 
> of "teaser" as to what would be found on the SANA end of the URL.

oh I see. essentially some documentation. I’m fine with that.


> We do not need to do that, but it would provide some motivation.
> Does anyone else on this email chain have any other opinions or 
> feedback?
> Thanks, Peter
> From: Marc Blanchet <info at sanaregistry.org>
> Date: Tuesday, September 15, 2020 at 10:20 AM
> To: Peter Shames <peter.m.shames at jpl.nasa.gov>
> Cc: "SANA Steering Group (SSG)" <ssg at mailman.ccsds.org>, CCSDS 
> Engineering Steering Group - CESG Exec <cesg at mailman.ccsds.org>
> Subject: Re: [EXTERNAL] OID repository: Updated
> 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 [],
> and that could be looked up in an on-line OID registry
> (https://urldefense.us/v3/__http://oid-info.com__;!!PvBDto6Hs4WbVuu7!cuBI_mBF0B9Y8UF5gp3N2lKCCahRYAUWZfTVZQsgf9ACgpqs2HL-cDU7PTvAFF9DpTOjAfOS$<https://urldefense.us/v3/__http:/oid-info.com__;!!PvBDto6Hs4WbVuu7!cuBI_mBF0B9Y8UF5gp3N2lKCCahRYAUWZfTVZQsgf9ACgpqs2HL-cDU7PTvAFF9DpTOjAfOS$> 
> ), 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<mailto:olivier.dubuisson at orange.com>" 
> <olivier.dubuisson at orange.com<mailto: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<mailto: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
> https://urldefense.us/v3/__http://oid-info.com/get/;!!PvBDto6Hs4WbVuu7!cuBI_mBF0B9Y8UF5gp3N2lKCCahRYAUWZfTVZQsgf9ACgpqs2HL-cDU7PTvAFF9DpfVhQPQ1$<https://urldefense.us/v3/__http:/oid-info.com/get/;!!PvBDto6Hs4WbVuu7!cuBI_mBF0B9Y8UF5gp3N2lKCCahRYAUWZfTVZQsgf9ACgpqs2HL-cDU7PTvAFF9DpfVhQPQ1$> 
> <https://urldefense.us/v3/__http:/oid-info.com/get/;!!PvBDto6Hs4WbVuu7!a9ORvqdJWwag-cdrWvdRHi4QIUshrQVCXBivv_myv3nY9x6gxxmZ48zT0szYylQTlSAF6Qfk$>
> You can Modify this
> OID<https://urldefense.us/v3/__http:/www.oid-info.com/cgi-bin/manage?oid=;!!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
> https://urldefense.us/v3/__http://www.oid-info.com/submit.htm__;!!PvBDto6Hs4WbVuu7!cuBI_mBF0B9Y8UF5gp3N2lKCCahRYAUWZfTVZQsgf9ACgpqs2HL-cDU7PTvAFF9DpWd0HoGy$<https://urldefense.us/v3/__http:/www.oid-info.com/submit.htm__;!!PvBDto6Hs4WbVuu7!cuBI_mBF0B9Y8UF5gp3N2lKCCahRYAUWZfTVZQsgf9ACgpqs2HL-cDU7PTvAFF9DpWd0HoGy$> 
> <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 [].  We, have an
> on-line registry called the Space Assigned Numbers Authority (SANA),
> https://urldefense.us/v3/__https://sanaragistry.org__;!!PvBDto6Hs4WbVuu7!cuBI_mBF0B9Y8UF5gp3N2lKCCahRYAUWZfTVZQsgf9ACgpqs2HL-cDU7PTvAFF9Dpa6z3mjL$<https://urldefense.us/v3/__https:/sanaragistry.org__;!!PvBDto6Hs4WbVuu7!cuBI_mBF0B9Y8UF5gp3N2lKCCahRYAUWZfTVZQsgf9ACgpqs2HL-cDU7PTvAFF9Dpa6z3mjL$> 
> <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<mailto: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.

More information about the CESG mailing list