Reviewer: Peter Van der Stok Review result: Ready with Issues IOT_DIR review of draft-ietf-roll-unaware-leaves-23 Many thanks for this document that will certainly help developers of products with very high energy constraints. The draft reads rather easily from a linguistic perspective. Unfortunately, some terminology is very difficult to understand. Especially page 4 needs some improvement. This review mainly suggests a simplified terminology; I hope that it helps to reduce the complexity of the draft. peter van der stok ______________________________________________________________________________ Another introduction of terms is suggested for page 4 like: Replace the first three Alineas of page 4 with: Useofrplinfo introduces the terms Ripple Aware Leaf and Ripple Unaware Leaf. A Ripple Aware Leaf is part of a RPL DODAG. A Ripple Unaware Leaf (RUL) is not. A RUL is connected to a 6Lowpan Router (6LR) to send packets over the DODAG that the 6LR belongs to. This note specifies how the RUL communicates with the 6LR and the connected DODAG. In this specification the RUL MUST be a 6lowpan Node (6LN). In contrast, other Ripple Unaware Nodes (RUN) are not 6LNs. In the Alinea: ‘examples …..and/or metering’: s/lightly powered/ severely energy constrained/ And add: The connection of the RUL to the DODAG makes use of the NON-Storing Mechanism even when the DODAG is operated in Storing mode. The unicast forwarding of a RUL packet from the 6LR onwards is described in section 4.1 of useofrplinfo. s/ RPL router/6RL/ page 5 s/6LN/RUL/ s/This document often uses/This document uses/ page 6. After al 1 add: 6LN can be a RAL or RUL. A 6LR is Ripple Aware per definition. Remove ‘This document… RPL by itself’ Page 7, section 3, Introduce the term: The start-6LR is the 6LR that is connected to the RUL. Page 7 everywhere, s/routers/6LR/ Section 3, Alinea 3: s/the root and the 6LR/the root and the start-6LR/ I don’t understand phrase: ‘A RUL is an example ….Host route’ Replace ‘so unless .. serves the RUL)’ by: If the packet from the RUL has no RPI, the 6LR tunnels it to the Root to add an RPI. Page 8 s/ inner packet/encapsulated packet/ Remove ‘[USEofRPLinfo] expects ….to a Host.’ (Unnecessary phrase, RUL is 6LN) The purpose of Sections 4.2.1, 4.2.2 and 4.2.3 is very unclear. In my perception, nowhere is an extension to RUL described. When referring to multicast, I assume you mean link broadcast? 6LN and 6LR need not be written out. In section 4.2.2 there is a reference to RUL, but specification is deferred to 5.1 Section 4.3,line 3, I expect that 6LN should be replaced by RUL. Al 3: S /across the LLN/between RUL and Root/ Section 5, page 11, s /obtain routing services/obtain RPL services/ (2x) s /Router/6LR/ page 12, first phrase: This a double negation, and impossible to understand. Page 12 al 2: S /A RUL that ………………services./ A RUL MUST register to at least one or all the 6LRs from which it desires RPL services. Al 4, S /The RUL needs to/The RUL MUST/ Section 5.2 s/must be able to decapsulate/MUST decapsulate/ Suppress ‘Unless it is aware ….by [RFC8504]’; (How will the root be aware? Not this year anyway.) Page 13, s/leaves that are not aware of RPL/RULs/ Remove ‘outside the RPL domain eg.’ 2nd al. s/on behalf …. functionality in/for any RUL. Section 7 s/RAN/6LR/ Section 9.1 s/6LN/RUL/ Page 19 every where s/6LN/RUL/ In fig 6 and 7 s/’6LN/RUL’/RUL; (having defined that a RUL is a 6LN) Page 21, Section 9.2.1 title: Perspective of the RUL First phrase: This specification specifies the RUL operation that is conform to the 6LN operation. s/6LN/RUL/ on page 21, 22, 23 , 25, 26 everywhere page 22 point 4 remove ‘a 6LN acting as’ page 27 s/6LN/RUL/ what does ‘maintain the binding’ mean? Page 28 section 10. I don’t understand al 2 ‘The RPL support …..listener 6LN’ Page 18 s/6LN/RUL/ Figure 10,11 6LN/RUL ->RUL Section 11 Shorter Suggestion: Only RPL aware nodes can effectuate a RPL based attack in the network. Consequently, nodes that are not part of the DODAG can only attack the RPL network when they are RULs. Page 31,32 s/6LN/RUL/ and s/rogue/rogue RUL/ -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
