Re: [Edm] [arch-d] Call for Comment: <draft-iab-use-it-or-lose-it-02> (Long-term Viability of Protocol Extension Mechanisms)

Eliot Lear <lear@lear.ch> Thu, 26 August 2021 04:24 UTC

Return-Path: <lear@lear.ch>
X-Original-To: edm@ietfa.amsl.com
Delivered-To: edm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BF03A1454; Wed, 25 Aug 2021 21:24:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level:
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 zIC0UdZNGPsB; Wed, 25 Aug 2021 21:24:48 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 12A7D3A1451; Wed, 25 Aug 2021 21:24:46 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 17Q4Obv7234951 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 26 Aug 2021 06:24:38 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1629951879; bh=k48LSf7UQd52BKJHc+Bldg364FH9PaAYy0TqqyokC7M=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=X0UjT6nyMcOKFMOSPX1Q1QzJgkFdOsp855t34HN4yB7tZrEHbyiQwdhofS+tod19f EzQhTPCyMsDacCYdWeY5SfVXEJaW2G6V2tYGiE5bmP/I41HB8f7SUl7G9NOE9+1OgV +iYHQRFCcCW+OSGi7i6zetHWjOXWKD9mMb2NlnfE=
To: Christian Huitema <huitema@huitema.net>, Brian E Carpenter <brian.e.carpenter@gmail.com>, architecture-discuss@ietf.org
Cc: edm@iab.org
References: <162991703946.25379.3009360954932586670@ietfa.amsl.com> <078f0246-6e3f-1a49-38e7-cfdae1539c93@joelhalpern.com> <d12b1bf0-e120-f686-d1af-3f63fea15f56@gmail.com> <b2d2f62f-255c-62e9-9d82-55210f696b35@huitema.net>
From: Eliot Lear <lear@lear.ch>
Message-ID: <59cd4e1c-6fae-8269-e9b9-2eebe0a5a6f3@lear.ch>
Date: Thu, 26 Aug 2021 06:24:37 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <b2d2f62f-255c-62e9-9d82-55210f696b35@huitema.net>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="SGyirdgn3RUVd5VgsY9Q5krsL6OUZzOe3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/edm/7D_vdTKzL-TdGlQCETVM12bQLeQ>
Subject: Re: [Edm] [arch-d] Call for Comment: <draft-iab-use-it-or-lose-it-02> (Long-term Viability of Protocol Extension Mechanisms)
X-BeenThere: edm@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Evolvability, Deployability, & Maintainability \(Proposed\) Program" <edm.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/edm>, <mailto:edm-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/edm/>
List-Post: <mailto:edm@iab.org>
List-Help: <mailto:edm-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/edm>, <mailto:edm-request@iab.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Aug 2021 04:24:54 -0000

I might point out that some features *are* intentionally blocked.  
Random pings and traceroutes into a network is generally considered 
unfriendly and have been used as a means to identify points of attack.  
There are also features that**are *unintentionally* blocked, simply 
because they are not understood.  One of the challenges we face is the 
design choices that permit or deny such blocking.  It's made all the 
more challenging because protocol designers may not fully understand the 
weaknesses in their designs.

This having been said, I would be concerned about going too far down 
that path in this draft, because it really is a work unto itself to explore.

Eliot

On 26.08.21 02:57, Christian Huitema wrote:
> I have some sympathy for the assumption in the draft that features are 
> not deliberately blocked. For me, the big issue partial blockage, such 
> as intermediaries allowing some configuration of an e2e protocol but 
> not others. For e2e deployments, that translates into random failures 
> for obscure reasons. Discussing that will require a fair bit of text, 
> much more than the current section 4.3. I can see why this would be 
> better addressed in a different draft -- like the wire-image draft. 
> But yes, this draft could explicitly point to wire-image for that 
> discussion.