[Roll] Erik Kline's Discuss on draft-ietf-roll-useofrplinfo-42: (with DISCUSS and COMMENT)

Erik Kline via Datatracker <noreply@ietf.org> Wed, 16 December 2020 05:46 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: roll@ietf.org
Delivered-To: roll@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDCF3A0FD7; Tue, 15 Dec 2020 21:46:54 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Erik Kline via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-roll-useofrplinfo@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Peter Van der Stok <consultancy@vanderstok.org>, aretana.ietf@gmail.com, consultancy@vanderstok.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.23.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Erik Kline <ek.ietf@gmail.com>
Message-ID: <160809761379.22994.11202105892505044046@ietfa.amsl.com>
Date: Tue, 15 Dec 2020 21:46:54 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/aLJ_WAGcqKnzZCZyhSxflt4s23A>
Subject: [Roll] Erik Kline's Discuss on draft-ietf-roll-useofrplinfo-42: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
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, 16 Dec 2020 05:47:00 -0000

Erik Kline has entered the following ballot position for
draft-ietf-roll-useofrplinfo-42: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[ section 12 ]

* Ignoring an invalid RH3 header by the end host (I'm assuming this
  means that segments left > 0) doesn't specify whether the packet
  should be processed (ignore the RH) or the whole packet should be
  ignored.

  I might recommend instead referring to RFC 6554 S4.2 for how to handle
  RH3's if the node is also a RPL-aware router and say it MUST drop the
  packet if segments left is non-zero and it's not a RPL-aware router.

  Related: I'd also recommend:

  "It should just be noted that an incoming RH3 must be fully consumed, or
   very carefully inspected."

  ->

  "It should just be noted that an incoming RH3 MUST be fully consumed."


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[[ comments ]]

[ section 8.1.3 ]

* I'm confused by the use of "consumed" here.  Is the final RH3 entry
  RUL's address?  I guess you could say RH penultimate hop "consumes"
  the header because the ultimate destination address is put in the
  header DA field.  Seems a bit odd though.

  I assume 6LR_n gets RUL's address from the last segment in RH3.

  "Consumed" means segments left == 0, I guess?  I suppose should have
  picked up on this terminology when it was first used in Section 2.
  Maybe clarify what it means in that section (2)?


[[ questions ]]

[ section 4.1.3 ]

* To be clear, the DODAG Configuration option flags being updated
  is the one in 6550 S6.7.6?

[ section 9 ]

* This the final paragraph strictly true?  It seems that in some situations
  in section 7 full-encapsulated packets can arrived at the RUL with all
  RPL artifacts removed.  Again: in certain situations.


[[ nits ]]

[ section 1.1 ]

* "uses cases" -> "use cases"

[ section 4.1.3 ]

* "when a node joins to a network will know" ->
  "when a node joins to a network it will know", I think

* "MUST be initialize to zero" -> "MUST be initialized to zero"

  (Separately: if this is quoting text from 6.7.6, then it's not
   exactly a direct quote.)

[ section 6 ]

* "while adding significant in the code" ->
  "while adding significant <noun|noun phrase> in the code", I think

[ section 9 ]

* "traffic originating from..." ->
  "Traffic originating from..."

[ section 12 ]

* "if attack" -> "if the attack" or "if an attack"