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

Paul Hoffman <> Thu, 14 April 2011 14:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 205EDE069F for <>; Thu, 14 Apr 2011 07:09:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.803
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s6+ddWl38M3s for <>; Thu, 14 Apr 2011 07:09:49 -0700 (PDT)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by (Postfix) with ESMTP id 4CB57E066B for <>; Thu, 14 Apr 2011 07:09:49 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (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
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Paul Hoffman <>
In-Reply-To: <>
Date: Thu, 14 Apr 2011 07:09:47 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <>
To: Thomas Narten <>
X-Mailer: Apple Mail (2.1084)
Subject: Re: [dnsext] Publication request: draft-ietf-dnsext-dnssec-registry-fixes-07
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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