Re: [dnsext] draft-ietf-dnsext-dnssec-alg-allocation-02 downrefs

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 27 January 2010 18:59 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135C43A67CC; Wed, 27 Jan 2010 10:59:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.185
X-Spam-Level:
X-Spam-Status: No, score=-106.185 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLWz1QO0PlHD; Wed, 27 Jan 2010 10:59:52 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 202473A677D; Wed, 27 Jan 2010 10:59:52 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NaD0c-000GMU-Na for namedroppers-data0@psg.com; Wed, 27 Jan 2010 18:52:58 +0000
Received: from [192.245.12.227] (helo=balder-227.proper.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <paul.hoffman@vpnc.org>) id 1NaD0Y-000GLn-2v for namedroppers@ops.ietf.org; Wed, 27 Jan 2010 18:52:54 +0000
Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id o0RIqpZU096698 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jan 2010 11:52:52 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p06240833c7863ae3e976@[10.20.30.158]>
In-Reply-To: <201001271731.SAA08531@TR-Sys.de>
References: <201001271731.SAA08531@TR-Sys.de>
Date: Wed, 27 Jan 2010 10:52:50 -0800
To: Alfred Hönes <ah@TR-Sys.de>
From: Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [dnsext] draft-ietf-dnsext-dnssec-alg-allocation-02 downrefs
Cc: namedroppers@ops.ietf.org
Content-Type: text/plain; charset="us-ascii"
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

At 6:31 PM +0100 1/27/10, Alfred =?hp-roman8?B?SM5uZXM=?= wrote:
> > I am leaving this as-is until after IESG evaluation because the
>> headers and boilerplates keep changing. For the RFC, I'm happy
>> to use whatever is current then.
>
>I thought it'd be only a matter of a PI parameter in the xml
>(ipr="full5378", currently)   :-)
>I also already have seen anecdotal evidence of the IESG challenging
>the pre-5378 clause, but I do not insist on this change now!

So, if you know that the current tools don't support this change, why are you asking for it in this WG?

> >> (2)  Front matter, Normative Downrefs, etc.
>>>
>>> The draft lists [RFC2535] and [RFC3755] as Normative Refs.
>>> Both RFCs have been obsoleted by RFC 4033..4035.
>>>
>>> Therefore, neither RFC 2535 nor RFC 3755 need to be formally
>>> "Updated" by the draft -- they already are "Obsoleted".
>>
>> That is irrelevant: you can update an obsoleted RFC if need be.
>
>So is there 'need' ?

No, but it is accurate to do so.

>Does anybody still need the bulk of RFC 2535 ?
>The only potentially interesting thing in RFC 2535 is SIG(0),
>but that's out of scope of this draft.
>My personal preference always has been to avoid potential
>confusion and to not draw people's attention to obsoleted
>documents they better should not read and implement now.

That makes sense, but so does updating documents whose policies are being changed.

> > In this case, those two RFCs are still listed in the IANA registry.
>>
>>> Also, the Introduction of the draft could be understood
>>> as if RFC 2535 (and maybe RFC 3755) still were the 'home'
>>> of the IANA "DNS Security Algorithm Numbers" registry.
>>
>> That's how IANA lists them, yes.
>
>AFAICS, RFC 2535 is no more listed as the "owner" of the registry,
>since quite a while.  As I had pointed out, it is still listed as a
>ref. for algorithm numbers 253 and 254 (only).

And understanding those two are *very important* to this document.

> > I don't want this draft blocked by such discussion.
>
>I don't want to see it blocked either.
>But I don't see any need or reason for such discussion.  As stated
>once more above, IANA already lists RFC 4034 as a parent of the
>registry.  My remark was a statement of fact, not a change request.

My apologies: it sounded like a change request.

>IMHO, there's no need to "implement or understand" RFC 2535 and
>RFC 3755 in order to "implement" this document.  RFC 4034 suffices.
>So the water mark for Normative is clearly missed.

That's one watermark. Another is that if a document is being updated, it is normative.

>I have been tought by one AD recently that "normative in an IANA
>registry" is no reason to treat the ref. as normative for a document
>that changes the policy of suche registry or adds such registry
>entries.  However, opinions vary, admittedly.

Yes.

>Maybe the IESG can (and most likely, will) contribute DISCUSSes
>to this topic.   :-(

No.

>I do not oppose to move on now and consider these changes later,
>e.g. after IETF LC, or when the IESG comes up with similar ideas.

During IETF LC is fine, and it lets the IESG weigh in on some of the assumptions you make.

--Paul Hoffman, Director
--VPN Consortium