Hi Karen, I believe Erik is on vacation until the end of this week, and I think he has sensibly stopped looking at email while he's away.
Cheers, Rick > -----Original Message----- > From: Karen Moore [mailto:kmo...@staff.rfc-editor.org] > Sent: 31 March 2025 19:14 > To: Erik Kline; Rick Taylor; Birrane, Edward J. > Cc: Rick Taylor; RFC Errata System; dtn-...@ietf.org; dtn-cha...@ietf.org; > sburleig...@gmail.com; auth48archive > Subject: [AD] re: [auth48] AUTH48: RFC-to-be 9758 <draft-ietf-dtn-ipn-update- > 14> for your review > > 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
