Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)

Keith Moore <moore@network-heretics.com> Thu, 27 February 2020 23:18 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E43F3A077C for <ietf@ietfa.amsl.com>; Thu, 27 Feb 2020 15:18:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 9FRVncbtqrVh for <ietf@ietfa.amsl.com>; Thu, 27 Feb 2020 15:18:51 -0800 (PST)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F18A73A0766 for <ietf@ietf.org>; Thu, 27 Feb 2020 15:18:50 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id CB6937D1; Thu, 27 Feb 2020 18:18:48 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 27 Feb 2020 18:18:48 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=8TCs7+SyfCRiYYZrk872hxCPRcFXFzFsKl9YaCQN3 LE=; b=DINJE7ckkJQrDPLJZaRUQnyNWreL4Z710qDC8kFXwNUVErGEWC3hQHRpA Fcj9NPD/ZW5vuvZeM7Z99q0igXEASpslA8KPpJF2KGRgSVTtYtSgQI4aJWXijK1j o43X3bt51djW3HTzM2wRcgPL1PLKb40ZACQNWiLeFau2gsVoVjUgYhhpEJUUxNRu e3SnZahHcZ9yZNfbI8bqJRvj9jK8ymwKAw7NMvslZzZdWspiHIMabDv0bVyRfwgN PskjOE84C7xWh2OO9JkM2R0adTTyYK62Iz7FlhaxQfzeQamqsLGoNnOrQVbQqmxh l/lsX/4wcdiKbWihlkNwYBrZ887EQ==
X-ME-Sender: <xms:V05YXk_aqQIeSjlThqhh3bFOyOPt5nko9AEakzrwX9Y-TdefoDvH1A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrleejgddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthekre dttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhrvgcuoehmohhorhgvsehnvghtfiho rhhkqdhhvghrvghtihgtshdrtghomheqnecukfhppedutdekrddvvddurddukedtrdduhe enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmohho rhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:V05YXviYCQuknPflsT6SgGoUcZUa5JzD3uxIfuRxGmq1pJYUUoVodQ> <xmx:V05YXsz6l6iKbihBEtSWIO6m3QNEmsJj9xtw_r9auPpwubjJiMZJNg> <xmx:V05YXn9A3p0GVoWtGkKjhwd9Y51Z-baG6Wr_2ZRdQ59xjCATLs4CbA> <xmx:WE5YXpY6IwptzXoS2JT0FIgJ-an6rjUAIRTRsJo52Eo2PmVhMlvNRQ>
Received: from [192.168.1.97] (108-221-180-15.lightspeed.knvltn.sbcglobal.net [108.221.180.15]) by mail.messagingengine.com (Postfix) with ESMTPA id AF9E23060FD3; Thu, 27 Feb 2020 18:18:47 -0500 (EST)
Subject: Re: [Int-area] Is IPv6 End-to-End? R.I.P. Architecture? (Fwd: Errata #5933 for RFC8200)
To: ietf@ietf.org
References: <876c9105-3da4-e614-2db0-bea025b54663@si6networks.com> <7749f91f-03f1-cc14-bae8-5fe68c88879f@si6networks.com> <CALx6S36wN7VEi_rxLC1ETcTvkGaPhs20KhQrGWAGGTrCL5OT+g@mail.gmail.com>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <b3a090f0-2b6f-1063-bef7-01a9e7ac29c7@network-heretics.com>
Date: Thu, 27 Feb 2020 18:18:47 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CALx6S36wN7VEi_rxLC1ETcTvkGaPhs20KhQrGWAGGTrCL5OT+g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/p7F6ZA37JepxJQ-ik5cCOPJz5BA>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Feb 2020 23:18:52 -0000

On 2/27/20 5:07 PM, Tom Herbert wrote:

> I think we need to be careful that IETF is labeled as a collection of
> inflexible architectural purists.

There are several problems with the "we should not be architectural 
purists" argument:

1. It presupposes that there are no significant technical justifications 
for different components of the infrastructure, or different stacks or 
applications, to behave consistently with one another, when in fact that 
very consistency is what permits interoperation at all.

2. IETF's job is not to specify what makes some vendors happy, but to 
specify what is believed to work well and interoperate, not merely in 
the short term but also in the long term.   Vendors' interests and the 
interest of the Internet community are not the same thing.   While 
everyone understands that a specification that nobody implements serves 
no useful purpose, a specification that abandons good sense in order to 
please (some) vendors does harm to the Internet in the long term by 
adding more complexity, more operational issues, and more costs that are 
ultimately borne by users.

3. The perceptions of people outside the IETF should not be considered 
more important that the technical judgment of those who actually have to 
make the compromises that go in the specifications.   This is not to say 
that IETF always knows better than everybody else, but rather than the 
working groups and authors who actually write the specifications have 
some responsibility to make good compromises, whereas external critics 
bear no such responsibility.

4. There will always be people insisting that IETF consists of 
inflexible architectural purists, because this is a standard trope that 
can be used by anyone who objects to any consensus decision that IETF makes.

Keith