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

神明達哉 <> Fri, 26 January 2018 19:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 886C112706D for <>; Fri, 26 Jan 2018 11:20:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SLmNHCUucPUE for <>; Fri, 26 Jan 2018 11:20:31 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 350A81241F5 for <>; Fri, 26 Jan 2018 11:20:31 -0800 (PST)
Received: by with SMTP id g1so3290210wmg.2 for <>; Fri, 26 Jan 2018 11:20:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=/M2lHqtMbmsbUtY2d8U11hcDC8wfZeIrsYsKDlyvvk0=; b=icO/P7x8555Oi9ryJZyRUTu6IW3AeQizZf412HNB9IzG+zuX4XRnk61cegIrLGuspr YedQNWEGHuGhztpyyXVW8U9a5imiB6QsOcUKklETEfOhIM7TVDuU4a6yyu518SpKzxcQ LFmW6K+iyzndj4+Yk/+rtShCdRdlV1SoldNOFActpDiq4PGelXnVBztmiDblvz8W6INA twOffGig9v+4pTEiCdzCm/J/NZ1qPGKXTVJ1U0HuzCiclCtxnAAU7ZtUAc+v3FsoM3Y3 KbmEdBCZ2WCZhfBUvizYqFHQlKTznD0/dfAT1bGIm62/o88SgT9yGYLVvY/C4b1MTax+ K6Ow==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=/M2lHqtMbmsbUtY2d8U11hcDC8wfZeIrsYsKDlyvvk0=; b=qrroJxk5S7SP349fkMkb+KvbyMJB0uHK7wJCyaNDshNzFTaSNLN5gTLL3uWQm88m74 GoD+eXrDOitvhP6up+o84cWXPVIF0jvIupICZcITkNm5Wvh43/N02tLXYe8BPjuwEJlM YMEs2mOAA0wt0F9k+ZSoaA2oc8bMJcDcWtbTvZNkjivzwCRF6mJv8gboiEAGz/g6aWPl EKHAhyv+vOqw/eJ7oqEJYTSw+6hvI0DdQvxKrLSnjZ3nOufmaAeuGOosTl814HrGcEJl 5fOSEG+JA0kbJdm878x+zzy7oz0CgSkMuw6ER03GC36tNL51DVuMTVdqXV3DMpK7pznp 708w==
X-Gm-Message-State: AKwxytdyPRed+PGg6bZYRdDybqMfPttMoOkh3N9XjYwoti98SWV1owpu k6jPcqQdORNk6/ATCHgP+vSrdyoDIpPTzfIm2FM=
X-Google-Smtp-Source: AH8x225yZxpmfNOrvbDnkL86XxQ48Nvu6p34nFjXG+RZTiBlXfoxi98gcaanAQ2aOHM5R3bOyO0PVRhIooA0ioICDxE=
X-Received: by with SMTP id c124mr10416138wma.110.1516994429621; Fri, 26 Jan 2018 11:20:29 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 26 Jan 2018 11:20:29 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Fri, 26 Jan 2018 11:20:29 -0800
X-Google-Sender-Auth: WYovE3bnJNcCKsg3DfrWBO_uH3c
Message-ID: <>
To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <>
Cc: dnsop <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Jan 2018 19:20:33 -0000

At Fri, 26 Jan 2018 17:32:33 +0100,
Petr Špaček <> wrote:

> > as these are requirements without a user-configurable knob.  If the
> > actual intent was just to specify the default behavior with a
> > configurable knob, I'd expect SHOULD-variants are used in cases like
> > these.
> Oh, I can see your point. Let me rephrase what I'm trying to say:
> 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.
> An example: RFC 4033 clearly states what should be done if result of
> validation is "Bogus". Nonetheless, Unbound has "val-permissive-mode:
> yes" which enables admin to pass bogus answers.

It's true that an implementer sometimes even ignore MUSTs.  And it's
also true that we (the IETF) can't do anything to prevent that; after
all there's no protocol police.

IMO, however, that doesn't mean we can casually use the fact to
silence objections when the requirement level might actually be too
strong.  In my understanding and also according to my experiences,
MUST requirements are in fact very strong.  Even "I do whatever I want
no matter what the standard says"-kind of customers often accept that
something cannot be implemented when it's prohibited with a "MUST
NOT".  It's much more likely that implementations (especially
open-source kinds, which tend to respect standard more literally) do
not provide a knob to change a MUST behavior.  And, if you write your
own implementation that doesn't follow a MUST, the reputation risk is
much higher than when you are just against a SHOULD.

So, if we want to use the strongest requirement level, especially when
it's somewhat controversial, I believe that the onus is on the authors
(and the WG that supports them) to explain why that level is necessary
more carefully and in detail.  On the other hand, if we really mean
silencing arguments against the requirements with the existence of a
user-configurable knob, then IMO what we should actually do is to
loosen the requirement level so that it explicitly allows such a knob.
(I'm actually not sure whether those who showed support moving forward
definitely wants to keep the MUSTs or they can live with SHOULDs).

JINMEI, Tatuya