Re: [secdir] secdir review of draft-ietf-dnsext-dnssec-alg-allocation-02

Samuel Weiler <weiler@watson.org> Tue, 02 March 2010 23:46 UTC

Return-Path: <weiler@watson.org>
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 4B1B73A89A4; Tue, 2 Mar 2010 15:46:08 -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 AsyXJsN5bi7p; Tue, 2 Mar 2010 15:46:07 -0800 (PST)
Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by core3.amsl.com (Postfix) with ESMTP id 5E7A83A85A1; Tue, 2 Mar 2010 15:46:07 -0800 (PST)
Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.14.3/8.14.3) with ESMTP id o22Nk5F6051698; Tue, 2 Mar 2010 18:46:05 -0500 (EST) (envelope-from weiler@watson.org)
Received: from localhost (weiler@localhost) by fledge.watson.org (8.14.3/8.14.3/Submit) with ESMTP id o22Nk3OU051692; Tue, 2 Mar 2010 18:46:03 -0500 (EST) (envelope-from weiler@watson.org)
X-Authentication-Warning: fledge.watson.org: weiler owned process doing -bs
Date: Tue, 2 Mar 2010 18:46:03 -0500 (EST)
From: Samuel Weiler <weiler@watson.org>
To: Andrew Sullivan <ajs@shinkuro.com>
In-Reply-To: <20100302231204.GM2901@shinkuro.com>
Message-ID: <alpine.BSF.2.00.1003021836230.46887@fledge.watson.org>
References: <9abf48a61003021143p6cef437fxb72fe0c3a58a684c@mail.gmail.com> <20100302203103.GJ2901@shinkuro.com> <6c9fcc2a1003021242p16379b6ai6d87f6cf497b37cb@mail.gmail.com> <20100302231204.GM2901@shinkuro.com>
User-Agent: Alpine 2.00 (BSF 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (fledge.watson.org [127.0.0.1]); Tue, 02 Mar 2010 18:46:05 -0500 (EST)
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: Tue, 02 Mar 2010 23:46:08 -0000

On Tue, 2 Mar 2010, Andrew Sullivan wrote:

> The text of this draft currently explicitly notes that it doesn't
> change the rules for making an algorithm mandatory to implement.
> Since making an algorithm mandatory to implement would update 4034, I
> therefore think that it would still require standards action, which
> punts the whole business right back to the same process in place
> today.  Does that make you less uneasy?

It still leaves me uneasy.  As a casual reader of this doc (and casual 
author of an algorithm definition doc), I'd be inclinded to assume 
that an algorithm definition doc, even if not standards track, could 
at least specify the requirement status for the algorithm it's 
defining.

As I pointed out when reviewing 
draft-ietf-dnsext-dnssec-registry-fixes, I'm worried about the 
possibility of an independent submission (=RFC Editor stream document) 
creating a new "MANDATORY" algorithm or of changing the requirement 
status of other new algorithms, even if those were defined on the 
standards track.  I proposed some text for the registry-fixes doc to 
resolve that, and I suggest repeating it here:

"Unless specified in a Standards Track RFC, new algorithms will have a 
requirements status of OPTIONAL.  Only a Standards Track RFC may set 
or change a requirements status of ENCOURAGED or MANDATORY."

There may be some additional issues around the particular keywords in 
that text, but that's the general idea.

At the very least, rather than say "This document does not change the 
requirements for when an algorithm because (sic) mandatory to 
implement. Such requirements should come in a separate, focused 
document.", actually tell people what the mechanism/threshhold for 
setting a requirement level is.  I don't think it's currently obvious.

-- Sam