Re: draft-housley-two-maturity-levels

Russ Housley <housley@vigilsec.com> Tue, 26 October 2010 12:34 UTC

Return-Path: <housley@vigilsec.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 9777A3A6952 for <ietf@core3.amsl.com>; Tue, 26 Oct 2010 05:34:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 eb5bP959gYkS for <ietf@core3.amsl.com>; Tue, 26 Oct 2010 05:34:16 -0700 (PDT)
Received: from odin.smetech.net (mail.smetech.net [208.254.26.82]) by core3.amsl.com (Postfix) with ESMTP id 4B6C63A6965 for <ietf@ietf.org>; Tue, 26 Oct 2010 05:34:16 -0700 (PDT)
Received: from localhost (unknown [208.254.26.81]) by odin.smetech.net (Postfix) with ESMTP id 5516EF2405E; Tue, 26 Oct 2010 08:36:10 -0400 (EDT)
X-Virus-Scanned: amavisd-new at smetech.net
Received: from odin.smetech.net ([208.254.26.82]) by localhost (ronin.smetech.net [208.254.26.81]) (amavisd-new, port 10024) with ESMTP id JQQDn4bvx7Ov; Tue, 26 Oct 2010 08:35:51 -0400 (EDT)
Received: from [198.180.150.230] (v230.vpn.iad.rg.net [198.180.150.230]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 27A279A470F; Tue, 26 Oct 2010 08:36:09 -0400 (EDT)
Message-ID: <4CC6CB39.4060507@vigilsec.com>
Date: Tue, 26 Oct 2010 08:36:09 -0400
From: Russ Housley <housley@vigilsec.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.11) Gecko/20101013 Lightning/1.0b2 Thunderbird/3.1.5
MIME-Version: 1.0
To: "Scott O. Bradner" <sob@harvard.edu>
Subject: Re: draft-housley-two-maturity-levels
References: <20101026024811.BD2AD5AC74F@newdev.eecs.harvard.edu>
In-Reply-To: <20101026024811.BD2AD5AC74F@newdev.eecs.harvard.edu>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 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: Tue, 26 Oct 2010 12:34:19 -0000

Scott:

Just to clarify, do you think that it would be better to document "one
step" or do you think that the community should not spend time on this
topic at all?

On 10/25/2010 10:48 PM, Scott O. Bradner wrote:
> 
>> I'd like to hear from the community about pushing forward with this
>> proposal or dropping it
> 
> I do not think this proposal fixes any known problems
> 
> the major reason (imo) that technology is not advanced along the
> standards track is because there is no need to do so.  
> 
> someone labors for a while to get a proposed standard published and
> people start to use it (if they did not start at the Internet Draft stage)
> soon about anyone that has a need for the technology has implemented it and 
> it is being used by customers all over the globe
> 
> just what is the reason that someone would take time from working on new 
> technology to do the work to advance the proposed standard?  it is unlikely 
> that all that many more people will implement or use the technology
> so what is the point?
> 
> in addition, the IESG acts as if the proposed standard will be the last step
> in the publication process (or at least reviews IDs as if this were the case)
> so we have all the benefits of the cross area review (this making the proposed standards 
> about as good as one could without requiring interoperable implementations at the
> first stage (i.e. bringing back running code))
> 
> so I say drop it and live with the fact that rfc 2026 does not paint an accurate
> picture of the current one step standard process
> 
> Scott
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>