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

Ines Robles <mariainesrobles@googlemail.com> Sun, 10 January 2021 19:19 UTC

Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E39493A11D9; Sun, 10 Jan 2021 11:19:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv_zqUImUfS2; Sun, 10 Jan 2021 11:19:11 -0800 (PST)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9FC43A11D8; Sun, 10 Jan 2021 11:19:10 -0800 (PST)
Received: by mail-vs1-xe34.google.com with SMTP id j140so8579998vsd.4; Sun, 10 Jan 2021 11:19:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yOFmEDn819xYDLgTEUVH6HkTwFTYBqK+dFXlmWRAv2I=; b=dyl+3+qIz2Q1PaFLroIRD+8yEMBAnBh8j1VRZGq7Tw0IcHPGBMWAvjI2LH+pyxFL11 QviHSPDSitR7mn6R39pV5WFvHDu280Pgf4/XxiHL9nuY2uIgEbW8MulOAirifDT+30Ib b9XsOIHYYab+iQU4npmjrzDbv+HbPWQbhWmw4zfjeoVNSf/Ec+S7EcHxIowN9/tSe+XL HCVGcOTKCKSk2uM3CxawE1BHQCEj4uvLHfhFHSHmbnQv0VLdVKGiO7lzRIItO7NXgam1 fQljHAkzZcUyhbjc9IGnsICIAKLwS2SWvXhmEugVcAsALisEAoavz12A21kUQsiwnFj7 ExRg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yOFmEDn819xYDLgTEUVH6HkTwFTYBqK+dFXlmWRAv2I=; b=H7Sj9zoevzSr/MUKmjQaocBaM/7INcw7GD4pRwctFZsbSXvuPwF9ydkE5gsDHico50 hURSRyfH3m7MpagVTj5fGRi0AcxjkuMjLWsWPvsIZLSPmic0NTqrH3SLAqeGGHyGzKvx lJFGzhiUFkTD2RuDja6sVA6RZq4Ehy/RgT7GXXchqOycTcS4JpjBPBKCaU8Mhy32cXui BsK7rfFJ2p1GvwoAiO5Y2K6AfPgKUFvNOe8FU1sL1xGgGqv7bbqBM3dJBGzCX7EycyiW DGWCkJO9w2Crm13H/PMmcvJ1ZkDWaihXCneA7gfFRbWYIVpK89A57yNrM/itKsvhbXEJ lubw==
X-Gm-Message-State: AOAM530sk8/nZh4NowDeD1O+Tu1gOQmocF5/WkrvNi5b0Mt6cOkmTkTM xO1N497/P3iPbc9GwQVsIVvtZ3xdgX4VYNWs+47u7YrPl3IEkA==
X-Google-Smtp-Source: ABdhPJxdyKBjboa3vzk8GFZvPOsDEwf8X7kXkTWegk9BYJxWJshch231N8Rayixeka9ItRSoTa/RksvzLkTCk4ye/f4=
X-Received: by 2002:a67:3189:: with SMTP id x131mr11031042vsx.13.1610306349535; Sun, 10 Jan 2021 11:19:09 -0800 (PST)
MIME-Version: 1.0
References: <160817820238.8811.1808720747296891005@ietfa.amsl.com>
In-Reply-To: <160817820238.8811.1808720747296891005@ietfa.amsl.com>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Sun, 10 Jan 2021 21:18:33 +0200
Message-ID: <CAP+sJUdGJ7maetOjcFdoh=3jKooZbt=bY798YvQX++MhJDzTtA@mail.gmail.com>
To: Barry Leiba <barryleiba@computer.org>
Cc: The IESG <iesg@ietf.org>, draft-ietf-roll-useofrplinfo@ietf.org, roll-chairs <roll-chairs@ietf.org>, roll <roll@ietf.org>, Peter Van der Stok <consultancy@vanderstok.org>, Alvaro Retana <aretana.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000f195ed05b890a9a6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/VPv2ZaBNZiOF80jJDz47XjUvT4Q>
Subject: Re: [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
Precedence: list
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: Sun, 10 Jan 2021 19:19:14 -0000

Dear Barry,

Thank you very much for your comments and suggestions, we believe that
version 43 (diff) addresses your concern, please find comments inline:

Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-43

On Thu, Dec 17, 2020 at 6:10 AM Barry Leiba via Datatracker <
noreply@ietf.org> wrote:

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> — 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.
>

<authors> Thank you for the clarification, the new description of flag day
is as follows:

Flag Day: It is a mechanism for resolving an interoperability
 situation (e.g. lack of interoperation between new RPI Option Type
(0x23) and old RPI Option Type (0x63) nodes) by making an abrupt,
disruptive changeover from one to the other.

</authors>


> — 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?
>

 <authors > it means that have been used plenty, we have deleted
“abusively”</authors >

>
> — 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.
>

 <authors > The new sentence is as follows:

The 0x23 RPI Option allows to send packets to not-RPL nodes. The not-RPL
nodes should ignore the option and continue processing the packets.

</authors >

>
>    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)”.
>

<authors > changed to - abrupt changeover-

....indicating the new RPI in the DODAG Configuration option flag is a way
to avoid the flag day (abrupt changeover) in a network using 0x63 as the
RPI Option Type value...

.</authors >

Thank you again,

Ines, Pascal and Michael.