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
