[Iot-directorate] draft-ietf-roll-enrollment-priority-18 telechat Iotdir review

Document: draft-ietf-roll-enrollment-priority
Title: Controlling Network Enrollment in RPL networks
Reviewer: Toerless Eckert
Review result: On the Right Track

Document: draft-ietf-roll-enrollment-priority-18
Title: Controlling Network Enrollment in RPL networks
Reviewer: Toerless Eckert
Review result: On the Right Track

Hi authors,

I have been selected as the IoT Directorate reviewer for this draft.
This review is intended to help the authors, working group, and ADs to
improve the document.

Document: draft-ietf-roll-enrollment-priority-18
Reviewer: Toerless Eckert
Review Date: August 18th, 2026
Intended Status: Standards Track

Thanks a lot for the work.

Benefits: This work looks like a useful optimization for deploying RPL,
specifically but not exclusively in 6TiSCH networks. Unfortunately, a really
good, motivating deployment example is missing, so I have unfortunately no idea
of the degree of benefits. An example deployment description that is choosen
for maximum benefit would be nice to motivate the work best.

Problems: I am top-posting three technical issues; all further issues are inlined.

1. The major issue of the draft is that it is completely unclear about its
scope. Its name and main text suggest that this is about improving
RFC9031/RFC9032 enrollment, but then it mentions en passant that it is also
meant to help improve tree balancing across multiple DODAGs in RPL parent
selection. This is further confused by the draft's attempt to disambiguate the
term "join", which is used for both processes - an attempt that does not succeed
(see inline comments).

This is most confusing because one of the parameters of the new option, the
DODAG size, is only used for DODAG selection, not for enrollment priority (if I
am reading the draft correctly).

While not explicitly asked for in the detailed review below, I would strongly
suggest improving the text quality by:

a) Changing the name of the new option to include DODAG size, and giving it a
   fitting abbreviation. For example, a "Minimum Enrollment Priority and DODAG
   Size" (MEPDS) option.

   Note: the inline concern in the IANA Considerations section would also need
   to be adjusted for such a changed name.

b) Changing the title of the draft to the name of the option.

c) Changing the introductory text to make it clear how this common option serves
   both functions (and maybe even more).

d) Restructuring the text so that the behavior of each of the two functions is
   described in its own chapter or section, instead of mentioning DODAG
   selection only en passant. Specifically, highlight how (if I understand it
   correctly) DODAG size is not limited to use in RFC9031/RFC9032 deployments,
   but can be applied to DODAG selection in any RPL instance with multiple
   DODAGs.

2. Using DODAG size to achieve a specific benefit, such as creating more
similarly sized DODAGs, is just wishful thinking if one relies on this draft's
text alone. It therefore looks a bit as if DODAG size had been added to the
option as a convenience, to avoid creating yet another option once someone works
out how to take it into account. And in networks with only a single
implementation it would of course be possible to come up with some algorithm
that improves conditions. So it is a perfect way to sneak proprietary
functionality into RPL - at the cost of safe interoperability.

If that is a correct understanding, then the primary ask is of course to be a lot
more specific about the state of how to use DODAG size. If there really is no
specification at all, then not only should that be said explicitly, but there
also needs to be a big warning that the use of DODAG size by independent
implementations may actually make things worse. And if you leave the
specification at this level, then I think it MUST reserve a value such as 0 for
DODAG size for the specific purpose of "perform all functions as you would if no
DODAG size had been signalled". That reservation is also useful if you go for the
next option:

A better option would be to invoke the concept of the Objective Function for the
use of DODAG size in DODAG selection. In one variant, the draft could say that
any use of DODAG size for DODAG selection requires a specification that extends
the OCP carried in the DODAG Configuration option to define how to use the DODAG
size. If it is foreseeable that a single OF (and hence OCP) might want to use two
or more separate algorithms involving DODAG size, then add some algorithm code
point field to the option.

3. It seems to be intended, but is not explicitly stated, that the signalled MEP
value is or can only be used by 6LRs implementing RFC9031/RFC9032. It is not
specified whether a 6TiSCH 6LR that does not implement RFC9031/RFC9032 can still
implement this draft, for example solely for the DODAG size benefits in DODAG
selection. I have no opinion, but it should be specified. For example: support
for this document does not imply a need to support RFC9031/RFC9032; however, if
a node implementing this draft also implements RFC9031/RFC9032, then it MUST use
the procedures specified in this draft to tune its RFC9031/RFC9032 behavior.

