On Fri, 14 Feb 2003, Robert Elz wrote:
Date: 14 Feb 2003 10:32:28 -0000
From: "D. J. Bernstein" <djb(_at_)cr(_dot_)yp(_dot_)to>
Message-ID:
<20030214103228(_dot_)71052(_dot_)qmail(_at_)cr(_dot_)yp(_dot_)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).
I don't think they can be dismissed so easilly. Indeed, I think the
proposed changes are rather "oddball", and are actually unncessary in
order to implement IXFR (which was the original claimed justification).
Indeed, the proposed changes are only necessary to justify BINDs' oddball
IXFR changes. They are only necessary to make BIND 9 compliant with the
RFC's.
It seems quite odd that a "clarification" would put 77% of the existing
servers out of compliance, and only brings into compliance a currently
non-compliant implementation. I think it is unprecedented in the history
of any standards organization, not just the IETF. Such a significant
change is clearly a completely new version. Thus the widespread
complaints about fraudulent labeling and discription of the proposal.
** 45% Bind 8
** 23% Bind 9
** 77% are not bind 9, and will not be compliant after this
"clarification"
This is not the way to run a railroad. (or rather, it is a railroading of
the changes through the process...)
| 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).
Consensus on the part of Bind proponents, yes. Consensus when the wider
community is counted, no.
| 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.
Of course not. It happens frequently in consortia. However, a "bloc"
behind a single vendor is usually counted as such. Its not unheard of for
a vendor to try to create an appearance of widespread support using
subcontactors, when in fact there is none. When that happens, people cry
"foul". We are crying "foul" now.
| 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.
We have hashed this through many, many times, I fail to see how you can
still make this claim with a straight face. It certainly will cause
failures: It will cause all non-bind 9implementations to be non-compliant
(or 77% of the servers).
The scare mongering about "huge redeployment costs" is utter nonsense,
no-one is being asked to redeploy anything.
Asked? No. It is demanded. This is a change to a standard, and to be
compliant demands conformance to the standard, and thus change, and
redeployment.
Perhaps unfortunately, the IETF has no branding program. However, we still
have interoperability testing to determine compliance with the standard.
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.
Clarification is a worthy goal. No one is opposed to clarification.
However, the changes proposed go in the wrong direction, and are motivated
purely by a crufty IXFR implementation in Bind 9. Many people have
indicated that the correct approch to clarification is to look at what
Bind8 and _OTHER IMPLEMENTATIONS_ did.
Since BIND9 is described in an Oreily book, this could be a difficult for
them. However, they should have thought about that before publishing a
book describing non-conforming implmentation as though it was standards
compliant. They created their own mess, and now want 77% of the world to
fix it for them. Talk about the shifting of costs to someone else...
The Bind9 people claim the changes are necessary to support IXFR. Of
course these changes aren't necessary. IXFR is in principle no different
than database transaction log processing. It has no bearing whatsoever on
AXFR any more than Oracle incremental replication has bearing on the
Oracle query protocol. They made changes to AXFR to make their crufty
IXFR implementation work, because they are bad engineers. They exercised
even worse judgement by publishing a book on their implementation prior to
standardization. Now they want the 77% of the world to jump through hoops
to make their oddball, badly engineered work "standard".
I'm not buying it.
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.
That's huge. And its not _only_ djbdns.
--Dean