Re: in support of axfr-clarify

[Mark.Andrews@isc.org]

> 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: Mark.Andrews@isc.org

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