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

神明達哉 <> Fri, 26 January 2018 22:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7261B128896 for <>; Fri, 26 Jan 2018 14:13:41 -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 JkuamMyZ0Nus for <>; Fri, 26 Jan 2018 14:13:39 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4B6991200E5 for <>; Fri, 26 Jan 2018 14:13:39 -0800 (PST)
Received: by with SMTP id v123so23846629wmd.5 for <>; Fri, 26 Jan 2018 14:13:39 -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; bh=FVP3/ZcK+2xsB+uKStZLzaXjngr6bQFiuDSQAnlIaus=; b=h/0BA3D860tPIBYuaFFdd97mK2/7q2oEZvx23cUFZds+bG5UaEXyWswdnNqVadWe2n Tzf02YlhQSJCBs8PHxWMa9zyQzIRh4g7QNtQXRyLYHG1NVmysZmscsFFUGTLp7qBgRdq XLIt3RDoeJvpNSnB83swm2KpudwY95umHCMuFrfuKZ/YQOv4YBMuu/8B6OA8i3wONDvL UCYoXFelRYFx+iftY7+2p4Hgl17fJ50t/spzTogVVNmz/AOQA+TC8WW++rGJhLEMLyGs a+E5cLzE5fY7f9ZJndw/1LkYRau8ebUk6siOJDXWWvChlIMnOzdWZJ+0vlApFmn6UX1H RDkA==
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; bh=FVP3/ZcK+2xsB+uKStZLzaXjngr6bQFiuDSQAnlIaus=; b=AYjfMelGCEZa8/r8T/gHMF4X2vpJWcGZHnXabcFO2fEaMue8RYQJnQyMZCW5T1fwDI LAcCl1ReZaZlZUvtaWCxXZZS704yZam1VuHnvH6QLKiUN3z2Rn7dCyOdwX4DKgrJYLBt gB7iU0TXD5Jin+cckM4Kk8Dstj4lzEYmI28KFVZWcX6BYLZZtp6F2C+6idT+esDCk/HM to1tJJz+RjELW2vu6DVDrSyrwX3NqbVJQmH63cu3Lg/nDxDMP0o0wFXhmTotFUCwnLti YIbI8WIZno/m3X6+g68+IRibd9NEuHvIa+hcpXZnmBiQottS4KTntm9GKlYMOUd3tPTh a3xQ==
X-Gm-Message-State: AKwxytd1y79bU/brXwRMGDXJJy/ZqczfUshpccgsdO9EK+DdNQMtfXWr jgp9Wmj0Yr8isnfzH2aPs2aGUnjEQppv0aSlHLXoP9+Q
X-Google-Smtp-Source: AH8x227Z4fLcKP5YI6Z7fk1E6X5j2abjEhtE0V9kY5KJLLfD/CyEXxQKWKMc4snV5D2qw5GvLA8bezMimMH+mbDBiKg=
X-Received: by with SMTP id t3mr11394440wmh.134.1517004817613; Fri, 26 Jan 2018 14:13:37 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 26 Jan 2018 14:13:36 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <>
Date: Fri, 26 Jan 2018 14:13:36 -0800
X-Google-Sender-Auth: tPEB4l1ojplops3gzlICHNq6s_s
Message-ID: <>
To: Ted Lemon <>
Cc: dnsop <>, =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <>
Content-Type: text/plain; charset="UTF-8"
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 22:13:41 -0000

At Fri, 26 Jan 2018 14:24:10 -0500,
Ted Lemon <> wrote:

> > 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.
> Can you talk about why you personally think MUST is too strong here?

I said it might be too strong, so it's more that I *wonder* whether it
might be too strong.  This impression comes from the observation that
while the draft uses a strong word several people hinted at
customization.  That looked odd to me - if they so strongly think it
must be a MUST, it would look more sensible to me if they said "it
MUST be that way, period <because XXX>".  It's true that there are
always people who still disagree with it and are willing to ignore the
MUST, but in that case we should rather call them a standard offender
instead of pretending to offer an option.  Stating a MUST on one hand
while hinting at violating it as a "customization" on the other looked
awkward to me, making me think the WG might actually feel it's too

> It's interesting to discuss it on a meta-level, but I think we might
> get lost in the weeds doing that.   If you are feeling uneasy about
> this requirement, I suspect that there is a use case lurking down
> there somewhere under the discomfort.   Bringing it up to the
> surface might help.

Personally, I don't mind the MUST (and for that matter I don't mind
either if it's a SHOULD).  But given that it will break existing
practices, I'd like the draft to explain the rationale in more detail.
And I'd like it to make it clearer that it intentionally plugs any
possibility of user customization, whether it's a protocol-violating
server option or a customized /etc/hosts entry.  And then let the
market decide whether to obey it.

As for specific use case, I don't have one for myself as such.  But
the discussion so far (not only in this thread but also in the past WG
discussions, which actually are the base of my own response to the LC)
seems to suggest that a non-negligible number of deployments exist.
And I just thought the current content of the draft isn't clear enough
as a message for those with the existing deployments.

BTW: in case you think if I personally don't mind I should shut up: I
observed this oddity as a weakness of the document that could make it
less convincing and more likely to be ignored.  I believe pointing it
out and possibly improving it are completely valid feedback for a
WGLC, regardless of my own personal position on the content.  Of
course, whether and how to address the feedback is up to the WG; I'm
not intending to be a blocker but are just trying to help it.

JINMEI, Tatuya