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
