Re: draft-housley-two-maturity-levels

RJ Atkinson <rja.lists@gmail.com> Mon, 24 January 2011 21:49 UTC

Return-Path: <rja.lists@gmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B13413A6967 for <ietf@core3.amsl.com>; Mon, 24 Jan 2011 13:49:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.385
X-Spam-Level:
X-Spam-Status: No, score=-3.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Pbo4LLCSyPrZ for <ietf@core3.amsl.com>; Mon, 24 Jan 2011 13:49:39 -0800 (PST)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 129C83A68EE for <ietf@ietf.org>; Mon, 24 Jan 2011 13:49:38 -0800 (PST)
Received: by vws7 with SMTP id 7so2083608vws.31 for <ietf@ietf.org>; Mon, 24 Jan 2011 13:52:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:content-type:content-transfer-encoding :subject:date:message-id:to:mime-version:x-mailer; bh=55g3CUcUURkekeo3aAxUJeI8vc+i/Ia/PwtWSSoev68=; b=fpVwLaLlV1eWRP7bUnraQXehFr8r313scDiN/Q2IOBPkhzckgy0ExyaxsRZd5SE6ce IuiZh1P0P9tDNHP07bzB+uVvoX2DBRBHBSDJzqEGssH/3wQe48tfDR20v74DeteTQR7s IQAX45osZaMJlmxaSwoqkBK4jztnPPiE+Qymc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :to:mime-version:x-mailer; b=qq/WdbuNkpse3WQFz9aQjqdHYX72MUV77/CYNk+ZT6p2fI7jf4fOvVSF4Gtb+Lbw13 VX5Tx/SDYVpXKGz7yyC0Nf1QLxVgLC6D0OYZhvmra+w12ICmZnkLUzY7oEzzLBipVq6E wyby9siat5tXgEbERC6gUBd08fSBkHVZYrsAM=
Received: by 10.220.185.79 with SMTP id cn15mr1411362vcb.54.1295905954530; Mon, 24 Jan 2011 13:52:34 -0800 (PST)
Received: from [10.30.20.7] (pool-96-225-170-25.nrflva.fios.verizon.net [96.225.170.25]) by mx.google.com with ESMTPS id j15sm4060539vcs.44.2011.01.24.13.52.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 24 Jan 2011 13:52:33 -0800 (PST)
From: RJ Atkinson <rja.lists@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Re: draft-housley-two-maturity-levels
Date: Mon, 24 Jan 2011 16:52:32 -0500
Message-Id: <91153BB8-DA2D-468D-9F4B-BBCF6D3731E7@gmail.com>
To: ietf@ietf.org
Mime-Version: 1.0 (Apple Message framework v1082)
X-Mailer: Apple Mail (2.1082)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jan 2011 21:49:41 -0000

Earlier, Joel Halpern wrote:
> It seems to me that this proposal strikes a good balance in making an effort
> to improve the situation regarding our document track.
> 
> Regarding the particular clause:
> 
>> On 1/24/2011 1:30 PM, Peter Saint-Andre wrote:
>> ...
>> 
>> 2. I found this statement to be strange:
>> 
>>     The intention of the two-tier maturity
>>     ladder is to restore the requirements for Proposed Standard from RFC
>>     2026.
>> 
>> Why "restore"? Have they been superseded or ignored? I suggest "retain".
> 
> I think the use of the word "restore" is very important. Over the years, 
> our informal requirements and our sense of what was needed for Proposed Standard
> have moved up noticeably. This reflected a number of factors, all of them
> driven as best I can tell by good intentions.  Restoring the lower bar for PS
> is probably the most direct benefit this proposal can have on our work.
> 
> Separately, the replacement of the requirement for verified interoperability
> with the assumption of interoperability based on wide deployment
> is an understandable compromise. I am not sure I like this change,
> but I can live with it, which is good enough.
> 
> I do like the more relaxed wording on the removal of unused features.

+1 to Joel's comments.