Hi Erik,

Thank you for providing your approval; we have noted it on the AUTH48 status 
page for this document (https://www.rfc-editor.org/auth48/rfc9758).

We will now ask IANA to update their registries to match the document.  We will 
inform you when those actions are complete.

Best regards,
RFC Editor/kc

> On May 9, 2025, at 1:34 PM, Erik Kline <ek.i...@gmail.com> wrote:
> 
> LGTM, thank you!
> 
> Section 5.6 reads more clearly now, thank you.
> 
> Apologies for the delay.
> 
> Thanks to folks for the various cattle prodding.  :-)


> 
> Hi Erik (AD),
> 
> The authors have provided their approvals of this document, and this is a 
> friendly reminder that we still await your approval of the update to Section 
> 5.6. The change can be viewed below as well as in this file: 
> https://www.rfc-editor.org/authors/rfc9758-auth48diff.html.
> 
> Section 5.6
> 
> Orignal:
> It is convenient for BPv7 services that have a public specification
> and wide adoption to be identified by a pre-agreed default Service
> Number, so that unless extra configurations are applied, such
> services can be sensibly assumed to be operating on the well-known
> Service Number on a particular node.
> 
> Current:
> It is convenient for BPv7 services that have a public specification
> and wide adoption to be identified by a pre-agreed default Service
> Number, so that unless overridden by explicit configuration, such
> services can be sensibly assumed to be operating on the well-known
> Service Number on a particular node.
> 
> --FILES (please refresh)--
> The updated XML file is here:
> https://www.rfc-editor.org/authors/rfc9758.xml
> 
> The updated output files are here:
> https://www.rfc-editor.org/authors/rfc9758.txt
> https://www.rfc-editor.org/authors/rfc9758.pdf
> https://www.rfc-editor.org/authors/rfc9758.html
> 
> These diff files show all changes made during AUTH48:
> https://www.rfc-editor.org/authors/rfc9758-auth48diff.html
> https://www.rfc-editor.org/authors/rfc9758-auth48rfcdiff.html (side by side)
> 
> These diff files show only the changes made during the last edit round:
> https://www.rfc-editor.org/authors/rfc9758-lastdiff.html
> https://www.rfc-editor.org/authors/rfc9758-lastrfcdiff.html (side by side)
> 
> These diff files show all changes made to date:
> https://www.rfc-editor.org/authors/rfc9758-diff.html
> https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by side)
> 
> For the AUTH48 status of this document, please see:
> https://www.rfc-editor.org/auth48/rfc9758
> 
> Best regards,
> RFC Editor/kc
>> 
>>> On Apr 28, 2025, at 1:00 PM, Karen Moore <kmo...@staff.rfc-editor.org> 
>>> wrote:
>>> 
>>> Hi Erik (AD),
>>> 
>>> The authors have provided their approvals of this document, and this is a 
>>> friendly reminder that we still await your approval of the update to 
>>> Section 5.6. The change can be viewed below as well as in this file: 
>>> https://www.rfc-editor.org/authors/rfc9758-auth48diff.html.
>>> 
>>> Section 5.6
>>> 
>>> Orignal:
>>> It is convenient for BPv7 services that have a public specification
>>> and wide adoption to be identified by a pre-agreed default Service
>>> Number, so that unless extra configurations are applied, such
>>> services can be sensibly assumed to be operating on the well-known
>>> Service Number on a particular node.
>>> 
>>> Current:
>>> It is convenient for BPv7 services that have a public specification
>>> and wide adoption to be identified by a pre-agreed default Service
>>> Number, so that unless overridden by explicit configuration, such
>>> services can be sensibly assumed to be operating on the well-known
>>> Service Number on a particular node.
>>> 
>>> --FILES (please refresh)--
>>> The updated XML file is here:
>>> https://www.rfc-editor.org/authors/rfc9758.xml
>>> 
>>> The updated output files are here:
>>> https://www.rfc-editor.org/authors/rfc9758.txt
>>> https://www.rfc-editor.org/authors/rfc9758.pdf
>>> https://www.rfc-editor.org/authors/rfc9758.html
>>> 
>>> These diff files show all changes made during AUTH48:
>>> https://www.rfc-editor.org/authors/rfc9758-auth48diff.html
>>> https://www.rfc-editor.org/authors/rfc9758-auth48rfcdiff.html (side by side)
>>> 
>>> These diff files show only the changes made during the last edit round:
>>> https://www.rfc-editor.org/authors/rfc9758-lastdiff.html
>>> https://www.rfc-editor.org/authors/rfc9758-lastrfcdiff.html (side by side)
>>> 
>>> These diff files show all changes made to date:
>>> https://www.rfc-editor.org/authors/rfc9758-diff.html
>>> https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by side)
>>> 
>>> For the AUTH48 status of this document, please see:
>>> https://www.rfc-editor.org/auth48/rfc9758
>>> 
>>> Best regards,
>>> RFC Editor/kc
>>> 
>>>> On Apr 17, 2025, at 3:19 PM, Karen Moore <kmo...@staff.rfc-editor.org> 
>>>> wrote:
>>>> 
>>>> Hi Erik,
>>>> 
>>>> This is a friendly reminder that we still await your approval of the 
>>>> update in Section 5.6. The change 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.
>>>> 
>>>> Best regards,
>>>> RFC Editor/kc
>>>> 
>>>>> On Apr 9, 2025, at 10:49 AM, Karen Moore <kmo...@staff.rfc-editor.org> 
>>>>> wrote:
>>>>> 
>>>>> Hi Erik,
>>>>> 
>>>>> This is a friendly reminder that we await your approval of the update in 
>>>>> Section 5.6. The change can be viewed below as well as in this file: 
>>>>> https://www.rfc-editor.org/authors/rfc9758-auth48diff.html.
>>>>> 
>>>>> Best regards,
>>>>> RFC Editor/kc
>>>>> 
>>>>>> On Mar 31, 2025, at 11:14 AM, Karen Moore <kmo...@staff.rfc-editor.org> 
>>>>>> wrote:
>>>>>> 
>>>>>> Hi Erik,
>>>>>> 
>>>>>> This is a reminder that we await your approval of the change to Section 
>>>>>> 5.6. The update can be viewed below as well as in this file: 
>>>>>> https://www.rfc-editor.org/authors/rfc9758-auth48diff.html.
>>>>>> 
>>>>>> Section 5.6
>>>>>> 
>>>>>> Orignal:
>>>>>> It is convenient for BPv7 services that have a public specification
>>>>>> and wide adoption to be identified by a pre-agreed default Service
>>>>>> Number, so that unless extra configurations are applied, such
>>>>>> services can be sensibly assumed to be operating on the well-known
>>>>>> Service Number on a particular node.
>>>>>> 
>>>>>> Current:
>>>>>> It is convenient for BPv7 services that have a public specification
>>>>>> and wide adoption to be identified by a pre-agreed default Service
>>>>>> Number, so that unless overridden by explicit configuration, such
>>>>>> services can be sensibly assumed to be operating on the well-known
>>>>>> Service Number on a particular node.
>>>>>> 
>>>>>> 
>>>>>> --FILES (please refresh)--
>>>>>> The updated XML file is here:
>>>>>> https://www.rfc-editor.org/authors/rfc9758.xml
>>>>>> 
>>>>>> The updated output files are here:
>>>>>> https://www.rfc-editor.org/authors/rfc9758.txt
>>>>>> https://www.rfc-editor.org/authors/rfc9758.pdf
>>>>>> https://www.rfc-editor.org/authors/rfc9758.html
>>>>>> 
>>>>>> These diff files show all changes made during AUTH48:
>>>>>> https://www.rfc-editor.org/authors/rfc9758-auth48diff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9758-auth48rfcdiff.html (side by 
>>>>>> side)
>>>>>> 
>>>>>> These diff files show only the changes made during the last edit round:
>>>>>> https://www.rfc-editor.org/authors/rfc9758-lastdiff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9758-lastrfcdiff.html (side by 
>>>>>> side)
>>>>>> 
>>>>>> These diff files show all changes made to date:
>>>>>> https://www.rfc-editor.org/authors/rfc9758-diff.html
>>>>>> https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by side)
>>>>>> 
>>>>>> For the AUTH48 status of this document, please see:
>>>>>> https://www.rfc-editor.org/auth48/rfc9758
>>>>>> 
>>>>>> Best regards,
>>>>>> RFC Editor/kc
>>>>>> 
>>>>>> 
>>>>>>> On Mar 25, 2025, at 11:23 AM, Karen Moore <kmo...@staff.rfc-editor.org> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> Hi Rick,
>>>>>>> 
>>>>>>> We have noted your approval on the AUTH48 status page 
>>>>>>> (https://www.rfc-editor.org/auth48/rfc9758).
>>>>>>> 
>>>>>>> We now await Erik’s approval of the change in Section 5.6.
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> RFC Editor/kc
>>>>>>> 
>>>>>>>> On Mar 25, 2025, at 5:36 AM, Rick Taylor 
>>>>>>>> <r...@tropicalstormsoftware.com> wrote:
>>>>>>>> 
>>>>>>>> Hi All,
>>>>>>>> 
>>>>>>>> Sorry for the delay.  I approve of the changes.
>>>>>>>> 
>>>>>>>> Cheers,
>>>>>>>> Rick
>>>>>>>> 
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Karen Moore [mailto:kmo...@staff.rfc-editor.org]
>>>>>>>>> Sent: 24 March 2025 21:21
>>>>>>>>> To: Birrane, Edward J.; Erik Kline; Rick Taylor
>>>>>>>>> Cc: RFC Errata System; dtn-...@ietf.org; dtn-cha...@ietf.org;
>>>>>>>>> sburleig...@gmail.com; auth48archive
>>>>>>>>> Subject: Re: [EXT] [auth48] AUTH48: RFC-to-be 9758 
>>>>>>>>> <draft-ietf-dtn-ipn-
>>>>>>>>> update-14> for your review
>>>>>>>>> 
>>>>>>>>> Hi Ed and *Erik (AD),
>>>>>>>>> 
>>>>>>>>> Thank you for your reply. We have updated our files accordingly, and 
>>>>>>>>> we have
>>>>>>>>> noted your approval of the document.
>>>>>>>>> 
>>>>>>>>> We now await approvals from Rick and Erik. Once received, we will ask 
>>>>>>>>> IANA to
>>>>>>>>> update their registries to match the edited document.
>>>>>>>>> 
>>>>>>>>> Clarification:
>>>>>>>>> 1) Note that we updated eight instances of "2 Element ipn EID 
>>>>>>>>> scheme-specific
>>>>>>>>> encoding” (and “3 Element...”) to “2-Element ipn EID encoding” for
>>>>>>>>> consistency (even though only 2 of those lines were over the 
>>>>>>>>> character limit). If
>>>>>>>>> that is not desired and you would like to only adjust the two lines 
>>>>>>>>> that are over
>>>>>>>>> the character limit, please let us know.
>>>>>>>>> 
>>>>>>>>> *Erik, please review the change to Section 5.6 and let us know if you 
>>>>>>>>> approve.
>>>>>>>>> The update can be viewed below as well as in this file: 
>>>>>>>>> https://www.rfc-
>>>>>>>>> editor.org/authors/rfc9758-auth48diff.html.
>>>>>>>>> 
>>>>>>>>> Section 5.6
>>>>>>>>> 
>>>>>>>>> Orignal:
>>>>>>>>> It is convenient for BPv7 services that have a public specification
>>>>>>>>> and wide adoption to be identified by a pre-agreed default Service
>>>>>>>>> Number, so that unless extra configurations are applied, such
>>>>>>>>> services can be sensibly assumed to be operating on the well-known
>>>>>>>>> Service Number on a particular node.
>>>>>>>>> 
>>>>>>>>> Current:
>>>>>>>>> It is convenient for BPv7 services that have a public specification
>>>>>>>>> and wide adoption to be identified by a pre-agreed default Service
>>>>>>>>> Number, so that unless overridden by explicit configuration, such
>>>>>>>>> services can be sensibly assumed to be operating on the well-known
>>>>>>>>> Service Number on a particular node.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --FILES (please refresh)--
>>>>>>>>> The updated XML file is here:
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.xml
>>>>>>>>> 
>>>>>>>>> The updated output files are here:
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.txt
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.pdf
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.html
>>>>>>>>> 
>>>>>>>>> These diff files show all changes made during AUTH48:
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-auth48diff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-auth48rfcdiff.html (side 
>>>>>>>>> by side)
>>>>>>>>> 
>>>>>>>>> These diff files show only the changes made during the last edit 
>>>>>>>>> round:
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-lastdiff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-lastrfcdiff.html (side by 
>>>>>>>>> side)
>>>>>>>>> 
>>>>>>>>> These diff files show all changes made to date:
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-diff.html
>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by side)
>>>>>>>>> 
>>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9758
>>>>>>>>> 
>>>>>>>>> Thank you!
>>>>>>>>> RFC Editor/kc
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Mar 21, 2025, at 10:25 PM, Birrane, Edward J.
>>>>>>>>> <edward.birr...@jhuapl.edu> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hello editors!
>>>>>>>>>> 
>>>>>>>>>> I concur/approve of the changes to the document, with the following 
>>>>>>>>>> specific
>>>>>>>>> comments (pulled to the top for ease of reference):
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>>> #2) <!--[rfced] Edward, we understand that in other RFCs (RFCs 
>>>>>>>>>>>> 9171,
>>>>>>>>>>>> 9172, and 9173), your preference was to list your name as "E. 
>>>>>>>>>>>> Birrane, III"
>>>>>>>>>>>> on the first page and "Edward J. Birrane, III" in the Authors'
>>>>>>>>>>>> Addresses section. Please let us know if you would you like to do
>>>>>>>>>>>> the same in this document for consistency.
>>>>>>>>>>>> —>
>>>>>>>>>> 
>>>>>>>>>> Yes, please keep my name consistent with RFC9171 (and others).
>>>>>>>>>> 
>>>>>>>>>>>> #10) <!--[rfced] In Section 6.1.1 and Appendix B.2, "# 2 Element 
>>>>>>>>>>>> ipn
>>>>>>>>>>>> EID scheme-specific encoding" is 1 character over the 72-character
>>>>>>>>>>>> limit.  Please let us know how you would like to update the spacing
>>>>>>>>>>>> within the sourcecode figures.
>>>>>>>>>>> 
>>>>>>>>>>> [RT]: @Ed, are you happy to compress "2 Element ipn EID 
>>>>>>>>>>> scheme-specific
>>>>>>>>> encoding"
>>>>>>>>>>> to "2 Element ipn EID encoding" to fit?
>>>>>>>>>> 
>>>>>>>>>> Yes, happy to compress this to "2 Element ipn EID encoding".
>>>>>>>>>> 
>>>>>>>>>>>> #12) <!-- [rfced] In the text below, should "such as the use of"
>>>>>>>>>>>> read as "such as with the use of"?
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> 
>>>>>>>>>>>> In both cases (and indeed in all bundle processing), the node that
>>>>>>>>>>>> receives a bundle should verify its authenticity and validity
>>>>>>>>>>>> before operating on it in any way, such as the use of BPSec
>>>>>>>>>>>> [RFC9172], and TCPCLv4 with TLS [RFC9174].
>>>>>>>>>>>> 
>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>> 
>>>>>>>>>>>> In both cases (and indeed in all bundle processing), the node that
>>>>>>>>>>>> receives a bundle should verify its authenticity and validity
>>>>>>>>>>>> before operating on it in any way, such as with the use of BPSec
>>>>>>>>>>>> [RFC9172] and TCP Convergence Layer version 4 (TCPCLv4) with TLS
>>>>>>>>>>>> [RFC9174].
>>>>>>>>>>>> —>
>>>>>>>>>>> 
>>>>>>>>>>> [RT]: I don't mind either way, the original is my personal 
>>>>>>>>>>> preference,
>>>>>>>>>>> but the meaning is kept intact. @Ed?
>>>>>>>>>> 
>>>>>>>>>> I think the proposed text "such as with the use of" is clearer and 
>>>>>>>>>> recommend
>>>>>>>>> we adopt.
>>>>>>>>>> 
>>>>>>>>>> -Ed
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Karen Moore <kmo...@staff.rfc-editor.org>
>>>>>>>>>> Sent: Friday, March 21, 2025 7:42 PM
>>>>>>>>>> To: Rick Taylor <rtay...@aalyria.com>; Birrane, Edward J.
>>>>>>>>> <edward.birr...@jhuapl.edu>
>>>>>>>>>> Cc: RFC Errata System <rfc-edi...@rfc-editor.org>; dtn-...@ietf.org; 
>>>>>>>>>> dtn-
>>>>>>>>> cha...@ietf.org; sburleig...@gmail.com; Erik Kline 
>>>>>>>>> <ek.i...@gmail.com>;
>>>>>>>>> auth48archive <auth48archive@rfc-editor.org>
>>>>>>>>>> Subject: [EXT] Re: [auth48] AUTH48: RFC-to-be 9758 
>>>>>>>>>> <draft-ietf-dtn-ipn-
>>>>>>>>> update-14> for your review
>>>>>>>>>> 
>>>>>>>>>> APL external email warning: Verify sender kmo...@staff.rfc-editor.org
>>>>>>>>> before clicking links or attachments
>>>>>>>>>> 
>>>>>>>>>> Hi Rick,
>>>>>>>>>> 
>>>>>>>>>> Thank you for providing the second updated XML file. The changes are 
>>>>>>>>>> now
>>>>>>>>> reflected in our files. We have also removed the linked terms (so 
>>>>>>>>> only the
>>>>>>>>> section numbers are linked). Please review the text and let us know 
>>>>>>>>> if any
>>>>>>>>> further changes are needed.
>>>>>>>>>> 
>>>>>>>>>> We now await Ed’s reply and approval from each author prior to moving
>>>>>>>>> forward with publication.
>>>>>>>>>> 
>>>>>>>>>> —FILES (please refresh)--
>>>>>>>>>> The updated XML file is here:
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.xml
>>>>>>>>>> 
>>>>>>>>>> The updated output files are here:
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.txt
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.pdf
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.html
>>>>>>>>>> 
>>>>>>>>>> These diff files show all changes made during AUTH48:
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-auth48diff.html
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-auth48rfcdiff.html (side 
>>>>>>>>>> by side)
>>>>>>>>>> 
>>>>>>>>>> These diff files show only the changes made during the last edit 
>>>>>>>>>> round:
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-lastdiff.html
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-lastrfcdiff.html (side by 
>>>>>>>>>> side)
>>>>>>>>>> 
>>>>>>>>>> These diff files show all changes made to date:
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-diff.html
>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by 
>>>>>>>>>> side)
>>>>>>>>>> 
>>>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9758
>>>>>>>>>> 
>>>>>>>>>> Thank you!
>>>>>>>>>> RFC Editor/kc
>>>>>>>>>> 
>>>>>>>>>>> On Mar 20, 2025, at 10:40 PM, Rick Taylor <rtay...@aalyria.com> 
>>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi Editors,
>>>>>>>>>>> 
>>>>>>>>>>> I attach an updated XML with a small adjustment to table 7.   Other
>>>>>>>>> comments inline...
>>>>>>>>>>> 
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Rick
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Rick Taylor
>>>>>>>>>>> Tech Lead Manager UK
>>>>>>>>>>> 
>>>>>>>>>>> www.aalyria.com
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Fri, 21 Mar 2025 at 07:24, Karen Moore 
>>>>>>>>>>> <kmo...@staff.rfc-editor.org>
>>>>>>>>> wrote:
>>>>>>>>>>> Hi Rick,
>>>>>>>>>>> 
>>>>>>>>>>> Thank you for your reply and the updated XML file. We have updated 
>>>>>>>>>>> our
>>>>>>>>> files based on your comments; see the updated files below. We have 
>>>>>>>>> some
>>>>>>>>> additional questions/clarifications.
>>>>>>>>>>> 
>>>>>>>>>>> 1) Note that we removed the section titles that were linked 
>>>>>>>>>>> (currently, only
>>>>>>>>> the section numbers are linked). We left instances where a term and 
>>>>>>>>> the
>>>>>>>>> section number were both linked as is. Please review and let us know 
>>>>>>>>> if this is
>>>>>>>>> agreeable or if you would like to also remove the linked terms and 
>>>>>>>>> have only
>>>>>>>>> the section numbers linked.
>>>>>>>>>>> 
>>>>>>>>>>> This is fine by me.  The previous long form was an artefact of the 
>>>>>>>>>>> markdown
>>>>>>>>> tools we have used.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 2) We added a hyphen to ‘ipn’ as follows; please review the text 
>>>>>>>>>>> and let us
>>>>>>>>> know if any further changes are needed.
>>>>>>>>>>> 
>>>>>>>>>>> ipn URI scheme  -> ‘ipn’ URI scheme (throughout the text)
>>>>>>>>>>> ipn scheme URIs -> 'ipn' scheme URIs (8 instances)
>>>>>>>>>>> ipn scheme -> 'ipn' scheme (3 instances: Sections 7.1, 8.3, and 9)
>>>>>>>>>>> 
>>>>>>>>>>> Note that we updated “IPN URI scheme” to "‘ipn’ URI scheme" in the
>>>>>>>>> examples in Sections 6.1.1 and 6.1.2 and Appendices B.1, B.2, and 
>>>>>>>>> B.3. Please
>>>>>>>>> let us know if that is not correct.
>>>>>>>>>>> 
>>>>>>>>>>> This all looks correct, and I assume you mean you added single 
>>>>>>>>>>> quotes.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 3) Regarding the question below, we did not make any changes as we
>>>>>>>>> believe your comment meant the current text is agreeable. If any 
>>>>>>>>> changes are
>>>>>>>>> needed, please let us know.
>>>>>>>>>>> 
>>>>>>>>>>>> f.) In Tables 2, 4, 6, and 7, we assume that ">= 2^32" is the same
>>>>>>>>>>>> as ">=0x100000000" in the IANA registries. Are any changes desired
>>>>>>>>>>>> in the document to make this consistent with the IANA registries, 
>>>>>>>>>>>> or
>>>>>>>>>>>> will this variance be clear to readers?
>>>>>>>>>>>> 
>>>>>>>>>>>> [RT]: We hope this is clear to readers.  Happy with the change
>>>>>>>>>>> 
>>>>>>>>>>> No further changes required.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 4) FYI:  In Appendices B1, B2, and B3, we added a hyphen to a few 
>>>>>>>>>>> instances
>>>>>>>>> of “2 Element” and “3 Element” for consistency.
>>>>>>>>>>> 
>>>>>>>>>>> Perfect
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 5) FYI: We didn’t make any changes to the use of “<tt>” in the 
>>>>>>>>>>> document. If
>>>>>>>>> any changes are desired, please let us know.
>>>>>>>>>>> 
>>>>>>>>>>> I spotted one correction which I have made in the attached XML.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 6) We will await a reply from Ed for the following three questions:
>>>>>>>>>>> 
>>>>>>>>>>>> #2) <!--[rfced] Edward, we understand that in other RFCs (RFCs 
>>>>>>>>>>>> 9171,
>>>>>>>>>>>> 9172, and 9173), your preference was to list your name as "E. 
>>>>>>>>>>>> Birrane, III"
>>>>>>>>>>>> on the first page and "Edward J. Birrane, III" in the Authors'
>>>>>>>>>>>> Addresses section. Please let us know if you would you like to do
>>>>>>>>>>>> the same in this document for consistency.
>>>>>>>>>>>> —>
>>>>>>>>>>> 
>>>>>>>>>>> ...
>>>>>>>>>>>> #10) <!--[rfced] In Section 6.1.1 and Appendix B.2, "# 2 Element 
>>>>>>>>>>>> ipn
>>>>>>>>>>>> EID scheme-specific encoding" is 1 character over the 72-character
>>>>>>>>>>>> limit.  Please let us know how you would like to update the spacing
>>>>>>>>>>>> within the sourcecode figures.
>>>>>>>>>>>> 
>>>>>>>>>>>> Current
>>>>>>>>>>>> Section 6.1.1:
>>>>>>>>>>>> 82                        # 2-Element Endpoint Encoding
>>>>>>>>>>>> 02                     # uri-code: 2 (IPN URI scheme)
>>>>>>>>>>>> 82                     # 2 Element ipn EID scheme-specific encoding
>>>>>>>>>>>>  1B 000EE86800000064 # Fully-Qualified Node Number
>>>>>>>>>>>>  01                  # Service Number
>>>>>>>>>>>> 
>>>>>>>>>>>> Appendix B.1:
>>>>>>>>>>>> 82                        # 2-Element Endpoint Encoding
>>>>>>>>>>>> 02                     # uri-code: 2 (IPN URI scheme)
>>>>>>>>>>>> 82                     # 2 Element ipn EID scheme-specific encoding
>>>>>>>>>>>>  1B 000EE86800000001 # Fully-Qualified Node Number
>>>>>>>>>>>>  01                  # Service Number
>>>>>>>>>>>> —>
>>>>>>>>>>> 
>>>>>>>>>>> [RT]: @Ed, are you happy to compress "2 Element ipn EID 
>>>>>>>>>>> scheme-specific
>>>>>>>>> encoding"
>>>>>>>>>>> to "2 Element ipn EID encoding" to fit?
>>>>>>>>>>> 
>>>>>>>>>>> ...
>>>>>>>>>>>> #12) <!-- [rfced] In the text below, should "such as the use of"
>>>>>>>>>>>> read as "such as with the use of"?
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> 
>>>>>>>>>>>> In both cases (and indeed in all bundle processing), the node that
>>>>>>>>>>>> receives a bundle should verify its authenticity and validity
>>>>>>>>>>>> before operating on it in any way, such as the use of BPSec
>>>>>>>>>>>> [RFC9172], and TCPCLv4 with TLS [RFC9174].
>>>>>>>>>>>> 
>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>> 
>>>>>>>>>>>> In both cases (and indeed in all bundle processing), the node that
>>>>>>>>>>>> receives a bundle should verify its authenticity and validity
>>>>>>>>>>>> before operating on it in any way, such as with the use of BPSec
>>>>>>>>>>>> [RFC9172] and TCP Convergence Layer version 4 (TCPCLv4) with TLS
>>>>>>>>>>>> [RFC9174].
>>>>>>>>>>>> —>
>>>>>>>>>>> 
>>>>>>>>>>> [RT]: I don't mind either way, the original is my personal 
>>>>>>>>>>> preference,
>>>>>>>>>>> but the meaning is kept intact. @Ed?
>>>>>>>>>>> ...
>>>>>>>>>>> 
>>>>>>>>>>> --FILES--
>>>>>>>>>>> The updated XML file is here:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.xml
>>>>>>>>>>> 
>>>>>>>>>>> The updated output files are here:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.txt
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.pdf
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.html
>>>>>>>>>>> 
>>>>>>>>>>> These diff files show all changes made during AUTH48:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-auth48diff.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-auth48rfcdiff.html (side
>>>>>>>>>>> by side)
>>>>>>>>>>> 
>>>>>>>>>>> These diff files show all changes made to date:
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-diff.html
>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by
>>>>>>>>>>> side)
>>>>>>>>>>> 
>>>>>>>>>>> Note that it may be necessary for you to refresh your browser to 
>>>>>>>>>>> view the
>>>>>>>>> most recent version. Please review the document carefully to ensure
>>>>>>>>> satisfaction as we do not make changes once it has been published as 
>>>>>>>>> an RFC.
>>>>>>>>>>> 
>>>>>>>>>>> Please contact us with any further updates or with your approval of 
>>>>>>>>>>> the
>>>>>>>>> document in its current form.  We will await approvals from each 
>>>>>>>>> author prior
>>>>>>>>> to moving forward in the publication process.
>>>>>>>>>>> 
>>>>>>>>>>> For the AUTH48 status of this document, please see:
>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9758
>>>>>>>>>>> 
>>>>>>>>>>> Best regards,
>>>>>>>>>>> RFC Editor/kc
>>>>>>>>>>> 
>>>>>>>>>>>> On Mar 19, 2025, at 9:23 PM, Rick Taylor via auth48archive
>>>>>>>>> <auth48archive@rfc-editor.org> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi Editors,
>>>>>>>>>>>> 
>>>>>>>>>>>> Firstly thank you so much for the editorial pass, it greatly 
>>>>>>>>>>>> improves
>>>>>>>>> readability, and I appreciate the hard work.
>>>>>>>>>>>> 
>>>>>>>>>>>> I attach an updated XML file with 3 minor proposed changes, and 
>>>>>>>>>>>> I'll
>>>>>>>>>>>> reply to questions inline below.Cheers, Rick
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, 20 Mar 2025 at 08:24, <rfc-edi...@rfc-editor.org> wrote:
>>>>>>>>>>>> Authors,
>>>>>>>>>>>> 
>>>>>>>>>>>> While reviewing this document during AUTH48, please resolve (as
>>>>>>>>> necessary) the following questions, which are also in the XML file.
>>>>>>>>>>>> 
>>>>>>>>>>>> 1) <!--[rfced] To more closely match the document title, we updated
>>>>>>>>>>>> the short title that spans the header of the PDF file as follows. 
>>>>>>>>>>>> Please let us
>>>>>>>>> know of any objections.
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> 
>>>>>>>>>>>> ipn-updates
>>>>>>>>>>>> 
>>>>>>>>>>>> Current:
>>>>>>>>>>>> 
>>>>>>>>>>>> ipn Updates
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> Perhaps ipn Update (singular)?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 2) <!--[rfced] Edward, we understand that in other RFCs (RFCs 9171,
>>>>>>>>>>>> 9172, and 9173), your preference was to list your name as "E. 
>>>>>>>>>>>> Birrane, III"
>>>>>>>>>>>> on the first page and "Edward J. Birrane, III" in the Authors'
>>>>>>>>>>>> Addresses section. Please let us know if you would you like to do
>>>>>>>>>>>> the same in this document for consistency.
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 3) <!-- [rfced] Throughout the document, specific terms and section
>>>>>>>>>>>> titles are linked/referenced. To help the reader differentiate
>>>>>>>>>>>> between the two, we added quote marks to the section titles;
>>>>>>>>>>>> however, please consider if removing the section titles and
>>>>>>>>>>>> providing links to the section numbers only would be helpful for
>>>>>>>>>>>> ease of reading and to avoid any confusion. For example:
>>>>>>>>>>>> 
>>>>>>>>>>>> Current (with terms and section titles/numbers linked):
>>>>>>>>>>>> 
>>>>>>>>>>>> Both LocalNode (Section 3.4.2) and Private Use (Section 3.4.3) ipn
>>>>>>>>>>>> URIs present a risk to the stability of deployed BPv7 networks...
>>>>>>>>>>>> 
>>>>>>>>>>>> See "LocalNode ipn EIDs" (Section 5.4) and "Private Use ipn EIDs"
>>>>>>>>>>>> (Section 5.5) for required behaviors to mitigate against this form 
>>>>>>>>>>>> of
>>>>>>>>>>>> abuse.
>>>>>>>>>>>> 
>>>>>>>>>>>> Perhaps (with terms and section numbers linked):
>>>>>>>>>>>> 
>>>>>>>>>>>> Both LocalNode (Section 3.4.2) and Private Use (Section 3.4.3) ipn
>>>>>>>>>>>> URIs present a risk to the stability of deployed BPv7 networks...
>>>>>>>>>>>> 
>>>>>>>>>>>> See Sections 5.4 and 5.5 for required behaviors to mitigate against
>>>>>>>>>>>> this form of abuse.
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> This is an artefact of the markdown tooling we have used, I think 
>>>>>>>>>>>> the
>>>>>>>>> proposed change is good.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 4) <!-- [rfced] FYI - For readability, we have updated the text
>>>>>>>>>>>> below as a bulleted list. Please review and let us know any 
>>>>>>>>>>>> objections.
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> 
>>>>>>>>>>>> Specifically, this document
>>>>>>>>>>>> introduces a hierarchical structure for the assignment of ipn 
>>>>>>>>>>>> scheme
>>>>>>>>>>>> URIs, clarifies the behavior and interpretation of ipn scheme URIs,
>>>>>>>>>>>> defines efficient encodings of ipn scheme URIs, and updates/defines
>>>>>>>>>>>> the registries associated for this scheme.
>>>>>>>>>>>> 
>>>>>>>>>>>> Current:
>>>>>>>>>>>> 
>>>>>>>>>>>> Specifically, this document:
>>>>>>>>>>>> 
>>>>>>>>>>>> *  introduces a hierarchical structure for the assignment of ipn
>>>>>>>>>>>> scheme URIs,
>>>>>>>>>>>> 
>>>>>>>>>>>> *  clarifies the behavior and interpretation of ipn scheme URIs,
>>>>>>>>>>>> 
>>>>>>>>>>>> *  defines efficient encodings of ipn scheme URIs, and
>>>>>>>>>>>> 
>>>>>>>>>>>> *  updates/defines the registries associated with this scheme.
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> I think this improves readability, so I'm happy.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 5) <!-- [rfced] Is "range" meant to be singular (option A) or 
>>>>>>>>>>>> plural
>>>>>>>>>>>> (option B) in the text below?
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> 
>>>>>>>>>>>> If a system does not require interoperable deployment of ipn scheme
>>>>>>>>>>>> URIs, then the Private Use Node Numbers (Section 3.4.3) range,
>>>>>>>>>>>> reserved by the Default Allocator (Section 3.2.2) for this purpose,
>>>>>>>>>>>> are to be used.
>>>>>>>>>>>> 
>>>>>>>>>>>> Perhaps A:
>>>>>>>>>>>> 
>>>>>>>>>>>> If a system does not require interoperable deployment of ipn scheme
>>>>>>>>>>>> URIs, then the Private Use Node Numbers (Section 3.4.3) range,
>>>>>>>>>>>> reserved by the Default Allocator (Section 3.2.2) for this purpose,
>>>>>>>>>>>> is to be used.
>>>>>>>>>>>> 
>>>>>>>>>>>> or
>>>>>>>>>>>> 
>>>>>>>>>>>> Perhaps B:
>>>>>>>>>>>> 
>>>>>>>>>>>> If a system does not require interoperable deployment of ipn scheme
>>>>>>>>>>>> URIs, then a range of Private Use Node Numbers (Section 3.4.3),
>>>>>>>>>>>> reserved by the Default Allocator (Section 3.2.2) for this purpose,
>>>>>>>>>>>> are to be used.
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> As a native British english speaker, I prefer (A).
>>>>>>>>>>>> 
>>>>>>>>>>>> 6) <!-- [rfced] For ease of the reader, we have broken up the text
>>>>>>>>>>>> below. Please review.
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> 
>>>>>>>>>>>> Rather than assigning unique Allocator Identifiers to each sub-
>>>>>>>>>>>> organization on a first-come first-served basis, there are
>>>>>>>>>>>> operational benefits in assigning Allocator Identifiers to such an
>>>>>>>>>>>> organization in a structured way so that an external observer can
>>>>>>>>>>>> detect that a group of Allocator Identifiers are organizationally
>>>>>>>>>>>> associated.
>>>>>>>>>>>> 
>>>>>>>>>>>> Current:
>>>>>>>>>>>> 
>>>>>>>>>>>> Rather than assigning unique Allocator Identifiers to each sub-
>>>>>>>>>>>> organization on a first-come, first-served basis, there are 
>>>>>>>>>>>> operational
>>>>>>>>>>>> benefits in assigning Allocator Identifiers to such an 
>>>>>>>>>>>> organization in a
>>>>>>>>>>>> structured way. This allows an external observer to detect
>>>>>>>>>>>> that a group of Allocator Identifiers is organizationally 
>>>>>>>>>>>> associated.
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> Yes, much better
>>>>>>>>>>>> 
>>>>>>>>>>>> 7) <!--[rfced] FYI - In all of the tables, we have aligned the
>>>>>>>>>>>> content to the left (instead of centering some columns) for
>>>>>>>>>>>> consistency and easy reading. If this is not preferred, please let 
>>>>>>>>>>>> us know.
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> I didn't really notice the difference, so obviously an improvement.
>>>>>>>>> Consistency with the RFC editorial style is what we are aiming for.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 8) <!-- [rfced] May we clarify what specifications the following
>>>>>>>>>>>> text refers to and also rework the last sentence to make clear that
>>>>>>>>>>>> an RFC (rather than a
>>>>>>>>>>>> protocol) defines this registry?
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> 
>>>>>>>>>>>> The IRTF BPv6 experimental specification termed the logical source 
>>>>>>>>>>>> or
>>>>>>>>>>>> destination of a bundle as an "Endpoint" identified by an "Endpoint
>>>>>>>>>>>> Identifier" (EID). BPv6 EIDs are formatted as URIs.  This 
>>>>>>>>>>>> definition and
>>>>>>>>>>>> representation of EIDs was carried forward from the IRTF BPv6
>>>>>>>>> specification
>>>>>>>>>>>> to the IETF BPv7 specification.  BPv7 additionally defined an IANA 
>>>>>>>>>>>> registry
>>>>>>>>>>>> called the "Bundle Protocol URI Scheme Types" registry...
>>>>>>>>>>>> 
>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>> 
>>>>>>>>>>>> The IRTF BPv6 experimental specification [RFC5050] termed the 
>>>>>>>>>>>> logical
>>>>>>>>>>>> source or destination of a bundle as an "Endpoint" identified by an
>>>>>>>>>>>> "Endpoint Identifier" (EID). BPv6 EIDs are formatted as URIs.  This
>>>>>>>>>>>> definition and representation of EIDs was carried forward from the 
>>>>>>>>>>>> IRTF
>>>>>>>>>>>> BPv6 specification [RFC5050] to the IETF BPv7 specification 
>>>>>>>>>>>> [RFC9171].
>>>>>>>>>>>> [RFC9171] additionally defined an IANA registry called the "Bundle
>>>>>>>>> Protocol
>>>>>>>>>>>> URI Scheme Types" registry...
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> Yes that makes more sense.  I think we originally were worried of
>>>>>>>>>>>> having too many references, but this is definitely clearer.  The
>>>>>>>>>>>> situation is currently a mess, and this doc is trying to clear it 
>>>>>>>>>>>> up
>>>>>>>>>>>> ;)
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 9) <!-- [rfced] In the instances below, does "security source" read
>>>>>>>>>>>> as redundant after "Bundle Protocol Security"?
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> 
>>>>>>>>>>>> For example, a LocalNode ipn EID MUST NOT be used as a Bundle
>>>>>>>>>>>> Protocol Security [RFC9172] security source for a bundle
>>>>>>>>>>>> transmitted from the local bundle node, because such a source EID
>>>>>>>>>>>> would have no meaning at a downstream bundle node.
>>>>>>>>>>>> 
>>>>>>>>>>>> For example, a Private Use ipn EID MUST NOT be used as a Bundle
>>>>>>>>> Protocol
>>>>>>>>>>>> Security [RFC9172] security source for a bundle, when the bundle is
>>>>>>>>>>>> destined for a different administrative domain.
>>>>>>>>>>>> 
>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>> 
>>>>>>>>>>>> For example, a LocalNode ipn EID MUST NOT be used as a
>>>>>>>>>>>> source of Bundle Protocol Security (BPSec) [RFC9172] for a bundle
>>>>>>>>>>>> transmitted from the local bundle node, because such a source EID
>>>>>>>>>>>> would have no meaning at a downstream bundle node.
>>>>>>>>>>>> 
>>>>>>>>>>>> For example, a Private Use ipn EID MUST NOT be used as a source of
>>>>>>>>>>>> BPSec [RFC9172] for a bundle when the bundle is destined for a
>>>>>>>>>>>> different administrative domain.
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> No, please keep the original.  A "Security Source" is a very
>>>>>>>>>>>> specific field in BPSec, so although the "Bundle Protocol Security
>>>>>>>>>>>> Security Source" sounds wrong, it's actually accurate
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 10) <!--[rfced] In Section 6.1.1 and Appendix B.2, "# 2 Element ipn
>>>>>>>>>>>> EID scheme-specific encoding" is 1 character over the 72-character
>>>>>>>>>>>> limit.  Please let us know how you would like to update the spacing
>>>>>>>>>>>> within the sourcecode figures.
>>>>>>>>>>>> 
>>>>>>>>>>>> Current
>>>>>>>>>>>> Section 6.1.1:
>>>>>>>>>>>> 82                        # 2-Element Endpoint Encoding
>>>>>>>>>>>> 02                     # uri-code: 2 (IPN URI scheme)
>>>>>>>>>>>> 82                     # 2 Element ipn EID scheme-specific encoding
>>>>>>>>>>>>  1B 000EE86800000064 # Fully-Qualified Node Number
>>>>>>>>>>>>  01                  # Service Number
>>>>>>>>>>>> 
>>>>>>>>>>>> Appendix B.1:
>>>>>>>>>>>> 82                        # 2-Element Endpoint Encoding
>>>>>>>>>>>> 02                     # uri-code: 2 (IPN URI scheme)
>>>>>>>>>>>> 82                     # 2 Element ipn EID scheme-specific encoding
>>>>>>>>>>>>  1B 000EE86800000001 # Fully-Qualified Node Number
>>>>>>>>>>>>  01                  # Service Number
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> @Ed:  Are you happy to compress "2 Element ipn EID scheme-specific
>>>>>>>>> encoding" to "2 Element ipn EID encoding" to fit?
>>>>>>>>>>>> 
>>>>>>>>>>>> 11) <!-- [rfced] FYI - We have adjusted the text below to read as a
>>>>>>>>>>>> numbered list. Please review and let us know any objections.
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> 
>>>>>>>>>>>> In the three-element scheme-specific encoding of an ipn EID, the
>>>>>>>>>>>> first element of the array is the Allocator Identifier, the second
>>>>>>>>>>>> element of the array is the Node Number, and the third element of 
>>>>>>>>>>>> the
>>>>>>>>>>>> array is the Service Number.
>>>>>>>>>>>> 
>>>>>>>>>>>> Current:
>>>>>>>>>>>> 
>>>>>>>>>>>> In the three-element scheme-specific encoding of an ipn EID:
>>>>>>>>>>>> 
>>>>>>>>>>>> 1.  the first element of the array is the Allocator Identifier,
>>>>>>>>>>>> 
>>>>>>>>>>>> 2.  the second element of the array is the Node Number, and
>>>>>>>>>>>> 
>>>>>>>>>>>> 3.  the third element of the array is the Service Number.
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> I like a numbered list.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 12) <!-- [rfced] In the text below, should "such as the use of" 
>>>>>>>>>>>> read
>>>>>>>>>>>> as "such as with the use of"?
>>>>>>>>>>>> 
>>>>>>>>>>>> Original:
>>>>>>>>>>>> 
>>>>>>>>>>>> In both cases (and indeed in all bundle processing), the node that
>>>>>>>>>>>> receives a bundle should verify its authenticity and validity
>>>>>>>>>>>> before operating on it in any way, such as the use of BPSec
>>>>>>>>>>>> [RFC9172], and TCPCLv4 with TLS [RFC9174].
>>>>>>>>>>>> 
>>>>>>>>>>>> Perhaps:
>>>>>>>>>>>> 
>>>>>>>>>>>> In both cases (and indeed in all bundle processing), the node that
>>>>>>>>>>>> receives a bundle should verify its authenticity and validity
>>>>>>>>>>>> before operating on it in any way, such as with the use of BPSec
>>>>>>>>>>>> [RFC9172] and TCP Convergence Layer version 4 (TCPCLv4) with TLS
>>>>>>>>>>>> [RFC9174].
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> I don't mind either way, the original is my personal preference, 
>>>>>>>>>>>> but the
>>>>>>>>> meaning is kept intact. @Ed?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 13) <!-- [rfced] We have included some specific questions about the
>>>>>>>>>>>> IANA text below. In addition to responding to those questions,
>>>>>>>>>>>> please review all of the IANA-related updates carefully and let us
>>>>>>>>>>>> know if any further updates are needed. Note that the registries 
>>>>>>>>>>>> can
>>>>>>>>>>>> be viewed at <https://www.iana.org/assignments/uri-schemes/>.
>>>>>>>>>>>> 
>>>>>>>>>>>> a.) We note different capitalization and use of quotation marks
>>>>>>>>>>>> around "Private Use" in the running text. We have removed the quote
>>>>>>>>>>>> marks for consistency as the policies of RFC 8126 usually appear as
>>>>>>>>>>>> uppercase without quote marks.
>>>>>>>>>>>> 
>>>>>>>>>>>> Perfect, let's use the correct way of using the words.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> b.) The registration procedures in Table 4 do not match the
>>>>>>>>>>>> registration procedures for the "'ipn' Scheme URI Default 
>>>>>>>>>>>> Allocator Node
>>>>>>>>> Numbers"
>>>>>>>>>>>> registry. We updated the reference entries accordingly (see Tables 
>>>>>>>>>>>> 4 and
>>>>>>>>> 5).
>>>>>>>>>>>> Please review and let us know if any further changes are needed.
>>>>>>>>>>>> 
>>>>>>>>>>>> I think Table 4 and 5 are an improvement, but I would drop the 
>>>>>>>>>>>> duplicate
>>>>>>>>> "Invalid" final row from Table 5.
>>>>>>>>>>>> 
>>>>>>>>>>>> c.) FYI: We have made "Well-Known" uppercase in the "'ipn' Scheme
>>>>>>>>>>>> URI Well-Known Service Numbers for BPv7" registry name, and we will
>>>>>>>>>>>> ask IANA to make this change prior to publication.
>>>>>>>>>>>> 
>>>>>>>>>>>> Fine by me
>>>>>>>>>>>> 
>>>>>>>>>>>> d.) We updated Tables 6 and 7 to match the "'ipn' Scheme URI
>>>>>>>>>>>> Well-Known Service Numbers for BPv7" registry. Please let us know 
>>>>>>>>>>>> if
>>>>>>>>>>>> any further changes are needed.
>>>>>>>>>>>> 
>>>>>>>>>>>> I'm not sure I like the duplication of the "Reserved for..." 
>>>>>>>>>>>> entries in Table 7.
>>>>>>>>> If the entries are reserved in table 6, why are they 'initial' in 
>>>>>>>>> Table 7?
>>>>>>>>>>>> 
>>>>>>>>>>>> e.) In Tables 2, 4, and 6, we updated "Registration Policy" to
>>>>>>>>>>>> "Registration Procedures" in the column headings to match the
>>>>>>>>>>>> respective IANA registries. In the running text, may we update
>>>>>>>>>>>> instances of "registration policies" to "registration procedures"
>>>>>>>>>>>> for consistency?
>>>>>>>>>>>> 
>>>>>>>>>>>> Fine by me
>>>>>>>>>>>> 
>>>>>>>>>>>> f.) In Tables 2, 4, 6, and 7, we assume that ">= 2^32" is the same
>>>>>>>>>>>> as ">=0x100000000" in the IANA registries. Are any changes desired
>>>>>>>>>>>> in the document to make this consistent with the IANA registries, 
>>>>>>>>>>>> or
>>>>>>>>>>>> will this variance be clear to readers?
>>>>>>>>>>>> 
>>>>>>>>>>>> We hope this is clear to readers.  Happy with the change
>>>>>>>>>>>> 
>>>>>>>>>>>> i.) We note the following variances in the IANA registries. Should
>>>>>>>>>>>> these be made consistent by replacing "greater than" with ">="?
>>>>>>>>>>>> 
>>>>>>>>>>>> In the "'ipn' Scheme URI Allocator Identifiers" and "'ipn' Scheme
>>>>>>>>>>>> URI  Default Allocator Node Numbers" registries:
>>>>>>>>>>>> 
>>>>>>>>>>>> ">=0x100000000"
>>>>>>>>>>>> 
>>>>>>>>>>>> In the "'ipn' Scheme URI Well-Known Service Numbers for BPv7"
>>>>>>>>>>>> registry:
>>>>>>>>>>>> 
>>>>>>>>>>>> "greater than 0x100000000"
>>>>>>>>>>>> 
>>>>>>>>>>>> Happy with >= instead of "greathan or equal to".
>>>>>>>>>>>> 
>>>>>>>>>>>> ii.) FYI: In Table 5, we replaced ">= 2^32" with ">=4294967296"
>>>>>>>>>>>> ("Invalid") to match the "'ipn' Scheme URI Default Allocator Node
>>>>>>>>>>>> Numbers" registry. Please let us know if this is not correct
>>>>>>>>>>>> 
>>>>>>>>>>>> It's correct, but 2^32 might be easier on the eye than the very 
>>>>>>>>>>>> long string
>>>>>>>>> of digits.
>>>>>>>>>>>> .
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 14) <!-- [rfced] Please review the following comments related to 
>>>>>>>>>>>> XML
>>>>>>>>> formatting:
>>>>>>>>>>>> 
>>>>>>>>>>>> a.) In the html and pdf outputs, the text enclosed in <tt> is 
>>>>>>>>>>>> output
>>>>>>>>>>>> in fixed-width font. In the txt output, there are no changes to the
>>>>>>>>>>>> font, and the quotation marks are removed. Please review carefully
>>>>>>>>>>>> and let us know if the output is acceptable or if any updates are 
>>>>>>>>>>>> needed.
>>>>>>>>>>>> 
>>>>>>>>>>>> This is an artefact of the markdown tooling we have used.  Please 
>>>>>>>>>>>> format
>>>>>>>>> as appropriate.
>>>>>>>>>>>> 
>>>>>>>>>>>> b.) Please review each <artwork> element and let us know if any
>>>>>>>>>>>> should be marked as <sourcecode> (or another element) instead.
>>>>>>>>>>>> 
>>>>>>>>>>>> We have already updated several <artwork> elements to <sourcecode>.
>>>>>>>>>>>> Please confirm these updates are correct and whether the "type"
>>>>>>>>>>>> attribute of any <sourcecode> element should be set and/or has been
>>>>>>>>>>>> set correctly.
>>>>>>>>>>>> 
>>>>>>>>>>>> The current list of preferred values for "type" is available at
>>>>>>>>>>>> <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>.
>>>>>>>>>>>> If the current list does not contain an applicable type, feel free
>>>>>>>>>>>> to suggest additions for consideration. Note that it is also
>>>>>>>>>>>> acceptable to leave the "type" attribute not set.
>>>>>>>>>>>> 
>>>>>>>>>>>> Having checked, the changes look correct.
>>>>>>>>>>>> 
>>>>>>>>>>>> c.) Please review whether the note in Section 6.3 should be in the
>>>>>>>>>>>> <aside> element. It is defined as "a container for content that is
>>>>>>>>>>>> semantically less important or tangential to the content that
>>>>>>>>>>>> surrounds it" 
>>>>>>>>>>>> (https://authors.ietf.org/en/rfcxml-vocabulary#aside).
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> No, this isn't an aside, it is semantically important, more of an 
>>>>>>>>>>>> NB than a
>>>>>>>>> side-note.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 15) <!-- [rfced] Errata exist for both RFCs 7116 and 9171. Please
>>>>>>>>>>>> review the errata for these RFCs and confirm that none are relevant
>>>>>>>>>>>> to the content of this document:
>>>>>>>>>>>> 
>>>>>>>>>>>> RFC 7116: <https://www.rfc-editor.org/errata_search.php?rfc=7116>
>>>>>>>>>>>> RFC 9171: <https://www.rfc-editor.org/errata_search.php?rfc=9171>
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> We are aware of the Errata, and this doc is designed to address 
>>>>>>>>>>>> some of
>>>>>>>>> them.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 16) <!-- [rfced] Please review the following questions and changes
>>>>>>>>>>>> regarding the terminology used in this document:
>>>>>>>>>>>> 
>>>>>>>>>>>> a.) In the RFC series, "Fully Qualified Domain Name (FQDN)"
>>>>>>>>>>>> typically appears as uppercase without a hyphen. Would you like to
>>>>>>>>>>>> remove the hyphen from the expansion of "Fully-Qualified Node 
>>>>>>>>>>>> Number"
>>>>>>>>> for consistency with the series?
>>>>>>>>>>>> 
>>>>>>>>>>>> My only preference is consistency.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Additionally, after the first expansion of "FQNN", may we replace
>>>>>>>>>>>> instances of "Fully-Qualified Node Number" with the acronym (per
>>>>>>>>>>>> guidance in "Web Portion of the Style Guide" at
>>>>>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#exp_abbrev>)?
>>>>>>>>>>>> 
>>>>>>>>>>>> Yes, if it meets the guidelines, please do.
>>>>>>>>>>>> 
>>>>>>>>>>>> b.) We note some variances with the terms below in the example
>>>>>>>>>>>> schemes. Should any of the occurrences in the example schemes be
>>>>>>>>>>>> updated for consistency (hyphen or no hyphen)?
>>>>>>>>>>>> 
>>>>>>>>>>>> 2 Element vs. 2-Element vs.
>>>>>>>>>>>> 3 Element
>>>>>>>>>>>> 
>>>>>>>>>>>> One example (Appendix B.1):
>>>>>>>>>>>> 
>>>>>>>>>>>> 82                # 2-Element Endpoint Encoding
>>>>>>>>>>>> 02             # uri-code: 2 (IPN URI scheme)
>>>>>>>>>>>> 83             # 3 Element ipn EID scheme-specific encoding
>>>>>>>>>>>>  1A 000EE868 # Allocator Identifier
>>>>>>>>>>>>  01          # Node Number
>>>>>>>>>>>>  01          # Service Number
>>>>>>>>>>>> 
>>>>>>>>>>>> Yes they should.
>>>>>>>>>>>> 
>>>>>>>>>>>> b.) We note different capitalization and quotation marks for 'null'
>>>>>>>>>>>> and Null in the instances below. Please let us know if/how may we
>>>>>>>>>>>> update for consistency.
>>>>>>>>>>>> 
>>>>>>>>>>>> Null ipn URI (term in IANA registry)
>>>>>>>>>>>> 5.2.  The Null Endpoint
>>>>>>>>>>>> B.3.  The 'null' Endpoint
>>>>>>>>>>>> 
>>>>>>>>>>>> 'null' ipn URI
>>>>>>>>>>>> 'null' ipn EID
>>>>>>>>>>>> 'null' endpoint
>>>>>>>>>>>> 'null' EID
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Given the IANA registry precedent, and my preference, I think Null 
>>>>>>>>>>>> is
>>>>>>>>> better than 'null'.
>>>>>>>>>>>> 
>>>>>>>>>>>> c.) Would you like either double (") or single (') quotes to appear
>>>>>>>>>>>> around ipn scheme? We note different usage across RFCs.
>>>>>>>>>>>> 
>>>>>>>>>>>> As used in this document:
>>>>>>>>>>>> ipn URI scheme
>>>>>>>>>>>> 
>>>>>>>>>>>> As used in the IANA registry names:
>>>>>>>>>>>> 'ipn' scheme
>>>>>>>>>>>> 
>>>>>>>>>>>> Usage from RFC 6260:
>>>>>>>>>>>> the "ipn" scheme
>>>>>>>>>>>> 
>>>>>>>>>>>> Usage from RFC 7116:
>>>>>>>>>>>> 'ipn' URI scheme
>>>>>>>>>>>> 
>>>>>>>>>>>> Let's use the single quotes, if that's the usual way of referring 
>>>>>>>>>>>> to a URI
>>>>>>>>> scheme in an RFC.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> d.) We note different formatting of "0" as seen below. For
>>>>>>>>>>>> consistency with the rest of this document, should any of these
>>>>>>>>>>>> instances be updated to "zero (0)" and should the <tt> tags be
>>>>>>>>>>>> removed? (We note that "Default Allocator" has a value of "0" in 
>>>>>>>>>>>> the
>>>>>>>>>>>> "'ipn' Scheme URI Allocator Identifiers" registry.)
>>>>>>>>>>>> 
>>>>>>>>>>>> ... the least-significant N bits of the first Allocator Identifier 
>>>>>>>>>>>> MUST
>>>>>>>>>>>> be all 0.
>>>>>>>>>>>> 
>>>>>>>>>>>> Correct
>>>>>>>>>>>> 
>>>>>>>>>>>> ... a range of bit-length 0
>>>>>>>>>>>> 
>>>>>>>>>>>> Correct
>>>>>>>>>>>> 
>>>>>>>>>>>> All leading <tt>0</tt> characters MUST be omitted. A single 
>>>>>>>>>>>> '<tt>0</tt>'
>>>>>>>>>>>> is valid.
>>>>>>>>>>>> 
>>>>>>>>>>>> Correct
>>>>>>>>>>>> 
>>>>>>>>>>>> Consider the ipn URI identifying Service Number 2 on Node Number 1
>>>>>>>>>>>> allocated by the Default Allocator (0) (Section 3.2.2).
>>>>>>>>>>>> 
>>>>>>>>>>>> Correct
>>>>>>>>>>>> 
>>>>>>>>>>>> Consider the ipn EID ipn:1.1.  This textual representation of an 
>>>>>>>>>>>> ipn
>>>>>>>>>>>> EID identifies Service Number 1 on Node Number 1 allocated by the
>>>>>>>>>>>> Default Allocator (0) (Section 3.2.2).
>>>>>>>>>>>> 
>>>>>>>>>>>> This should be <tt>ipn:1.1</tt>, but the other uses are correct.
>>>>>>>>>>>> 
>>>>>>>>>>>> We have attempted to differentiate between the number 0 and the
>>>>>>>>> explicit ASCII character 0, and this is important when talking about 
>>>>>>>>> textual
>>>>>>>>> representation vs a numeric value or count.  When dealing with a 
>>>>>>>>> 'count' then
>>>>>>>>> "... zero (0) ..." seems the correct usage, unless it results in 
>>>>>>>>> multiple nested
>>>>>>>>> parantheses, in which case "(0)" seems best.  When dealing with a 
>>>>>>>>> numeric
>>>>>>>>> value, 0 seems correct, when dealing with the character or sequence of
>>>>>>>>> characters <tt> is correct.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> e.) Because CBOR expands to Concise Binary Object Representation
>>>>>>>>>>>> (CBOR), would "CBOR representation" be redundant in the instances
>>>>>>>>> below?
>>>>>>>>>>>> 
>>>>>>>>>>>> 6.   CBOR representation of ipn URIs with BPv7 . . . . . . . .  15
>>>>>>>>>>>> 7.2. CBOR Representation Interoperability  . . . . . . . . . .  19
>>>>>>>>>>>> CBOR representation (2 instances in the running text)
>>>>>>>>>>>> 
>>>>>>>>>>>> No please leave as is.  "CBOR representation"  is the common usage,
>>>>>>>>> despite the odd expansion.
>>>>>>>>>>>> 
>>>>>>>>>>>> f.) FYI - We have added expansions for abbreviations upon first use
>>>>>>>>>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
>>>>>>>>>>>> expansion in the document carefully to ensure correctness.
>>>>>>>>>>>> 
>>>>>>>>>>>> Concise Binary Object Representation (CBOR)
>>>>>>>>>>>> TCP Convergence Layer version 4 (TCPCLv4)
>>>>>>>>>>>> 
>>>>>>>>>>>> Perfect, they got missed in our paragraph shuffling.
>>>>>>>>>>>> 
>>>>>>>>>>>> -->
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 17) <!-- [rfced] Please review the "Inclusive Language" portion of
>>>>>>>>>>>> the online Style Guide
>>>>>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
>>>>>>>>>>>> and let us know if any changes are needed.  Updates of this nature
>>>>>>>>>>>> typically result in more precise language, which is helpful for 
>>>>>>>>>>>> readers.
>>>>>>>>>>>> 
>>>>>>>>>>>> Note that our script did not flag any words in particular, but this
>>>>>>>>>>>> should still be reviewed as a best practice. -->
>>>>>>>>>>>> 
>>>>>>>>>>>> Excellent, we tried to be inclusive.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Thank you.
>>>>>>>>>>>> 
>>>>>>>>>>>> RFC Editor/kf/kc
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Mar 19, 2025, at 6:20 PM, RFC Editor via auth48archive
>>>>>>>>> <auth48archive@rfc-editor.org> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> *****IMPORTANT*****
>>>>>>>>>>>> 
>>>>>>>>>>>> Updated 2025/03/19
>>>>>>>>>>>> 
>>>>>>>>>>>> RFC Author(s):
>>>>>>>>>>>> --------------
>>>>>>>>>>>> 
>>>>>>>>>>>> Instructions for Completing AUTH48
>>>>>>>>>>>> 
>>>>>>>>>>>> Your document has now entered AUTH48.  Once it has been reviewed 
>>>>>>>>>>>> and
>>>>>>>>>>>> approved by you and all coauthors, it will be published as an RFC.
>>>>>>>>>>>> If an author is no longer available, there are several remedies
>>>>>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>>>>>>>>>>>> 
>>>>>>>>>>>> You and you coauthors are responsible for engaging other parties
>>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing
>>>>>>>>>>>> your approval.
>>>>>>>>>>>> 
>>>>>>>>>>>> Planning your review
>>>>>>>>>>>> ---------------------
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the following aspects of your document:
>>>>>>>>>>>> 
>>>>>>>>>>>> *  RFC Editor questions
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review and resolve any questions raised by the RFC Editor
>>>>>>>>>>>> that have been included in the XML file as comments marked as
>>>>>>>>>>>> follows:
>>>>>>>>>>>> 
>>>>>>>>>>>> <!-- [rfced] ... -->
>>>>>>>>>>>> 
>>>>>>>>>>>> These questions will also be sent in a subsequent email.
>>>>>>>>>>>> 
>>>>>>>>>>>> *  Changes submitted by coauthors
>>>>>>>>>>>> 
>>>>>>>>>>>> Please ensure that you review any changes submitted by your
>>>>>>>>>>>> coauthors.  We assume that if you do not speak up that you
>>>>>>>>>>>> agree to changes submitted by your coauthors.
>>>>>>>>>>>> 
>>>>>>>>>>>> *  Content
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the full content of the document, as this cannot
>>>>>>>>>>>> change once the RFC is published.  Please pay particular attention 
>>>>>>>>>>>> to:
>>>>>>>>>>>> - IANA considerations updates (if applicable)
>>>>>>>>>>>> - contact information
>>>>>>>>>>>> - references
>>>>>>>>>>>> 
>>>>>>>>>>>> *  Copyright notices and legends
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the copyright notice and legends as defined in
>>>>>>>>>>>> RFC 5378 and the Trust Legal Provisions
>>>>>>>>>>>> (TLP – https://trustee.ietf.org/license-info).
>>>>>>>>>>>> 
>>>>>>>>>>>> *  Semantic markup
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the markup in the XML file to ensure that elements of
>>>>>>>>>>>> content are correctly tagged.  For example, ensure that 
>>>>>>>>>>>> <sourcecode>
>>>>>>>>>>>> and <artwork> are set correctly.  See details at
>>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>.
>>>>>>>>>>>> 
>>>>>>>>>>>> *  Formatted output
>>>>>>>>>>>> 
>>>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the
>>>>>>>>>>>> formatted output, as generated from the markup in the XML file, is
>>>>>>>>>>>> reasonable.  Please note that the TXT will have formatting
>>>>>>>>>>>> limitations compared to the PDF and HTML.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Submitting changes
>>>>>>>>>>>> ------------------
>>>>>>>>>>>> 
>>>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as
>>>>>>>>>>>> all the parties CCed on this message need to see your changes. The
>>>>>>>>>>>> parties
>>>>>>>>>>>> include:
>>>>>>>>>>>> 
>>>>>>>>>>>> *  your coauthors
>>>>>>>>>>>> 
>>>>>>>>>>>> *  rfc-edi...@rfc-editor.org (the RPC team)
>>>>>>>>>>>> 
>>>>>>>>>>>> *  other document participants, depending on the stream (e.g.,
>>>>>>>>>>>> IETF Stream participants are your working group chairs, the
>>>>>>>>>>>> responsible ADs, and the document shepherd).
>>>>>>>>>>>> 
>>>>>>>>>>>> *  auth48archive@rfc-editor.org, which is a new archival mailing 
>>>>>>>>>>>> list
>>>>>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion
>>>>>>>>>>>> list:
>>>>>>>>>>>> 
>>>>>>>>>>>> *  More info:
>>>>>>>>>>>> 
>>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2US
>>>>>>>>>>>> xIAe6P8O4Zc
>>>>>>>>>>>> 
>>>>>>>>>>>> *  The archive itself:
>>>>>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/
>>>>>>>>>>>> 
>>>>>>>>>>>> *  Note: If only absolutely necessary, you may temporarily opt out
>>>>>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter).
>>>>>>>>>>>> If needed, please add a note at the top of the message that you
>>>>>>>>>>>> have dropped the address. When the discussion is concluded,
>>>>>>>>>>>> auth48archive@rfc-editor.org will be re-added to the CC list and
>>>>>>>>>>>> its addition will be noted at the top of the message.
>>>>>>>>>>>> 
>>>>>>>>>>>> You may submit your changes in one of two ways:
>>>>>>>>>>>> 
>>>>>>>>>>>> An update to the provided XML file
>>>>>>>>>>>> — OR —
>>>>>>>>>>>> An explicit list of changes in this format
>>>>>>>>>>>> 
>>>>>>>>>>>> Section # (or indicate Global)
>>>>>>>>>>>> 
>>>>>>>>>>>> OLD:
>>>>>>>>>>>> old text
>>>>>>>>>>>> 
>>>>>>>>>>>> NEW:
>>>>>>>>>>>> new text
>>>>>>>>>>>> 
>>>>>>>>>>>> You do not need to reply with both an updated XML file and an
>>>>>>>>>>>> explicit list of changes, as either form is sufficient.
>>>>>>>>>>>> 
>>>>>>>>>>>> We will ask a stream manager to review and approve any changes that
>>>>>>>>>>>> seem beyond editorial in nature, e.g., addition of new text,
>>>>>>>>>>>> deletion of text, and technical changes.  Information about stream
>>>>>>>>>>>> managers can be found in the FAQ.  Editorial changes do not require
>>>>>>>>> approval from a stream manager.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Approving for publication
>>>>>>>>>>>> --------------------------
>>>>>>>>>>>> 
>>>>>>>>>>>> To approve your RFC for publication, please reply to this email
>>>>>>>>>>>> stating that you approve this RFC for publication.  Please use
>>>>>>>>>>>> ‘REPLY ALL’, as all the parties CCed on this message need to see 
>>>>>>>>>>>> your
>>>>>>>>> approval.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Files
>>>>>>>>>>>> -----
>>>>>>>>>>>> 
>>>>>>>>>>>> The files are available here:
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.xml
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.html
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.pdf
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758.txt
>>>>>>>>>>>> 
>>>>>>>>>>>> Diff file of the text:
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-diff.html
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-rfcdiff.html (side by
>>>>>>>>>>>> side)
>>>>>>>>>>>> 
>>>>>>>>>>>> Diff of the XML:
>>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9758-xmldiff1.html
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Tracking progress
>>>>>>>>>>>> -----------------
>>>>>>>>>>>> 
>>>>>>>>>>>> The details of the AUTH48 status of your document are here:
>>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9758
>>>>>>>>>>>> 
>>>>>>>>>>>> Please let us know if you have any questions.
>>>>>>>>>>>> 
>>>>>>>>>>>> Thank you for your cooperation,
>>>>>>>>>>>> 
>>>>>>>>>>>> RFC Editor
>>>>>>>>>>>> 
>>>>>>>>>>>> --------------------------------------
>>>>>>>>>>>> RFC9758 (draft-ietf-dtn-ipn-update-14)
>>>>>>>>>>>> 
>>>>>>>>>>>> Title            : Update to the ipn URI scheme
>>>>>>>>>>>> Author(s)        : R. Taylor, E. Birrane
>>>>>>>>>>>> WG Chair(s)      : Edward J. Birrane, Rick Taylor
>>>>>>>>>>>> Area Director(s) : Erik Kline, Éric Vyncke
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> auth48archive mailing list -- auth48archive@rfc-editor.org To
>>>>>>>>>>>> unsubscribe send an email to auth48archive-le...@rfc-editor.org
>>>>>>>>>>>> 
>>>>>>>>>>>> <rfc9758.xml>--
>>>>>>>>>>>> auth48archive mailing list -- auth48archive@rfc-editor.org To
>>>>>>>>>>>> unsubscribe send an email to auth48archive-le...@rfc-editor.org
>>>>>>>>>>> 
>>>>>>>>>>> <rfc9758 (1).xml>
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

-- 
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org

Reply via email to