Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis

Petr Špaček <pspacek@isc.org> Mon, 12 July 2021 11:52 UTC

Return-Path: <pspacek@isc.org>
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 0BB683A107D for <dnsop@ietfa.amsl.com>; Mon, 12 Jul 2021 04:52:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.2
X-Spam-Level:
X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, 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=isc.org header.b=PRX8ZzpO; dkim=pass (1024-bit key) header.d=isc.org header.b=Ob0nnkti
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 G1zg2r6yUWGu for <dnsop@ietfa.amsl.com>; Mon, 12 Jul 2021 04:52:16 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C72D33A1050 for <dnsop@ietf.org>; Mon, 12 Jul 2021 04:52:16 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 6D22A3AB01C for <dnsop@ietf.org>; Mon, 12 Jul 2021 11:52:15 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1626090735; bh=EM9Im+DHPs1b1vKGpQcuSab3CzuvIurvZmN1ainzziA=; h=To:References:From:Subject:Date:In-Reply-To; b=PRX8ZzpOcIx4kRT4uFH/Vyl57ALkI+2GwFUQ4YCuTgw0o8zHAFokbk/74PYAwSWWd dfLnKGcOmUJtJTIZW+64MjqeSNidCr/vBVZCrW5UmP1JkGm6GrK1zBG+iB12e2NF9i g6XRfNQHpc3lV6n25TPZqa/Mp59GaOGYwYrkd244=
Received: from zmx1.isc.org (localhost.localdomain [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 349B9160072 for <dnsop@ietf.org>; Mon, 12 Jul 2021 11:52:15 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id DB32116006F for <dnsop@ietf.org>; Mon, 12 Jul 2021 11:52:14 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 zmx1.isc.org DB32116006F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1626090734; bh=NrZbOojJe358zncQDV0ULDL6ZXIEWzGAIqDLWpx7AjA=; h=To:From:Subject:Message-ID:Date:MIME-Version:Content-Type: Content-Transfer-Encoding; b=Ob0nnktiydmIkb9068fO6DaOPQMABZWnLYFuo0OVHFJk/5uwBKkat7TcCh3/ulEha PgSZSWZ77+TDVUWb/P9pFBOeWyGKzuFjQyWPNp3SAJqX6wofxjqWqVwhNPGizt3wcP b4A1yx3yGNQkZfHjUOxL5v9BvEYB+mQbEnzB9Dz0=
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id a5gQHyTYIFvz for <dnsop@ietf.org>; Mon, 12 Jul 2021 11:52:14 +0000 (UTC)
Received: from [192.168.0.116] (ip-86-49-248-122.net.upcbroadband.cz [86.49.248.122]) by zmx1.isc.org (Postfix) with ESMTPSA id 43011160066 for <dnsop@ietf.org>; Mon, 12 Jul 2021 11:52:14 +0000 (UTC)
To: dnsop@ietf.org
References: <CAHw9_iKhvHwUfJMOp-YhJkimmnN0f3DLbh+JWYxhCiZ9CjEEQQ@mail.gmail.com> <0ed6efa6-c981-fa64-472c-eef0c5453f4a@isc.org> <4559CEDB-93D4-4BB6-8E39-AA0A0493D40C@dukhovni.org>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <pspacek@isc.org>
Message-ID: <b27d6594-d306-9700-16b3-6602bb06607c@isc.org>
Date: Mon, 12 Jul 2021 13:52:12 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <4559CEDB-93D4-4BB6-8E39-AA0A0493D40C@dukhovni.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EZynVzddG5TyvijdXOWMz1SIsp0>
Subject: Re: [DNSOP] Consensus check on underscore names and draft-ietf-dnsop-rfc7816bis
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 12 Jul 2021 11:52:26 -0000

On 08. 07. 21 18:00, Viktor Dukhovni wrote:
>> On 8 Jul 2021, at 10:28 am, Petr Špaček <pspacek@isc.org> wrote:
>>
>> With my implementer hat on, I say "no", I don't see a compelling reason to "mandate" it. Keep it at MAY/optional level and leave it to implementers to decide what's best for their implementation and use-cases.
> 
> Just wanted to check what you mean by *mandate*, I don't quite see
> RECOMMENDED as a mandate, my understanding is that SHOULD/RECOMMENDED
> means "do this unless you have good reason to do otherwise".  So there
> is certainly enough rope to ignore the advice.
> 
> How would you strongly suggest that stopping qname minimisation at the
> first special-use label is probably a good idea, more strongly than just
> mentioning as a possible optional optimisation?

When I look at RFC 2119 ...

--------
3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there 
may exist valid reasons in particular circumstances to ignore a 
particular item, but the full implications must be understood and 
carefully weighed before choosing a different course.

...

5. MAY   This word, or the adjective "OPTIONAL", mean that an item is 
truly optional.  One vendor may choose to include the item because a 
particular marketplace requires it or because the vendor feels that it 
enhances the product while another vendor may omit the same item. An 
implementation which does not include a particular option MUST be 
prepared to interoperate with another implementation which does include 
the option, though perhaps with reduced functionality. In the same vein 
an implementation which does include a particular option MUST be 
prepared to interoperate with another implementation which does not 
include the option (except, of course, for the feature the option provides.)
--------

I think MAY describes exactly what workarounds are:
A completely optional hack which _nobody_ can rely on.

When I read definitions SHOULD and MAY together, I believe the text 
implies problems caused by ignoring SHOULD lie on the party which choose 
to ignore that particular instance of SHOULD:
IMHO this is very wrong when describing workarounds.
Workarounds are temporary "crutches for broken implementations", and 
anything stronger than MAY is just wrong.

As a resolver implementer, I do not want to get into a position when a 
broken auth vendor uses the SHOULD requirement in RFC as an argument to 
keep their auth-brokenness because "resolvers SHOULD implement the 
workaround!"

-- 
Petr Špaček