IPv6 Neighbor Discovery Prefix Registration
draft-ietf-6lo-prefix-registration-18

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-6lo-prefix-registration and RFC 9926, changed IESG state to RFC Published)

RFC Editor Note was changed to

RFC Editor Note

Please process draft-ietf-6lo-updating-rfc-8928 and draft-ietf-6lo-prefix-registration together (they should actually be in a cluster anyway) and allocate two sequential RFC number if possible. The lower RFC number should be for draft-ietf-6lo-updating-rfc-8928 and the higher for draft-ietf-6lo-prefix-registration.

Thanks

-éric

[Ballot comment]
Thanks to the author and the WG for this very useful extension for Prefix Discovery in 6LoWPAN.

Thanks for the discussion and making the changes. I am clearing my DISCUSS position.

I will let the INT ADs review the current set of RFCs listed on the "updates" metadata for their correctness. They seem OK to me.

[Ballot discuss]
Thanks to the author and the WG for this very useful extension for Prefix Discovery in 6LoWPAN.

I am updating my DISCUSS post the telechat in two ways: (a) removed my previous question for clarification of whether this extension is narrowly scoping to 6LoWPAN (and related scenarios) alone or generically for all of IPv6 ND deployments, and (b) clarified my position on the other discuss (see below).


This document is setting the "update" RFC metadata on 7 RFCs 4861 (base IPv6 ND), 6550 (RPL), 6553, 8505 (6LoWPAN ND which btw does not update 4861), 8928, 8929 , 9010.

For the record, none of the RFCs from 6Lo (and related space/WGs) updated base ND RFC 4861 until very recently RFC9685 did that by "updating" a whole host of RFCs just like this document is trying to do.

Now this draft references draft-kuehlewind-update-tag and uses its terminology of ammend/extend (but curiously not "also see"). I have no issue with the use or referencing on this term in the body of the text. My query is whether extending those terms from draft-kuehlewind to reflect on the existing "updates" RFC metadata (which is not what draft-kuehlewind proposes) is correct. i.e., is this a normal protocol extension using available bits, fields, TLVs OR is it a change (or bugfix) of the base specification itself.

I do also have doubts on the claim that it amends RFC4861 (I believe it amends RFC8505 instead).

I could be wrong and request the INT ADs to correct me.

[Ballot comment]
# Internet AD comments for draft-ietf-6lo-prefix-registration-11
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

* I don't think the IETF should (continue to) publish documents like this
  repeat editorial critiques of previous rounds of IPv6 ND design work.

  Some of the editorial comments have technical merit, but many of the
  statements read like editorial an column driving a personal agenda.

[Ballot comment]
# Andy Newton, ART AD, comments for draft-ietf-6lo-prefix-registration-12
CC @anewton1998

* line numbers:
  - https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-6lo-prefix-registration-12.txt&submitcheck=True

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

I have no objection to the public of this document as an RFC.

[Ballot discuss]
** As other ADs have balloted, [I-D.kuehlewind-update-tag] has no standing.  Section 2.1 appears to state that “extends” and “amends” are synonyms for “updates”.  I take that to mean that the processes associated with the “updates tag” apply.  As such, the document is not self-consistent:

-- Section 5 says this documents extends RFC7400, but this document isn’t included in the “Updates meta-data” (RFC8929 is also noted as “extending” but is included in the list of documents referenced by the update tag)

-- The Updates meta-data tag and abstract say RFC6553 is updated, but the body of the text doesn’t explain how.  There isn’t even a reference to it.

[Ballot comment]
Thank you to Dan Romascanu for the GENART review.

** Section 13.2.  The registry field names used in Table 3 are not correct.  Per https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#sixlowpan-capability-bits:

-- s/Capability Bit/Bit/
-- s/Meaning/Description/

[Ballot comment]
This document is very dense, and I can tell that you've made efforts to connect it to the context of existing documents in this space. Thank you for that investment. I have a few comments that I hope will help improve the document; they can be incorporated at the editor's and the responsible AD's discretion.

In Section 2.1, there is no Extends or Amends "tag" per se. I think it's fine to define the terms as you're using them for precision in this document, but draft-kuehlewind-update-tag has been replaced and its replacement expired without being adopted by RSWG. It has no formal standing at this point.

In Section 2.2, there's already a References section at the end of the document. Consider instead specifying what terminology you're importing from each document.

In Section 3, the second sentence is difficult to parse due to the descriptive clauses for each item in your list. Consider breaking this up into multiple sentences or using a bulleted list to isolate the elements.

In Section 7.3, there is an inconsistency between "less than 120 bits long" and "up to 120 bits" / "at most 120". I suspect the first intends to say "at most 120 bits long."

