Re: draft-housley-two-maturity-levels

Andrew Sullivan <ajs@shinkuro.com> Tue, 26 October 2010 16:11 UTC

Return-Path: <ajs@shinkuro.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 2A0643A6912 for <ietf@core3.amsl.com>; Tue, 26 Oct 2010 09:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.161
X-Spam-Level:
X-Spam-Status: No, score=-102.161 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 MIZ1vPSkD0QQ for <ietf@core3.amsl.com>; Tue, 26 Oct 2010 09:11:35 -0700 (PDT)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id D27C33A6964 for <ietf@ietf.org>; Tue, 26 Oct 2010 09:11:33 -0700 (PDT)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id BD2901ECB408 for <ietf@ietf.org>; Tue, 26 Oct 2010 16:13:20 +0000 (UTC)
Date: Tue, 26 Oct 2010 12:13:19 -0400
From: Andrew Sullivan <ajs@shinkuro.com>
To: ietf@ietf.org
Subject: Re: draft-housley-two-maturity-levels
Message-ID: <20101026161318.GL45134@shinkuro.com>
References: <4CC6224B.5060300@gmail.com> <20101026024400.57137.qmail@joyce.lan> <201010260337.o9Q3b4Mb020219@sj-core-5.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <201010260337.o9Q3b4Mb020219@sj-core-5.cisco.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
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: Tue, 26 Oct 2010 16:11:37 -0000

On Mon, Oct 25, 2010 at 10:37:03PM -0500, James M. Polk wrote:
> I'm not in love with the 3 maturity levels, especially when I was asked 
> by an AD during Maastricht to provide proof of 2 independent  
> implementations just to have an ID I was presenting be considered to  
> become a WG item.
>
> That bar is just WAY too high.

I agree, but I see precious little evidence so far presented that the
two-maturity-levels proposal under discussion will solve that problem.

If the problem we need to solve is that it's too hard to get an ID
published as Proposed Standard, then we should tackle that.  The
problem in that case does not need tweaking of standards levels and so
on, but hard rebukes of WGs (and, frankly, IESG members) who insist on
making that publication hard.

If the problem is that things linger in the standards track without
progressing, then _maybe_ reducing the number of maturity levels
helps, because it might solve a public relations problem the IETF has
(i.e. if the real problem of lingering is that the IETF has a
resulting PR problem).

The draft as it stands claims that the reason the bar is so high for
PS is because things linger there.  That is an incentive to make the
resulting RFC as good as possible because it will be the only document
ever published.  This amounts to a causal argument about how things
got to be the way they are.  I am a little sceptical that this story
is true.  (One can tell just as compelling a story in the other
direction: once the PS bar was high enough, there was no incentive to
revisit an RFC and try to advance it.)  But suppose the
two-maturity-levels draft's story were right: as the draft stands, it
will do absolutely nothing to solve that problem.

If things are currently languishing as PS in a three-track system,
there is no reason to suppose that removing one (later) level of
maturity will do anything about those documents that never advance
beyond PS.  If documents do not so advance, then the incentives to
make publication as PS hard remain exactly the same.  We should
therefore expect the same result, which is that things linger at PS
and WGs and the IESG make it hard to publish that initial, PS-level
RFC.

In fact, the draft as it stands will actually make that incentive
stronger, because it explicitly permits downrefs from STANDARD to
PROPOSED STANDARD.  I get the reasoning, but one likely effect of this
is going to be that there is even more pressure to get the PS
documents close to perfect.  Even if there are significant problems
with a given PS, if there are downrefs to it there will be a lot of
pressure to avoid changing it substantively, because of those
references, which means that revisiting PS RFCs won't pay off.  

Because of the above, I don't think the proposal is a good idea in
principle.  As a matter of fact, however, I don't think its adoption
would make much practical difference: the RFCs that manage to clear
the initial high bar will mostly continue to stick at PS for want of
energy to move them along the track.  Sometimes, some people will have
the energy to move things along, and then they will.

Best regards,

Andrew

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.