Subject: [ietf-dkim] Recommend not adding DNS RR(s) into DKIM base doc

From: Mark Delany <[email-masked]>
Date: Mon, 27 Mar 2006 22:46:56 +0000

On Mon, Mar 27, 2006 at 08:57:41AM -0600, Arvel Hathcock allegedly wrote:

> My own view is that if DNS is a mandatory mechanism, if 'simple' and 

On a tangent to the discussion about splitting the base document,
someone suggested that the new DNS RRs specifications be added to the
base. I believe this to be a bad idea for scheduling and dependency
reasons, perhaps in a surprising way.

First off, I believe we could actually get out a DNS RR before the
DKIM base if we work at it as it's relatively uncontroversial. And, if
we can do that, it will be very helpful in the deployment sphere.

Second off, a number of the DNS related mechanisms in the base, such
as the hierarchy search, sub-domaining, namespace use and TXT then DKK
lookup are likely to cause delays and controversy as base goes through
the final review processes. Keeping those issues separate from the RR
definition(s) will make the RR process easier.

Third off, at IETF65, I received verbal support from a number of the
folk in the DNS community that they will assist in the RR creation
process. Smoothing the wheels and showing us what obstacles to avoid,
if you will. They also helped review my chicken scratchings of a first
draft.

In summary, regardless of the merits or otherwise, of splitting the
base document, I would prefer that the base not-subsume the DKK RR and
presumably the Policy/Practice/Preference/Percolator RR or whatever it
will be called.

Mark.

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

---

From: Jim Fenton <[email-masked]>
Date: Mon, 27 Mar 2006 17:19:05 -0800

> presumably the Policy/Practice/Preference/Percolator RR or whatever it
Agreed.  Letting the design process of the DKK and DKP RRs go forward in
parallel is a substantial benefit.

-Jim

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Mar 2006 08:51:59 +0200

Mark,

My larger concern is this: it's important that we get the RR done in
time for the base so that we have the query rules done, stating that the
new RR should be preferred to TXT records.

Eliot

---

From: Mark Delany <[email-masked]>
Date: Tue, 28 Mar 2006 07:19:04 +0000

> new RR should be preferred to TXT records.

Agreed. And, er, forgive my propensity to density, but I presume
you're suggesting that a separate doc adds risk because the timing may
not work out.

That concern is clearly valid. The trade-offs are that:

a) the base is kept simpler and more manageable

b) from a deployment perspective, we may be able to get the ball
   rolling earlier on DNS s/w support

c) the DNS RR can progress without all the issues that will arise
   with the base

d) a separate doc has considerable precedent. Eg, RFC821 does not
   describe MX RRs. In fact most RRs as far as I can tell are described
   in isolation from the application protocol.

e) some on this WG think that a new RR is a serious distraction and a
   waste of time. De-coupling a new RR avoids their concerns.

I'm not in a position to judge any of these perspectives and none of
them strike me as compelling, but on the whole, if we diligently work
on an RR spec, which I promise to do, a separate doc seems to have
some merit.

Mark.