Re: [Roll] AD Review of draft-ietf-roll-turnon-rfc8138-07

Alvaro Retana <aretana.ietf@gmail.com> Tue, 21 July 2020 15:03 UTC

Return-Path: <aretana.ietf@gmail.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 EB91E3A0B1A; Tue, 21 Jul 2020 08:03:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3YZJ2N-_zaX0; Tue, 21 Jul 2020 08:03:42 -0700 (PDT)
Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 6F7423A0B19; Tue, 21 Jul 2020 08:03:42 -0700 (PDT)
Received: by mail-wr1-x430.google.com with SMTP id s10so21479223wrw.12; Tue, 21 Jul 2020 08:03:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=Et/KQVFkRqn7QYEFp+thimW+ipX3ydVn9+RNT7nLW2w=; b=C03e30KRY9pNsYMC6KuZPyUvIoXuR/0oq71RKlMgUOPW3nboly6aYxQaRs15KfWSn7 aFWSGxVSTO/P9aZLh3/kGLOg2s/tTEt0kl52BDRIor/DJrXL0Dn6LBHAKVHokVRBrnJ7 fWBqOwYyseqk5Pua4ePmwqy4Kgh861tEgYYHv8+d5HrCw2RsfJNSmxnkEfE2nXsbyyKT MJHmeij2viJ+PFcMXE3EkoxKT/Be0ab3wH3vV6nRym4lQuPsBsaGkz9Oh8AWWqK6MbWC El2XNUfb8NwQVbwavQdnZHzr+kOOQuux6+gZJIzIzlJPZYBoc2KoJnYQacyxSNHqvTFW GhTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=Et/KQVFkRqn7QYEFp+thimW+ipX3ydVn9+RNT7nLW2w=; b=ryERxaRQ4hPzXPL7eN18kyoWiD3xx7L5DAWUChQLIZCc6UZtyVKsebhkkyiLFFhkA9 2zrDnAnvcPw7k1/lWwerCLemDTOPYO5BItvzQnxjAc5sG4EN/vdj0Z4T0uutq5Bo6Wvk IC/zR7athIHpCN1uP7REDkkN1anIbpHkxKnDEYSeqPSEuCAzF2aSithJboVS6WVDclb2 hmZhOO2ACeohNWwocK4gcItaEu0V4JghufawWctHwrJJYMbxHpCoCo4Z5XrbiyQJuQ2N Tu8DFx2K2R33RUue1NQC5dVgZRr309bO3R59exAJOW6yOzGLqMbTwgZwEdo/j3PsBO2w 1bOQ==
X-Gm-Message-State: AOAM530m7m0WYo5oLAnVaM9jVEdzA7bH3orhpHTlPkQUMQTx5TasDk7b pd/9fkfC5WvgdFzL/+s13GA8hMzXUpwnRLeZkYG5Zs45
X-Google-Smtp-Source: ABdhPJyJ062LB+HDFqGIXIhFCSmK48G9OkTp5wTS0NW4Sh+YBX3wxNWqhn0v45OzvrWdMr42mhqO0KLpp54Khp0e4Ko=
X-Received: by 2002:adf:b30c:: with SMTP id j12mr10126858wrd.420.1595343820788; Tue, 21 Jul 2020 08:03:40 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 21 Jul 2020 11:03:40 -0400
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <MN2PR11MB356583CFA0780AC72BFF778DD8780@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <CAMMESsxN+9G7xCR8RVeVE3krv2mRnwF9EVTTG=m=wQyY3QDZVA@mail.gmail.com> <MN2PR11MB35656EE2B4AD84357E81A58DD8640@MN2PR11MB3565.namprd11.prod.outlook.com> <CAMMESsxCCnGxaAAcvgwv_DnZufWP-nYrO_roUB5=GZ6wEDCp7Q@mail.gmail.com> <MN2PR11MB356583CFA0780AC72BFF778DD8780@MN2PR11MB3565.namprd11.prod.outlook.com>
MIME-Version: 1.0
Date: Tue, 21 Jul 2020 11:03:39 -0400
Message-ID: <CAMMESswn-4Y1eauib--ZXtF4T-CjM2SFMmH9sCybG9fQHsuf+Q@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "draft-ietf-roll-turnon-rfc8138@ietf.org" <draft-ietf-roll-turnon-rfc8138@ietf.org>
Cc: "roll-chairs@ietf.org" <roll-chairs@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/lBKtm1di6pQxTPR_YXOeNxaob3I>
Subject: Re: [Roll] AD Review of draft-ietf-roll-turnon-rfc8138-07
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: Tue, 21 Jul 2020 15:03:44 -0000

On July 21, 2020 at 5:53:53 AM, Pascal Thubert wrote:


Pascal:

Hi!


...
> Agreed for the registry part.
> All we want is to say that the code should check for MOP<7 before it uses
> the flag.
> To prepare for this the current draft onlyt changes the name of the
> registry as below.

Changing the name of the registry will result in having to Update the
other documents that have option flags because they don't include a
limitation.  It would also probably require an additional registry for
MOP >= 7...just for completeness.  By the time we're done with that
justification we're already half way to RLPv2 -- in this document!

Let's leave the registry unchanged.


> "
> 6. IANA Considerations
>
> IANA is requested to assign a new option flag from the Registry for
> the "DODAG Configuration Option Flags" that was created for [RFC6550]
> as follows:
>
> +---------------+---------------------------------+-----------+
> | Bit Number | Capability Description | Reference |
> +---------------+---------------------------------+-----------+
> | 2 (suggested) | Turn on RFC8138 Compression (T) | THIS RFC |
> +---------------+---------------------------------+-----------+
>
> Table 1: New DODAG Configuration Option Flag
>
> The DODAG Configuration Option Flags defined so far will be obsolete
> for RPL Mode of Operation (MOP) above and including 7.
>
> IANA is requested to update the name of the Registry from "DODAG
> Configuration Option Flags" to "DODAG Configuration Option Flags for
> RPL MOP 0..6".
>
> When MOP values of 7 and more are defined, a new registry will be
> needed.
> "
>
> Should I remove the text after the table or is it OK?

Yes, please.



> > This should simplify more. Thoughts?
> >
> >
>
> Please keep in mind that we want the core written today to disregard the
> flag (I guess that means use a default that is TBD) for MOP >= 7. Said this
> way, we still need text, and we need to define the default. I suspect it
> should be "ON" but I need to check with the ML.

This default won't be in this document, right?



...
> > The Abstract still says that the document Updates rfc6550:
> >
> > Suggestion>
> > This document updates RFC 8138 by defining a bit in the RPL DODAG
> > Configuration Option to indicate whether compression is used within the
> > RPL Instance, and specify the behavior of when the bit is set and reset.
> >
> >
>
> Did you mean
> "
> This document updates RFC 8138 by defining a bit in the RPL DODAG
> Configuration Option to indicate whether compression is used within the
> RPL Instance, and specify the behavior of RFC 8138-capable nodes
> when the bit is set and reset.
>
> "
>
> ?

Sure.


Thanks!

Alvaro.