Re: AXFR "clarify"

[Mark Andrews <Mark_Andrews@isc.org>]

> At 13:52 +1100 1/18/08, Mark Andrews wrote:
> >	The first thing the WG has to decide is which document we
> >	are producing.
> >
> >	* a document that allows for future growth and removes
> >	  implementation quirks.
> >	  [Some implementations will not be conformant with the new
> >	   specification.  Known quirks should be documented but
> >	   should not be accepted by default.]
> 
> No!  I feel strongly that this is not what we want.
> 
> We don't need innovation in DNS now.

	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.

> It's good.  There's a lot of 
> work being done based on what it is, not what it may be.  I really 
> like it as it is - it has too much already even.
> 
> And the worst thing the IETF can do is declare working DNS 
> implementations (meaning they meet the needs of the application) 
> invalid because of nuances or the desire for feature bloat.

	Actually it isn't.  The worst thing the IETF can do is produce
	wishy washy specification.
 
> >			or
> >
> >	* a minimal change document which allows leaves all existing
> >	  implementations comformant.
> 
> That's what I want.  I prefer not to change the world, it's a paper 
> pushing exercise.

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

> >	I believe most of the issues are because Dan percieved the
> >	that the later was what was requested but the former was
> >	what was coming out.
> 
> I can see that.  I sympathize with both sides, but I somewhat agree 
> with what *I think* is Dan's side.  It's hard to say without talking 
> to him.
> 
> >	I believe we should be producing a document that allows for
> >	future growth and removes implementation quirks.
> 
> I don't.  And the folks that are asking us to be clear on AXFR 
> prioritize meeting the de jure understanding of AXFR.
> 
> >		---------------------------------------
> >
> >	One thing that is missing is case preservation of rdata
> >	when using compression.  This is a general requirement of
> >	DNS servers.
> >
> >	When using label compression the master server MUST choose
> >	compression targets that preserve the case of the original
> >	domain name.
> >
> >	In general, most servers are overly agressive when applying
> >	compression and do not met the spirit of RFC 103[45] when
> >	it comes to preserving case.  This applies in general not
> >	just AXFR.
> 
> Well, maybe a mention of an issue like this, but really, does it 
> matter?  E.g., the world cares more about IDN than capitalization. 
> I'm no longer really interested in maintaining the spirit of 1034 and 
> 1035 if it becomes an obstacle to getting a useful definition of DNS.

	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.

	Mark
-- 
Mark Andrews, ISC
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/>