<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle26
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:226385412;
mso-list-type:hybrid;
mso-list-template-ids:1440893624 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:599527257;
mso-list-template-ids:273294450;}
@list l1:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2
{mso-list-id:1256749209;
mso-list-template-ids:-1965796630;}
@list l2:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3
{mso-list-id:1967078210;
mso-list-type:hybrid;
mso-list-template-ids:-537249640 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l3:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l3:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l3:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Dear All,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This may strike you all as strange, but I am pleased to see that you are digging into all of these related topics with an aim to bring clarity. What we tried to do in creating the set of SANA registries, specifically the Service Site &
Aperture (SS&A) and related, was to create a framework that you all (CSS area and others who are affected) could refine to meet your collective needs for capturing the necessary data and identifiers. We created unique identifiers (OIDs) for all objects nd
created fields for various names and abbreviations that we believed would be useful and aligned, as best we could tell, with the intentions of the several different Working Groups in SLS, SIS, CSS, and SEA areas.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We populated these registries with the information that we had in hand (Spacecraft SCIDs, IOAG RF assets, Orgs, Contacts, and such CSS OIDs as existed). We asked the Agencies to update their information in these registries, typically with
little actual response. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">And then we waited for you guys to figure out what you really wanted these registries to contain.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Because we (CCSDS as a whole) had originally taken the “let a thousand flowers bloom” approach to creating registries there was not a culture of consistent use of registries, names, terms, across all WG. In reality, there was not a consistent
use of these elements even within any given area, witness the plethora of identical terms in the SANA Terminology registry, in some cases, and the absence of other terms. Go to the Terms registry (<a href="https://sanaregistry.org/r/terms/">https://sanaregistry.org/r/terms/</a>)
and search for “packet” or “frame”, or “aperture”, or “antenna”. One point I am making is that we (collectively) need to clean up our act. The SANA framework is there to support this, but we collectively need to do the work.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">That includes, IMHO, getting this business of definitions (aperture, antenna, station) sorted out and getting clear about what we want as some sort of “canonical names” as well as, if it is necessary, real abbreviated names.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’ll make the following assertions, which I believe are factual (i.e. observable). Some will be judgements, i.e. things that I believe to be true which may not be. It is all up for discussion.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo5">The necessary SANA registries, Terms, Agencies, Contacts, SS&A, SCID, etc all exist (fact)<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo5">The fields in these registries are (mostly) well enough defined (judgement)<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo5">The Terms we need mostly exist (fact)<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo5">The Terms need to be cleaned up and normalized for clarity (judgment)
<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo5">Some Terms that we need are not yet defined in the SANA Terms registry (fact)<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo5">Terms registry maintenance is out of date with the current publications (judgement, but likely provable as fact by examination of the Terms and current publications)<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo5">The SS&A registry is also out of date (observable fact)<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo5">The SS&A registry contains “abbreviations” that are not always abbreviated (fact)<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo5">We do not have a rule for SS&A abbreviations, nor for canonical names, nor for “DDOR 4-character ‘STATION’ names” (fact)<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo5">We do not have definitions for aperture, antenna, and station that describe how they are related nor how they related to aperture arrays (fact)<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo5">We have a framework for authentication of users and authorization of user access, given different roles, but it is not (quite) finished, more on that in a minute.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo5">I could go on, but I hope you get the idea<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We have a framework, and more than a framework in place, but there is a lot of data update work to be done. A lot of that must be done by the WG that care about it. At this point, given accurate inputs, the SANA Operator will do the updates.
In some cases, like the FRM, there is a lot of work for you guys to do to figure out just what it is that you want to CM and how you want to do it. It’s not an easy problem given that you are essentially tracking three areas worth of standards.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">On the topic of the authorization framework, there has been progress. I spoke to Marc about this the end of last week. They have implemented it and are testing it. They elected, wisely I think, to implement a generic role / authorization
approach that can easily be extended and reused. This sounds easy, but it is not, largely because of some of the ways that we, CCSDS, have decided to use it.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Why is this complicated, you might ask? I did. Here is the answer:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l3 level1 lfo6">We have roles, Agency Representative (AR) for SCID assignment, AR for SS&A updates for some network owned by some agency.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l3 level1 lfo6">Then we have a SCID assignment AR “Charlie” who works for agency X. And then Agency Y says “we also want Charlie to be our AR”. But Charlie is not a member of Agency Y, only of
Agency X, how does that work?<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l3 level1 lfo6">And we have a SS&A AR named “Fred” for agency P, making assignments in the SS&A registry for network K. But Fred really works for a different center in Agency P, so he is a member
of P.Q, but P “owns” network K. How does that work?<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l3 level1 lfo6">So the nice clean assumption “this guy works for that agency” model breaks down in reality when agencies elect to do things differently. The SANA guys have had to implement a more
generalized framework that covers these variations, and that has taken time and involves a lot of testing.<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The good news is that this is now implemented and they think they will be done with this is a couple of weeks. The bad news is that they also, now, need to rectify this whole “SLE claimed 1.3.112.4.3 OID subtree but never filled the registry”
problem. It’s all manageable, it just takes time.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Just like making standards, I guess.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Cheers, Peter<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">SMWG <smwg-bounces@mailman.ccsds.org> on behalf of John Pietras <john.pietras@gst.com><br>
<b>Date: </b>Wednesday, May 12, 2021 at 7:36 AM<br>
<b>To: </b>SMWG <smwg@mailman.ccsds.org><br>
<b>Subject: </b>[EXTERNAL] [cssm] FW: D-DOR FRM definition<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> John Pietras <br>
<b>Sent:</b> Tuesday, April 27, 2021 6:29 PM<br>
<b>To:</b> SMWG <smwg-bounces@mailman.ccsds.org><br>
<b>Subject:</b> D-DOR FRM definition<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">CSSMWG colleagues ---</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Attached is the FRM HTML DOCX file that contains the “approved” Tier-1 FRM definitions and the draft Tier-2 FRM definitions. The Tier-2 definitions include the DdorRawDataCollection FR. On the first page, the
link can be found on the Physical Channel: Delta-DOR Raw Data Collection line. This FR performs the reception of the radio waveform through the generation of the D-DOR Raw Data file.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">As I said in today’s WG meeting, I have not yet reviewed this FR definition. However, Wolfgang has told me that he organized it around the information that appears in the Delta Raw Data Files that the FR produces.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">As with all of the FRs, the parameters that are proposed as configuration parameters have the Configured attribute set to ‘true’.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">NOTE – there are some issues with the limits and data types used by the D-DOR file format with respect to the data that’s available in the SANA Service Sites and Apertures registry. Ideally, the D-DOR files would
be able to use those SANA values directly. The email below summarizes the issues that Wolfgang and I uncovered regarding this.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Best regards,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">John</span><o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"> </span><o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Wolfgang Hell [<a href="mailto:wo_._he@t-online.de">mailto:wo_._he@t-online.de</a>]
<br>
<b>Sent:</b> Friday, March 5, 2021 9:55 AM<br>
<b>To:</b> John Pietras <<a href="mailto:john.pietras@gst.com">john.pietras@gst.com</a>>; Shames, Peter M (313B) (<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>) <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>>;
Border, James S (335D) (<a href="mailto:james.s.border@jpl.nasa.gov">james.s.border@jpl.nasa.gov</a>) <<a href="mailto:james.s.border@jpl.nasa.gov">james.s.border@jpl.nasa.gov</a>><br>
<b>Cc:</b> <a href="mailto:Erik.J.Barkley@jpl.nasa.gov">Erik.J.Barkley@jpl.nasa.gov</a>;
<a href="mailto:Holger.Dreihahn@esa.int">Holger.Dreihahn@esa.int</a>; Pham, Timothy T (3300) (<a href="mailto:timothy.t.pham@jpl.nasa.gov">timothy.t.pham@jpl.nasa.gov</a>) <<a href="mailto:timothy.t.pham@jpl.nasa.gov">timothy.t.pham@jpl.nasa.gov</a>><br>
<b>Subject:</b> Re: SANA Service Sites and Aperture registry and Delta-DOR raw data files<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"> <o:p></o:p></p>
<p>Dear John, Peter, and Jim,<o:p></o:p></p>
<p>This is to thank John for his concise description of the issues that we have uncovered. In addition to what he has addressed in his email below, I would like to mention that CCSDS 506.1-B-1 needs to identify the observed objects which are either a spacecraft
or a quasar. For the spacecraft ID we have the same constraint as for the station ID (four ASCII characters) and as a consequence the pertinent SANA registry cannot be used as source for this ID. If an update of CCSDS 506.1 is envisaged, this issue could be
resolved on that occasion as well as the station ID problem.<o:p></o:p></p>
<p>The quasar IDs are those of the JPL maintained quasar catalog and as far as I can tell any agency acquiring DDOR raw data is using that catalog. In other words for that point we do not have a problem in CCSDS 506.1, but I'm wondering if it would not be better
(if acceptable to JPL) to have this catalog under the auspices of a standardization body such as CCSDS for instance by converting this catalog to a SANA registry.<o:p></o:p></p>
<p>Best regards,<o:p></o:p></p>
<p>Wolfgang <o:p></o:p></p>
<div>
<p class="MsoNormal">Am 04.03.2021 um 16:41 schrieb John Pietras:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span style="font-size:12.0pt">Peter and Jim,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">As a consequence of Wolfgang Hell’s development of the definition of the functional resource representing the reception and processing of D-DOR data into raw data files, Wolfgang and I have uncovered several
issues regarding the SANA Service Sites and Apertures (SS&A) registry, some of which relate to information in D-DOR raw data file headers.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Let’s start with the D-DOR-specific issues first. CCSDS 506.1-B-1 stipulates (a) that the Observation Header of the Observation File contains two “STATION” (transmit and receive), each of which contains ”4
ASCII characters”, and (b) the Header of the Product File contains a 16-bit unsigned integer “STATION ID” field. Currently, it appears that the values that are used to populate these fields are bilaterally agreed, although the SANA Considerations paragraph
(B2) states “Conventions for Spacecraft and Station IDs may be collected in a future SANA registry.”</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">The SANA SS&A would seem to be the logical registry to cover the “Station ID” aspects. Currently the SANA SS&A registry specifies/registers:</span><o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo2"><span style="font-size:12.0pt">A “Name” for each site. These names are geographical in nature, e.g., the name of the (closest) town, or the island on which the site resides. These
names *<b>are not unique</b>* - e.g., there are 3 sites name “Kiruna” – one each owned by CNES,ESA, and JAXA;</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo2"><span style="font-size:12.0pt">An “Abbreviation” for the Name. As currently used in the SS&A registry, these really aren’t abbreviations at all – most are longer than the corresponding
name. But they *<b>are</b>* unique. For the 3 sites named Kiruna, CNES site has the abbreviation “Kiruna”, ESA has “Kiruna0”, and JAXA has “Kiruna01”. So rather than “Abbreviation” this attribute would more properly be called something like “Distinguished
Name” or “Globally-Unique Name”;</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo2"><span style="font-size:12.0pt">An Object Identifier (OID) for the site under the CCSDS Service Sites and Apertures node (1.3.112.4.9). The “label” for the OID is the so-called “abbreviation”
for the site name. E.g., for the JAXA Kiruna site named “Kiruna”, the abbreviation “Kiruna01” is the label for the OID for the JAXA Kiruna site;</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l1 level1 lfo2"><span style="font-size:12.0pt">Under each site, one or more apertures, each of which has<br>
1) A name<br>
2) A so-called Abbreviation<br>
3) An OID. As with the site-level OIDs, the labels for the OIDs are the Abbreviations.
</span><o:p></o:p></li></ol>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Now back to CCSDS 506.1-B-1. “Station” is not defined, but from the context of the example in Annex E, where two STATION fields are populated with “DS24” and “DS25”, I interpret “station” to most closely
map to “aperture”. From the current contents of the SS&A registry, it’s clear that many of the aperture names/abbreviations are not strictly 4 characters: some are 3, and many are more than 4. So “out of the box” the aperture names/apertures can’t be used
directly in the Observation Header. One could consider changing the STATION fields in the Observation Header to be longer or variable length, but perhaps the simpler approach would be to add an (optional) attribute for those apertures that are used to support
D-DOR operations. Similarly, an unsigned integer Station ID attribute could be added to register the values used in the Headers of the Product Files.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">CCSDS 506.1-B-1 was published in 2013, and there is no indication on ccsds.org that it has been certified beyond its nominal 5-year “freshness” date. Before the book is updated or re-affirmed, the discrepancies
between it and the SANA SS&A registry should be resolved so that that registry can be cited in the blue book (at least for matters concerning Station IDs).</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">The remainder of my comments on the SS&A registry are more general. As background, my plunge into this registry was motivated by the need to conform the presence of OIDs for the sites and apertures. CSS Area
products, and CSTS products in particular, make use of the OIDs to identify these entities. I found that finding these OIDs wasn’t as straightforward as I might have hoped.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">When one goes to the Service Sites and Apertures registry page, one sees</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><img border="0" width="1326" height="497" style="width:13.8125in;height:5.177in" id="Picture_x0020_1" src="cid:image001.png@01D74B3D.73B6FF60"></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">What I did initially was scroll down the list of sites to find the ESA site with the name “Kiruna”*, and hit the Details button. That resulted in multiple pages of data (includingthe OID for ESA), but no OIDs
for the site itself or its aperture(s.) </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">However, if one clicks on the OID Tree at the top of the page, one *<b>does</b>* get the site and aperture OIDs:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><img border="0" width="878" height="557" style="width:9.1458in;height:5.802in" id="Picture_x0020_2" src="cid:image002.png@01D74B3D.73B6FF60"></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">To get the “right” Kiruna (in this case, the ESA Kiruna), one has to use the “abbreviation” (which, as noted above, therefore should be more properly called something like “distinguished name”) to know which
site one is looking for. Of course, none of this is explained anywhere. </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">I think that for completeness the site and aperture OIDs should also be displayed in the Details for each site.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Finally,on the left side of each site entry in the main table is an arrow. If you click on that arrow you get another listing:</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><img border="0" width="1327" height="652" style="width:13.8229in;height:6.7916in" id="Picture_x0020_3" src="cid:image003.png@01D74B3D.73B6FF60"></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><img border="0" width="1341" height="463" style="width:13.9687in;height:4.8229in" id="Picture_x0020_4" src="cid:image004.png@01D74B3D.73B6FF60"></span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">In this case, “Kiruna” is identified as/associated with a city. But If I look at the Wallops Island “arrow”, it doesn’t give a city but just a State/region (VA), even though it also has a “City “ listing under
the “Details” view. The logic of why different things are displayed for different sites in the “arrow” view are not at all obvious.
</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">In summary, I would suggest that:</span><o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo4"><span style="font-size:12.0pt">The Station identifiers that are used in the D-DOR raw data files be accommodated by the SS&A registry, either by changing the D-DOR raw data file blue
book to use registry names and identifiers or by adding the D-DOR identifier to the SS&A registry as optional atrtributes;</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo4"><span style="font-size:12.0pt">The Details view should also display the site and aperture OIDs; and</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l2 level1 lfo4"><span style="font-size:12.0pt">The title “Abbreviation” be replaced with something that more accurately describes the contents, like “distinguished name” or “globally-unique name”,
and that they be more reader-friendly (e.g., “Kiruna_ESA”, Kiruna_CNES”, and “Kiruna-JAXA”).</span><o:p></o:p></li></ol>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Best regards,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">John</span><o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
</blockquote>
</div>
</body>
</html>