It might be worth mentioning earlier in the document that this design excludes support for prefixes longer than 120 bits. That's almost certainly a reasonable restriction, but discovering it in the encoding rules of the message is sub-optimal.

In Section 12.1, is there a citation for "brown field use case"? Is this phrase needed, or could this sentence begin with "A mix of devices that support any or all of..."

===NITS FOLLOW===

Abstract, "allows to request" => "allows the node to request" or "allows requesting"

Section 1, paragraph 3 has odd spacing. Please check whether you have extraneous whitespace or nbsp characters in your input that might be causing this.

Section 3, "that it participates to" => "that it participates in" or "in which it participates"; "enables to decouple" => "enables decoupling"; "to stimulate the" => "to request"

Section 7.2, Should "The Status field that is used only when the EARO is placed in an NA message." be "The Status field is used only when the EARO is placed in an NA message."?

Section 7.4, "similar as" => "similar to that"; "it is of" => "it is"

[Ballot comment]
Hi Pascal,

Thanks for the the discussion and for taking care of most of the points in [1].

The pending point about I-flag will be discussed as part of my draft-ietf-6lo-updating-rfc-8928 ballot [2].

Cheers,
Med

[1] https://mailarchive.ietf.org/arch/msg/6lo/A8K5rsUHTcQvqgwS7KbeCjDUJdM/

[1] https://mailarchive.ietf.org/arch/msg/6lo/YHNtP6qllKSuJg3FtVgcUF8lWkI/

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-6lo-prefix-registration-12

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-6lo-prefix-registration-12.txt

# Many thanks for this write up. It is a non-trivial update touching many parts in various specifications. It represents a significant amount of detailed work.

# when running idnits there disclaimer message is observed. I didn't see this addressed in the shepherd writeup.

"
  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)
"

# section 4 suggests amending RFC4861, section 5 suggest extending RFC7400. But section 6 describes "Updating RFC6550". How is Updating any different from ammending or extending? Maybe that should be clarified in the section where amending/Extending is described? (note that other sections use Updating keyword)

# the text uses often the "*" to make a keyword appear *bold* in markdown. When reading that in text only it reads odd. Is that the intent? many tables are exposed to this idnit

# Detailed Review
# ===============

234   *Amends/Amended by:*  This tag pair is used with an amending RFC that
235           changes the amended RFC.  This could include bug fixes,
236           behavior changes etc.  This is intended to specify mandatory
237           changes to the protocol.  The goal of this tag pair is to
238           signal to anyone looking to implement the amended RFC that
239           they MUST also implement the amending RFC.
240   *Extends/Extended by:*  This tag pair is used with an extending RFC
241           that defines an optional addition to the extended RFC.  This
242           can be used by documents that use existing extension points or
243           clarifications that do not change existing protocol behavior.
244           This signals to implementers and protocol designers that there
245           are changes to the extended RFC that they need to consider but
246           not necessarily implement.

GV> I found this not easy to fully understand. I tried to reword this. Does this reworked definition work for you?

"
Amends / Amended by:
This tag pair is used when an RFC formally modifies the protocol behavior defined in another RFC. Such modifications may include corrections, updates to normative behavior, or other substantive changes. The presence of this tag pair indicates that the amending RFC introduces mandatory changes to the amended RFC. Implementers of the amended RFC MUST also implement the corresponding changes described in the amending RFC.

Extends / Extended by:
This tag pair is used when an RFC introduces an optional extension or clarification to another RFC, without altering its existing normative behavior. Such extensions may utilize defined extension points or provide additional informational content. The presence of this tag pair indicates that there are supplementary specifications or enhancements to consider. Implementation of the extending RFC is OPTIONAL, but protocol designers and implementers SHOULD be aware of its existence when working with the extended RFC.
"

302   SND:  Subnet Neighbor Discovery (protocol)

GV> idnit observation. The other entries in this list have "*" to make the keyword bold, but this SND keyword does accidently not have this

324   otherwise therein, the behavior of the 6LBR that acts as RPL Root, of

GV> The "6LBR" seems forgotten within the terminology list

473   [RFC9685] defines a 2-bits P-Field with values from 0 to 2, and
474   reserves value 3.  This specification defines value 3 for the
475   P-Field, and uses it to signal that the Registered Address is a
476   prefix.  When the P-Field is set to 3, the receiver installs a route
477   to the prefix via the sender's address used as source address in the
478   NS(EARO) registration message.
479
480   This specification assigns the value of 3, resulting in the complete
481   table as follows:

GV> What about the following? (i sneaked in a normative MUST):

"
[RFC9685] defines a 2-bit P-Field with values 0 through 2 and reserves the value 3 for future use. This specification defines the semantics of P-Field value 3.

