IETF Logo Mail Archive

Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs

Owen DeLong <owen@delong.com> Wed, 29 July 2020 16:32 UTC

Return-Path: <owen@delong.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFBD3A0C63 for <v6ops@ietfa.amsl.com>; Wed, 29 Jul 2020 09:32:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=delong.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 NO8eYUVFCwB6 for <v6ops@ietfa.amsl.com>; Wed, 29 Jul 2020 09:32:07 -0700 (PDT)
Received: from owen.delong.com (owen.delong.com [IPv6:2620:0:930::200:2]) by ietfa.amsl.com (Postfix) with ESMTP id 816F33A0D23 for <v6ops@ietf.org>; Wed, 29 Jul 2020 09:32:06 -0700 (PDT)
Received: from [IPv6:2620::930:0:b15e:4b13:c156:790d] ([IPv6:2620:0:930:0:b15e:4b13:c156:790d]) (authenticated bits=0) by owen.delong.com (8.15.2/8.15.2) with ESMTPSA id 06TGW4NN1546135 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 29 Jul 2020 09:32:04 -0700
DKIM-Filter: OpenDKIM Filter v2.11.0 owen.delong.com 06TGW4NN1546135
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delong.com; s=mail; t=1596040324; bh=jM3khG5jFOY++SXdcixa0BiApxcIZBYwpnHZv06yt3A=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=YGnQXk4I1NJHJ0X5+4CQMvtjdVF5rtvjv8VpiGjQ4doSMi1C+RbHcfA6uXviv/PAN QiDzGAN6xmj3ysbS2pnRwDawFOBXxVtdT7uVrBjOsfS+dIzE++wwAJ1wunfrdZj03h 2wmbC4A3aJcNgDr9LOAdfQLDIrwsLuWmp7EqWb0E=
From: Owen DeLong <owen@delong.com>
Message-Id: <A197EF3A-1E1E-40F1-BB50-68469E3C8E63@delong.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3DFB6DB4-6B05-46CC-BFF7-CDCF1B1BFE4B"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 29 Jul 2020 09:32:04 -0700
In-Reply-To: <DEB1318E-0E5B-4093-A691-8E1FD35B9F50@strayalpha.com>
Cc: Fernando Gont <fgont@si6networks.com>, IPv6 Operations <v6ops@ietf.org>
To: Joseph Touch <touch@strayalpha.com>
References: <d8d59ce07f7f4031a545ff6e24fdbb88@huawei.com> <20200729084351.GG2485@Space.Net> <32BAEAEA-7352-4BAE-ADA8-FDA2395D5732@employees.org> <a6ed89a8-c12e-b8d2-c720-5cc02e127a68@si6networks.com> <FCBD1043-A0B2-435A-9AB9-0FCE3566C769@employees.org> <4573db3f-ac8d-3103-1979-e803ae40f117@si6networks.com> <DEB1318E-0E5B-4093-A691-8E1FD35B9F50@strayalpha.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.6.2 (owen.delong.com [IPv6:2620:0:930:0:0:0:200:2]); Wed, 29 Jul 2020 09:32:04 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/oOa5a5Bot0t1yqh4Ew6f13PHoOk>
Subject: Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - implications from new development for EHs
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2020 16:32:10 -0000


> On Jul 29, 2020, at 09:04 , Joseph Touch <touch@strayalpha.com> wrote:
> 
> 
> 
>> On Jul 29, 2020, at 3:50 AM, Fernando Gont <fgont@si6networks.com <mailto:fgont@si6networks.com>> wrote:
>> 
>> I'm proposing to document and acknowledge reality.
> 
> We’ve spoken about this before, but for the group:
> 
> There is a tension between “document and acknowledge reality” and “adhere to standards to ensure interoperation”.
> 
> Not every “reality” represents something that should change a standard. Some can - and should - be declared as “bugs” or “errors” and called out for doing so.

Yes, so let’s do that… Let’s have this document represent the current situation and then call out which parts of that situation are considered to be bugs/errors
and which parts we believe represent “opportunities” for improvements in the standards.

> If we are merely documenting what happens to be implemented, we cease to be a standards body and become merely reporters.

If we avoid any introspection or consideration of operational reality, the cease to be a relevant standards body and become an ivory tower.

Owen

v2.23.0 | Report a Bug | By Email