Re: RFC 2119 section 6
"D. J. Bernstein" <djb@cr.yp.to> Thu, 12 July 2001 19:17 UTC
Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09647 for <dnsext-archive@lists.ietf.org>; Thu, 12 Jul 2001 15:17:39 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.31 #1) id 15KlKU-000DVy-00 for namedroppers-data@psg.com; Thu, 12 Jul 2001 11:36:50 -0700
Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15KlKU-000DVs-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 11:36:50 -0700
Received: from randy by rip.psg.com with local (Exim 3.30 #1) id 15KlKU-000GzP-00 for namedroppers@ops.ietf.org; Thu, 12 Jul 2001 11:36:50 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: "D. J. Bernstein" <djb@cr.yp.to>
To: namedroppers@ops.ietf.org
Subject: Re: RFC 2119 section 6
References: <E15IDD0-000J0d-00@psg.com> <E15IEZl-000LJv-00@psg.com> <E15IMxJ-000ACJ-00@psg.com> <E15Ie0n-000H8P-00@psg.com> <E15Ikad-0003j0-00@psg.com> <E15JxhS-000Kro-00@psg.com> <E15K8Yt-000IXm-00@psg.com> <E15KEI2-0003Cy-00@psg.com> <E15KLoi-0008wA-00@psg.com> <E15KY3J-0006OT-00@psg.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Message-Id: <E15KlKU-000DVy-00@psg.com>
Date: Thu, 12 Jul 2001 11:36:50 -0700
Content-Transfer-Encoding: 7bit
The problem is not the amount of code. The problem is the time and effort required to deploy that code at thousands of sites. If you extend a protocol without maintaining compatibility, you are inflicting completely unnecessary costs on people who don't want to use your extension. Suppose, for example, that you start randomly sending TKEY records to caches that haven't asked for them. My cache has no special knowledge of TKEY, but it follows the letter and spirit of the RFC 1123 rules on new record types, as explained in http://cr.yp.to/djbdns/newtypes.html; so it will save those records if they're within your bailiwick, and return them in response to appropriate queries. Suppose that---as Brian Wellington seems to suggest---these cached TKEY records will cause your own TKEY-aware clients to fail. (I don't know if this is actually the case. I haven't read the TKEY specification, nor do I see any reason that I should. IPSEC works.) Your extension is then incompatible with the installed base. If you insist on using it, you are creating failures. If you insist that I change my code to work around these failures, you are imposing costs on people---my users---who don't want to use your extension, and you will still have to wait many years before your extension is safe to use. That is not sensible engineering. You should have designed a compatible extension, an extension that would be safe to use immediately. I cannot imagine why anyone would argue in favor of an incompatible extension, except as a deliberate attempt to impose costs on other people. I accuse the BIND company of doing precisely that. Kevin Darcy writes: > Section-agnosticism is not necessary for minimalism, security or > performance, it's just a "feature" Dan made up to justify a fairly > mundane design decision What are you talking about? I've said nothing of the sort. This was a trivial implementation decision: out of the many possible ways to correctly parse an AXFR response message, I chose the one that I found easiest to write. ---Dan to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.
- Re: DNSEXT WGLC AXFR-02 SHORT last call Robert Elz
- Re: DNSEXT WGLC AXFR-02 SHORT last call Peter Koch
- Re: DNSEXT WGLC AXFR-02 SHORT last call Masataka Ohta
- Re: DNSEXT WGLC AXFR-02 SHORT last call Robert Elz
- Re: DNSEXT WGLC AXFR-02 SHORT last call D. J. Bernstein
- Re: DNSEXT WGLC AXFR-02 SHORT last call Olafur Gudmundsson/DNSEXT co-chair
- Re: DNSEXT WGLC AXFR-02 SHORT last call Randy Bush
- Re: DNSEXT WGLC AXFR-02 SHORT last call D. J. Bernstein
- AXFR security issues, again D. J. Bernstein
- Re: DNSEXT WGLC AXFR-02 SHORT last call Andreas Gustafsson
- Re: DNSEXT WGLC AXFR-02 SHORT last call Robert Elz
- Re: DNSEXT WGLC AXFR-02 SHORT last call Paul A Vixie
- Re: DNSEXT WGLC AXFR-02 SHORT last call Paul A Vixie
- Re: DNSEXT WGLC AXFR-02 SHORT last call Olafur Gudmundsson/DNSEXT co-chair
- Re: DNSEXT WGLC AXFR-02 SHORT last call Paul A Vixie
- RFC 2119 section 6 D. J. Bernstein
- Re: DNSEXT WGLC AXFR-02 SHORT last call Paul Vixie
- Re: RFC 2119 section 6 D. J. Bernstein
- Re: DNSEXT WGLC AXFR-02 SHORT last call D. J. Bernstein
- Re: RFC 2119 section 6 Kevin Darcy
- Re: RFC 2119 section 6 Andreas Borchert
- Re: DNSEXT WGLC AXFR-02 SHORT last call D. J. Bernstein
- Re: RFC 2119 section 6 D. J. Bernstein
- Re: RFC 2119 section 6 Kevin Darcy
- Re: DNSEXT WGLC AXFR-02 SHORT last call Robert Elz
- Re: DNSEXT WGLC AXFR-02 SHORT last call Robert Elz
- Re: RFC 2119 section 6 D. J. Bernstein
- Re: DNSEXT WGLC AXFR-02 SHORT last call Kevin Darcy