Re: [Roll] [Iot-directorate] Iotdir last call review of draft-ietf-roll-turnon-rfc8138-09

[Carles Gomez Montenegro <[e-mail]>]

Hello Pascal,

Thanks for addressing my comments!

Answering to your subsequent email, I believe that the document is now
ready for revision -10.

All the best,

Carles


> Many thanks for your review Carles!
>
>
>
> Please see below:
>
>
>
>> Some nits/questions/comments follow:
>
>>
>
>> - Section 2.1, 1st paragraph:  s/The Terminology/The terminology
>
>>
>
>> - Section 2.1, 2nd paragraph, first line: s/"RPL Instance”/and “RPL
>> Instance”
>
>>
>
>> - Section 2.1, 3rd paragraph: s/RPL Aware Leaf/RPL-Aware Leaf
>
>
>
> Done
>
>
>
>>
>
>> - Section 2.2: note that the use of hyphens in the expanded forms of RAL
>> and
>
>> RUL are different from those in draft-ietf-roll-useofrplinfo. (I think
>> the correct
>
>> form is the one in the turnon-rfc8138 document, but I guess this will
>> be
>
>> confirmed at subsequent stages…)
>
>
>
> See also https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-18
>
> We need to converge and I agree that the hyphened version is correct.
>
> Let us start here 😊
>
>
>
>
>
>> - Section 3: “A MOP value of 7 and above”. If the MOP is a 3-bit
>> field, the
>
>> highest MOP value is 7 (assuming that the lowest value is 0). Why state
>> here
>
>> "and above"? Are there plans to extend the MOP field size?
>
>
>
> Yes, there is. See https://tools.ietf.org/html/draft-ietf-roll-mopex-01.
> This is why. Yet what you are saying makes sense, as written it cannot go
> beyond 7. I can change to "(and above when extended)"
>
>
>
>
>
>> - Section 3, after “A MOP value of 7 and above”. s/MUST use
>
>> compression/indicates that compression MUST be used
>
>
>
> The following text
>
> "
>
>    Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP)
>
>    in the DIO Base Object.  For MOP values 0 to 6, the use of compression
> is
>
>    as specified in this document.  A MOP value of 7 MUST use compression
> by
>
>    default and ignore the setting of the “T” flag.
>
>
>
> "
>
> was suggested by Alvaro during his A-D review. But I believe that your
> proposal does not alter the meaning so I'm picking it.
>
>
>
> Resulting sentence:
>
> "
>
>    Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in
>
>    the DIO Base Object.  This specification applies to MOP values 0 to
>
>    6.  For a MOP value of 7 (and above when extended), the compression
>
>    MUST be used by default regardless of the setting of the "T" flag."
>
>
>
>
>
>> - Section 4, 1st paragraph: “if and only if the "T" flag is set.”
>> Should we
>
>> perhaps append “or if the MOP value is 7.”  ?
>
>
>
> With the change above, I believe that we are good.
>
>
>
>
>
>> - Section 4, 1st paragraph: s/implementations/implementation
>
>
>
> Done
>
>
>
>> - Section 4, 3rd paragraph: What is the "RPL border router"? I couldn't
>> find a
>
>> definition in the Terminology section or in other documents...  May the
>> "RPL
>
>> border router" and the Root run in the same physical device? May the
>> "RPL
>
>> border router" and the Root run in different physical devices?
>
>
>
> Here we mean by border router the 6LR that serves the external route at
> the leaf edge.
>
>
>
> Proposed Clarification:
>
> "
>
>    An external target [USEofRPLinfo] is not expected to support
>
>    [RFC8138].  In most cases, packets from and to an external target are
>
>    tunneled back and forth between the border router (referred to as
>
>    6LR) that serves the external target and the Root, regardless of the
>
>    MOP used in the RPL DODAG.  The inner packet is typically not
>
>    compressed with [RFC8138], so for outgoing packets, the border router
>
>    just needs to decapsulate the (compressed) outer header and forward
>
>    the (uncompressed) inner packet towards the external target.
>
> "
>
>
>
>
>
>> - Section 4, 3rd paragraph: the last sentence is written only from the
>> “from”
>
>> perspective, whereas the previous one is keeps the double "from/to"
>
>> perspective.
>
>
>
> True
>
>
>
>>
>
>> - Section 4, last paragraph, 1st sentence. Please remove the blank space
>> at the
>
>> end of the sentence.
>
>
>
> Done
>
>
>
>>
>
>> - Section 5, 1st paragraph, 2nd sentence. Perhaps prepend the
>> following:
>
>> “Without this specification, ”
>
>
>
> Generalizing to any signaling:
>
> "
>
>                                     Enabling the [RFC8138] compression
>
>    without a turn-on signaling requires a "flag day"; all nodes must be
>
>    upgraded, and then the network can be rebooted with the [RFC8138]
>
>    compression turned on.
>
> "
>
>
>
>
>
> "
>
>>
>
>> - Section 7, last sentence. Might this still be exploited as an attack
>> (e.g. to
>
>> battery-operated devices) based on depleting energy at a faster rate?
>> If
>
>> appropriate, please briefly discuss whether this might be significant or
>> not.
>
>
>
> Added
>
> "
>
>     An attacker in the middle of the network may reset the "T" flag to
> cause
>
>     extra energy spending in its subDAG. Conversely it may set the "T"
> flag, so
>
>     that nodes located downstream would compress when that it is not
> desired,
>
>     potentially resulting in the loss of packets. In a tree structure,
> the
>
>     attacker would be in position to drop the packets from and to the
> attacked
>
>     nodes. So the attacks above would be more complex and more visible
> than
>
>     simply dropping selected packets. The downstream node may have other
>
>     parents and see both settings, which could raise attention.
>
> "
>
>
>
> Does that work?
>
>
>
> I pushed the diffs here:
>
>
>
> https://github.com/roll-wg/roll-turnon-rfc8138/commit/9f5b90e44c45f2a5003e50cf927c2047ee6fbdbf
>
>
>
> Again, many thanks Carles!
>
>
>
> Pascal
> --
> Iot-directorate mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iot-directorate
>