Re: [Iot-directorate] Iotdir last call review of draft-ietf-roll-unaware-leaves-23

[Peter van der Stok <[e-mail]>]

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:

> 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.
> 
>> 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
> 
> 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.
> 
>> Alinea: 'examples …..and/or metering': s/lightly powered/ severely energy
>> 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
>> 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)
> 
> 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
> " 
> 
>> 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/
> 
> 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.
> 
>> 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'
> 
> 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.
> 
>> 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/
> 
> 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