When the P-Field is set to 3, it indicates that the Registered Address represents a prefix rather than a single address. Upon receiving an NS(EARO) message with the P-Field set to 3, the receiver MUST install a route to the indicated prefix via the source address of the NS(EARO) message.

This specification assigns the value 3 to the P-Field, resulting in the following complete set of defined values:
"

548   New and updated Option Fields:
549
550   *F:*  1-bit flag; set to 1 to indicate that the sender expects other
551       routers to forward packets to self when the packets are sourced
552       within the registered prefix.
553
554   *Prefix Length:*  7-bit integer; this field contains a prefix length
555       expressed in bits if the P-Field is set to 3 and the EARO is
556       placed in an NS message.  In that case the value MUST be between
557       16 and 120, both included.  The field contains a Status if the
558       EARO is placed in an NA message regardless of the setting of the P
559       flag.  In all other cases it is reserved, so it MUST be set to 0
560       by the sender and ignored by the receiver.
561
562   *r (reserved):*  1-bit reserved field; it MUST be set to zero by the
563       sender and MUST be ignored by the receiver.

GV> What about:

"
New and Updated Option Fields

F (Forwarding Flag):
A 1-bit flag. When set to 1, it indicates that the sender expects other routers to forward packets to the sender when those packets are sourced from within the registered prefix.

Prefix Length:
A 7-bit unsigned integer. When the P-Field is set to 3 and the EARO is included in a Neighbor Solicitation (NS) message, this field MUST contain a prefix length expressed in bits, with a value between 16 and 120 inclusive.
When the EARO is included in a Neighbor Advertisement (NA) message, this field MUST carry a Status value, regardless of the setting of the P-Field.
In all other cases, this field is reserved; it MUST be set to zero by the sender and MUST be ignored by the receiver.

r (Reserved):
A 1-bit reserved field. It MUST be set to zero by the sender and MUST be ignored by the receiver.
"

598   New and updated Option Fields:
589
600   *Reserved:*  6-bit field; reserved, MUST be set to 0 and ignored by
601       the receiver
602
603   *Prefix:*  15 bytes field; carries up to 120 bits of prefix, and MUST
604       be padded with zeros.  The padding MUST be overwritten with zeros
605       when the prefix is being used by the receiver.
606
607   *r:*  1-bit field; reserved, MUST be set to 0 and ignored by the
608       receiver
609
610   *Prefix Length:*  7-bit integer; signals the length of the prefix, in
611       bits.  The value MUST be at least 16 and at most 120.

GV> What about:

"
New and Updated Option Fields

Reserved:
A 6-bit field reserved for future use. It MUST be set to zero by the sender and MUST be ignored by the receiver.

Prefix:
A 15-byte field that carries up to 120 bits of the prefix. If the prefix is shorter than 120 bits, the remaining bits MUST be padded with zeros. The receiver MUST treat the padding as zeroed and MUST overwrite any unused bits with zeros before using the prefix.

r (Reserved):
A 1-bit field reserved for future use. It MUST be set to zero by the sender and MUST be ignored by the receiver.

Prefix Length:
A 7-bit unsigned integer indicating the length of the prefix in bits. The value MUST be in the inclusive range of 16 to 120.
"

Many thanks for this document,
Gunter Van de Velde,
Routing AD

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-6lo-prefix-registration-12

# The line numbers used are rendered from IETF idnits tool: https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-6lo-prefix-registration-12.txt

# Many thanks for this write up. It is a non-trivial update touching many parts in various specifications. It represents a significant amount of detailed work.

# when running idnits there disclaimer message is observed. I didn't see this addressed in the shepherd writeup.

"
  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)
"

# section 4 suggests amending RFC4861, section 5 suggest extending RFC7400. But section 6 describes "Updating RFC6550". How is Updating any different from ammending or extending? Maybe that should be claried in the section where amending/Extending is described? (note that other sections use Updating keyword)

# the text uses often the "*" to make a keyword appear *bold* in markdown. WHen reading that in text only it reads odd. Is that the intent? many tables are exposed to this idnit

# Detailed Review
# ===============

234   *Amends/Amended by:*  This tag pair is used with an amending RFC that
235           changes the amended RFC.  This could include bug fixes,
236           behavior changes etc.  This is intended to specify mandatory
237           changes to the protocol.  The goal of this tag pair is to
238           signal to anyone looking to implement the amended RFC that
239           they MUST also implement the amending RFC.
240   *Extends/Extended by:*  This tag pair is used with an extending RFC
241           that defines an optional addition to the extended RFC.  This
242           can be used by documents that use existing extension points or
243           clarifications that do not change existing protocol behavior.
244           This signals to implementers and protocol designers that there
245           are changes to the extended RFC that they need to consider but
246           not necessarily implement.

GV> I found this not easy to fully understand. I tried to reword this. Does this reworked definition work for you?

