Re: Last Call: <draft-resnick-on-consensus-05.txt> (On Consensus and Humming in the IETF) to Informational RFC

Dave Crocker <dhc@dcrocker.net> Tue, 08 October 2013 15:48 UTC

Return-Path: <dhc@dcrocker.net>
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 AA73F21E81F1; Tue, 8 Oct 2013 08:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.001
X-Spam-Level:
X-Spam-Status: No, score=-6.001 tagged_above=-999 required=5 tests=[AWL=0.598, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 2tmKJAk9Fxi9; Tue, 8 Oct 2013 08:48:20 -0700 (PDT)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7AFB921E8186; Tue, 8 Oct 2013 08:48:20 -0700 (PDT)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id r98Fm6gV030565 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 8 Oct 2013 08:48:09 -0700
Message-ID: <5254292C.9020809@dcrocker.net>
Date: Tue, 08 Oct 2013 08:47:56 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Ted Hardie <ted.ietf@gmail.com>
Subject: Re: Last Call: <draft-resnick-on-consensus-05.txt> (On Consensus and Humming in the IETF) to Informational RFC
References: <20131007164829.16131.73595.idtracker@ietfa.amsl.com> <CA+9kkMB4VX7mABG=oZ16uNu3zOT-1-h0K5dEN68RW92X9ER59w@mail.gmail.com> <52530CCF.8090605@gmail.com> <CA+9kkMB-x3B5QD9T9Q4eFRH9QSXza8AcB=4=zvmrOqyyUTnFJQ@mail.gmail.com>
In-Reply-To: <CA+9kkMB-x3B5QD9T9Q4eFRH9QSXza8AcB=4=zvmrOqyyUTnFJQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Tue, 08 Oct 2013 08:48:10 -0700 (PDT)
Cc: IESG <iesg@ietf.org>, IETF <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: dcrocker@bbiw.net
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: Tue, 08 Oct 2013 15:48:25 -0000

On 10/8/2013 8:36 AM, Ted Hardie wrote:
> And what are the RFC numbers for the comments?  If none, as I suspect,
> then the comments aren't the same status as the documents--that's fine
> for RFC 791 and 2460, but it is not clear that Pete's document falls
> into the same class.  I would argue it does not.


Unfortunately the concern you are raising has often been applied to all 
sorts of IETF work.  Many bits of IETF work are subject to on-going 
comments and often reach the practical status of de facto -- or, in the 
case of the errata mechanism, IETF de jure -- modifications to the 
published document.

In fact, the line of argument you raise has frequently been lodged 
against the BCP construct.  Yet we keep finding BCPs useful to create.


    1.  Does the IETF need a modern, thorough, community-approved 
statement of it's consensus model and the application of the model? 
That is, both theory and practice.

        So far, it looks as if the community certainly thinks we do, and 
  strongly agree.  In fact I think we suffer greatly by not having it. 
And as we've gone through multiple generations of participants, we've 
tended towards reliance on catch-phrases, without a shared understanding 
of their deeper meaning and specific practice.  So folks invent their 
own meanings as best they can.  Something like Pete's draft is needed to 
provide shared substance to what we mean when we talk about rough consensus.


    2.  Should the statement be an RFC or something more malleable (and 
therefore ephemeral)?

        Why would we not want something this essential to be available 
through our formal publishing and archiving mechanism?  To the extent 
that later discussions prompt modifications, that's what the errata 
mechanism is for.  And eventual revision to the RFC.  Unless someone 
thinks that this core construct for the IETF is going to be subject to 
constant and fundamental modification???

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net