IETF Logo Mail Archive

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

Benjamin Kaduk <kaduk@mit.edu> Sat, 12 September 2020 01:22 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 3558F3A09A2; Fri, 11 Sep 2020 18:22:07 -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 WrbbiL8ddnNM; Fri, 11 Sep 2020 18:22:05 -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 51FC53A0998; Fri, 11 Sep 2020 18:22:05 -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 08C1LsRx009671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 11 Sep 2020 21:21:57 -0400
Date: Fri, 11 Sep 2020 18:21:54 -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>, Martin Duke <martin.h.duke@gmail.com>, "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: <20200912012154.GW89563@kduck.mit.edu>
References: <159968972884.1065.3876077471852624744@ietfa.amsl.com> <MN2PR11MB35659A0710E687A7C9995E6ED8270@MN2PR11MB3565.namprd11.prod.outlook.com> <20200910200744.GE89563@kduck.mit.edu> <17053.1599841430@localhost> <20200911162617.GQ89563@kduck.mit.edu> <4724.1599853045@localhost> <CAM4esxSp9n-MKWamQDN+3MHcN8TNJUinJB_Kjc55OY+=6engaQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAM4esxSp9n-MKWamQDN+3MHcN8TNJUinJB_Kjc55OY+=6engaQ@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/o2bDToRHjRS74BbR64kV66i25iU>
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: Sat, 12 Sep 2020 01:22:07 -0000

On Fri, Sep 11, 2020 at 12:53:08PM -0700, Martin Duke wrote:
> On Fri, Sep 11, 2020 at 12:37 PM Michael Richardson <mcr+ietf@sandelman.ca>
> wrote:
> 
> >
> > Benjamin Kaduk <kaduk@mit.edu> wrote:
> >     >> 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.
> >
> > While I think that's probably what we'll conclude, this wasn't in for WGLC
> > that I recall.  I think that this also must have gotten in during IESG
> > review.
> >
> > Pascal, can we make this say:
> >     For a MOP value of 7, there is no "T" flag, and the compression
> >     behaviour will be defined by future work.
> >
> >
> I believe this text would be sufficient to lift my DISCUSS, though I don't
> completely understand the interaction between MOP and versioning in this
> protocol.

I believe it would also be sufficient to lift my DISCUSS (given the
discussion we've had already) ... but it is unclear whether it is actually
the right thing to do.  I'm hoping that Michael (or others in the WG, of
course) will chime in on the "what do we want an implementation to do?"
question.

-Ben

v2.23.0 | Report a Bug | By Email