"
Amends / Amended by:
This tag pair is used when an RFC formally modifies the protocol behavior defined in another RFC. Such modifications may include corrections, updates to normative behavior, or other substantive changes. The presence of this tag pair indicates that the amending RFC introduces mandatory changes to the amended RFC. Implementers of the amended RFC MUST also implement the corresponding changes described in the amending RFC.

Extends / Extended by:
This tag pair is used when an RFC introduces an optional extension or clarification to another RFC, without altering its existing normative behavior. Such extensions may utilize defined extension points or provide additional informational content. The presence of this tag pair indicates that there are supplementary specifications or enhancements to consider. Implementation of the extending RFC is OPTIONAL, but protocol designers and implementers SHOULD be aware of its existence when working with the extended RFC.
"

302   SND:  Subnet Neighbor Discovery (protocol)

GV> idnit observation. The other entries in this list have "*" to make the keyword bold, but this SND keyword does accidently not have this

324   otherwise therein, the behavior of the 6LBR that acts as RPL Root, of

GV> The "6LBR" seems forgotten within the terminology list

473   [RFC9685] defines a 2-bits P-Field with values from 0 to 2, and
474   reserves value 3.  This specification defines value 3 for the
475   P-Field, and uses it to signal that the Registered Address is a
476   prefix.  When the P-Field is set to 3, the receiver installs a route
477   to the prefix via the sender's address used as source address in the
478   NS(EARO) registration message.
479
480   This specification assigns the value of 3, resulting in the complete
481   table as follows:

GV> What about the following? (i sneaked in a normative MUST):

"
[RFC9685] defines a 2-bit P-Field with values 0 through 2 and reserves the value 3 for future use. This specification defines the semantics of P-Field value 3.

When the P-Field is set to 3, it indicates that the Registered Address represents a prefix rather than a single address. Upon receiving an NS(EARO) message with the P-Field set to 3, the receiver MUST install a route to the indicated prefix via the source address of the NS(EARO) message.

This specification assigns the value 3 to the P-Field, resulting in the following complete set of defined values:
"

548   New and updated Option Fields:
549
550   *F:*  1-bit flag; set to 1 to indicate that the sender expects other
551       routers to forward packets to self when the packets are sourced
552       within the registered prefix.
553
554   *Prefix Length:*  7-bit integer; this field contains a prefix length
555       expressed in bits if the P-Field is set to 3 and the EARO is
556       placed in an NS message.  In that case the value MUST be between
557       16 and 120, both included.  The field contains a Status if the
558       EARO is placed in an NA message regardless of the setting of the P
559       flag.  In all other cases it is reserved, so it MUST be set to 0
560       by the sender and ignored by the receiver.
561
562   *r (reserved):*  1-bit reserved field; it MUST be set to zero by the
563       sender and MUST be ignored by the receiver.

GV> What about:

"
New and Updated Option Fields

F (Forwarding Flag):
A 1-bit flag. When set to 1, it indicates that the sender expects other routers to forward packets to the sender when those packets are sourced from within the registered prefix.

Prefix Length:
A 7-bit unsigned integer. When the P-Field is set to 3 and the EARO is included in a Neighbor Solicitation (NS) message, this field MUST contain a prefix length expressed in bits, with a value between 16 and 120 inclusive.
When the EARO is included in a Neighbor Advertisement (NA) message, this field MUST carry a Status value, regardless of the setting of the P-Field.
In all other cases, this field is reserved; it MUST be set to zero by the sender and MUST be ignored by the receiver.

r (Reserved):
A 1-bit reserved field. It MUST be set to zero by the sender and MUST be ignored by the receiver.
"

598   New and updated Option Fields:
589
600   *Reserved:*  6-bit field; reserved, MUST be set to 0 and ignored by
601       the receiver
602
603   *Prefix:*  15 bytes field; carries up to 120 bits of prefix, and MUST
604       be padded with zeros.  The padding MUST be overwritten with zeros
605       when the prefix is being used by the receiver.
606
607   *r:*  1-bit field; reserved, MUST be set to 0 and ignored by the
608       receiver
609
610   *Prefix Length:*  7-bit integer; signals the length of the prefix, in
611       bits.  The value MUST be at least 16 and at most 120.

GV> What about:

"
New and Updated Option Fields

Reserved:
A 6-bit field reserved for future use. It MUST be set to zero by the sender and MUST be ignored by the receiver.

Prefix:
A 15-byte field that carries up to 120 bits of the prefix. If the prefix is shorter than 120 bits, the remaining bits MUST be padded with zeros. The receiver MUST treat the padding as zeroed and MUST overwrite any unused bits with zeros before using the prefix.

r (Reserved):
A 1-bit field reserved for future use. It MUST be set to zero by the sender and MUST be ignored by the receiver.

