Hi Karen, et. al. Thanks for all your hard work. I approve of all the changes.
Cheers, Rick Rick Taylor Tech Lead Manager UK www.aalyria.com On Thu, 15 May 2025 at 19:10, Karen Moore <kmo...@staff.rfc-editor.org> wrote: > Dear Rick and Ed, > > IANA has completed the updates to the "'ipn' Scheme URI Well-known Service > Numbers for > BPv7” registry. Please note that in Tables 2, 4, and 6, we updated the > range ">= 2^32" to ">=0x100000000" to exactly match the IANA registries. > Please let us know of any objections. > > If there are no objections, we will begin the publication process. > > Thank you to all for your time and for working closely with us on this > document! > > --FILES (please refresh)-- > The updated XML file is here: > https://www.rfc-editor.org/authors/rfc9758.xml > > The updated output files are here: > https://www.rfc-editor.org/authors/rfc9758.txt > https://www.rfc-editor.org/authors/rfc9758.pdf > https://www.rfc-editor.org/authors/rfc9758.html > > These diff files show all changes made during AUTH48: > https://www.rfc-editor.org/authors/rfc9758-auth48diff.html > https://www.rfc-editor.org/authors/rfc9758-auth48rfcdiff.html (side by > side) > > These diff files show changes made during the last edit round: > https://www.rfc-editor.org/authors/rfc9758-lastdiff.html > https://www.rfc-editor.org/authors/rfc9758-lastrfcdiff.html (side by side) > > These diff files show all changes made to date: > https://www.rfc-editor.org/authors/rfc9758-diff.html > https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by side) > > Best regards, > RFC Editor/kc > > > > On May 9, 2025, at 2:11 PM, Karen Moore <kmo...@staff.rfc-editor.org> > wrote: > > > > Hi Erik, > > > > Thank you for providing your approval; we have noted it on the AUTH48 > status page for this document (https://www.rfc-editor.org/auth48/rfc9758). > > > > We will now ask IANA to update their registries to match the document. > We will inform you when those actions are complete. > > > > Best regards, > > RFC Editor/kc > > > > On May 9, 2025, at 1:34 PM, Erik Kline <ek.i...@gmail.com> wrote: > > > > LGTM, thank you! > > > > Section 5.6 reads more clearly now, thank you. > > > > Apologies for the delay. > > > > Thanks to folks for the various cattle prodding. :-) > > > > > > > > Hi Erik (AD), > > > > The authors have provided their approvals of this document, and this is > a friendly reminder that we still await your approval of the update to > Section 5.6. The change can be viewed below as well as in this file: > https://www.rfc-editor.org/authors/rfc9758-auth48diff.html. > > > > Section 5.6 > > > > Orignal: > > It is convenient for BPv7 services that have a public specification > > and wide adoption to be identified by a pre-agreed default Service > > Number, so that unless extra configurations are applied, such > > services can be sensibly assumed to be operating on the well-known > > Service Number on a particular node. > > > > Current: > > It is convenient for BPv7 services that have a public specification > > and wide adoption to be identified by a pre-agreed default Service > > Number, so that unless overridden by explicit configuration, such > > services can be sensibly assumed to be operating on the well-known > > Service Number on a particular node. > > > > --FILES (please refresh)-- > > The updated XML file is here: > > https://www.rfc-editor.org/authors/rfc9758.xml > > > > The updated output files are here: > > https://www.rfc-editor.org/authors/rfc9758.txt > > https://www.rfc-editor.org/authors/rfc9758.pdf > > https://www.rfc-editor.org/authors/rfc9758.html > > > > These diff files show all changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9758-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9758-auth48rfcdiff.html (side by > side) > > > > These diff files show only the changes made during the last edit round: > > https://www.rfc-editor.org/authors/rfc9758-lastdiff.html > > https://www.rfc-editor.org/authors/rfc9758-lastrfcdiff.html (side by > side) > > > > These diff files show all changes made to date: > > https://www.rfc-editor.org/authors/rfc9758-diff.html > > https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by side) > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9758 > > > > Best regards, > > RFC Editor/kc > > > > On Apr 28, 2025, at 1:00 PM, Karen Moore <kmo...@staff.rfc-editor.org> > wrote: > > > > Hi Erik (AD), > > > > The authors have provided their approvals of this document, and this is > a friendly reminder that we still await your approval of the update to > Section 5.6. The change can be viewed below as well as in this file: > https://www.rfc-editor.org/authors/rfc9758-auth48diff.html. > > > > Section 5.6 > > > > Orignal: > > It is convenient for BPv7 services that have a public specification > > and wide adoption to be identified by a pre-agreed default Service > > Number, so that unless extra configurations are applied, such > > services can be sensibly assumed to be operating on the well-known > > Service Number on a particular node. > > > > Current: > > It is convenient for BPv7 services that have a public specification > > and wide adoption to be identified by a pre-agreed default Service > > Number, so that unless overridden by explicit configuration, such > > services can be sensibly assumed to be operating on the well-known > > Service Number on a particular node. > > > > --FILES (please refresh)-- > > The updated XML file is here: > > https://www.rfc-editor.org/authors/rfc9758.xml > > > > The updated output files are here: > > https://www.rfc-editor.org/authors/rfc9758.txt > > https://www.rfc-editor.org/authors/rfc9758.pdf > > https://www.rfc-editor.org/authors/rfc9758.html > > > > These diff files show all changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9758-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9758-auth48rfcdiff.html (side by > side) > > > > These diff files show only the changes made during the last edit round: > > https://www.rfc-editor.org/authors/rfc9758-lastdiff.html > > https://www.rfc-editor.org/authors/rfc9758-lastrfcdiff.html (side by > side) > > > > These diff files show all changes made to date: > > https://www.rfc-editor.org/authors/rfc9758-diff.html > > https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by side) > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9758 > > > > Best regards, > > RFC Editor/kc > > > > On Apr 17, 2025, at 3:19 PM, Karen Moore <kmo...@staff.rfc-editor.org> > wrote: > > > > Hi Erik, > > > > This is a friendly reminder that we still await your approval of the > update in Section 5.6. The change can be viewed below as well as in this > file: https://www.rfc-editor.org/authors/rfc9758-auth48diff.html. > > > > Section 5.6 > > > > Orignal: > > It is convenient for BPv7 services that have a public specification > > and wide adoption to be identified by a pre-agreed default Service > > Number, so that unless extra configurations are applied, such > > services can be sensibly assumed to be operating on the well-known > > Service Number on a particular node. > > > > Current: > > It is convenient for BPv7 services that have a public specification > > and wide adoption to be identified by a pre-agreed default Service > > Number, so that unless overridden by explicit configuration, such > > services can be sensibly assumed to be operating on the well-known > > Service Number on a particular node. > > > > Best regards, > > RFC Editor/kc > > > > On Apr 9, 2025, at 10:49 AM, Karen Moore <kmo...@staff.rfc-editor.org> > wrote: > > > > Hi Erik, > > > > This is a friendly reminder that we await your approval of the update in > Section 5.6. The change can be viewed below as well as in this file: > https://www.rfc-editor.org/authors/rfc9758-auth48diff.html. > > > > Best regards, > > RFC Editor/kc > > > > On Mar 31, 2025, at 11:14 AM, Karen Moore <kmo...@staff.rfc-editor.org> > wrote: > > > > Hi Erik, > > > > This is a reminder that we await your approval of the change to Section > 5.6. The update can be viewed below as well as in this file: > https://www.rfc-editor.org/authors/rfc9758-auth48diff.html. > > > > Section 5.6 > > > > Orignal: > > It is convenient for BPv7 services that have a public specification > > and wide adoption to be identified by a pre-agreed default Service > > Number, so that unless extra configurations are applied, such > > services can be sensibly assumed to be operating on the well-known > > Service Number on a particular node. > > > > Current: > > It is convenient for BPv7 services that have a public specification > > and wide adoption to be identified by a pre-agreed default Service > > Number, so that unless overridden by explicit configuration, such > > services can be sensibly assumed to be operating on the well-known > > Service Number on a particular node. > > > > > > --FILES (please refresh)-- > > The updated XML file is here: > > https://www.rfc-editor.org/authors/rfc9758.xml > > > > The updated output files are here: > > https://www.rfc-editor.org/authors/rfc9758.txt > > https://www.rfc-editor.org/authors/rfc9758.pdf > > https://www.rfc-editor.org/authors/rfc9758.html > > > > These diff files show all changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9758-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9758-auth48rfcdiff.html (side by > side) > > > > These diff files show only the changes made during the last edit round: > > https://www.rfc-editor.org/authors/rfc9758-lastdiff.html > > https://www.rfc-editor.org/authors/rfc9758-lastrfcdiff.html (side by > side) > > > > These diff files show all changes made to date: > > https://www.rfc-editor.org/authors/rfc9758-diff.html > > https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by side) > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9758 > > > > Best regards, > > RFC Editor/kc > > > > > > On Mar 25, 2025, at 11:23 AM, Karen Moore <kmo...@staff.rfc-editor.org> > wrote: > > > > Hi Rick, > > > > We have noted your approval on the AUTH48 status page ( > https://www.rfc-editor.org/auth48/rfc9758). > > > > We now await Erik’s approval of the change in Section 5.6. > > > > Best regards, > > RFC Editor/kc > > > > On Mar 25, 2025, at 5:36 AM, Rick Taylor <r...@tropicalstormsoftware.com> > wrote: > > > > Hi All, > > > > Sorry for the delay. I approve of the changes. > > > > Cheers, > > Rick > > > > -----Original Message----- > > From: Karen Moore [mailto:kmo...@staff.rfc-editor.org] > > Sent: 24 March 2025 21:21 > > To: Birrane, Edward J.; Erik Kline; Rick Taylor > > Cc: RFC Errata System; dtn-...@ietf.org; dtn-cha...@ietf.org; > > sburleig...@gmail.com; auth48archive > > Subject: Re: [EXT] [auth48] AUTH48: RFC-to-be 9758 <draft-ietf-dtn-ipn- > > update-14> for your review > > > > Hi Ed and *Erik (AD), > > > > Thank you for your reply. We have updated our files accordingly, and we > have > > noted your approval of the document. > > > > We now await approvals from Rick and Erik. Once received, we will ask > IANA to > > update their registries to match the edited document. > > > > Clarification: > > 1) Note that we updated eight instances of "2 Element ipn EID > scheme-specific > > encoding” (and “3 Element...”) to “2-Element ipn EID encoding” for > > consistency (even though only 2 of those lines were over the character > limit). If > > that is not desired and you would like to only adjust the two lines that > are over > > the character limit, please let us know. > > > > *Erik, please review the change to Section 5.6 and let us know if you > approve. > > The update can be viewed below as well as in this file: https://www.rfc- > > editor.org/authors/rfc9758-auth48diff.html. > > > > Section 5.6 > > > > Orignal: > > It is convenient for BPv7 services that have a public specification > > and wide adoption to be identified by a pre-agreed default Service > > Number, so that unless extra configurations are applied, such > > services can be sensibly assumed to be operating on the well-known > > Service Number on a particular node. > > > > Current: > > It is convenient for BPv7 services that have a public specification > > and wide adoption to be identified by a pre-agreed default Service > > Number, so that unless overridden by explicit configuration, such > > services can be sensibly assumed to be operating on the well-known > > Service Number on a particular node. > > > > > > --FILES (please refresh)-- > > The updated XML file is here: > > https://www.rfc-editor.org/authors/rfc9758.xml > > > > The updated output files are here: > > https://www.rfc-editor.org/authors/rfc9758.txt > > https://www.rfc-editor.org/authors/rfc9758.pdf > > https://www.rfc-editor.org/authors/rfc9758.html > > > > These diff files show all changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9758-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9758-auth48rfcdiff.html (side by > side) > > > > These diff files show only the changes made during the last edit round: > > https://www.rfc-editor.org/authors/rfc9758-lastdiff.html > > https://www.rfc-editor.org/authors/rfc9758-lastrfcdiff.html (side by > side) > > > > These diff files show all changes made to date: > > https://www.rfc-editor.org/authors/rfc9758-diff.html > > https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by side) > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9758 > > > > Thank you! > > RFC Editor/kc > > > > > > On Mar 21, 2025, at 10:25 PM, Birrane, Edward J. > > <edward.birr...@jhuapl.edu> wrote: > > > > Hello editors! > > > > I concur/approve of the changes to the document, with the following > specific > > comments (pulled to the top for ease of reference): > > > > > > #2) <!--[rfced] Edward, we understand that in other RFCs (RFCs 9171, > > 9172, and 9173), your preference was to list your name as "E. Birrane, > III" > > on the first page and "Edward J. Birrane, III" in the Authors' > > Addresses section. Please let us know if you would you like to do > > the same in this document for consistency. > > —> > > > > Yes, please keep my name consistent with RFC9171 (and others). > > > > #10) <!--[rfced] In Section 6.1.1 and Appendix B.2, "# 2 Element ipn > > EID scheme-specific encoding" is 1 character over the 72-character > > limit. Please let us know how you would like to update the spacing > > within the sourcecode figures. > > > > [RT]: @Ed, are you happy to compress "2 Element ipn EID scheme-specific > > encoding" > > to "2 Element ipn EID encoding" to fit? > > > > Yes, happy to compress this to "2 Element ipn EID encoding". > > > > #12) <!-- [rfced] In the text below, should "such as the use of" > > read as "such as with the use of"? > > > > Original: > > > > In both cases (and indeed in all bundle processing), the node that > > receives a bundle should verify its authenticity and validity > > before operating on it in any way, such as the use of BPSec > > [RFC9172], and TCPCLv4 with TLS [RFC9174]. > > > > Perhaps: > > > > In both cases (and indeed in all bundle processing), the node that > > receives a bundle should verify its authenticity and validity > > before operating on it in any way, such as with the use of BPSec > > [RFC9172] and TCP Convergence Layer version 4 (TCPCLv4) with TLS > > [RFC9174]. > > —> > > > > [RT]: I don't mind either way, the original is my personal preference, > > but the meaning is kept intact. @Ed? > > > > I think the proposed text "such as with the use of" is clearer and > recommend > > we adopt. > > > > -Ed > > > > > > -----Original Message----- > > From: Karen Moore <kmo...@staff.rfc-editor.org> > > Sent: Friday, March 21, 2025 7:42 PM > > To: Rick Taylor <rtay...@aalyria.com>; Birrane, Edward J. > > <edward.birr...@jhuapl.edu> > > Cc: RFC Errata System <rfc-edi...@rfc-editor.org>; dtn-...@ietf.org; > dtn- > > cha...@ietf.org; sburleig...@gmail.com; Erik Kline <ek.i...@gmail.com>; > > auth48archive <auth48archive@rfc-editor.org> > > Subject: [EXT] Re: [auth48] AUTH48: RFC-to-be 9758 <draft-ietf-dtn-ipn- > > update-14> for your review > > > > APL external email warning: Verify sender kmo...@staff.rfc-editor.org > > before clicking links or attachments > > > > Hi Rick, > > > > Thank you for providing the second updated XML file. The changes are now > > reflected in our files. We have also removed the linked terms (so only > the > > section numbers are linked). Please review the text and let us know if > any > > further changes are needed. > > > > We now await Ed’s reply and approval from each author prior to moving > > forward with publication. > > > > —FILES (please refresh)-- > > The updated XML file is here: > > https://www.rfc-editor.org/authors/rfc9758.xml > > > > The updated output files are here: > > https://www.rfc-editor.org/authors/rfc9758.txt > > https://www.rfc-editor.org/authors/rfc9758.pdf > > https://www.rfc-editor.org/authors/rfc9758.html > > > > These diff files show all changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9758-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9758-auth48rfcdiff.html (side by > side) > > > > These diff files show only the changes made during the last edit round: > > https://www.rfc-editor.org/authors/rfc9758-lastdiff.html > > https://www.rfc-editor.org/authors/rfc9758-lastrfcdiff.html (side by > side) > > > > These diff files show all changes made to date: > > https://www.rfc-editor.org/authors/rfc9758-diff.html > > https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by side) > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9758 > > > > Thank you! > > RFC Editor/kc > > > > On Mar 20, 2025, at 10:40 PM, Rick Taylor <rtay...@aalyria.com> wrote: > > > > Hi Editors, > > > > I attach an updated XML with a small adjustment to table 7. Other > > comments inline... > > > > Cheers, > > Rick > > > > > > > > Rick Taylor > > Tech Lead Manager UK > > > > www.aalyria.com > > > > > > On Fri, 21 Mar 2025 at 07:24, Karen Moore <kmo...@staff.rfc-editor.org> > > wrote: > > Hi Rick, > > > > Thank you for your reply and the updated XML file. We have updated our > > files based on your comments; see the updated files below. We have some > > additional questions/clarifications. > > > > 1) Note that we removed the section titles that were linked (currently, > only > > the section numbers are linked). We left instances where a term and the > > section number were both linked as is. Please review and let us know if > this is > > agreeable or if you would like to also remove the linked terms and have > only > > the section numbers linked. > > > > This is fine by me. The previous long form was an artefact of the > markdown > > tools we have used. > > > > > > 2) We added a hyphen to ‘ipn’ as follows; please review the text and let > us > > know if any further changes are needed. > > > > ipn URI scheme -> ‘ipn’ URI scheme (throughout the text) > > ipn scheme URIs -> 'ipn' scheme URIs (8 instances) > > ipn scheme -> 'ipn' scheme (3 instances: Sections 7.1, 8.3, and 9) > > > > Note that we updated “IPN URI scheme” to "‘ipn’ URI scheme" in the > > examples in Sections 6.1.1 and 6.1.2 and Appendices B.1, B.2, and B.3. > Please > > let us know if that is not correct. > > > > This all looks correct, and I assume you mean you added single quotes. > > > > > > 3) Regarding the question below, we did not make any changes as we > > believe your comment meant the current text is agreeable. If any changes > are > > needed, please let us know. > > > > f.) In Tables 2, 4, 6, and 7, we assume that ">= 2^32" is the same > > as ">=0x100000000" in the IANA registries. Are any changes desired > > in the document to make this consistent with the IANA registries, or > > will this variance be clear to readers? > > > > [RT]: We hope this is clear to readers. Happy with the change > > > > No further changes required. > > > > > > > > 4) FYI: In Appendices B1, B2, and B3, we added a hyphen to a few > instances > > of “2 Element” and “3 Element” for consistency. > > > > Perfect > > > > > > 5) FYI: We didn’t make any changes to the use of “<tt>” in the document. > If > > any changes are desired, please let us know. > > > > I spotted one correction which I have made in the attached XML. > > > > > > 6) We will await a reply from Ed for the following three questions: > > > > #2) <!--[rfced] Edward, we understand that in other RFCs (RFCs 9171, > > 9172, and 9173), your preference was to list your name as "E. Birrane, > III" > > on the first page and "Edward J. Birrane, III" in the Authors' > > Addresses section. Please let us know if you would you like to do > > the same in this document for consistency. > > —> > > > > ... > > #10) <!--[rfced] In Section 6.1.1 and Appendix B.2, "# 2 Element ipn > > EID scheme-specific encoding" is 1 character over the 72-character > > limit. Please let us know how you would like to update the spacing > > within the sourcecode figures. > > > > Current > > Section 6.1.1: > > 82 # 2-Element Endpoint Encoding > > 02 # uri-code: 2 (IPN URI scheme) > > 82 # 2 Element ipn EID scheme-specific encoding > > 1B 000EE86800000064 # Fully-Qualified Node Number > > 01 # Service Number > > > > Appendix B.1: > > 82 # 2-Element Endpoint Encoding > > 02 # uri-code: 2 (IPN URI scheme) > > 82 # 2 Element ipn EID scheme-specific encoding > > 1B 000EE86800000001 # Fully-Qualified Node Number > > 01 # Service Number > > —> > > > > [RT]: @Ed, are you happy to compress "2 Element ipn EID scheme-specific > > encoding" > > to "2 Element ipn EID encoding" to fit? > > > > ... > > #12) <!-- [rfced] In the text below, should "such as the use of" > > read as "such as with the use of"? > > > > Original: > > > > In both cases (and indeed in all bundle processing), the node that > > receives a bundle should verify its authenticity and validity > > before operating on it in any way, such as the use of BPSec > > [RFC9172], and TCPCLv4 with TLS [RFC9174]. > > > > Perhaps: > > > > In both cases (and indeed in all bundle processing), the node that > > receives a bundle should verify its authenticity and validity > > before operating on it in any way, such as with the use of BPSec > > [RFC9172] and TCP Convergence Layer version 4 (TCPCLv4) with TLS > > [RFC9174]. > > —> > > > > [RT]: I don't mind either way, the original is my personal preference, > > but the meaning is kept intact. @Ed? > > ... > > > > --FILES-- > > The updated XML file is here: > > https://www.rfc-editor.org/authors/rfc9758.xml > > > > The updated output files are here: > > https://www.rfc-editor.org/authors/rfc9758.txt > > https://www.rfc-editor.org/authors/rfc9758.pdf > > https://www.rfc-editor.org/authors/rfc9758.html > > > > These diff files show all changes made during AUTH48: > > https://www.rfc-editor.org/authors/rfc9758-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9758-auth48rfcdiff.html (side > > by side) > > > > These diff files show all changes made to date: > > https://www.rfc-editor.org/authors/rfc9758-diff.html > > https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by > > side) > > > > Note that it may be necessary for you to refresh your browser to view the > > most recent version. Please review the document carefully to ensure > > satisfaction as we do not make changes once it has been published as an > RFC. > > > > Please contact us with any further updates or with your approval of the > > document in its current form. We will await approvals from each author > prior > > to moving forward in the publication process. > > > > For the AUTH48 status of this document, please see: > > https://www.rfc-editor.org/auth48/rfc9758 > > > > Best regards, > > RFC Editor/kc > > > > On Mar 19, 2025, at 9:23 PM, Rick Taylor via auth48archive > > <auth48archive@rfc-editor.org> wrote: > > > > Hi Editors, > > > > Firstly thank you so much for the editorial pass, it greatly improves > > readability, and I appreciate the hard work. > > > > I attach an updated XML file with 3 minor proposed changes, and I'll > > reply to questions inline below.Cheers, Rick > > > > > > > > > > On Thu, 20 Mar 2025 at 08:24, <rfc-edi...@rfc-editor.org> wrote: > > Authors, > > > > While reviewing this document during AUTH48, please resolve (as > > necessary) the following questions, which are also in the XML file. > > > > 1) <!--[rfced] To more closely match the document title, we updated > > the short title that spans the header of the PDF file as follows. Please > let us > > know of any objections. > > > > Original: > > > > ipn-updates > > > > Current: > > > > ipn Updates > > > > --> > > > > Perhaps ipn Update (singular)? > > > > > > 2) <!--[rfced] Edward, we understand that in other RFCs (RFCs 9171, > > 9172, and 9173), your preference was to list your name as "E. Birrane, > III" > > on the first page and "Edward J. Birrane, III" in the Authors' > > Addresses section. Please let us know if you would you like to do > > the same in this document for consistency. > > > > --> > > > > > > 3) <!-- [rfced] Throughout the document, specific terms and section > > titles are linked/referenced. To help the reader differentiate > > between the two, we added quote marks to the section titles; > > however, please consider if removing the section titles and > > providing links to the section numbers only would be helpful for > > ease of reading and to avoid any confusion. For example: > > > > Current (with terms and section titles/numbers linked): > > > > Both LocalNode (Section 3.4.2) and Private Use (Section 3.4.3) ipn > > URIs present a risk to the stability of deployed BPv7 networks... > > > > See "LocalNode ipn EIDs" (Section 5.4) and "Private Use ipn EIDs" > > (Section 5.5) for required behaviors to mitigate against this form of > > abuse. > > > > Perhaps (with terms and section numbers linked): > > > > Both LocalNode (Section 3.4.2) and Private Use (Section 3.4.3) ipn > > URIs present a risk to the stability of deployed BPv7 networks... > > > > See Sections 5.4 and 5.5 for required behaviors to mitigate against > > this form of abuse. > > > > --> > > > > This is an artefact of the markdown tooling we have used, I think the > > proposed change is good. > > > > > > > > 4) <!-- [rfced] FYI - For readability, we have updated the text > > below as a bulleted list. Please review and let us know any objections. > > > > Original: > > > > Specifically, this document > > introduces a hierarchical structure for the assignment of ipn scheme > > URIs, clarifies the behavior and interpretation of ipn scheme URIs, > > defines efficient encodings of ipn scheme URIs, and updates/defines > > the registries associated for this scheme. > > > > Current: > > > > Specifically, this document: > > > > * introduces a hierarchical structure for the assignment of ipn > > scheme URIs, > > > > * clarifies the behavior and interpretation of ipn scheme URIs, > > > > * defines efficient encodings of ipn scheme URIs, and > > > > * updates/defines the registries associated with this scheme. > > > > --> > > > > I think this improves readability, so I'm happy. > > > > > > > > 5) <!-- [rfced] Is "range" meant to be singular (option A) or plural > > (option B) in the text below? > > > > Original: > > > > If a system does not require interoperable deployment of ipn scheme > > URIs, then the Private Use Node Numbers (Section 3.4.3) range, > > reserved by the Default Allocator (Section 3.2.2) for this purpose, > > are to be used. > > > > Perhaps A: > > > > If a system does not require interoperable deployment of ipn scheme > > URIs, then the Private Use Node Numbers (Section 3.4.3) range, > > reserved by the Default Allocator (Section 3.2.2) for this purpose, > > is to be used. > > > > or > > > > Perhaps B: > > > > If a system does not require interoperable deployment of ipn scheme > > URIs, then a range of Private Use Node Numbers (Section 3.4.3), > > reserved by the Default Allocator (Section 3.2.2) for this purpose, > > are to be used. > > --> > > > > As a native British english speaker, I prefer (A). > > > > 6) <!-- [rfced] For ease of the reader, we have broken up the text > > below. Please review. > > > > Original: > > > > Rather than assigning unique Allocator Identifiers to each sub- > > organization on a first-come first-served basis, there are > > operational benefits in assigning Allocator Identifiers to such an > > organization in a structured way so that an external observer can > > detect that a group of Allocator Identifiers are organizationally > > associated. > > > > Current: > > > > Rather than assigning unique Allocator Identifiers to each sub- > > organization on a first-come, first-served basis, there are operational > > benefits in assigning Allocator Identifiers to such an organization in a > > structured way. This allows an external observer to detect > > that a group of Allocator Identifiers is organizationally associated. > > > > --> > > > > Yes, much better > > > > 7) <!--[rfced] FYI - In all of the tables, we have aligned the > > content to the left (instead of centering some columns) for > > consistency and easy reading. If this is not preferred, please let us > know. > > > > --> > > I didn't really notice the difference, so obviously an improvement. > > Consistency with the RFC editorial style is what we are aiming for. > > > > > > 8) <!-- [rfced] May we clarify what specifications the following > > text refers to and also rework the last sentence to make clear that > > an RFC (rather than a > > protocol) defines this registry? > > > > Original: > > > > The IRTF BPv6 experimental specification termed the logical source or > > destination of a bundle as an "Endpoint" identified by an "Endpoint > > Identifier" (EID). BPv6 EIDs are formatted as URIs. This definition and > > representation of EIDs was carried forward from the IRTF BPv6 > > specification > > to the IETF BPv7 specification. BPv7 additionally defined an IANA > registry > > called the "Bundle Protocol URI Scheme Types" registry... > > > > Perhaps: > > > > The IRTF BPv6 experimental specification [RFC5050] termed the logical > > source or destination of a bundle as an "Endpoint" identified by an > > "Endpoint Identifier" (EID). BPv6 EIDs are formatted as URIs. This > > definition and representation of EIDs was carried forward from the IRTF > > BPv6 specification [RFC5050] to the IETF BPv7 specification [RFC9171]. > > [RFC9171] additionally defined an IANA registry called the "Bundle > > Protocol > > URI Scheme Types" registry... > > > > --> > > Yes that makes more sense. I think we originally were worried of > > having too many references, but this is definitely clearer. The > > situation is currently a mess, and this doc is trying to clear it up > > ;) > > > > > > 9) <!-- [rfced] In the instances below, does "security source" read > > as redundant after "Bundle Protocol Security"? > > > > Original: > > > > For example, a LocalNode ipn EID MUST NOT be used as a Bundle > > Protocol Security [RFC9172] security source for a bundle > > transmitted from the local bundle node, because such a source EID > > would have no meaning at a downstream bundle node. > > > > For example, a Private Use ipn EID MUST NOT be used as a Bundle > > Protocol > > Security [RFC9172] security source for a bundle, when the bundle is > > destined for a different administrative domain. > > > > Perhaps: > > > > For example, a LocalNode ipn EID MUST NOT be used as a > > source of Bundle Protocol Security (BPSec) [RFC9172] for a bundle > > transmitted from the local bundle node, because such a source EID > > would have no meaning at a downstream bundle node. > > > > For example, a Private Use ipn EID MUST NOT be used as a source of > > BPSec [RFC9172] for a bundle when the bundle is destined for a > > different administrative domain. > > > > --> > > No, please keep the original. A "Security Source" is a very > > specific field in BPSec, so although the "Bundle Protocol Security > > Security Source" sounds wrong, it's actually accurate > > > > > > 10) <!--[rfced] In Section 6.1.1 and Appendix B.2, "# 2 Element ipn > > EID scheme-specific encoding" is 1 character over the 72-character > > limit. Please let us know how you would like to update the spacing > > within the sourcecode figures. > > > > Current > > Section 6.1.1: > > 82 # 2-Element Endpoint Encoding > > 02 # uri-code: 2 (IPN URI scheme) > > 82 # 2 Element ipn EID scheme-specific encoding > > 1B 000EE86800000064 # Fully-Qualified Node Number > > 01 # Service Number > > > > Appendix B.1: > > 82 # 2-Element Endpoint Encoding > > 02 # uri-code: 2 (IPN URI scheme) > > 82 # 2 Element ipn EID scheme-specific encoding > > 1B 000EE86800000001 # Fully-Qualified Node Number > > 01 # Service Number > > > > --> > > > > @Ed: Are you happy to compress "2 Element ipn EID scheme-specific > > encoding" to "2 Element ipn EID encoding" to fit? > > > > 11) <!-- [rfced] FYI - We have adjusted the text below to read as a > > numbered list. Please review and let us know any objections. > > > > Original: > > > > In the three-element scheme-specific encoding of an ipn EID, the > > first element of the array is the Allocator Identifier, the second > > element of the array is the Node Number, and the third element of the > > array is the Service Number. > > > > Current: > > > > In the three-element scheme-specific encoding of an ipn EID: > > > > 1. the first element of the array is the Allocator Identifier, > > > > 2. the second element of the array is the Node Number, and > > > > 3. the third element of the array is the Service Number. > > > > --> > > I like a numbered list. > > > > > > 12) <!-- [rfced] In the text below, should "such as the use of" read > > as "such as with the use of"? > > > > Original: > > > > In both cases (and indeed in all bundle processing), the node that > > receives a bundle should verify its authenticity and validity > > before operating on it in any way, such as the use of BPSec > > [RFC9172], and TCPCLv4 with TLS [RFC9174]. > > > > Perhaps: > > > > In both cases (and indeed in all bundle processing), the node that > > receives a bundle should verify its authenticity and validity > > before operating on it in any way, such as with the use of BPSec > > [RFC9172] and TCP Convergence Layer version 4 (TCPCLv4) with TLS > > [RFC9174]. > > > > --> > > I don't mind either way, the original is my personal preference, but the > > meaning is kept intact. @Ed? > > > > > > 13) <!-- [rfced] We have included some specific questions about the > > IANA text below. In addition to responding to those questions, > > please review all of the IANA-related updates carefully and let us > > know if any further updates are needed. Note that the registries can > > be viewed at <https://www.iana.org/assignments/uri-schemes/>. > > > > a.) We note different capitalization and use of quotation marks > > around "Private Use" in the running text. We have removed the quote > > marks for consistency as the policies of RFC 8126 usually appear as > > uppercase without quote marks. > > > > Perfect, let's use the correct way of using the words. > > > > > > b.) The registration procedures in Table 4 do not match the > > registration procedures for the "'ipn' Scheme URI Default Allocator Node > > Numbers" > > registry. We updated the reference entries accordingly (see Tables 4 and > > 5). > > Please review and let us know if any further changes are needed. > > > > I think Table 4 and 5 are an improvement, but I would drop the duplicate > > "Invalid" final row from Table 5. > > > > c.) FYI: We have made "Well-Known" uppercase in the "'ipn' Scheme > > URI Well-Known Service Numbers for BPv7" registry name, and we will > > ask IANA to make this change prior to publication. > > > > Fine by me > > > > d.) We updated Tables 6 and 7 to match the "'ipn' Scheme URI > > Well-Known Service Numbers for BPv7" registry. Please let us know if > > any further changes are needed. > > > > I'm not sure I like the duplication of the "Reserved for..." entries in > Table 7. > > If the entries are reserved in table 6, why are they 'initial' in Table > 7? > > > > e.) In Tables 2, 4, and 6, we updated "Registration Policy" to > > "Registration Procedures" in the column headings to match the > > respective IANA registries. In the running text, may we update > > instances of "registration policies" to "registration procedures" > > for consistency? > > > > Fine by me > > > > f.) In Tables 2, 4, 6, and 7, we assume that ">= 2^32" is the same > > as ">=0x100000000" in the IANA registries. Are any changes desired > > in the document to make this consistent with the IANA registries, or > > will this variance be clear to readers? > > > > We hope this is clear to readers. Happy with the change > > > > i.) We note the following variances in the IANA registries. Should > > these be made consistent by replacing "greater than" with ">="? > > > > In the "'ipn' Scheme URI Allocator Identifiers" and "'ipn' Scheme > > URI Default Allocator Node Numbers" registries: > > > > ">=0x100000000" > > > > In the "'ipn' Scheme URI Well-Known Service Numbers for BPv7" > > registry: > > > > "greater than 0x100000000" > > > > Happy with >= instead of "greathan or equal to". > > > > ii.) FYI: In Table 5, we replaced ">= 2^32" with ">=4294967296" > > ("Invalid") to match the "'ipn' Scheme URI Default Allocator Node > > Numbers" registry. Please let us know if this is not correct > > > > It's correct, but 2^32 might be easier on the eye than the very long > string > > of digits. > > . > > > > --> > > > > > > 14) <!-- [rfced] Please review the following comments related to XML > > formatting: > > > > a.) In the html and pdf outputs, the text enclosed in <tt> is output > > in fixed-width font. In the txt output, there are no changes to the > > font, and the quotation marks are removed. Please review carefully > > and let us know if the output is acceptable or if any updates are needed. > > > > This is an artefact of the markdown tooling we have used. Please format > > as appropriate. > > > > b.) Please review each <artwork> element and let us know if any > > should be marked as <sourcecode> (or another element) instead. > > > > We have already updated several <artwork> elements to <sourcecode>. > > Please confirm these updates are correct and whether the "type" > > attribute of any <sourcecode> element should be set and/or has been > > set correctly. > > > > The current list of preferred values for "type" is available at > > <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. > > If the current list does not contain an applicable type, feel free > > to suggest additions for consideration. Note that it is also > > acceptable to leave the "type" attribute not set. > > > > Having checked, the changes look correct. > > > > c.) Please review whether the note in Section 6.3 should be in the > > <aside> element. It is defined as "a container for content that is > > semantically less important or tangential to the content that > > surrounds it" (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > > --> > > > > No, this isn't an aside, it is semantically important, more of an NB > than a > > side-note. > > > > > > 15) <!-- [rfced] Errata exist for both RFCs 7116 and 9171. Please > > review the errata for these RFCs and confirm that none are relevant > > to the content of this document: > > > > RFC 7116: <https://www.rfc-editor.org/errata_search.php?rfc=7116> > > RFC 9171: <https://www.rfc-editor.org/errata_search.php?rfc=9171> > > > > --> > > > > We are aware of the Errata, and this doc is designed to address some of > > them. > > > > > > 16) <!-- [rfced] Please review the following questions and changes > > regarding the terminology used in this document: > > > > a.) In the RFC series, "Fully Qualified Domain Name (FQDN)" > > typically appears as uppercase without a hyphen. Would you like to > > remove the hyphen from the expansion of "Fully-Qualified Node Number" > > for consistency with the series? > > > > My only preference is consistency. > > > > > > Additionally, after the first expansion of "FQNN", may we replace > > instances of "Fully-Qualified Node Number" with the acronym (per > > guidance in "Web Portion of the Style Guide" at > > <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>)? > > > > Yes, if it meets the guidelines, please do. > > > > b.) We note some variances with the terms below in the example > > schemes. Should any of the occurrences in the example schemes be > > updated for consistency (hyphen or no hyphen)? > > > > 2 Element vs. 2-Element vs. > > 3 Element > > > > One example (Appendix B.1): > > > > 82 # 2-Element Endpoint Encoding > > 02 # uri-code: 2 (IPN URI scheme) > > 83 # 3 Element ipn EID scheme-specific encoding > > 1A 000EE868 # Allocator Identifier > > 01 # Node Number > > 01 # Service Number > > > > Yes they should. > > > > b.) We note different capitalization and quotation marks for 'null' > > and Null in the instances below. Please let us know if/how may we > > update for consistency. > > > > Null ipn URI (term in IANA registry) > > 5.2. The Null Endpoint > > B.3. The 'null' Endpoint > > > > 'null' ipn URI > > 'null' ipn EID > > 'null' endpoint > > 'null' EID > > > > > > Given the IANA registry precedent, and my preference, I think Null is > > better than 'null'. > > > > c.) Would you like either double (") or single (') quotes to appear > > around ipn scheme? We note different usage across RFCs. > > > > As used in this document: > > ipn URI scheme > > > > As used in the IANA registry names: > > 'ipn' scheme > > > > Usage from RFC 6260: > > the "ipn" scheme > > > > Usage from RFC 7116: > > 'ipn' URI scheme > > > > Let's use the single quotes, if that's the usual way of referring to a > URI > > scheme in an RFC. > > > > > > d.) We note different formatting of "0" as seen below. For > > consistency with the rest of this document, should any of these > > instances be updated to "zero (0)" and should the <tt> tags be > > removed? (We note that "Default Allocator" has a value of "0" in the > > "'ipn' Scheme URI Allocator Identifiers" registry.) > > > > ... the least-significant N bits of the first Allocator Identifier MUST > > be all 0. > > > > Correct > > > > ... a range of bit-length 0 > > > > Correct > > > > All leading <tt>0</tt> characters MUST be omitted. A single '<tt>0</tt>' > > is valid. > > > > Correct > > > > Consider the ipn URI identifying Service Number 2 on Node Number 1 > > allocated by the Default Allocator (0) (Section 3.2.2). > > > > Correct > > > > Consider the ipn EID ipn:1.1. This textual representation of an ipn > > EID identifies Service Number 1 on Node Number 1 allocated by the > > Default Allocator (0) (Section 3.2.2). > > > > This should be <tt>ipn:1.1</tt>, but the other uses are correct. > > > > We have attempted to differentiate between the number 0 and the > > explicit ASCII character 0, and this is important when talking about > textual > > representation vs a numeric value or count. When dealing with a 'count' > then > > "... zero (0) ..." seems the correct usage, unless it results in > multiple nested > > parantheses, in which case "(0)" seems best. When dealing with a numeric > > value, 0 seems correct, when dealing with the character or sequence of > > characters <tt> is correct. > > > > > > e.) Because CBOR expands to Concise Binary Object Representation > > (CBOR), would "CBOR representation" be redundant in the instances > > below? > > > > 6. CBOR representation of ipn URIs with BPv7 . . . . . . . . 15 > > 7.2. CBOR Representation Interoperability . . . . . . . . . . 19 > > CBOR representation (2 instances in the running text) > > > > No please leave as is. "CBOR representation" is the common usage, > > despite the odd expansion. > > > > f.) FYI - We have added expansions for abbreviations upon first use > > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > > expansion in the document carefully to ensure correctness. > > > > Concise Binary Object Representation (CBOR) > > TCP Convergence Layer version 4 (TCPCLv4) > > > > Perfect, they got missed in our paragraph shuffling. > > > > --> > > > > > > 17) <!-- [rfced] Please review the "Inclusive Language" portion of > > the online Style Guide > > <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > > and let us know if any changes are needed. Updates of this nature > > typically result in more precise language, which is helpful for readers. > > > > Note that our script did not flag any words in particular, but this > > should still be reviewed as a best practice. --> > > > > Excellent, we tried to be inclusive. > > > > > > Thank you. > > > > RFC Editor/kf/kc > > > > > > > > On Mar 19, 2025, at 6:20 PM, RFC Editor via auth48archive > > <auth48archive@rfc-editor.org> wrote: > > > > *****IMPORTANT***** > > > > Updated 2025/03/19 > > > > RFC Author(s): > > -------------- > > > > Instructions for Completing AUTH48 > > > > Your document has now entered AUTH48. Once it has been reviewed and > > approved by you and all coauthors, it will be published as an RFC. > > If an author is no longer available, there are several remedies > > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > > > You and you coauthors are responsible for engaging other parties > > (e.g., Contributors or Working Group) as necessary before providing > > your approval. > > > > Planning your review > > --------------------- > > > > Please review the following aspects of your document: > > > > * RFC Editor questions > > > > Please review and resolve any questions raised by the RFC Editor > > that have been included in the XML file as comments marked as > > follows: > > > > <!-- [rfced] ... --> > > > > These questions will also be sent in a subsequent email. > > > > * Changes submitted by coauthors > > > > Please ensure that you review any changes submitted by your > > coauthors. We assume that if you do not speak up that you > > agree to changes submitted by your coauthors. > > > > * Content > > > > Please review the full content of the document, as this cannot > > change once the RFC is published. Please pay particular attention to: > > - IANA considerations updates (if applicable) > > - contact information > > - references > > > > * Copyright notices and legends > > > > Please review the copyright notice and legends as defined in > > RFC 5378 and the Trust Legal Provisions > > (TLP – https://trustee.ietf.org/license-info). > > > > * Semantic markup > > > > Please review the markup in the XML file to ensure that elements of > > content are correctly tagged. For example, ensure that <sourcecode> > > and <artwork> are set correctly. See details at > > <https://authors.ietf.org/rfcxml-vocabulary>. > > > > * Formatted output > > > > Please review the PDF, HTML, and TXT files to ensure that the > > formatted output, as generated from the markup in the XML file, is > > reasonable. Please note that the TXT will have formatting > > limitations compared to the PDF and HTML. > > > > > > Submitting changes > > ------------------ > > > > To submit changes, please reply to this email using ‘REPLY ALL’ as > > all the parties CCed on this message need to see your changes. The > > parties > > include: > > > > * your coauthors > > > > * rfc-edi...@rfc-editor.org (the RPC team) > > > > * other document participants, depending on the stream (e.g., > > IETF Stream participants are your working group chairs, the > > responsible ADs, and the document shepherd). > > > > * auth48archive@rfc-editor.org, which is a new archival mailing list > > to preserve AUTH48 conversations; it is not an active discussion > > list: > > > > * More info: > > > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2US > > xIAe6P8O4Zc > > > > * The archive itself: > > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > > > * Note: If only absolutely necessary, you may temporarily opt out > > of the archiving of messages (e.g., to discuss a sensitive matter). > > If needed, please add a note at the top of the message that you > > have dropped the address. When the discussion is concluded, > > auth48archive@rfc-editor.org will be re-added to the CC list and > > its addition will be noted at the top of the message. > > > > You may submit your changes in one of two ways: > > > > An update to the provided XML file > > — OR — > > An explicit list of changes in this format > > > > Section # (or indicate Global) > > > > OLD: > > old text > > > > NEW: > > new text > > > > You do not need to reply with both an updated XML file and an > > explicit list of changes, as either form is sufficient. > > > > We will ask a stream manager to review and approve any changes that > > seem beyond editorial in nature, e.g., addition of new text, > > deletion of text, and technical changes. Information about stream > > managers can be found in the FAQ. Editorial changes do not require > > approval from a stream manager. > > > > > > Approving for publication > > -------------------------- > > > > To approve your RFC for publication, please reply to this email > > stating that you approve this RFC for publication. Please use > > ‘REPLY ALL’, as all the parties CCed on this message need to see your > > approval. > > > > > > Files > > ----- > > > > The files are available here: > > https://www.rfc-editor.org/authors/rfc9758.xml > > https://www.rfc-editor.org/authors/rfc9758.html > > https://www.rfc-editor.org/authors/rfc9758.pdf > > https://www.rfc-editor.org/authors/rfc9758.txt > > > > Diff file of the text: > > https://www.rfc-editor.org/authors/rfc9758-diff.html > > https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by > > side) > > > > Diff of the XML: > > https://www.rfc-editor.org/authors/rfc9758-xmldiff1.html > > > > > > Tracking progress > > ----------------- > > > > The details of the AUTH48 status of your document are here: > > https://www.rfc-editor.org/auth48/rfc9758 > > > > Please let us know if you have any questions. > > > > Thank you for your cooperation, > > > > RFC Editor > > > > -------------------------------------- > > RFC9758 (draft-ietf-dtn-ipn-update-14) > > > > Title : Update to the ipn URI scheme > > Author(s) : R. Taylor, E. Birrane > > WG Chair(s) : Edward J. Birrane, Rick Taylor > > Area Director(s) : Erik Kline, Éric Vyncke > > > > > > -- > > auth48archive mailing list -- auth48archive@rfc-editor.org To > > unsubscribe send an email to auth48archive-le...@rfc-editor.org > > > > <rfc9758.xml>-- > > auth48archive mailing list -- auth48archive@rfc-editor.org To > > unsubscribe send an email to auth48archive-le...@rfc-editor.org > > > > <rfc9758 (1).xml> > > > > > > > > > > > > > > > > > > > > > > > > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
