Re: [dnsext] Publication request: draft-ietf-dnsext-dnssec-registry-fixes-07

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 14 April 2011 13:39 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: dnsext@ietfc.amsl.com
Delivered-To: dnsext@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 29740E0776 for <dnsext@ietfc.amsl.com>; Thu, 14 Apr 2011 06:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.782
X-Spam-Level:
X-Spam-Status: No, score=-101.782 tagged_above=-999 required=5 tests=[AWL=0.817, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty3QmIItACxn for <dnsext@ietfc.amsl.com>; Thu, 14 Apr 2011 06:39:22 -0700 (PDT)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by ietfc.amsl.com (Postfix) with ESMTP id E76E7E06B8 for <dnsext@ietf.org>; Thu, 14 Apr 2011 06:39:21 -0700 (PDT)
Received: from [10.20.30.150] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id p3EDdK0g037196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Apr 2011 06:39:20 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <20110414125527.GE24471@crankycanuck.ca>
Date: Thu, 14 Apr 2011 06:39:20 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <F88155D3-70BA-47BD-B4D5-3DFD1D4E5F8B@vpnc.org>
References: <20110413151934.GL24471@shinkuro.com> <201104132344.p3DNih4v013997@cichlid.raleigh.ibm.com> <0560E4CC-35C9-4B32-A5E4-669B7B08D559@vpnc.org> <201104140155.p3E1t4ho014811@cichlid.raleigh.ibm.com> <20110414125527.GE24471@crankycanuck.ca>
To: Andrew Sullivan <ajs@shinkuro.com>
X-Mailer: Apple Mail (2.1084)
Cc: Thomas Narten <narten@us.ibm.com>, dnsext-ads@tools.ietf.org, dnsext@ietf.org
Subject: Re: [dnsext] Publication request: draft-ietf-dnsext-dnssec-registry-fixes-07
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2011 13:39:23 -0000

The philosophical / operational tussle here is whether the definitive list of crypto algorithms and their implementation requirements should be kept in:

a) an IANA registry for the growing list of algorithms, and a single RFC for the implementation requirements

b) an IANA registry for the growing list of algorithms, and a set of loosely coupled RFCs for the implementation requirements

c) an IANA registry for a growing list of algorithms that is tied to a single RFC for the implementation requirements

Some WGs have gone with (a), and some with with (b). The current draft proposes (c) for this protocol. It is a modification of the idea in (a), and it gives the implementer less chance of getting it wrong because they will find the exact same set of implementation requirements in "the" RFC and the IANA registry.

To me, this is different and a bit weird, but could make sense for getting better interoperability because of better understanding on the part of developers. It seems worth a try and, if it turns out to be more confusing than (a) or (b), the WG can drop back to one of them.

--Paul Hoffman