Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-02
Andrew Sullivan <ajs@shinkuro.com> Wed, 03 March 2010 02:53 UTC
Return-Path: <ajs@shinkuro.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 774A03A8836; Tue, 2 Mar 2010 18:53:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 P5PybulrOKNg; Tue, 2 Mar 2010 18:53:25 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9BE2B3A859E; Tue, 2 Mar 2010 18:53:25 -0800 (PST)
Received: from crankycanuck.ca (3.e54f41.client.atlantech.net [65.79.229.3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id EB56E1ECBC22; Wed, 3 Mar 2010 02:53:18 +0000 (UTC)
Date: Tue, 02 Mar 2010 21:53:14 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: Samuel Weiler <weiler@watson.org>
Message-ID: <20100303025314.GA4711@shinkuro.com>
References: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> <20100302203103.GJ2901@shinkuro.com> <6c9fcc2a1003021242p16379b6ai6d87f6cf497b37cb@mail.gmail.com> <20100302231204.GM2901@shinkuro.com> <alpine.BSF.2.00.1003021836230.46887@fledge.watson.org> <20100303000509.GR2901@shinkuro.com> <alpine.BSF.2.00.1003021955090.62257@fledge.watson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.BSF.2.00.1003021955090.62257@fledge.watson.org>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: draft-ietf-dnsext-dnssec-alg-allocation.all@tools.ietf.org, Barry Leiba <barryleiba@computer.org>, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Mar 2010 02:53:26 -0000
On Tue, Mar 02, 2010 at 08:00:09PM -0500, Samuel Weiler wrote: > No. alg-allocation, read by itself, is still confusing. Rather than > cite the new metric for changing requirement status (as being > defined/changed in registry-fixes), alg-allocation could instead cite > the current metric. Earlier in this thread you said that was to update > 4034 (=standards action). > > No matter what the metric is, I want alg-allocation to be explicit about > the metric. It appears, however, that the approach you're suggesting could actually make things more confusing in the near term. DNSEXT is currently trying to do two, strictly separate things: 1. Alter the mechanism to get an algorithm assignment in the IANA registry. That's what the document we're discussing does. 2. Clean up the registry to make it easier to find, in one place, data like what is mandatory to implement or not. That's what registry-fixes does. What you are suggesting is that the present document be made to say not only that it does not alter how you get a "mandatory" flag, but what the current procedure is. The problem with that is that we're actually trying to _change_ what the procedure is, because at the moment it's "update 4034" or maybe "update 3755" or maybe "update 2536". In any case, it's certainly standards action; but what that action is, we'd have to work out when we did it. It is in fact this very confusion that regstry-fixes is supposed to help: on its publication, what you'd have to do is update the registry with the required flad, and registry-fixes makes clear that such an update requires standards action. If we change the current document to say precisely how you get a mandatory flag today, however, we're out of luck: there's actually no mandatory flag in the registry as it stands, so there's nowhere to track this. This therefore would require a lengthy explanation in the current document about how there is in fact no such thing as a mandatory flag in the registry, and that therefore you can't have a restriction on setting the mandatory flag, but that anyway you can't have a mandatory-to-implement algorithm without a standards action. All of that to be obsoleted immediately on publication of whatever ends up coming out of registry-fixes (since even if one doesn't like the current words in that document, _something_ needs to be done about the registry in question). I'm therefore not actually sure how to make the text clearer for the immediate circumstance without also making it more confusing in the hopefully-near future. If you have suggested text to do this, however, I'd be interested in seeing it. Best, A -- Andrew Sullivan ajs@shinkuro.com Shinkuro, Inc.
- [secdir] secdir review of draft-ietf-dnsext-dnsse… Barry Leiba
- Re: [secdir] secdir review of draft-ietf-dnsext-d… Andrew Sullivan
- Re: [secdir] secdir review of draft-ietf-dnsext-d… Barry Leiba
- Re: [secdir] secdir review of draft-ietf-dnsext-d… Andrew Sullivan
- Re: [secdir] secdir review of draft-ietf-dnsext-d… Barry Leiba
- Re: [secdir] secdir review of draft-ietf-dnsext-d… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-dnsext-d… Andrew Sullivan
- Re: [secdir] secdir review of draft-ietf-dnsext-d… Samuel Weiler
- Re: [secdir] secdir review of draft-ietf-dnsext-d… Andrew Sullivan
- Re: [secdir] secdir review of draft-ietf-dnsext-d… Paul Hoffman