<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 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;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
        {font-family:Georgia;
        panose-1:2 4 5 2 5 4 5 2 3 3;}
/* 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
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
tt
        {mso-style-priority:99;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle22
        {mso-style-type:personal;
        font-family:"Georgia",serif;
        color:windowtext;}
span.EmailStyle23
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.EmailStyle24
        {mso-style-type:personal;
        font-family:"Georgia",serif;
        color:windowtext;}
span.EmailStyle25
        {mso-style-type:personal;
        font-family:"Georgia",serif;
        color:windowtext;}
span.EmailStyle26
        {mso-style-type:personal;
        font-family:"Calibri",sans-serif;
        color:#1F497D;}
span.EmailStyle27
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.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;}
--></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-GB" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US">Hello Erik,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US">I think Martin’s correction in the meantime would suggest that a better analogy for the pass-specific SICF would be having your “mother ship” email you a new login token every day.
 By itself, that would not be a great replacement for your VPN.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US">Anthony<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Barkley, Erik J (US 3970) <erik.j.barkley@jpl.nasa.gov>
<br>
<b>Sent:</b> 18 February 2021 00:32<br>
<b>To:</b> Anthony Crowson <anthony.crowson@telespazio.de>; EXTERNAL-Unal, Martin P (9110-Affiliate) <Martin.Unal@esa.int><br>
<b>Cc:</b> SMWG <smwg-bounces@mailman.ccsds.org>; smwg@mailman.ccsds.org<br>
<b>Subject:</b> RE: [cssm] [EXTERNAL] Re: SACP: configuration of tranfer services<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Georgia",serif">Hello Anthony,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Georgia",serif"><br>
I think your comments are essentially correct.  To continue the analogy a bit, whenever I connect to the “mother ship” via VPN I do have to use multi-factor authentication which includes information that changes frequently.  This seems akin to pass specific
 SICF.  Having said that, I will be the first to admit there are probably other approaches that should be considered above and beyond permanent vs pass-specific SCIFs (or what becomes part of the SPDF?)
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Georgia",serif">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Georgia",serif">-Erik
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Georgia",serif"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Anthony Crowson <</span><a href="mailto:anthony.crowson@telespazio.de"><span lang="EN-US">anthony.crowson@telespazio.de</span></a><span lang="EN-US">>
<br>
<b>Sent:</b> Tuesday, February 16, 2021 8:53<br>
<b>To:</b> Barkley, Erik J (US 3970) <</span><a href="mailto:erik.j.barkley@jpl.nasa.gov"><span lang="EN-US">erik.j.barkley@jpl.nasa.gov</span></a><span lang="EN-US">>; EXTERNAL-Unal, Martin P (9110-Affiliate) <</span><a href="mailto:Martin.Unal@esa.int"><span lang="EN-US">Martin.Unal@esa.int</span></a><span lang="EN-US">><br>
<b>Cc:</b> SMWG <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span lang="EN-US">smwg-bounces@mailman.ccsds.org</span></a><span lang="EN-US">>;
</span><a href="mailto:smwg@mailman.ccsds.org"><span lang="EN-US">smwg@mailman.ccsds.org</span></a><span lang="EN-US"><br>
<b>Subject:</b> RE: [cssm] [EXTERNAL] Re: SACP: configuration of tranfer services<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">At the risk of wading in to a sensitive area, it seems to me that the expected advantage of a pass specific SICF over a permanent SICF is pass-specific credentials. If the credentials are accidentally exposed,
 there is a much smaller window in which they could be misused.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">However, having even one pass hijacked could in the worst case lead to loss of a mission.<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">If I’m already wrong at this state, please correct me gently and ignore the rest…<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><br>
There is an, admittedly imperfect, analogy to the prevalent but outdated practice of insisting that passwords are changed every few months. If a password is exposed to a malicious actor, it will almost certainly be used before a change is forced. Approaches
 such as two-factor authentication are much more useful.<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">Now the SLE IP, as far as I understand, does not do any encryption – rather, it expects that the network connection would if necessary be tunnelled through a secure communications channel. If this is not done,
 then even per-pass credentials will not protect against a man-in-the-middle attack. On the other hand, if strong authentication is provided by a secure communications channel, completely independently of SLE itself, then the SLE credentials become vastly less
 critical – more at the level of a protection against misconfiguration than against serious attacks.<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">So yes, in the absence of other measures, a pass-specific SICF can provide a modest security improvement by limiting credential lifetime. However, it is not by itself an adequate protection against modern cybersecurity
 threats. If adequate protection is provided by other means, it is not clear that the pass-specific SICF adds significant value. In other words, the more productive focus would be on protecting and authenticating the underlying connection.<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">Anthony<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"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Barkley, Erik J (US 3970) <</span><a href="mailto:erik.j.barkley@jpl.nasa.gov"><span lang="EN-US">erik.j.barkley@jpl.nasa.gov</span></a><span lang="EN-US">>
<br>
<b>Sent:</b> 16 February 2021 17:02<br>
<b>To:</b> EXTERNAL-Unal, Martin P (9110-Affiliate) <</span><a href="mailto:Martin.Unal@esa.int"><span lang="EN-US">Martin.Unal@esa.int</span></a><span lang="EN-US">><br>
<b>Cc:</b> SMWG <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span lang="EN-US">smwg-bounces@mailman.ccsds.org</span></a><span lang="EN-US">>; Anthony Crowson <</span><a href="mailto:anthony.crowson@telespazio.de"><span lang="EN-US">anthony.crowson@telespazio.de</span></a><span lang="EN-US">>;
</span><a href="mailto:smwg@mailman.ccsds.org"><span lang="EN-US">smwg@mailman.ccsds.org</span></a><span lang="EN-US"><br>
<b>Subject:</b> RE: [cssm] [EXTERNAL] Re: SACP: configuration of tranfer services<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Georgia",serif">Martin,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Georgia",serif">You indicate that pass specific SICF is not “a serious answer” re today’s cybersecurity threats. I fail to see how a permanent SICF is a serious answer.   Do you have
 any suggestions? <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Georgia",serif">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Georgia",serif">-Erik<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:12.0pt;font-family:"Georgia",serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> SMWG <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span lang="EN-US">smwg-bounces@mailman.ccsds.org</span></a><span lang="EN-US">>
<b>On Behalf Of </b></span><a href="mailto:Martin.Unal@esa.int"><span lang="EN-US">Martin.Unal@esa.int</span></a><span lang="EN-US"><br>
<b>Sent:</b> Monday, February 15, 2021 7:26<br>
<b>To:</b> Barkley, Erik J (US 3970) <</span><a href="mailto:erik.j.barkley@jpl.nasa.gov"><span lang="EN-US">erik.j.barkley@jpl.nasa.gov</span></a><span lang="EN-US">><br>
<b>Cc:</b> SMWG <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span lang="EN-US">smwg-bounces@mailman.ccsds.org</span></a><span lang="EN-US">>; Anthony Crowson <</span><a href="mailto:anthony.crowson@telespazio.de"><span lang="EN-US">anthony.crowson@telespazio.de</span></a><span lang="EN-US">>;
</span><a href="mailto:smwg@mailman.ccsds.org"><span lang="EN-US">smwg@mailman.ccsds.org</span></a><span lang="EN-US"><br>
<b>Subject:</b> Re: [cssm] [EXTERNAL] Re: SACP: configuration of tranfer services<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Hello<br>
<br>
This was discussed in length with Wolfgang Hell at the time we discontinued pass specific SICF.</span><span lang="EN-US">
<br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">In term of security, the added value of pass specific SICF is close to nil.</span><span lang="EN-US">
<br>
<br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">In term of operational failure, the handling of pass specific was causing lose of service on a monthly basis.
</span><span lang="EN-US"><br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">And the recovery action was to use permanent SICF. So what the point.</span><span lang="EN-US">
<br>
<br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">I have experienced the usage of pass specific SICF, and I can insure you this is not something you want to see in human spaceflight operation.</span><span lang="EN-US">
<br>
<br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Cyber security has to be taken seriously.
</span><span lang="EN-US"><br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Pass specific SICF is not a serious answer to today threat.<br>
<br>
Regards<br>
________________________________________<br>
Martin UNAL<br>
Ground Operation Manager<br>
Ground Facilities Ops HSO - ONO<br>
H-376<br>
ESOC<br>
Robert-Bosch Strasse 5<br>
64 293 Darmstadt<br>
Germany<br>
Tel +49 6151 90 2959 <br>
________________________________________</span><span lang="EN-US"> <br>
<br>
<br>
<br>
</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">From:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">"Barkley, Erik J\(US 3970\) via SMWG" <</span><a href="mailto:smwg@mailman.ccsds.org"><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">smwg@mailman.ccsds.org</span></a><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">></span><span lang="EN-US">
<br>
</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">To:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">"</span><a href="mailto:Holger.Dreihahn@esa.int"><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">Holger.Dreihahn@esa.int</span></a><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">"
 <</span><a href="mailto:Holger.Dreihahn@esa.int"><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">Holger.Dreihahn@esa.int</span></a><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">>, "</span><a href="mailto:Marcin.Gnat@dlr.de"><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">Marcin.Gnat@dlr.de</span></a><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">"
 <</span><a href="mailto:Marcin.Gnat@dlr.de"><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">Marcin.Gnat@dlr.de</span></a><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">></span><span lang="EN-US">
<br>
</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Cc:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">"SMWG" <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">smwg-bounces@mailman.ccsds.org</span></a><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">>,
 "Anthony Crowson" <</span><a href="mailto:anthony.crowson@telespazio.de"><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">anthony.crowson@telespazio.de</span></a><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">>,
 "</span><a href="mailto:smwg@mailman.ccsds.org"><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">smwg@mailman.ccsds.org</span></a><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">" <</span><a href="mailto:smwg@mailman.ccsds.org"><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">smwg@mailman.ccsds.org</span></a><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">></span><span lang="EN-US">
<br>
</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Date:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">15/02/2021 15:52</span><span lang="EN-US">
<br>
</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Subject:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">Re: [cssm] [EXTERNAL] Re:  SACP: configuration of tranfer services</span><span lang="EN-US">
<br>
</span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Sent by:        </span><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">"SMWG" <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">smwg-bounces@mailman.ccsds.org</span></a><span lang="EN-US" style="font-size:9.0pt;font-family:"Arial",sans-serif">></span><span lang="EN-US">
<o:p></o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US">
<hr size="3" width="100%" noshade="" style="color:#A0A0A0" align="center">
</span></div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"><o:p> </o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-family:"Georgia",serif">Just to add a quick comments to this thread, the DSN also employs permanent SICFs for SLE instance configurations. Much like what Colin has indicated the implementers
 complained that it was just too much trouble to deal with dynamic SICFs as that would involve more testing and more things could go wrong, etc. However given the changing cyber security landscape I would ask if, eventually, can you afford not to have dynamically
 generated SICFs or some other equivalent such that access is very much controlled on a tracking pass by tracking pass basis – especially  if you are supporting human spaceflight? I think it is something we should keep an eye on.</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-family:"Georgia",serif"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-family:"Georgia",serif">Best regards,</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-family:"Georgia",serif">-Erik</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-family:"Georgia",serif"> </span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> SMWG <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span lang="EN-US">smwg-bounces@mailman.ccsds.org</span></a><span lang="EN-US">>
<b>On Behalf Of </b></span><a href="mailto:Holger.Dreihahn@esa.int"><span lang="EN-US">Holger.Dreihahn@esa.int</span></a><b><span lang="EN-US"><br>
Sent:</span></b><span lang="EN-US"> Wednesday, February 10, 2021 23:45<b><br>
To:</b> </span><a href="mailto:Marcin.Gnat@dlr.de"><span lang="EN-US">Marcin.Gnat@dlr.de</span></a><b><span lang="EN-US"><br>
Cc:</span></b><span lang="EN-US"> SMWG <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span lang="EN-US">smwg-bounces@mailman.ccsds.org</span></a><span lang="EN-US">>;
</span><a href="mailto:smwg@mailman.ccsds.org"><span lang="EN-US">smwg@mailman.ccsds.org</span></a><span lang="EN-US">; Anthony Crowson <</span><a href="mailto:anthony.crowson@telespazio.de"><span lang="EN-US">anthony.crowson@telespazio.de</span></a><span lang="EN-US">><b><br>
Subject:</b> [EXTERNAL] Re: [cssm] SACP: configuration of tranfer services<o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US"> <o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Hi Marcin,</span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
I remember having implemented SLE SICF generation for our scheduling system (2008?) and I think we have put some thinking in how to do that. As Colin correctly remarks, the feature of pass specific SICFs is not used - simply too many files.</span><span lang="EN-US">
<br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
However, the trick at the time was to distribute the information for SLE SICF creation to the two relevant places: The mission agreement with the (SLE) service requirements and the ground station model with the ground station capabilities (amongothers the SLE
 services supported formulated as templates). The two are used for determine 'does the station have the required capabilities' and then to combine the information as shown below to the configuration (slide 45 of attachment):</span><span lang="EN-US">
<br>
<br>
<br>
</span><img border="0" width="1381" height="339" style="width:14.3854in;height:3.5312in" id="Picture_x0020_2" src="cid:image001.jpg@01D705D7.BDA8C1E0" alt="cid:image001.jpg@01D705D7.BDA8C1E0"><span lang="EN-US"> <br>
<br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
Some background: Our scheduling is service based, so in addition to the SLE services we define the underlying production services as operational services (TM, TC, DDOR, Ranging, etc.), which are required (mission agreement) and matched with station capabilities
 (station model). Those production services are in fact subject to configuration profiles, which can be refined by missions per pass or requested service.</span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
In orinciple the complete configuration profiles could be defined by FRM parameters.</span><span lang="EN-US">
<br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
I know it's not exactly what you discuss, but maybe of some interest.</span><span lang="EN-US">
<br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
Best regards,</span><span lang="EN-US"> </span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
Holger</span><span lang="EN-US"> <br>
<br>
<br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif"><br>
Holger Dreihahn<br>
European Spacecraft Operations Centre | European Space Agency | H-293<br>
+49 6151 90 2233 | </span><a href="https://urldefense.us/v3/__http:/www.esa.int/esoc__;!!PvBDto6Hs4WbVuu7!cUFMLvyNBxsXjIEqxu_xPyOODmdz7sNc8DmT2jFOhzJdaKN8-vi73Ny7pJZjU4K_DJAqVlE$"><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">http://www.esa.int/esoc</span></a><span lang="EN-US">
<br>
<br>
<br>
</span><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
From:        </span><a href="mailto:Colin.Haddow@esa.int"><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">Colin.Haddow@esa.int</span></a>
<span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">
<br>
To:        </span><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">"Anthony Crowson" <</span><a href="mailto:anthony.crowson@telespazio.de"><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">anthony.crowson@telespazio.de</span></a><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">></span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Cc:        </span><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">"SMWG" <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">smwg-bounces@mailman.ccsds.org</span></a><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">>,
 "</span><a href="mailto:smwg@mailman.ccsds.org"><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">smwg@mailman.ccsds.org</span></a><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">" <</span><a href="mailto:smwg@mailman.ccsds.org"><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">smwg@mailman.ccsds.org</span></a><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">></span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Date:        </span><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">10/02/2021 18:46</span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Subject:        </span><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">Re: [cssm] SACP: configuration of tranfer services</span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif;color:#5F5F5F"><br>
Sent by:        </span><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">"SMWG" <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">smwg-bounces@mailman.ccsds.org</span></a><span lang="EN-US" style="font-size:8.0pt;font-family:"Arial",sans-serif">></span><span lang="EN-US">
<o:p></o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US">
<hr size="3" width="100%" noshade="" style="color:#A0A0A0" align="center">
</span></div>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US"><br>
<br>
</span><span lang="EN-US" style="font-size:10.0pt"><br>
Hi Marcin, Anthony,</span><span lang="EN-US"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
                                    ESOC has effectivly moved to permanent SICfs. The NIS (Neywork Interface System - Handles MCS - Groundstation SLE links) was designed to be able to use dynamic as well as permanent SICFs and the missions screamed about the
 prospect of having to use dynamic ones, much preferring to use permanent ones.</span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
<br>
Cheers for now,</span><span lang="EN-US"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
<br>
Colin</span><span lang="EN-US"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
<br>
<br>
---------------------------------------------------------------------------------------------------------<br>
Dr. Colin R. Haddow,<br>
HSO-GI, European Space Agency,<br>
European Space Operations Centre,<br>
Robert-Bosch-Str 5,<br>
64293 Darmstadt,<br>
Germany.<br>
<br>
Phone; +49 6151 90 2896<br>
Fax;      +49 6151 90 3010<br>
E-Mail;  </span><a href="mailto:colin.haddow@esa.int"><span lang="EN-US" style="font-size:10.0pt">colin.haddow@esa.int</span></a><span lang="EN-US" style="font-size:10.0pt"><br>
---------------------------------------------------------------------------------------------------------</span><span lang="EN-US"><br>
<br>
<br>
</span><span lang="EN-US" style="font-size:8.0pt;color:#5F5F5F"><br>
<br>
From:        </span><span lang="EN-US" style="font-size:8.0pt">"Anthony Crowson" <</span><a href="mailto:anthony.crowson@telespazio.de"><span lang="EN-US" style="font-size:8.0pt">anthony.crowson@telespazio.de</span></a><span lang="EN-US" style="font-size:8.0pt">></span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:8.0pt;color:#5F5F5F"><br>
To:        </span><span lang="EN-US" style="font-size:8.0pt">"</span><a href="mailto:Marcin.Gnat@dlr.de"><span lang="EN-US" style="font-size:8.0pt">Marcin.Gnat@dlr.de</span></a><span lang="EN-US" style="font-size:8.0pt">" <</span><a href="mailto:Marcin.Gnat@dlr.de"><span lang="EN-US" style="font-size:8.0pt">Marcin.Gnat@dlr.de</span></a><span lang="EN-US" style="font-size:8.0pt">>,
 "</span><a href="mailto:smwg@mailman.ccsds.org"><span lang="EN-US" style="font-size:8.0pt">smwg@mailman.ccsds.org</span></a><span lang="EN-US" style="font-size:8.0pt">" <</span><a href="mailto:smwg@mailman.ccsds.org"><span lang="EN-US" style="font-size:8.0pt">smwg@mailman.ccsds.org</span></a><span lang="EN-US" style="font-size:8.0pt">></span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:8.0pt;color:#5F5F5F"><br>
Date:        </span><span lang="EN-US" style="font-size:8.0pt">10/02/2021 18:23</span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:8.0pt;color:#5F5F5F"><br>
Subject:        </span><span lang="EN-US" style="font-size:8.0pt">Re: [cssm] SACP: configuration of tranfer services</span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:8.0pt;color:#5F5F5F"><br>
Sent by:        </span><span lang="EN-US" style="font-size:8.0pt">"SMWG" <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span lang="EN-US" style="font-size:8.0pt">smwg-bounces@mailman.ccsds.org</span></a><span lang="EN-US" style="font-size:8.0pt">></span><span lang="EN-US">
<o:p></o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US">
<hr size="3" width="100%" noshade="" style="color:#A0A0A0" align="center">
</span></div>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US"><br>
</span><span lang="EN-US" style="font-size:10.0pt;color:#004080"><br>
Hi Marcin,</span><span lang="EN-US"> </span><span lang="EN-US" style="font-size:10.0pt;color:#004080"><br>
</span><span lang="EN-US"> </span><span lang="EN-US" style="font-size:10.0pt;color:#004080"><br>
As I would see it, and as I think we had it in the old Blue-1 book, the service instance identifiers and the parameters you feel are missing are part of the service package, not the SA or CP. Your 3 spacecraft configurations would be 3 configuration profiles.
 The SP request may identify a specific station or antenna; at any rate, the SP itself will identify the aperture and the service instances, and at least port IDs.
<br>
There was a discussion which I don’t think was ever fully resolved, about service instance identifiers. The original concept had them being dynamically defined for each service package. But the “stop-gap” SICF approach ended up with people getting used to “permanent”
 SI IDs and being reluctant to change that. Certainly I think it would be unhelpful to have to reproduce the same config multiple times just to use different SI IDs for different apertures.
<br>
Basically what you suggest in your second and third bullets looks about right, modulo discussion on permanence of SI IDs.</span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:10.0pt;color:#004080"><br>
</span><span lang="EN-US"> </span><span lang="EN-US" style="font-size:10.0pt;color:#004080"><br>
I think the FRM parameters identified as just “reporting” mean they cannot be changed during production. Clearly they have to be set somewhere, i.e. “by management”, as part of setting up the service packages.</span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:10.0pt;color:#004080"><br>
</span><span lang="EN-US"> </span><span lang="EN-US" style="font-size:10.0pt;color:#004080"><br>
Anthony</span><span lang="EN-US"> </span><span lang="EN-US" style="font-size:10.0pt;color:#004080"><br>
</span><span lang="EN-US"> </span><b><span lang="EN-US" style="font-size:10.0pt"><br>
From:</span></b><span lang="EN-US" style="font-size:10.0pt"> SMWG <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span lang="EN-US" style="font-size:10.0pt">smwg-bounces@mailman.ccsds.org</span></a><span lang="EN-US" style="font-size:10.0pt">>
<b>On Behalf Of </b></span><a href="mailto:Marcin.Gnat@dlr.de"><span lang="EN-US" style="font-size:10.0pt">Marcin.Gnat@dlr.de</span></a><b><span lang="EN-US" style="font-size:10.0pt"><br>
Sent:</span></b><span lang="EN-US" style="font-size:10.0pt"> 26 January 2021 15:32<b><br>
To:</b> </span><a href="mailto:smwg@mailman.ccsds.org"><span lang="EN-US" style="font-size:10.0pt">smwg@mailman.ccsds.org</span></a><b><span lang="EN-US" style="font-size:10.0pt"><br>
Subject:</span></b><span lang="EN-US" style="font-size:10.0pt"> [cssm] SACP: configuration of tranfer services</span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal" align="center" style="text-align:center"><span lang="EN-US" style="font-size:12.0pt;color:white">-
<b>CAUTION: </b>This message was sent from outside of Telespazio Germany. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe. Please report all suspicious emails to "</span><a href="mailto:support@telespazio.de"><span lang="EN-US" style="font-size:12.0pt">support@telespazio.de</span></a><span lang="EN-US" style="font-size:12.0pt;color:white">"
 as an attachment. -</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-size:10.0pt"><br>
Dear SMWG,</span><span lang="EN-US"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
In course of some implementation work and discussion with my developers, I came to the point where I think we shall have some closer discussion soon (in one of our teleconferences and definitely later during spring meetings).</span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
The protagonist: configuration (profile) of the transfer service (known currently under nicknames “SLE configuration” or “SICF”).</span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
The place and time: somewhere in snowy Bavaria during Winter 2020/2021, Corona situation.</span><span lang="EN-US">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
The Synopsis: during implementation of VEEEEEERY remotely similar profiles into DLR’s new scheduling system, my developers asked me how they shall treat the Service Instance Identifiers in the profile. When I looked at their initial implementation, I noticed,
 that they did put the complete configuration (service) profile in “one piece”, according to the current list from FRM and to what I told them. It does not correspond to the full flexibility of the actual planned SACP (this was not the intention). Anyhow, I
 realized two things: </span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><br>
</span><a name="Gruß"></a><span lang="EN-US" style="font-size:10.0pt"><br>
1.        Not all of SLE parameters were there (GVCID, Port and User identifiers, etc…)
<br>
2.        Defined as such now, projects would need to define multiple configuration profiles, being actually the same, differing only with Service Instance Identifier, for each Service Instance. In our case, for example for TerraSAR mission, we have actual
 3 spacecraft configurations for the antenna, but in total 32 service instances for different stations, antennas and cortexes. This maybe does not multiply 1x1, but at least we would need 32 configuration profiles (I can almost hear the project people coming
 to get me)! <br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
Okay, this is to some extent my own fault, as I burdened the implementation of “some kind of configuration profile” to my developers, and maybe did not thought about it in front. But it shows I think also some shortcomings we have with the concept (maybe it
 will shape up still).</span><span lang="EN-US" style="font-size:12.0pt"> </span>
<span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
To the first point, I quickly noticed, that – even I made a list of parameters based on FRM – actually not all parameters are really exposed. When looking to the export of Holger out of FRM and the schema files, I noticed than there is number of parameters
 which are marked only as “reporting” thus in first place not visible to SACP (hence my omission). And so, all Initiator and Responder Id’s as well as PortId’s and the GVCID’s are marked as “reporting” or “read-only” if you like. How are we going to set them?
<b>Shouldn’t they be also configurable, similar like Service Instance ID?</b></span><span lang="EN-US" style="font-size:12.0pt">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
>From this:</span><span lang="EN-US" style="font-size:12.0pt"> <br>
</span><img border="0" width="419" height="242" style="width:4.3645in;height:2.5208in" id="Picture_x0020_5" src="cid:image002.png@01D705D7.BDA8C1E0" alt="cid:image002.png@01D705D7.BDA8C1E0"><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
To this:</span><span lang="EN-US" style="font-size:12.0pt"> <br>
</span><img border="0" width="411" height="342" style="width:4.2812in;height:3.5625in" id="Picture_x0020_6" src="cid:image003.png@01D705D7.BDA8C1E0" alt="cid:image003.png@01D705D7.BDA8C1E0"><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
Second topic is the actual (operational) separation of the antenna configuration and the transfer services configuration. Currently (at least at DLR) this looks like this:</span><span lang="EN-US" style="font-size:12.0pt">
<br>
</span><img border="0" width="461" height="361" style="width:4.802in;height:3.7604in" id="Picture_x0020_7" src="cid:image004.png@01D705D7.BDA8C1E0" alt="cid:image004.png@01D705D7.BDA8C1E0"><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
There are few antenna configurations (which may be effectively also identical throughout different antennas) and number of SLE configurations (Service Instances). To be fully honest, the multiplication of the SLE config is just due to the different Responder
 ID and Port ID’s, resulting also in separate Service Instance ID, the rest of the config is typically the same (for a specific RCF or FCLTU service).</span><span lang="EN-US" style="font-size:12.0pt">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><b><span lang="EN-US" style="font-size:10.0pt"><br>
How do we want to handle that with our current concept of SACP?</span></b><span lang="EN-US" style="font-size:12.0pt">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
I know we had some brief discussions on that, and there is some three page (chapter 3.4.2) information on intended use in the TechNote of John. It speaks relatively high level about two options, reusing SICF files (kind of an extension to the actual SACP config)
 and also by dynamically setting the abovementioned parameters. <br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
First option says, that SICF files shall be there, and the Responder and Provider ID’s and Ports shall be fixed in Service Agreement and for specific Site and Mission, and later on only these shall be used. It does not actually however says anything on how
 actual SICF is bound to the specific Service Package nor Service Package Request nor Configuration Profile. We have Ports and their ID’s, but how do I know which SICF shall I use? Shall there be also predefined ONE fixed SICF?</span><span lang="EN-US" style="font-size:12.0pt">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
Second option of using the extended/abstract parameters in Service Package  may allow for dynamic provision of the so called “scheduledSocket” which would be just the ProviderPort. So far so good, but still I miss the rest of the SLE/CSTS configuration, especially
 wrt to what I wrote above.</span><span lang="EN-US" style="font-size:12.0pt"> </span>
<span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><b><span lang="EN-US" style="font-size:10.0pt"><br>
Here is where the I lost the trace of the hunted game. And maybe we need here some discussion. ?</span></b><span lang="EN-US" style="font-size:12.0pt">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
I was thinking – just to came into with some proposal – of the following (better ideas are welcome!):</span><span lang="EN-US" style="font-size:12.0pt">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
-          To not destroy everything else we already somehow managed to set up wrt SMURF, SPDF and SACP…</span><span lang="EN-US" style="font-size:12.0pt">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
-          …We could use extended list (as at the beginning) in the Service profile, with Service Instance ID, PortID’s, GVCID’s etc., having predefined some parameters (i.e. Buffer sizes), whereas leaving all of these “variable ones” undefined. That way we
 would have limited number of Configuration Profiles (a set of few generic ones for the spacecraft, universally engageable in every station).</span><span lang="EN-US" style="font-size:12.0pt">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
-          When booking the Service Package (sending the Request) we could “overwrite” the previously mentioned parameters using AbstractParameter Class (for example “InitiatiorID” and “ServiceInstanceID” and “GVCID”). The same would be true for SPDF – the
 values there would be shown in AbstractParameter class (and for example additionally station defined PortID would be provided). This would allow to use all of our Books / Formates as they are, and have individual SLE configuration for each pass/service package.</span><span lang="EN-US" style="font-size:12.0pt">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
-          The disadvantage of the above method would be, that there would need to be some kind of automated generation of Service Instance ID and GVCID on user side and the ProviderPort on provider side. Otherwise we come into danger of crazy users/providers
 not filling these parameters, or filling them wrongly or even filling them different.</span><span lang="EN-US" style="font-size:12.0pt">
</span><span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
Okay… I’m done for today ?</span><span lang="EN-US" style="font-size:12.0pt"> </span>
<span lang="EN-US" style="font-size:10.0pt"><br>
</span><span lang="EN-US" style="font-size:12.0pt"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
Cheers</span><span lang="EN-US" style="font-size:12.0pt"> </span><span lang="EN-US" style="font-size:10.0pt"><br>
Marcin</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New"">_______________________________________________<br>
SMWG mailing list<u><span style="color:blue"><br>
</span></u></span><a href="mailto:SMWG@mailman.ccsds.org"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New"">SMWG@mailman.ccsds.org</span></a><u><span lang="EN-US" style="font-size:12.0pt;color:blue"><br>
</span></u><a href="https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg__;!!PvBDto6Hs4WbVuu7!cUFMLvyNBxsXjIEqxu_xPyOODmdz7sNc8DmT2jFOhzJdaKN8-vi73Ny7pJZjU4K_oOrp91M$"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New"">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg</span></a><span style="font-size:12.0pt">
</span><span lang="EN-US"><br>
</span><span lang="EN-US" style="font-size:12.0pt;font-family:"Courier New"">This message is intended only for the recipient(s) named above. It may contain proprietary information and/or<br>
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received<br>
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect<br>
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (</span><a href="mailto:dpo@esa.int"><span lang="EN-US" style="font-size:12.0pt;font-family:"Courier New"">dpo@esa.int</span></a><span lang="EN-US" style="font-size:12.0pt;font-family:"Courier New"">).</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""><br>
_______________________________________________<br>
SMWG mailing list<u><span style="color:blue"><br>
</span></u></span><a href="mailto:SMWG@mailman.ccsds.org"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New"">SMWG@mailman.ccsds.org</span></a><u><span lang="EN-US" style="font-size:12.0pt;color:blue"><br>
</span></u><a href="https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg__;!!PvBDto6Hs4WbVuu7!cUFMLvyNBxsXjIEqxu_xPyOODmdz7sNc8DmT2jFOhzJdaKN8-vi73Ny7pJZjU4K_oOrp91M$"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New"">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg</span></a>
<span lang="EN-US"><o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New"">This message is intended only for the recipient(s) named above. It may contain proprietary information and/or</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New"">protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New"">this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect</span><span lang="EN-US"><o:p></o:p></span></p>
<p style="margin:0cm;margin-bottom:.0001pt"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New"">personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (</span><a href="mailto:dpo@esa.int"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New"">dpo@esa.int</span></a><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New"">).<tt>_______________________________________________</tt><br>
<tt>SMWG mailing list</tt><br>
</span><a href="mailto:SMWG@mailman.ccsds.org"><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New"">SMWG@mailman.ccsds.org</span></a><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""><br>
</span><a href="https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg__;!!PvBDto6Hs4WbVuu7!abAism1pR-n6NTePhOZgrDRTFaxIsbYBpPXs0GaDo3686SSf-BVBeVVaERZ8oxNti7XymgY$"><tt><span lang="EN-US" style="font-size:10.0pt">https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg</span></tt></a><span lang="EN-US"><o:p></o:p></span></p>
<pre><span lang="EN-US">This message is intended only for the recipient(s) named above. It may contain proprietary information and/or<o:p></o:p></span></pre>
<pre><span lang="EN-US">protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received<o:p></o:p></span></pre>
<pre><span lang="EN-US">this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect<o:p></o:p></span></pre>
<pre><span lang="EN-US">personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (</span><a href="mailto:dpo@esa.int"><span lang="EN-US">dpo@esa.int</span></a><span lang="EN-US">).<o:p></o:p></span></pre>
</div>
</div>
</div>
</body>
</html>