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