Other comments inline.

     1	
     2	
     3	
     4	
     5	ROLL Working Group                                         M. Richardson
     6	Internet-Draft                                  Sandelman Software Works
     7	Intended status: Standards Track                            R. A. Jadhav
     8	Expires: 22 January 2027                                     Huawei Tech
     9	                                                              P. Thubert
    10	                                                             Independent
    11	                                                             K. Iwanicki
    12	                                                    University of Warsaw
    13	                                                            21 July 2026
    14	
    15	
    16	             Controlling Network Enrollment in RPL networks
    17	                 draft-ietf-roll-enrollment-priority-18
    18	
    19	Abstract
    20	
    21	   The Routing Protocol for Low-Power and Lossy Networks (RPL) manages
    22	   the routing topology but lacks a mechanism to globally regulate how
    23	   many new nodes, known as Pledges, can join a node in a 6TiSCH network
    24	   at any given time.  Currently, Join Proxies (6LowPAN Routers) make
    25	   local decisions about whether to facilitate a Pledge's enrollment
    26	   based only on their immediate resources.
    27	
    28	   This document introduces RPL extensions to ensure that enrollment
    29	   remains orderly, prevents localized congestion at specific Join
    30	   Proxies, and allows the network to stay within its operational
    31	   capacity limits.
    32	
    33	About This Document
    34	
    35	   This note is to be removed before publishing as an RFC.
    36	
    37	   Status information for this document may be found at
    38	   https://datatracker.ietf.org/doc/draft-ietf-roll-enrollment-
    39	   priority/.
    40	
    41	   Discussion of this document takes place on the roll Working Group
    42	   mailing list (mailto:roll@ietf.org), which is archived at
    43	   https://mailarchive.ietf.org/arch/browse/roll/.  Subscribe at
    44	   https://www.ietf.org/mailman/listinfo/roll/.
    45	
    46	   Source for this draft and an issue tracker can be found at
    47	   https://github.com/roll-wg/voucher.
    48	
    49	Status of This Memo
    50	
    51	   This Internet-Draft is submitted in full conformance with the
    52	   provisions of BCP 78 and BCP 79.
    53	
    54	
    55	
    56	Richardson, et al.       Expires 22 January 2027                [Page 1]
    57	
    58	Internet-Draft                 join-metric                     July 2026
    59	
    60	
    61	   Internet-Drafts are working documents of the Internet Engineering
    62	   Task Force (IETF).  Note that other groups may also distribute
    63	   working documents as Internet-Drafts.  The list of current Internet-
    64	   Drafts is at https://datatracker.ietf.org/drafts/current/.
    65	
    66	   Internet-Drafts are draft documents valid for a maximum of six months
    67	   and may be updated, replaced, or obsoleted by other documents at any
    68	   time.  It is inappropriate to use Internet-Drafts as reference
    69	   material or to cite them other than as "work in progress."
    70	
    71	   This Internet-Draft will expire on 22 January 2027.
    72	
    73	Copyright Notice
    74	
    75	   Copyright (c) 2026 IETF Trust and the persons identified as the
    76	   document authors.  All rights reserved.
    77	
    78	   This document is subject to BCP 78 and the IETF Trust's Legal
    79	   Provisions Relating to IETF Documents (https://trustee.ietf.org/
    80	   license-info) in effect on the date of publication of this document.
    81	   Please review these documents carefully, as they describe your rights
    82	   and restrictions with respect to this document.  Code Components
    83	   extracted from this document must include Revised BSD License text as
    84	   described in Section 4.e of the Trust Legal Provisions and are
    85	   provided without warranty as described in the Revised BSD License.
    86	
    87	Table of Contents
    88	
    89	   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
    90	     1.1.  Motivation and Overview . . . . . . . . . . . . . . . . .   3
    91	   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
    92	   3.  Protocol Definition . . . . . . . . . . . . . . . . . . . . .   5
    93	     3.1.  Option Format . . . . . . . . . . . . . . . . . . . . . .   6
    94	     3.2.  Option Processing . . . . . . . . . . . . . . . . . . . .   7
    95	   4.  Operational Considerations  . . . . . . . . . . . . . . . . .   8
    96	     4.1.  Incremental deployment Considerations . . . . . . . . . .   8
    97	   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
    98	   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
    99	   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   100	   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
   101	     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
   102	     8.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   103	   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12
   104	
   105	
   106	
   107	
   108	
   109	
   110	
   111	
   112	Richardson, et al.       Expires 22 January 2027                [Page 2]
   113	
   114	Internet-Draft                 join-metric                     July 2026
   115	
   116	
   117	1.  Introduction
   118	
   119	   The adaption of the Time-Slotted Channel Hopping (TSCH) mode of
   120	   [ieee802154] for use in 6TiSCH networks is described in [RFC7554].
   121	   The security and onboarding framework for these networks, described
   122	   in [RFC9031] and [RFC9032], allows a new node, known as a "Pledge",
   123	   to utilize a nearby 6LowPAN Router as a Join Proxy.
   124	
   125	   To facilitate discovery, [RFC9032] specifies extensions to the IEEE
   126	   802.15.4 Enhanced Beacon that allow a Join Proxy to announce its
   127	   presence, enabling Pledges to identify and select an appropriate
   128	   entry point into the network.  Currently, Join Proxies make local
   129	   decisions about whether to facilitate a Pledge's enrollment based
   130	   only on their immediate resources.
   131	
   132	   This document introduces Routing Protocol for Low-Power and Lossy
   133	   Networks (RPL) extensions to ensure that enrollment remains orderly,
   134	   prevents localized congestion at specific Join Proxies, and allows
   135	   the network to stay within its operational capacity limits.
   136	
   137	1.1.  Motivation and Overview
   138	
   139	   Not every routing member of a mesh ought to announce itself as a
   140	   _Join Proxy_. The constructed Destination Oriented Directed Acyclic
   141	   Graph (DODAG) can become unbalanced if many nodes join in one part.
   142	   This can be the result of optimization decisions based upon local
   143	   information only.  If nodes could get more information about the
   144	   global view, then they could make different choices that would result
   145	   in more balanced resource usage.
   146	
   147	   There are a variety of local metrics which a 6LowPAN Router (6LR)
   148	   [RFC6066] can use to determine if it should provide the _Join Proxy_
   149	   function.  These reasons include low available battery power, already
   150	   high committed network bandwidth, and lack of available free memory
   151	   for Neighbor Cache Entry (NCE) slots [RFC4861], Section 5.1.  An NCE
   152	   is needed in order to maintain communication with the Pledge nodes
   153	   trying to enroll.  See [RFC9898] and [RFC6583] for a deeper analysis
   154	   of NCE exhaustion.
   155	
   156	   In addition to the local per-node constraints, if the network around
   157	   a 6LR is congested then adding more nodes to that part of the network
   158	   would make the congestion worse.  The attachment might not even
   159	   succeed if other non-local resources are in short supply.  For
   160	   instance, in storing-mode and mixed [dao-projection] mode LLNs,
   161	   routing table entries at other levels could become exhausted.
   162	
   163	
   164	
   165	
   166	
   167	
   168	Richardson, et al.       Expires 22 January 2027                [Page 3]
   169	
   170	Internet-Draft                 join-metric                     July 2026
   171	
   172	
   173	   Enrollment of new nodes into the DODAG involves having the Join Proxy
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

