<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=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (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:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1799176574;
mso-list-type:hybrid;
mso-list-template-ids:2037007948 -1009344854 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-font-family:Calibri;
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D">In most I agree, especially with the idea to alter the SANA CCSDS SCID registry. Good idea.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">But still I think we may consider allowing “other not registered” S/C to use the SM-Stuff. If we do it the way I proposed or other, does not really matter.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Marcin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> John Pietras [mailto:john.pietras@gst.com]
<br>
<b>Sent:</b> Dienstag, 2. Juni 2015 16:11<br>
<b>To:</b> Gnat, Marcin<br>
<b>Cc:</b> smwg@mailman.ccsds.org; Wolfgang_._Hell@t-online.de; Colin.Haddow@esa.int<br>
<b>Subject:</b> RE: [Smwg] CSS User Registry should not be limited to Spacecraft Idenfier registry<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Marcin,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">The problem with using the SANA SCID registry for the spacecraft names for the ‘user’ parameter of the Simple Schedule is not that some missions don’t want (or are too lazy) to register their missions there,
it is that the purpose of the SANA SCID registry is to assign CCSDS Spacecraft Identifiers (those relatively small integer values that appear in the CCSDS transfer frame headers). In order to get your spacecraft into the SANA SCID registry, your spacecraft
has to use CCSDS space link protocols in the first place. NASA, for one still supports a number of missions that don’t use CCSDS space link protocols (for a variety of reasons). Those missions couldn’t register their S/C in the SCID registry if they wanted
too (the “SCID space” is too small for CCSDS to allocate them to missions that don’t actually use them). But that still doesn’t mean that the networks supporting those missions can’t use CCSDS Service Management interfaces (e.g., the Simple Schedule).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">In any case, I don’t think that your proposed solution solves the problem either. Even if some SC names were not registered with SANA, they would have to be “registered” in some way – e.g., in some form of a
service agreement (not necessarily one that conforms to the (eventual) CCSDS Service Agreement Info Entity). A SANA registry is just a convenient place to collect all of those names in a common place so that they can be used consistently and authoritatively
whenever a CCSDS standard service needs to use a spacecraft name. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">However, I agree that creating a separate SC Name registry opens up the possibility of multiple registries with inconsistent contents (some registered in one but not the other, different spellings, etc.). I think
a better solution would be to alter the SANA CCSDS SCID registry into a SANA Spacecraft Name and SCID registry that allows for the registration of SC names and *<b>optionally</b>* CCSDS SCIDs. That would create a single authoritative source for all SC names,
and if some of those also happen to use/need CCSDS SCIDs those will be there too. Or a relational database approach could be applied to those registries that work of various subsets of related date (in this case, related by spacecraft name).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">I haven’t yet read the email that Erik sent out about the new proposals for SANA registries – perhaps some of these issues will be addressed there.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Talk to you soon in the WebEx.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">John<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a> [<a href="mailto:Marcin.Gnat@dlr.de">mailto:Marcin.Gnat@dlr.de</a>]
<br>
<b>Sent:</b> Tuesday, June 02, 2015 9:38 AM<br>
<b>To:</b> John Pietras<br>
<b>Cc:</b> <a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>; <a href="mailto:Wolfgang_._Hell@t-online.de">
Wolfgang_._Hell@t-online.de</a>; <a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a><br>
<b>Subject:</b> RE: [Smwg] CSS User Registry should not be limited to Spacecraft Idenfier registry<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Hi John,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Especially in the latter case you shown, creating another registry does not necessarily help, because it still may happen that someone didn’t registered there (didn’t wanted, or being too lazy ;-)), exactly as
at S/C ID Registry the problem is. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">My simple proposal would be eventually (if we are going to change anything) to rather go for another special keyword (like “NONREGISTERED” or “OTHER”) which should be followed by in such a case obligatory extension
attribute i.e.:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">-user=”NONREGISTERED”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">–nonreguser=”Cool S/C Name which is not registered in SANA”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">In other cases than “NONREGISTERED” this attribute would be optional.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">We can than cover Non-SANA Spacecraft and we do not generate extra registries. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Marcin<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">
<a href="mailto:smwg-bounces@mailman.ccsds.org">smwg-bounces@mailman.ccsds.org</a> [<a href="mailto:smwg-bounces@mailman.ccsds.org">mailto:smwg-bounces@mailman.ccsds.org</a>]
<b>On Behalf Of </b>John Pietras<br>
<b>Sent:</b> Montag, 1. Juni 2015 20:02<br>
<b>To:</b> <a href="mailto:Colin.Haddow@esa.int">Colin.Haddow@esa.int</a><br>
<b>Cc:</b> CCSDS SMWG ML (<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>);
<a href="mailto:Wolfgang_._Hell@t-online.de">Wolfgang_._Hell@t-online.de</a><br>
<b>Subject:</b> [Smwg] CSS User Registry should not be limited to Spacecraft Idenfier registry<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Colin,<o:p></o:p></p>
<p class="MsoNormal">As currently defined in E2.3 of the Simple Schedule book, the content of the ‘user’ column CSS User Registry is confined to:<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>UNALLOCATED<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>PROVIDER-CSSS, or<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]> “any value contained in the SANA Spacecraft Identifiers Registry (<a href="http://sanaregistry.org/r/spacecraftid/spacecraftid.html">http://sanaregistry.org/r/spacecraftid/spacecraftid.html</a>) column ‘Spacecraft Name’”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">While Wolfgang and I were discussing the ‘spacecraftName’ component of the CSTS Service Instance Identifier (see the email that I sent out earlier today) this morning, Wolfgang made a point that upon further consideration raises an issue
for the Simple Schedule book. That point is that not all spacecraft that are supported by CCSDS member agencies have CCSDS-assigned SCIDs (he mentioned Russian spacecraft as an example).
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Wolfgang’s concern focused on tying the CSTS SII to the existing SANA SCID registry, but this also applies to the Simple Schedule, assuming that that we would promote the use of the Simple Schedule to report the schedules for spacecraft
that don’t have CCSDS SCIDs.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So I think that we’re going to have to loosen up the specification of the allowable contents of the ‘user’ column of the CSS User Registry.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This issue has triggered several more thoughts. As currently constructed, the CSS User Registry must be constantly updated to copy the spacecraft names from the SANA SCID registry. Ignoring for the moment the issue of some desirable SC
names not appearing in the SANA SCID registry in the first place, wouldn’t it be simpler (that is, easier to maintain) to simply specify in the definition of the Simple Schedule ‘user’ parameter that it’s allowed values are<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>UNALLOCATED<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>PROVIDER-CSSS, or<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]> “any value contained in the SANA Spacecraft Identifiers Registry (<a href="http://sanaregistry.org/r/spacecraftid/spacecraftid.html">http://sanaregistry.org/r/spacecraftid/spacecraftid.html</a>) column ‘Spacecraft Name’”<o:p></o:p></p>
<p class="MsoNormal">without creating a separate registry?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Of course, we do have the possibility of needing to register names that don’t appear in the SANA SCID registry, so we do need the some sort of registry for those names. However, by including UNALLOCATED and PROVIDER-CSSS in the CSS User
Registry, this registry is constrained to be used *<b>only</b>* for the ‘user’ parameter of the Simple Schedule. If we have another Info Entity with a parameter populated by spacecraft names but not UNALLOCATED or PROVIDER-CSSS (perhaps Service Agreement,
for example), we’d have to create another registry that copies almost all of the contents except the Simple Schedule ‘user’ parameter-specific UNALLOCATED and PROVIDER-CSSS values. An alternative approach would be to define a CSS Spacecraft Name registry that
contains only that (spacecraft names), and defines the allowed values in the Simple schedule ‘user’ parameter as:<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>UNALLOCATED<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]>PROVIDER-CSSS, or<o:p></o:p></p>
<p class="MsoListParagraph" style="text-indent:-18.0pt;mso-list:l0 level1 lfo2"><![if !supportLists]><span style="mso-list:Ignore">-<span style="font:7.0pt "Times New Roman"">
</span></span><![endif]> “any value contained in the SANA CSS Spacecraft Name Registry”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">That is, distinguish the spacecraft Name registry (which will vary over time but could be used for multiple purposes) from the Simple Schedule ‘user’ parameter-specific values.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">My apologies for raising these concerns in the 11<sup>th</sup> hour, but the need to support spacecraft that don’t use CCSDS SCIDs is an issue that does need to be addressed. The rest of the comments are observations on what might be better
ways to proceed but aren’t critical to the correctness or applicability of the Simple Schedule specification.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Best regards,<o:p></o:p></p>
<p class="MsoNormal">John<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:13.5pt;font-family:"Times New Roman","serif";color:black;background:white">
<hr size="2" width="100%" align="center">
</span></div>
<p class="MsoNormal"><span style="font-size:13.5pt;font-family:"Times New Roman","serif";color:black;background:white">NOTE: This message was trained as non-spam. If this is wrong, please correct the training as soon as possible.
<br>
<a href="https://filter.gst.com/canit/b.php?i=01OzpI007&m=0bd598c2cf8d&c=s" target="canit_note">Spam</a><br>
<a href="https://filter.gst.com/canit/b.php?i=01OzpI007&m=0bd598c2cf8d&c=n" target="canit_note">Not spam</a><br>
<a href="https://filter.gst.com/canit/b.php?i=01OzpI007&m=0bd598c2cf8d&c=f" target="canit_note">Forget previous vote</a></span><span style="font-size:12.0pt;font-family:"Times New Roman","serif""><o:p></o:p></span></p>
</div>
</div>
</body>
</html>