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