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

Thomas Narten <> Wed, 13 April 2011 23:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E21F1E0679 for <>; Wed, 13 Apr 2011 16:44:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.864
X-Spam-Status: No, score=-105.864 tagged_above=-999 required=5 tests=[AWL=0.735, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0cLp+mqo85yv for <>; Wed, 13 Apr 2011 16:44:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 15056E061E for <>; Wed, 13 Apr 2011 16:44:47 -0700 (PDT)
Received: from ( []) by (8.14.4/8.13.1) with ESMTP id p3DNKVCD003723 for <>; Wed, 13 Apr 2011 19:20:31 -0400
Received: from ( []) by (Postfix) with ESMTP id 3F44E6E8036 for <>; Wed, 13 Apr 2011 19:44:46 -0400 (EDT)
Received: from ( []) by (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3DNikLt337924 for <>; Wed, 13 Apr 2011 19:44:46 -0400
Received: from (loopback []) by (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3DNijUH015799 for <>; Wed, 13 Apr 2011 20:44:45 -0300
Received: from ( []) by (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3DNii6k015768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 20:44:45 -0300
Received: from ( []) by (8.14.4/8.12.5) with ESMTP id p3DNih4v013997; Wed, 13 Apr 2011 19:44:44 -0400
Message-Id: <>
To: Andrew Sullivan <>
In-reply-to: <>
References: <>
Comments: In-reply-to Andrew Sullivan <> message dated "Wed, 13 Apr 2011 11:19:35 -0400."
Date: Wed, 13 Apr 2011 19:44:43 -0400
From: Thomas Narten <>
X-Content-Scanned: Fidelis XPS MAILER
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: Wed, 13 Apr 2011 23:44:48 -0000

Based on the writeup, and this in particular:

> The WG has been talking about this draft for some time.  I believe it
> has had adequate review, but it is a strange document.  It is
> basically a process document, and I therefore suspect that the only
> time it will get the sort of attention it needs on that front is
> during IETF-wide review.  It should also be reviewed by IANA.

I went and and reviewed the document (for the first time).

> The draft uses a novel procedural trick to put something into a
> registry that usually isn't in a registry, so I think this will
> require careful review by IETF process wonks.

I'm wondering if I fully understand the purpose of this document.
>From the document's introduction:

    The original list of algorithm status is found in [RFC4034].  Other
    DNSSEC documents have added new algorithms or changed the status of
    algorithms in the registry.  However, currently implementers must
    read through all the documents in order to discover which algorithms
    are considered wise to implement, which are not, and which algorithms
    may become widely used in the future.
    This compliance status indication is only to be considered for
    implementation, not deployment or operations.  Operators are free to
    deploy any digital signature algorithm available in implementations
    or algorithms chosen by local security policies.  This status is to
    measure compliance to this RFC only.

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

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

a) This SHOULD/MUST be implemented, or
b) something other than 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?

> 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.)

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?

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.