Skip to main content

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 revision 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
I-D 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 B. Davies (diff)
Assignment Reviewer Peter Van der Stok
State Completed
Request Last Call review on draft-ietf-roll-unaware-leaves by Internet of Things Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/iot-directorate/moZGP1XcGrE46vXXT0qT5gnXD9A
Reviewed revision 23 (document currently at 30)
Result Ready w/issues
Completed 2020-12-08
review-ietf-roll-unaware-leaves-23-iotdir-lc-van-der-stok-2020-12-08-00
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/