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

ned+ietf@mauve.mrochek.com Fri, 09 January 2009 22:54 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 C0CA13A6923; Fri, 9 Jan 2009 14:54:51 -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 354533A6923 for <ietf@core3.amsl.com>; Fri, 9 Jan 2009 14:54:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.56
X-Spam-Level:
X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 ROSMQ5JindUj for <ietf@core3.amsl.com>; Fri, 9 Jan 2009 14:54:49 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.59.230.40]) by core3.amsl.com (Postfix) with ESMTP id 575EF3A68DF for <ietf@ietf.org>; Fri, 9 Jan 2009 14:54:49 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01N43GNHL6CW00TGE5@mauve.mrochek.com> for ietf@ietf.org; Fri, 9 Jan 2009 14:54:34 -0800 (PST)
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01N43EJO5PA800007A@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for ietf@ietf.org; Fri, 09 Jan 2009 14:54:31 -0800 (PST)
Date: Fri, 09 Jan 2009 14:45:42 -0800
From: ned+ietf@mauve.mrochek.com
Subject: RE: [Trustees] ANNOUNCEMENT: The IETF Trustees invite your reviewand comments on a proposed Work-Around to the Pre-5378 Problem
In-reply-to: "Your message dated Fri, 09 Jan 2009 16:32:57 -0500" <DBAA71AA401E5398212B1E03@PST.jck.com>
To: John C Klensin <john-ietf@jck.com>
Message-id: <01N43GNGOAFY00007A@mauve.mrochek.com>
MIME-version: 1.0
References: <70873A2B7F744826B0507D4B84903E60@noisy> <"FB8A848E-E415-4CDE-9E3F-5C74A561 4F18"@cisco.com> <49678B2A.8000100@dcrocker.net> <20090109181503.GP24908@verdi> <6E372F257B0C42E7AB9B7DA6231FF4E4@LROSENTOSHIBA> <p06240800c58d5466241b@[10.227.48.131]> <DBAA71AA401E5398212B1E03@PST.jck.com>
Cc: Ted Hardie <hardie@qualcomm.com>, '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

I've tried really hard to stay out of this whole IPR mess - there are only
so many hours in the day - but the point John makes here is so vital I simply
have to chime in and support it.

> ...

> Now, what I recommend is that we try to see if we can agree that
> the three-stage description above is what we intend.   If we can
> agree, then the _next_ step is figuring out how to get there in
> the minimum period of time.

> My problem with the Trust's latest proposed policy is that we've
> got extensive evidence --including the consensus decision that
> got us into the mess-- that the IETF is not good at evaluating
> legal documents and theories and their possible consequences and
> side-effects.  I don't believe that the right way to solve that
> problem is to hand the IETF yet another legal document, with
> some language and a theory in it that seems subtle, and ask us
> to evaluate it.

> I believe that the IETF should accept a clearly-stated set of
> principles and that the Trust should then come back and say "on
> the advice of Counsel, the following text implements that
> principle".  If lawyers then want to argue about whether the
> text is optimal to implement those principles, that is fine with
> me, as long as the argument is limited to the relationship
> between principles and text and not an attempt to change
> principles.   Remember that the Trustees do have insurance
> against getting that sort of thing wrong; the rest of us are not
> insured against either getting those things wrong or against the
> Trust doing so.

This is EXACTLY the approach we should be using: Formulate a set of goals, get
agreement on them, and only then ask the laywers to turn that informal
specification into competent legalese.

When Innosoft, the company I co-founded, got to the point of hiring a real CEO
with serious business chops, one of the first things the new CEO did was to
change how we engaged with our lawyers from what was effectively the approach
the IETF has been using to the approach John describes.

The difference was like night and day. Instead of being mired in interminable
discussions with engineers playing at being laywers and doing a crappy job of
it, we divided the task in a fashion that suits the actual competencies of the
players. Process sped way way up and the quality of the product improved
dramatically.

I actually have tried to articulate this several times in the past, but for
whatever reason I couldn't find the right words to do so. I'm delighted that
John has done so here.

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