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

Peter Van der Stok via Datatracker <noreply@ietf.org> Tue, 08 December 2020 15:02 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: iot-directorate@ietf.org
Delivered-To: iot-directorate@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A90E3A0F49; Tue, 8 Dec 2020 07:02:08 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Peter Van der Stok via Datatracker <noreply@ietf.org>
To: <iot-directorate@ietf.org>
Cc: last-call@ietf.org, roll@ietf.org, draft-ietf-roll-unaware-leaves.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <160743972812.4353.2327485830954240210@ietfa.amsl.com>
Reply-To: Peter Van der Stok <consultancy@vanderstok.org>
Date: Tue, 08 Dec 2020 07:02:08 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/iot-directorate/moZGP1XcGrE46vXXT0qT5gnXD9A>
Subject: [Iot-directorate] Iotdir last call review of draft-ietf-roll-unaware-leaves-23
X-BeenThere: iot-directorate@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Mailing list for the IoT Directorate Members <iot-directorate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/iot-directorate/>
List-Post: <mailto:iot-directorate@ietf.org>
List-Help: <mailto:iot-directorate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iot-directorate>, <mailto:iot-directorate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Dec 2020 15:02:08 -0000

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/