Submitted! URL: https://www.ietf.org/internet-drafts/draft-ietf-roll-turnon-rfc8138-10.txt Status: https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ Htmlized: https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-10 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-roll-turnon-rfc8138 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-10 Many thanks to both of you 😊 Pascal > -----Original Message----- > From: Carles Gomez Montenegro <carlesgo@xxxxxxxxxxxxx> > Sent: mercredi 5 août 2020 18:19 > To: Pascal Thubert (pthubert) <pthubert@xxxxxxxxx> > Cc: iot-directorate@xxxxxxxx; last-call@xxxxxxxx; roll@xxxxxxxx; draft-ietf-roll- > turnon-rfc8138.all@xxxxxxxx > Subject: Re: [Iot-directorate] Iotdir last call review of draft-ietf-roll-turnon- > rfc8138-09 > > 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/9f5b90e44c45f2a5 > > 003e50cf927c2047ee6fbdbf > > > > > > > > Again, many thanks Carles! > > > > > > > > Pascal > > -- > > Iot-directorate mailing list > > Iot-directorate@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/iot-directorate > > > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
