Re: AXFR "clarify"

[Mark Andrews <Mark_Andrews@isc.org>]

> At 21:34 -0500 1/18/08, Brian Dickson wrote:
> >Edward Lewis wrote:
> 
> >>  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
> .
> >>
> >Such a change is desired.
> 
> Specifically, what change?  Before expecting that a change is going 
> to be made because it is suggested, keep in mind "it had better be a 
> gooood, really good change."
> 
> >Correct me if I'm wrong, but it doesn't matter what the deployed base
> >is, or the state of the software, or where or how it's used.
> 
> In my opinion, the deployed base rules in this case. I don't see any 
> consumer of DNS services (such as web site hosters, tld operators, 
> home hobbyists) howling that they cannot locate DNS implementations 
> that do AXFR.  In my opinion, and why I am motivated to do this, is 
> that it is the specification that is lacking.  Keep in mind my 
> concern is addressing RFPs and not writing a new implementation.
> 
> The IETF is all about interoperability and I don't hear that this is 
> lacking in the AXFR space.  That is why, to me, the current code base 
> rules.

	Really?  Users do notice the bugs in the AXFR implementations.
	The problem is that all of the *mostly* work.  It's only
	in specific cirumstances where they don't work.  By don't
	work I mean what's entered at one end of a AXFR/IXFR graph
	gets out the other end of a AXFR/IXFR graph.

	If you just have a single hop and don't have parent / child
	zones on the same servers it basically works for all
	implementations.  Once you go beyond that you start to see
	the interactions occuring which shouldn't be occuring.

> >Anyone doing any kind of implementation, for any purpose, of
> >RFC 1034/1035/1995/1996 has a chip in the game. Like me.
> >I vote for tightening up requirements.
> 
> I don't think this is a a point of contention but I want to set 
> expectations by at least revealing my interpretation of the 
> situation.  I am for tightening up the requirements in the sense that 
> they reflect reality.  I am not for raising the bar on functionality.
> 
> >In 1034/1035, the language is "should" (lower case). At a minimum it
> >should be "SHOULD", and preferably "MUST".
> >(The irony of the case comparison between "should" and "SHOULD" is not
> >lost on me.)
> 
> Updating the language is a good thing, as the IETF has evolved from 
> an engineering organization to a standards body over time.
> 
> >I see no reason that the language describing the behavior (recommending
> >against changing case on rdata) should be ignored, and the RFC text near tha
> t
> >language, even contemplates potential reasons for this.
> 
> I think the rationale for, and the case against, compression has 
> already been laid out in previous documents.  Compression isn't an 
> AXFR issue though, it's a general message processing issue.  Lip 
> service is all I would put towards it in the document.

	It the case for doing complession in a case sensitive manner
	vs a case insensitive manner.  Compress on its own is not
	bad it just has to be done correctly.

	Your comment above is a perfect example of why it needs to
	be in the document as you are missing the nuances of the
	issue.

> >Just like the data described in the protocols (like 822):
> >(IMHO) Maintainers of RFCs should be liberal in what they accept, and
> >strict in what they send.
> 
> I don't believe that.  What's true for code isn't true for prose. 
> The purpose of an RFC is to provide necessary and sufficient 
> information to allow multiple interoperable implementations.  That 
> doesn't mean liberal in what is accepted.  It means to be clear on 
> what has to be done and what is probably a pretty good idea unless 
> the situation is unusual.
> 
> >If you are updating an RFC, the worst thing you can do is weaken a
> >specification. In fact, it could/should be argued, that when the opportunity
> >to tighten up language *known* to be ambiguous, that it SHOULD be done.
> >RFCs do not get updated that often, and this RFC is rather important
> >to the health of the Internet.
> 
> There are two ways to read "worst thing you can do is weaken a 
> specification."  I am not for strengthening the AXFR mechanism in the 
> sense of making it more efficient, feature rich, etc.  But I am for 
> strengthening the definition so that it is clear what someone means 
> by saying "please provide AXFR access to the zone data."

	I don't think anyone has ask for more feature.  Just a tighting
	of the exisiting specification.
 
> What I am sensitive to is that the word "clarifications" has become a 
> lightening rod.  Clarifications to some mean just making the meaning 
> of the base clearer. To some clarifications can include extensions 
> that are assumed to have been in the original design.  And so some 
> clarifications can include feature creep.  Once a word has become a 
> lightening rid, I like to steer clear of it.
> 
> >Having case preserved specifically on XFR, is something much more important
> >than any normal query/answer data.
> 
> I don't think that it is as simple as that.
> 
> I can paint a scenario in which an "ordinary" response's mashing of 
> capitalization results in more stub resolvers getting "incorrectly" 
> capitalized answers than the mashing done in an zone transfer.
> 
> E.g., a lookup from a large consumer-serving ISP for a high-traffic 
> on-line retainer will cause a cache entry that will get jillions of 
> hits before it times out.  There are some TLDs that won't get even a 
> smidgen-of-a-jillion queries in the same time.

	People care about what their host is called.  In a reverse
	lookup there is almost zero probability that you will find
	the hostname ends in ARPA.  When you are transfering a
	reverse zone there is almost 100% probability that compression
	will be used on the PTR records.

	This results in individual queries no compression, case preserved.
	Axfr compression used case insensitively, case potentially not
	preserved.
	Axfr compression used case sensitively, case preserved.
 
> This is why I say it's not particular to AXFR.

	No one says it is.  But we don't want to wait for the document
	that clarifies compression to come out.  Document it as a issue
	here and now.
 
> And yes, I agree it is how you define and measure "importance."  In 
> the architectural hierarchy, AXFR comes before QUERY/RESPONSE.  But 
> in operations, QUERY/RESPONSE is always there, AXFR(and IXFR, NOTIFY) 
> is not.
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
> 
> Think glocally.  Act confused.
-- 
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/>