Subject: Re: in support of axfr-clarify

From: Greg Hudson <[email-masked]>
Date: 27 Nov 2002 16:48:06 -0500

On Wed, 2002-11-27 at 16:32, Dean Anderson wrote:
> 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".

Would it really make any of you happier if the title were changed from
"clarifications" to "revisions" and the introductory text modified
accordingly?  (If so, I'm all for it.)

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

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 27 Nov 2002 17:21:54 -0500

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.

> 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

---

From: Dean Anderson <[email-masked]>
Date: Wed, 27 Nov 2002 17:52:11 -0500 (EST)

It would make the standards transaction more intellectually honest.

But I still think the changes are dubious.  I assert that the AXFR
protocol and semantics should not need to be changed in order to do IXFR.
Changes to the AXFR semantics seems to imply changes to RFC1035, and
affects backward compatibility.  I think tampering with AXFR is risky, and
not well understood.

However, I haven't looked into the Bind 9 IXFR modifications enough to
know exactly why AXFR changes are really necessary, or if indeed they are
really necessary or just a convenient hack to make IXFR work in Bind.

I think I would rather change IXFR to make it work without changes to
AXFR.

So I still wouldn't be for it.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Wed, 27 Nov 2002 18:16:12 -0500 (EST)

> accommodates the idiosyncratic behavior of every AXFR implementation out there.

I agree with this statement. But we aren't talking about a lot of
idiosyncratic behavior. We are talking about behavior shared by numerous
nameservers, and now significantly changed by Bind 9.  So far as I know,
_only_ Bind 9 has this change.

A clarification should define the common way its done, the way it was
reasonably and commonly understood by readers the original document.

> I dispute that the changes are "gratuitous", that BIND is "a commercial product"

Vixie asserts a trademark on "BIND". Though I'm not convinced its really
valid, since it was in the public domain by UCB.  Trademarks are only
valid if used in commerce. .: Bind is a commercial product.

I guess "gratuitous" is rather vague. I should say that I think IXFR
should be changed instead of AXFR, and that I'm not convinced that any
protocol/semantic changes are really necessary to make this work. Rather
than accept these changes to AXFR, I think the implementors should give it
more thought.

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

Appearances of impropriety weigh just as heavily as actual impropriety.

		--Dean

---

From: [email-masked]
Date: Thu, 28 Nov 2002 11:30:34 +1100

> So I still wouldn't be for it.

	The rules are required for basic AXFR to work regardless of
	IXFR.

	Take the following senario.

	A is the primary master for example.net.
	B is the primary master for child.example.net.
	C is a server for example.net and child.example.net.
	D is a server for example.net that uses C as a master.

	A and B both change the NS RRset for child.example.net.
	The NOTIFY from B is lost so the update relies on refresh.
	C transfers example.net.  C replaces the NS RRset with that
	from child.example.net.
	C notifies D that it has a new version of example.net.
	D transfers example.net from C.
	C performs a refresh query for child.example.net and transfers it.

	You now have:

	A with the NEW NS RRset for child.example.net.
	B with the NEW NS RRset for child.example.net.
	C with the NEW NS RRset for child.example.net.
	D with the OLD NS RRset for child.example.net.

	This is why you MUST preserve zone contents with AXFR.

	Mark

--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 27 Nov 2002 17:13:10 -0800 (PST)

> protocol and semantics should not need to be changed in order to do IXFR.

These are not protocol changes.  The one and only protocol change
specified by the draft is that of marking the end of a transfer by
sending the SOA rather than the apex node, since the former is what
every implementation does.  Everything else in the draft is specifying
things that were previously left unspecified.

> I think tampering with AXFR is risky, and not well understood.

I belive I have a pretty good understanding of AXFR after implementing
it in four different name servers for three different companies and
reapeatedly having to deal with the consequences of the
underspecification in RFC1034/1035.  I find that it is far more risky
to leave the protocol as vague as it is than to specify it in detail.

As for "tampering", you might as well say that this whole IETF thing
is a bad idea - after all, tampering with the Internet is risky and
not well understood.
--
Andreas Gustafsson, [email-masked]

---

From: Danny Mayer <[email-masked]>
Date: Wed, 27 Nov 2002 22:57:48 -0500

>reasonably and commonly understood by readers the original document.

Right. However, if the original document is unclear then different
implementors will have implemented differently, resulting in interoperatibility
problems. By clarifying you necessarily make some of those implementations
non-compliant. You can't clarify without breaking something.

>valid if used in commerce. .: Bind is a commercial product.

That's an untrue statement. You can trademark anything without it being
a commercial product. I don't know if Paul has made any trademark claim
with repect to BIND, though it would be on behalf of ISC.

>than accept these changes to AXFR, I think the implementors should give it

You can't do IXFR unless AXFR is clear and unambiguous. Incremental
makes no sense without that. Are you going to negotiate the type of data
to be sent based on everyone else's different interpretation of the spec?

Danny

---

From: "D. J. Bernstein" <[email-masked]>
Date: 28 Nov 2002 10:21:07 -0000

[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  your subscription address is
  [email-masked], please post from it or
  fix subscription your subscription address! ]

> This is why you MUST preserve zone contents with AXFR.

No. If a screwy configuration causes problems with the deployed AXFR
protocol, the solution is to outlaw the configuration, not to demand
that the entire universe deploy new software.

Is interoperability such a difficult concept to grasp? If you want a new
protocol, use a new query type. Using the existing AXFR type is clearly
malicious: you're trying to hurt other implementors and users.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: "D. J. Bernstein" <[email-masked]>
Date: 28 Nov 2002 11:04:29 -0000

Kevin Darcy writes:
> incanting "but it won't interoperate with my implementation!" as if
> it were some sort of religious mantra

Interoperability is incredibly important in the real world. You have no
right to go creating interoperability problems where none exist today.

> 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.

That's absurd. In fact, many future implementors would benefit from an
accurate specification of the existing AXFR protocol. This does _not_
mean screwing up interoperability. It does _not_ mean documenting
irrelevant BIND 9 implementation details as if they were the protocol.

> (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).

When did I ever say that local protocols aren't protocols? What I'm
saying is that unauthorized users like you have no right to demand a
response---or even to try to participate in the protocol in the first
place. The protocol is for authorized users.

> 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

No, the specifications don't say that. Servers can say REFUSED if they
want to, but there's no rule saying that they have to.

> the Authority and Additional sections are reserved for
> specific purposes (e.g. referrals, glue, OPTs, TSIGs etc.)

AXFR responses include glue, remember? A server implementor who doesn't
investigate existing practice could reasonably interpret RFC 1034 as
_requiring_ use of the additional section. That would, in turn, cause
failures with careless clients that don't look at the additional section.

I support requiring the careful server behavior. I object to prohibiting
the careful client behavior.

Analogy that I pointed out last year: RFC 2821 clearly prohibits SMTP
clients from sending non-ASCII header bytes, but clearly allows SMTP
servers to accept those bytes.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 28 Nov 2002 11:26:20 -0000

BIND company employee Danny Mayer writes:
> You can't clarify without breaking something.

That's absurd.

Right now, because the specifications are unclear, implementors have to
spend a lot of time investigating how the protocol actually works. Most
of us have been very careful about this; consequently, there have been
very few AXFR interoperability problems. (The ``non-glue records'' bug
introduced in BIND 8.2.3 is an exception.)

We can save tons of time for future implementors, and reduce the chance
of future interoperability problems, by clarifying the existing AXFR
protocol. This need not, and should not, break anything.

If there were a current interoperability problem between two deployed
pieces of software, and if both implementors claimed to be right, then
we'd have to resolve the conflict one way or another, after evaluating
the costs of each approach. But that's not the situation here. You're
wrong when you suggest that all differences between implementations are
interoperability problems.

> can't do IXFR

So fix IXFR. Stop demanding that _my_ users pay to make _your_ silly
protocol extensions work. Compatibility is not rocket science.

> You can trademark anything without it being a commercial product.

An applicant for a trademark must declare that he is using, or intends to
use, the mark in commerce. See 37 C.F.R. 2.33.

---

From: Danny Mayer <[email-masked]>
Date: Fri, 29 Nov 2002 20:05:08 -0500

>BIND company employee Danny Mayer writes:

I am not and never have been an employee of either ISC or Nominum.

> > You can't clarify without breaking something.

No, it's reality.  You wouldn't need to clarify if the RFC weren't ambiguous.
Since it's ambiguous, people have made different interpretations of the
spec resulting in compatibility problems. So the clarification means that
someone's interpretation be noncompliant with the draft. Right now
that means yours will be noncompliant. Maybe others too.

>protocol. This need not, and should not, break anything.

If the spec is unclear there are bound to be people not implementing
the same way as everyone else.

>interoperability problems.

No, the cost is not relevant. What is relevant is doing it right so
there are no future problems and any future extensions will be
implementable in some reasonable fashion.  The only question being
addressed here is what is the meaning of "right"?

>protocol extensions work. Compatibility is not rocket science.

You can't fix IXFR if AXFR is not nailed down.

>use, the mark in commerce. See 37 C.F.R. 2.33.

Your statement does not include the word sell, for profit or otherwise.
There are many non-profits in the US that have trademarks. You also
seem to be restricting yourself to the US. Are you saying that ISC
cannot trademark the name whereever they please?

Danny

---

From: Dean Anderson <[email-masked]>
Date: Sat, 30 Nov 2002 01:34:11 -0500 (EST)

> No, the cost is not relevant.

I think this is absurd, and irresponsible. Cost and effects on
interoperability are always issues to be seriously considered.

> What is relevant is doing it right so

"Right" might not be the same as "Common". But changes from common aren't
"clarifications".  "Right" depends on your point of view.

> You can't fix IXFR if AXFR is not nailed down.

I'm OK with that. However, AXFR should be nailed down in ways that
correspond to how people reasonably interpreted the vague spec. The
clarification should be done so as to minimize the breakage to existing
implementations.

I think that AXFR can be nailed down without severely impacting existing
implementations, and I expect that IXFR can be made to work with the
existing (and clarified) AXFR.

> cannot trademark the name whereever they please?

This says nothing of the sort.

Non-profit is not the same as "non-commercial". The ISC uses names in
commerce: it seeks donations, owns property, hires employees, and (if I
recall, either offers either support or directions to Vixies consulting
operations), and promotes the Bind, Inn, and DCHPD packages.

ISC claims (rightly or wrongly) a trademark on Bind. That indicates that
it intends to use "Bind"  in commerce.  Whether it makes a profit or not
is irrelevant.  Bind is a product of ISC.

Whether that trademark claim is invalid (by prior public domain use by
UCB), is irrelevant.  Once ISC makes a declaration of a trademark, it
can't later say the "product" is not commercial.

		--Dean

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Nov 2002 04:27:03 -0000

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  your subscription address is
  [email-masked], please post from it or, if you
  wish to regularly post from an address that is not subscribed to this
  mailing list, send a message to [email-masked] and ask to
  have the alternate address added to the list of addresses from which
  submissions are automatically accepted. ]

