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
