Subject: RE: [ietf-dkim] Montreal agenda, other than base

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 16 Jun 2006 15:08:31 -0700

I would rather have a 6 month pushback from the IESG than a spec that is dependent on the next release of Windows Server to become viable. 

The first does not delay deployment in the slightest. As far as I am concerned its damn the torpedoes.

The second will mean as an absolute minimum waiting for a BIND product cycle and will require a much higher degree of support from ISPs and DNS Registrars.

> [mailto:[email-masked]] On Behalf Of Dave Crocker

> I suggest that we explicitly solicit some discussion in the 
> meeting with both Security and DNS experts.  We have made 
> some assumptions about what is likely to be acceptable to 
> each of those communities, yet I suspect we do not have much 
> feedback yet about their limits.
> 
> (I suspect we are in quite good shape, with respect to the 
> Security folks, but I find myself worried about the DNS constituency.)
> 
> So, for example, the DNS purists could well take exception to 
> the choice we have made for an initial TXT record, with a new 
> RR outside the critical path of -base.
> 
> Montreal could give us some valuable insight into the likely 
> problems we will or will not have in getting -base approved.
> 
> Alternatively, we could go through working group last call, 
> IETF last call, and IESG push-back.  For any interesting 
> push-back, we are probably looking at delays in the range of 
> 6 months.  (That estimate is, of course, not merely
> theoretical.)

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 16 Jun 2006 15:32:26 -0700

On Jun 16, 2006, at 3:08 PM, Hallam-Baker, Phillip wrote:

> I would rather have a 6 month pushback from the IESG than a spec  
> that is dependent on the next release of Windows Server to become  
> viable.
>
> The second will mean as an absolute minimum waiting for a BIND  
> product cycle and will require a much higher degree of support from  
> ISPs and DNS Registrars.

Defining a DKIM specific RR type should not prevent deployment.   
Defining the DKIM specific RR within the base draft means a new DKIM  
version is not required to enable its use.  If there are issues  
handling a DKIM specific RR, this is a problem independent of DKIM.   
A new RR issue, if there are any, may delay exclusive reliance upon  
the DKIM specific RR.

-Doug

---

From: [email-masked]
Date: Fri, 16 Jun 2006 17:34:55 -0700 (PDT)

> I would rather have a 6 month pushback from the IESG than a spec that is
> dependent on the next release of Windows Server to become viable.

Nicely put. I agree completely with this sentiment.

> concerned its damn the torpedoes.

Yup.

> The second will mean as an absolute minimum waiting for a BIND product cycle
> and will require a much higher degree of support from ISPs and DNS Registrars.

And as you pointed out later, DKIM may well provide the push needed to
get DNSSEC deployed, dragging better RR support along in the process.

We're much better off in the role of horse than acting like a cart, especially
when there's no other horse in sight.

				Ned

---

From: Dave Crocker <[email-masked]>
Date: Sun, 18 Jun 2006 21:24:19 -0400

> Nicely put. I agree completely with this sentiment.

Sounds nice to me, too.

The only problem is that I don't know what it means.

There has been no input suggesting that the current -base proposal is difficult
to deploy for Windows, or otherwise depends on its release cycle.

Certainly there has been no working group agreement that the current proposal is
deficient in this regard, and it seems to me that the working group has been
rather diligent in its effort to worry about such things.

So I have no idea where that reference comes from or how it relates to the
concern about substantial delays.

>> concerned its damn the torpedoes.

Is this supposed to mean that a delayed approval by the IESG will not delay
deployment of the specification?

Perhaps folks have not noticed the amount of change that can be imposed by the
IESG phase of the process?

Were the industry that insensitive to change, it would already be deploying the
original version of DKIM in larger numbers.

At any rate, the tone of the comments on this thread is that folks do not seem
worried about another half-year of delay for publishing the base DKIM spec.

Please tell me I'm misunderstanding this.

d/
-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

---

From: John Levine <[email-masked]>
Date: 19 Jun 2006 02:03:28 -0000

>The only problem is that I don't know what it means.

Someone was predicting another round of DNS wars, of the define a new
RR vs.reusing TXT variety, with hostilities breaking out via the IESG.

My position, which I believe is widely shared among the DKIM group, is
that the _domainkey subdomain introduces a new namespace within which
all TXT records must be DKIM keys, so we're not overloading any
existing TXT record.  We might want to add a sentence or two warning
people that they'll be sorry if they put any other kind of TXT record
under _domainkey, but that's cosmetic.  This is a fairly important
principle, since we're doing the same thing for the SRV records in CSV
and will probably do a lot of other namespaces that redefine existing
record types in the future.

The sentiment up at >>> is that a new RR type is such a bad idea that
it'd be worth a six month fight with the IESG to prevent it, but I
think we all agree that a much better outcome would be to go ahead
with the technically sound plan we have without the detour.

R's,
John