[Roll] useofrplinfo version 5

peter van der Stok <stokcons@xs4all.nl> Wed, 06 July 2016 12:14 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6D7E812D178 for <roll@ietfa.amsl.com>; Wed, 6 Jul 2016 05:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id zNdkChEzKhHI for <roll@ietfa.amsl.com>; Wed, 6 Jul 2016 05:14:26 -0700 (PDT)
Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net []) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A9112D149 for <roll@ietf.org>; Wed, 6 Jul 2016 05:14:25 -0700 (PDT)
Received: from webmail.xs4all.nl ([]) by smtp-cloud2.xs4all.net with ESMTP id FQEP1t00E4h15BW01QEPi4; Wed, 06 Jul 2016 14:14:23 +0200
Received: from AMontpellier-654-1-248-197.w92-133.abo.wanadoo.fr ([]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Wed, 06 Jul 2016 14:14:23 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Wed, 06 Jul 2016 14:14:23 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Roll <roll@ietf.org>
Organization: vanderstok consultancy
Mail-Reply-To: consultancy@vanderstok.org
Message-ID: <b9e569f12a008245ef824e340f510dff@xs4all.nl>
X-Sender: stokcons@xs4all.nl (o4keeXmlQoSGg2t6fydh5z/3qdvI0HZE)
User-Agent: XS4ALL Webmail
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/kxDa7VcF8kZfWeDokrTlZbsOLzs>
Cc: Kovatsch Matthias <kovatsch@inf.ethz.ch>, emarobl <maria.ines.robles@ericsson.com>
Subject: [Roll] useofrplinfo version 5
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: consultancy@vanderstok.org, Routing Over Low power and Lossy networks <roll@ietf.org>
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Jul 2016 12:14:28 -0000

Hi Authors,

Below my review of the document.

Although the subject is tedious, the draft looks important to me to 
assure inter-operability between implementations

This version was much more readable than the first one. So, I mostly 
signal nits and typos.
It is important that someone with more implementation experience also 
carefully reviews the document to signal missing text.

Below my comments,



Review of RPLinfo version 05.
Intro, last line, change to: “… type 3 {RFC6554], an efficient IP-in-IP 
technique, and use cases …”.
Section 3, Figure 1 is not referred to in the text.
Page 5: Reorder phrases: first the phrase “In the figure 2,…” followed 
by the phrase “The numbers …”
Page 5, line 3: leaf -> leafs
Page 5, line 7: “is mentioned as well as” -> “is often named”
Page 6, figure 3 is not referred to.
Page 7, phrase 2, “This is a fundamental” -> “A fundamental”
Page 8, line 8,”to add to remove” -> “to add or remove”
Page 8, line 22, “In tables” -> “In table 1”
Page 8, line 25, complete -> extensive
Section 5, phrase 1 change to: “In storing mode (fully stateful), the 
sender cannot determine whether the destination is RPL-capable and thus 
Section 5, line 9, indicates when (when to be added)
Page 9, last line; don’t understand: “and are the RPL root node.”
Page 10, line 6: remove: “in order to be able to”
Section 5.2, line 3, insert -> inserts; send ->sends
Section 5.3 and section 5.2: If the 6LBR does not know whether 
destination is Raf or not_Raf in section 5.3, then this is also the case 
in section 5.2. Question why is the IPv6-in-IPv6 header not also used in 
section 5.2. The problem for the 6LBR is the same.
The text in section 5.3 seems to suggest that at each 6LR the 
IPv6-in-IPv6 is removed and then re-added again. I would expect the row 
re-added headers be filled in under 6LR.
Other question: how does the last 6LR know that the next node is a 
Section 5.4: IP-in-IP is removed and re-added in 6LRs? This also refers 
to the following sections 5.x
Section 5.8 and section 5.6; same question as for section 5.3 and 
section 5.2.
Section 5.9, line 11, sending 6LN to (“6LN to” added)
Section 5.10, line 4, remove “sends”
Page 16, “Alternatively, …. Compress.” I miss a lot of context to 
understand this paragraph.
Section 5.11, line 5, addresses -> addressed
Section 5.11, line 6, subject of “must send” misses.
Section 5.12, The phrase “The IP-in-IP header must be addressed on a 
hop-by-hop basis” suggests that the header is removed and re-inserted at 
every hop. Nevertheless, that is not mentioned in the accompanying 
table. This is the same question I have for earlier sections 5.x.
Section 6.1, In the table, why does the 6LBR add RPI? 6LBR is the 
Section 6.2, “the traffic originates with an RPL aware node”. What do 
you mean? 6LBR is RPL aware? The destination is known to 6LBR because 
destination is RPL aware? Or something else?
Section 6.3, My interpretation: In 6LBR the RH3 is added and modified in 
each consecutive 6LR until it is fully consumed and removed in the last 
Section 6.3, You cite several alternatives. I suggest to only mention 
the solution without RPI.
Section 6.5, line 3, remoted -> removed
Identical to storing mode case (please mention section).
Section 6.6 same remark about RPI as section 6.3
Sections 6.7 – 6.12, Here you use 6LN for not-RPL aware node, while in 
earlier section 6.x you use IPv6 node. Why?
Section 7.1, line 6, stiaution -> approach
Section 7.1, line 10; what is a “single code path”?
Section 7.2, line 1, This -> In
Section 7.2 line 3, all DODAG nodes, (added DODAG)
Section 7.2, line 12, “intermediate 6LN nodes” should be “intermediate 
IPv6 nodes”? If not, I don’t understand the phrase.
Section 7.2, line 20, there are -> there is

Peter van der Stok
mailto: consultancy@vanderstok.org