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

Paul Hoffman <phoffman@imc.org> Wed, 03 March 2010 17:07 UTC

Return-Path: <phoffman@imc.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 F173C28C153; Wed, 3 Mar 2010 09:07:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.046
X-Spam-Level:
X-Spam-Status: No, score=-6.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4]
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 pVMX9CytWULj; Wed, 3 Mar 2010 09:07:36 -0800 (PST)
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) by core3.amsl.com (Postfix) with ESMTP id 0638F28C12C; Wed, 3 Mar 2010 09:07:35 -0800 (PST)
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 o23H7WZV018274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 3 Mar 2010 10:07:33 -0700 (MST) (envelope-from phoffman@imc.org)
Mime-Version: 1.0
Message-Id: <p06240823c7b445d69632@[10.20.30.158]>
In-Reply-To: <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> <alpine.BSF.2.00.1003021836230.46887@fledge.watson.org>
Date: Wed, 3 Mar 2010 09:05:24 -0800
To: Samuel Weiler <weiler@watson.org>, Andrew Sullivan <ajs@shinkuro.com>
From: Paul Hoffman <phoffman@imc.org>
Content-Type: text/plain; charset="us-ascii"
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 17:07:37 -0000

At 6:46 PM -0500 3/2/10, Samuel Weiler wrote:
>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.

That line of logic would mean that any Informational RFC on any topic can "specify the requirement status". The IETF has never worked that way, and never will.

>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."

Mixing the contents of these two documents is a terrible idea. It puts the rules for the registry in two documents instead of one.

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

It is not because that mechanism is in a different document, as it should be.