Re: draft-housley-two-maturity-levels

Eric Burger <eburger-l@standardstrack.com> Thu, 28 July 2011 14:03 UTC

Return-Path: <eburger-l@standardstrack.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B4AF21F8C52 for <ietf@ietfa.amsl.com>; Thu, 28 Jul 2011 07:03:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.486
X-Spam-Level:
X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSMkeXFnPeuR for <ietf@ietfa.amsl.com>; Thu, 28 Jul 2011 07:03:06 -0700 (PDT)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.194.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6049521F8C32 for <ietf@ietf.org>; Thu, 28 Jul 2011 07:03:06 -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:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=AyAtV9Yq1r5Zj5cxOOF3mvAWmC4eXYtgqRs5DtRBfxj2eqh+DmSWICH6EtfLsUnAdBLz/lUpkCSjuvGYHce0ZDwo7XxfZPDohfsKDmkLF+J8PUVUDglw4EUbrQG02XAa;
Received: from dhcp-63da.meeting.ietf.org ([130.129.99.218]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <eburger-l@standardstrack.com>) id 1QmRB2-00019u-R0; Thu, 28 Jul 2011 07:03:05 -0700
Subject: Re: draft-housley-two-maturity-levels
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Eric Burger <eburger-l@standardstrack.com>
In-Reply-To: <12B69DB8-AFDD-4C40-BC9A-0A8158D9F7C0@nostrum.com>
Date: Thu, 28 Jul 2011 10:03:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0D43A851-C57B-484F-ADDD-BBD7A412689C@standardstrack.com>
References: <20110728121904.2D22AD7A76F@newdev.eecs.harvard.edu> <12B69DB8-AFDD-4C40-BC9A-0A8158D9F7C0@nostrum.com>
To: Bradner Scott <sob@harvard.edu>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.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@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Thu, 28 Jul 2011 14:03:07 -0000

And the real question is, are we moving forward? I think that we are not moving as far as we originally wanted. However, I offer we are moving a baby step forward, and as such is worthwhile doing.

On Jul 28, 2011, at 9:19 AM, Robert Sparks wrote:

> Scott -
> 
> Didn't RFC 5657 address your point 2?
> 
> The current proposal no longer requires this report during advancement, but it does not disallow it.
> I hope it's obvious that I believe these reports are valuable, but I am willing to accept the proposed
> structure, with the hope and expectation that  communities that are serious about producing and 
> refining protocols will be producing these reports anyhow.
> 
> RjS
> 
> On Jul 28, 2011, at 8:19 AM, Scott O. Bradner wrote:
> 
>> 
>> this is better than the last version but
>> 
>> 1/ I still see no reason to think that this change will cause any
>> significant change in the percent of Proposed Standards that move up the
>> (shorter) standards track since the proposal does nothing to change the
>> underlying reasons that people do not expend the effort needed to
>> advance documents
>> 
>> 2/ one of the big issues with the PS->DS step is understanding what
>> documentation is needed to show that there are the interoperable
>> implementations and to list the unused features - it would help a lot to
>> provide some guidance (which I did not do in 2026 - as I have been
>> reminded a number of times :-) ) as to just what process is to be
>> followed
>> 
>> could be
>> 	a spread sheet showing features & implementations
>> 	an assertion by the person proposing the advancement that the
>> requirements have been met
>> or something in between
>> 
>> Scott
>> _______________________________________________
>> Ietf mailing list
>> Ietf@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf