Re: [Roll] Reclaiming the bits

Ines Robles <mariainesrobles@googlemail.com> Fri, 13 December 2019 16:18 UTC

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
Precedence: list

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

[Roll] Reclaiming the bits Pascal Thubert (pthubert)
Re: [Roll] Reclaiming the bits Rahul Jadhav
Re: [Roll] Reclaiming the bits Pascal Thubert (pthubert)
Re: [Roll] Reclaiming the bits Pascal Thubert (pthubert)
Re: [Roll] Reclaiming the bits Pascal Thubert (pthubert)
Re: [Roll] Reclaiming the bits Michael Richardson
Re: [Roll] Reclaiming the bits Ines Robles