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
-->
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.
-->
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.
-->
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.
-->
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.
-->
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.
-->
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...
-->
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.
-->
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
-->
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.
-->
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].
-->
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.
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.
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.
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.
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?
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?
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"
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.
-->
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.
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.
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).
-->
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>
-->
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?
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>)?
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
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
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
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.
... a range of bit-length 0
All leading <tt>0</tt> characters MUST be omitted. A single '<tt>0</tt>'
is valid.
Consider the ipn URI identifying Service Number 2 on Node Number 1
allocated by the Default Allocator (0) (Section 3.2.2).
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).
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)
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)
-->
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. -->
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
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
