Subject: Re: in support of axfr-clarify

From: [email-masked]
Date: Mon, 02 Dec 2002 14:13:09 +1100

> On Sat, 30 Nov 2002, Danny Mayer wrote:
> 
> > 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.
> 
> AXFR clearly needs clarification. The cheapest thing to do is clarify
> AXFR so as to minimize or eliminate changes to existing software, and to
> minimize the introduction of interoperability problems.

	Clarification should always be, firstly, to get the protocol
	to do what it is attempting to do.  After that if there are
	multiple ways to do something you look at the implementation
	costs.
 
> The "right" thing is to minimize costs, and not introduce unnecessary
> changes in AXFR.

	No. The right thing here is to ensure that AXFR transfers the zone
	to all servers in the AXFR transfer graph.

> No one has shown yet that the changes proposed are in
> fact necessary.  That is, they haven't shown that one can't implment IXFR
> with a more common implemented (but clarified) version of AXFR.
 
	It's quite easy to demonstrate the need for these changes and
	it has been done several times.

	As for IXFR over broken AXFR.  What is the correct behaviour of a
	IXFR client when it receives a delta which says to remove a record
	that doesn't exist due to merging of zone contents?

	Does it abort the IXFR and request a AXFR?
	Does it apply what it can and then transmit the changes to its
	copy of the zone.

	These questions don't even come up if the servers don't merge
	content from different sources.

> > >"Right" might not be the same as "Common". But changes from common aren't
> > >"clarifications".  "Right" depends on your point of view.
> >
> > It didn't mention the word common. I said right. Right is very rarely objec
> tive
> > anyway, so what's your point?
> 
> That is my point: You want to do the "right" thing from your point of
> view.  Others have different points of view. But I think the most common
> point of view of "right", is to minimize the impact and costs, and avoid
> unnecessary changes.
> 
> > >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.
> >
> > 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.
> 
> The current clarify document requires unnecessary changes, and imposes
> unnecessary costs, and interoperability problems in the field.
> 
> I would be willing to work on an alternative clarify document.
> 
> * I've re-ordered your email to separate some of the less relevant
> material and put it at the end.
> 
> > 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.
> 
> Bind made incompatible and non-standard changes. Its supporters are now
> trying to impose those changes on the rest of the community under the
> dishonest description of a "clarification".

	Please demonstate which changes are incompatible and
	non-standard.  

> Further, I think most sites are still running some version of Bind 8. For
> very little cost, ISC can remove the non-standard changes. The cost
> expended so far by Bind will have to be considered "research"  which
> didn't produce anything useful.  C'est la Vie.
> 
> > 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.
> 
> Nonsense.  Deployment costs imposed on the user community are part of the
> costs to be considered.  And I'm willing to concede for sake of argument
> (though perhaps DJB does not, and I have no authority to speak for him),
> that djbdns is also a commercial product, as are other implementations.
> 
> The users of Bind 8 will also be forced to upgrade.  As will users of
> Microsoft, etc.  Many operating system vendors ship Bind 8 variants. They
> (and their users) will be forced to upgrade.  In the meantime, unnecessary
> interoperability problems will persist.

	The operating system vendors are already shifting to BIND 9.  It's
	management is backwards compatible with BIND 8.

	Note there are no *forced* upgrades happening here.  The pre-clarify
	servers will interoperate with the post-clarify servers.  However
	the post-clarify servers can be used in configurations where most
	of the pre-clarify servers (those that merge data) can't.

	Mark
 
> This is a very expensive operation, and it is unnecessarilly expensive.
> 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
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: Tue, 03 Dec 2002 11:40:30 -0500

"D. J. Bernstein" wrote:

> [ 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! ]
>
> Kevin Darcy writes:
> > You're only reinforcing the need for a Clarify draft.
>
> I've been saying for years that the DNS specifications are horribly
> inadequate. I thought axfr-clarify sounded like a great idea until I
> read the document and discovered twelve problems. Two of those problems
> have now been fixed; ten more to go.
>
> > an implicit assumption -- that non-Answer sections of an AXFR response
> > would never be used productively -- which turned out to be false
> > because of things like EDNS0 and TSIG.
>
> These issues have been discussed before. First, contrary to your claim,
> there is no evidence of an actual problem. Second, and more importantly,
> if an optional protocol extension fails to ensure compatibility with the
> previous protocol, that is entirely the extension's fault.

Well, no, not really. My understanding is that any protocol extension may
alter the base protocol as long as the extension itself is on Standards
Track. In this case, it's rather a moot point anyway, since AXFR was
underspecified originally (we all agreed on that, right?), so it's not clear
whether TSIG, EDNS0, etc. actually broke anything vis-a-vis their potential
applicability to AXFR transactions. You can't "break" something that wasn't
specified in the first place.

> As I wrote when we last discussed this in July 2001, after you asked why
> I wasn't changing my code:
>
>    The benefits are nonexistent. The harms include encouraging further
>    disregard for compatibility. What stops incompetent implementors from
>    demanding another code change every week? Ignore AXFR AR, discard
>    TKEY, ignore types 128-255, recognize IXFR, ignore MS garbage. This
>    is not a sane way to handle optional protocol extensions.
>
> Is compatibility such a difficult concept to grasp?

Just because you don't find any use for TSIG, EDNS0,  doesn't mean that
other people don't. Yes, I find compatibility-as-a-concept easy to grasp,
but what I fail to understand is why you think *your* compatibility trumps
everyone else's. I want to (and do) use TSIG-signed zone transfers. Do you
think this is or should be a "proprietary" mechanism? As your code stands
today, would it break your AXFR client to receive one? axfr-clarify confers
the blessing of IETF standards on TSIG-signed zone transfers, among other
extensions, while at the same time ensuring that implementations which don't
understand or don't support these extensions aren't hurt if some day they
receive one. And the only cost we (collectively) pay for these benefits is
that *one* implementation (yours) has to make a relatively small code change
that didn't demonstrably help anyone in the first place.

- Kevin