[Sis-dtn] New version of BPv7 document

[Dr. Keith L Scott]

All,

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.


  1.  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.



  1.  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 *think* 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).


  1.  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:

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.

I also fixed the text of 2-1 (tenth paragraph) per Ignacio’s suggestion.  It now says:
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.


Let’s see if we can nail these down on tomorrow’s call.

                        v/r,

                        --keith

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20221116/01e51d20/attachment.htm>