BIND company employee Mark Andrews writes: > No one is trying to force a incompatabile extension on anyone. You are demanding a rule whose only purpose is to support incompatible extensions. _You_ are trying to impose costs on _my_ users so that _you_ don't have to bother preserving backwards compatibility in _your_ stupid protocol extensions. Furthermore, adding insult to injury, you're trying to sneak this protocol change through as a ``clarification.'' You didn't answer my question: How would you like it if Microsoft wrote an RFC on some incompatible protocol extension, hid the interoperability problems until the RFC was published as an elective Proposed Standard, and then demanded that every BIND installation be ``upgraded'' to deal with the junk produced by that protocol extension? How do you think your users would like it? If you want to break compatibility with a deployed protocol, you have to admit the massive costs of changing software around the Internet, and demonstrate benefits that are even more massive. Saying something like We'd like to offer people a pointless, clumsy, ad-hoc reinvention of IPSEC, and we realize that there's no need to break compatibility to do this, and our implementation in fact follows a rule that ensures compatibility, but we didn't put this rule into the spec because it's against company policy to think through compatibility issues, and now instead of fixing the spec we're demanding that other people upgrade their software doesn't cut it. What's particularly amazing about your ``axfr-clarify'' document is that you admit that it imposes rules violated by BIND 8. How can you possibly claim that this is necessary for interoperability? > There is nothing incompatable with saying that servers built > from this time on MUST NOT treat records in the authority > and additional sections as part of the results of AXFR. 1. Please stop viewing the entire world through a BIND lens. Don't say ``server'' if you mean ``AXFR client.'' 2. When you use a phrase like ``in future implementations,'' you're admitting that you're violating RFC 2119, section 6. There is no valid excuse for a protocol to refer to software creation dates. 3. It's content-free to say that an extra requirement doesn't create a compatibility problem. What I'm talking about are compatibility problems created by protocol extensions that don't work correctly with unextended protocol implementations. ---D. J. Bernstein, Associate Professor, Department of Mathematics, Statistics, and Computer Science, University of Illinois at Chicago