Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 21 Oct 2004 11:21:15 -0700

Ed Lewis writes:
> My motivation is not to do this for the sake of academic 
> protocol/architectural purity.  My motivation is to move the DNS into 
> position for future efforts (via having a pure protocol/architecture).

This is my motivation as well. But I believe I am starting from a 
considerably wider view of what that oppportunity is and how we
can best get there.

I am viewing the problem in terms of critical paths. If the DNSEXT
group insists on placing deployment on my critical path then I
am going to do everything I can to prevent their advice being
taken. I would hope that most people would understand why I am 
not going to allow IPv6 to be placed in my critical path. New
RRs fall in the same category. However much you like them they
do nothing for me and it is my community that has the pain points
and the industry consensus that are the ingredients of a killer 
app.

The document is a rather transparent attempt to try recourse to
authority. To play that game you should really understand what
your hand is. I don't claim to be the best engineer here. But
I am a whole lot more experienced at communicating with the 
people who have the decision power which is not the IESG or 
the IAB.

>Speaking from the experience of talking with the MARID group and also 
>from observing the behavior of one popular DNS implementation, 
>relying on a strategy of "try one, if it fails, try the other" is not 
>going to be well received.

Ed tried his best, but the agreement in the room for Ted's proposal
was on the understanding on the part of the implementors that it
would change nothing in practice. Nobody expected a significant
number of sites to use the new RR for at least ten years. And 
regardless of what the spec said nobody seriously intended to 
implement a serial scheme where the RR is tried first with 
fallback to TXT. At best the systems would do it in parallel.

If you think it terrible that people would ignore authority in
this way then ask yourself what was ever done to justify that
authority.

Dan Bernstein writes:
>We already have encouragement. I already quoted the relevant sections of
>RFC 1034 and RFC 1123. I wouldn't object to yet another document making
>crystal clear that BIND and NSD and Microsoft screwed up and that we
>really want to get rid of this problem before 2010.

Is that what people would consider a reasonable data for requiring 
servers to deploy new RR types?

I am not opposed to the use of new RR types, in fact there are some
proposals in that regard that I do want to make - XML resource records
for example.

Pekka writes:
>Unless we use it, nothing is going to change in the next 10 years.

So, that does not give you the right to tie your ornaments to my
Christmass tree. And that is the precise analogy I have been 
raising in the policy area.

>By the way, as it appears a lot of people are breaking DNS
>specifications pretty badly, I wonder if it would make sense to try to
>come up with some kind DNS implementation requirements document,
>similar to "host requirements" a long time ago, but updated with
>respect to new specs.. this would be a lot of work, but it might be
>worth it if we want to decrease the amount of completely broken DNS
>implementations out there.

I do not believe yet another document will do anything. What we
need is compliance testing. The failure of the IETF to address this
area is understandable, hey testing is what real engineers do, it
does not get you tenure. But that is what is needed in the real
world.

Paul writes:
> if new rr's take too long on deployment to be useful for new globally
> deployed services and service models to be practical, somebody had
> better tell microsoft that using SRV was a mistake.

Microsofts use is a bad example. Microsoft use SRV to configure windows
in an environment where Windows is the infrastructure. To take
advantage of the SRV all your infrastructure has to have been 
upgraded already.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Oct 2004 08:56:56 +1000

> advantage of the SRV all your infrastructure has to have been 

	Well lets look at another example AAAA.  The ends that
	wanted to use AAAA upgraded their servers and apart from a
	few load balancers, which also usually didn't handle SOA/NS/MX
	records, there were no major problems.  AAAA as we know
	required much more than just adding a new rdata type.

	AAAA deployment has also weeded out most of the bad servers
	so later deployment of new types should go smoother.

	I don't know about the other developers but BIND 9 is
	designed to allow for the easy addition of new RR types.
	Write a pair of files (.c,.h) that describe the wire and
	text formats, additional processing rules etc.  Recompile
	and you are done.

	IPSECKEY did just that to test out the new RR type.

	Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]