IPv6 Neighbor Discovery Multicast and Anycast Address Listener Subscription
draft-ietf-6lo-multicast-registration-19

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

Special thanks to the author, Pascal Thubert, as he has replied to all COMMENTS and implemented the suggested changes.

Other thanks for the very detailed review by John Scudder (and of course to the other reviewers).

[Ballot comment]
Thanks for working on this specification. Thanks to Kyle Rose for his TSVART review. Based on that review and mine I am balloting no objection.

[Ballot comment]
In Section 7.3:

  A device that wishes to refresh its state, e.g., upon reboot if it
  may have lost some registration state, SHOULD send an asynchronous
  NA(EARO) with this new status value. That asynchronous multicast
  NA(EARO) SHOULD be sent to the all-nodes link scope multicast address
  (ff02::1) and Target MUST be set to the link local address that was
  exposed previously by this node to accept registrations

"SHOULD" gives me a choice.  So if I want to refresh my state, but I don't do those things, has my state still been reset?  I'm not sure you want SHOULD here, and it feels like at least one of these needs to be MUST, or you could just change "SHOULD send" to "sends" to make it normal behavior when wants to reset state.

In Section 2.3, you define these terms, but never use them: 6BBR, AMC, AMR.

[Ballot comment]
Thanks for this document. I enjoyed reading it, although some of it was fairly heavy going. I have several comments I hope may be helpful to you.

### Section 1, please expand DIO

                            The mode is signaled in the Mode of
  Operation (MoP) field in the DIO messages and applies to the whole
  RPL Instance.

You do define DIO in your glossary, but since it comes later in the document, I suggest you expand it here anyway. (Also, you use mixed case for "MoP" here but mostly all-upper "MOP" elsewhere.)

### Section 1, please expand ULP

  is up to the ULP to cope with both situations.

Please expand/define.

### Section 2.3, MOP

You use the acronym "MOP" in quite a few places. Consider adding it to your glossary.

### Section 3, conserves

  As opposed to unicast addresses, there might be multiple
  registrations from multiple parties for the same address.  The router
  conserves one registration per party per multicast or anycast
  address, but injects the route into the routing protocol only once
  for each address, asynchronously to the registration.
 
I don't find the meaning of the second sentence very clear, in particular, I don't think the verb "conserves" is common in this context. I guess what you mean is something like "retains" or "stores"?

### Section 3, please define DMB

Figure 1 has "DMB link". DMB isn't defined anywhere in the document.

### Section 3, Figure 1

Figure 1 is *relatively* self-explanatory and I found it useful to look at. However, it was a little strange that it's not mentioned in the prose at all.

### Section 3, EVPN isn't a routing protocol

                                        or redistributed in a full-
  fledged routing protocol such as EVPN
 
EVPN isn't a routing protocol per se. It's a "solution", specifically a "BGP MPLS-based solution" per [RFC7432 Section 1]. A minimal fix might be to change the quoted text to "or redistributed in a full-fledged routing protocol such as might be done in EVPN".

### Section 3, nit, "has"

                          The device mobility can be gracefully
  supported as long has the routers can exchange and make sense of the
  sequence counter in the TID field of the EARO.

"has" should be "as"

### Section 3, "as for"

I found this sentence quite hard to follow:

              As for the unicast address registration, the subscription
  to anycast and multicast addresses is agnostic to the routing
  protocol in which this information may be redistributed, though
  protocol extensions would be needed in the protocol when multicast
  services are not available.

After reading it a few times, I think your intent is captured if we change "as for" to "as with"? That is to say, you're saying that anycast and multicast follow the same pattern as unicast does?

### Section 3, "therein"

Did you mean "herein"?

  This specification also Extends [RFC6550] and [RFC9010] in the case
  of a route-over multilink subnet based on the RPL routing protocol,
  to add multicast ingress replication in Non-Storing Mode and anycast
  support in both Storing and Non-Storing modes.  A 6LR that implements
  the RPL extensions specified therein MUST also implement [RFC9010].
                                ^^^^^^^

### Section 6.1, toggling between 1 and 2 descendants

  A RPL router maintains a remaining Path Lifetime for each DAO that it
  receives for a multicast target, and sends its own DAO for that
  target with the longest remaining lifetime across its listening
  children.  If the router has only one descendant listening, it
  propagates the TID and ROVR as received.  Conversely, if the router
  merges multiple advertisements (including possibly one for self as a
  listener), the router uses its own ROVR and TID values.

If I understand this correctly, it implies that in the situation where you go from one descendent to two, or from two to one, you have to withdraw the old TID and ROVR and announce new ones. This seems to me to be worth a sentence spelling it out.

Also, it has the potential to be kind of chatty in the edge case, but I'm not saying anything needs to be done about that, necessarily.

### Section 7.2, s/DAC/DAR/

  Section 4 of [RFC6775] provides the same format for DAR and DAC
  messages but the status field is only used in DAC message and has to
  set to zero in DAC messages.
 
Should be "set to zero in DAR messages", right? (Also, "in DAC messages", plural.)

### Section 7.3, only unicast addresses

  [RFC8505] specifies the following behaviours:

...

  *  Only unicast addresses can be registered.

...

  This specification adds the following behavior:

You're not just adding new behaviors, right, you're also revising old ones? In particular, the restriction I've quoted no longer holds. It's probably clear enough from context what you're trying to say, which is why this isn't a DISCUSS, but it seems worth trying to be more precise if we can figure out how. One way, which is inelegant but has the merit of being straightforward, would be something like,

NEW:
  [RFC8505] specifies that only unicast addresses can be registered.
  This specification removes that restriction and adds procedures for
  registering multicast and anycast addresses.

### Section 7.3, lollipops and other confectionary

In a couple of places in this section you reference lollipops. I don't know if I would find this term defined if I went to one of the underlying specifications, but it sure isn't defined here, and it's not a standard enough term of art to use it without defining it, IMO.

### Section 7.3, ???

I wasn't able to understand this paragraph:

      The multicast NA(EARO) SHOULD be resent enough times for the TID
      to be issued with the value of 255 so the next NA(EARO) after the
      initial series is outside the lollipop and not confused with a
      reboot.  A 6LN that has recently processed the multicast NA(EARO)
      indicating "Registration Refresh Request" ignores the next
      multicast NA(EARO) with the same status and a newer TID received
      within the duration of the initial series.

Maybe it would be sufficiently clear to the intended audience of this document, but I thought I should flag it.

### Section 7.3, the other way around

                                        If the value of the P-Field is
      not consistent with the Registered Address, e.g., the Registered
      Address is a multicast address (section 2.4 of [RFC4291]) and the
      P-Field indicates a value that is not 1, or the other way around,
      then the message, NS(EARO) or EDAR, MUST be dropped, and the
      receiving node MAY either reply with a status of 12 "Invalid
      Registration" or remain silent.

As written this is ambiguous, I think because you are trying to construct a new example case by substitution, but the referent of "the other way around" is itself ambiguous. I think what you mean is, in the e.g.,

- the Registered Address is a multicast address and the
  P-Field indicates a value that is not 1, or
- the Registered Address is not a multicast address and the
  P-Field indicates a value that is 1.
 
Is that right? If so, I suggest spelling it out for clarity. Also, do you really mean "e.g.", that is to say, is this only an example, and there might be other "not consistent" cases you expect an implementation to cover, but you don't want to exhaustively list them? If it is just an example, an even simpler fix would be to just get rid of "or the other way around", since you're not attempting to be exhaustive anyway.

### Section 7.3, all-nodes link-scope

  *  The 6LN MUST also subscribe all the IPv6 multicast addresses that
      it listens to but the all-nodes link-scope multicast address
      ff02::1 [RFC4291] which is implicitly registered, and it MUST set
      the P-Field to 1 in the EARO for those addresses.
     
That doesn't make sense as written, or at best is ambiguous. Would it be correct to rewrite it as,

NEW:
  *  The 6LN MUST also subscribe all the IPv6 multicast addresses that
      it listens to, other than the all-nodes link-scope multicast address
      ff02::1 [RFC4291] which is implicitly registered, and it MUST set
      the P-Field to 1 in the EARO for those addresses.

(replaced "but" with ", other than")

Also, in many places where you use "subscribe", I feel like you should use "subscribe to", but I expect the RFC Editor will fix this if they agree with me so I'm not calling the cases out.

### Section 7.3, SLLAO? LMAO!

But seriously, please gloss it or expand it in line.

  *  The 6LR MUST also consider that all the nodes that registered an
      address to it (as known by the SLLAO) also registered to the all
      nodes link-scope multicast address ff02::1 [RFC4291].

### Section 8, only unicast routes

  *  The 6LR injects only unicast routes in RPL

