Re: draft-housley-two-maturity-levels

John Leslie <john@jlc.net> Fri, 28 January 2011 09:07 UTC

Return-Path: <john@jlc.net>
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 122223A6B00 for <ietf@core3.amsl.com>; Fri, 28 Jan 2011 01:07:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.379
X-Spam-Level:
X-Spam-Status: No, score=-106.379 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 tNBA5AC2txIo for <ietf@core3.amsl.com>; Fri, 28 Jan 2011 01:07:55 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by core3.amsl.com (Postfix) with ESMTP id B23AA3A6959 for <ietf@ietf.org>; Fri, 28 Jan 2011 01:07:55 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id AEC1233C6C; Fri, 28 Jan 2011 04:11:00 -0500 (EST)
Date: Fri, 28 Jan 2011 04:11:00 -0500
From: John Leslie <john@jlc.net>
To: Mark Atwood <mra@pobox.com>
Subject: Re: draft-housley-two-maturity-levels
Message-ID: <20110128091100.GD68297@verdi>
References: <20110127032924.2FE4480CCE8@newdev.eecs.harvard.edu> <201101280230.p0S2UhrM006665@fs4113.wdf.sap.corp> <AANLkTi=aBt=e6SzQNOXa_+J18_qM-MEkD-TjrfdXFW6N@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <AANLkTi=aBt=e6SzQNOXa_+J18_qM-MEkD-TjrfdXFW6N@mail.gmail.com>
User-Agent: Mutt/1.4.1i
Cc: "Scott O. Bradner" <sob@harvard.edu>, ietf@ietf.org
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: Fri, 28 Jan 2011 09:07:57 -0000

Mark Atwood <mra@pobox.com> wrote:
> 
> This post would be much less confusing if you would name names, cite
> examples, and point fingers.

   No, it wouldn't.

   We don't need a flame-war over which features of which protocols
would have to go away under a strict reading of RFC 2026 in order to
advance.

   The point is clear enough: that features that find their way into
Proposed Standards have constituencies, and that pulling them out is
too painful for most WGs to tackle.

> [Martin Rex <mrex@sap.com> wrote:] 
>
>> The reason why so many documents are at proposed is that they're
>> often collections of bloat (limited-use features with an aggresive
>> requirements level) from various interest groups that is
>> not strictly necessary for a protocol to be useful, and sometimes
>> used only by a minority.

   Thank you, Martin!

   This brings us closer to the actual problem.

>> Normally, for progression from Proposed to Draft,
>>
>> - some of the MUSTs would have to be changed to SHOULDs,
>> - some of the SHOULDs would have to be changed to MAYs,
>> - some parts might better be moved to seperate, optional
>>   extensions documents

   I've been there, done that, got the T-shirt. Some pretty dreadful
MUSTs remain because of constituencies. "Consensus" is reached only
by exhaustion.

   Often we end up leaving stuff which can reasonably be called "bloat"
(though that's not how I would describe it) because we can't reach
agreement that we can patch-in a better way without "recycling at
Proposed".

   The whole process is exhausting. More often than not, folks give up.

>> But the particular interest groups would rather have the document
>> remain at Proposed than seeing any of the requirements level of
>> those particular features they're interested in, to come out lowered,
>> or see features removed from the base protocol and into a
>> seperate extensions document.

   Remaining at Proposed just doesn't seem that bad after you've been
through the wringer a few times. (It's not that people start out
wanting to prevent progression; it's that consensus on needed changes
is too hard to reach.)

   Add to this that chartering a WG to advance from Proposed to Draft
never seems to happen (what AD would volunteer to endure this _again_?)
and we have the wrangling which should be contained in a WG arising
during IETF LastCall: few document authors will persist long enough.

   I refuse to argue how many levels there should be -- though I'd
be happy to work within the old consensus for three. What needs work
(assuming we aim for more than one) is how to get there from here!
I have some ideas; but the time just doesn't seem ripe to discuss them.

--
John Leslie <john@jlc.net>