<span style=" font-size:10pt;font-family:sans-serif">Keith,</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">I am ok with your
explanations about anonymous bundles. The PIDs SLS-10 and 11 can now be
closed.</span>
<br>
<br><span style=" font-size:10pt;font-family:sans-serif">For SLS-14 and
based on what I read below, we are in sync. Just wait for any additional
feedback and a final edition. Similarly for SLS-06.</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><img src=cid:_1_084D07DC084D03F8004DC271C12588FC 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></span>
<br><span style=" font-size:9pt;color:#5f5f5f;font-family:sans-serif">Cc:
</span><span style=" font-size:9pt;font-family:sans-serif">"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">15/11/2022
17:06</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:
[EXT] Re: 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">-06</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">My
sincere apologies for missing -06, will get on that. Ah, OK, I copied
your ‘from’ text…</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">Anonymous
bundles:</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">I
think we need to support the <i>concept</i> of dtn:none in case e.g. somebody
SENDS an anonymous bundle into the CCSDS portion of the DTN network. As
a concrete example, if somebody were to perversely send an anonymous bundle
to the (as yet not-entirely-specified) bpecho service (which simply reflects
the bundle back to the source), the receiving node needs (I think) to be
able to interpret the source EID (ipn:0.0) as a valid well-formed EID,
and it will then find that there is no route to that endpoint. It
would be an implementation optimization to then simply not reply (or immediately
discard the reply) instead of trying to wait for a route to ipn:0.0 to
become available, which it should never do. Or, if a node is validating
the primary block of a bundle with an anonymous source, the bare fact that
it has an anonymous source shouldn’t cause the node to throw an error
(though security policy certainly might).</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
CCSDS BPv7 profile states that CCSDS implementations don’t need to be
able to source anonymous bundles (3.3.3), which might get at your question
above (why do we need them in the space context – we don’t, at least
we assert that implementations aren’t required to be able to generate
any). That leaves open the possibility that an implementation could
send anonymous bundles if it came up with a good reason to do so.</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">[As
a side note: I think dtn:none is left over from BPv6 and the current custodian
field. It doesn’t really make sense to use dtn:none as a report-to
EID, and certainly not as a destination EID.]</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"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">SLS-14</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:11pt;font-family:Calibri">We
tried to address this by renaming section 5 simply “Services BP Requires”.
I think this is in half-correct, in that in order to function correctly
the PROTOCOL needs a time source. The PROTOCOL doesn’t really need
storage, but any sane implementation does.</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">I
sort of like “<b>BP Node Requirements</b>” or “<b>Services Required
by BP Nodes</b>” (the BP agent is part of the node, and I could see someone
arguing that storage is required as part of the application agent to buffer
bundles for delivery to registrations that are in a passive state). I
suppose a contender would be “BP Implementation Requirements” but I think
I like ‘node’ better. <b>Anybody else have thoughts here?</b></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">Assuming
we go with ‘BP Node Requirements’ or ‘Services Required by BP Nodes’
as the title of section 5 and correct the text for -06, would that then
address all of your concerns?</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:240px"><span style=" font-size:12pt;font-family:Calibri"><b>From:
</b>Ignacio.Aguilar.Sanchez@esa.int <Ignacio.Aguilar.Sanchez@esa.int><b><br>
Date: </b>Tuesday, November 15, 2022 at 10:10 AM<b><br>
To: </b>Dr. Keith L Scott <kscott@mitre.org><b><br>
Cc: </b>Blanding, Beau T. (MSFC-HP27)[HOSC SERVICES CONTRACT] <beau.t.blanding@nasa.gov>,
sis-dtn@mailman.ccsds.org <sis-dtn@mailman.ccsds.org><b><br>
Subject: </b>[EXT] Re: PID responses for BPV7</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:10pt;font-family:Arial">Keith,</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Thank your for your e-mail.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
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><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
For the remaining ones, please find additional feedback.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
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><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
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. <br>
Perhaps you could explain what is the purpose of anonymous bundles and
why they are needed on a space mission context. <br>
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. <br>
But I guess this is not the current motivation behind their tolerance in
this standard. So I need some understanding here.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
What are they good for? Anonymous for whom?</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
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><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
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><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
But clearly that one has interoperability meaning as well.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
Hence, no need to define error codes at the service interface.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
Therefore, we can close this one as well.</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
PID SLS-14 is about being more clear on the boundaries and the subject
for the requirements provided in section 5.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
The so-called "System" seemed to me undefined, too open to interpretation.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
I wonder if what you are actually formulating in that section is a few
key requirements for a Bundle Protocol node (implementation).</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
Note for instance the very clear and specific subject used in requirement
5.1.1 (now 5.2.1): Bundle protocol node.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
Note as well "Bundle protocol agent" in 5.2.1 (now 5.3.1). <br>
Stating requirements for the "bundle protocol" instead would
not make much sense in my opinion.</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:10pt;font-family:Arial"><br>
They should have been an input from which this standard would have been
derived.</span><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Arial"><br>
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><span style=" font-size:11pt;font-family:Calibri"> </span><span style=" font-size:10pt;font-family:Arial"><br>
For instance, what about Bundle Protocol Node (and/or Agent) Requirements?</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Your thoughts?</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Kind regards,</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:10pt;font-family:Arial"><br>
Ignacio</span><span style=" font-size:11pt;font-family:Calibri"> <br>
<br>
</span><img src=cid:_1_0EC98FFC0EC97944004DC271C12588FC style="border:0px solid;"><span style=" font-size:12pt;font-family:Calibri">
</span><span style=" font-size:11pt;font-family:Calibri"> <br>
</span><span style=" font-size:9pt;color:#4f4f4f;font-family:NotesEsa"><b><br>
Ignacio Aguilar Sánchez</b></span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#4f4f4f;font-family:NotesEsa"><br>
Communication Systems Engineer</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#4f4f4f;font-family:NotesEsa"><br>
Electrical Engineering Department</span><span style=" font-size:11pt;font-family:Calibri">
<br>
</span><span style=" font-size:9pt;color:#4f4f4f;font-family:NotesEsa"><br>
European Space Research and Technology Centre<br>
Keplerlaan 1, PO Box 299, 2200 AG Noordwijk, The Netherlands</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#4f4f4f;font-family:NotesEsa"><br>
Tel. (31) 71 565 5695</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#4f4f4f;font-family:NotesEsa"><br>
Fax (31) 71 565 5418</span><span style=" font-size:11pt;font-family:Calibri">
</span><span style=" font-size:9pt;color:#4f4f4f;font-family:NotesEsa"><br>
Email: ignacio.aguilar.sanchez@esa.int</span><span style=" font-size:11pt;color:blue;font-family:Calibri"><u><br>
</u></span><a href=www.esa.int><span style=" font-size:9pt;color:blue;font-family:NotesEsa"><u>www.esa.int</u></span></a><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">"Dr.
Keith L Scott" <kscott@mitre.org></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">"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><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">14/11/2022
17:48</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">PID
responses for BPV7</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">Ignacio,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt"> </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:12pt;color:#0082bf"><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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">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:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">
v/r,</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt">
--keith</span></p>
<p style="margin-top:0px;margin-Bottom:0px"><span style=" font-size:12pt"> </span></p>
<p style="margin-top:0px;margin-Bottom:0px"><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 (dpo@esa.int).</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>