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

Dave Crocker <dhc2@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 E5E4528C108; Thu, 26 Jun 2008 02:46:52 -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 18BFE28C11D; Thu, 26 Jun 2008 02:46:51 -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 ng26GRjkKbaY; Thu, 26 Jun 2008 02:46:50 -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 AE54628C131; Thu, 26 Jun 2008 02:46:49 -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 m5N9SphL019201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Jun 2008 02:28:56 -0700
Message-ID: <485FCF9D.5020508@dcrocker.net>
Date: Mon, 23 Jun 2008 09:30:21 -0700
From: Dave Crocker <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Russ Housley <housley@vigilsec.com>
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]); Mon, 23 Jun 2008 02:28:56 -0700 (PDT)
Cc: iesg@ietf.org, ietf@ietf.org
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