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-4Q9l2USxIAe6P8O4Zc > > > > * 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
