<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=utf-8">
<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:11.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:11.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:822694642;
        mso-list-template-ids:-1276320498;}
@list l1:level1
        {mso-level-start-at:3;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;}
@list l2
        {mso-list-id:1302223245;
        mso-list-template-ids:2064147272;}
@list l3
        {mso-list-id:1955867094;
        mso-list-template-ids:1540634172;}
@list l3:level1
        {mso-level-start-at:2;
        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">Keith, et al,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards, Peter<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></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<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">All,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo3">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></li></ol>
<p class="MsoListParagraph"><o:p> </o:p></p>
<ol style="margin-top:0in" start="2" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo3">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></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" start="3" type="1">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo3">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></li></ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.0in">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></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I also fixed the text of 2-1 (tenth paragraph) per Ignacio’s suggestion.  It now says:<o:p></o:p></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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">                        v/r,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">                        --keith<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>