minor:

The phrase "Enrollment of new nodes into the DODAG" seems to be wrong, because
the Join Proxy is not necessarily the later RPL parent, nor does it (if I am not
mistaken) perform any enrollment into a specific RPL instance (and hence DODAG).

So maybe just call it "Enrollment" or "RFC9031 Enrollment" (or onboarding, as
discussed elsewhere), without referring to RPL specifics. Otherwise there should
be some explanation justifying why the use of an RPL term is appropriate here.

   174	   forward traffic from unknown nodes into the DODAG.  These unknown
   175	   nodes are not yet known to be trustworthy, the introduction of a lot
   176	   of traffic from could be part of a denial of service attack.
   177	
   178	   This extension includes a mechanism to allow the network operator to
   179	   send a signal that no new nodes are expected at that time, and for
   180	   all join proxy operations to be turned off by forcing the minimum
   181	   enrollment priority to the maximum (worst) value.
   182	
   183	   The RPL Destination Information Object (DIO) option described here
   184	   contains new metrics that propagate down the DODAG, informing each
   185	   layer of the conditions in the DODAG above the node.
   186	
   187	   This new metric, the minimum enrollment priority, is updated by each
   188	   6LR to reflect conditions in that 6LR.  This metric is only increased
   189	   based upon local conditions, and the new value is sent as within the
   190	   DIO that this node emits.  Additionally, this new metric forms the
   191	   basis for the proxy priority described in [RFC9032].
   192	   Section Section 3.1 explains how these fields affect the Trickle

nit:

Recommend using an AI for spell checking; it finds word duplications. Maybe even
in the MD source (not 100% sure).

   193	   Timer.
   194	
   195	   The minimum enrollment priority value is derived from multiple

minor:

A curious reader would love to know at this point "derived how?" -
automagically, or with a lot of human operator experience and magic nerd-knob
configuration?

Something like "currently, no specification exists to automatically determine
the minimum enrollment priority" would be a good indicator of this whole
mechanism being just another nail in the coffin of network simplicity. Oops - I
meant: of operator or (AI) SDN controller job security.

   196	   constraining factors, for instance, the size of the DODAG, the
   197	   occupancy of the bandwidth at the DODAG Root, the memory capacity at
   198	   the Root, or an administrative decision.
   199	
   200	   This minimum enrollment priority is used by each 6LR node to
   201	   determine whether or not it will operate as a _Join Proxy_ for nodes
   202	   that want to enroll.  For nodes which are already enrolled, but which
   203	   need to reconnect to a DODAG, the DODAG Size information helps the
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^      ^^^^^^^^^^

nit:

connect/reconnect is not introduced in the terminology at all. I thought this
was to be called (1)"Join".

minor:

DODAG Size is undefined here and, AFAIK, also not specified in RFC6550 or
RFC9031/9032. Please introduce and explain the term, or explain how to determine
it.

Hah! DODAG Size is introduced later in this document. Add "(see <section below>)"
after "DODAG Size".

   204	   node decide between different DODAGs which might be visible.
   205	
   206	   This minimum enrollment priority expresses the ability of RPL DODAG
   207	   globally to accept new joins: lower numerical priority values
                                  ^^^^^

minor:

Enrollments ???

   208	   indicate increased ability to accept new child nodes.
   209	
   210	   Moreover, when a RPL domain is composed of multiple DODAGs, a node at
   211	   the edge of more than one such DODAG may join any of the DODAGs it
                                                    ^^^^

minor:

Now this sounds as if the new parameter is used outside of enrollment, for an
actual RFC6550 Join operation of already enrolled RPL nodes. It would probably be
best to separate this from enrollment completely, by creating two subsections of
this introductory section.

   212	   sees.  It can also use this information to move between DODAGs in
   213	   order to help keep the relative sizes balanced.  For this, the
   214	   approximate knowledge of the size of the DODAGs is also an essential
   215	   metric.  Depending on the network policy, the size of the DODAG may
   216	   or may not affect the minimum enrollment priority.  Therefore, since
   217	   making one proportional to the other would be limiting their value,
   218	   the current size of the DODAG is advertised separately in the new
   219	   option.

minor:

