<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=Windows-1252">
<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:NotesEsa;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Ignacio,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">-06<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">My sincere apologies for missing -06, will get on that. Ah, OK, I copied your ‘from’ text…<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Anonymous bundles:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">[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.]<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">SLS-14<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">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?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> v/r,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> --keith<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Ignacio.Aguilar.Sanchez@esa.int <Ignacio.Aguilar.Sanchez@esa.int><br>
<b>Date: </b>Tuesday, November 15, 2022 at 10:10 AM<br>
<b>To: </b>Dr. Keith L Scott <kscott@mitre.org><br>
<b>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><br>
<b>Subject: </b>[EXT] Re: PID responses for BPV7<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif">Keith,</span><span style="font-size:11.0pt">
<br>
<br>
</span><span style="font-family:"Arial",sans-serif">Thank your for your e-mail.</span><span style="font-size:11.0pt">
<br>
<br>
</span><span style="font-family:"Arial",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><span style="font-size:11.0pt">
<br>
<br>
</span><span style="font-family:"Arial",sans-serif">For the remaining ones, please find additional feedback.</span><span style="font-size:11.0pt">
<br>
<br>
</span><span style="font-family:"Arial",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><span style="font-size:11.0pt">
<br>
<br>
</span><span style="font-family:"Arial",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><span style="font-size:11.0pt"><br>
</span><span style="font-family:"Arial",sans-serif">Perhaps you could explain what is the purpose of anonymous bundles and why they are needed on a space mission context.
</span><span style="font-size:11.0pt"><br>
</span><span style="font-family:"Arial",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><span style="font-size:11.0pt"><br>
</span><span style="font-family:"Arial",sans-serif">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:11.0pt">
<br>
</span><span style="font-family:"Arial",sans-serif">What are they good for? Anonymous for whom?</span><span style="font-size:11.0pt">
<br>
<br>
</span><span style="font-family:"Arial",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><span style="font-size:11.0pt">
<br>
</span><span style="font-family:"Arial",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><span style="font-size:11.0pt">
<br>
</span><span style="font-family:"Arial",sans-serif">But clearly that one has interoperability meaning as well.</span><span style="font-size:11.0pt">
<br>
</span><span style="font-family:"Arial",sans-serif">Hence, no need to define error codes at the service interface.</span><span style="font-size:11.0pt">
<br>
</span><span style="font-family:"Arial",sans-serif">Therefore, we can close this one as well.</span><span style="font-size:11.0pt">
<br>
<br>
</span><span style="font-family:"Arial",sans-serif">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:11.0pt">
<br>
</span><span style="font-family:"Arial",sans-serif">The so-called "System" seemed to me undefined, too open to interpretation.</span><span style="font-size:11.0pt">
<br>
</span><span style="font-family:"Arial",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><span style="font-size:11.0pt">
<br>
</span><span style="font-family:"Arial",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><span style="font-size:11.0pt">
<br>
</span><span style="font-family:"Arial",sans-serif">Note as well "Bundle protocol agent" in 5.2.1 (now 5.3.1).
</span><span style="font-size:11.0pt"><br>
</span><span style="font-family:"Arial",sans-serif">Stating requirements for the "bundle protocol" instead would not make much sense in my opinion.</span><span style="font-size:11.0pt">
<br>
</span><span style="font-family:"Arial",sans-serif">They should have been an input from which this standard would have been derived.</span><span style="font-size:11.0pt">
<br>
</span><span style="font-family:"Arial",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><span style="font-size:11.0pt">
<br>
</span><span style="font-family:"Arial",sans-serif">For instance, what about Bundle Protocol Node (and/or Agent) Requirements?</span><span style="font-size:11.0pt">
<br>
<br>
</span><span style="font-family:"Arial",sans-serif">Your thoughts?</span><span style="font-size:11.0pt">
<br>
<br>
</span><span style="font-family:"Arial",sans-serif">Kind regards,</span><span style="font-size:11.0pt">
<br>
<br>
</span><span style="font-family:"Arial",sans-serif">Ignacio</span><span style="font-size:11.0pt">
<br>
<br>
<img width="92" height="33" style="width:.9583in;height:.3437in" id="_x0000_i1026" src="cid:_1_0A3693300A368F4C00532075C12588FB"></span><span style="font-size:12.0pt"> </span><span style="font-size:11.0pt">
<br>
<br>
</span><b><span style="font-size:9.0pt;font-family:"NotesEsa",serif;color:#4F4F4F">Ignacio Aguilar Sánchez</span></b><span style="font-size:11.0pt">
<br>
</span><span style="font-size:9.0pt;font-family:"NotesEsa",serif;color:#4F4F4F">Communication Systems Engineer</span><span style="font-size:11.0pt">
<br>
</span><span style="font-size:9.0pt;font-family:"NotesEsa",serif;color:#4F4F4F">Electrical Engineering Department</span><span style="font-size:11.0pt">
<br>
<br>
</span><span style="font-size:9.0pt;font-family:"NotesEsa",serif;color:#4F4F4F">European Space Research and Technology Centre<br>
Keplerlaan 1, PO Box 299, 2200 AG Noordwijk, The Netherlands</span><span style="font-size:11.0pt">
<br>
</span><span style="font-size:9.0pt;font-family:"NotesEsa",serif;color:#4F4F4F">Tel. (31) 71 565 5695</span><span style="font-size:11.0pt">
<br>
</span><span style="font-size:9.0pt;font-family:"NotesEsa",serif;color:#4F4F4F">Fax (31) 71 565 5418</span><span style="font-size:11.0pt">
<br>
</span><span style="font-size:9.0pt;font-family:"NotesEsa",serif;color:#4F4F4F">Email: ignacio.aguilar.sanchez@esa.int<br>
</span><span style="font-size:11.0pt"><a href="www.esa.int"><span style="font-size:9.0pt;font-family:"NotesEsa",serif">www.esa.int</span></a>
<br>
<br>
<br>
<br>
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">From: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">"Dr. Keith L Scott" <kscott@mitre.org></span><span style="font-size:11.0pt">
<br>
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">To: </span><span style="font-size:9.0pt;font-family:"Arial",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><span style="font-size:11.0pt">
<br>
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Date: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">14/11/2022 17:48</span><span style="font-size:11.0pt">
<br>
</span><span style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#5F5F5F">Subject: </span><span style="font-size:9.0pt;font-family:"Arial",sans-serif">PID responses for BPV7</span><span style="font-size:11.0pt">
<o:p></o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:11.0pt">
<hr size="0" width="100%" noshade="" style="color:#A0A0A0" align="center">
</span></div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p style="margin:0in">Ignacio,<o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in">The sis-dtn working group has reviewed your PIDs on the draft BPv7 Red Book.<o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in">A spreadsheet with the dispositions as well as a marked-up document are available from the Google Drive Folder here:<o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in"><a href="https://drive.google.com/drive/folders/1q1bS7VfNsLfh55GwKvy6Eza_Q1FoU4Kn?usp=share_link"><span style="color:#0082BF">https://drive.google.com/drive/folders/1q1bS7VfNsLfh55GwKvy6Eza_Q1FoU4Kn?usp=share_link</span></a><o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in">And I can send you snapshots if that’s difficult to access.<o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in">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.<o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in"> v/r,<o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<p style="margin:0in"> --keith<o:p></o:p></p>
<p style="margin:0in"> <o:p></o:p></p>
<pre>This message is intended only for the recipient(s) named above. It may contain proprietary information and/or<o:p></o:p></pre>
<pre>protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received<o:p></o:p></pre>
<pre>this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect<o:p></o:p></pre>
<pre>personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo@esa.int).<o:p></o:p></pre>
</div>
</body>
</html>