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

Benjamin Kaduk <kaduk@mit.edu> Fri, 11 September 2020 16:26 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 A818B3A1477; Fri, 11 Sep 2020 09:26:37 -0700 (PDT)
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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 B7UUGa7U2wPq; Fri, 11 Sep 2020 09:26:36 -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 807D93A1408; Fri, 11 Sep 2020 09:26:24 -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 08BGQHuQ023399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Sep 2020 12:26:19 -0400
Date: Fri, 11 Sep 2020 09:26:17 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, Alvaro Retana <aretana.ietf@yahoo.com>, Ines Robles <mariainesrobles@googlemail.com>, "draft-ietf-roll-turnon-rfc8138@ietf.org" <draft-ietf-roll-turnon-rfc8138@ietf.org>, The IESG <iesg@ietf.org>
Message-ID: <20200911162617.GQ89563@kduck.mit.edu>
References: <159968972884.1065.3876077471852624744@ietfa.amsl.com> <MN2PR11MB35659A0710E687A7C9995E6ED8270@MN2PR11MB3565.namprd11.prod.outlook.com> <20200910200744.GE89563@kduck.mit.edu> <17053.1599841430@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <17053.1599841430@localhost>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/_kuhIbthF0Yx4gl0CLBUhaJ9Y3U>
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: Fri, 11 Sep 2020 16:26:46 -0000

On Fri, Sep 11, 2020 at 12:23:50PM -0400, Michael Richardson wrote:
> 
> Benjamin Kaduk <kaduk@mit.edu> wrote:
>     > to MOPs 0..6; but the situation for MOP 7 seems slightly different.  If we
>     > were *just* leaving the bit undefined/free for reuse in that situation,
>     > that is probably also something that we can do in a normal "allocate a bit
>     > from an IANA registry" document without need for Updates.
> 
> Up to here, we agree.
> 
>     > But that's not
>     > all we're doing; we're also saying that if you see MOP==7, then you have to
>     > use the 8138 header/compression/whatever-we-end-up-calling-it.  Yet we are
>     > *not* allocating MOP==7.
> 
> Tthat's exactly what we don't want to do.
> 
> We are saying NOTHING about rfc8138 when MOP==7.
> Nor are we saying that the T-bit exists (or doesn't exist).

That's not how I read:

       For a MOP value of 7, the compression MUST be used by default
   regardless of the setting of the "T" flag.


> What behaviour is default and what behaviour is negotiated, and how it it
> negotiated, and how the results are turned on, would be up to a document that
> specifies MOP=7 (or larger mopex)

What you describe here is more along the lines of what I expected.

-Ben

> As an analogy, when we did the ToS->DSCP + bits-that-became-ECN
> change, we did this for IP_version==4 and IP_version==6.
> We specifically did not change it for IP_version==7 or 8.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>