Re: [Roll] AD Review of draft-ietf-roll-turnon-rfc8138-07

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

Hello Alvaro

Many thanks for your review!

Indeed we have this problem with the capabilities draft. On the one hand, the missing flag blocks the use of RFC 8138 in brown field networks and 3rd party standards that would build on RPL, so we want turnon, like yesterday. Note that those are RPLv1.

OTOH, the complete scenario would be with the capabilities, but then the capabilities draft is not stable, so it would push the feature to an undefined future (till RPLv2 in fact). Existing RPLv1 networks will never benefit from the capability draft, you'll need a flag day to make them RPLv2.

So we went for the unpleasant (b) which means that for now we live without the capability and it takes an external management system to know if all nodes are ready; in the future the capability draft will improve the game as a second step for RPLv2 networks. 

Now this is in the open for the group to reconsider; I still stand for (b) though you're completely right that a piece is missing.

Also, I'd like to have a round of Q/A with you before I propose text, so make sure we agree on the direction, if that's OK?

Please see below:

> In short, I believe that the specification in this draft is incomplete.  Specifically:
> 
> (1) §5.2 talks about the use of a single RPL instance, where an extra OCP is
>     needed.  However, that OCP is not defined/assigned anywhere.  It then
>     seems to me that this scenario cannot be implemented.  Am I missing
>     something?  Is the intent of this section to specify the scenario, or
>     simply as an example of something that was considered but not
> recommended
>     (in favor of §5,3)?

Both, actually. A deployment is free to use its own OCPs with its own OFs, the whole game being to allow new environments (metrics and logic) that the IETF could not predict. I did not expect OF0 to be generally used, all the contrary I just wanted to provide a strawman on how to specify an OF in another std body; it is very possible for the upgraded node to be configured with OCP =5 with the meaning that it is the same as OCP=4, or a smallish variation of it that favors parents that expose the DODAG that has the new flag set. Now, this is a bit scary and weird, and as you point out, not favored.

Is it enough to indicate the latter (not recommended) or should I also indicate how that's possible with the explanation above?

> (2) The text talks in several places about how a "parent router must
>     know...when a leaf does not support the compression defined in
>     [RFC8138]."  There is no specification related to *how* the parent would
>     know.  The only hint is in the Introduction: "by configuration, or
>     leveraging "RPL Capabilities" [CAPABILITIES]".  Note that the rest of the
>     text doesn't even mention configuration as an option.

Maybe we should stick to network management / configuration for this draft? Note that when the parent does not know, it decompresses, so the text should probably say that if the parent knows for sure that the leaf supports the compression then it can leave the packet compressed, else it MUST uncompress. Will that be better


>     I know that there's some resistance to normatively depend on
>     draft-ietf-roll-capabilities.  However, the specification does use
>     Normative language when describing the expected action based on the
>     knowledge of support (or not); for example "delivering to a leaf that is
>     not known to support [RFC8138], in which cases it MUST uncompress the
>     packet." (§4)   Knowing that a capability is not yet explicitly defined
>     for this use, I think there are a couple of ways forward:
> 
>     (a) Define, in this document or draft-ietf-roll-capabilities, the
>     capability to indicate support for rfc8138.  Make
>     draft-ietf-roll-capabilities a Normative reference.
> 
>     (b) Specify that the current method to know if the leaf supports rfc8138
>     is (only) configuration.  Take all references to
>     draft-ietf-roll-capabilities out.
> 
> 
>     [Personal opinion: (a) is the complete solution.]

I placed the discussion at the top of the mail because it is core. I believe we need to support the RPLv1 brown field and that RPL v2 will come with this and other capabilities, later. 

> (3) §3 says that ""T" flag is defined only for MOP value between 0 to 6".
>     The current registry is not set up for this type of assignment, so it
>     needs to be updated (see more specifics below).

Yes there is something there. One thing is that MOP value between 0 to 6 designate RPLv1. 
https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-40#section-4.3 has similar language and the same concern. 

A proposal would be for now to rename the registry to indicate MOP values 0..1 and the specs of RPL v2 will have to create another registry per MOP.

An alternate is a new column and we tried that with RFC 8025 https://www.iana.org/assignments/_6lowpan-parameters/_6lowpan-parameters.xhtml#_6lowpan-parameters-1 . But that has become a nightmare to manage for IANA and now we are talking about splitting.

What's you inclination? Which draft should resquest it?

> 
> I will wait for these points to be addressed before moving the document
> forward.  I also have more comments inline below.
> 
> 
> Thanks!!
> 
> Alvaro.
> 
> 
> [Line numbers from idnits.]
> 
> ...
> 11	Abstract
> 
> 13	   This document updates RFC 8138 and RFC 6550 by defining a bit in
> the
> 14	   RPL configuration option to indicate whether RFC 8138 compression
> is
> 15	   used within the RPL Instance, and specify the behavior of RFC
> 16	   8138-capable nodes when the bit is set and reset.
> 
> [major] rfc6550 talks about the "DODAG Configuration option", and not about
> a "RPL configuration option".  Please be consistent!

Will do

> 
> ...
> 70	1.  Introduction
> 
> 72	   The transition of a RPL [RFC6550] network to activate the
> compression
> 73	   defined in [RFC8138] can only be done when all routers in the
> network
> 74	   support it.  Otherwise, a non-capable node acting as a router would
> 75	   drop the compressed packets and black-hole its subDAG.  In a mixed
> 76	   case with both RFC8138-capable and non-capable nodes, the
> compression
> 77	   may be turned on only if all the non-capable nodes act as Hosts and
> 78	   their RPL parents handle the compression/decompression for them.
> 
> [nit] Expand/explain subDAG.


Will do



> 
> 
> ...
> 128	2.2.  Glossary
> 
> 130	   This document often uses the following acronyms:
> 
> [nit] Some of the acronyms were already defined in the previous section.
> 
 
Will do

> ...
> 147	2.3.  BCP 14
> 
> [minor] s/BCP 14/Requirements Language
> 
>
 
Will do
 
> ...
> 155	3.  Updating RFC 6550
> 
> [major] I don't think that a formal Update to rfc6550 is necessary.
> In general, a formal Update indicates (at least to me) that an rfc6550
> implementation has to also support this specification.  IOW, all RPL routers will
> have to support the new flag to be compliant with rfc6550.  Also, rfc8138 did
> not formally Update rfc6550.
> 
> [minor] I think that this section could be reorganized a little: start by telling the
> reader what the Configuration Option is and that it is distributed
> everywhere...this should provide background to understand the availability of
> the T bit in the network.
> 

 
Will do

> 
> 157	   This specification defines a new flag "Enable RFC8138 Compression"
> 158	   (T).  The "T" flag is set to turn on the use of the compression of
> 159	   RPL artifacts with [RFC8138] within a RPL Instance.  If a RPL
> 160	   Instance has multiple Roots then they must be coordinated to use the
> 161	   same setting.
> 
> [major] Do we need a Normative MUST in the last sentence?  What is the
> effect of the roots not coordinating?

There are possible side effects like a node that is a router in a "T" off dodag would become a leaf as it jumps to the "T" on, leaving its children potentially orphan. Also trouble if using projected routes that traverse DODAGs. So it seemed simpler to request a coordinated setting in the RPL domain than to go through those cases.

I do not see things that we could not address with enough effort but this "must" is a way to keep things simple. Happy to make it a MUST. Note that this is also a problem to be handled for any configuration item. All the DODAGs must have the same configuration else roaming becomes complex with a situation that depends on the configuration item.

Now you make me wonder what we can really do with the capabilities in the case of multiple roots. Each can only learn the capabilities within its own DODAG. Like I said the capabilities work is not complete.


> 
> 
> 163	   RPL defines a Configuration Option that is registered to IANA in
> 164	   section 20.14. of [RFC6550].  The "T" flag is encoded in one of the
> 165	   reserved control bits in the RPL Configuration Option.  The bit
> 166	   position of the "T" flag is indicated in Section 6.
> 
> [minor] "RPL defines a Configuration Option that is registered to IANA in
> section 20.14. of [RFC6550]."  The Configuration Option (the whole
> thing) is not registered to IANA, the Flags have a registry managed by IANA.

True, will correct that 

> 
> [minor] It would be very nice if the packet format was shown here with the
> new flag.

Yes, I thought of doing that but it is in flux with other drafts also setting bits. A lot easier not to do it but if you insist...

> 
> 
> 168	   Section 6.3.1.  of [RFC6550] defines a 3-bit Mode of Operation (MOP)
> 169	   in the DIO Base Object.  The new "T" flag is defined only for MOP
> 170	   value between 0 to 6.  For a MOP value of 7 or above, the flag MAY
> 171	   indicate something different and MUST NOT be interpreted as
> "Enable
> 172	   RFC8138 Compression" unless the specification of the MOP indicates
> to
> 173	   do so.
> 
> [major] The last sentence is not needed: the second one already says that the
> flag is only valid for 0-6. 
> 
> Also, I think there's a Normative conflict with "MAY indicate something
> different and MUST NOT be interpreted as...unless the specification of the
> MOP indicates to do so."  Perhaps, if you really want to keep some text, you
> can include something like this:
> 
>    A document defining a MOP with value 7 or above MUST specify the behavior
>    of the T flag.
> 

It may also not use it at all : ) what about 
A document defining a MOP with value 7 or above MUST specify the behavior
of the T flag or keep it reserved

> 
> [major] Regardless of the text, this document is specifying a split in the registry
> (at last for this flag): it applies to some MOPs, but not all.  The registry needs to
> be updated in the IANA Considerations section to show that difference.  Is this
> update being done somewhere else?

We can do it here; useofrplinfo is shipping earlier and has the same concern.

> 
> I thought that draft-ietf-roll-mopex would be a good place, but the update
> doesn't seem to be there.  The intent of not applying to all the MOPs can't be
> finalized until the registry can reflect it.

Happy to indicate in MOPex that the MOPs over 7 create the new IANA registries.
Since the MOPs above 7 do not exist at this time, there does not seem to be a consequence in delaying the IANA update.

> 
> 
> 175	4.  Updating RFC 8138
> 
> 177	   A node that supports this specification MUST source packets in the
> 178	   compressed form using [RFC8138] if and only if the "T" flag is set.
> 179	   This behaviour can be overridden by the configuration of the node in
> 180	   order to cope with intermediate implementations of the Root that
> 181	   support [RFC8138] but not this specification and cannot set the "T"
> 182	   flag.
> 
> [nit] s/A node that supports this specification/A node
> 
> [major] "MUST...if and only if...behaviour can be
> overridden"   s/MUST/SHOULD


Will do both

> 
> 184	   The decision of using [RFC8138] is made by the originator of the
> 185	   packet depending on its capabilities and its knowledge of the state
> 186	   of the "T" flag.  A router that encapsulates a packet is the
> 187	   originator of the resulting packet and decides whether to compress
> 188	   the outer headers as indicated above.  An external target
> 189	   [USEofRPLinfo] is not expected to support [RFC8138].  An intermediate
> 190	   router MUST forward the packet in the form that the source used,
> 191	   either compressed or uncompressed, unless it is forwarding to an
> 192	   external target or delivering to a leaf that is not known to support
> 193	   [RFC8138], in which cases it MUST uncompress the packet.
> 
> [minor] "as indicated above"  Where?
> 
> [major] "MUST forward...unless...MUST"  That's a strange construct with the
> exception in the middle.
> 
> NEW>
>    An intermediate router MUST uncompress a packet that is to be forwarded
>    to an external target or delivered to a leaf that is not known to support
>    [RFC8138].  Otherwise, the router MUST forward the packet in the form that
>    the source used, either compressed or uncompressed.

Great!


> [major] "not known"  How would the router know?  §1 mentions capabilities as
> an example), but that is not part of the specification...the MUSTs above make
> it so.
> 

Will add that this is the config / management information as discusses at the beginning of this mail


> 
> 195	5.  Transition Scenarios
> ...
> 207	   A node that does not support [RFC8138] can interoperate with nodes
> 208	   that do in a network with [RFC8138] compression turned off.  If the
> 209	   compression is turned on, the node cannot forward compressed
> packets
> 210	   and therefore it cannot act as a router.  It may remain connected to
> 211	   that network as a leaf, generates uncompressed packets, and can
> 212	   receive packets if they are delivered by the parent router in the
> 213	   uncompressed form.  Unless this is known by other means, the node
> 214	   SHOULD join as a RUL as an indication that its parent router needs to
> 215	   uncompress the packets before delivering.
> 
> [nit] s/generates/generate

Will do

> 
> [minor] "this is known"  This, what?  Assuming that "this" refers to the lack of
> support for rfc8138, we're then to the question of *how* would it be known.
> 

Maybe we can have a small section on that, and refer to it in the few places where the knowledge is useful?

> [major] "the node SHOULD join as a RUL"  To be clear, we're talking about a
> node that doesn't support rfc8138, right?  I'm assuming that if it doesn't
> support rfc8138 then it won't support this specification either -- then we can't
> normatively define anything that this type of node would do!

The RUL draft https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ is independent of this and if RFC 8138. The RUL operation is arch minimal vs. RPL support. 
It creates the default assumption of no support for RFC 8138 and provides RPL routing with less hassle. If the node cannot do RUL then it should not attempt to join.
Suggestion is to add a reference to remind what the RUL operation i.

> 
> 
> 217	   [RFC6550] states that "Nodes other than the DODAG Root MUST
> NOT
> 218	   modify this information when propagating the DODAG Configuration
> 219	   option".  Therefore, even a legacy parent propagates the "T" flag as
> 220	   set by the Root whether it supports this specification or not.  So
> 221	   when the "T" flag is set, it is transparently flooded to all the
> 222	   nodes in the RPL Instance.
> 
> [major] s/[RFC6550] states/[RFC6550] states, when referring to the DODAG
> Configuration option,

Will do

> 
> 
> 224	   Sections 8.5 and 9.2 of [RFC6550] also suggests that a RAN may only
> 225	   attach to a DODAG as a leaf when it does not support the Mode of
> 226	   Operation of a RPL Instance, the Objective Function (OF) as indicated
> 227	   by the Objective Code Point (OCP) or some other parameters in the
> 228	   configuration option.
> 
> [minor] s/also suggests that a RAN may only attach/specify that a RAN may
> attach
> 

Will do

> 
> 230	   This specification reiterates that a RAN that is configured to
> 231	   operate in a RPL Instance but does not support a value for a known
> 232	   parameter that is mandatory for routing, such as the OCP, MUST
> NOT
> 233	   operate as a router but MAY still join as a leaf.  Note that a legacy
> 234	   RAN will not recognize when a reserved field is used and will not
> 235	   turn to a leaf when the "T" flag is set.
> 
> [major] "This specification reiterates..."  Saying things again is not a big deal;
> but normatively specifying them is.  In this case it is not only not necessary, but
> also has no effect over nodes that don't support this document...so it is not
> needed.
> 

Ack, will remove

> 
> ...
> 244	5.1.  Inconsistent State While Migrating
> 
> 246	   When the "T" flag is turned on in the configuration option by the
> 247	   Root, the information slowly percolates through the DODAG as the
> DIO
> 248	   gets propagated.
> 
> [?] How slow?  Seconds, minutes?

Depends in the Trickle settings, could be second to days. I can remind that in this text.

> 
> 
> 250	   Some nodes will see the flag and start sourcing packets in the
> 251	   compressed form while other nodes in the same RPL Instance are still
> 252	   not aware of it.  Conversely, in non-storing mode, the Root will
> 253	   start using [RFC8138] with a Source Routing Header 6LoRH (SRH-
> 6LoRH)
> 254	   that routes all the way to the parent router or to the leaf.
> 
> [minor] I don't understand how the second sentence reverses
> ("Conversely") the statement in the first sentence...or how the mode affects
> the outcome of nodes (including the Root) sending compressed packets when
> others may not still be aware of the flag or able to support receiving the
> packets...

Wrong term, sorry. I guess we can just remove that word? I cannot find the term that would say "the related thing in the opposite situation"

> 
> [minor] "[RFC8138] with a Source Routing Header 6LoRH (SRH-6LoRH)"
> sounds redundant.  Also, this is the only place in the document where the use
> of rfc8138 is coupled with the SRH-6LoRH.  Not wrong, just redundant and
> inconsistent.  If needed, the sentence can be restructured.

RFC 8138 defines the 6LoRH. The SRH-6LoRH is one of the possible 6LoRH. It is used to transport a source routing header. This happens only in non-storing mode. In general the text talks about any and all 6LoRH. This sentence is the place where we talk about the specific case when one of the 6LoRH added to the frame is an SRH. It probably looks redundant but actually the wording was intended. Should I change since it creates confusion? Suggestion?


> 
> 256	   To ensure that a packet is forwarded across the RPL Instance in the
> 257	   form in which it was generated, it is required that all the routers
> 258	   support [RFC8138] at the time of the switch, and that all nodes that
> 259	   do not support [RFC8138] only operate as leaves.
> 
> 261	   Setting the "T" flag is ultimately the responsibility of the network
> 262	   administrator.  In a case of upgrading a network to turn the
> 263	   compression on, the network SHOULD be operated with the "T" flag
> 264	   reset until all targeted nodes are upgraded to support this
> 265	   specification.  Section 5.2 and Section 5.3 provide possible
> 266	   transition scenarios where this can be enforced.
> 
> [major] This section talks about inconsistencies, and it is "required that all the
> routers support [RFC8138]", but then not setting the T flag is only
> recommended.  Why/when is it ok to set the flag if it is known that not all
> nodes support rfc8138?  IOW, why not use MUST?

Yes, MUST it must be.

> 
> 
> 268	5.2.  Single RPL Instance Scenario
> 
> 270	   In a Single RPL Instance Scenario, nodes that support [RFC8138] are
> 271	   configured with a new OCP, that may use the same OF operation or a
> 272	   variation of it, while nodes that do not support [RFC8138] are not,
> 273	   but are configured to join an unknown OCP.
> 
> [major] A new OCP?  I only see 2 OCPs in the registry -- unless I'm missing
> something, there's no way to configure "a new OCP, that may use the same
> OF".
> 

Actually the intent is to use an unregistered OCP. The registry is intended for well-known OCPs but is not seen as limitative. 
We probably should define a range for private / experimental OCPs to avoid this situation?


> 
> ...
> 279	   The parent router - which supports [RFC8138] - compresses the
> packets
> 280	   originated from the leaf and uncompresses the packets going to the
> 281	   leaf.  This may be done on the fly by the parent of a non-capable
> 282	   RAL, or as part of the tunneling operation between the parent and
> the
> 283	   Root, if the leaf behaves as a RUL.  This is described in section 7,
> 284	   8, and 9 of [USEofRPLinfo].
> 
> [nit] s/This is/This operation is

OK


> 
> 
> 286	   Note that though tunneling from the Root to the parent is the generic
> 287	   case for RULs, on paper it is possible for the Root to avoid it for
> 288	   the traffic that it originates.  The Root SHOULD always use tunneling
> 289	   to the parent of a RUL, even for its own packets, unless it knows
> 290	   that the leaf supports [RFC8138].
> 
> [nit] s/on paper/

Ack

> 
> [major] "RUL...unless it knows that the leaf supports [RFC8138]"
> Isn't this a contradiction?  [BTW, §1 says that RULs implicitly don't support
> rfc8138.]

Yes, the RUL is not expected to understand RFC 8138, but on paper it could, there is no law that says it must not. 
It would just be VERY surprising to support RPL compression but not RPL. I need to revisit both places.
For the text above, maybe I should remove the "unless it knows that the leaf supports [RFC8138]" because it creates more questions than it actually helps.

> 
> [major] "unless it knows that the leaf supports [RFC8138]"  Assuming you're
> not talking about a RUL, how do you know?  §1 mentions capabilities as an
> example, but that is not part of the specification...the SHOULD above makes it
> so.
> 

Same as several times above, I suggest we do (b) and document knowledge through management.

> 
> ...
> 294	   *  The method consumes an extra OCP.  It also forces nodes that do
> 295	      not support [RFC8138] to operate as RULs, unless there is a method
> 296	      to let the parent router know that it must uncompress the packet
> 297	      for this RAL.
> 
> [major] What is this "method to let the parent router know..."?
> 


Can add "e.g., through management". The goal of this weird wording is to leave the road open for capabilities when they come. Your suggestions very welcome!

> 
> 299	   *  If the RPL implementation of a node does not turn it to a leaf
> 300	      when the OCP is changed to an unknown one, then the node may
> be
> 301	      stalled.
> 
> [minor] Right, but then this implementation wouldn't be compliant with
> rfc6550.

Correct. Can I remove that sentence?


> 
> 
> 303	   *  If the only possible parents of a node are nodes that do not
> 304	      support [RFC8138], then that node will loose all its parent at the
> 305	      time of the migration and it will be stalled until a parent is
> 306	      deployed with the new capability.
> 
> [minor] If the parents don't support rfc3183 then they would have joined as
> leaves anyway (because of the new OCP) and wouldn't really be available as
> parents, right?  What am I missing?

Say T is off and those guys are parents. Then we set T on. As you point out they become leaves so they are no more available as parents. This node becomes an orphan though it was not before as a consequence of turning the flag. In the 2 instances method, this node remains attached to the old DODAG and the root can see that it Is not visible on the new instance, so it can figure there's something to do like upgrade or deploy more.

> 
> 
> 308	5.3.  Double RPL Instances Scenario
> ...
> 319	   Nodes that support [RFC8138] participate in both Instances but favor
> 320	   the new RPL Instance for the traffic that they source.  By contrast,
> 321	   nodes that only support the uncompressed format would either not
> be
> 322	   configured for the new RPL Instance, or would be configured to join
> 323	   it as leaves only.
> 
> [major] "Nodes that support [RFC8138]...favor the new RPL Instance for the
> traffic that they source..."   Support for rfc8138 doesn't require
> compression.  IOW, a node that supports rfc8138 can compress, but it doesn't
> have to, right?  I think you need to be more specific when talking about
> "favor"; does it mean that the routers SHOULD use the new instance?

Yes, will reword like that. It MUST join the new instance and SHOULD use it for its traffic to benefit from the compression. It is a SHOULD because the RANK in that more limited DODAG may be bad in which case it is unusable. I can add words that say that too.

> 
> 
> ...
> 330	   The 2 instances MUST be operated with the same security
> guarantees,
> 331	   e.g., both "unsecured" with a lower layer security of a same
> 332	   strength, both "preinstalled" or both "authenticated" security mode
> 333	   (see section 3.2.3 of [RFC6550] for more details on those modes).
> 334	   The latter mode could be use to enforce the segregation of updated
> 335	   and non-updated nodes, by providing the keys for joining as routers
> 336	   to the updated nodes only.
> 
> [nit] s/could be use/could be used

Ack

> 
> [major] "The 2 instances MUST be operated with the same security
> guarantees..."  Why is that a requirement?  Would something break if it is not
> the case?
> 

Hmu, the new instance should have at least the same guarantees, otherwise we are trading compression gains with security, hard to do.

> 
> 338	5.4.  Rolling Back
> 
> 340	   After downgrading a network to turn the [RFC8138] compression off,
> 341	   the administrator SHOULD make sure that all nodes have converged
> to
> 342	   the "T" flag reset before allowing nodes that do not support the
> 343	   compression in the network (see caveats in Section 5.2).
> 
> [minor] "downgrading" sounds as if software needs to changed (at least)...but
> in this case it is a configuration change.  Maybe something like:
> 
>    When turning [RFC8138] compression off in the network...
> 


OK, no problem, will change

> 
> [major] s/SHOULD make sure that all nodes have converged/SHOULD wait until
> all nodes have converged
> 

OK

> [minor] How does the administrator know when the nodes have converged?
>  Given the potential problems, it sounds like a MUST may be more
> appropriate...??

Yes, will MUST


> 
> [minor] "see caveats in Section 5.2"  The caveats there don't seem to apply
> unless the single instance scenario is specified somehow...
> 

I can remove the "see caveats". The bottom line is that the legacy nodes will not like a compressed packet so we need to ensure the T off is generalized first.

> ...
> 349	6.  IANA Considerations
> 
> 351	   This specification updates the Registry for the "DODAG Configuration
> 352	   Option Flags" that was created for [RFC6550] as follows:
> 
> [major] s/This specification updates/IANA is requested to assign a new option
> flag from


OK

> 
> 354	       +------------+---------------------------------+-----------+
> 355	       | Bit Number | Capability Description          | Reference |
> 356
> 	       +============+=================================+========
> ===+
> 357	       | 2          | Turn on RFC8138 Compression (T) | THIS RFC  |
> 358	       +------------+---------------------------------+-----------+
> 
> [major] This value (even though is free in the registry) should be marked as a
> suggestion for IANA.

OK will do

> 
> 
> ...
> 362	7.  Security Considerations
> 
> 364	   First of all, it is worth noting that with [RFC6550], every node in
> 365	   the LLN that is RPL-aware can inject any RPL-based attack in the
> 366	   network.  A trust model MUST be put in place so that rogue nodes
> are
> 367	   excluded from participating to the RPL and the 6LowpAN signaling,
> and
> 368	   from the data packet exchange.  This trust model could be at a
> 369	   minimum based on a Layer-2 Secure joining and the Link-Layer
> 370	   security.  This is a generic RPL and 6LoWPAN requirement, see
> Req5.1
> 371	   in Appendix of [RFC8505].
> 
> [major] Is this paragraph talks about an "generic RPL and 6LoWPAN
> requirement", then please don't use Normative language.  Also, pointing at the
> appropriate RFCs and their Security Considerations is enough.

OK

> 
> [] As a side note, secure joining doesn't really prevent a rogue node from being
> in the network.  Consider the case where the node is subverted after
> joining...or simply where the administrator can set the T flag (as below).
> 

Very true; we are starting zero trust work in IOT, like https://datatracker.ietf.org/doc/draft-ietf-6lo-ap-nd/ and ROV is RPL by transporting the ROVR in DaDAO messages see https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ . Maybe
 
"so that rogue nodes are excluded from participating to the RPL"
->
"in an effort to exclude rogue nodes from participating to the RPL"

> are
> 367	   excluded from participating to the RPL
> 
> 373	   Setting the "T" flag before some routers are upgraded may cause a
> 374	   loss of packets.  The new bit is protected as the rest of the
> 375	   configuration so this is just one of the many attacks that can happen
> 376	   if an attacker manages to inject a corrupted configuration.
> 
> [nit] s/before some routers/before all routers

Ack, will change

> 
> 
> ...
> 392	9.  Normative References
> ...
> 414	   [RFC7228]  Bormann, C., Ersue, M., and A. Keranen, "Terminology for
> 415	              Constrained-Node Networks", RFC 7228,
> 416	              DOI 10.17487/RFC7228, May 2014,
> 417	              <https://www.rfc-editor.org/info/rfc7228>.
> 
> [major] This reference should be Informative.

I'm getting that recommendation in both ways but OK, will do.


> 
> 
> ...
> 427	   [UNAWARE-LEAVES]
> 428	              Thubert, P. and M. Richardson, "Routing for RPL Leaves",
> 429	              Work in Progress, Internet-Draft, draft-ietf-roll-unaware-
> 430	              leaves-14, 11 April 2020, <https://tools.ietf.org/html/
> 431	              draft-ietf-roll-unaware-leaves-14>.
> 
> [minor] This reference can be Informative.
> 
OK

> 
> 433	10.  Informative References
> ...
> 441	   [RFC8138]  Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
> 442	              "IPv6 over Low-Power Wireless Personal Area Network
> 443	              (6LoWPAN) Routing Header", RFC 8138, DOI
> 10.17487/RFC8138,
> 444	              April 2017, <https://www.rfc-editor.org/info/rfc8138>.
> 
> [major] This reference must be Normative.


OK also : )

So many thanks Alvaro, this was really deep and constructive. Please let me know when the proposals are in the right direction and when not. Based on that I'll publish a revision to track the proposed changes and present it to you.

Take care,

Pascal