Similar point to my previous "Section 7.3, only unicast addresses".

### Section 8, nodes or node?

In this,

  *  Upon receiving a packet directed to a unicast address for which it
      has an active registration, the 6LR delivers the packet as a
      unicast layer-2 frame to the LLA the nodes that registered the
      unicast address.

do you mean,

  *  Upon receiving a packet directed to a unicast address for which it
      has an active registration, the 6LR delivers the packet as a
      unicast layer-2 frame to the LLA of the node that registered the
      unicast address.

That is, node singular and not nodes plural, plus added a needed "of".

### Section 9, addresses used to source traffic

                                            Also, anycast and multicast
  addresses are not used to source traffic.
 
Surely not? An anycast address is just a unicast address with delusions of grandeur. It's both legal and expected for it to sometimes appear as the SA. I think the rest of the section can stand alone without this statement, so one fix would be to just delete it. Or, fix it. Or explain to me why it doesn't need to be fixed.

### Section 10, nit, ordering of field descriptions

It would be nice if the fields were described in the order in which they occur in the diagram.

### Section 10, 2-exponent

IMO "2-exponent" is a little terse/slangy. "Exponent to the base 2", perhaps.

### Section 10, prepositions are so annoying

"2 at the power of" should be "2 to the power of".

### Section 10, Epoch

                                                  The receiver derives
  the boot time of the sender as the current Epoch minus the sender's
  Consistent Uptime.

Don't you mean, "the current time"? If you do mean https://en.wikipedia.org/wiki/Epoch_(computing), please say more.

### Section 10, state must be reassessed

  If the boot time of the sender is updated to a newer time, any state
  that was installed in the sender MUST be reassessed and reinstalled
  if it is missing but still needed.
 
I think I get what you're telling me to do here, but I also think you're asking the reader to do too much work and in particular, to exercise their creativity and imagination, always dangerous. I think what you're saying is, that if I receive a message that tells me the sender has updated their boot time, I (who is not the sender!) have to reassess state, and resend it if I think the sender has lost it.

(Also in that same paragraph you have a "the the".)

### Section 10, s/if/of/

I think "The value if the uptime" is supposed to be "The value of the uptime", right?

### Section 10, can you be more prescriptive?

  Any change in the value of the NSSI from a node is an indication that
  the node updated some state and that the needful state should be
  reinstalled, e.g., addresses that where formed based on an RA with a
  previous NSSI should be reassessed, and the registration state
  updated in the peer.

Once again I'm a little concerned that you're inviting the reader to exercise creativity and imagination. If this is what the WG decided is both appropriate and sufficient, I won't stand in the way, but I did think I should point it out.

### Section 11, s/and//

Should

  *  The RPL routers that support the mixed mode and are configured to
      operate in in accordance with the desired operation in the
      network.

instead be

  *  The RPL routers that support the mixed mode are configured to
      operate in accordance with the desired operation in the
      network.

(Deleted "and", and also fixed "in in".). If that isn't the right fix, can you please explain further?

### Section 12, not prescribed

  RPL network, since the nodes that do not really need to speak RPL, or
  are not trusted enough to inject RPL messages, can be prescribed from
  doing so, which bars a number of attacks Vectors from within RPL.

I guess you probably meant "proscribed"? But I would suggest using "forbidden", "prevented", etc, instead. If you did mean "prescribed", please help me understand.

### Section 12, ROV

  multicast subscription inside the RPL network.  This is a first step
  to enable Route Ownership Validation (ROV) in RPL using the ROVR

I devoutly hope that the abbreviation ROV isn't already well-established for this use, because it's a potentially a problematic collision with (BGP, RPKI) Route Origin Validation (ROV) which is already in wide use. Come to think of it, I don't know what Route Ownership Validation is... but maybe you actually did mean Route Origin Validation, in which case make that edit and also it would probably be appropriate to add an informative reference to RFC 6811. (In looking back at RFC 6811, I was reminded that we foolishly titled it "Prefix Origin Validation" even though the technology is universally referred to as ROV. Ah well.)

### Section 15, thanking Mx Ellipsis

  The Editor wishes to thank ...  and Esko Dijk for their useful WGLC
  reviews and proposed changes.

Did you really mean to thank Mx Ellipsis?

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

** Use of draft-kuehlewind-rswg-updates-tag language.  The document goes to the trouble of using this nuanced approach to the update tag, but then inconsistently applies.  For example:

