Re: IETF Policy on dogfood consumption or avoidance - SMTP version

Nick Hilliard <nick@foobar.org> Sun, 15 December 2019 23:00 UTC

Return-Path: <nick@foobar.org>
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 2BC9D12006F; Sun, 15 Dec 2019 15:00:23 -0800 (PST)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 pALvujW2VikV; Sun, 15 Dec 2019 15:00:21 -0800 (PST)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8995120013; Sun, 15 Dec 2019 15:00:20 -0800 (PST)
X-Envelope-To: ietf@ietf.org
Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id xBFN0HT6012755 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Dec 2019 23:00:18 GMT (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local
Subject: Re: IETF Policy on dogfood consumption or avoidance - SMTP version
To: John C Klensin <john-ietf@jck.com>
Cc: ietf@ietf.org, iesg@ietf.org
References: <8EE11B75E1F8A7E7105A1573@PSB>
From: Nick Hilliard <nick@foobar.org>
Message-ID: <6a0a5f8a-9da6-30e7-f4b9-0b263cda507a@foobar.org>
Date: Sun, 15 Dec 2019 23:00:16 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.9
MIME-Version: 1.0
In-Reply-To: <8EE11B75E1F8A7E7105A1573@PSB>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/MZ0VYZpRto3W9zcgD1dWco64V5k>
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: Sun, 15 Dec 2019 23:00:23 -0000

John C Klensin wrote on 15/12/2019 21:15:
> It is whether there is consensus among IETF participants that
> "the leadership" (I presume whatever bodies, individuals, or
> their designees are relevant) should have the authority to
> instruct the Secretariat to violate an IETF standard without
> consultation of appropriate experts within the community
> (presumably on relevant mailing lists), evidence of IETF rough
> consensus, and/or Internet Drafts that specify alterations to
> the relevant standard(s).
this is rather missing the point - or perhaps accepting the point - that 
there's a good deal of difference between defining a working protocol 
and running a production system which uses that protocol. The protocol 
will be defined by people who are good at defining protocols, but the 
system will be run by someone who knows how to run systems. Sometimes 
there is consistency between the two.

Currently it's expedient to drop domain literals in EHLO commands, but 
this is a policy practice of the operators rather than an integral 
function of the protocol itself.  Codifying this in the protocol is 
roping in policy considerations and probably the line protocol is not 
the place to do this.

Nick