Sounds like a lot of hand-waving, with an implied "insert magic here".
Maybe add an example section with the simplest example of a deployment that
ideally works automatically (no operator- or SDN-controller-provided nerd knobs),
and that shows how such additional information is derived - and hence how the new
functionality of this draft can provide the promised benefits.

   220	
   221	
   222	
   223	
   224	Richardson, et al.       Expires 22 January 2027                [Page 4]
   225	
   226	Internet-Draft                 join-metric                     July 2026
   227	
   228	
   229	   Updates to the option propagate through the network according to the
   230	   trickle algorithm.  [RFC6206] Other than the minimum enrollment
   231	   priority value, the contents of the option are generated at the DODAG
   232	   Root, and are not changed.
   233	
   234	   If the contents represent an update that is considered important
   235	   (e.g., quickly disabling any enrollments), the option can trigger
   236	   trickle timer resets at the nodes to speed up its propagation.
   237	
   238	2.  Terminology
   239	
   240	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   241	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   242	   "OPTIONAL" in this document are to be interpreted as described in
   243	   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   244	   capitals, as shown here.
   245	
   246	   The term 6LR means 6LowPAN Router, and is defined in [RFC6606].  It
   247	   refers to a router that forwards packets in a 6LowPAN network.
   248	
   249	   The terms DAO, DODAG, DODAG root, DIO, trickle timer are from
   250	   [RFC6550].  The lollipop counter function comes from [RFC6550],
   251	   Section 7.2.
   252	
   253	   The term (1)"Join" has been used in documents such as [RFC9031] to
   254	   denote the activity of a new node authenticating itself to the
   255	   network to obtain authorization to become a member of the network.
   256	
   257	   In the context of the [RFC6550] RPL protocol, the term (2)"Join" has
   258	   an alternative meaning: that of a node (already authenticated to the
   259	   network, and already authorized to be a member of the network),
   260	   deciding which part of the RPL DODAG to attach to.  This term "Join"
   261	   has to do with preferred parent selection processes.

minor:

Given that RFC6550 predates RFC9031 by about a decade, and that seemingly nobody
bothered to catch and avoid this ambiguity in RFC9031, I would appreciate it if
the order were reversed to follow the chronology, so that (1)"Join" is what
RFC6550 means - swap the paragraphs and numbers - and the references below were
fixed accordingly.

   262	
   263	   In order to avoid the ambiguity of this term, this document refers to
   264	   the process (1)"Join" as enrollment, leaving the term "Join" to mean
   265	   (2)"Join".  The term "onboarding" (or "IoT Onboarding") is
   266	   increasingly used to describe what is now called (1)Join in other
   267	   documents, and is called enrollment in this document.  However, the
   268	   term _Join Proxy_ is retained with its (1)"Join" meaning from
   269	   [RFC9031].

minor:

>From my understanding "enrollment" is used predominantly only when pledges
are given unique credentials that allow them to securely identify themselves,
such as in EST, BRSKI and the like. Other protocol that hand out shared
secrets, such as GDOI (handing out group keys) do only call themselves key
distribution or the like. RFC9031 does not hand out unique keys. And it just
calls itselfa "Join Protocol". Maybe "onboarding" is the right term to use
for mechanisms such as RFC9031 that do not hand out unique credentials.

I would also not replace "Join" with another term to disambiguate the conflicting
use of "Join". I would just disambiguate their use by adding specific prefix
or suffix. E.g.: "RPL tree Join", "Constrained Join" (Protocol). Inventing new
terms is always more cumbersome/problematic than just disambiguating overloaded
terms with such additions.

   270	
   271	3.  Protocol Definition
   272	
   273	   This document uses the extensions mechanism specified by [RFC6550].
   274	   As explained in Section 4, no mechanism is needed to enable it.

nit:

Maybe add "below" after "As explained in Section 4" - when reading this, I
wondered whether it could also refer to RFC6550 Section 4. Just to avoid that
confusion.

   275	
   276	
   277	
   278	
   279	
   280	Richardson, et al.       Expires 22 January 2027                [Page 5]
   281	
   282	Internet-Draft                 join-metric                     July 2026
   283	
   284	
   285	3.1.  Option Format

nit:

Would suggest renaming the section to "Minimum Enrollment Priority Option
(MEP)".

   286	
   287	   The following option is defined for transmission in DIOs issued by

nit:

s/following/Minimum Enrollment Priority (MEP)/

Explanation: the name of the option really needs to be introduced and used,
instead of letting the option remain anonymous until the IANA Considerations
section.

   288	   the DODAG Root to be propagated within the DODAG.

nit:

s/within/throughout/

It is flooded, right? "Throughout" should then be better... I think...

   289	
   290	       0                   1                   2                   3
   291	       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
   292	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   293	      | Type = TBD01  |Opt Length = 3 |Version Number |T| Min Priority|
   294	      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   295	      |  Exp  |DODAGSz|
   296	      +-+-+-+-+-+-+-+-+
   297	
   298	   Type  To be assigned by IANA.
   299	
   300	   Version Number  An 8-bit unsigned integer set by the DODAG root and
   301	      denoting the version number of the contents of the option.  The
   302	      version number is interpreted as a lollipop counter (see
   303	      Section 7.2 of [RFC6550]).
   304	
   305	   T  A bit indicating whether the particular version of the option is
   306	      important in that adopting its contents should trigger a trickle
   307	      timer [RFC6206], Section 4.2 reset at the node [RFC6550],
   308	      Section 8.3

nit:

The text starting at "trigger a trickle timer" is too dense. Is a "see" simply
missing before "Section 4.2..."? If not, then I am confused when reading the
sentence. Is something missing at the end, too - more than just a period, I mean?

   309	
   310	   Min Priority  The minimum enrollment priority.  This is a 7-bit field
   311	      providing a base value for the Enhanced Beacon Join priority.  A
   312	      value of 0x7f (127) is considered infinity, and this disables the
   313	      _Join Proxy_ function entirely.
   314	
   315	   Exp  A 4-bit unsigned integer indicating the power of 2 that defines
   316	      the unit of the DODAG Size, such that (unit = 2^Exp).
   317	
   318	   DODAGSz  A 4-bit unsigned integer expressing the size of the DODAG in
   319	      units that depend on the Exp field.
   320	
   321	   The DODAG Size is calculated as (DODAGSz * 2^Exp).

nit:

I do not find the explanatory text after Exp and DODAGSz particularly useful.
To me it is more confusing than helpful.

Line 321 is the only clear and simple explanation, to my mind. Suggest shortening
to:

   Exp  4-bit unsigned integer, DODAG Size exponent.

   DODAGSz  4-bit unsigned integer, DODAG Size significand.

   DODAG Size = DODAGSz * 2^Exp.

nit:

Why not swap the Exp and DODAGSz fields in the option? Then they would appear in
the order in which such an exponential number is normally read. It also looks
nicer. Unless, of course, there are already pre-existing implementations. If you
do swap them, then of course swap the explanatory text as well.

   323	   The DODAG Size can be measured by the Root based on the DAO activity.
   324	   In such a case, it represents the number of routes not the number of
   325	   nodes, and can thus be used to infer the load only in a network where
   326	   each node advertises roughly the same number of addresses and
   327	   generates roughly the same amount of traffic.

minor:

This reads to me like confusing hand-waving. "can be measured" = this paragraph
discusses one arbitrary option for how to measure. But is the value to be
determined through measurement at all, or can it also be determined in another
way, such as through configuration?

I really do not see why this would not simply be the number of nodes, which the
root can always determine easily... I think.

   328	
   329	   As the DODAG Size is always a multiple of a power of 2, when the

nit:

Fix to: "As the DODAG Size is always represented in the MEP option as a
multiple" ...

   330	   actual size falls between two such values, the DODAG Root is to
   331	   always round up.

nit:

Again, a suggestion to use an AI spell checker. This should be 'rounded up'.

minor:

MUST be rounded up ?

minor:

MUST be rounded up, unless it already exceeds 491520, the maximum value that can
be expressed in the MEP option (DODAGSz = 15, Exp = 15, 15 * 2^15 = 491520)?

   332	
   333	
   334	
   335	
   336	Richardson, et al.       Expires 22 January 2027                [Page 6]
   337	
   338	Internet-Draft                 join-metric                     July 2026
   339	
   340	
   341	   In any case, the DODAG Size may slightly change between one DIO and
   342	   the next, so the value transmitted is considered as an approximation.
   343	
   344	   A 6LR node uses the contents of this option from whichever parent it
   345	   selects as the basis for the option that it sends.  When that parent
   346	   increments its minimum enrollment priority above the previous value
   347	   that was seen, then this MUST be considered an "inconsistent" value
   348	   for the purposes of the trickle timer.  A parent that decrements its
   349	   minimum enrollment priority to a lower value MAY be considered
   350	   "inconsistent", or a node MAY wait re-transmit according to the
                                         ^^^^^^^^^^^^^^^^^

nit:

Wait to retransmit WHAT?

   351	   trickle timer's redundancy constant.  This is consistent with
   352	   paragraph one of [RFC6550], Section 8.3, which considers lower Rank
   353	   to be consistent.
   354	
   355	3.2.  Option Processing
   356	
   357	   The contents of the option MUST be generated by the DODAG Root.  A
                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

minor:

Would be good to have more text reconfirming that this option must always be
sent/generated by a root - or only when configured. Its easier to ask for it
to always be sent if there was also a good "ignore me" option value for the
parameters. WHich wouldn't necessarily have to be default, but if it's always
to be sent, it would be the best backeward compatible option in case something
goes wrong. And the question is whether 0x40 should be the default MED value to
send.

   358	   6LR MAY change only the Version Number (in lollipop fashion), and MAY
   359	   increment the Min Priority, if it is less than 0x7f.
   360	
   361	   Whenever the DODAG root changes the values of the minimum enrollment
   362	   priority or DODAG Size in the option, it MUST also increment the
   363	   value of Version Number.  Moreover, if the change is considered
   364	   important (i.e., it is expected to propagate in the DODAG quickly),
   365	   the DODAG Root MUST also set the T bit to 1; otherwise, it MUST set
   366	   the bit to 0.
   367	
   368	   Upon receiving the option, a 6LR first checks the value of the
   369	   Version Number field in the option, _vr_, versus the value of the
   370	   Version Number it has last adopted locally, _vl_.
   371	
   372	   *  If _vl_ is greater than _vr_ (in the lollipop counter order), then
   373	      the 6LR MUST ignore the received option.
   374	
   375	   *  Otherwise, the 6LR MUST adopt the contents of the option (i.e.,
   376	      the values of Version Number, Min Priority, DODAG Size, and the T
   377	      bit) as its local ones.  Moreover, if _vl_ was smaller than _vr_
   378	      (in the lollipop counter order) and the T bit in the received
   379	      option was set, then the 6LR MUST reset its DIO trickle timer.
   380	
   381	   A 6LR, which would otherwise be willing to act as a _Join Proxy_,
   382	   will examine the locally adopted value of minimum enrollment priority
   383	   and to that number add any additional local consideration (such as
   384	   upstream congestion, number of NCE slots available, etc.).
   385	
   386	   The maximum resulting value any 6LR can obtain this way is 0x7f.
   387	
   388	
   389	
   390	
   391	
   392	Richardson, et al.       Expires 22 January 2027                [Page 7]
   393	
   394	Internet-Draft                 join-metric                     July 2026
   395	
   396	
   397	   The resulting minimum enrollment priority, if less than 0x7f, should
   398	   enable the _Join Proxy_ function.