Prefix Length:
A 7-bit unsigned integer indicating the length of the prefix in bits. The value MUST be in the inclusive range of 16 to 120.
"

Many thanks for this document,
Gunter Van de Velde,
Routing AD

[Ballot discuss]
I share the concerns of Ketan and Mohamed regarding the normative use of an individual internet draft that has no IETF consensus.
It would be better if only RFCs that are "updated" (as opposed to "extended") are given the Update: flag
The Update: tag also lists more RFCs than mentioned in the Abstract, so it seems something is still missing?


I am not a topic expert on this, so I hope the next two questions make sense. But:

In Figure 4, why is the F bit taken from the next 4 bytes, while there is still room in the Reserved space before that?

In Figure 5, what was taken up by the space of the F bit before this? It seems unlikely there was only a single unused bit there?

[Ballot discuss]
Thanks to the author and the WG for this very useful extension for Prefix Discovery in 6LoWPAN.

I have a couple of points that I would like to discuss to get some clarity on this document.

It is not clear if the specifications in this document are scoped only for 6LO deployment scenarios or are being made generically applicable/available for all of IPv6 ND deployment/usage even in "usual" networks across the Internet. The document claims to update RFC4861 but previous documents RFC 6775 and 8505 seem to be (at least to me) narrowly scoped to 6LO.

Note: Likely RFC 9685 also had the same ambiguity

This document claims to be updating a host of existing RFCs using the logic/argument presented in draft-kuehlewind-update-tag. That individual draft does not have IETF consensus and so I do not think it is appropriate to apply its rationale for the "update" tag for IETF RFCs. I have no objections on anyone using the terms (amend & extend) to clarify relationship with existing RFCs. However, this document also uses those terms along with the "updates" term and has a long list of document that it is claiming to "update".

Note: I am aware of at least one RFC 9685 that did similar actions and was approved by the previous IESG. Nevertheless, I would like to discuss this within the current IESG. My concerns with such usage is that it obfuscates the meaning of "update" tag and will makes the problem highlighted by draft-kuehlewind even worse. I worry how its application for a protocol like BGP will turn out to be.

[Ballot discuss]
Bonjour Pascal,

Thanks for the effort put into this specification with many "surgical" changes that manipulate various pieces.

Special thanks for Section 3. Note that some of these considerations (e.g., those discussing pre-requisites) are better moved to an operational considerations section.

# DISCUSS

## Consistency with 7400 and IANA registration


CURRENT:
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Type      |  Length = 1  |  Reserved    |X|A|D|L|B|P|E|G|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |F|                          Reserved                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                  Figure 4: New Capability Bit in the 6CIO

  New Option Field:

  *F:*  1-bit flag, set to 1 to indicate "Registration for prefixes
      Supported"

### Per https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#sixlowpan-capability-bits, the request should indicate a bit position.

### None of the entries in that registry updates 7400. Any specific reason why are we deviating from that practice?

### The fields indicated as “Reserved” in Figure are marked as unassigned (not reserved) in RFC7400: “Bits marked by underscores in Figure 5 are unassigned and available for future assignment.”. Some consistency is needed here vs. 7400

### Any reason why not any of the unassigned bits in the low range is used?

## New EARO Prefix Length Field and F flag

CURRENT:
      0                  1                  2                  3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |    Type      |    Length    |F|Prefix Length|    Opaque    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |r|C| P | I |R|T|    TID      |    Registration Lifetime    |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                              |
    ...                            ROVR                            ...
    |                                                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 5: EARO Option Format for Use in NS Messages

  New and updated Option Fields:

### Only PRT are defined in https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-adress-registration-option-flags. Where the flags are defined?

### RFC8505 says “MUST be set to 0 in NS messages”. How a legacy receiver will handle this updated EARO option? Will it be ignored? Rejected? Please consider adding some considerations to the backward compatibility section. Of course, adding a pointer to where this is already described would be sufficient. Thanks.

[Ballot comment]
# Consistency with Your Own Terminology on Amend/Extend

For example,

OLD: 4. Updating RFC 4861
NEW: 4. Amending RFC 4861

# Section 5:

CURRENT:
  5.  Extending RFC 7400

This is about associating a meaning with an unassigned value in a registry managed by IANA, not updating 7400.

The document says "[RFC7400] was already extended by [RFC8505]" but it does so without updating 7400.

# Section 7.1: Update 8505

The values are handled in an IANA registry: https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#p-field-values. Nothing is updated in 8505. Also, this field is defined in rfc9685, not 8505.

Why is this subsection provided under “Update 8505”?

# Section 12

Consider adding some deployment considerations. For example, how the various extensions are expected to be added to a network that is composed of nodes compliant with existing RFCs?

# NITS

