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

Thomas Narten <> Thu, 14 April 2011 01:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00132E0781 for <>; Wed, 13 Apr 2011 18:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -105.91
X-Spam-Status: No, score=-105.91 tagged_above=-999 required=5 tests=[AWL=0.689, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i5jZnTvS8-6U for <>; Wed, 13 Apr 2011 18:55:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 423E1E07B2 for <>; Wed, 13 Apr 2011 18:55:16 -0700 (PDT)
Received: from ( []) by (8.14.4/8.13.1) with ESMTP id p3E1mJ2O002269 for <>; Wed, 13 Apr 2011 19:48:19 -0600
Received: from ( []) by (8.13.8/8.13.8/NCO v10.0) with ESMTP id p3E1t7LN093290 for <>; Wed, 13 Apr 2011 19:55:07 -0600
Received: from (loopback []) by (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p3E1t7lT015526 for <>; Wed, 13 Apr 2011 19:55:07 -0600
Received: from ( []) by (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p3E1t6lj015511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Apr 2011 19:55:06 -0600
Received: from ( []) by (8.14.4/8.12.5) with ESMTP id p3E1t4ho014811; Wed, 13 Apr 2011 21:55:04 -0400
Message-Id: <>
To: Paul Hoffman <>
In-reply-to: <>
References: <> <> <>
Comments: In-reply-to Paul Hoffman <> message dated "Wed, 13 Apr 2011 17:27:19 -0700."
Date: Wed, 13 Apr 2011 21:55:04 -0400
From: Thomas Narten <>
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 01:55:17 -0000

Paul Hoffman <> writes:

> 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 lots of things that, strictly speaking, there are no
procedural problems with doing. But that does not mean we should do

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

I don't see that. I gather (reading between the lines) that the column
is expected to use RFC 2119 keywords and that those keywords are
supposed to be in the document that updates the registry.

But I didn't see text in the document itself that says that is what is
required. Just examples...

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

OK. Then I think I'm in the camp that is pretty strongly opposed to

I think the proper way to document what is recommended in terms of
algorithms is simply to write a document that says that, make it a
BCP, and publish it. That is what we do all throughout the IETF. This
stuff does not need to go into the registry. I am not convinced that
putting this info in a registry will make it more likely to be found
by an implementer than just having the recommendation in a BCP. 

What this is doing is creating a "profile" document, and putting that
profile information into the registry. That is not the primary purpose
for registries and I do not see compelling value in putting such
information in a registry. Indeed, I see this as additional compexity
and process for questionable value.

Just write a document, say what the requirements are, and publish it.