Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 10 September 2020 21:09 UTC

Return-Path: <kaduk@mit.edu>
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 90FCC3A0839; Thu, 10 Sep 2020 14:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 vlLC-VCy27Sf; Thu, 10 Sep 2020 14:09:08 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6A53A0906; Thu, 10 Sep 2020 14:09:07 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 08AL8va6030553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 10 Sep 2020 17:08:59 -0400
Date: Thu, 10 Sep 2020 14:08:57 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Alvaro Retana <aretana.ietf@gmail.com>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Alvaro Retana <aretana.ietf@yahoo.com>, The IESG <iesg@ietf.org>, "roll@ietf.org" <roll@ietf.org>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, "draft-ietf-roll-turnon-rfc8138@ietf.org" <draft-ietf-roll-turnon-rfc8138@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>
Message-ID: <20200910210857.GI89563@kduck.mit.edu>
References: <159968972884.1065.3876077471852624744@ietfa.amsl.com> <MN2PR11MB35659A0710E687A7C9995E6ED8270@MN2PR11MB3565.namprd11.prod.outlook.com> <20200910200744.GE89563@kduck.mit.edu> <CAMMESsx_Tgbn6VUHmbmzbLeVOxa5Uiw44GyRQK0m+_8NgQBT-Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAMMESsx_Tgbn6VUHmbmzbLeVOxa5Uiw44GyRQK0m+_8NgQBT-Q@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/PgABeFC5pFG34CYkU_YJ3tUUGMw>
Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and 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: Thu, 10 Sep 2020 21:09:21 -0000

On Thu, Sep 10, 2020 at 04:58:33PM -0400, Alvaro Retana wrote:
> Hi!
> 
> Jumping in here on the Updates/MOP 7 point.
> 
> 
> The only reason we’re trying to treat MOP 7 differently is because we (the
> WG) know that the mopex draft is coming…which is the future document that
> will define what 7 really means.
> 
> However, we’re still not there…and the mopex draft should be the one
> defining all the changes.
> 
> I think the easiest thing to do at this point is to ignore mopex, and the
> knowledge that things will change in the future…because we still don’t know
> exactly what that future will be…this extension should then simply be
> defined as other extensions have been: applicable to all MOPs.  When mopex
> comes we can deal with the respective Updates, changes to the registries,
> etc.

That seems like it's setting us up for exactly the situation that
Pascal/Michael want to avoid -- if we allocate the T flag "normally" then
an implementation written next month will treat the bit in position 2 as
the T flag, independnetly of the MOP value.  When MOP==7 finally comes
along then the bit is burned and can't be repurposed, so long as that
implementation is still deployed, and that can't be fixed by Updates or
registry changes.

Is it so bad to say that the bit allocation is only defined for a subset of
MOPs?

-Ben