## Abstract

### nits, expand acronyms, etc.

OLD:
  This document updates IPv6 Neighbor Discovery RFC4861 and the 6LoWPAN
  extensions (RFC8505, RFC8928, RFC8929, RFC7400) to enable a node that
  owns or is directly connected to a prefix to register that prefix to
  neighbor routers.  The registration indicates that the registered
  prefix can be reached via the advertising node without a loop.  The
  unicast prefix registration allows to request neighbor router(s) to
  redistribute the prefix in a larger routing domain regardless of the
  routing protocol used in the larger domain.  This document extends
  RPL (RFC6550, RFC6553, RFC9010) to enable the 6LR to inject the
  registered prefix in RPL.


NEW:
  This document updates IPv6 Neighbor Discovery (RFC 4861) and the 6LoWPAN
  extensions (RFC 8505, RFC 8928, RFC 8929, and RFC 7400) to enable a node that
  owns or is directly connected to a prefix to register that prefix to
  neighbor routers.  The registration indicates that the registered
  prefix can be reached via the advertising node without a loop.  The
  unicast prefix registration allows to request neighbor router(s) to
  redistribute the prefix in a larger routing domain regardless of the
  routing protocol used in that domain.  This document extends
  Routing Protocol for Low-Power and Lossy Networks (RPL) (RFC 6550,
  RFC 6553, and RFC 9010) to enable a 6LoWPAN Router (6LR) to inject the
  registered prefix in RPL.

### Large routing domain

What does that mean? Do we really need to mention that for injecting routes?

I would avoid that as this is a distraction at this stage.

# Introduction

### Stimulated

CURRENT:
  *  Unicast host to router operations stimulated by the host and its
      applications.

What does "stimulated” mean here? Do we mean “triggered”?

### (nits) There are many instance of 6LN/6LR

Consider making these changes:

OLD:
      unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA)
      messages between the 6LN and the 6LR.

NEW:
      unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA)
      messages between a 6LN and a 6LR.


OLD:
      [RFC9010] to enable the 6LR to inject the anycast and multicast
      addresses in RPL.  Similarly, this specification extends [RFC8505]
      and [RFC9010] to add the capability for the 6LN to register
      unicast prefixes as opposed to addresses, and to signal in a
      routing-protocol-independent fashion to the 6LR that it is
      expected to redistribute the prefixes.

NEW:
      [RFC9010] to enable a 6LR to inject the anycast and multicast
      addresses in RPL.  Similarly, this specification extends [RFC8505]
      and [RFC9010] to add the capability for a 6LN to register
      unicast prefixes as opposed to addresses, and to signal in a
      routing-protocol-independent fashion to a 6LR that it is
      expected to redistribute the prefixes.

There are other instances in the document that I think should be fixed as well.

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-6lo-prefix-registration-10. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are two actions which we must complete.

First, in the P-Field Values registry in the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry group located at:

https://www.iana.org/assignments/icmpv6-parameters/

a single new registration will be made as follows:

Value: [ TBD-at-Registration ]
Registered Address Type Indicator: Registration for a prefix
Reference: [ RFC-to-be ]

IANA notes that the authors have suggested a value of 3 for this new registration.

Second, in the 6LoWPAN Capability Bits registry also in the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry group located at:

https://www.iana.org/assignments/icmpv6-parameters/

a single new registration will be made as follows:

Bit: [ TBD-at-Registration ]
Description: F flag: Registration for prefixes Supported (F)
Reference: [ RFC-to-be ]

IANA notes that the authors suggest a value of 7 for this new registration.

IANA Question --> IANA notes that suggested value for this registration comes out of the range reserved for experimental use, but that the current Internet Draft is not experimental but in intended for the Standards Track. Is this intentional?

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-04-30):

From: The IESG
To: IETF-Announce
CC: 6lo-chairs@ietf.org, 6lo@ietf.org, draft-ietf-6lo-prefix-registration@ietf.org, evyncke@cisco.com, shwetha.bhandari@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IPv6 Neighbor Discovery Prefix Registration) to Proposed Standard


The IESG has received a request from the IPv6 over Networks of
Resource-constrained Nodes WG (6lo) to consider the following document: -
'IPv6 Neighbor Discovery Prefix Registration'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-04-30. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document updates IPv6 Neighbor Discovery RFC4861 and the 6LoWPAN
  extensions (RFC8505, RFC8928, RFC8929, RFC7400) to enable a node that
  owns or is directly connected to a prefix to register that prefix to
  neighbor routers.  The registration indicates that the registered
  prefix can be reached via the advertising node without a loop.  The
  unicast prefix registration allows to request neighbor router(s) to
  redistribute the prefix in a larger routing domain regardless of the
  routing protocol used in the larger domain.  This document extends
  RPL (RFC6550, RFC6553, RFC9010) to enable the 6LR to inject the
  registered prefix in RPL.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-6lo-prefix-registration/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

