Ted's proposal gets each party what they really want.
Meng and microsoft get the ability to immediately deploy marid without
waiting for deployment of the extensions handling capability.
The dnsext group get an application to drive deployment of infrastructure
that is extensible.
Note well the fact that nobody needs anyone to ever use the record created
to achieve their core objective.
Nobody in the txt record camp is opposed to the idea of improving
extensibility in dns. The only thing that is objected to is having dnsext
put in our critical path. If dnsext was deployable we would have seen a
presentaion intended to convince us of that, the figure for deployment I was
given was 65% and tha does not come remotely close to an acceptable level
for me.
That does not mean we do not make a good faith effort to help solve the
deployment of dnsext. None of us want to meet this issue again and again. In
fact we have a pretty good set of use issues to deal with that should be
captured and fed back. There is still a wildcard issue to be addressed for
srv. I think that can be solved.
I don't think even bob objects to fixing the windows apis in future releases
of windows, sorry can't read the full thread on the rim. In fact i'll bet he
would love to get them fixed for the future, just don't ask him for
something he can't deliver.
I bet we can get microsoft to deploy a utf8 or xml record.
-----Original Message-----
From: Ted Hardie [mailto:hardie(_at_)qualcomm(_dot_)com]
Sent: Fri May 21 12:09:57 2004
To: Bob Atkinson; Margaret Olson; Arnt Gulbrandsen
Cc: Michael Richardson; ietf-mxcomp(_at_)imc(_dot_)org; Alan T. DeKok
Subject: RE: "Bob Atkinson": RE: suggested new RRtype experiment
At 10:26 AM -0700 05/21/2004, Bob Atkinson wrote:
A serious concern I have with the above is its testability.
With this approach we'd be asking people to code to an eventuality that
won't show up for years. Query for a new RR type first, and if not
there, query for TXT: the first case will virtually never hit for years
and years to come.
I think this is seriously overstated. There will, no doubt, be available
domains with MARID RRs as soon as the type code has been assigned;
you've seen from the test scenarios posted that some sites have
no problems creating arbitrary RRs and populating their zones
with them. Those zones may not exercise all of the available
functions in a converged spec, but that can be tested separately.
A much more serious concern would be chaining--where there was
a requirement to test for MARID, then test for TXT RRs. As was
discussed in the meeting, this can be optimized such that the
queries are issued simultaneously with preference given to the
data in the MARID RRs returned. There are a small number of cases in
which a lost or delayed response means someone might start
processing based on the TXT response and then receive a
MARID response; I think those can be resolved (proceed with
the current based on TXT, for example, but cache MARID) and I don't
see it as a show-stopper.
And there's a real cost to asking people to code to this: basically
double the DNS query cost for the foreseeable future. And the benefit to
be gained from paying this cost is what, architectural purity?
There are several. As was discussed yesterday, a new RR could allow
UTF-8, where TXT is limited to US-ASCII according to RFC 1464; that
would make it easier deal with XML (since some other part of the
process would not have to enforce and mark the XML as US-ASCII).
TXT remains a common target of enterprise records, and avoiding
it means you will have less risk of packet overflow when inside
firewalls (Wayne's data yesterday pointed out that this was not
usually a problem with externally-facing authoritative resolvers,
but those are also not "behind firewalls" in the way the RPC-limited
ones described here are).
Perhaps most important is the opportunity to move beyond a tweak
to an architectural change. Frankly, before the unknown RRs RFC
the situation in the deployed DNS wasn't that different from that
in the Microsoft environment--you had to be sure that all of the
resolvers that might *potentially* be in the path between a query
and the authoritative server were upgraded before you could use
a new type. Fixing that means that new types are not limited by
the DNS itself, they are limited by configuration and OS issues
that are part of the larger environment. By fixing those (even
with a time horizon of five years), you open things up to improvement
at a much more rapid pace later. That will help when the thing
that comes after NSEC or MARID comes along.
Looking back, I find that virtually all my professional life I have been
dealing with extensible and dynamically versioned systems, from OLE/COM
through many other things. And one thing I've learned if I've learned
anything is that, as much as I would wish it were otherwise, if it ain't
tested it doesn't work.
Again, the testability problem is probably smaller than you fear; there
will be records you can test against. Given I administer my own domain, I
am pretty sure I can guarantee it :).
The point that Ed was making yesterday is similar, though, and bears
repeating. Sub-typing has to be built in from the beginning; coming
back to something that is defined as unstructured and trying to introduce
sub-typing has a world of problems--we've seen it with TXT, with
KEY, and with lots of other systems. We can do if we're pressed, but
we need to do it knowing it's a workaround, not as the long term
basis of a new part of the infrastructure.
Note that we're talking about adding 2821.Fred to the mail system too,
rather than re-purposing something like 2821.MAIL-FROM; that
decision is based on exactly the same kind of reasoning--we need this
new piece of infrastructure, and we need to get it deployed in a way that
neither breaks existing use nor limits what we want in the long term.
And again, we have a transition--use 2821.Fred as soon as it is
available, but "grovel through" the 2822 headers until it is. As Jim
put it yesterday--that's the way to get this done quickly while
leading us to a place where we can do it well.
But at least it's not fatally flawed, only misguided.
Bob
Thank heavens for small favors!
regards,
Ted Hardie