major:

s/should/SHOULD/ - or even MUST ?

Should be normative IMHO. Also not clear why it's just should.
Also, this doc should be called an update to RFC9031, specifying how it's
enabled by default and controlled.

   399	
   400	   Note that the calculated local value _vl_ does _not_ update the value
   401	   _vr_ in the option.
   402	
   403	4.  Operational Considerations
   404	
   405	   The RPL ecosystem has not included a management protocols to date.  A
   406	   future mechanisms, such as [I-D.ietf-roll-capabilities] could enable
   407	   assessment and configuration of node features.  If/when such a thing

nit:

s/thing/mechanism/

   408	   became available, a node would still need to be connected before it

nit:
s/connected/Joined to the DODAG/ ???

   409	   configuration parameters could be adjusted.  Until such a mechanism
   410	   becomes available, the only way an operator can change any defaults
   411	   in the node is via a custom firmware load, or a vendor proprietary
   412	   mechanism.  For instance, a vendor might do this via custom
   413	   programming of a configuration section in memory using some kind of
   414	   cable.  This kind of per-node tuning is very expensive to do, and
   415	   runs counter to the goals of zero-touch mechanisms.
   416	
   417	   RPL nodes therefore need to come with sensible defaults that allow a
   418	   node to join a DODAG.  Many current deployments have been single
   419	   vendor with consistent features and well-tested defaults.  However,
   420	   even within such an environment, incremental deployment of firmware
   421	   updates might still cause feature skew among nodes.
   422	
   423	   Intermediate nodes in a DODAG might not be upgraded at the same time
   424	   as nodes further down the leaf, and therefore might not support this
   425	   new metric container.
   426	
   427	   It is therefore necessary to consider how the lack of this metric
   428	   container can be compensated for nodes further away from the root.
   429	
   430	4.1.  Incremental deployment Considerations
   431	
   432	   A 6LR that did not support this option would not act on it or
   433	   propagate it in its DIO messages.  In effect, the 6LR's sub-tree
   434	   below a node without support for this option could not receive any
   435	   information about the DODAG size or minimum enrollment priority.  In
   436	   the absence of of this metric, a 6LR will need to base decisions on
   437	   how to act based upon information about local resources only.
   438	
   439	   This document therefore establishes that a 6LRs that support this
   440	   option but do not receive it via any path SHOULD assume a default
   441	   value of 0x40 as their base value for the Enhanced Beacon Join
   442	   Priority.  This half-way value has been chosen to allow for the best
   443	   reaction.

minor:

The normative requirements make this text ill-suited to a deployment
considerations section. I would suggest moving 4.1 up, e.g. as Section 3.3.

   445	
   446	
   447	
   448	Richardson, et al.       Expires 22 January 2027                [Page 8]
   449	
   450	Internet-Draft                 join-metric                     July 2026
   451	
   452	
   453	   A 6LR downstream of a 6LR where there was such an interruption in the
   454	   metric could err in two directions:
   455	
   456	   *  If the value implied by the base value of 0x40 was too low, then
   457	      the 6LR might continue to attract enrollment traffic when none
   458	      should have been collected.  This is a stressor for the network,
   459	      but the similar behaviour would occur if no option existed.
   460	
   461	   *  If the value implied by the base value of 0x40 was too high, then
   462	      the 6LR might deflect enrollment traffic to other parts of the
   463	      DODAG, possibly refusing any enrollment traffic at all.
   464	
   465	   In order for this to happen, some significant congestion must exist
   466	   in the sub-DODAG where the implied 0x40 was introduced.  The 0x40 is
   467	   only the half-way point, so if such an amount of congestion was
   468	   present, then this sub-DODAG of the DODAG simply winds up being more
   469	   cautious than it needed to be.
   470	
   471	   There is an additional possibility of having more than one
   472	   interruption of information if multiple nodes in the DODAG were
   473	   lacking a firmware update to enable this option.  Such alternation of
   474	   the above two situations might introduce some pathology of cycles of
   475	   accepting and then rejecting enrollment traffic: This is something an
   476	   operator should consider if they incrementally deploy this option to
   477	   an existing Low-power/Lossy-Network (LLN).
   478	
   479	   In addition, due to these interruptions, an operator would be unable
   480	   to turn off enrollment traffic by sending a maximum value enrollment
   481	   priority to the sub-DODAG.  This situation is unfortunate, but
   482	   without this option, the situation would occur all over the DODAG,
   483	   rather than just in the sub-DODAG that the option did not reach.  So
   484	   this problem is not a new problem.
   485	
   486	5.  Security Considerations
   487	
   488	   As per [RFC7416], RPL control frames either run over a secured layer
   489	   2 or use the [RFC6550] Secure DIO methods at layer 3.  This option
   490	   can be placed into either a "clear" (layer-2 secured) DIO or a
   491	   layer-3 Secure DIO.

minor:

That statement is factually wrong. RFC7416 does not specify that frames are
secured either at layer 2 or at layer 3. It merely performs a security analysis
for cases in which one of the two security options is used. RFC6550 itself also
permits no security at all. Please fix.

