Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem

Dave CROCKER <dhc2@dcrocker.net> Fri, 09 January 2009 17:37 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 027F428C1A3; Fri, 9 Jan 2009 09:37:07 -0800 (PST)
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 5BC9C3A68A5; Fri, 9 Jan 2009 09:37:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.276
X-Spam-Level:
X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.323, 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 lvh1OV-gtXzr; Fri, 9 Jan 2009 09:37:05 -0800 (PST)
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 125033A688D; Fri, 9 Jan 2009 09:37:04 -0800 (PST)
Received: from [192.168.0.4] (adsl-68-122-40-145.dsl.pltn13.pacbell.net [68.122.40.145]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id n09Haggo012960 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jan 2009 09:36:48 -0800
Message-ID: <49678B2A.8000100@dcrocker.net>
Date: Fri, 09 Jan 2009 09:36:42 -0800
From: Dave CROCKER <dhc2@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
References: <70873A2B7F744826B0507D4B84903E60@noisy> <FB8A848E-E415-4CDE-9E3F-5C74A5614F18@cisco.com>
In-Reply-To: <FB8A848E-E415-4CDE-9E3F-5C74A5614F18@cisco.com>
X-Virus-Scanned: ClamAV 0.92/8848/Fri Jan 9 05:16:38 2009 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]); Fri, 09 Jan 2009 09:36:48 -0800 (PST)
Cc: Trustees <trustees@ietf.org>, Working Group Chairs <wgchairs@ietf.org>, IETF Discussion <ietf@ietf.org>, IAB IAB <iab@iab.org>, IESG IESG <iesg@ietf.org>, RFC Editor <rfc-editor@rfc-editor.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


Fred Baker wrote:
>  From my perspective, the best approach involves keeping the general 
> case simple. The documents that have been transferred outside the IETF 
> in the past five years is a single digit number, a tenth of a percent of 
> all RFCs if not a smaller fraction. From my perspective, the simplest 
> solution to the transfer issue is to ask the people relevant to a 
> document for which transfer has been suggested whether they have an 
> issue with transferring it, rather than asking every document author his 
> or her opinion on the vast majority of documents, which will never be 
> transferred. 


+1 for simplicity, pragmatics, stability, narrowness of impact, and probably 
"legality".

A number of the comments, so far, appear to hinge on a rather basic cost/benefit 
model that is clearly quite different from what the proposal is based.  I 
suspect that difference comes from a different sense of the problem, per John 
Klensin's posting.

My reference to "legality" is based on a view of the proposal which sees it as 
having individual submitters essentially say "I am required to get permission 
and I have not gotten it".  That's an admission of guilt, which seems like a 
very bad thing to admit and formally document, particularly for an issue 
involving the law.  And if you don't think that's what the proposal calls for, 
please explain, because I don't think my interpretation is all that creative.


I am also struck by the proposal's noting:

> This situation has halted the progression of some Internet-Drafts and  
> interrupted the publication of some RFCs.  

This means that we have a crisis which is stopping productive work, yet the 
crisis appears to be caused by a faulty new requirement, rather than by the 
situation that the document seeks to correct.  In other words, remove the new 
requirement and we no longer have a crisis.  We have an issue to pursue -- the 
same one that prompted the new requirement -- but no crisis.

d/
-- 

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