Subject: [Roll] Iotdir last call review of draft-ietf-roll-unaware-leaves-23

From: Peter Van der Stok via Datatracker <[email-masked]>
Date: Tue, 08 Dec 2020 07:02:08 -0800

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/

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Dec 2020 12:09:01 -0500

Thank you Peter, we'll try to get your suggestions in during AUTH48.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 9 Dec 2020 18:42:05 +0000

Dear Peter

Many thanks for your deep review! 

I submitted the proposed changes as rev 24 so you can investigate what I did in the diffs:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-24

Let's see below.

> 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

> 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

Does that really help, Peter? 
1) Your proposal changes the rule to elaborate the acronym on first use.
2) Injecting route is something that people understand beyond the world of RPL. Adding the DODAG and 6LowPAN terminology makes things even harder to figure, doesn't it? All this comes later.
3) The definition In https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-42#section-2 is purely RPL based and does not imply 6LoWPAN. A RUL could use a non-6LoWPAN method to attach to the LLN, e.g., another IGP. The draft presents one such method that is indeed based on 6LoWPAN ND.
4) we also debated on whether it is a 6LoWPAN node acting as a RUL or the other way around; we settled for one side and I would not reopen the wound.

Still I see the need to simplify. What about
"
   Section 2 of [USEofRPLinfo] defines the terms RPL Leaf, RPL-Aware-
   Leaf (RAL) and RPL-Unaware Leaf (RUL).  A RPL Leaf is a Host attached
   to one or more RPL router(s); as such, it relies on the RPL router(s)
   to forward its traffic across the RPL domain but does not forward
   traffic from another node.  As opposed to the RAL, the RUL does not
   participate to RPL, and relies on its RPL router(s) also to inject
   the routes to its IPv6 addresses in the RPL domain.

...

   This document specifies how the Router injects the Host routes in the
   RPL domain on behalf of the RUL.  Section 5 details how the RUL can
   leverage 6LoWPAN ND to obtain the routing services from the router.
   In that model, the RUL is also a 6LoWPAN Node (6LN) and the RPL-Aware
   router is also a 6LoWPAN Router (6LR).  Using the 6LoWPAN ND Address
   Registration mechanism, the RUL signals that the router must inject a
   Host route for the Registered Address.
"

Note that there's a formatting issue in the notes as I received them, so I'm doing my best; also that I have concerns with many of the proposed changes because they word the operation from a 6LoWPAN standpoint and this is still a ROLL spec. All in all I picked what I could extract from the below.

> constrained/ 

Done

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:

That's actually wrong. Most routers are not 6LRs. They are RPL routers. Only the attachment router that connects the RUL using this spec needs to be a 6LR as well.

> ‘A RUL is an
> Page 8 s/ inner packet/encapsulated packet/ Remove ‘[USEofRPLinfo] expects
> ….to a Host.’ (Unnecessary phrase, RUL is 6LN) 

And what is the expectation on a 6LN? There's no document like requirements on a 6LN like RFC 8504 is there?

The purpose of Sections 4.2.1,
> 4.2.2 and 4.2.3 is very unclear.

The whole section 4 is a description of the pieces of 6LoWPAN ND that the reader may need.
I added text at the beginning of section 4:
"

4.  6LoWPAN Neighbor Discovery

   This section goes through the 6LoWPAN ND mechanisms that are
   leveraged in this specification as a non-normative reference to the
   reader.  The normative text is to be found in [RFC6775], [RFC8505],
   and [RFC8928].
"

> In my perception, nowhere is an extension to
> RUL described.

The specification is for the 6LR operation. There is a requirement on how the 6LN uses RFC 8505 as well, but the normative text for the 6LN operation is in RFC 8505.
The explanation is reworded in the intro as:
"
   This document specifies how the Router injects the Host routes in the
   RPL domain on behalf of the RUL.  Section 5 details how the RUL can
   leverage 6LoWPAN ND to obtain the routing services from the router.
"

 When referring to multicast, I assume you mean link
> broadcast? 

Well the text says multicast rightfully but you're correct that behind the seen the L3 multicast because a L1/2 broadcast.

> 6LN and 6LR need not be written out.

I do not understand this?

> 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/ 

Actually between the 6LR and the root. The intention of the formulation is to emphasize the cost.

Section 5, page 11,  s /obtain routing services/obtain RPL

Ne. the full sentence is 
"
This section describes
   the minimal RPL-independent functionality that the RUL needs to
   implement to obtain routing services for its addresses.
"

The whole point is that from the RUL perspective it is not RPL. It is routing.

> services/ (2x) s /Router/6LR/ page 12, first phrase:

> This a double negation, and impossible to understand.

Turned it to an "only if" form. Concerned that other people may find it actually harder. Both versions are correct.
"
   The RUL is expected to request routing services from a Router only if that router originates RA messages with a CIO that has the L, P, and E flags all set
"
> services. Al 4, S /The RUL needs to/The RUL MUST/ 

This belongs to RFC 8505 and is there; This doc must not paraphrase normatively.

