RFC3844 and IETF Core Values

Hector <sant9442@gmail.com> Sun, 11 September 2011 02:21 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 052DC21F8495 for <ietf@ietfa.amsl.com>; Sat, 10 Sep 2011 19:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.352
X-Spam-Level:
X-Spam-Status: No, score=-3.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, 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 9IrvxM8k4sGj for <ietf@ietfa.amsl.com>; Sat, 10 Sep 2011 19:21:35 -0700 (PDT)
Received: from mail-gx0-f181.google.com (mail-gx0-f181.google.com [209.85.161.181]) by ietfa.amsl.com (Postfix) with ESMTP id 0786B21F8494 for <ietf@ietf.org>; Sat, 10 Sep 2011 19:21:34 -0700 (PDT)
Received: by gxk9 with SMTP id 9so2454357gxk.40 for <ietf@ietf.org>; Sat, 10 Sep 2011 19:23:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=Yon0dauibinqV614G8jnmcx6IgveVS1+7SxRIKfUHTo=; b=rqUR9IU6LoR+olEhMRrHm+5pVWQictEOFTWfQBJ+RqFxDnAVR72JQObMETFtGbRDJ7 txEbYU0A9W8OjoayD77/5csiGlmMxyXgHj3rgae84a1T1qeLSsdYS9RgX8IZjfDbKzre GeQ+ESYad2VSIW71AnXP3lgilEuP9bPGE1B1A=
Received: by 10.236.195.3 with SMTP id o3mr19563029yhn.67.1315707813046; Sat, 10 Sep 2011 19:23:33 -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 u69sm10557625yhg.16.2011.09.10.19.23.32 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 10 Sep 2011 19:23:32 -0700 (PDT)
Message-ID: <4E6C1BB5.4090605@gmail.com>
Date: Sat, 10 Sep 2011 22:23:49 -0400
From: Hector <sant9442@gmail.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Eric Burger <eburger-l@standardstrack.com>
Subject: RFC3844 and IETF Core Values
References: <20110728121904.2D22AD7A76F@newdev.eecs.harvard.edu> <4E5D4570.9080108@piuha.net> <6.2.5.6.2.20110902090159.09e97af0@resistor.net> <4E6147D4.2020204@santronics.com> <DF7F294AF4153D498141CBEFADB17704C352657343@EMBX01-WF.jnpr.net> <20110906161108.GI31240@shinkuro.com> <CEDD8840-BE2D-405E-872A-271C25A9A59D@network-heretics.com> <01O5QFMUPV8S014O5Z@mauve.mrochek.com> <96633252-503F-4DCD-B6FD-B6B9DEA1FC66@network-heretics.com> <01O5RIOBEGP0014O5Z@mauve.mrochek.com> <201109100133.p8A1XFvS003894@cichlid.raleigh.ibm.com> <3E9E22D3-9C4B-48CF-A0F1-BACD219AF582@standardstrack.com>
In-Reply-To: <3E9E22D3-9C4B-48CF-A0F1-BACD219AF582@standardstrack.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Thomas Narten <narten@us.ibm.com>, IETF list discussion <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: Sun, 11 Sep 2011 02:21:36 -0000

> On Sep 9, 2011, at 9:33 PM, Thomas Narten wrote:
> 
>> Advancing a spec is done for marketing, political, process and other
>> reasons. E.g., to give a spec more legitimacy. Or to more clear
>> replace an older one. Nothing wrong with that.

Eric Burger wrote:

> So should we move to a one-step process?

I asked the great visionary sayer - google, the question:

             What is the IETF Purpose?

and got this top result link:

      http://www.alvestrand.no/ietf/iesg/purpose.php

Alvestrand's conclusion states it as a QA problem which I personally 
agree with:

    A problem in the first 2 bullets is that we have a quality control
    problem - if the WG proposals or the WG consensus documents are not
    high quality, speed will drop like a stone - and SHOULD. We need
    metrics to capture this, somehow.

The search also provided a link to RFC3844,"IETF Problem Resolution 
Process"

Reading RFC3844 now for the first time, seems to have a down a darn 
good job of laying out all the issues in 2002 and thats to be still 
true today, in 2011.

Says in its intro:

    1. Introduction

    ...
    This document begins with an outline of what are currently thought to
    be the purpose and core values of the IETF, and it offers a reminder
    of the good things about the IETF that we don't want to lose in the
    process of solving our problems.

and says pretty profoundly in section 2:

    2. IETF Purpose and Core Values

    As we consider how to address the problems with the IETF processes
    and organizational structure, it is important to keep in mind the
    things about the IETF that we don't want to change -- our sense of
    purpose, and the core values that give the IETF its unique identity.

And it list the items that were concluded in 2002 as non-core values 
that could be considered for change in section 2.1:

   - The division into WGs and Areas
   - The three-step standards process
   - The ASCII format for RFCs and I-Ds
   - The format of IETF meetings
   - The structure of WG mailing lists
   - The powers of the IESG and IAB

and says:

   These things were designed to help us achieve our goals in a way that
   is consistent with our core values.  If they are no longer effective,
   we can and should change them.

I disagree that any of these has shown not the be effective, in 
particular the one on topic with "The Three-step standards process" 
which can only be viewed as a way to bypass the results of these tools 
in keeping core-values.

In section 3, it highlights there ideas that is has put the IETF in a 
bind:

    - Economics,  Commercialization and Convergence.

I personally agree these are the realities, but don't think it should 
alter the essential IETF core values.

--
HLS