Re: AXFR "clarify"

[Edward Lewis <Ed.Lewis@neustar.biz>]

At 15:50 +1100 1/18/08, Mark Andrews wrote:

> 	I said *allows* for innovation.  The current draft prevents
> 	innovation as it encodes forever a implementation bug,
> 	garbage message id's.
>
> 	There is nothing innovative about wanting to be able to
> 	check message id's of incoming AXFR streams and rejecting
> 	(or warning about) them if they don't match the AXFR's query
> 	id as default behaviour.
>
> 	Declaring nameservers that don't set the message id to that
> 	of the query as broken is a good thing.

You mention innovation and then give an example that is unrelated.

As far as innovation, what I want to avoid is any discussion of the 
use of the other sections of the message AXFR does not make use of 
now (like Authority).

When it comes to tightening up a requirement like you mention, I 
think that we need to hear from more implementers that such a change 
is desired.

> 	Actually it isn't.  The worst thing the IETF can do is produce
> 	wishy washy specification.

Which it already has done.  The worst next thing is to break the 
world we built on a bad foundation.

> 	The world's already changed and will continue to change.

Engineers love to believe that, but some elements don't change.  The 
DNS is nearing that point.

> 	Well if you don't want to take implementors experiences into
> 	account...
>
> 	People DO care about this.  I've got the bug reports to
> 	prove it.

This is the first I have heard of it.  Anyone else?  And in that 
vein, a soapbox moment:

I want to issue this challenge to the implementers on this list.  A 
lot is heard about ISC's BIND experience.  ISC has been energetic in 
contributing to the process.  But the volume of the contribution 
sometimes backfires, and one victim has been the axfr-clarify 
document.  To make a clarification, or an updated definition, have 
merit it needs to be based on a broad spectrum of implementation 
experiences.

The goal is not to declare, by default, the BIND way of doing DNS as 
a standard.  The goal is an interoperable definition.  The experience 
of BIND yields a wealth of information to us, and that's valuable 
input.  The question is how can the document benefit from the BIND 
reports without becoming BIND centric?  The answer is to have input 
and reactions from other implementations.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

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