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
