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
