Re: [ietf-dkim] New Issue: New resource record type

Scott Kitterman <ietf-dkim@kitterman.com> Mon, 16 October 2006 13:21 UTC

Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZSP5-0003kg-H9 for ietf-dkim-archive@lists.ietf.org; Mon, 16 Oct 2006 09:21:15 -0400
Received: from sb7.songbird.com ([208.184.79.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZSP3-00031g-3h for ietf-dkim-archive@lists.ietf.org; Mon, 16 Oct 2006 09:21:15 -0400
Received: from sb7.songbird.com (sb7.songbird.com [127.0.0.1]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k9GDIVFc031612; Mon, 16 Oct 2006 06:18:32 -0700
Received: from mailout00.controlledmail.com (mailout00.controlledmail.com [72.81.252.19]) by sb7.songbird.com (8.12.11.20060308/8.12.11) with ESMTP id k9GDIBgG031566 for <ietf-dkim@mipassoc.org>; Mon, 16 Oct 2006 06:18:12 -0700
Received: from mailout00.controlledmail.com (localhost [127.0.0.1]) by mailout00.controlledmail.com (Postfix) with ESMTP id 233C75CC132 for <ietf-dkim@mipassoc.org>; Mon, 16 Oct 2006 13:17:54 +0000 (UTC)
Received: from [192.168.111.103] (static-72-81-252-22.bltmmd.fios.verizon.net [72.81.252.22]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout00.controlledmail.com (Postfix) with ESMTP id F3CDD5CC0FF for <ietf-dkim@mipassoc.org>; Mon, 16 Oct 2006 13:17:53 +0000 (UTC)
From: Scott Kitterman <ietf-dkim@kitterman.com>
To: ietf-dkim@mipassoc.org
Subject: Re: [ietf-dkim] New Issue: New resource record type
Date: Mon, 16 Oct 2006 09:17:51 -0400
User-Agent: KMail/1.9.4
References: <200610141114.40215.ietf-dkim@kitterman.com> <45336A79.3040008@cisco.com> <45338055.9060309@mtcc.com>
In-Reply-To: <45338055.9060309@mtcc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200610160917.51367.ietf-dkim@kitterman.com>
X-Virus-Scanned: ClamAV using ClamSMTP
X-Songbird: Clean, Clean
X-BeenThere: ietf-dkim@mipassoc.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF DKIM Discussion List <ietf-dkim.mipassoc.org>
List-Unsubscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=unsubscribe>
List-Archive: <http://mipassoc.org/pipermail/ietf-dkim>
List-Post: <mailto:ietf-dkim@mipassoc.org>
List-Help: <mailto:ietf-dkim-request@mipassoc.org?subject=help>
List-Subscribe: <http://mipassoc.org/mailman/listinfo/ietf-dkim>, <mailto:ietf-dkim-request@mipassoc.org?subject=subscribe>
Sender: ietf-dkim-bounces@mipassoc.org
Errors-To: ietf-dkim-bounces@mipassoc.org
X-SongbirdInformation: support@songbird.com for more information
X-Songbird-From: ietf-dkim-bounces@mipassoc.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c

Any design the requires a new RR type is not deployable anytime soon.

As I said before, if a new RR type is the path we are going down, then we may 
as well quit and go home now.

To put it in requirements language, I think it is a requirement that SSP be 
deployable with the same DNS infrastructure that supports base (this is 
independent of where in the namespace the record goes - as long as it's 
somewhere in TXT we can design the details later).

Scott K

On Monday 16 October 2006 08:51, Michael Thomas wrote:
>  From a requirements standpoint, I'd just assume we not go into this level
> of detail. The high level bits of deterministic number of lookups and other
> things seem fairly uncontroversial, but the engineering/deployment
> considerations
> of the RR problem require a lot more detail and/or experimental evidence
> to be
> examined. I don't think that a requirements document is the right venue
> to run
> that debate.
>
>        Mike
>
> Jim Fenton wrote:
> >Eliot Lear wrote:
> >>Jim,
> >>
> >>Fair points.  One possibility, by the way, is that we use the SAME
> >>prefix but simply with new attributes.  That way you get the whole thing
> >>in one shot.
> >
> >I'm not sure what you have in mind here.  One of the benefits of using a
> >new RR type is that it may allow us to get away from the use of a prefix
> >entirely, which in turn may shorten the search process by detecting
> >nonexistent domains more easily.  I'm not certain how well this
> >mechanism works, but you can see what I'm talking about in
> >draft-allman-dkim-ssp-02.
> >
> >-Jim
> >_______________________________________________
> >NOTE WELL: This list operates according to
> >http://mipassoc.org/dkim/ietf-list-rules.html
>
> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html