<span style=" font-size:10pt;font-family:sans-serif">Keith,</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Thank your for
your e-mail.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">From what I have
seen in the updated draft and its comments, we can close PIDs SLS-01, -02,
-03, -04, -05, -07, -08, -09, and -12,</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">For the remaining
ones, please find additional feedback.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">I believe PID
SLS-06 has been missed, since I do not see any comment at the relevant
paragraph (page 2-1, tenth paragraph) and the text remains as it was. It
should be easy to fix.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">PIDs SLS-10 and
-11 go about anonymous bundles. I believe you have interpreted well my
willingness to eliminate them on a space mission context. </span>
<br><span style=" font-size:10pt;font-family:sans-serif">Perhaps you could
explain what is the purpose of anonymous bundles and why they are needed
on a space mission context. </span>
<br><span style=" font-size:10pt;font-family:sans-serif">I could see a
potential use for network security . Anonymity is a well sought security
property for certain networks. An observer cannot determine who is talking
to who. </span>
<br><span style=" font-size:10pt;font-family:sans-serif">But I guess this
is not the current motivation behind their tolerance in this standard.
So I need some understanding here.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">What are they
good for? Anonymous for whom?</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">PID SLS-13 is
about error indications at the service interface. In fact after reading
your response I agree with you that, in contrast to those reported in Annex
C3, they do not have interoperability meaning.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">My reference to
other protocols was pointing to the example of the Verification Status
Code defined in the Space Link Protocols when implementing SDLS.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">But clearly that
one has interoperability meaning as well.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Hence, no need
to define error codes at the service interface.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Therefore, we
can close this one as well.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">PID SLS-14 is
about being more clear on the boundaries and the subject for the requirements
provided in section 5.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">The so-called
"System" seemed to me undefined, too open to interpretation.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">I wonder if what
you are actually formulating in that section is a few key requirements
for a Bundle Protocol node (implementation).</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Note for instance
the very clear and specific subject used in requirement 5.1.1 (now 5.2.1):
Bundle protocol node.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">Note as well "Bundle
protocol agent" in 5.2.1 (now 5.3.1). </span>
<br><span style=" font-size:10pt;font-family:sans-serif">Stating requirements
for the "bundle protocol" instead would not make much sense in
my opinion.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">They should have
been an input from which this standard would have been derived.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">So I think that
if you identify the (active) subject for the requirements stated in that
section and reflect it in the title, you will probably improve meaning.</span>
<br><span style=" font-size:10pt;font-family:sans-serif">For instance,
what about Bundle Protocol Node (and/or Agent) Requirements?</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Your thoughts?</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Kind regards,</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">Ignacio</span>
<br>
<br><img src=cid:_1_0A3693300A368F4C00532075C12588FB style="border:0px solid;"><span style=" font-size:12pt"> </span>
<br>
<br><span style=" font-size:9pt;color:#4f4f4f;font-family:NotesEsa"><b>Ignacio
Aguilar Sánchez</b></span>
<br><span style=" font-size:9pt;color:#4f4f4f;font-family:NotesEsa">Communication
Systems Engineer</span>
<br><span style=" font-size:9pt;color:#4f4f4f;font-family:NotesEsa">Electrical
Engineering Department</span>
<br>
<br><span style=" font-size:9pt;color:#4f4f4f;font-family:NotesEsa">European
Space Research and Technology Centre<br>
Keplerlaan 1, PO Box 299, 2200 AG Noordwijk, The Netherlands</span>
<br><span style=" font-size:9pt;color:#4f4f4f;font-family:NotesEsa">Tel.
(31) 71 565 5695</span>
<br><span style=" font-size:9pt;color:#4f4f4f;font-family:NotesEsa">Fax
(31) 71 565 5418</span>
<br><span style=" font-size:9pt;color:#4f4f4f;font-family:NotesEsa">Email:
ignacio.aguilar.sanchez@esa.int<br>
</span><a href=www.esa.int><span style=" font-size:9pt;color:blue;font-family:NotesEsa">www.esa.int</span></a>
<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">"Dr.
Keith L Scott" <kscott@mitre.org></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">To:
</span><span style=" font-size:9pt;font-family:sans-serif">"Ignacio.Aguilar.Sanchez@esa.int"
<Ignacio.Aguilar.Sanchez@esa.int>, "Blanding, Beau T. (MSFC-HP27)[HOSC
SERVICES CONTRACT]" <beau.t.blanding@nasa.gov>, "sis-dtn@mailman.ccsds.org"
<sis-dtn@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">14/11/2022
17:48</span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Subject:
</span><span style=" font-size:9pt;font-family:sans-serif">PID
responses for BPV7</span>
<br>
<hr noshade>
<br>
<br>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">Ignacio,</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:11pt;font-family:Calibri">The
sis-dtn working group has reviewed your PIDs on the draft BPv7 Red Book.</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:11pt;font-family:Calibri">A
spreadsheet with the dispositions as well as a marked-up document are available
from the Google Drive Folder here:</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"><a href="https://drive.google.com/drive/folders/1q1bS7VfNsLfh55GwKvy6Eza_Q1FoU4Kn?usp=share_link"><span style=" font-size:11pt;color:#0082bf;font-family:Calibri"><u>https://drive.google.com/drive/folders/1q1bS7VfNsLfh55GwKvy6Eza_Q1FoU4Kn?usp=share_link</u></span></a></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:11pt;font-family:Calibri">And
I can send you snapshots if that’s difficult to access.</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:11pt;font-family:Calibri">Can
you let me know if you agree with the dispositions and/or if you have some
time to discuss them? I think the largest thing that we’d like to
NOT do is to add a list of error indications at the service interface,
which is slightly (maybe) qualitatively different from the error indications
listed in annex C in that the service interface is entirely local and implementation-dependent.
We could probably add such a list of suggested error indications
in a non-normative note or discussion section, but I’d prefer to add it
to the list of material to put into a revised DTN rationale Green Book.</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:11pt;font-family:Calibri">
v/r,</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:11pt;font-family:Calibri">
--keith</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"></p>
<p style="margin-top:0px;margin-Bottom:0px"></p>
<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>