Section 5.2 s/must be able
> to decapsulate/MUST decapsulate/

Same; plus that hhere we do not describe the operation but the capability to perform that operation. Text is correct.

 Suppress ‘Unless it is aware ….by
> [RFC8504]’; (How will the root be aware? Not this year anyway.) 

By other means, as said. This includes configuration, or the general standard that encompasses this spec, like a Thread that imposes that all leaves support IP in IP

Page 13,
> s/leaves that are not aware of RPL/RULs/

That was voluntary, to emphasize the point

 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

Actually you're countermanding a conscious decision. 

The RUL does not know it is a RUL. It knows it is a 6LN. So it is a 6LN Acting as RUL, though probably it does not know. What we describe is what it knows, that is a 6LN behaviour.

> 4 remove ‘a 6LN acting as’ page 27 s/6LN/RUL/ what does ‘maintain the

Again, that is something that was discussed and agreed upon in earlier reviews. I'm not saying that your point of view is invalid. But we went for the other option.

> mean? Page 28 section 10. I don’t understand al 2 ‘The RPL support …..listener

I reread but cannot find how to clarify moore. This is MLD.

> 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/

Yes I added this all the way back to the intro

"
   A RUL may be unable to participate because it is very energy-constrained,
   code-space constrained, or because it would be unsafe to let it inject
   routes in RPL. Using 6LoWPAN ND as opposed to RPL as the Host-to-Router
   interface limits the surface of the possible attacks by the RUL against the
   RPL domain, and can protect RUL for its address ownership.
"

Many thanks again Peter.

The main thing I did not act upon is the change 6LN->RUL. The conscious behavior by the node is that of a 6LN, not that of a RUL; we found it logical to present the RUL as a 6LN in the sections where it uses 6LoWPAN ND. Thus the text as it stands.

Again, many thanks for your review!

Please let me know if we are good, and keep safe;

Pascal

---

From: Peter van der Stok <[email-masked]>
Date: Thu, 10 Dec 2020 09:02:54 +0100

HI Pascal,

My hope is that my comments, in spite of the mistakes, did not add to
the confusion.
The layout that you received certainly did not help.
It was a real struggle to go from word format to txt that comformed to
the iotdir review format. (4 tries);
But what I saw as final result was different again from what you
show.....

The text of the draft is certainly simplified at several places.

I regret that that the term RUL/6LN is still needed. I found that very
confusing; and that triggred my suggestions.
The point being that it was unclear when 6LN spec was repeated and when
new RUL behavior was specified.
Apparently, it is too convoluted to define the RUL such that 6LN is only
mentioned in section 2.
But the 6LN RUL separation is clearer in the new text.

cheerio,
all the best,

Peter

Pascal Thubert (pthubert) schreef op 2020-12-09 19:42:

>> Alinea: 'examples …..and/or metering': s/lightly powered/ severely energy
>> constrained/
> 
> Done
> 
>> 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
>> 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
>> Page 8 s/ inner packet/encapsulated packet/ Remove '[USEofRPLinfo] expects
>> ….to a Host.' (Unnecessary phrase, RUL is 6LN)
> 
> Suppress 'Unless it is aware ….by 
> 
>> [RFC8504]'; (How will the root be aware? Not this year anyway.)
> 
> Remove 'outside the RPL domain 
> 
>> eg.' 2nd al. s/on behalf …. functionality in/for any RUL. Section 7 s/RAN/6LR/
>> s/'6LN/RUL'/RUL; (having defined that a RUL is a 6LN) Page 21, Section 9.2.1
>> 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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 10 Dec 2020 08:26:36 +0000

It is indeed Peter;

Note that the goal is to specify the new operation by the RPL router.

As a side effect we need to precise which subset of WiND the 6LN needs to implement to get the router to inject the routes as expected. But that’s still operating within RFC 8505 ans 8928.

Also note that the tool is not the only way. I often send my comments directly and feed the tool retrospectively.

Take care,

Pascal

Le 10 déc. 2020 à 09:03, Peter van der Stok <[email-masked]> a écrit :

 HI Pascal,

My hope is that my comments, in spite of the mistakes, did not add to the confusion.
The layout that you received certainly did not help.
It was a real struggle to go from word format to txt that comformed to the iotdir review format. (4 tries);
But what I saw as final result was different again from what you show.....

I regret that that the term RUL/6LN is still needed. I found that very confusing; and that triggred my suggestions.
The point being that it was unclear when 6LN spec was repeated and when new RUL behavior was specified.
Apparently, it is too convoluted to define the RUL such that 6LN is only mentioned in section 2.
But the 6LN RUL separation is clearer in the new text.

cheerio,
all the best,

Peter

Dear Peter

Let's see below.

peter van der stok
__________________________________________________________________
____________
Another introduction of terms is suggested for page 4  like:
Replace the first three Alineas of page 4 with:

...

Done

‘A RUL is an

Ne. the full sentence is
"
This section describes

Page 13,

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’

"

Many thanks again Peter.

Pascal