Re: draft-housley-two-maturity-levels

Eric Burger <eburger@standardstrack.com> Tue, 26 October 2010 10:10 UTC

Return-Path: <eburger@standardstrack.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 CA8E43A6828 for <ietf@core3.amsl.com>; Tue, 26 Oct 2010 03:10:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.456
X-Spam-Level:
X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 TWz7SI+kt9da for <ietf@core3.amsl.com>; Tue, 26 Oct 2010 03:10:11 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [66.117.3.189]) by core3.amsl.com (Postfix) with ESMTP id 20A453A67A3 for <ietf@ietf.org>; Tue, 26 Oct 2010 03:10:11 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=standardstrack.com; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=l+OhBa6av3gz2diPFKxMMkvZPa+hUTLSMItNVQCrCCHIdAXiUD2C4EJ33TC9uPGQOTryi/t3OfVlzs95FgcCog9G8B3CoI6WiOGKcqfbUoyuGpMULsz6Aggvnlbp5hJT;
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.134]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <eburger@standardstrack.com>) id 1PAgUl-0000Sq-KN; Tue, 26 Oct 2010 03:11:07 -0700
Subject: Re: draft-housley-two-maturity-levels
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: multipart/signed; boundary="Apple-Mail-47-543069330"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Eric Burger <eburger@standardstrack.com>
In-Reply-To: <20101026024811.BD2AD5AC74F@newdev.eecs.harvard.edu>
Date: Tue, 26 Oct 2010 06:11:54 -0400
Message-Id: <665140E6-F4EF-4F7E-8973-984CF3096694@standardstrack.com>
References: <20101026024811.BD2AD5AC74F@newdev.eecs.harvard.edu>
To: "Scott O. Bradner" <sob@harvard.edu>
X-Mailer: Apple Mail (2.1081)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
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 10:10:14 -0000

The known problem is it takes well over four years to get anything published.

I am experiencing in one never-ending saga the logical conclusion of the logic: since Proposed Standard is the new Draft Standard, and since the IESG has to make sure any proposal is beyond bullet-proof, the industry has long since implemented draft-mumble-21, which has not changed for over a year, and few in industry cares if the document publishes as an RFC, because from their point of view, if something has been working in the field for three years, has 18 independent implementations, and has not yet crashed the Internet, it is probably ready, whether the IETF formally says so or not. That is the fast track to making the IETF irrelevant.

The very real danger here is while that attitude may be OK for a small media application, that attitude could be a disaster in, for example, the routing area. Something really has to be done.

Now, I do agree with Scott here there is absolutely no incentive for anyone to bring a protocol to Draft/Internet Standard level.

What I *am* hoping is that with two, clearly defined maturity levels, we can go back to publishing Proposed Standards in about a year, and have Internet Standard mean something. Otherwise, we will be perpetually running the Internet on Internet Drafts, which is something I do not think anyone really can say is a good thing.

On Oct 25, 2010, at 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