-- Section 4 and 6 are titled “Updating …” and later in the body of the text use the amends/extends from draft-kuehlewind-rswg-updates-tag to more precisely described the document relationship. However, Section 5 uses a tag type from draft-kuehlewind-rswg-updates-tag directly in the title with “Extends …”. 

-- Section 8 doesn’t seem to use either amends or extend to explain how the “Updating …” is occurring.

** Section 10.  Editorial. Why are the field descriptions not consistent with the order in which they appear (i.e., why is exponent and mantissa at the end?)?

[Ballot comment]
This is a bit far outside the field of my expertise, but I did have one question.

In section 6.4. New Registered Address Type Indicator P-Field, the value '3' states:

    Reserved, MUST be ignored by the receiver.

But that means that the packet is not any of the "Registration" values, so I am not sure
what "MUST ignore" means? Wouldn't the entire packet be invalid, eg some kind of error?
That is not really the same as "ignore" which implies "continue with the other valid values"

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

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

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

First, a new registry is to be created called the P-Field values registry. The new registry will be located in the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry group located at:

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

The new registry will be managed via Standards Action as defined by RFC8126. There are initial values in the new registry as follows:

Value Registered Address Type Indicator Reference
-----+-----------------------------------+---------------
0 Registration for a Unicast Address [ RFC-to-be ]
1 Registration for a Multicast Address [ RFC-to-be ]
2 Registration for an Anycast Address [ RFC-to-be ]
3 Unassigned [ RFC-to-be ]

Second, a new registry is to be created called the EDAR Message Flags registry. The new registry will be located in the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry group located at:

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

The new registry will be managed via IETF Review or IESG Approval as defined by RFC8126. There are initial values in the new registry as follows:

Bit Number Meaning Reference
-----------+--------+----------
0..1 P-Field (2 bits) [ RFC-to-be; Section 14.1 ]
2..7 Unassigned

Third, in the Address Registration Option Flags 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:

Bit Number: 2..3
Meaning: P-Field (2 bits)
Reference: [ RFC-to-be; Section 14.1 ]

Fourth, in the RPL Target Option Flags registry in the Routing Protocol for Low Power and Lossy Networks (RPL) registry group located at:

https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-target-option-flags

a single new registration is to be made as follows:

Bit Number: 2..3
Meaning: P-Field (2 bits)
Reference: [ RFC-to-be; Section 14.1 ]

Fifth, in the Mode of Operation registry also in the Routing Protocol for Low Power and Lossy Networks (RPL) registry group located at:

https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-target-option-flags

a single new registration will be made as follows:

Value: 5
Description: Non-Storing Mode of Operation with ingress replication multicast support
Reference: [ RFC-to-be ]

Sixth, in the 6LoWPAN Capability Bits 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:

Bit: 8
Meaning: X flag: Registration for Unicast, Multicast, and Anycast Addresses Supported
Reference: [ RFC-to-be ]

Seventh, in the Address Registration Option Status Values registry in the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry group located at:

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

two new registrations will be made as follows:

Value: 11
Description: Registration Refresh Request
Reference: [ RFC-to-be ]

Value: 12
Description: Invalid Registration
Reference: [ RFC-to-be ]

Eighth, in the IPv6 Neighbor Discovery Option Formats registry also in the Internet Control Message Protocol version 6 (ICMPv6) Parameters registry group located at:

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

two new registrations will be made as follows:

Value: 42
Description: Consistent Uptime Option
Reference: [ RFC-to-be ]

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 2024-03-05):

From: The IESG
To: IETF-Announce
CC: 6lo-chairs@ietf.org, 6lo@ietf.org, draft-ietf-6lo-multicast-registration@ietf.org, ek.ietf@gmail.com, shwetha.bhandari@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (IPv6 Neighbor Discovery Multicast and Anycast Address Listener Subscription) 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 Multicast and Anycast Address Listener
  Subscription'
  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 2024-03-05. 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 the 6LoWPAN extensions to IPv6 Neighbor
  Discovery (RFC 4861, RFC 8505) to enable a listener to subscribe to
  an IPv6 anycast or multicast address; the document updates RPL (RFC
  6550, RFC 6553) to add a new Non-Storing Multicast Mode and a new
  support for anycast addresses in Storing and Non-Storing Modes.  This
  document extends RFC 9010 to enable the 6LR to inject the anycast and
  multicast addresses in RPL.




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


The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/5263/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc9030: An Architecture for IPv6 over the Time-Slotted Channel Hopping Mode of IEEE 802.15.4 (6TiSCH) (Informational - Internet Engineering Task Force (IETF))

# Internet AD comments for draft-ietf-6lo-multicast-registration-15
CC @ekline

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

## Comments

### General

* The idnits tools highlights this disclaimer text issue:

"""
  (Using the creation date from RFC4861, updated by this document, for
  RFC5378 checks: 2004-07-16)

-- 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.)
"""

  Do we already know if an author of 4861 has granted BCP78 rights?  If not,
  should this document use the pre-5378 disclaimer?

  Separately: I will take an action item to reach out to RFC 4861 authors
  to see if any have already dealt with this BCP78 rights grant.

### S6

* "This specification Extends RFC6550 to require that"

  This paragraph doesn't have any capitalized normative language.  Should
  this be reworded to get "REQUIRED" in here somewhere?

### S6.4, S6.5, S7.1, S7.2

* Can you explain why there are 2 bit used here instead of just 1?

  Whether an address is multicast or not can be determined by inspecting
  the address itself.  We should only need 1 bit to distinguish unicast
  from anycast... right?

* What is supposed to happen if the address is a multicast address but the
  flags indicate unicast/anycast?  Or vice versa?

### S10

* What is the benefit of including a representation of the uptime?

  It seems like the primary comparison to be used is:

      (this NSSI != the last NSSI seen) : yes or no

  rather than performing uptime calculations.

  Is it simpler to drop this and expand the bits available for the two
  NSSI fields?  This would then be a more generic "generation number
  option."

## Nits

### S3

* I found the wording of "there is no concept of duplication" to be a bit
  awkward.  Perhaps something like "there is no restriction on duplication".

* "so it generally discouraged" -
  "so is generally discouraged"

### S6.1

* "allows to hybrid" ->
  "allows hybrid use of"

### S7.3

* s/FF02::1/ff02::1/g

  (per RFC 5952 S4.3)

### S10

* "then the NSSI is randomly generated loss"

  Does this really mean just "randomly generated"?

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## 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?
It received feedback and support from 6lo participants. It was jointly reviewed with ROLL workgroup.
6man was also included in the notifications and review.

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

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.)
No

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)?
This document was developed for Wi-Sun and is incorporated in Wi-Sun FAN 1.1.
So all products that conform FAN 1.1 will also conform this.

## 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.
ROLL and 6man reviewed the draft. WGLC received feedback from participants in 6lo, ROLL and 6man.
This draft addresses review feedback received from all workgroups.

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.
Not applicable. The document extending IPv6 ND flags and options to support this. The request is reviewed by the 6man workgroup.

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]?
Not applicable.

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.
Not applicable.

## 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?
Yes.

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?
https://wiki.ietf.org/group/int/IntAreaIssues has been discussed and 6man involved for the changes.


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?
Proposed Standard. It is appropriate as it modifies protocol for the deployment it is intended for.

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.
Yes. https://mailarchive.ietf.org/arch/msg/6lo/HoNzI1U2fwgHqICE9kV7UQhf-uc/ has been disclosed by the author.

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.
This document has a single author.

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.)
Authors were notified on I-D nits found in -14 and it is fixed in -15.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None

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.
None

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

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. It updates: 4861, 6550, 6553, 8505, 9010.


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,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
Edits were suggested as part of shepherd review of -14 and have been addressed in -15.
    a) Section 10 defines Consistent Uptime Option (CUO) however IANA registration refers to it as Node Uptime Option
    b) Section 14.3 lists 4 and 5"I" Field RFC 8505 that is already registered, this line is redundant in the IANA section of this document
    c) "P-field values" registry in the IANA request - a more descriptive name for the registry that reflects its purpose for e.g. Address Registration Indicator field?


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.
None needed

[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 version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## 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?
It received feedback and support from 6lo participants. It was jointly reviewed with ROLL workgroup.
6man was also included in the notifications and review.

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

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.)
No

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)?
This document was developed for Wi-Sun and is incorporated in Wi-Sun FAN 1.1.
So all products that conform FAN 1.1 will also conform this.

## 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.
ROLL and 6man reviewed the draft. WGLC received feedback from participants in 6lo, ROLL and 6man.
This draft addresses review feedback received from all workgroups.

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.
Not applicable. The document extending IPv6 ND flags and options to support this. The request is reviewed by the 6man workgroup.

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]?
Not applicable.

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.
Not applicable.

