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

[Barkley, Erik J (3970)]

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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20150629/ea804410/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CCSDS OID Tree 25Jun15 v4.pdf
Type: application/pdf
Size: 126993 bytes
Desc: CCSDS OID Tree 25Jun15 v4.pdf
URL: <http://mailman.ccsds.org/pipermail/css-csts/attachments/20150629/ea804410/attachment.pdf>