[Roll] RPLinfo review

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

Dear authors,

Thanks for your document. In my opinion the document is very useful. 
Although many things are well explained, I am still left with questions 
and possible ambiguities in my understanding. Consequently, my review 
goes up to section 5.8. Continuing the review becomes more effective 
when my current questions are answered.
Line numbers are with respect to page or to section header; hope this is 
clear.
Below my review:
____________________________________________________________________________
Page 3, section1, line1: the first use of RPL please write in full.
Section 2: please provide the reader with a list of terms from RFC7102 
that is used in the document.
Page 4: ICMPv6 may need a reference?
DIS, DIO, and DAO are not provided by RFC7102. Please write in full or 
provide reference in section 2.
Page 5 I like figure 2, and use it as a reference throughout the 
document.
Page 5, line 2: I assume that 6LN is not RPI aware.
Page 5: The phrase:  “Advertisement, 6lowPAN  … network” may need 
reference to RFC.
Page 5 2nd al. write 6tisch in full?
Page 5, 3rd al; write LLN in full (first occurrence)
Page 6, Figure 3 and architecture text is informative, but please 
clarify how the use cases of section 4 map to figure 3. For example 
where does Internet start/end: at border router or at backbone router?
And how does flow from one mesh over the backbone to the next mesh map 
to the use cases.
I also did not see a mapping of flow from one RPL instance to another 
instance.
Page 8, line 3: route -> root.
Page 8, line 8: RPL-SN and RPL-NSN should that not be RPL-SM and 
RPL-NSM, otherwise explain the meaning of the N.
Page 8, Please align terminology of table 1 with terminology of Figure 2
I would suggest to move table 1 and its concluding text to a last 
summary section of section 5. At the beginning of section 5, the import 
of the text is far from clear.
I would recommend to write down at the beginning of section 5 the 
characteristics of storing mode for this document; e.g. root and 6lr do 
not know if a destination is part of RPL DODAG; and thus needs IP over 
IP header in all cases.
Page 9 , section 5.1 line 1: states -> stated
Page 9, line 7: is suitable -> is compulsory; or use SHOULD in different 
kind of phrase
“in storing mode …….information”. suggestion to move section to start of 
section 5
Page9, Line 10: RPL-aware-leaf (6LN) in figure 2 it is called 6LR, I 
recommend to use 6LR throughout. According to figure 2, 6LN stands for 
something else. This is relevant for whole section 5.
“Note:….root node”. Remove this phrase is already done in section 3.
Page9 line13: send -> sends
Line14: decrement -> decrements; send -> sends
Line 15 arrives to 6LBR -> arrives at 6LBR
Line 20: “The RPI header …DIO messages” -> The 6LR recognizes the 
address of the 6LBR (root?) from earlier received DIO messages, and can 
thus insert RPI directly in the header. The 6LBR receives the packet and 
accepts the payload.
NB: In the whole document root and 6LBR is freely exchanged. May be good 
to say something about this in section 3.
Section 5.2
Everywhere: 6LN -> 6LR
Page10, line 1: insert -> inserts; send -> sends
This is weird. According to the intro, 6LBR does not know if destination 
is a 6LR or a 6LN. In my opinion treatment, described in 5.2 and 5.3, by 
6LBR and 6LR should be identical.
Section 5.3
Put the alinea “ The question…. To leaf” up front of section 5.3.
Section 5.3, Line 3: It includes -> The root (6LBR) uses
Section 5.3 line 6: “the header ….node” -> the header before it passes 
the packet to 6LN.
IPv6 is a new term not introduced earlier.
Section 5.4
I assume IPv6 node is 6LN.
How can the RPI header be encapsulated in the IP-IP header. I thought 
the encapsulating IPIP header contains RPI.
Section 5.4, line 6: process -> processes.
Section 5.5 6LN -> 6LR in whole section
It would help the reader to explain that 6LR knows the destination is 
Internet because the prefixes differ.
Why should it be done hop by hop? Interoperability requires that it is 
done in one way. So one IPIP encapsulation with RPI, with encapsulation 
removed by 6LBR.
Section 5.6
6LN ->6LR for whole section
Section 5.6, line 4: send -> sent
Section 5.6, line 5: When the packet arrives at 6LR, the …
Why is this not done in a hop by hop fashion as in section 5.2 modelled 
on section 5.3, because also here the root does not know whether the 
destination is 6LR or 6LN node.
Page 13, line 1 Why two fashions: direct root, and hop by hop to root.
Section 5.8
Can refer to section 5.3 directly, and remove text.
-----------------------------------------------------------------------------------------------------------------------------------------
I stop here because I made too many assumptions about the text, and the 
validity of the rest of the review becomes more and more questionable.
I hope this helps; and my misinterpretations may lead to better text.
Greetings,
peter