<html 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)">
<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;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{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;}
/* List Definitions */
@list l0
{mso-list-id:697003984;
mso-list-type:hybrid;
mso-list-template-ids:1876974164 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l1
{mso-list-id:992221237;
mso-list-template-ids:-1282248458;}
@list l2
{mso-list-id:1343505793;
mso-list-template-ids:1429243568;}
@list l2:level1
{mso-level-start-at:2;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3
{mso-list-id:1615597747;
mso-list-template-ids:-1082504996;}
@list l3:level1
{mso-level-start-at:3;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Comments inline (>> and in blue) below.<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"> 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">Shames, Peter M (US 312B) <peter.m.shames@jpl.nasa.gov><br>
<b>Date: </b>Wednesday, November 16, 2022 at 7:35 PM<br>
<b>To: </b>Dr. Keith L Scott <kscott@mitre.org>, sis-dtn@mailman.ccsds.org <sis-dtn@mailman.ccsds.org><br>
<b>Cc: </b>Howie Weiss <howard.weiss@parsons.com>, Torgerson, J. Leigh (US 332C) <jordan.l.torgerson@jpl.nasa.gov>, EXTERNAL-Birrane, Edward J (US 9300-Affiliate) <Edward.Birrane@jhuapl.edu><br>
<b>Subject: </b>Re: [EXTERNAL] New version of CCSDS BPv7 document<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">Keith, et al,<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 promised I have read through the revised CCSDS BPv7 document. Most of my concerns have been satisfactorily addressed by these changes. Thanks. There are still a few dangling participles, highlighted
in yellow. In some cases these are items that appear in a sidebar note, but do not appear to have been addressed in the revised text. Perhaps they are still under discussion?<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">There is still, in my mind, something of a disconnect in the text, and in the SANA registries, between the CBHE Node Numbers registry (https://beta.sanaregistry.org/r/bp_cbhe_node_numbers/) , which records
a CCSDS org that has been assigned a block of what are potentially thousands of node numbers, and the specific node ID assigned to a unique, deployed, node. This version of the doc states (in revised sec D2) that the node ID(s) for any node that offers DTN
services shall be registered, by the SANA, in the Site Services portion of the Service Site and Apertures (SS&A) Registry entry for that Site. This does require action by the Agency Representative for that Service Site and this must be clarified.<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">However, what is missing is the linkage between the specific Node ID, allocated within the CBHE block of Node IDs assigned to an Agency, and the association of that specific Node ID with the SS&A entry. Someone
has to make that allocation of the Node ID from the block and associate it with the deployed Node, as registered in the SS&A registry. This could, in these early days, be the equivalent of the HOSTS.TXT file that was used in the early Internet, but it seems
prudent to have some globally accessible way to document which Node IDs have been assigned and the SS&A entries they are associated with. This role could be assigned to the SANA, or it could be required of each of the Agencies assigned CBHE Node ID blocks,
but IMHO someone ought to do it and curate it in some globally accessible location. Presumably, at least in the early days, this will be a slowly moving target.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#2F5597;mso-style-textfill-fill-color:#2F5597;mso-style-textfill-fill-alpha:100.0%">>> OK, so some statement in D2 to the effect of: When instantiating a new BP Node at a sites, the Agency Representative
MAY request additional node IDs from SANA if needed. Once an agency has received node assignments is then the responsibility of the agency to internally manage the node numbers assigned to it. When a new node is to be instantiated at a site, the agency should
internally assign one of its node IDs and add it to the list of NodeIDs for the site.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#2F5597;mso-style-textfill-fill-color:#2F5597;mso-style-textfill-fill-alpha:100.0%"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#2F5597;mso-style-textfill-fill-color:#2F5597;mso-style-textfill-fill-alpha:100.0%">>> My thought was that the proposed BP Node IDs portion of the SS&A registry would *<b>be</b>* the globally (for folks
who have access to the SS&A registry) way to document allocation of nodes and the binding between node IDs and sites. If one were to query the SS&A registry for all the node ID assignments, that would effectively be the hosts file. External entities really
don’t need to (I don’t think) have visibility into what’s happening with ALL the nodes allocated to an agency, but just those that show up in the SS&A registry (assumed to be potential connectivity opportunities). Allowing agencies to get ranges and then
manage those ranges internally, exposing those that need exposure through the SS&A registry, seems like it would be more efficient.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#2F5597;mso-style-textfill-fill-color:#2F5597;mso-style-textfill-fill-alpha:100.0%"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#2F5597;mso-style-textfill-fill-color:#2F5597;mso-style-textfill-fill-alpha:100.0%">>> Are you saying that you want to document ALL of the node IDs assigned to a particular agency? So that if an agency
is allocated #s X—Y we have an ‘operational’ POC for every node in that range?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#2F5597;mso-style-textfill-fill-color:#2F5597;mso-style-textfill-fill-alpha:100.0%"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#2F5597;mso-style-textfill-fill-color:#2F5597;mso-style-textfill-fill-alpha:100.0%">>> Am I misunderstanding your request?<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;color:#2F5597;mso-style-textfill-fill-color:#2F5597;mso-style-textfill-fill-alpha:100.0%"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Regards, Peter<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>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">Keith Scott <kscott@mitre.org><br>
<b>Date: </b>Wednesday, November 16, 2022 at 1:41 PM<br>
<b>To: </b>"sis-dtn@mailman.ccsds.org" <sis-dtn@mailman.ccsds.org><br>
<b>Cc: </b>Peter Shames <peter.m.shames@jpl.nasa.gov>, Howie Weiss <howard.weiss@parsons.com>, Leigh Torgerson <jordan.l.torgerson@jpl.nasa.gov>, "EXTERNAL-Birrane, Edward J (US 9300-Affiliate)" <Edward.Birrane@jhuapl.edu><br>
<b>Subject: </b>[EXTERNAL] New version of BPv7 document</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt">All,<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">After some discussions w/ Peter and emails w/ Ignacio,I propose we use the current version of the document from the Google Drive site to close out the PIDs and to be the object of a resolution to put the document
out for another round of CESG review. I unfortunately did NOT turn on ‘suggesting’ mode (track changes) but the differences between this and the last versions we discussed are small and summarized here.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo3"><span style="font-size:11.0pt">There is a new subsection at the end of section 2 (after the other 2 new subsections for BPsec and Network Management) that is the roadmap for ‘how to
add a new BP node into an existing network’. This subsection is designed to address Peter’s concerns that we be up-front with folks that there is a fair amount of human-in-the-loop coordination / configuration needed to stand up a new node and get it stitched
into the network. The procedure in the new subsection leverages extensions to the SANA Service Site and Apertures registry to include a list of BP Node Identifiers in the Site portions of the registry for those sites that support BP services.<o:p></o:p></span></li></ol>
<p class="MsoListParagraph"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<ol style="margin-top:0in" start="2" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo3"><span style="font-size:11.0pt">Annex C has also been modified to include the request that SANA include a list of Node Identifiers for such sites in the SS&A registry. I *<b>think</b>*
we’ll need to wait for SANA to add that field to the BETA registries before the document can go out for re-poll to the CESG (at least that’s how I recall the rules).<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<ol style="margin-top:0in" start="3" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo3"><span style="font-size:11.0pt">There was a fair amount of discussion about anonymous bundles and why one would ever have such a thing. I believe that the primary motivation for dtn:none
was left over from custody transfer in bpv6 where the current custodian was a mandatory part of the primary block, so we needed a way to say ‘there is no current custodian’. There was desire to remove support for dtn:none entirely; I’ve sort of loathe to
do that because we may be (hopefully eventually WILL be) part of a larger DTN network that includes all sorts of folks who MIGHT be using dtn:none for something useful (though I have no idea what that might be). I ended up with the following:<o:p></o:p></span></li></ol>
<p class="MsoNormal"><span style="font-size:11.0pt"> <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:1.0in"><span style="font-size:11.0pt">3.2.2 Implementations of this specification are not required to support bundles whose source, destination, or report-to endpoint identifiers use the dtn URI scheme in RFC 9171.<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 also fixed the text of 2-1 (tenth paragraph) per Ignacio’s suggestion. It now says:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:12.0pt;color:black">Deep space missions often carry constraints regarding the amount of equipment they can support on the satellite. Spacecraft telecommunication resources are generally optimized
to ensure the prevailing instrument data download requirements. The result of this resource optimization is an asymmetric, sometimes even simplex, link between the satellite and the receiver.</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Let’s see if we can nail these down on tomorrow’s call.</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> v/r,</span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><span style="font-size:11.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> --keith</span><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>
</div>
</body>
</html>