This uses the shepherd write-up template version dated 4 July 2022.

Below are the answers to the shepherd’s questions regarding this document.

## Document History

1. **Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?**
The working group consensus was broad. In discussions on the 6LoWPAN and RPL mailing lists, most participants actively contributed to the evolution of the draft. There was general agreement on the need to extend address registration to cover prefixes, and improvements were made iteratively based on widespread feedback rather than the viewpoints of only a few individuals.

2. **Was there controversy about particular points, or were there decisions where the consensus was particularly rough?**

While some discussion took place regarding the use and encoding of the new flags (for example, the F flag and the extended use of the P-field for prefix registrations), the WG discussions were productive. The alternative approaches were debated with data and simulation results where available. In the end, the consensus reflected a balanced choice that improved backward compatibility and interoperability with existing implementations. There were no extremely contentious points or rough consensus blocks.

3. **Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)**

To date, there have been no threats of appeal or indications of extreme discontent regarding this document.

4. **For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)?**

While the document provides a comprehensive framework for prefix registration, there are currently no known implementations.

## Additional Reviews

5. **Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.**
This document closely interacts with technologies developed in other IETF working groups, particularly those related to IPv6 Neighbor Discovery and RPL (Routing Protocol for Low-Power and Lossy Networks). Reviews from these 6man h have been solicited and incorporated to ensure compatibility and coherence across protocols. Also early GenART and INTDir directorates have been consulted and completed early reviews.

6. **Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.**
The document does not specify the need for formal expert reviews such as MIB Doctor or YANG Doctor.

7. **If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]?**
The document does not contain a YANG module.

8. **Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.**

The document primarily details protocol extensions and updated message formats, rather than formal encodings such as CBOR’s CDDL or BNF rules. Automated text checks (using idnits for instance) have been run and minor nits were addressed in the revision process. There were no unresolved issues with formal syntax present in the document.

## Document Shepherd Checks

9. **Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?**

Based on my review, the document is well-written, complete, and correctly designed. It effectively addresses the need for prefix registration in IPv6 Neighbor Discovery and is ready for submission to the responsible Area Director.

10. **Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?**
Common issues related to normative versus informative references, clarity in terminology, and security considerations have been identified and addressed in the draft. Specific checks against the IETF's "Content Guidelines" have been performed, ensuring compliance with RFC formatting and reference standards.

11. **What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?**

The document is intended for publication as a Standards Track RFC. This designation is appropriate given its purpose to update existing standards (RFC4861, RFC8505, RFC8928, RFC7400) and define new normative behaviors. The Datatracker state attributes accurately reflect this intent.

12. **Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.**

All authors have been reminded of their IPR disclosure obligations as described in BCP 79. To the best of my knowledge, no IPR disclosures have been filed related to this document.

13. **Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.**
The sole author, Pascal Thubert, has confirmed his willingness to be listed as such.

14. **Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)**
The document has been reviewed using the idnits tool. No significant issues were found, and any minor nits have been addressed in the current version.

15. **Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16].**
The references have been reviewed to ensure appropriate classification as normative or informative. No changes are necessary.

16. **List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?**
All normative references are to RFCs and publicly avaiable documents.

17. **Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them.**

There are no normative downward references in this document.

18. **Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?**
No, all normative references are to existing RFCs. There are no references to documents in an unclear state that would impact the publication of this draft.

19. **Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.**

Yes, this document updates RFC 4861, RFC 6550, RFC 6553, RFC 7400, RFC 8505, RFC 8928 and RFC 9010. The Datatracker metadata correctly reflects this, and these RFCs are listed in the title page and discussed in the abstract and introduction. The relationship to these RFCs is explicitly covered in the document, ensuring clarity on how this update affects them.

20. **Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocation procedures, and a reasonable name (see [RFC 8126][11]).**

    The IANA considerations section has been reviewed for consistency with the document body. It correctly specifies updates to existing IANA registries. All referenced IANA registries are clearly identified, and any new registry follows the guidelines in RFC 8126. The document provides clear instructions for allocations, ensuring smooth implementation.

21. **List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.**
No new IANA registries are being created; instead, existing registries are being updated with new values. As such, there are no additional Designated Expert Reviews required beyond those applicable to the **ICMPv6 Parameters** and **6LoWPAN Capability Bits** registries. The instructions provided to the designated experts are clear and adhere to standard IANA procedures.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

This uses the shepherd write-up template version dated 4 July 2022.

Below are the answers to the shepherd’s questions regarding this document.

## Document History

