Re: [dnsext] Publication request: draft-ietf-dnsext-dnssec-registry-fixes-07
Edward Lewis <Ed.Lewis@neustar.biz> Mon, 18 April 2011 13:38 UTC
Return-Path: <Ed.Lewis@neustar.biz>
X-Original-To: dnsext@ietfc.amsl.com
Delivered-To: dnsext@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 28251E070E for <dnsext@ietfc.amsl.com>; Mon, 18 Apr 2011 06:38:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8URLPk4VewSf for <dnsext@ietfc.amsl.com>; Mon, 18 Apr 2011 06:38:23 -0700 (PDT)
Received: from stora.ogud.com (stora.ogud.com [66.92.146.20]) by ietfc.amsl.com (Postfix) with ESMTP id 3EE21E0700 for <dnsext@ietf.org>; Mon, 18 Apr 2011 06:38:23 -0700 (PDT)
Received: from Work-Laptop-2.local (gatt.md.ogud.com [10.20.30.6]) by stora.ogud.com (8.14.4/8.14.4) with ESMTP id p3IDcein085372; Mon, 18 Apr 2011 09:38:40 -0400 (EDT) (envelope-from Ed.Lewis@neustar.biz)
Received: from [10.31.200.105] by Work-Laptop-2.local (PGP Universal service); Mon, 18 Apr 2011 09:38:19 -0400
X-PGP-Universal: processed; by Work-Laptop-2.local on Mon, 18 Apr 2011 09:38:19 -0400
Mime-Version: 1.0
Message-Id: <a06240800c9d1ea253482@[10.31.200.116]>
In-Reply-To: <201104141354.p3EDsvxv007218@cichlid.raleigh.ibm.com>
References: <20110413151934.GL24471@shinkuro.com> <201104132344.p3DNih4v013997@cichlid.raleigh.ibm.com> <0560E4CC-35C9-4B32-A5E4-669B7B08D559@vpnc.org> <201104140155.p3E1t4ho014811@cichlid.raleigh.ibm.com> <20110414125527.GE24471@crankycanuck.ca> <F88155D3-70BA-47BD-B4D5-3DFD1D4E5F8B@vpnc.org> <201104141354.p3EDsvxv007218@cichlid.raleigh.ibm.com>
Date: Mon, 18 Apr 2011 09:35:41 -0400
To: Thomas Narten <narten@us.ibm.com>, dnsext@ietf.org
From: Edward Lewis <Ed.Lewis@neustar.biz>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Scanned-By: MIMEDefang 2.68 on 10.20.30.4
Cc: dnsext-ads@tools.ietf.org, ed.lewis@neustar.biz
Subject: Re: [dnsext] Publication request: draft-ietf-dnsext-dnssec-registry-fixes-07
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Apr 2011 13:38:24 -0000
At 9:54 -0400 4/14/11, Thomas Narten wrote: >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. I'd rather have a registry that points to documents than have a document be the source of *what* is defined. Documents are there for *how* something is defined. The reason is that the registry is a single, fixed location (perhaps at a URL) dynamically updated where I can actively access it to see the current state of the protocol parameters. RFCs are never changed, updating the contents mean issuing a new one. Essentially this is a moving location that has fixed contents. I prefer one location than having to hunt for the latest. If in my head I know RFC 2929 is the "IANA considerations for DNS", I might not know about RFC 5395. Yes, the RFC-Editor keeps track of what obsoletes what, but, it's not always reliable and it is yet another web site to consult. Especially if I've downloaded RFC 2929 and only refer to what is in a local file repository. Regarding this (I think from Paul): >> c) an IANA registry for a growing list of algorithms that is tied to >> a single RFC for the implementation requirements I would agree if this is what is meant: a single RFC for each algorithm's implementation requirements. That is, like we have for the RRtypes registry, each type lists the RFC or other document where the type is defined. (As opposed to one gigantic RFC listing all the definitions.) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStar You can leave a voice message at +1-571-434-5468 Me to infant son: "Waah! Waah! Is that all you can say? Waah?" Son: "Waah!"
- [dnsext] Publication request: draft-ietf-dnsext-d… Andrew Sullivan
- Re: [dnsext] Publication request: draft-ietf-dnse… Thomas Narten
- Re: [dnsext] Publication request: draft-ietf-dnse… Paul Hoffman
- Re: [dnsext] Publication request: draft-ietf-dnse… Thomas Narten
- Re: [dnsext] Publication request: draft-ietf-dnse… Andrew Sullivan
- Re: [dnsext] Publication request: draft-ietf-dnse… Paul Hoffman
- Re: [dnsext] Publication request: draft-ietf-dnse… Thomas Narten
- Re: [dnsext] Publication request: draft-ietf-dnse… Paul Hoffman
- Re: [dnsext] Publication request: draft-ietf-dnse… Joe Abley
- Re: [dnsext] Publication request: draft-ietf-dnse… Andrew Sullivan
- Re: [dnsext] Publication request: draft-ietf-dnse… Edward Lewis