<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)">
<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;}
@font-face
{font-family:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
@font-face
{font-family:"Apple Color Emoji";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* 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:blue;
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.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:70.85pt 70.85pt 56.7pt 70.85pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:170685677;
mso-list-template-ids:-175717026;}
@list l0:level1
{mso-level-start-at:2;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:514609540;
mso-list-type:hybrid;
mso-list-template-ids:-243102604 -1 -1 -1 -1 -1 -1 -1 -1 -1;}
@list l1:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2
{mso-list-id:543063032;
mso-list-type:hybrid;
mso-list-template-ids:-243102604 -1 -1 -1 -1 -1 -1 -1 -1 -1;}
@list l2:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l2:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l3
{mso-list-id:1230964014;
mso-list-type:hybrid;
mso-list-template-ids:-243102604 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;}
@list l4
{mso-list-id:1367173514;
mso-list-template-ids:1644083364;}
@list l4:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5
{mso-list-id:1456941925;
mso-list-type:hybrid;
mso-list-template-ids:-243102604 -1 -1 -1 -1 -1 -1 -1 -1 -1;}
@list l5:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l5:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l5:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l6
{mso-list-id:1615359527;
mso-list-type:hybrid;
mso-list-template-ids:460245014 1487451670 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l6:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Calibri",sans-serif;}
@list l6:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l6:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l6:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l7
{mso-list-id:1763451244;
mso-list-type:hybrid;
mso-list-template-ids:-243102604 -1 -1 -1 -1 -1 -1 -1 -1 -1;}
@list l7:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l7:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l7:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7: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="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif">Dear Marcin, Erik, et al,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif">Maybe I am over-reacting, but I have the feeling that all of the issues that I identified have been “pushed off the table” in the rush to get something out the door because “</span>We are already
very late with development for Blue-1”. I understand the desire to get something out on the street, and I really do not want to slow that down.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">But …<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 lfo3"><span style="font-family:"Aptos",sans-serif">Any standard that pretends to address “Service Agreements” must be doing it between a Service Provider and a Service User. These are Organizations.
And there are likely to be discrete Point of Contact (persons) who are involved. There is a SANA Organizations registry (</span><a href="https://urldefense.us/v3/__https:/sanaregistry.org/r/organizations/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54bCjLZRwQ$">https://sanaregistry.org/r/organizations/</a><span style="font-family:"Aptos",sans-serif">).
If you do not use that as the default just what ARE you going to use? If you do not use the SANA Contacts registry for the PoC (<a href="https://urldefense.us/v3/__https:/sanaregistry.org/r/contacts/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54aKUFABXA$">https://sanaregistry.org/r/contacts/</a>)
just what are you going to use? You can always allow an “override” or “fill in the blank” option, but I believe that the defaults should be these registries. In fact, the SANA docs require it.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l3 level1 lfo3"><span style="font-family:"Aptos",sans-serif">These Agreements must address, in the most narrow case, some communications between a user MOC (EUN in SCCS-ARD terms), a Ground Station
(ESLT), and a Spacecraft (SUN). There is a SANA registry for ESLT (Service Site and Apertures,
<a href="https://urldefense.us/v3/__https:/sanaregistry.org/r/service_sites_apertures/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54YyS0VoOA$">
https://sanaregistry.org/r/service_sites_apertures/</a>), and there is a SANA registry for Spacecraft and SCIDs (the only identifier that CCSDS defines for spacecraft at the link layer,
<a href="https://urldefense.us/v3/__https:/sanaregistry.org/r/spacecraft/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54aEYDzClg$">
https://sanaregistry.org/r/spacecraft/</a>, <a href="https://sanaregistry.org/r/spacecraftid/">
https://sanaregistry.org/r/spacecraftid/</a>). If you do not use the SANA SS&A registry for the ESLT and Service providers just what are you going to use? You can always allow an “override” or “fill in the blank” option, but I believe that the defaults
should be these registries. Likewise the S/C and SCID.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l3 level1 lfo3"><span style="font-family:"Aptos",sans-serif">This is really basic and it should, according to the CCSDS SANA Guidelines, CCSDS 313.2-Y-2, be the default approach for resolving all
references to such entities. It’s not that anyone in the WG is “important enough” to do it, it’s that CCSDS requires it. RTFM. Section 3.2.1 and 3.2.4 would be good places to start.<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif">As for what you guys decide to do with things like space-to-space links (which already exist), link layer relaying (which already exists in a crude form between NASA and ESA), and networking
(which is right over the horizon in LNIS) that’s up to you. Go ahead and start small, but please to keep in mind that there is going to come a time when you must extend this framework to address those topics. That light at the end of the tunnel is indeed
a freight train headed your way.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif">Yes, there is work that must be done between CSS (SM) and SIS (DTN) to get that stuff sorted out. There must be a well documented and understood relationship between the CSS link layer parts
and the SIS DTN Routing and NW Mgmt parts. One relies upon the other. SEA will surely be in the mix too, and no, it is not yet done.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif">On the issue of use of RFM to describe these spacecraft on-board environments I agree completely that this should be tackled. Each time I have asked the question I am told: 1) RFM is only for
the ground; 2) We could use it for on-board (it’s the “flip side”) but haven’t done it yet due to resource limitations; and 3) we do not have RFM for DTN. I think that has been the “party line”, and I do understand it. I also fully support using RFM for
these on-board environments, and for DTN. But you cannot really succeed in discussing this with SIS DTN until you have a nice clear picture of how it all might work that you can a) agree upon yourselves; and b) present to others.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif">I took a shot at describing how I understand that CSS RFM, SOIS EDS, and MOIMS SM&C (do not get me started on this) relate. This was discussed at CESG and I believe that there is substantial
agreement at that level. I did not tackle the SIS DTN AMA models at that time, but have done so recently. Those two analysis presentations are attached. I think that these materials can help form a starting point for discussion when you ARE ready to tackle
these issues.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif">Until then, please do just set it aside. Ok?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif">However, in my opinion, and according to CCSDS guidelines, those SANA issues really must be addressed now.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif">Thanks, Peter<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Aptos",sans-serif"><o:p> </o:p></span></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">"Marcin.Gnat@dlr.de" <Marcin.Gnat@dlr.de><br>
<b>Date: </b>Tuesday, February 6, 2024 at 2:34 AM<br>
<b>To: </b>Peter Shames <peter.m.shames@jpl.nasa.gov><br>
<b>Cc: </b>SMWG <smwg@mailman.ccsds.org>, Erik Barkley <erik.j.barkley@jpl.nasa.gov><br>
<b>Subject: </b>RE: [cssm] [EXTERNAL] CSSM: Service Agreement Parameters - Update of the presentation from Fall Meetings 2023<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;font-family:"Aptos",sans-serif"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal">Dear Peter,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regarding your points 2/3 already you got the answer from Erik. We focus right now for the simple scenario, and as soon we know what we want to do with complex, interplanetary scenarios we can extend it (i.e. for Blue-2 Version). We are
already very late with development for Blue-1 and struggling with additional complex scenarios would push us beyond any meaningful usefulness (industry and players started to develop their own things, because they did not found anything).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">To the fist one: SANA, I think most have been said already, thus I will not go into details. I do not feel I’m important enough to decide on specific SANA usage or not
<span style="font-family:"Apple Color Emoji"">😉</span>. In essence however, all of the parameters which have “String” as type, can use SANA entries (or FRM OID’s in that matter). I did not write it in my power point, but I will have it in the Blue Book in field
descriptions, saying “this value should be ideally SANA registry… blah blah… or otherwise bilaterally agreed value”. Something along this lines we have already in SSF and CPIF, CDE, etc…
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Quintessence: we did not forget all these topics, but we want a release quick, to still make it to the “market”.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Cheers<o:p></o:p></p>
<p class="MsoNormal">Marcin<o:p></o:p></p>
<p class="MsoNormal"><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> Shames, Peter M (US 312B) <peter.m.shames@jpl.nasa.gov>
<br>
<b>Sent:</b> Samstag, 20. Januar 2024 00:51<br>
<b>To:</b> Barkley, Erik J (US 3970) <erik.j.barkley@jpl.nasa.gov>; Gnat, Marcin <Marcin.Gnat@dlr.de>; smwg@mailman.ccsds.org<br>
<b>Subject:</b> Re: [cssm] [EXTERNAL] CSSM: Service Agreement Parameters - Update of the presentation from Fall Meetings 2023<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I like the idea of leveraging FRMs as part of this. And I get the issue that some of the future issues I raised are just too “future” for you to think about … just please keep them in mind.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">But no one made any mention of leveraging the existing SANA registries at all. Is that because it is just so obvious that of course you will use them, or that you (silently) rejected it?
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Curious minds want to know.<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>
<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">Erik Barkley <<a href="mailto:erik.j.barkley@jpl.nasa.gov">erik.j.barkley@jpl.nasa.gov</a>><br>
<b>Date: </b>Thursday, January 18, 2024 at 9:39 PM<br>
<b>To: </b>Peter Shames <<a href="mailto:peter.m.shames@jpl.nasa.gov">peter.m.shames@jpl.nasa.gov</a>>, "<a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a>" <<a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a>>, SMWG <<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>><br>
<b>Subject: </b>RE: [cssm] [EXTERNAL] CSSM: Service Agreement Parameters - Update of the presentation from Fall Meetings 2023<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">Dear Peter,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Okay, so we have been warned that your desk is “loaded” <span style="font-family:"Apple Color Emoji"">
😊</span>. More seriously, although the inputs are good, I think we (the CSSM WG) are still a good ways away from coming near the territory of service agreements for all of space exploration – e.g. I think there would have to be a lot of discussion first
as to what DTN network management needs to have by way of peering arrangements, etc. For now, we (CSSM WG) are just trying to gather a preliminary list of likely service agreement parameters for E2S link management. I think we can be mindful and can agree
in principle with, as you say to us, “to discuss this at more length when you are ready.” <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">On a side note we could also consider, perhaps somewhat more seriously, adoption for (additional) FRMs in SOIS, SIS, etc. This could also have a bearing on capturing service agreement parameters in other domains that you note.<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">-Erik <o:p></o:p></p>
<p class="MsoNormal"><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> SMWG <<a href="mailto:smwg-bounces@mailman.ccsds.org">smwg-bounces@mailman.ccsds.org</a>>
<b>On Behalf Of </b>Shames, Peter M (US 312B) via SMWG<br>
<b>Sent:</b> Thursday, January 18, 2024 9:45<br>
<b>To:</b> <a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a>; <a href="mailto:smwg@mailman.ccsds.org">
smwg@mailman.ccsds.org</a><br>
<b>Subject:</b> Re: [cssm] [EXTERNAL] CSSM: Service Agreement Parameters - Update of the presentation from Fall Meetings 2023<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi Marcin, et al,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It’s great that you guys have started to develop this Service Agreement framework. I think it should be of a lot of use and that what you have produced is a good start.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">That said, I have a few comments and observations that will undoubtedly come up when this standard crosses my desk as part of a CESG review. So I thought I’d toss them out now, for your consideration.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Comments<o:p></o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l7 level1 lfo9">This draft makes mention of a variety of objects for which we have existing (if somewhat incompletely filled out) SANA registries, but there is no mention of SANA anywhere. I believe
that all of the following should be referenced, and that the standard should clarify how these are to be used, extended if needed, or substituted only where it is essential to do so.
<o:p></o:p></li><ol style="margin-top:0in" start="1" type="a">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l7 level2 lfo9"><a href="https://urldefense.us/v3/__https:/sanaregistry.org/r/organizations/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54bCjLZRwQ$">https://sanaregistry.org/r/organizations/</a><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l7 level2 lfo9"><a href="https://urldefense.us/v3/__https:/sanaregistry.org/r/contacts/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54aKUFABXA$">https://sanaregistry.org/r/contacts/</a><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l7 level2 lfo9"><a href="https://urldefense.us/v3/__https:/sanaregistry.org/r/service_management_entity_types/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54bePBw39g$">https://sanaregistry.org/r/service_management_entity_types/</a><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l7 level2 lfo9"><a href="https://urldefense.us/v3/__https:/sanaregistry.org/r/service_sites_apertures/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54YyS0VoOA$">https://sanaregistry.org/r/service_sites_apertures/</a><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l7 level2 lfo9"><a href="https://urldefense.us/v3/__https:/sanaregistry.org/r/spacecraft/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54aEYDzClg$">https://sanaregistry.org/r/spacecraft/</a><o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l7 level2 lfo9"><a href="https://urldefense.us/v3/__https:/sanaregistry.org/r/spacecraftid/__;!!PvBDto6Hs4WbVuu7!J54qJVQ6uOSMg6cM_6oPzeBd9gHFGlqv3g5u8EqaMKUW21CdwumYrMxJJlVatZVHoO1AW2gubjpTTuSQ54au9Neskg$">https://sanaregistry.org/r/spacecraftid/</a><o:p></o:p></li></ol>
</ol>
<p class="MsoListParagraph" style="margin-left:1.0in"><o:p> </o:p></p>
<ol style="margin-top:0in" start="2" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l7 level1 lfo9">This seems to be exclusively focused on “standard” Earth to S/C services, but we are already in an era where there are existing “space based services”, like the Mars orbiting missions,
and the Lunar mission set, with “standardized” relay operations, is already in development. Is there a plan for addressing these other classes of missions?<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l7 level1 lfo9">Is there a plan to build in extensibility for new service types as these are developed? This might include, for instance, Lunar PNT services, DTN services, and DTN to IP “protocol
bridging”.<o:p></o:p></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’d be happy to discuss this at more length when you are ready.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks, Peter<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 <<a href="mailto:smwg-bounces@mailman.ccsds.org">smwg-bounces@mailman.ccsds.org</a>> on behalf of SMWG <<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>><br>
<b>Reply-To: </b>"<a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a>" <<a href="mailto:Marcin.Gnat@dlr.de">Marcin.Gnat@dlr.de</a>><br>
<b>Date: </b>Thursday, January 18, 2024 at 12:49 AM<br>
<b>To: </b>SMWG <<a href="mailto:smwg@mailman.ccsds.org">smwg@mailman.ccsds.org</a>><br>
<b>Subject: </b>[EXTERNAL] [cssm] CSSM: Service Agreement Parameters - Update of the presentation from Fall Meetings 2023<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><a name="Gruß"></a><span lang="DE">Dear all,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<p class="MsoNormal">I had a small task to update the collection of the Service Agreement parameters, which I presented during Fall Meetings 2023. During this presentation we had a discussion and number of comments/changes, which now I implemented. As you can
see I still have there two or so “TBCs”. Except that I think it looks good for the first schema version for SA File type. I will try to set it up until our next teleconference, but not promising it….;-)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Cheers<o:p></o:p></p>
<p class="MsoNormal">Marcin<o:p></o:p></p>
</div>
</body>
</html>