<span style=" font-size:10pt;font-family:sans-serif">Hello<br>
</span>
<br><span style=" font-size:11pt;color:#004080;font-family:Calibri">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.</span>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">However,
having even one pass hijacked could in the worst case lead to loss of a
mission.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">If
I’m already wrong at this state, please correct me gently and ignore the
rest…</span></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">This
is wrong.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">The
credential are not part of the SICF.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">The
credential (user/password) are stored in the SLE provider repository.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">The
pass specific SICF concept introduces 3 weakness which can result in a
bind failure or service degradation.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">They
are clearly weakness, as they cause problem to operational usage, not to
someone willing to damage the service.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">-
Time range request => If you support times change, you get unbind</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">-
Pass specific Sagr => If it does not match, you can not bind. This is
not a problem for a hacker, as the sagr follow basic rule, with proper
tool, you can generate multiple name until one bind.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">A
security Guru will then propose to "lock" the user in case of
too many failure. Not a problem if your goal is to damage the service,
but a real mess for the real user locked out as well.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">From
a user perspective, this solution can be seen as equivalent as changing
you username on a daily basis, while keeping your password. Would you really
buy that ?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">Last
but not least:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">-
SICF contains many configuration parameter. If you generate SICF for each
pass, you introduce the chance to use new/wrong parameters which will cause
random behaviour in the comms.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">The
parameter change effect (e.g. buffer size) is very insidious and can be
hard to identify.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">From
past experience you will have divergence between pass specific and permanent
SICF within a year.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">You
still want to use pass specific ? Good, how will you generates and exchange
the information for each pass in due time ? How will you accomodate late
changes/request and update ?</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">As
you don't trust you LAN (that why you want to use pass specific) this will
be complicated.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">During
the time DSN/ESTRACK have been using pass specific SICF, this has been
the killer. The DSN database generating the unique sagr was getting rebooted
every now and then, the provider and user sagr were commonly out of sync.
But was not a problem as we have permanent SICF as fall back.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">Now
to answer to Erik question about what shall be security:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">-
TM/TC shall be encrypted between control system and spacecraft.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">-
Update you SLE provider password on a regular basis (but no, don't the
update the username !)</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">-
To protect your SLE provider, you must build a safe VPN.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">-
You want to be more safe ? Add a firewall in front of your SLE provider
to block "agressive" IP coming from inside your VPN.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">If
a hacker is within your VPN and able to emulate your control system IP,
you lose. But at that stage you can assume that the pass lost is the least
of your problem.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">To
conclude:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">Losing
a pass shall never lead to a loss of mission.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">Passes
are lost for many reason on a regular basis (</span><a href=https://en.wikipedia.org/wiki/Hanlon%27s_razor><span style=" font-size:10pt;color:blue;font-family:sans-serif">https://en.wikipedia.org/wiki/Hanlon%27s_razor</span></a><span style=" font-size:10pt;font-family:sans-serif">),
and I can not remember in the history of space that a mission was lost
due to a failed pass.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">Due
to TC encryption, most of current attacks are of DoS type. Either at IP
level, which we protect by using VPN and firewall, or for the "very"
bad guys, by upliningk a pure career to saturate the on-board reciever.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">The
Chinese got a SinoSat CCTV satellite successfuly hacked by the Falun gong
group in 2002 using this technic to hijack the payload.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">But
this can usually be traced back as you need lots of hardware. Be prepared
to face the wrath of the owner. </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:sans-serif">I
suggest you have a look to what happens to the Falun gong guys before trying
you skills on a chinese hardware.<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></p>
<br>
<br>
<br>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">From:
</span><span style=" font-size:9pt;font-family:sans-serif">"Anthony
Crowson" <anthony.crowson@telespazio.de></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"Barkley,
Erik J (US 3970)" <erik.j.barkley@jpl.nasa.gov>, "EXTERNAL-Unal,
Martin P (9110-Affiliate)" <Martin.Unal@esa.int></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Cc:
</span><span style=" font-size:9pt;font-family:sans-serif">"SMWG"
<smwg-bounces@mailman.ccsds.org>, "smwg@mailman.ccsds.org"
<smwg@mailman.ccsds.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Date:
</span><span style=" font-size:9pt;font-family:sans-serif">16/02/2021
18:50</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">RE:
[cssm] [EXTERNAL] Re: SACP: configuration of tranfer services</span>
<br>
<hr noshade>
<br>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">However,
having even one pass hijacked could in the worst case lead to loss of a
mission.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">If
I’m already wrong at this state, please correct me gently and ignore the
rest…</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"><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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">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.</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri">Anthony</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;color:#004080;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>From:</b>
Barkley, Erik J (US 3970) <erik.j.barkley@jpl.nasa.gov> <b><br>
Sent:</b> 16 February 2021 17:02<b><br>
To:</b> EXTERNAL-Unal, Martin P (9110-Affiliate) <Martin.Unal@esa.int><b><br>
Cc:</b> SMWG <smwg-bounces@mailman.ccsds.org>; Anthony Crowson <anthony.crowson@telespazio.de>;
smwg@mailman.ccsds.org<b><br>
Subject:</b> RE: [cssm] [EXTERNAL] Re: SACP: configuration of tranfer services</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Georgia">Martin,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Georgia"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Georgia">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? </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Georgia"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Georgia">Best
regards,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Georgia">-Erik</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Georgia"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"><b>From:</b>
SMWG <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>smwg-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">>
<b>On Behalf Of </b></span><a href=mailto:Martin.Unal@esa.int><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>Martin.Unal@esa.int</u></span></a><span style=" font-size:11pt;font-family:Calibri"><b><br>
Sent:</b> Monday, February 15, 2021 7:26<b><br>
To:</b> Barkley, Erik J (US 3970) <</span><a href=mailto:erik.j.barkley@jpl.nasa.gov><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>erik.j.barkley@jpl.nasa.gov</u></span></a><span style=" font-size:11pt;font-family:Calibri">><b><br>
Cc:</b> SMWG <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>smwg-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:11pt;font-family:Calibri">>;
Anthony Crowson <</span><a href=mailto:anthony.crowson@telespazio.de><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>anthony.crowson@telespazio.de</u></span></a><span style=" font-size:11pt;font-family:Calibri">>;
</span><a href=mailto:smwg@mailman.ccsds.org><span style=" font-size:11pt;color:blue;font-family:Calibri"><u>smwg@mailman.ccsds.org</u></span></a><span style=" font-size:11pt;font-family:Calibri"><b><br>
Subject:</b> Re: [cssm] [EXTERNAL] Re: SACP: configuration of tranfer services</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial">Hello<br>
<br>
This was discussed in length with Wolfgang Hell at the time we discontinued
pass specific SICF.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
In term of security, the added value of pass specific SICF is close to
nil.</span><span style=" font-size:11pt;font-family:Calibri"> <br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
In term of operational failure, the handling of pass specific was causing
lose of service on a monthly basis. <br>
And the recovery action was to use permanent SICF. So what the point.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
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 style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Cyber security has to be taken seriously. <br>
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 style=" font-size:11pt;font-family:Calibri">
<br>
<br>
<br>
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
From: </span><span style=" font-size:9pt;font-family:Arial">"Barkley,
Erik J\(US 3970\) via SMWG" <</span><a href=mailto:smwg@mailman.ccsds.org><span style=" font-size:9pt;color:blue;font-family:Arial"><u>smwg@mailman.ccsds.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
To: </span><span style=" font-size:9pt;font-family:Arial">"</span><a href=mailto:Holger.Dreihahn@esa.int><span style=" font-size:9pt;color:blue;font-family:Arial"><u>Holger.Dreihahn@esa.int</u></span></a><span style=" font-size:9pt;font-family:Arial">"
<</span><a href=mailto:Holger.Dreihahn@esa.int><span style=" font-size:9pt;color:blue;font-family:Arial"><u>Holger.Dreihahn@esa.int</u></span></a><span style=" font-size:9pt;font-family:Arial">>,
"</span><a href=mailto:Marcin.Gnat@dlr.de><span style=" font-size:9pt;color:blue;font-family:Arial"><u>Marcin.Gnat@dlr.de</u></span></a><span style=" font-size:9pt;font-family:Arial">"
<</span><a href=mailto:Marcin.Gnat@dlr.de><span style=" font-size:9pt;color:blue;font-family:Arial"><u>Marcin.Gnat@dlr.de</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Cc: </span><span style=" font-size:9pt;font-family:Arial">"SMWG"
<</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span style=" font-size:9pt;color:blue;font-family:Arial"><u>smwg-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:9pt;font-family:Arial">>,
"Anthony Crowson" <</span><a href=mailto:anthony.crowson@telespazio.de><span style=" font-size:9pt;color:blue;font-family:Arial"><u>anthony.crowson@telespazio.de</u></span></a><span style=" font-size:9pt;font-family:Arial">>,
"</span><a href=mailto:smwg@mailman.ccsds.org><span style=" font-size:9pt;color:blue;font-family:Arial"><u>smwg@mailman.ccsds.org</u></span></a><span style=" font-size:9pt;font-family:Arial">"
<</span><a href=mailto:smwg@mailman.ccsds.org><span style=" font-size:9pt;color:blue;font-family:Arial"><u>smwg@mailman.ccsds.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Date: </span><span style=" font-size:9pt;font-family:Arial">15/02/2021
15:52</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Subject: </span><span style=" font-size:9pt;font-family:Arial">Re:
[cssm] [EXTERNAL] Re: SACP: configuration of tranfer services</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#5f5f5f;font-family:Arial"><br>
Sent by: </span><span style=" font-size:9pt;font-family:Arial">"SMWG"
<</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span style=" font-size:9pt;color:blue;font-family:Arial"><u>smwg-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:9pt;font-family:Arial">></span><span style=" font-size:11pt;font-family:Calibri">
</span></p>
<div align=center>
<hr noshade></div>
<p style="margin-top:0px;margin-Bottom:240px"><span style=" font-size:11pt;font-family:Calibri"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Georgia">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></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Georgia"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Georgia">Best
regards,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Georgia">-Erik</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Georgia"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"><b>From:</b>
SMWG <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span style=" font-size:12pt;color:blue;font-family:Times New Roman"><u>smwg-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:12pt;font-family:Times New Roman">>
<b>On Behalf Of </b></span><a href=mailto:Holger.Dreihahn@esa.int><span style=" font-size:12pt;color:blue;font-family:Times New Roman"><u>Holger.Dreihahn@esa.int</u></span></a><span style=" font-size:12pt;font-family:Times New Roman"><b><br>
Sent:</b> Wednesday, February 10, 2021 23:45<b><br>
To:</b> </span><a href=mailto:Marcin.Gnat@dlr.de><span style=" font-size:12pt;color:blue;font-family:Times New Roman"><u>Marcin.Gnat@dlr.de</u></span></a><span style=" font-size:12pt;font-family:Times New Roman"><b><br>
Cc:</b> SMWG <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span style=" font-size:12pt;color:blue;font-family:Times New Roman"><u>smwg-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:12pt;font-family:Times New Roman">>;
</span><a href=mailto:smwg@mailman.ccsds.org><span style=" font-size:12pt;color:blue;font-family:Times New Roman"><u>smwg@mailman.ccsds.org</u></span></a><span style=" font-size:12pt;font-family:Times New Roman">;
Anthony Crowson <</span><a href=mailto:anthony.crowson@telespazio.de><span style=" font-size:12pt;color:blue;font-family:Times New Roman"><u>anthony.crowson@telespazio.de</u></span></a><span style=" font-size:12pt;font-family:Times New Roman">><b><br>
Subject:</b> [EXTERNAL] Re: [cssm] SACP: configuration of tranfer services</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial">Hi
Marcin,</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><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 style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
<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 style=" font-size:12pt;font-family:Times New Roman">
<br>
<br>
<br>
</span><img src=cid:_2_1311852C13117EB8003C94C4C125867F style="border:0px solid;"><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
<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 style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
In orinciple the complete configuration profiles could be defined by FRM
parameters.</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
<br>
I know it's not exactly what you discuss, but maybe of some interest.</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
<br>
Best regards,</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Arial"><br>
Holger</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
<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 style=" font-size:10pt;color:blue;font-family:Arial"><u>http://www.esa.int/esoc</u></span></a><span style=" font-size:12pt;font-family:Times New Roman">
<br>
<br>
</span><span style=" font-size:8pt;color:#5f5f5f;font-family:Arial"><br>
<br>
From: </span><a href=mailto:Colin.Haddow@esa.int><span style=" font-size:8pt;color:blue;font-family:Arial"><u>Colin.Haddow@esa.int</u></span></a><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:8pt;color:#5f5f5f;font-family:Arial"><br>
To: </span><span style=" font-size:8pt;font-family:Arial">"Anthony
Crowson" <</span><a href=mailto:anthony.crowson@telespazio.de><span style=" font-size:8pt;color:blue;font-family:Arial"><u>anthony.crowson@telespazio.de</u></span></a><span style=" font-size:8pt;font-family:Arial">></span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:8pt;color:#5f5f5f;font-family:Arial"><br>
Cc: </span><span style=" font-size:8pt;font-family:Arial">"SMWG"
<</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span style=" font-size:8pt;color:blue;font-family:Arial"><u>smwg-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:8pt;font-family:Arial">>,
"</span><a href=mailto:smwg@mailman.ccsds.org><span style=" font-size:8pt;color:blue;font-family:Arial"><u>smwg@mailman.ccsds.org</u></span></a><span style=" font-size:8pt;font-family:Arial">"
<</span><a href=mailto:smwg@mailman.ccsds.org><span style=" font-size:8pt;color:blue;font-family:Arial"><u>smwg@mailman.ccsds.org</u></span></a><span style=" font-size:8pt;font-family:Arial">></span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:8pt;color:#5f5f5f;font-family:Arial"><br>
Date: </span><span style=" font-size:8pt;font-family:Arial">10/02/2021
18:46</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:8pt;color:#5f5f5f;font-family:Arial"><br>
Subject: </span><span style=" font-size:8pt;font-family:Arial">Re:
[cssm] SACP: configuration of tranfer services</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:8pt;color:#5f5f5f;font-family:Arial"><br>
Sent by: </span><span style=" font-size:8pt;font-family:Arial">"SMWG"
<</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span style=" font-size:8pt;color:blue;font-family:Arial"><u>smwg-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:8pt;font-family:Arial">></span><span style=" font-size:12pt;font-family:Times New Roman">
</span></p>
<div align=center>
<hr noshade></div>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt;font-family:Times New Roman"><br>
</span><span style=" font-size:10pt;font-family:Times New Roman"><br>
<br>
Hi Marcin, Anthony,</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Times New Roman"><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 style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Times New Roman"><br>
<br>
Cheers for now,</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Times New Roman"><br>
<br>
Colin</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:10pt;font-family:Times New Roman"><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 style=" font-size:10pt;color:blue;font-family:Times New Roman"><u>colin.haddow@esa.int</u></span></a><span style=" font-size:10pt;font-family:Times New Roman"><br>
---------------------------------------------------------------------------------------------------------</span><span style=" font-size:12pt;font-family:Times New Roman"><br>
<br>
</span><span style=" font-size:8pt;color:#5f5f5f;font-family:Times New Roman"><br>
<br>
<br>
From: </span><span style=" font-size:8pt;font-family:Times New Roman">"Anthony
Crowson" <</span><a href=mailto:anthony.crowson@telespazio.de><span style=" font-size:8pt;color:blue;font-family:Times New Roman"><u>anthony.crowson@telespazio.de</u></span></a><span style=" font-size:8pt;font-family:Times New Roman">></span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:8pt;color:#5f5f5f;font-family:Times New Roman"><br>
To: </span><span style=" font-size:8pt;font-family:Times New Roman">"</span><a href=mailto:Marcin.Gnat@dlr.de><span style=" font-size:8pt;color:blue;font-family:Times New Roman"><u>Marcin.Gnat@dlr.de</u></span></a><span style=" font-size:8pt;font-family:Times New Roman">"
<</span><a href=mailto:Marcin.Gnat@dlr.de><span style=" font-size:8pt;color:blue;font-family:Times New Roman"><u>Marcin.Gnat@dlr.de</u></span></a><span style=" font-size:8pt;font-family:Times New Roman">>,
"</span><a href=mailto:smwg@mailman.ccsds.org><span style=" font-size:8pt;color:blue;font-family:Times New Roman"><u>smwg@mailman.ccsds.org</u></span></a><span style=" font-size:8pt;font-family:Times New Roman">"
<</span><a href=mailto:smwg@mailman.ccsds.org><span style=" font-size:8pt;color:blue;font-family:Times New Roman"><u>smwg@mailman.ccsds.org</u></span></a><span style=" font-size:8pt;font-family:Times New Roman">></span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:8pt;color:#5f5f5f;font-family:Times New Roman"><br>
Date: </span><span style=" font-size:8pt;font-family:Times New Roman">10/02/2021
18:23</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:8pt;color:#5f5f5f;font-family:Times New Roman"><br>
Subject: </span><span style=" font-size:8pt;font-family:Times New Roman">Re:
[cssm] SACP: configuration of tranfer services</span><span style=" font-size:12pt;font-family:Times New Roman">
</span><span style=" font-size:8pt;color:#5f5f5f;font-family:Times New Roman"><br>
Sent by: </span><span style=" font-size:8pt;font-family:Times New Roman">"SMWG"
<</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span style=" font-size:8pt;color:blue;font-family:Times New Roman"><u>smwg-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:8pt;font-family:Times New Roman">></span><span style=" font-size:12pt;font-family:Times New Roman">
</span></p>
<div align=center>
<hr noshade></div>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;color:#004080;font-family:Times New Roman"><br>
<br>
Hi Marcin,</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;color:#004080;font-family:Times New Roman"><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 style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;color:#004080;font-family:Times New Roman"><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 style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;color:#004080;font-family:Times New Roman"><br>
Anthony</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Times New Roman"><b><br>
From:</b> SMWG <</span><a href="mailto:smwg-bounces@mailman.ccsds.org"><span style=" font-size:10pt;color:blue;font-family:Times New Roman"><u>smwg-bounces@mailman.ccsds.org</u></span></a><span style=" font-size:10pt;font-family:Times New Roman">>
<b>On Behalf Of </b></span><a href=mailto:Marcin.Gnat@dlr.de><span style=" font-size:10pt;color:blue;font-family:Times New Roman"><u>Marcin.Gnat@dlr.de</u></span></a><span style=" font-size:10pt;font-family:Times New Roman"><b><br>
Sent:</b> 26 January 2021 15:32<b><br>
To:</b> </span><a href=mailto:smwg@mailman.ccsds.org><span style=" font-size:10pt;color:blue;font-family:Times New Roman"><u>smwg@mailman.ccsds.org</u></span></a><span style=" font-size:10pt;font-family:Times New Roman"><b><br>
Subject:</b> [cssm] SACP: configuration of tranfer services</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span></p>
<div align=center><span style=" font-size:12pt;color:white;font-family:Calibri">-
<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 style=" font-size:12pt;color:blue;font-family:Calibri"><u>support@telespazio.de</u></span></a><span style=" font-size:12pt;color:white;font-family:Calibri">"
as an attachment. -</span></div>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Times New Roman"><br>
Dear SMWG,</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Times New Roman"><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 style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Times New Roman"><br>
The protagonist: configuration (profile) of the transfer service (known
currently under nicknames “SLE configuration” or “SICF”).</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Times New Roman"><br>
The place and time: somewhere in snowy Bavaria during Winter 2020/2021,
Corona situation.</span><span style=" font-size:12pt;font-family:Times New Roman">
<br>
</span><span style=" font-size:10pt;font-family:Times New Roman"><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></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Calibri"><br>
<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)! </span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:10pt;font-family:Calibri"><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 style=" font-size:12pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Calibri"><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 style=" font-size:12pt;font-family:Calibri"> <br>
</span><span style=" font-size:10pt;font-family:Calibri"><br>
>From this:</span><span style=" font-size:12pt;font-family:Calibri"> </span><span style=" font-size:11pt;font-family:Calibri"><br>
</span><img src=cid:_4_0F129A5C0F129004003C94C4C125867F style="border:0px solid;"><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:10pt;font-family:Calibri"><br>
To this:</span><span style=" font-size:12pt;font-family:Calibri"> </span><span style=" font-size:11pt;font-family:Calibri"><br>
</span><img src=cid:_4_0F129D740F129004003C94C4C125867F style="border:0px solid;"><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:10pt;font-family:Calibri"><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 style=" font-size:12pt;font-family:Calibri">
</span><span style=" font-size:11pt;font-family:Calibri"><br>
</span><img src=cid:_4_1316DB5C0F129004003C94C4C125867F style="border:0px solid;"><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:10pt;font-family:Calibri"><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 style=" font-size:12pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Calibri"><b><br>
How do we want to handle that with our current concept of SACP?</b></span><span style=" font-size:12pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Calibri"><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. </span><span style=" font-size:12pt;font-family:Calibri"><br>
</span><span style=" font-size:10pt;font-family:Calibri"><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 style=" font-size:12pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Calibri"><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 style=" font-size:12pt;font-family:Calibri"> <br>
</span><span style=" font-size:10pt;font-family:Calibri"><b><br>
Here is where the I lost the trace of the hunted game. And maybe we need
here some discussion. ?</b></span><span style=" font-size:12pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Calibri"><br>
I was thinking – just to came into with some proposal – of the following
(better ideas are welcome!):</span><span style=" font-size:12pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Calibri"><br>
- To not destroy everything else we already
somehow managed to set up wrt SMURF, SPDF and SACP…</span><span style=" font-size:12pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Calibri"><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 style=" font-size:12pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Calibri"><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 style=" font-size:12pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Calibri"><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 style=" font-size:12pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Calibri"><br>
Okay… I’m done for today ?</span><span style=" font-size:12pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Calibri"><br>
Cheers</span><span style=" font-size:12pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Calibri"><br>
Marcin</span><span style=" font-size:10pt;font-family:Courier New">_______________________________________________<br>
SMWG mailing list</span><span style=" font-size:11pt;color:blue;font-family:Calibri"><u><br>
</u></span><a href=mailto:SMWG@mailman.ccsds.org><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>SMWG@mailman.ccsds.org</u></span></a><span style=" font-size:11pt;color:blue;font-family:Calibri"><u><br>
</u></span><a href="https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg__;!!PvBDto6Hs4WbVuu7!cUFMLvyNBxsXjIEqxu_xPyOODmdz7sNc8DmT2jFOhzJdaKN8-vi73Ny7pJZjU4K_oOrp91M$"><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg</u></span></a><span style=" font-size:12pt;font-family:Calibri">
</span><span style=" font-size:12pt;font-family:Courier New"><br>
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 style=" font-size:12pt;color:blue;font-family:Courier New"><u>dpo@esa.int</u></span></a><span style=" font-size:12pt;font-family:Courier New">).</span><span style=" font-size:10pt;font-family:Courier New"><br>
_______________________________________________<br>
SMWG mailing list</span><span style=" font-size:11pt;color:blue;font-family:Calibri"><u><br>
</u></span><a href=mailto:SMWG@mailman.ccsds.org><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>SMWG@mailman.ccsds.org</u></span></a><span style=" font-size:11pt;color:blue;font-family:Calibri"><u><br>
</u></span><a href="https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg__;!!PvBDto6Hs4WbVuu7!cUFMLvyNBxsXjIEqxu_xPyOODmdz7sNc8DmT2jFOhzJdaKN8-vi73Ny7pJZjU4K_oOrp91M$"><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg</u></span></a><span style=" font-size:11pt;font-family:Calibri">
</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><a name="Gruß"></a><span style=" font-size:10pt;font-family:Courier New">This
message is intended only for the recipient(s) named above. It may contain
proprietary information and/or</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Courier New">protected
content. Any unauthorised disclosure, use, retention or dissemination is
prohibited. If you have received</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Courier New">this
e-mail in error, please notify the sender immediately. ESA applies appropriate
organisational measures to protect</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;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 style=" font-size:10pt;color:blue;font-family:Courier New"><u>dpo@esa.int</u></span></a><span style=" font-size:10pt;font-family:Courier New">)._______________________________________________<br>
SMWG mailing list</span><span style=" font-size:10pt;color:blue;font-family:Courier New"><u><br>
</u></span><a href=mailto:SMWG@mailman.ccsds.org><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>SMWG@mailman.ccsds.org</u></span></a><span style=" font-size:12pt;color:blue;font-family:Times New Roman"><u><br>
</u></span><a href="https://urldefense.us/v3/__https:/mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg__;!!PvBDto6Hs4WbVuu7!abAism1pR-n6NTePhOZgrDRTFaxIsbYBpPXs0GaDo3686SSf-BVBeVVaERZ8oxNti7XymgY$"><span style=" font-size:10pt;color:blue;font-family:Courier New"><u>https://mailman.ccsds.org/cgi-bin/mailman/listinfo/smwg</u></span></a></p>
<br><span style=" font-size:10pt;font-family:Courier New">This message
is intended only for the recipient(s) named above. It may contain proprietary
information and/or</span>
<br><span style=" font-size:10pt;font-family:Courier New">protected content.
Any unauthorised disclosure, use, retention or dissemination is prohibited.
If you have received</span>
<br><span style=" font-size:10pt;font-family:Courier New">this e-mail in
error, please notify the sender immediately. ESA applies appropriate organisational
measures to protect</span>
<br><span style=" font-size:10pt;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 style=" font-size:10pt;color:blue;font-family:Courier New"><u>dpo@esa.int</u></span></a><span style=" font-size:10pt;font-family:Courier New">).</span>
<br>
<br><PRE>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).
</PRE>