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
