Re: RFC 2119 section 6

[Kevin Darcy <[e-mail]>]

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

Dan, you really *shouldn't* be treating all RR's in an AXFR response as
zone data. Whether or not TKEY was implemented shortsightedly is rather a
moot point, since implementations are already starting to use it as it is
currently specified. And I'm sure other extensions will probably want to
use Authority and/or Additional, and won't necessarily think to treat AXFR
responses as a special case. You can't expect the rest of the protocol to
evolve around AXFR while it stays static. If you want your software to be
robust, I don't think you have any other choice but to ignore unexpected
RRs in Authority or Additional, regardless of what the clarify draft says,
because, bilateral agreement or not, you're going to be *seeing* those RRs,
and treating them as zone data is bound to cause problems.

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

Perhaps I misinterpreted the following statement then:

> My AXFR client doesn't look for sections. It treats all records as part
>   of the zone. It works just fine.
>
I read this as praise of section-agnoticism.

- Kevin




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