[Roll] Re: WGLC: draft-ietf-roll-enrollment-priority-13

[Ines Robles <[e-mail]>]

Dear all,

Regarding this document, we have received a few reviews supporting the
work, and we understand that the comments have been addressed. We have not
received any further complaints or objections.

Therefore, we conclude that the WGLC is closed and that this document can
move forward to publication.

Best regards,

Ines and Aris

On Mon, Oct 27, 2025 at 8:51 PM Charles Perkins <[e-mail]>
wrote:

> Hello folks,
>
> I have reviewed the draft draft-ietf-roll-enrollment-priority-13, and
> support its progress towards publication.
>
> Most of my comments are editorial.  I had some thoughts to expand the use
> of the option to help with cases where quantities other than DODAG size are
> of interest.  I looked back briefly at the mailing list archives, but I am
> otherwise unfamiliar with the working group discussions about this
> document.  I hope the authors will find these comments useful.
>
> These comments are presented in the format provided by
> rfcdiff/Before-after, with a little bit of emphasis added.  Please don't
> hesitate to ask if my format is confusing.
> ==================================================================
>
> INTRODUCTION, paragraph 5:
> OLD:
>
>  Status of This Memo
>
> NEW:
>
>  CEP: Is it possible to have an Abstract that does not first require the
> reader
>       to understand the Definitions?  Perhaps replace Pledges -> RPL nodes.
>
>  Status of This Memo
> --------------------------
>
> Section 1.1., paragraph 1:
> OLD:
>
>     It has become clear that not every routing member of the mesh ought
>     to announce itself as a _Join Proxy_. There are a variety of local
>     reasons for which a 6LowPAN Router (6LR) might not want to provide
>     the _Join Proxy_ function.  They include low available battery power,
>     already high committed network bandwidth, and available free memory
>     for Neighbor Cache Entry (NCE) slots.  (An NCE entry is needed in
>     order to maintain communication with the Pledge nodes trying to
>     enroll)
>     There are other situations where the operator of the network would
>     like to selectively enable or disable the enrollment process in a
>     specific Destination Oriented Directed Acyclic Graph (DODAG).  In
>     particular, as the enrollment process involves permitting unencrypted
>     traffic into the best effort part of a network, it would be better to
>     have the enrollment process off when no new nodes are expected.
>
> NEW:
>
>     It has become clear that not every routing member of the mesh ought
>  CEP: Phrases such as "It has become clear that" add words but not
>       understanding.
>     to announce itself as a _Join Proxy_. There are a variety of local
>     reasons for which a 6LowPAN Router (6LR) might not want to provide
>     the _Join Proxy_ function.  They include low available battery power,
>  CEP: "They" --> "Some reasons"
>     already high committed network bandwidth, and available free memory
>  CEP: "available" --> "lack of available"
>     for Neighbor Cache Entry (NCE) slots.  (An NCE entry is needed in
>     order to maintain communication with the Pledge nodes trying to
>     enroll)
>  CEP: Parentheses should be deleted.
>
>     There are other situations where the operator of the network would
>     like to selectively enable or disable the enrollment process in a
>     specific Destination Oriented Directed Acyclic Graph (DODAG).  In
>     particular, as the enrollment process involves permitting unencrypted
>     traffic into the best effort part of a network, it would be better to
>     have the enrollment process off when no new nodes are expected.
>  CEP: "have" --> "turn"
> ---------------------------------------------
>
> Section 1.1., paragraph 2:
> OLD:
>
>     This document describes a Routing Protocol for Low-Power and Lossy
>     Networks (RPL) Destination Information Object (DIO) option that can
>     be used to set a minimum enrollment priority.  The minimum priority
>     expresses the inability of the RPL DODAG globally to accept new
>     joins.  It may derive from multiple constraining factors, for
>     instance, the size of the DODAG, the occupancy of the bandwidth at
>     the DODAG Root, the memory capacity at the Root, or an administrative
>     decision.  Each potential _Join Proxy_ utilizes this value as a base
>     on which to add values relating to local conditions, such as its Rank
>     and number of pending joins.  As explained in [RFC9032], higher
>     values decrease the likelihood of an unenrolled node sending
>     enrollment traffic via this _Join Proxy_. In particular, by setting
>     the minimum enrollment priority to the maximum value allowed, a
>     network operator can globally disable all new enrollment traffic.
>
> NEW:
>
>     This document describes a Routing Protocol for Low-Power and Lossy
>     Networks (RPL) Destination Information Object (DIO) option that can
>     be used to set a minimum enrollment priority.  The minimum priority
>     expresses the inability of the RPL DODAG globally to accept new
>  CEP: "expresses the inability" --> "assesses the ability"
>     joins.  It may derive from multiple constraining factors, for
>     instance, the size of the DODAG, the occupancy of the bandwidth at
>     the DODAG Root, the memory capacity at the Root, or an administrative
>     decision.  Each potential _Join Proxy_ utilizes this value as a base
>     on which to add values relating to local conditions, such as its Rank
>     and number of pending joins.  As explained in [RFC9032], higher
>     values decrease the likelihood of an unenrolled node sending
>     enrollment traffic via this _Join Proxy_. In particular, by setting
>     the minimum enrollment priority to the maximum value allowed, a
>     network operator can globally disable all new enrollment traffic.
> ----------------------------------------
>
> Section 1.1., paragraph 3:
> OLD:
>
>     Moreover, when a RPL domain is composed of multiple DODAGs, a node at
>     the edge of more than one such DODAG may not only join any of the
>     DODAGs but also move between them in order to keep their relative
>     sizes balanced.  For this, the approximate knowledge of the size of
>     the DODAGs is also an essential metric.  Depending on the network
>     policy, the size of the DODAG may or may not affect the minimum
>     enrollment priority.  Therefore, since making one proportional to the
>     other would be limiting their value, the current size of the DODAG is
>     advertised separately in the new option.
>
> NEW:
>
>     Moreover, when a RPL domain is composed of multiple DODAGs, a node at
>     the edge of more than one such DODAG may not only join any of the
>     DODAGs but also move between them in order to keep their relative
>     sizes balanced.  For this, the approximate knowledge of the size of
>     the DODAGs is also an essential metric.  Depending on the network
>     policy, the size of the DODAG may or may not affect the minimum
>     enrollment priority.  Therefore, since making one proportional to the
>     other would be limiting their value, the current size of the DODAG is
>     advertised separately in the new option.
>  CEP: As mentioned, the viability of joining a new DODAG could depend on
> other
>       factors.  It could also, for instance, depend on how saturated the
> DODAG
>       is currently (regardless of size), or on the nature of the layer 2.
>       Perhaps this field should be equipped with a type descriptor so that
> it
>       could provide information about other determining factors.  Maybe the
>       extra bits could be carved out of the Min Priority field.
> ------------------------------------
>
> Section 2., paragraph 6:
> OLD:
>
>     In order to avoid the ambiguity of this term, this document refers to
>     the process (1)"Join" as enrollment, leaving the term "Join" to mean
>     (2)"Join".  The term "onboarding" (or "IoT Onboarding") is
>     increasingly used to describe what is now called (1)Join in other
>     documents, and is called enrollment in this document.  However, the
>     term _Join Proxy_ is retained with its (1)"Join" meaning from
>     [RFC9031].
>
> NEW:
>
>     In order to avoid the ambiguity of this term, this document refers to
>     the process (1)"Join" as enrollment, leaving the term "Join" to mean
>     (2)"Join".  The term "onboarding" (or "IoT Onboarding") is
>     increasingly used to describe what is now called (1)Join in other
>     documents, and is called enrollment in this document.  However, the
>     term _Join Proxy_ is retained with its (1)"Join" meaning from
>     [RFC9031].
>  CEP: Why not "Enrollment Proxy"?
>  CEP: and then "enrollment-metric" for the short name of the draft.
> ---------------------------------
>
> Section 3., paragraph 1:
> OLD:
>
>     This document uses the extensions mechanism designed into [RFC6550].
>     No mechanism is needed to enable it.
>
> NEW:
>
>     This document uses the extensions mechanism designed into [RFC6550].
>  CEP: "designed into"  -->  "specified by"
>     No mechanism is needed to enable it.
>  CEP: This sentence raises more questions than it answers, at least for me.
>       Perhaps simply leave it out (especially if you use "specified by").
> --------------------------------------
>
> Section 3.1., paragraph 6:
> OLD:
>
>     Min Priority  A 7-bit field providing a base value for the Enhanced
>        Beacon Join priority.  A value of 0x7f (127) disables the _Join
>        Proxy_ function entirely.
>
> NEW:
>
>     Min Priority  A 7-bit field providing a base value for the Enhanced
>        Beacon Join priority.  A value of 0x7f (127) disables the _Join
>        Proxy_ function entirely.
>  CEP: If T were 2 bits, and Min Priority were 6 bits, you would have
>       more control over the Trickle Timer.  Do you really need 7 bits?
> --------------------------------------
>
> Section 3.1., paragraph 10:
> OLD:
>
>     The DODAG Size can be measured by the Root based on the DAO activity.
>     In such a case, it represents the number of routes not the number of
>     nodes, and can thus be used to infer the load only in a network where
>     each node advertises roughly the same number of addresses and
>     generates roughly the same amount of traffic.
>
> NEW:
>
>     The DODAG Size can be measured by the Root based on the DAO activity.
>  CEP: Couldn't you just count the number of enrollments?  Is there a
> keepalive?
>
>     In such a case, it represents the number of routes not the number of
>     nodes, and can thus be used to infer the load only in a network where
>     each node advertises roughly the same number of addresses and
>     generates roughly the same amount of traffic.
>  CEP: I understand the last sentence to mean that the applicability is
>       quite limited.
> ----------------------------------
>
> Section 3.1., paragraph 12:
> OLD:
>
>     Future work such as [I-D.ietf-roll-capabilities] will enable
>     collection of capabilities such as this one in reports to the DODAG
>     Root.
>
> NEW:
>
>     Future work such as [I-D.ietf-roll-capabilities] will enable
>     collection of capabilities such as this one in reports to the DODAG
>     Root.
>  CEP: I don't see how this improves the current specification.
> ---------------------------------
>
> Section 3.1., paragraph 13:
> OLD:
>
>     In any case, the DODAG Size may slightly change between a DIO and the
>     next, so the value transmitted is considered as an approximation.
>
> NEW:
>
>     In any case, the DODAG Size may slightly change between a DIO and the
>  CEP: "between a"  -->  "between one"
>     next, so the value transmitted is considered as an approximation.
> --------------------------------------------
>
> Section 3.2., paragraph 1:
> OLD:
>
>     The contents of the option MUST be generated by the DODAG Root.  A
>     6LR MUST NOT change them when propagating the option.
>
> NEW:
>
>     The contents of the option MUST be generated by the DODAG Root.  A
>     6LR MUST NOT change them when propagating the option.
>  CEP: "6LR MUST NOT change the option when propagating it."
> ----------------------------------------
>
> Section 3.2., paragraph 6:
> OLD:
>
>     A 6LR, which would otherwise be willing to act as a _Join Proxy_,
>     will examine the locally adopted value of Min Priority and to that
>     number add any additional local consideration (such as upstream
>     congestion, number of NCE slots available, etc.).
>
> NEW:
>
>     A 6LR, which would otherwise be willing to act as a _Join Proxy_,
>     will examine the locally adopted value of Min Priority and to that
>     number add any additional local consideration (such as upstream
>     congestion, number of NCE slots available, etc.).
>  CEP: Does the Min Priority control enrollment, or willingness to act
>       as a _Join Proxy_?  These seem like two different things.
> ----------------------------------------
>
> Section 3.3., paragraph 1:
> OLD:
>
>     A 6LR that did not support this option would not act on it or
>     propagate it in its DIO messages.  In effect, the 6LR's children and
>     grandchildren nodes could not receive any telemetry.  Therefore, 6LRs
>     that support this option but do not receive it via any path SHOULD
>     assume a default value of 0x40 as their base value for the Enhanced
>     Beacon Join Priority.
>
> NEW:
>
>     A 6LR that did not support this option would not act on it or
>     propagate it in its DIO messages.  In effect, the 6LR's children and
>  CEP: How about "subtree nodes"?
>     grandchildren nodes could not receive any telemetry.  Therefore, 6LRs
>  CEP: Doesn't this imply that all DODAGs are about telemetry?  Is that
> O.K.??
>     that support this option but do not receive it via any path SHOULD
>     assume a default value of 0x40 as their base value for the Enhanced
>     Beacon Join Priority.
>  CEP: How long do they wait before this?  What happens if a 6LR does
>       this, but later receives the option with Min_Priority == _MAX_VALUE_?
> -------------------------------------
>
> Section 3.3., paragraph 4:
> OLD:
>
>     *  If the value implied by the base value of 0x40 was too high, then
>        the 6LR might deflect enrollment traffic to other parts of the
>        DODAG, possibly refusing any enrollment traffic at all.  In order
>        for this to happen, some significant congestion must be seen in
>        the sub-DODAG where the implied 0x40 was introduced.  The 0x40 is
>        only the half-way point, so if such an amount of congestion was
>        present, then this sub-DODAG of the DODAG simply winds up being
>        more cautious than it needed to be.
>
> NEW:
>
>     *  If the value implied by the base value of 0x40 was too high, then
>        the 6LR might deflect enrollment traffic to other parts of the
>        DODAG, possibly refusing any enrollment traffic at all.  In order
>        for this to happen, some significant congestion must be seen in
>  CEP: "must" here seems wrong, and "significant" is really too ambiguous
>        the sub-DODAG where the implied 0x40 was introduced.  The 0x40 is
>        only the half-way point, so if such an amount of congestion was
>        present, then this sub-DODAG of the DODAG simply winds up being
>        more cautious than it needed to be.
>  CEP: One might, for instance, suggest that packet drop rates should
>       not exceed 5%.
> ----------------------------------
>
> Section 3.3., paragraph 5:
> OLD:
>
>     It is possible that the temporal alternation of the above two
>     situations might introduce cycles of accepting and then rejecting
>     enrollment traffic.  This is something an operator should consider if
>     they incrementally deploy this option to an existing Low-power/Lossy-
>     Network (LLN).  In addition, an operator would be unable to turn off
>     enrollment traffic by sending a maximum value enrollment priority to
>     the sub-DODAG.  This situation is unfortunate, but without this
>     option, the situation would occur all over the DODAG, rather than
>     just in the sub-DODAG that the option did not reach.
>
> NEW:
>
>     It is possible that the temporal alternation of the above two
>     situations might introduce cycles of accepting and then rejecting
>     enrollment traffic.  This is something an operator should consider if
>     they incrementally deploy this option to an existing Low-power/Lossy-
>     Network (LLN).  In addition, an operator would be unable to turn off
>     enrollment traffic by sending a maximum value enrollment priority to
>     the sub-DODAG.  This situation is unfortunate, but without this
>     option, the situation would occur all over the DODAG, rather than
>     just in the sub-DODAG that the option did not reach.
>  CEP: It is not clear what, if anything, the previous paragraph is
> specifying.
>       Moreover, the alternation doesn't really depend on the incremental
>       deployment.  Moreover, to say that one has to deploy the protocol
>       in order to operate the protocol seems unhelpful.  Maybe this
> paragraph
>       would fit better as part of the discussion in the Introduction.
>
>
> ==================================================================
>
> Regards,
> Charlie P.
>
> On 7/7/2025 8:10 AM, Ines Robles wrote:
>
> Dear all,
>
> This is a Working Group Last Call for
> draft-ietf-roll-enrollment-priority-13 (
> https://datatracker.ietf.org/doc/html/draft-ietf-roll-enrollment-priority-13)
> from 07th July to 21th July.
>
> Please read it and let us know your opinion.
>
> Thank you very much in advance,
>
> Ines and Aris.
>
> _______________________________________________
> Roll mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>