Re: axfr-clarify's fraudulent claims of consensus

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        14 Feb 2003 10:32:28 -0000
    From:        "D. J. Bernstein" <djb@cr.yp.to>
    Message-ID:  <20030214103228.71052.qmail@cr.yp.to>

  | This ``clarification'' document prohibits several perfectly legitimate,
  | very widely deployed, AXFR implementation techniques.

It prohibits some odd-ball techniques that risk future enhancements
(and generally clarifies the almost non-existant specification).

  | In particular,
  | this document violates RFC 2119, section 6, in five separate ways.

2119 is a list of words with definitions to save other RFCs from having
to define them over and over again.   It has some recommendations about
where the words should be used - but it is always up to the document in
question (the WG for a WG document) to decide which of those words should
be used in what circumstances (or to ignore 2119 completely if so inclined).
"Violating" 2119 is a nonsense concept.

  | Furthermore, the Yokohama minutes report a WG decision that axfr-clarify
  | is ``too bind specific''---too specific to BIND 9, to be precise.

That related to some of the language in the draft I believe (I was there,
and I think was one of those who supported this position).   Some of that
I still believe could be cleaned up to be nicer.   It doesn't relate to
any of the substance though, nor particularly to BIND 9, but rather to use
of terms like "slave" and "master" which are (recent) BIND inventions to
refer to what the DNS (1034/1035) has always used the words "secondary"
and "primary" for.   There's a bit more like that I think as well.  None
of it really matters, though the doc would be better if it was all fixed.

  | Despite this decision and these extensive objections, the WG chairs
  | declared ``consensus'' for axfr-clarify and sent it to the IESG.

I believe rough consensus exists on this one (it is rough, but there's
certainly much more support than opposition).

  | A review of all of the axfr-clarify discussions in the WG list archive
  | shows that this document is being pushed primarily by people who have
  | been paid for BIND work:

Even if this were true (and I don't believe it is - I have never been
paid for any BIND work) it is irrelevant.   It is not at all unusual
for a group of related people (sometimes all actually currently employed
by one organisation) to push a proposal.

  | Note that the users attacked by this document include BIND 8 users---who
  | are no longer represented in the WG by implementors, now that the BIND
  | implementors are pushing BIND 9. The document's proponents admit that
  | their ``clarification'' imposes rules disobeyed by BIND 8. My survey
  | http://cr.yp.to/surveys/dns1.html two months ago showed that 45% of all
  | .com names were served by BIND 8, while only 23% were served by BIND 9.

What has this to do with anything?   All that is being done here is to
tighten up the specification for how AXFR is supposed to be done.   That
old BIND code has bugs can hardly be news (even older BIND code had
millions of bugs).   Nothing proposed is going to cause failures of
any existing implementations, nor any current implementations to fail to
interoperate with any new implementations that follow this clarification.

The scare mongering about "huge redeployment costs" is utter nonsense,
no-one is being asked to redeploy anything.

All this document seeks to do is to get future AXFR implementations to
be a little tighter in what they do, so that some possible (even worse)
implementations bugs would have less bad effects than they might otherwise
have done.

The effect upon your implementation would be, that unless you alter
your implementation, you wouldn't be able to claim that it is conformant
with this new RFC (once it is issued of course).   That's it.   As you
seem to dislike AXFR as a zone transfer mechanism anyway (which is just
fine, it has never been required) I'm not sure why you'd care.

kre