[Roll] Barry Leiba's No Objection on draft-ietf-roll-useofrplinfo-42: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Thu, 17 December 2020 04:10 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 CB4893A1402; Wed, 16 Dec 2020 20:10:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba 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: Barry Leiba <barryleiba@computer.org>
Message-ID: <160817820238.8811.1808720747296891005@ietfa.amsl.com>
Date: Wed, 16 Dec 2020 20:10:02 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/J4tmBDiHYgWCS9iNg3XtjBnbhj4>
Subject: [Roll] Barry Leiba's No Objection on draft-ietf-roll-useofrplinfo-42: (with 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: Thu, 17 Dec 2020 04:10:03 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-roll-useofrplinfo-42: No Objection

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/



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

I would have liked to spend more time on this than I had, but I do have some
non-blocking comments that I’d like you to consider:

— Section 2 —

   Flag Day: In this document, refers to a transition that involves
   having a network with different values of RPI Option Type.

I don’t understand.  First, I don’t find the text here clear at all: is it
trying to say that two different values are coexisting (present at the same
time) in one network?  Second, that seems to be exactly the opposite of what we
usually use a flag day for.  The normal meaning of “flag day” is a preset time
when a changeover is made, exactly *because* the old and the new can’t coexist
interoperably.  A “flag day” isn’t a situation caused by two non-interoperable
things... it’s a mechanism for resolving such a situation by making an abrupt,
planned changeover from one to the other.

— Section 4.2 —

   Thus, this document updates the Option Type of the RPL Option
   [RFC6553], abusively naming it RPI Option Type for simplicity,

What is the point of “abusively” here?  What’s it supposed to mean?

— Section 10 —

   This options allows to send
   packets to not-RPL nodes, which should ignore the option and continue
   processing the packets.

I can’t sort this sentence out:
1. “This options” is mixing singular and plural.
2. No option or options has/have been mentioned before, so I don’t know what
option(s) it’s talking about. 3. I guess you mean “non-RPL”, rather than
“not-RPL“. 4. Allows *who* to send packets?  “Allows to” needs a subject, like
“allows a node to send”, or some such. 5. What is the antecedent to “which”? 
It’s not clear to me.

   As mentioned previously, indicating the new RPI in the DODAG
   Configuration option flag is a way to avoid the flag day (lack of
   interoperation) in a network using 0x63 as the RPI Option Type value.

I’ll just note that this is a correct use of “flag day”, but with an odd
explanation in the parentheses.  I would say “(abrupt, disruptive changeover)”.