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

From: Paul Vixie <[email-masked]>
Date: Wed, 20 Oct 2004 13:29:56 +0000

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.

(and, note: we've cut the time down by a lot since then.)

--
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: Paul Vixie <[email-masked]>
Date: Thu, 28 Oct 2004 15:19:48 +0000

> > side note: i don't agree with alex that any of this touches on opt-in.
> 
> I'm not going to die in a ditch over it. My main point is that opt-in
> is in the requirements matrix. If we are agreeing what this work
> item is (in forms 1, 2, and 3) we should at least be explicit whether
> or not opt-in is part of it, rather than be silent on the issue.

then let's make it explicit in the way of olaf's strengthened language,
which is to say, let's outlaw it.  we cannot live through another round
of opt-in debate, and i say that speaking as someone who thinks the last
debate ended wrongly.

> A "third way" is to design an NSEC+ such that it intervals lacking
> authenticated denial can exist, but prohibit their use unless and
> until the security model / policy bit is sorted out. Given this
> requires putting in one bit and marking it reserved, it should not
> (surely) be too contentious. This at least means that if one ever
> decided to introduce opt-in, it's impact on the on-the-wire protocol
> would be minimal.

in order to reserve a bit, you have to describe client behaviour during
the time when you're not yet sure what the bit means.  you can say "interrim
clients shall pay no attention to this bit" or "interrim clients shall treat
responses having this bit set as being undefined, and drop them", or any
number of things in between those fenceposts.  my bet is that there is no
definition of interrim client behaviour that will be useful to the future
definition of opt-in, unless you can propose a versioning mechanism, such
as EDNS(x=n).  if you're going to propose a versioning mechanism, then
you're already finished, since in EDNS(x<n) already reserves all unused bits.