Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 29 January 2018 17:14 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF1012ECAD for <dnsop@ietfa.amsl.com>; Mon, 29 Jan 2018 09:14:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=yitter.info header.b=Pr05fti8; dkim=pass (1024-bit key) header.d=yitter.info header.b=AhBIoFjs
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 Q3M9sThF0S9M for <dnsop@ietfa.amsl.com>; Mon, 29 Jan 2018 09:14:57 -0800 (PST)
Received: from mx4.yitter.info (mx4.yitter.info [159.203.56.111]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B84112EC9B for <dnsop@ietf.org>; Mon, 29 Jan 2018 09:14:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mx4.yitter.info (Postfix) with ESMTP id 9A1E2BE072 for <dnsop@ietf.org>; Mon, 29 Jan 2018 17:14:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1517246096; bh=N6RKEYwdFpZmYj877vfbxzm9JaxzomMARQaiTfyA6k4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=Pr05fti8BxMf/jte8z1Tf0QXOgIjD7vHrpUHOqZnmmnoByXg6eKpCPyaDUvENNBbX Pm/3cI54DPjOchtjAQlaNO3EeRpxByYfEbmtOPiUe2lSAAuHA5gKR9V96nds9Ps/qX do4/+o3I860rSXsxkULTDFYzq6e2PhFU01/NO8Sk=
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx4.yitter.info ([127.0.0.1]) by localhost (mx4.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtCZGwmSgCVY for <dnsop@ietf.org>; Mon, 29 Jan 2018 17:14:50 +0000 (UTC)
Date: Mon, 29 Jan 2018 12:14:50 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yitter.info; s=default; t=1517246090; bh=N6RKEYwdFpZmYj877vfbxzm9JaxzomMARQaiTfyA6k4=; h=Date:From:To:Subject:References:In-Reply-To:From; b=AhBIoFjs8hoQCTfryAJxJOhWF3Uxu2FTMhpVBupjbUaF1bKvWg5UdTwCrdYiZT8eR CRdRLu75OmI6fAY0FJ2iRp10QADh7FY+MBkqNSZvGcaaW8w5utAuqu7hGaLtWicnAj K6zoUjgeAdUJTn4WbyQassp9ViKggNB9VYDQh5WE=
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsop@ietf.org
Message-ID: <20180129171450.GA17118@mx4.yitter.info>
References: <9DCE2F63-EE37-4865-B9D6-6B79BBE05593@gmail.com> <CAJE_bqcSirZyfr7PKhf=ttMxf=DeMVeJPNPn=R-HS2cH3Z-nPw@mail.gmail.com> <8e69dac2-359b-d528-45e5-05604f4dbf90@nic.cz> <CAJE_bqdeDRmN78dE5VUYDB6y-fXfUK9gSOkjJxszcP0WjjR9dw@mail.gmail.com> <3eb04472-82f0-9dd9-0922-4e6cd4f825e6@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <3eb04472-82f0-9dd9-0922-4e6cd4f825e6@nic.cz>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jkfXUJjm6W8fZBKHHfCa9DKAaPU>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jan 2018 17:14:59 -0000

On Fri, Jan 26, 2018 at 05:32:33PM +0100, Petr Špaček wrote:
> I personally agree with the doc, it makes sense to me, and I do not
> believe that its wording prevent anyone from adding knobs they want.
> Software in the end will do whatever its developers wanted, which might
> include knob to override any part of spec.

The purpose of RFC 2119 language is not to make people feel better or
to provide the imaginary benefit of a stick with which to beat people
for non-conformance.  The purpose is to maximise reliable
interoperation, where "reliable" is interpreted generously to include
concern for security and privacy, and "interoperation" is interpreted
generously to include avoidance of anti-patterns in design and
deployment choices.

So the problem here is that, if people start adding local
configurations to override the proposed update to "MUST", the goals of
the document won't be realised anyway.  If on the other hand we
understand 2119 language correctly and apply it rigorously, the
failure to capture localhost at the local boundary will already be
understood as a problem (regardless of what the mechanism is by which
one gets there -- the BSD approach would be as good as any other).

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com