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
