Re: in support of axfr-clarify

[Kevin Darcy <kcd@daimlerchrysler.com>]

Dean Anderson wrote:

> I would note that the "de facto rules" are defined by the "de
> facto" implementations, which is not Bind 9.

Well, when I said "_de_facto_ rules" I was referring not only to a mere survey of
what extant AXFR implementations do, but also the rules followed generally for
query/response transactions within DNS. AXFR is, after all, a query/response
transaction, albeit a somewhat "special" kind. The general rules say that data
answering a DNS query goes into the Answer section (along with possibly CNAMEs
and DNSSEC goop), and the Authority and Additional sections are reserved for
specific purposes (e.g. referrals, glue, OPTs, TSIGs etc.), none of which really
apply to "classic" unsigned AXFR responses. The general rules also say that if a
server declines to answer a query for some administratively-defined reason, it
sends back an approriate RCODE, rather than just dropping the connection (as
DJB's server apparently does, because he considers AXFR client/server
transactions to be "local matter[s]" rather than something to be governed by
protocol, go figure).

> While there could be reasons to change something, that isn't what
> "clarify" means.  "Clarify" is where you document what was _done_ when the
> specifications were vague.
>

No, the purpose of clarifying AXFR is not to spread a "big tent" that
accommodates the idiosyncratic behavior of every AXFR implementation out there.
Such a specification, if it is possible at all, would be so watered down it would
be useless. The purpose of clarifying AXFR is to bring it into the mainstream of
DNS as a whole, and to allow future implementations to be based on a common
understanding of how AXFR works, and therefore be able to interoperate with a
minimum of hassle. If this means DJB actually has to touch some of his existing
code to make it conformant to the clarified spec, then them's the breaks. He
shouldn't have taken such liberties in the first place. It is exactly
*because* there was a divergence in AXFR implementations (with older
BIND versions being among the prime offenders) that the clarifications were
deemed necessary. A "clarification" that merely documented the incompatibilities
between different implementations would have been pointless: the IETF is not a
historical society, merely documenting the mistakes of the past; it is supposed
to lead into the future. Also, I'll add that every Tom, Dick and Harriet who
decides to implement a poorly-specified IETF protocol doesn't thereby get veto
power over any future clarification of that protocol, simply by incanting "but it
won't interoperate with my implementation!" as if it were some sort of religious
mantra. That's no way to set forward-looking standards.

> It seems highly inappropriate to make seemingly gratiutous changes in a
> particular commercial product, begin distributing those changes to users,
> and then attempt to change the standards to reflect the changes, and
> describing those changes as a "clarification".

I dispute that the changes are "gratuitous", that BIND is "a commercial product"
(yes, it is used *in* some commercial products, but that's not the same thing),
and, finally, that the standards are actually being changed here.

> This seems more like behind the scenes dirty tricks.
>

Yeah, it's all a big conspiracy. Sheesh.


- Kevin



--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>