Last Call Review of draft-ietf-roll-unaware-leaves-23
review-ietf-roll-unaware-leaves-23-iotdir-lc-van-der-stok-2020-12-08-00

Request Review of draft-ietf-roll-unaware-leaves
Requested rev. no specific revision (document currently at 30)
Type Last Call Review
Team Internet of Things Directorate (iotdir)
Deadline 2020-12-09
Requested 2020-11-16
Requested by Alvaro Retana
Authors Pascal Thubert, Michael Richardson
Draft last updated 2020-12-08
Completed reviews Iotdir Last Call review of -13 by Shwetha Bhandari (diff)
Rtgdir Last Call review of -23 by Julien Meuric (diff)
Iotdir Last Call review of -23 by Peter Van der Stok (diff)
Secdir Last Call review of -23 by Carl Wallace (diff)
Genart Last Call review of -24 by Elwyn Davies (diff)
Assignment Reviewer Peter Van der Stok 
State Completed Snapshot
Review review-ietf-roll-unaware-leaves-23-iotdir-lc-van-der-stok-2020-12-08
Posted at https://mailarchive.ietf.org/arch/msg/iot-directorate/moZGP1XcGrE46vXXT0qT5gnXD9A
Reviewed rev. 23 (document currently at 30)
Review result Ready with Issues
Review completed: 2020-12-08

Review
review-ietf-roll-unaware-leaves-23-iotdir-lc-van-der-stok-2020-12-08

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/