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

Paul Hoffman <> Thu, 14 April 2011 00:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F835E0731 for <>; Wed, 13 Apr 2011 17:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.683
X-Spam-Status: No, score=-101.683 tagged_above=-999 required=5 tests=[AWL=0.916, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0pEbZQiUeN8T for <>; Wed, 13 Apr 2011 17:27:22 -0700 (PDT)
Received: from (IPv6.Hoffman.Proper.COM [IPv6:2001:4870:a30c:41::81]) by (Postfix) with ESMTP id 5CB23E072E for <>; Wed, 13 Apr 2011 17:27:22 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.4/8.14.3) with ESMTP id p3E0RKr8004473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Apr 2011 17:27:20 -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: Wed, 13 Apr 2011 17:27:19 -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 00:27:23 -0000

On Apr 13, 2011, at 4:44 PM, Thomas Narten wrote:

> Is the purpose of this document simply to add a column to the existing
> registry indicating what the IETF status of all the registered
> algorithms?

No. The "IETF status" would be "on standards track" and "not on standards track", and that is irrelevant to the current document. The purpose it to list the mandatory-to-implement status. In order to do that, the registry has to point to a specific RFC, because that is where the mandatory-to-implement status is defined.

> Well, actually, not even that. E.g., what the IETF position currently
> is w.r.t. whether it should be implemented.

And there is no such "IETF position", of course.

> a) This SHOULD/MUST be implemented, or
> b) something other than that?

Pretty much that.

> If so, I find that an odd thing to put in the registry. I don't know
> of other IANA registries that do that. Do we have examples?

I, too, didn't like this idea, but the WG really did. To turn around your question: is there a procedural problem if this is the first registry to do what is proposed here?

>> There are those who have argued that what the document is doing --
>> putting "implementation levels" into a registry -- is a bad idea.
>> This appears to have been a minority position.
> Well, one issue is that it's not clear that you can capture the proper
> information in a single column. What is the range of things that can
> go into this registry status? (The document seems to leave this pretty
> open, actually.)

We disagree: the document gets quite specific here. The column lists compliance to an RFC, namely this one.

> Let me ask the key question: by what action is the compliance column
> for a given entry changed/updated?
> Apparently (from the document):
>   Adding a newly specified algorithm to the registry with a compliance
>   status SHALL entail obsolescing this document and replacing the
>   registry table (with the new algorithm entry).  Altering the status
>   column value of any existing algorithm in the registry SHALL entail
>   obsolescing this document and replacing the registry table.
>   This document cannot be updated, only made obsolete and replaced by a
>   successor document.
> So, to change the status of any entry in the registry, you have to
> essentially reissue this document with a change?

Correct. RFCs don't change.

> If so, then I don't get it. 
> If you want to be clear about which algorithms the IETF recommends, it
> seems to me the best way is to issue a short document that says "here
> are the currently recommended algorithms". E.g., something like RFC
> 4307. Such a document can have sufficient context to give real
> guidance. E.g., "this algorithm is being phased out, but you probably
> still need to implement it for now", etc.
> And, if there were such a single (clear) document for DNSSEC, I don't
> immediately see the need for a new column in the IANA registry. Folk
> should just review the relevant BCP document.
> Sorry if this has all been discussed before, but I read the document
> for the first time and didn't pay attention to any of the discussion
> that led to it. 

It has been discussed before, and you are voicing a view that some us voiced.

--Paul Hoffman