Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

Edward Lewis <edward.lewis@icann.org> Mon, 09 March 2015 15:25 UTC

Return-Path: <edward.lewis@icann.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC29E1A9009 for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2015 08:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 dfEDBQvKb11h for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2015 08:25:19 -0700 (PDT)
Received: from out.west.pexch112.icann.org (pfe112-ca-2.pexch112.icann.org [64.78.40.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 602931A9024 for <dnsop@ietf.org>; Mon, 9 Mar 2015 08:16:33 -0700 (PDT)
Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 9 Mar 2015 08:16:31 -0700
Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.0847.030; Mon, 9 Mar 2015 08:16:31 -0700
From: Edward Lewis <edward.lewis@icann.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Thread-Topic: [dns-operations] dnsop-any-notimp violates the DNS standards
Thread-Index: AQHQWnR2uDXa0vwttkGLrWqOYN+WYp0UdWYA
Date: Mon, 9 Mar 2015 15:16:30 +0000
Message-ID: <D1232D95.992E%edward.lewis@icann.org>
References: <20150309110803.4516.qmail@cr.yp.to>
In-Reply-To: <20150309110803.4516.qmail@cr.yp.to>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.8.150116
x-originating-ip: [192.0.47.235]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3508744586_15210437"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/7NfA5euqmU0Y8SqZ4tRP-S5KnrM>
Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 09 Mar 2015 15:25:23 -0000

On 3/9/15, 7:08, "D. J. Bernstein" <djb@cr.yp.to> wrote:

>The common theme of CNAME/MX/A and A/AAAA is that there's widepread
>interest in being able to easily retrieve multiple record types. What
>I'm saying is not that query type ANY is the ultimate answer (clearly it
>can be improved); what I'm saying is that these are protocol issues, and
>that protocol changes need to be handled by an appropriately chartered
>IETF working group.

(I removed the dns-operations list from this because this needs to be
discussed on DNSOP.)


Dan,

You're right.  But.

Operators are not bound to comply with what the IETF documents.

As much as operators shouldn't bully the IETF nor the public for which the
serve, the street goes two ways.  The IETF is not able to and should not
bully them.  The IETF is supposed to provide us with an interoperable way
to operate and is supposed to have documents that reflect "running code."

>  * Second: The merits of the protocol modification have to be properly
>    discussed in that working group, to evaluate the costs and benefits
>    of the protocol modification---and to consider whether there are
>    better ways to achieve the same benefits.


If operators find that a protocol needs to be modified to be properly
operated, the IETF ought to adjust the protocol definition.  Having a
migration path would be a plus too.  (Said tongue in cheek.)

But - "finding that a protocol needs to be modified" is not as easy as
that - hence my quoting of your words above.

Ed Lewis