[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AXFR "clarify"
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.
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 that
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.
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."
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.
This is why I say it's not particular to AXFR.
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.
--
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/>