Re: [Roll] Reclaiming the bits

Ines Robles <mariainesrobles@googlemail.com> Fri, 13 December 2019 16:18 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 EAEB012010C for <roll@ietfa.amsl.com>; Fri, 13 Dec 2019 08:18:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 sSYSCw1trxl9 for <roll@ietfa.amsl.com>; Fri, 13 Dec 2019 08:18:09 -0800 (PST)
Received: from mail-il1-x143.google.com (mail-il1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (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 B510B12009E for <roll@ietf.org>; Fri, 13 Dec 2019 08:18:09 -0800 (PST)
Received: by mail-il1-x143.google.com with SMTP id r81so2545466ilk.0 for <roll@ietf.org>; Fri, 13 Dec 2019 08:18:09 -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=JHoirVNKumSBz02T1gob2wcCLrhAuduKEF2cdhD28/k=; b=doZaVbSiQ+kAL2BBFJ7D0VTF0r0lKiZiww5+BPisyvAEbIulRzF/IO5lqdi3kEbfah LO12rUmsK7yPq3t58gDy9/vq8yxGjPqAeR4LXrZEligTRWzF0hwPSFtOTZGNqUjkwb7g MZIo8lMhsuJxkiZc2LtMcd4XngyWyMHRk6NdXIR8f4N5DD7jIk0mS7JHq3lPIPGV/xAN bNEBIJwIWDqP4QiA6MgABOADYEr1qURrM1dBGmdw/+2P7vpeqfL61WwCDrFHUrFhe+sT uAXm9lkgzbnl8SyLfAu7/H0SvNJKlwBV7FiwcDXlt6LHq55Jpa2SoGA1lqmWIy4gf1Iq /p/g==
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=JHoirVNKumSBz02T1gob2wcCLrhAuduKEF2cdhD28/k=; b=n5WS/qK7eUCp81cf2UD4UojyvdesrQ7dYOuVSDRWpCIrCVadrkl5blikX/bGjQ6cF8 kqZNueh5ELlsWA4l/3T/Bzt+nWiE9vpyi/OTR4sbVE+xpNg6lJ5ykXqjG++WaMAjGtmY kQx3VJDRmp0I3Z6xocM3KzVLhCZ6Ms7aCoP/GxKh2y1kmqGxxSUD3CQ3FGusrbg+qsu+ gKJRB/6bH72airPlI/T8eeJaagcYKX/ReDkggbaEE5gjAS2/kv2Dj9Mzfr7d/eWNZ551 PjorQTgD3CpPEvboVc74KlIqEnoQt1DQdxS+E2Ccj0CUKAKYFNaM1U55XZEqVtM0A555 acjg==
X-Gm-Message-State: APjAAAXkacWP0lb1hD51LGM+cBQ9i6HMHCK/kCpcVKdMl8JVbuXBPEbo MnTOIOBS+7Gmk3EwJNeZ1uIk62jVg6J1to3GhjA=
X-Google-Smtp-Source: APXvYqwB4hknQmDcs20HPEvGG0CqkmGqHBpMv4I8YlkTXx4dzkqbVd7tkx5mzb2bboiyK6TibommqPIJKfXPYlC5MGw=
X-Received: by 2002:a92:d7c6:: with SMTP id g6mr94149ilq.282.1576253888948; Fri, 13 Dec 2019 08:18:08 -0800 (PST)
MIME-Version: 1.0
References: <MN2PR11MB3565E131BDE051D0AD920F84D85A0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAO0Djp1UW+hmvN0FE7c+GW2jqdwrGVJ-1JPXE4WBQH=MgVUXVA@mail.gmail.com> <MN2PR11MB356568F70A59FA4035539314D8550@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB356568F70A59FA4035539314D8550@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Fri, 13 Dec 2019 13:17:32 -0300
Message-ID: <CAP+sJUcrREGDQD06ZuyY4hAOE0SQeYx+bVK7AqO3a-VqpagGZQ@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: "Michael Richardson (mcr@sandelman.ca)" <mcr@sandelman.ca>, Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002072530599983551"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Nk7nvI-LqIR_bpy3JD51i6PZfaE>
Subject: Re: [Roll] Reclaiming the bits
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: Fri, 13 Dec 2019 16:18:12 -0000

Thank you very much Pascal for add the clarification. Version 33 was just
posted with that.

Diff:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-33.txt

Please comments,

Thank you,

Ines.



On Thu, Dec 12, 2019 at 9:05 AM Pascal Thubert (pthubert) <
pthubert@cisco.com>; wrote:

> For Use of RPL info I propose the following addition
>
> "
>
> Section 6.3.1. of <xref target="RFC6550"/> defines a 3-bit Mode of
> Operation (MOP) in the DIO Base Object. The flag is defined only
> for MOP value between 0 to 6. For a MOP value of 7 or above, the flag
> MAY indicate something different and MUST NOT be interpreted as
> "RPI 0x23 enable" unless the specification of the MOP
> indicates to do so.
>
> "
>
> I created a pull request to the authors. The pull request also proposes
> some clean up since the original text really abuses terms like "RPI value".
> The RPI is an abstract data defined in RFC 6550. RFC 6553 defines a RPL
> Option. 0x63 is the value of the Option Type field of the RPL Option. I
> changed the draft to use "RPI" in abusive replacement of "RPL Option" so we
> can use " RPI Option Type" but kept the abuse at that.
>
> https://github.com/roll-wg/useofrplinfo/pull/6
>
> Ines: You author section does not compile well, if you could look at it as
> well?
>
> All the best
>
> Pascal
>
>
> From: Roll <roll-bounces@ietf.org>; On Behalf Of Rahul Jadhav
> Sent: jeudi 12 décembre 2019 02:13
> To: Routing Over Low power and Lossy networks <roll@ietf.org>;
> Subject: Re: [Roll] Reclaiming the bits
>
>
> The proposal on the table was:
> - change turnon-rfc8138 to say that the configuration bit only applies to
> MOP < 7 (RPL v1)
> - use-of-rpl-info is edited to say the same thing
> - we create a IANA registry with a MOP column so the bits depend on the
> MOP. MOPext could be the place for introducing this registry.
>
> I’d like to check if the ML is in line with this approach.
>
> [RJ] I am inline with these points.
> I would like to confirm a point here... Reclaiming the turnon-8138 flag in
> MOP>=7 would mean that 8138 is _mandatorily_ supported in the nodes above
> MOP>=7 such that they no more depend on this flag. This in itself is a
> bigger decision! Is my understanding correct? While the advantages of 8138
> are obvious in non-storing MOP case, they are less impacting/obvious in
> storing MOP case.
>
>