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.