Re: [Roll] Reviews request for draft-ietf-roll-enrollment-priority

["Pascal Thubert (pthubert)" <[e-mail]>]

Dear authors

A few comments and questions:

Intro:
“
[I-D.ietf-6tisch-minimal-security<https://tools.ietf.org/html/draft-ietf-roll-enrollment-priority-03#ref-I-D.ietf-6tisch-minimal-security>] and
   [I-D.ietf-6tisch-dtsecurity-secure-join<https://tools.ietf.org/html/draft-ietf-roll-enrollment-priority-03#ref-I-D.ietf-6tisch-dtsecurity-secure-join>] describe mechanisms by which

“
Is there a plan for the secure join draft?

Section 2:
“

   6LRs that see this DIO Option SHOULD increment their minimum

   enrollment priority if they observe congestion on the channel used

   for enrollment traffic.

“
As described the minimum is that set by the root and propagated unchanged. But if the channel is congested at an ancestor, then the child will not know and accept the enrollment, so the above cannot be achieved. OTOH, if the parent/ancestor could increase the min_priority in the DIO that it propagates, it could inform its descendants not to take more pledges. If we take that path, a child would use either 1) the value of min_priority from its preferred parent or 2) the minimum min_priority across candidate parents. In the case of 2) that might mean use that non-preferred parent for a ratio of traffic. What do you think?

Also:

Considering that the policy to compute the priority increment is unspecified, other global info might be needed by the RPL router. I wonder if it makes sense to place the DODAG size in this option rather than in a metric container as suggested by draft-hushe-roll-dodag-metric-00.

Section 2.1:

Say I want to add a field in the future… What’s the general plan to enhance that option? Push the Length? Do we “must” that the first byte is forever as shown here (please caption the figure) even if the length is > 1? Or should the node ignore the option if length != 1? Or should there be a flag field indicating what’s in like for the Solicited Information option?

Section 3 paragraph 1)

The text below is a cc from https://www.ietf.org/archive/id/draft-ietf-roll-unaware-leaves-30.html#name-security-considerations
“
It is worth noting that with [RFC6550<https://www.ietf.org/archive/id/draft-ietf-roll-unaware-leaves-30.html#RFC6550>], every node in the LLN is RPL-aware and can inject any RPL-based attack in the network.
“
“
In a general manner, the Security Considerations in [RFC6550<https://www.ietf.org/archive/id/draft-ietf-roll-unaware-leaves-30.html#RFC6550>], [RFC7416<https://www.ietf.org/archive/id/draft-ietf-roll-unaware-leaves-30.html#RFC7416>] [RFC6775<https://www.ietf.org/archive/id/draft-ietf-roll-unaware-leaves-30.html#RFC6775>], and [RFC8505<https://www.ietf.org/archive/id/draft-ietf-roll-unaware-leaves-30.html#RFC8505>] apply to this specification as well.
“
believe that it could be adapted here with a bit of tailorization.

You all keep safe!

Pascal



From: Roll <[e-mail]> On Behalf Of Ines Robles
Sent: samedi 23 janvier 2021 13:00
To: roll <[e-mail]>
Subject: [Roll] Reviews request for draft-ietf-roll-enrollment-priority

Dear all,

We are looking reviews for this document:

https://datatracker.ietf.org/doc/draft-ietf-roll-enrollment-priority/

Please let us know if you are willing to help us with that.

Thank you very much in advance,

Ines and Dominique