Hi all, We've capitalized the "Known" in "Well-Known" and replaced "greater than" with ">=" as described below:
https://www.iana.org/assignments/uri-schemes thanks, Amanda Baber IANA Operations Manager On Fri May 09 23:48:37 2025, kmo...@staff.rfc-editor.org wrote: > Dear IANA, > > Please update the "'ipn' Scheme URI Well-known Service Numbers for > BPv7” registry <https://www.iana.org/assignments/uri-schemes/> to > match the edited document at https://www.rfc- > editor.org/authors/rfc9758-diff.html as follows. > > 1) Update “known” to “Known” in the registry title: > > OLD: > 'ipn' Scheme URI Well-known Service Numbers for BPv7 > > NEW: > 'ipn' Scheme URI Well-Known Service Numbers for BPv7 > > 2) Update two instances of “greater than” to “>=": > > OLD: > greater than 0x100000000 > Reserved for future expansion > [RFC-ietf-dtn-ipn-update-14] > > NEW: > > =0x100000000 > Reserved for future expansion > [RFC-ietf-dtn-ipn-update-14] > > > Thank you in advance! > RFC Editor/kc > > > > Begin forwarded message: > > > > From: Karen Moore <kmo...@staff.rfc-editor.org> > > Subject: Re: [AD] [auth48] AUTH48: RFC-to-be 9758 <draft-ietf-dtn- > > ipn-update-14> for your review > > Date: May 9, 2025 at 2:11:54 PM PDT > > To: Erik Kline <ek.i...@gmail.com>, Rick Taylor > > <rtay...@aalyria.com>, "Birrane, Edward J." > > <edward.birr...@jhuapl.edu>, Rick Taylor > > <r...@tropicalstormsoftware.com> > > Cc: RFC Errata System <rfc-edi...@rfc-editor.org>, "dtn-...@ietf.org" > > <dtn-...@ietf.org>, "dtn-cha...@ietf.org" <dtn-cha...@ietf.org>, > > "sburleig...@gmail.com" <sburleig...@gmail.com>, auth48archive > > <auth48archive@rfc-editor.org> > > > > 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- > >>>>>>>>>>> a...@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-leave@rfc- > >>>>>>>>>>>>> editor.org > >>>>>>>>>>>>> > >>>>>>>>>>>>> <rfc9758.xml>-- > >>>>>>>>>>>>> auth48archive mailing list -- auth48archive@rfc- > >>>>>>>>>>>>> editor.org To > >>>>>>>>>>>>> unsubscribe send an email to auth48archive-leave@rfc- > >>>>>>>>>>>>> editor.org > >>>>>>>>>>>> > >>>>>>>>>>>> <rfc9758 (1).xml> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