This is important, because you should define the scope of your security
considerations here, right at the beginning. If you were to consider cases in
which neither layer 2 nor layer 3 security is used, you would have a lot more
issues to consider, and probably no good reference to point to. So I would
suggest reframing this introduction to state that these security considerations,
like those of RFC7416, only consider deployments with layer 2 and/or layer 3
security.

   492	
   493	   In most deployments involving wireless technology, layer 2 is always
   494	   encrypted using a layer-2 specific technology, and so privacy of this
   495	   option is available.

nit:

s/privacy/confidentiality/

minor:

The same is true for layer 3, though, so this paragraph is confusing as to what
is special enough here to mention layer 2 only.

   496	
   497	
   498	
   499	
   500	
   501	
   502	
   503	
   504	Richardson, et al.       Expires 22 January 2027                [Page 9]
   505	
   506	Internet-Draft                 join-metric                     July 2026
   507	
   508	
   509	   However, a malicious node that was part of the RPL control plane
   510	   (i.e., had been enrolled into the layer-2 security) would be able to
   511	   see the values of this option and, based upon the observed minimal
   512	   enrollment priority, could signal a confederate that it was a good
   513	   time to send malicious join traffic.

nit:

In standard terminology, a node that was enrolled into a security scheme is not
"malicious" but "compromised": it did pass whatever muster was necessary to
become part of the security domain, but nevertheless behaves as an attacker.
Please fix the terminology.

"confederate" is a somewhat surprising term here. Suggest using something like
"collaborating attacker".

minor:

The description is insufficient to understand the exact nature of the attack, or
why it is worse than it would be without the option. An example comparing the
same type of attack (with the help of a compromised 6LR) with and without the
option in use would be useful here.

   515	   What is more, such a malicious node, being already part of the RPL

nit: s/malicious/compromised/

   516	   control plane, could also send DIOs with a different minimal
   517	   enrollment priority, which would cause downstream mesh routers to
   518	   change their _Join Proxy_ behavior: lower minimal priorities would
   519	   cause downstream nodes to accept more Pledges than the network was
   520	   expecting; higher minimal priorities could cause the enrollment
   521	   process to stall.

minor:

As above, a concrete example would be nice.

   522	
   523	   The use of layer-2 or layer-3 security for RPL control messages
   524	   prevents the two aforementioned attacks by non-participating nodes by
   525	   preventing malicious nodes from becoming part of the control plane.

minor:

If you keep "malicious" in lines 509-513 (as opposed to changing it to
"compromised", as I suggest), then this paragraph contradicts lines 509-513,
because if this paragraph were true, a malicious node would never become a 6LR.

But if you do use the correct terminology, and if these security considerations
only consider layer 2 and/or layer 3 encrypted deployments, as I suggest after
line 491, then this paragraph is irrelevant.

So: this paragraph should really be removed, unless you want to open the door to
discussing a lot more attack vectors for completely unsecured RPL deployments.

   526	
   527	   Nevertheless, a node that is attacked and has malware placed on it
   528	   creates vulnerabilities in the same way such an attack on any node
   529	   involved in Internet routing protocol does.  The re-keying provisions
   530	   of [RFC9031] exist to permit an operator to remove such nodes from
   531	   the network.

minor:

Do not hand-wave towards the universe/the Internet. You can easily be more
specific:

   Attacks by a compromised 6LR that do not involve the new option are
   outside the scope of this section; they are documented in RFC7416.

But it may be better to fold such a sentence into a corrected first paragraph of
this section, instead of putting it at the end. That makes it clear up front that
this section adds to RFC7416.

   532	
   533	6.  IANA Considerations
   534	
   535	   Please allocate a new entry, TBD01 from Registry RPL Control Message
   536	   Options at https://www.iana.org/assignments/rpl/rpl.xhtml#control-
   537	   message-options
   538	
   539	   This entry should be called Minimum Enrollment Priority, and the
   540	   reference should be to this document.

nit:

The "Meaning" of this entry should be "Minimum Enrollment Priority (MEP)".

