[Css-csts] Re: FW: Some apparent peculiarities in CSS OIDs

Thu Jul 2 13:58:10 UTC 2015

Dear Erik  and Peter,

the points raised by Peter  are valid, but I'd like to stress that what is 
presently in SANA w.r.t.  OIDs is still in a draft state

I recap   the steps undertaken so far : the OIDs   were given by the CSTS 
WG to the SANA engineer (Blanchet) already a couple of years ago with the 
aim of making an initial attempt of registration. At that time  the 
discussion was more on the "shape" of the registry,  while the 
completeness  of the content was (supposed)  to  be re-assessed . By 
"shape"'  I mean that we did want to have the tree structure of OIDs 
clearly visible in the Registry. Initially this was not achieved, but 
later the content of the Registry has been re-structured, and  the tree 
structure is  visible now.
Both branches ( SLE and CSTS) will be completely re-assessed as soon as we 
are finished with the CSTS Framework.  In particular, concerning the CSTS 
branch, this has changed to a certain extent in the new version of the 
Book, and consequently also the OIDs are affected.

Also, we decided to come up with a breakdown between OIDs for CSTS 
framework/services, and the published identifiers for Functional Resources 
and related elements ( parameters , events, directives). For the latter, 
it has been foreseen to associate to each OID all the related information, 
in a table-like structure.
The prototype for of "OIDs table"  for Functional 
Resources/Parameters/Events can be found at :
 http://beta.sanaregistry.org/r/oid_v2/oid_v2
(this is also in draft form and needs to by updated - more fields will be 
added).

Once the  CSTS WG (or  CSS Area) has completed all the updates , we  will 
inform Peter . At that time, a thorough review can be done. 
Kind regards
Margherita

-------------------------------------------------------------
Margherita di Giulio
Ground Station Back-end Section (HSO-GIB)
European Space Agency ESA/ESOC
Robert-Bosch-Str. 5
D-64293 Darmstadt - Germany
Tel: +49-6151-902779
e-mail: Margherita.di.Giulio at esa.int

From:   "Barkley, Erik J (3970)" <erik.j.barkley at jpl.nasa.gov>
To:     Margherita di Giulio/esoc/ESA <Margherita.di.Giulio at esa.int>, 
Cc:     "css-csts at mailman.ccsds.org" <css-csts at mailman.ccsds.org>
Date:   29/06/2015 23:40
Subject:        FW: Some apparent peculiarities in CSS OIDs

Dear Margherita,

As part of the revision of the SANA registries being led by the SE Area, 
some questions with regard to the current OID numbers for CSTS and SLE 
have been raised.   Perhaps you or other members of the CSTS WG can 
provide some insight as to the questions listed below?  The more general 
question of using the OIDs in registry identification is something that I 
think will have to be worked at an area level is not really at  CESG 
and/or ?expert group? level.  So, for the moment, the question is really 
just for the SLE and CSTS branches as indicated below.

Best regards,
-Erik

. 

From: Shames, Peter M (312B) 
Sent: Monday, June 29, 2015 8:29 AM
To: Barkley, Erik J (3970)
Cc: John Pietras; colin.haddow at esa.int
Subject: Some apparent peculiarities in CSS OIDs

Hi Erik,

As you know I've been digging into (and extending) the CCSDS OID 
definitions to see if there is a set that hangs together in a global 
sense.  I updated the attached v4 OID tree to show the OID definitions for 
SLE and CSTS that I found in the SANA.  In doing that I uncovered what I 
think are some anomalies.  They show up in the MindMap:

SLE (3) branch
there is a 3.1.1 RAF branch that contains a version, common modules and 
the, strangely, FSP (3.1.1.24)
There is a 3.1.2 branch that has no name on it (NULL), which itself 
contains 3.1.2.7 CLTU, 3.1.2.22 RAF, etc
I do not understand why fsp shows up in the 3.1.1 RAF sub-tree
I do not understand why raf shows up in 3.1.1 and 3.1.2
I do not understand why 3.1.2 is NULL, with other services in its 
sub-trees instead of these services, which are peers to RAF, appearing in 
3.1.3, 3.1.4, etc
CSTS (4) branch
I researched both the published and beta registries, it appears that 4.2 
Services (published) has been replaced by 4.2 Cross Support Resources. 
(beta), is that correct?
Under 4.2.1 Cross Support Functionalities there is then a set of sub-trees 
for antenna, fwd space link carrier, etc.
Within each of those lower level elements there is a set of even lower 
level parameters, but these get very peculiar numbering because, instead 
of having the antenna (4.2.1.1) production-status identified as 4.2.1.1.1, 
it is labelled 4.2.1.1.1.1.1.  There appear to be two extraneous "1" added 
to the OID.
This is the case for all of these lowest level parameters in this 
sub-tree.  Is there a reason for this or is it a source or transcription 
error?
I'll have some separate discussion about how the various databases and 
these OIDs relate.  I showed some of these sorts of relationships in the 
Person and Organization database sketches.  I think we need to do the same 
for the Service & Site databases and the relationships to these SLE and 
CSTS OIDs, the Service and Site OIDs, and the CSSM. 

I do not know if you guys have tried to sketch any of this out already. If 
you have I'd like to just use it instead of trying to re-invent it.  If 
you do not have these sorts of maps then I think we would all benefit from 
having them to reference.  Do you agree?

Thanks, Peter

 [attachment "CCSDS OID Tree 25Jun15 v4.pdf" deleted by Margherita di 
Giulio/esoc/ESA] 

This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20150702/0fa6d3c5/attachment.html>