## 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?
Yes.

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?
https://wiki.ietf.org/group/int/IntAreaIssues has been discussed and 6man involved for the changes.


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?
Proposed Standard. It is appropriate as it modifies protocol for the deployment it is intended for.

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.
Yes. https://mailarchive.ietf.org/arch/msg/6lo/HoNzI1U2fwgHqICE9kV7UQhf-uc/ has been disclosed by the author.

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.
This document has a single author.

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.)
Authors were notified on I-D nits found in -14 and it is fixed in -15.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None

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.
None

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

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. It updates: 4861, 6550, 6553, 8505, 9010.


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,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
Edits were suggested as part of shepherd review of -14 and have been addressed in -15.
    a) Section 10 defines Consistent Uptime Option (CUO) however IANA registration refers to it as Node Uptime Option
    b) Section 14.3 lists 4 and 5"I" Field RFC 8505 that is already registered, this line is redundant in the IANA section of this document
    c) "P-field values" registry in the IANA request - a more descriptive name for the registry that reflects its purpose for e.g. Address Registration Indicator field?


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.
None needed

[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 version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## 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?
It received feedback and support from 6lo participants. It was jointly reviewed with ROLL workgroup.
6man was also included in the notifications and review.

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

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.)
No

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)?

## 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.
ROLL and 6man reviewed the draft. WGLC received feedback from participants in 6lo, ROLL and 6man.
-14 version of the draft addresses review feedback received from all workgroups.

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.
Not applicable. The document extending IPv6 ND flags and options to support this. The request is reviewed by the 6man workgroup.

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]?
Not applicable.

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.
Not applicable.

## 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?
Yes.

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?
https://wiki.ietf.org/group/int/IntAreaIssues has been discussed and 6man involved for the changes.


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?
Proposed Standard. It is appropriate as it modifies protocol for the deployment it is intended for.

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.
Yes. https://mailarchive.ietf.org/arch/msg/6lo/HoNzI1U2fwgHqICE9kV7UQhf-uc/ has been disclosed by the author.

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.
This document has a single author.

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.)
Authors are notified on I-D nits found in -14. -15 expected to address this

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
Normative reference to an informational document: RFC 9030

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None

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.
None

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

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. It updates: 4861, 6550, 6553, 8505, 9010.
6553 is not mentioned in introduction or abstract


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,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
Edits needed
    a) Section 10 defines Consistent Uptime Option (CUO) however IANA registration refers to it as Node Uptime Option
    b) Section 14.3 lists 4 and 5"I" Field RFC 8505 that is already registered, this line is redundant in the IANA section of this document
    c) "P-field values" registry in the IANA request - a more descriptive name for the registry that reflects its purpose for e.g. Address Registration Indicator field?


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.
None needed

[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 version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## 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?
It received feedback and support from 6lo participants. It was jointly reviewed with ROLL workgroup.
6man was also included in the notifications and review.

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

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.)
No

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)?

## 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.
ROLL and 6man reviewed the draft. WGLC received feedback from participants in 6lo, ROLL and 6man.
-14 version of the draft addresses review feedback received from all workgroups.

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.
Not applicable. The document extending IPv6 ND flags and options to support this. The request is reviewed by the 6man workgroup.

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]?
Not applicable.

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.
Not applicable.

## 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?
Yes.

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?
https://wiki.ietf.org/group/int/IntAreaIssues has been discussed and 6man involved for the changes.


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?
Proposed Standard. It is appropriate as it modifies protocol for the deployment it is intended for.

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.
Yes. https://mailarchive.ietf.org/arch/msg/6lo/HoNzI1U2fwgHqICE9kV7UQhf-uc/ has been disclosed by the author.

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.
This document has a single author.

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.)
Authors are notified on I-D nits found in -14. -15 expected to address this

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
Normative reference to an informational document: RFC 9030

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
None

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.
None

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

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. It updates: 4861, 6550, 6553, 8505, 9010.
6553 is not mentioned in introduction or abstract


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,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
Edits needed
    a) Section 10 defines Consistent Uptime Option (CUO) however IANA registration refers to it as Node Uptime Option
    b) Section 14.3 lists 4 and 5"I" Field RFC 8505 that is already registered, this line is redundant in the IANA section of this document
    c) "P-field values" registry in the IANA request - a more descriptive name for the registry that reflects its purpose for e.g. Address Registration Indicator field?


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.
None needed

[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/