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

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 14 April 2011 14:09 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 205EDE069F for <dnsext@ietfc.amsl.com>; Thu, 14 Apr 2011 07:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.803
X-Spam-Level:
X-Spam-Status: No, score=-101.803 tagged_above=-999 required=5 tests=[AWL=0.796, 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 s6+ddWl38M3s for <dnsext@ietfc.amsl.com>; Thu, 14 Apr 2011 07:09:49 -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 4CB57E066B for <dnsext@ietf.org>; Thu, 14 Apr 2011 07:09:49 -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 p3EE9lVQ039230 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Apr 2011 07:09:48 -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: <201104141354.p3EDsvxv007218@cichlid.raleigh.ibm.com>
Date: Thu, 14 Apr 2011 07:09:47 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <439A9F6D-EA5A-45C7-B21A-445EDF178FFA@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> <F88155D3-70BA-47BD-B4D5-3DFD1D4E5F8B@vpnc.org> <201104141354.p3EDsvxv007218@cichlid.raleigh.ibm.com>
To: Thomas Narten <narten@us.ibm.com>
X-Mailer: Apple Mail (2.1084)
Cc: 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 14:09:50 -0000

On Apr 14, 2011, at 6:54 AM, Thomas Narten wrote:

>> c) an IANA registry for a growing list of algorithms that is tied to
>> a single RFC for the implementation requirements
> 
> And I have to wonder why we even need a registry, when the contents of
> the registry are effectively kept in a single RFC, with some types of
> updates to the registry effectively requiring reissuing the RFC and
> replacing the entire IANA registry.

Because we have trained a large subset of developers to go to the IANA registry. We have trained only a very small number of developers to be able to correctly find the *one* *current* RFC that has the implementation requirements (where both "one" and "current" are difficult for typical developers). This proposes an expedient that has a chance for higher success.

>> 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.
> 
> I think we are deceiving ourselves if we think putting the compliance
> info into the IANA registry will make any difference at all.
> 
> The important thing is to have the requirements in one place, where
> they are easily findable by anyone who has even a small amount of
> clue. If implementors won't find them in a BCP IETF document, I
> suspect there is very little we can do to make things easier for them.
> 
> And implementors will implement what is in RFPs and the like, and they
> will point to the RFC stating the requirements, not the IANA registry.

We should be able to evaluate the success of this idea within a few years to see if you are right.

>> 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.
> 
> To me, the work to be done is the same: layout the implementation
> recommendations in a BCP RFC. I don't see much value in putting that
> info into the IANA registry itself, and I very much dislike the idea
> of trying to have the IANA registry be where implementation
> recommendations are captured. It seems like the wrong mechanism to
> bring about a particular result.


I can see both arguments, and have made both on this list in the past. :-)

--Paul Hoffman