Re: Usable extension headers [Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt]

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 28 November 2019 22:06 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5036B120041 for <ipv6@ietfa.amsl.com>; Thu, 28 Nov 2019 14:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 y8IYQQc1qYnx for <ipv6@ietfa.amsl.com>; Thu, 28 Nov 2019 14:06:32 -0800 (PST)
Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0EDC120033 for <6man@ietf.org>; Thu, 28 Nov 2019 14:06:32 -0800 (PST)
Received: by mail-pg1-x52c.google.com with SMTP id b1so13421770pgq.10 for <6man@ietf.org>; Thu, 28 Nov 2019 14:06:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Zo3w6RLl4xHNwqgtu78Jhc8UeXwrdKhH1uuJa3E8UN0=; b=JqJXKmoxTAGK5kyG41w4WMiaURVFiyyZ3sFAXyu8rWsJoXdlsslbljNXUlphx632xu VRpltmg3JO9KobfHfkm+Vq63+dcLdeUYb8aK3dJb084hHLss6HJB8sjHC4cjByEymaRW gyGtzaREKX6YSim53tI3FvP+F0bnpET+V0pB4dyfVVnp8Meom6EMGiL01Q/23hSXPc1q zJrmB3W1uSQoOJclmDn084k7aSW3yJ/BPtJfaXV/ZBrr3mYwShQihgkg9YcOm7diI8tI Id/Nit4Bk1QVcZcqBBXGjxxfFZMVwH3SWQvgO+awjjUa6+Tgs/p0c4WOO7+NbPDWSC1e swhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Zo3w6RLl4xHNwqgtu78Jhc8UeXwrdKhH1uuJa3E8UN0=; b=sBEHFfHapldllIbQaXaoiUXzhspqqAIKCoq0RtDB9SR/o6W2c9AmKbj/PQHdOHBRgQ ageBNgtHKvnRCqMy4X3fBupksl9mN2oaVGAfGfpM2FyUyhejT6rGA9/U+5VJQwNADxmm o3s/ghQkywqDdywvm8CHqu7Cw8B+UjHUTPBJIQzZFS2y9T1jtBxEY/mt/pR2zjPjtH86 p1kk4YFMyVCJ4M2lkqQZj8KbWRplsS8rGH1Uc22EphDfovHgHuM+bKXaAMUyswWNzo7Y tgbFNGN5l6zRJhEgy5wmY5ckU6kZL4PN0IPIXHT4pj5DMrBNLFcwEXXW8YSh56y9zbWw Iz3w==
X-Gm-Message-State: APjAAAVbi9cP22N/4PwnoLkFDrT8sj1XLAFjkvlZ3RPtpzAIWDO3qNvg lWQmAXXFcBlskfuialteCz18pHTR
X-Google-Smtp-Source: APXvYqwZQHEgMwB1zQmdxC/Oou5ZhnkVdPXG1vF8bVvVY8/ALcMillHBsf8nVyCiotbUeP4vYsflKQ==
X-Received: by 2002:a63:1e23:: with SMTP id e35mr13482464pge.219.1574978791419; Thu, 28 Nov 2019 14:06:31 -0800 (PST)
Received: from [192.168.178.30] (228.147.69.111.dynamic.snap.net.nz. [111.69.147.228]) by smtp.gmail.com with ESMTPSA id q4sm20725080pgp.30.2019.11.28.14.06.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Nov 2019 14:06:30 -0800 (PST)
Subject: Re: Usable extension headers [Re: New Version Notification for draft-voyer-6man-extension-header-insertion-08.txt]
To: Ole Troan <otroan@employees.org>, Tim Chown <Tim.Chown@jisc.ac.uk>
Cc: 6MAN <6man@ietf.org>
References: <157422734071.5406.14331301768750185617.idtracker@ietfa.amsl.com> <851F7007-3DD5-42F3-8884-8842DA07EE53@cisco.com> <1cfd682f-d6bc-a697-38a7-933aa0485b8a@si6networks.com> <D4436EF5-2B97-44A4-915D-EF7611590B51@steffann.nl> <ccf6cbe6-c837-64e3-b25e-d3fa8e3b7bcb@si6networks.com> <E68CE93F-4C3E-44FB-B4B5-7C6FC6799E47@gmail.com> <554baf9b-2a7f-8098-8203-e7d3277b549b@gmail.com> <CALx6S36L5AWEaXmccpKoENxOEv-XRCmTsq1bCqi06J_YgJGZdg@mail.gmail.com> <ecb3c877-c347-fd3a-86de-8f05fe8b7459@gmail.com> <CALx6S353m9b9b2b+Yt3x-g=BZuE6vwcOoGGfq4BPONVscnQ=xg@mail.gmail.com> <d9c2e11b-53b4-e281-e869-28802a76c72f@gmail.com> <CALx6S346p=M09ZPY_xM2X3gkPp_0KUVZU_u4UeLUagomRnjhPw@mail.gmail.com> <79d22e5a-0145-9ad9-e965-d3744b58c3bf@gmail.com> <d791c9eee34c4e019292fc74d629217c@boeing.com> <5d2af468-be61-d2ca-5bf0-35d5f71fdb6c@gmail.com> <6A41AB04-F56B-46E1-8B8B-3E24B928A042@jisc.ac.uk> <1B629A88-AE10-4F65-8D3D-FD2702B6D63D@employees.org>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <07f06c2f-adb0-7e8c-0c7a-e7988c7baa40@gmail.com>
Date: Fri, 29 Nov 2019 11:06:27 +1300
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <1B629A88-AE10-4F65-8D3D-FD2702B6D63D@employees.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZPAykRZiOgTSFKvr2kpU6I2U9lA>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Nov 2019 22:06:34 -0000

On 29-Nov-19 00:03, Ole Troan wrote:
...> RFC7872 was (IMNSHO) based on the flawed belief that any end-host/service end-point should accept arbitrary extension headers.

I don't think so. The extension header mechanism was designed on a "consenting adults" model where all that matters is that both end points support a particular header type. (With two exceptions: the fragment header and the hop-by-hop options header, which are both significant en route. The routing header is *not* an exception to that model.) RFC7872 might be construed as testing whether that model is viable, but it doesn't imply any particular belief about end systems afaik.

> The document offers little with regards to the deployment of extension headers within a limited _network_ domain.

Indeed not; why should it, since it was measuring the open Internet?
> 
> I'm all in support for continuing monitoring and testing. 

Yes.

> Testing the "right thing"(tm) and understanding the results is a discipline on its own. If there is any learning that I can take from 7872, is that the RFC format isn't the right channel for measurement results.

There are specialised conferences or conference streams for measurement stuff, where there is also specialised peer review. Personally I don't care where the results are published, as long as we can all see them.

Regards
   Brian