On Fri, 14 Feb 2003, Andreas Gustafsson wrote: > Dean Anderson writes: > > 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). > > This is not a "change". There are no existing standards which mandate > or even explicitly allow mixing of data between zones. On the > contrary, RFC1035 specifically suggests using separate data structures > that ensure that no such mixing occurs: The key word is "suggests", which has the meaning... > Which one is more "oddball", a server which follows this suggestion or > one which does not? Neither. It doesn't matter what the implementation is. What matters is the protocol. Despite the "suggestion", all implementations prior to Bind 9 made different (but ultimately identical) assumptions. I don't think the section you quote is so compelling. The "oddball" part is requiring a change to a irrelevant part of a protocol. This is nothing less than bad or lazy engineering.** As I mentioned previously, IXFR is in principle no different from an Oracle incremental replication. Clearly, one does not need to alter SQL to have replicated databases. One _could_ alter SQL, but it would be a "bad idea". The concepts of replicated databases, and different kinds of replication is well researched, and well documented. There isn't any rocket science to IXFR, nor are there any theoretical papers to be written on the subject. The AXFR protocol does not _need_ to be changed for IXFR. IXFR can be made to work with AXFR the way it stands. ** a collection of good engineering principles: A "good" engineer avoids making gratiutous changes. A "good" engineer, thinking a significant change to a standard of interoperability needs to be made, will seek consensus from the standards body on the change before distributing it. A "good" engineer, upon finding a language ambiguity or vagueness, would investigate how others analyzed the language, what assumptions they made about the ambiguity and follow accordingly, or discuss and resolve the ambiguity if there are no concrete implementations. A "good" engineer, realizing an incompatible change has to be made to a standard of interoperabilty, would consult the standards body prior to publishing a (non-interoperable) book on the subject. A "good" manager, would ensure that engineers are making "good" engineering decisions. Pretty clearly, the Bind 9 group didn't exercise "good" engineering principles, nor "good" engineering management. Quite obviously, they made a mistake altering and distributing AXFR prior to standardization, or by exploiting the vagueness in the specification. Clearly, they knew about the incompatibility issue. One must wonder if anyone could be so arrogant as to assume that they could push anything they pleased through the standardization process. We probably can't know the answer. I don't know anything about their intentions and can only fairly judge the results of their actions. However, there is much to criticize about the actions. I do not think I am being unfair in that criticism. I also realize that Bind 9 was a group effort, and there is blame to spread among many. However, I do not want to pay for that mistake. Nor do others. > > 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. > > BIND 9 is compliant with the existing AXFR standard even without > axfr-clarify. It's not hard to comply since the existing the > specification is almost nonexistent. No. This isn't true either. If we clarify AXFR to standardize the _assumptions_ identically and concretely made by many implementors over a long period of time, then BIND 9 will not be compliant**. Bind 9 is "compliant" only with the vague AXFR spec by invirtue of its vagueness. AXFR should be clarified. I (and others) think it should be clarified to follow the concrete assumptions made by many implementors over many years. This will only make BIND 9 non-compliant. Then 23% of the servers will have to change. 77% will be unaffected. **Actually, it might not even be this bad, as I think there are some "backwards compatibility" functionality that current Bind 9 users can utilize. So perhaps no servers need changing if we standardize AXFR as I propose. Except that Bind 9 will have to withdraw IXFR support until it fixes it to work with AXFR as clarified, or make it synonomous with AXFR. > > It seems quite odd that a "clarification" would put 77% of the existing > > servers out of compliance, > > 77% of the existing servers do not reliably interoperate in IXFR (even > with one another), and sometimes serve data inconsistent between the > authoritative servers of a zone. They *should* be declared out of > compliance. No, because IXFR support is essentially optional. An IXFR server can return the whole zone (AXFR) if it doesn't support IXFR. A server can be compliant with RFC 1995 just by making IXFR a synonym for AXFR. That's probably a one line change for most if not all implementations. Further, most people are not using IXFR. AXFR is not optional. Most people are using AXFR. > > and only brings into compliance a currently > > non-compliant implementation. > > Again, BIND 9 is currently compliant. Bind 9 won't be compliant (modulo its "backward compatibilty") after clarification of AXFR to specify the commonly assumed and commonly implemented behavior for AXFR. > > Consensus on the part of Bind proponents, yes. Consensus when the wider > > community is counted, no. > I have been reluctant to bring up this issue because because it should > make no difference whatsoever - the draft should be judged solely on > its technical merits, not based on the affiliations of its proponents, > but the groundless accusations of misconduct and conspiracy theories > by you and Dr. Bernstein have gone too far. I have made no allegations. My position on the issue of "conspiracy and misconduct" is that allegations made against Dr. Bernstein need to be investigated, and the allegations made by Dr. Bernstein also need to investigated. I think the allegations made by both sides are sufficiently specific that a determination can be made as to their truth. There are many on the djbdiscuss list who seem to think the issue deserves investigation. (I will try to get back to that matter next week, and work with others to come to a conclusion about which accusations were credible and which accusations weren't.) Clearly, some of the allegations made go way too far. --Dean
