Re: Conclusion of the last call on draft-housley-two-maturity-levels

hector <gmail.sant9442@winserver.com> Sat, 10 September 2011 21:45 UTC

Return-Path: <sant9442@gmail.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 ACB5621F8567 for <ietf@ietfa.amsl.com>; Sat, 10 Sep 2011 14:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.764
X-Spam-Level:
X-Spam-Status: No, score=-2.764 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uifw36U0WfFT for <ietf@ietfa.amsl.com>; Sat, 10 Sep 2011 14:45:38 -0700 (PDT)
Received: from mail-gw0-f42.google.com (mail-gw0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id EB56A21F8560 for <ietf@ietf.org>; Sat, 10 Sep 2011 14:45:37 -0700 (PDT)
Received: by gwb17 with SMTP id 17so3414631gwb.15 for <ietf@ietf.org>; Sat, 10 Sep 2011 14:47:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=K/uF+PJLXHH0+owl9Da/LkEQ1tjGOH3UoLTZ9eWl9vQ=; b=XMm5VJx2x2xeawBZCxz/M2in/vKvJELdBEcT3eYScbwtGZO7wHltAV0fcU8k+5y7gA 2WjLcMcuXjb1jaaMzduN/q2nAdpqGySfBBPZEc2rSlZnv6M85iCWhAouaq+VYkFbEEaf AA0sz0mG4P5JXbTV4WWeNC3AGvMVt3C0mCWh8=
Received: by 10.236.186.36 with SMTP id v24mr18992015yhm.46.1315691256593; Sat, 10 Sep 2011 14:47:36 -0700 (PDT)
Received: from adsl-215-50-126.mia.bellsouth.net (99-3-147-93.lightspeed.miamfl.sbcglobal.net [99.3.147.93]) by mx.google.com with ESMTPS id j61sm10335796yhf.6.2011.09.10.14.47.35 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Sep 2011 14:47:35 -0700 (PDT)
Sender: HLS <sant9442@gmail.com>
Message-ID: <4E6BDB00.6030609@winserver.com>
Date: Sat, 10 Sep 2011 17:47:44 -0400
From: hector <gmail.sant9442@winserver.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
CC: ietf@ietf.org
Subject: Re: Conclusion of the last call on draft-housley-two-maturity-levels
References: <20110728121904.2D22AD7A76F@newdev.eecs.harvard.edu> <4E5D4570.9080108@piuha.net> <4E6AEBDC.60002@gmail.com> <2E8B54A8-A024-4869-9E50-1377F48AAA80@vigilsec.com> <94D40572-03D0-4E35-8C1C-F62537F2798D@network-heretics.com>
In-Reply-To: <94D40572-03D0-4E35-8C1C-F62537F2798D@network-heretics.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Sat, 10 Sep 2011 21:45:38 -0000

Whether they were planned as part of revamp plan or not, I don't see 
the two-step and the RFC2119bis efforts and recent debates here as a 
mere coincidence.

Here is how Pareto Optimality design decisions are made such that 
no-one could be made better off without making someone else worse off. 
  I only point this out that we sometimes we to accept change where 
one might not be better off.

    http://en.wikipedia.org/wiki/Pareto_efficiency#Pareto_frontier

    The Pareto frontier is particularly useful in engineering:
    by restricting attention to the set of choices that are
    Pareto-efficient, a designer can make tradeoffs within this
    set, rather than considering the full range of every parameter.

One we view we are an optimal state right now where we don't wish to 
benefit one without making someone else worst and I see the two-step 
and RFC2119bis as attempts to making Pareto Frontier Efficient 
engineering decisions.

The question is always "how much" change we want without ignoring 
those that can be made worst off.

--

Keith Moore wrote:
> On Sep 10, 2011, at 10:44 AM, Russ Housley wrote:
> 
>> That said, at the plenary at IETF 81, Harald suggested that we have waited so long that incremental improvements may not be the right approach, rather it was time for 2026bis.  I agree that it is needed, but I am not sure the IETF community is willing to tackle a project of that size and complexity.
> 
> I suspect that there are two underlying problems, both significant.
> 
> 1. Many people would see an attempt to change the process as a "threat" of one kind or another, feeling like the result of such change under current circumstances would likely be worse than the status quo.
> 
> 2. There seems to be wide perceptual variation among IETF participants as to the organization's purpose and/or what's wrong with the current process.
> 
> I think there's a need for consensus-building around these two topics (and perhaps others) before even considering whether and how to revise 2026.  In the first case, we need to find out what people see as threats and use that to bound the charter of the rewrite effort so that people won't feel like they have to be in damage control mode.  But the second topic is even more important.   
> 
> Keith
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf