Re: RFC 2119 section 6

[Brian Wellington <[e-mail]>]

On Thu, 12 Jul 2001, D. J. Bernstein wrote:

> The problem is not the amount of code. The problem is the time and
> effort required to deploy that code at thousands of sites.

No one but you thinks it's necassary that all of these sites deploy the
new code.

> If you extend a protocol without maintaining compatibility, you are
> inflicting completely unnecessary costs on people who don't want to use
> your extension.

True.  I don't think anyone disagrees with this.

> 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.)

I'm suggesting no such thing.  I'm saying that your server will cache the
records, which could lead to strange results in the future.  For example,
the cache TKEY records would be included in the response to an ANY query.

For the record, your comments about BIND 9's handling of unknown types
in http://cr.yp.to/djbdns/newtypes.html are wrong.

> 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.

Exactly which extension are you complaining about?  No other
implementations have these problems.

> 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.

No one's arguing for an incompatible extension.  The point is that there
are extensions already that are reasonable given the spirit of the
original AXFR specification.  The axfr-clarify draft clarifies the AXFR
specification, which makes these extensions fully legitimate.

I'm fairly sure no decisions have ever been made purely to make your life
more difficult.

Brian



to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.