Explanation: "Meaning" is the name of the column in the IANA registry. As
suggested before, the option should also have an official abbreviation, to allow
easier and shorter references later.

   541	
   542	7.  Acknowledgements
   543	
   544	   This has been reviewed by Charlie Perkins, Rifaat Shehk-Yusek, Dave
   545	   Thaler, and Thomas Watteyne.
   546	
   547	   Huimin She contributed text about expressing the DODAG size.  Ketan
   548	   Talaulika was the responsible AD and provided many editorial
   549	   improvements.
   550	
   551	8.  References
   552	
   553	8.1.  Normative References
   554	
   555	
   556	
   557	
   558	
   559	
   560	Richardson, et al.       Expires 22 January 2027               [Page 10]
   561	
   562	Internet-Draft                 join-metric                     July 2026
   563	
   564	
   565	   [ieee802154]
   566	              IEEE standard for Information Technology, "IEEE Std.
   567	              802.15.4, Part. 15.4: Wireless Medium Access Control (MAC)
   568	              and Physical Layer (PHY) Specifications for Low-Rate
   569	              Wireless Personal Area Networks", n.d.,
   570	              <http://standards.ieee.org/findstds/
   571	              standard/802.15.4-2015.html>.
   572	
   573	   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
   574	              Requirement Levels", BCP 14, RFC 2119,
   575	              DOI 10.17487/RFC2119, March 1997,
   576	              <https://www.rfc-editor.org/rfc/rfc2119>.
   577	
   578	   [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
   579	              "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206,
   580	              March 2011, <https://www.rfc-editor.org/rfc/rfc6206>.
   581	
   582	   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
   583	              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
   584	              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
   585	              Low-Power and Lossy Networks", RFC 6550,
   586	              DOI 10.17487/RFC6550, March 2012,
   587	              <https://www.rfc-editor.org/rfc/rfc6550>.
   588	
   589	   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
   590	              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
   591	              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
   592	
   593	   [RFC9031]  Vučinić, M., Ed., Simon, J., Pister, K., and M.
   594	              Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH",
   595	              RFC 9031, DOI 10.17487/RFC9031, May 2021,
   596	              <https://www.rfc-editor.org/rfc/rfc9031>.
   597	
   598	   [RFC9032]  Dujovne, D., Ed. and M. Richardson, "Encapsulation of
   599	              6TiSCH Join and Enrollment Information Elements",
   600	              RFC 9032, DOI 10.17487/RFC9032, May 2021,
   601	              <https://www.rfc-editor.org/rfc/rfc9032>.
   602	
   603	8.2.  Informative References
   604	
   605	   [dao-projection]
   606	              Thubert, P., Jadhav, R., and M. Richardson, "Root-
   607	              initiated Routing State in RPL", Work in Progress,
   608	              Internet-Draft, draft-ietf-roll-dao-projection-40, 11
   609	              March 2025, <https://datatracker.ietf.org/doc/html/draft-
   610	              ietf-roll-dao-projection-40>.
   611	
   612	
   613	
   614	
   615	
   616	Richardson, et al.       Expires 22 January 2027               [Page 11]
   617	
   618	Internet-Draft                 join-metric                     July 2026
   619	
   620	
   621	   [I-D.ietf-roll-capabilities]
   622	              Jadhav, R., Thubert, P., Richardson, M., and R. N. Sahoo,
   623	              "RPL Capabilities", Work in Progress, Internet-Draft,
   624	              draft-ietf-roll-capabilities-09, 9 November 2021,
   625	              <https://datatracker.ietf.org/doc/html/draft-ietf-roll-
   626	              capabilities-09>.
   627	
   628	   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
   629	              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
   630	              DOI 10.17487/RFC4861, September 2007,
   631	              <https://www.rfc-editor.org/rfc/rfc4861>.
   632	
   633	   [RFC6066]  Eastlake 3rd, D., "Transport Layer Security (TLS)
   634	              Extensions: Extension Definitions", RFC 6066,
   635	              DOI 10.17487/RFC6066, January 2011,
   636	              <https://www.rfc-editor.org/rfc/rfc6066>.
   637	
   638	   [RFC6583]  Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
   639	              Neighbor Discovery Problems", RFC 6583,
   640	              DOI 10.17487/RFC6583, March 2012,
   641	              <https://www.rfc-editor.org/rfc/rfc6583>.
   642	
   643	   [RFC6606]  Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem
   644	              Statement and Requirements for IPv6 over Low-Power
   645	              Wireless Personal Area Network (6LoWPAN) Routing",
   646	              RFC 6606, DOI 10.17487/RFC6606, May 2012,
   647	              <https://www.rfc-editor.org/rfc/rfc6606>.
   648	
   649	   [RFC7416]  Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
   650	              and M. Richardson, Ed., "A Security Threat Analysis for
   651	              the Routing Protocol for Low-Power and Lossy Networks
   652	              (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
   653	              <https://www.rfc-editor.org/rfc/rfc7416>.
   654	
   655	   [RFC7554]  Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using
   656	              IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the
   657	              Internet of Things (IoT): Problem Statement", RFC 7554,
   658	              DOI 10.17487/RFC7554, May 2015,
   659	              <https://www.rfc-editor.org/rfc/rfc7554>.
   660	
   661	   [RFC9898]  Xiao, X., Vasilenko, E., Metz, E., Mishra, G., and N.
   662	              Buraglio, "Neighbor Discovery Considerations in IPv6
   663	              Deployments", RFC 9898, DOI 10.17487/RFC9898, November
   664	              2025, <https://www.rfc-editor.org/rfc/rfc9898>.
   665	
   666	Authors' Addresses
   667	
   668	
   669	
   670	
   671	
   672	Richardson, et al.       Expires 22 January 2027               [Page 12]
   673	
   674	Internet-Draft                 join-metric                     July 2026
   675	
   676	
   677	   Michael Richardson
   678	   Sandelman Software Works
   679	   Email: mcr+ietf@sandelman.ca
   680	
   681	
   682	   Rahul Arvind Jadhav
   683	   Huawei Tech
   684	   Email: rahul.ietf@gmail.com
   685	
   686	
   687	   Pascal Thubert
   688	   Independent
   689	   Email: pascal.thubert@gmail.com
   690	
   691	
   692	   Konrad Iwanicki
   693	   University of Warsaw
   694	   Email: iwanicki@mimuw.edu.pl
   695	
   696	
   697	
   698	
   699	
   700	
   701	
   702	
   703	
   704	
   705	
   706	
   707	
   708	
   709	
   710	
   711	
   712	
   713	
   714	
   715	
   716	
   717	
   718	
   719	
   720	
   721	
   722	
   723	
   724	
   725	
   726	
   727	
   728	Richardson, et al.       Expires 22 January 2027               [Page 13]

EOF