Mayer claimed ``You can't clarify without breaking something.'' Is there
anyone else here who doesn't understand how ridiculous that claim is?

> I am not and never have been an employee of either ISC or Nominum.

I apologize for the error. The fact remains that you're not disclosing
your financial interests in BIND.

> Since it's ambiguous, people have made different interpretations of
> the spec resulting in compatibility problems.

A typical implementation difference---whether or not it is caused by
different interpretations of the spec---does _not_ cause any failures.

For example, some AXFR servers insert glue records everywhere they're
used, while some AXFR servers insert each glue record exactly once.
AXFR clients can handle either approach. There are no failures here.

Explaining that servers can repeat records, and requiring clients to
handle repetitions, would be a clarification of the protocol. It would
not cause any failures. It would save time for future implementors, and
reduce the chance of careless implementors screwing up.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Nov 2002 19:17:31 -0000

> accordingly?  (If so, I'm all for it.)

Everybody agrees that a clarification would be useful. This document is
fraudulently posing as a clarification, and perhaps fooling some people
into supporting it for that reason.

Example: In his (false) declarations of consensus in March 2001 and June
2001, Gudmundsson claimed that this document ``formalizes the zone
transfer protocol in accordance with the fielded DNS server software.''
Sounds great, doesn't it? The problem is that it simply isn't true.

If you're asking whether dishonesty is acceptable, the answer is no. If
you're asking whether dishonesty is the only problem with axfr-clarify,
the answer is no. See http://cr.yp.to/djbdns/axfr-clarify.html.

---

From: Danny Mayer <[email-masked]>
Date: Sat, 30 Nov 2002 19:28:47 -0500

>interoperability are always issues to be seriously considered.

The cheapest thing would be to do nothing. It is, however, not the right
thing to do. Figure out the right thing first and then you can take a
realistic view of the costs.

>"clarifications".  "Right" depends on your point of view.

It didn't mention the word common. I said right. Right is very rarely objective
anyway, so what's your point?

>existing (and clarified) AXFR.

That's what the document is trying to do. So far nothing that you said
discusses the document, just how "unfair" it is to djbdns.

>can't later say the "product" is not commercial.

Assuming that you are in the US, you know nothing about UCC. I suggest
an introductory course in the Uniform Commercial Code before you discuss
this so knowledgably. Please point me to a site that is selling BIND on
behalf of ISC.

Of course, it is relevant to point out that if BIND were a commercial product
it would cost more, in real money, to have it changed than for djbdns to be
changed. Since djbdns is apparently a non-commercial product and noone
is employed to make changes or fixes to it, it costs nothing to change and
we have therefore chosen the cheapest alternative.

Danny