Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-04.txt

Andrew Sullivan <ajs@anvilwalrusden.com> Mon, 11 March 2013 20:34 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202A321F8FEE for <dnsext@ietfa.amsl.com>; Mon, 11 Mar 2013 13:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.81
X-Spam-Level:
X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crdA042UV9V4 for <dnsext@ietfa.amsl.com>; Mon, 11 Mar 2013 13:34:41 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) by ietfa.amsl.com (Postfix) with ESMTP id 975F921F8E06 for <dnsext@ietf.org>; Mon, 11 Mar 2013 13:34:41 -0700 (PDT)
Received: from crankycanuck.ca (dhcp-2430.meeting.ietf.org [130.129.36.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id D81BC8A031 for <dnsext@ietf.org>; Mon, 11 Mar 2013 20:34:40 +0000 (UTC)
Date: Mon, 11 Mar 2013 16:34:15 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: dnsext@ietf.org
Message-ID: <20130311203415.GE38441@crankycanuck.ca>
References: <20130311152035.4888.59295.idtracker@ietfa.amsl.com> <20130311191607.GF38303@crankycanuck.ca> <alpine.BSF.2.00.1303111558310.25246@fledge.watson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <alpine.BSF.2.00.1303111558310.25246@fledge.watson.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dnsext] I-D Action: draft-ietf-dnsext-dnssec-algo-imp-status-04.txt
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, 11 Mar 2013 20:34:42 -0000

Hi Sam,

On Mon, Mar 11, 2013 at 04:13:17PM -0400, Samuel Weiler wrote:
> The last sentence is the troubling one.  I think you mean "where no
> other document has set an implementation status", but that's
> somewhat vague, and it would be reasonable to interpret the doc as
> saying "and everything else is Optional", which is not what we
> intend.

It absolutely is too what we intend.  The very point of this document
is that there be exactly one current official list of the status
values of every algorithm.  Every algorithm not explicitly called out
in that table has the status value Optional.  That was exactly what I
understood previous consensus calls on this document to be saying, and
if people think that's not what we said then we have a problem.

> I think something needs to change.  Most likely, we just need to
> restate in the text (not just the table) the status of RSASHA1 and
> RSAMD5.

Why not just in the table?

> Also, shouldn't the indirect, private, and privateoid text replace
> "up to the implementer's discretion" with "Optional"?  It's good to
> call out that these numbers could refer to multiple algoriths, as is
> done.

I don't think I can tell the difference between Optional and "up to
the implementer's discretion".  Also, since the document explicitly
says that anything not listed elsewhere in the table is therefore
Optional, the indirect, private, and privateoid algorithms just are
Optional.  No?

I should note that the WG pretty much ran out of steam on this
document quite some time ago, and there is every reason to suppose
that the document will never get published if we start making
substantive changes right now, so I urge participants to be careful
about the changes they ask for.  This is not an attempt to tell people
not to raise substantive issues, but it is a plea to consider whether
this or that part needs to be polished to a higher gloss, or whether
the document is comprehensible as it stands and clearly expresses the
meaning of the WG.

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com