<font size=2 face="sans-serif">Dear Erik and Peter,</font>
<br>
<br><font size=2 face="sans-serif">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</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br><font size=2 face="sans-serif">The prototype for of "OIDs table"
for Functional Resources/Parameters/Events can be found at :</font>
<br><a href=http://beta.sanaregistry.org/r/oid_v2/oid_v2><font size=3 color=blue face="Arial"><u> http://beta.sanaregistry.org/r/oid_v2/oid_v2</u></font></a>
<br><font size=2 face="sans-serif">(this is also in draft form and needs
to by updated - more fields will be added).</font>
<br>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br><font size=2 face="sans-serif">Kind regards<br>
Margherita</font>
<br>
<br><font size=2 face="sans-serif">-------------------------------------------------------------<br>
Margherita di Giulio<br>
Ground Station Back-end Section (HSO-GIB)<br>
European Space Agency ESA/ESOC<br>
Robert-Bosch-Str. 5<br>
D-64293 Darmstadt - Germany<br>
Tel: +49-6151-902779<br>
e-mail: Margherita.di.Giulio@esa.int<br>
<br>
</font>
<br>
<br>
<br>
<br><font size=1 color=#5f5f5f face="sans-serif">From:
</font><font size=1 face="sans-serif">"Barkley, Erik
J (3970)" <erik.j.barkley@jpl.nasa.gov></font>
<br><font size=1 color=#5f5f5f face="sans-serif">To:
</font><font size=1 face="sans-serif">Margherita di Giulio/esoc/ESA
<Margherita.di.Giulio@esa.int>, </font>
<br><font size=1 color=#5f5f5f face="sans-serif">Cc:
</font><font size=1 face="sans-serif">"css-csts@mailman.ccsds.org"
<css-csts@mailman.ccsds.org></font>
<br><font size=1 color=#5f5f5f face="sans-serif">Date:
</font><font size=1 face="sans-serif">29/06/2015 23:40</font>
<br><font size=1 color=#5f5f5f face="sans-serif">Subject:
</font><font size=1 face="sans-serif">FW: Some apparent
peculiarities in CSS OIDs</font>
<br>
<hr noshade>
<br>
<br>
<br><font size=2 color=#004080 face="Calibri">Dear Margherita,</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">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.</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">Best regards,</font>
<br><font size=2 color=#004080 face="Calibri">-Erik</font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 color=#004080 face="Calibri">. </font>
<br><font size=2 color=#004080 face="Calibri"> </font>
<br><font size=2 face="Calibri"><b>From:</b> Shames, Peter M (312B) <b><br>
Sent:</b> Monday, June 29, 2015 8:29 AM<b><br>
To:</b> Barkley, Erik J (3970)<b><br>
Cc:</b> John Pietras; colin.haddow@esa.int<b><br>
Subject:</b> Some apparent peculiarities in CSS OIDs</font>
<br><font size=3 face="Times New Roman"> </font>
<br><font size=2 face="Calibri">Hi Erik,</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">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:</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">SLE (3) branch</font>
<ul>
<li><font size=2 face="Calibri">there is a 3.1.1 RAF branch that contains
a version, common modules and the, strangely, FSP (3.1.1.24)</font>
<li><font size=2 face="Calibri">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</font>
<li><font size=2 face="Calibri">I do not understand why fsp shows up in
the 3.1.1 RAF sub-tree</font>
<li><font size=2 face="Calibri">I do not understand why raf shows up in
3.1.1 and 3.1.2</font>
<li><font size=2 face="Calibri">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</font></ul><font size=2 face="Calibri">CSTS
(4) branch</font>
<ul>
<li><font size=2 face="Calibri">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?</font>
<li><font size=2 face="Calibri">Under 4.2.1 Cross Support Functionalities
there is then a set of sub-trees for antenna, fwd space link carrier, etc.</font>
<li><font size=2 face="Calibri">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.</font>
<li><font size=2 face="Calibri">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?</font></ul><font size=2 face="Calibri">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. </font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">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?</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri">Thanks, Peter</font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri"> </font>
<br><font size=2 face="Calibri"> [attachment "CCSDS OID Tree
25Jun15 v4.pdf" deleted by Margherita di Giulio/esoc/ESA] </font>
<br><PRE>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.
</PRE>