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

John Leslie <john@jlc.net> Fri, 09 January 2009 18:15 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 062F53A6A43; Fri, 9 Jan 2009 10:15:21 -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 3995B3A6A36 for <ietf@core3.amsl.com>; Fri, 9 Jan 2009 10:15:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.952
X-Spam-Level:
X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=0.647, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 FhI9rDBsejlq for <ietf@core3.amsl.com>; Fri, 9 Jan 2009 10:15:19 -0800 (PST)
Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.9]) by core3.amsl.com (Postfix) with ESMTP id D61F73A6A43 for <ietf@ietf.org>; Fri, 9 Jan 2009 10:15:18 -0800 (PST)
Received: by mailhost.jlc.net (Postfix, from userid 104) id 83DF833C1F; Fri, 9 Jan 2009 13:15:03 -0500 (EST)
Date: Fri, 09 Jan 2009 13:15:03 -0500
From: John Leslie <john@jlc.net>
To: dcrocker@bbiw.net
Subject: Re: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your review and comments on a proposed Work-Around to the Pre-5378 Problem
Message-ID: <20090109181503.GP24908@verdi>
References: <70873A2B7F744826B0507D4B84903E60@noisy> <FB8A848E-E415-4CDE-9E3F-5C74A5614F18@cisco.com> <49678B2A.8000100@dcrocker.net>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <49678B2A.8000100@dcrocker.net>
User-Agent: Mutt/1.4.1i
Cc: IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Dave CROCKER <dhc2@dcrocker.net> wrote:
> 
> 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.

   Agreed.

> 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...

   I don't read it that way. Refer to:

http://trustee.ietf.org/docs/Draft-Update-to-IETF-Trust-Legal-Provisions-1-06-09.pdf
] 
] 6. c. iii.
] ... This document contains material from IETF Documents or IETF
] Contributions published before November 10, 2008 and, to the
] Contributor's knowledge, the person(s) controlling the copyright 
] in such material have not granted the IETF Trust the right to allow
] modifications of such material outside the IETF Standards Process.
] Without obtaining an adequate license from the person(s) controlling
] the copyright, this document may not be modified outside the IETF
] Standards Process, and derivative works of it may not be created
] outside the IETF Standards Process, except to format it for
] publication as an RFC and to translate it into languages other than
] English. 

   If you believe there is an admission of guilt there, please send
text. (But understand, lawyers have to sign off on any changes.)

> 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 may not be the one to explain, but I _don't_ think that's what
the proposal calls for. I think it calls for inclusion of the
boilerplate I listed above, which simply disclaims knowledge of
_whether_ all the rights of 5378 are granted (and thus derivative
works "outside the IETF Standards Process" are not authorized by
the IETF Trust).

>> 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.

   True...

> 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.

   Alas, I must disagree. We have an IETF Consensus document (5378),
and that consensus must be overturned to get to where Dave claims
we are. In my experience, overturning consensus is hard. (That's
the _point_ of having a consensus process.)

   However wrong some of us (now) believe that consensus to be, we
should not expect to overturn it in 30 days -- whereas this quick
fix can be applied in 30 days. I strongly urge all of us to let
the quick fix go through without holding it hostage to overturning
the consensus of 5378.

--
John Leslie <john@jlc.net>
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf