Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis

Dave Crocker <dhc@dcrocker.net> Thu, 26 June 2008 09:46 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BB1B28C12C; Thu, 26 Jun 2008 02:46:49 -0700 (PDT)
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 73CFF28C12F for <ietf@core3.amsl.com>; Thu, 26 Jun 2008 02:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.702
X-Spam-Level:
X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_FUTURE_06_12=1.897]
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 lXMhCKRzEyiH for <ietf@core3.amsl.com>; Thu, 26 Jun 2008 02:46:47 -0700 (PDT)
Received: from sbh17.songbird.com (mail.mipassoc.org [IPv6:2001:470:1:76:0:ffff:4834:7146]) by core3.amsl.com (Postfix) with ESMTP id 9209728C12B for <ietf@ietf.org>; Thu, 26 Jun 2008 02:46:45 -0700 (PDT)
Received: from [192.168.0.3] (adsl-67-127-53-97.dsl.pltn13.pacbell.net [67.127.53.97]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m5O87Rt3007429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <ietf@ietf.org>; Tue, 24 Jun 2008 01:07:32 -0700
Message-ID: <48610E0F.9070802@dcrocker.net>
Date: Tue, 24 Jun 2008 08:09:03 -0700
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: Appeal against IESG blocking DISCUSS on draft-klensin-rfc2821bis
References: <8832006D4D21836CBE6DB469@klensin-asus.vbn.inter-touch.net> <485590E2.3080107@gmail.com> <p06250116c47c330c7dd0@[75.145.176.242]> <4856DE3A.3090804@gmail.com> <C122F91B-59B0-49AC-ABBC-6752217C4E47@NOKIA.COM> <20080619024147.9146C3A6938@core3.amsl.com> <982D9B028F78DF6F95D2E946@p3.JCK.COM> <20080623154145.485BC3A67CF@core3.amsl.com>
In-Reply-To: <20080623154145.485BC3A67CF@core3.amsl.com>
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Tue, 24 Jun 2008 01:07:32 -0700 (PDT)
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: dcrocker@bbiw.net
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/pipermail/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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org


Russ Housley wrote:
> As you said in your note, we disagree on the details.  I have forwarded 
> the text to the list that shows that the issue was raised during IETF 
> Last Call.  Meaning, it was not a late surprise.

First, there is a difference between a reviewer's making an observation, versus
an Area Director's imposing it as a requirement.  The latter is the issue in the
appeal.

Second, even the reviewer said they didn't care about it.  So it is not merely a
possibility of having missed the reviwer's comment; it is that the reviewer
explicity removed any need for concern about their observation.


> I agree that the community should not have to watch IESG decisions to 
> infer trends.  In this case, the ID Checklist already includes a SHOULD 
> statement.  It could be more clear.  More about that below.

I'll ask again:  When did ID-Nits become an authoritative source, rather than a
summary of other sources?

And if it does indeed represent the sole venue for imposing some requirements,
by what approval process did these individual items get reviewed and approved?

This should be particularly explained with respect to the specific rule that you
are using as the basis for blocking the document.


And lastly, what has emerged from this exchange is a rather explicit
clarification that the IETF really has a two-state requirements model.

The first set of requirements is based on community consensus and the second on
IESG consensus, with the latter overriding whatever might be set by the first,
in terms of form, style or content.

This is, after all, the real implication of a framework which leaves the IESG
free to impose whatever judgment it wishes either in requirements documents it
issues without community approval, or Discuss vetoes it sustains.

To the extent that this summary of the IETF authority model is incorrect, how?

To the extent that it is correct, is this really what the community wants?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf