Re: Call for review of proposed update to ID-Checklist

Dave Crocker <dhc2@dcrocker.net> Wed, 13 August 2008 17:55 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 EA0BB28C16B; Wed, 13 Aug 2008 10:55:06 -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 6744A3A6AAA; Wed, 13 Aug 2008 10:55:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 YFqj0HIZY7SW; Wed, 13 Aug 2008 10:55:05 -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 EBCDA3A6A58; Wed, 13 Aug 2008 10:55:04 -0700 (PDT)
Received: from [192.168.0.3] (ppp-67-124-90-139.dsl.pltn13.pacbell.net [67.124.90.139]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id m7DHt5YX011249 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Aug 2008 10:55:05 -0700
Message-ID: <48A31FF9.2080700@dcrocker.net>
Date: Wed, 13 Aug 2008 10:55:05 -0700
From: Dave Crocker <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: "Bert Wijnen (IETF)" <bertietf@bwijnen.net>
Subject: Re: Call for review of proposed update to ID-Checklist
References: <D78EAB64AF674E24B2199B2C1DBDA1FE@BertLaptop> <489F13F2.3060707@dcrocker.net> <6F1B41ACCFC0441E8E86CD61B5874A02@BertLaptop> <48A0626E.8060507@dcrocker.net> <98CA2246DD534DCBBF7FEE196F833AC8@BertLaptop>
In-Reply-To: <98CA2246DD534DCBBF7FEE196F833AC8@BertLaptop>
X-Virus-Scanned: ClamAV 0.92/8026/Wed Aug 13 06:03:11 2008 on sbh17.songbird.com
X-Virus-Status: Clean
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Wed, 13 Aug 2008 10:55:05 -0700 (PDT)
Cc: ietf@ietf.org, iesg@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-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


Bert Wijnen (IETF) wrote:
> ----- Original Message ----- From: "Dave Crocker" <dhc2@dcrocker.net>
>> RFC 3979 says what is to be in an RFC, not what isn't. The Checklist says 
>> what isn't.
> 
> The proble we saw in the IESG (when we started ID_Checklist) was that we saw 
> A LOT OF I-Ds that requested publication and that DID HAVE SPECIFIC IPR 
> claims. So we wanted to make it clear to people that such is NOT TO BE DONE.
> 
> Just saying that RFC3979 text was to be used seemed not to get through!


Bert,

One of the likely reasons it didn't get through is that the IESG was inventing a
new rule.  A good rule, in my opinion, but a new one, since I think that
redundancy of specifications invites disparity.

To say that something must be in one place is very different from saying that it
may not (also) be in another.

So the IESG a) invented a more strict, formal rule than had existed before, and
b) only documented it in the Checklist.

Consider both of these points, please, in terms of your earlier claim:

> Bert Wijnen (IETF) wrote:
>> I think that both of you (and some others) arwe looking at the ID_Checklist
>> too much as if it is part of our (rigid) process. Our processes are 
>> described in formally approved BCP documents.


While it is vastly more convenient, for the IESG, to have it take initiative and
decide on its own to make a more strict rule and issue it in a document that
does not go through public vetting, it isn't the way things are supposed to be
done in the IETF.

If the IESG is now responsible for inventing IETF policy, that ought to be
acknowledged and documented explicitly.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf