|
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 |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