1. **Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement?**
The working group consensus was broad. In discussions on the 6LoWPAN and RPL mailing lists, most participants actively contributed to the evolution of the draft. There was general agreement on the need to extend address registration to cover prefixes, and improvements were made iteratively based on widespread feedback rather than the viewpoints of only a few individuals.

2. **Was there controversy about particular points, or were there decisions where the consensus was particularly rough?**

While some discussion took place regarding the use and encoding of the new flags (for example, the F flag and the extended use of the P-field for prefix registrations), the WG discussions were productive. The alternative approaches were debated with data and simulation results where available. In the end, the consensus reflected a balanced choice that improved backward compatibility and interoperability with existing implementations. There were no extremely contentious points or rough consensus blocks.

3. **Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)**

To date, there have been no threats of appeal or indications of extreme discontent regarding this document.

4. **For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942][3] recommends) or elsewhere (where)?**

While the document provides a comprehensive framework for prefix registration, there are currently no known implementations.

## Additional Reviews

5. **Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place.**
This document closely interacts with technologies developed in other IETF working groups, particularly those related to IPv6 Neighbor Discovery and RPL (Routing Protocol for Low-Power and Lossy Networks). Reviews from these 6man h have been solicited and incorporated to ensure compatibility and coherence across protocols. Also early GenART and INTDir directorates have been consulted and completed early reviews.

6. **Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.**
The document does not specify the need for formal expert reviews such as MIB Doctor or YANG Doctor.

7. **If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools][4] for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342][5]?**
The document does not contain a YANG module.

8. **Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.**

The document primarily details protocol extensions and updated message formats, rather than formal encodings such as CBOR’s CDDL or BNF rules. Automated text checks (using idnits for instance) have been run and minor nits were addressed in the revision process. There were no unresolved issues with formal syntax present in the document.

## Document Shepherd Checks

9. **Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director?**

Based on my review, the document is well-written, complete, and correctly designed. It effectively addresses the need for prefix registration in IPv6 Neighbor Discovery and is ready for submission to the responsible Area Director.

10. **Several IETF Areas have assembled [lists of common issues that their reviewers encounter][6]. For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews?**
Common issues related to normative versus informative references, clarity in terminology, and security considerations have been identified and addressed in the draft. Specific checks against the IETF's "Content Guidelines" have been performed, ensuring compliance with RFC formatting and reference standards.

11. **What type of RFC publication is being requested on the IETF stream ([Best Current Practice][12], [Proposed Standard, Internet Standard][13], [Informational, Experimental or Historic][14])? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent?**

The document is intended for publication as a Standards Track RFC. This designation is appropriate given its purpose to update existing standards (RFC4861, RFC8505, RFC8928, RFC7400) and define new normative behaviors. The Datatracker state attributes accurately reflect this intent.

12. **Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79][7]? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable.**

All authors have been reminded of their IPR disclosure obligations as described in BCP 79. To the best of my knowledge, no IPR disclosures have been filed related to this document.

13. **Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification.**
The sole author, Pascal Thubert, has confirmed his willingness to be listed as such.

14. **Document any remaining I-D nits in this document. Simply running the [idnits tool][8] is not enough; please review the ["Content Guidelines" on authors.ietf.org][15]. (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.)**
The document has been reviewed using the idnits tool. No significant issues were found, and any minor nits have been addressed in the current version.

15. **Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References][16].**
The references have been reviewed to ensure appropriate classification as normative or informative. No changes are necessary.

16. **List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references?**
All normative references are to RFCs and publicly avaiable documents.

17. **Are there any normative downward references (see [RFC 3967][9] and [BCP 97][10]) that are not already listed in the [DOWNREF registry][17]? If so, list them.**

There are no normative downward references in this document.

18. **Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion?**
No, all normative references are to existing RFCs. There are no references to documents in an unclear state that would impact the publication of this draft.

19. **Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed.**

Yes, this document updates RFC 4861, RFC 6550, RFC 6553, RFC 7400, RFC 8505, RFC 8928 and RFC 9010. The Datatracker metadata correctly reflects this, and these RFCs are listed in the title page and discussed in the abstract and introduction. The relationship to these RFCs is explicitly covered in the document, ensuring clarity on how this update affects them.

20. **Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocation procedures, and a reasonable name (see [RFC 8126][11]).**

    The IANA considerations section has been reviewed for consistency with the document body. It correctly specifies updates to existing IANA registries. All referenced IANA registries are clearly identified, and any new registry follows the guidelines in RFC 8126. The document provides clear instructions for allocations, ensuring smooth implementation.

21. **List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate.**
No new IANA registries are being created; instead, existing registries are being updated with new values. As such, there are no additional Designated Expert Reviews required beyond those applicable to the **ICMPv6 Parameters** and **6LoWPAN Capability Bits** registries. The instructions provided to the designated experts are clear and adhere to standard IANA procedures.


[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/