Re: [Stackevo] draft-thomson-use-it-or-lose-it

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Thu, 02 August 2018 14:42 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
X-Original-To: stackevo@ietfa.amsl.com
Delivered-To: stackevo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0D9D128B14 for <stackevo@ietfa.amsl.com>; Thu, 2 Aug 2018 07:42:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 NO4dQlPd5DBx for <stackevo@ietfa.amsl.com>; Thu, 2 Aug 2018 07:42:47 -0700 (PDT)
Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42064128CE4 for <stackevo@iab.org>; Thu, 2 Aug 2018 07:42:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 41hCZY3ZHYzMlTk; Thu, 2 Aug 2018 16:42:45 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch
Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jthviQfKhRxf; Thu, 2 Aug 2018 16:42:44 +0200 (CEST)
X-MtScore: NO score=0
Received: from [192.168.178.24] (i577BCEEB.versanet.de [87.123.206.235]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 2 Aug 2018 16:42:44 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <991AD90C-A84A-4302-BB25-C5FAB33C8E80@trammell.ch>
Date: Thu, 02 Aug 2018 16:42:42 +0200
Cc: Stack Evolution Program <stackevo@iab.org>, "Brian Trammell (IETF)" <ietf@trammell.ch>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3C07107C-D373-4E4B-ABBA-B025AC3A7B2A@tik.ee.ethz.ch>
References: <991AD90C-A84A-4302-BB25-C5FAB33C8E80@trammell.ch>
To: Martin Thomson <martin.thomson@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stackevo/3j8dAcHWxZlctk4rTdB9lH1F0X8>
Subject: Re: [Stackevo] draft-thomson-use-it-or-lose-it
X-BeenThere: stackevo@iab.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IP Stack Evolution Program Mailing List <stackevo.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/stackevo>, <mailto:stackevo-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stackevo/>
List-Post: <mailto:stackevo@iab.org>
List-Help: <mailto:stackevo-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/stackevo>, <mailto:stackevo-request@iab.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Aug 2018 14:42:50 -0000

Hi Martin,

I finally reviewed the doc completely and I really like the „use-it-or-lose-it“ message and the background explanations. However, I’m less sure about the migration techniques you propose (sec 4). 

First section 4.1. (Active Use), I think, could be more concrete: does it make sense to specify two versions in parallel just to use this mechanism? Or just make sure you actually have a plan to specify a next version soon. And does it also mean that you should not have a versioning mechanism if you don’t plan to specify another version soon?

Then I’m really not sure about section 4.2. Maybe I’m just not a full believer in greasing but I really think it worked „well" for TLS because you used it as a mechanism to detect deployed brokenness afterwards. I really don’t think you will have the same result if you reserve something for greasing at the time of the first specification, because then people will implement this as an extra case (even if it would be easier to just implement the versioning mechanism correctly, because this is just how people work).

Also section 4.3: I have the feeling that the middlebox problem is a bit a different question. It’s a good note to spell out that middleboxes are protocol participants (as done in section 2.2), however, explicitly only exposing what should be expose is rather the message of the path-signals and wire-image drafts and I think I would rather refer to these drafts instead.

Not sure if section 4.4. should be rather an own section because it is something additional and not really a migration technique/design principle for protocols, is it?

Mirja





> Am 26.04.2018 um 12:27 schrieb Brian Trammell (IETF) <ietf@trammell.ch>:
> 
> Hello, stackevo!
> 
> We've sent wire-image and path-signals up to the IAB; it seems to me that Martin's document on protocol extensibility and agility (draft-thomson-use-it-or-lose-it) fits well with these two, and would benefit from being published together with them.
> 
> So, please have a look at this document (https://tools.ietf.org/html/draft-thomson-use-it-or-lose-it-01) over the next couple of weeks, and send feedback with a view toward sending this document up to the IAB.
> 
> Thanks, cheers,
> 
> Brian
> 
> 
> _______________________________________________
> Stackevo mailing list
> Stackevo@iab.org
> https://www.iab.org/mailman/listinfo/stackevo