Re: Proposal to create IETF IPR Advisory Board

Ted Hardie <hardie@qualcomm.com> Wed, 18 February 2009 20:58 UTC

Return-Path: <hardie@qualcomm.com>
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 63FAB3A6A76 for <ietf@core3.amsl.com>; Wed, 18 Feb 2009 12:58:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 PCpV-u+F1w6D for <ietf@core3.amsl.com>; Wed, 18 Feb 2009 12:58:36 -0800 (PST)
Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 57E553A6B32 for <ietf@ietf.org>; Wed, 18 Feb 2009 12:58:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=hardie@qualcomm.com; q=dns/txt; s=qcdkim; t=1234990729; x=1266526729; h=mime-version:message-id:in-reply-to:references:date:to: from:subject:cc:content-type:x-ironport-av; z=MIME-Version:=201.0|Message-ID:=20<p0624080cc5c224dbaef5 @[10.227.68.59]>|In-Reply-To:=20<20090218144437.03800839@ cs.columbia.edu>|References:=20<20090217234217.D9FB66BE56 A@mercury.lcs.mit.edu>=0D=0A=20<20090217191240.029b7d57@c s.columbia.edu>=0D=0A=20<C12A100E0BB445E5B8C144839AE93A42 @LROSENTOSHIBA>=0D=0A=20<20090218022441.GA3600@mini-me.la n>=0D=0A=20<BAE53BA5860F48C1B18FA0706837206A@LROSENTOSHIB A>=0D=0A=20<20090218144437.03800839@cs.columbia.edu> |Date:=20Wed,=2018=20Feb=202009=2012:58:45=20-0800|To:=20 "Steven=20M.=20Bellovin"=20<smb@cs.columbia.edu>|From:=20 Ted=20Hardie=20<hardie@qualcomm.com>|Subject:=20Re:=20Pro posal=20to=20create=20IETF=20IPR=20Advisory=20Board|CC: =20"ietf@ietf.org"=20<ietf@ietf.org>|Content-Type:=20text /plain=3B=20charset=3D"us-ascii"|X-IronPort-AV:=20E=3DMcA fee=3Bi=3D"5300,2777,5529"=3B=20a=3D"15612729"; bh=7E7pI252cLHk7puretq2Q6incTA5YWfZ5dJjgbaZF9Y=; b=BySAFnOsxprKFKMDekXUCzjrp2AY5xtzzkko9IIQ5qdpU1f/L268mDqZ aZpUgLSLp7o5asy6XtOlRKWSVBLHvBz2CtAonz1AfHd42dBqm0CitvjpW 6XfBmRgJg6HSnkOwF99bSaSvVP7xukEehhNcEgsqrQX+EqvajFTyWOVht Y=;
X-IronPort-AV: E=McAfee;i="5300,2777,5529"; a="15612729"
Received: from pdmz-ns-mip.qualcomm.com (HELO numenor.qualcomm.com) ([199.106.114.10]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Feb 2009 12:58:48 -0800
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1IKwmVH022800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Feb 2009 12:58:48 -0800
Received: from nasanexhub04.na.qualcomm.com (nasanexhub04.qualcomm.com [129.46.134.222]) by totoro.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id n1IKwmS7010608 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 18 Feb 2009 12:58:48 -0800 (PST)
Received: from nasanexmsp01.na.qualcomm.com (10.45.56.204) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.1.336.0; Wed, 18 Feb 2009 12:58:47 -0800
Received: from [10.227.68.59] (10.46.82.6) by qcmail1.qualcomm.com (10.45.56.204) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 18 Feb 2009 12:58:47 -0800
MIME-Version: 1.0
Message-ID: <p0624080cc5c224dbaef5@[10.227.68.59]>
In-Reply-To: <20090218144437.03800839@cs.columbia.edu>
References: <20090217234217.D9FB66BE56A@mercury.lcs.mit.edu> <20090217191240.029b7d57@cs.columbia.edu> <C12A100E0BB445E5B8C144839AE93A42@LROSENTOSHIBA> <20090218022441.GA3600@mini-me.lan> <BAE53BA5860F48C1B18FA0706837206A@LROSENTOSHIBA> <20090218144437.03800839@cs.columbia.edu>
Date: Wed, 18 Feb 2009 12:58:45 -0800
To: "Steven M. Bellovin" <smb@cs.columbia.edu>
From: Ted Hardie <hardie@qualcomm.com>
Subject: Re: Proposal to create IETF IPR Advisory Board
Content-Type: text/plain; charset="us-ascii"
Cc: "ietf@ietf.org" <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-Archive: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Wed, 18 Feb 2009 20:58:37 -0000

At 11:44 AM -0800 2/18/09, Steven M. Bellovin wrote:
> Really, with the exception that it needs legal input, such
>a group would actually be a design team that is supposed to look at the
>tradeoffs (per our policies) and make a recommendation to the WG.

Under that theory, I note that the IESG Design Team document would
appear to apply (http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt)

For those  hard of linking, here's text that is particularly important from
my perspective:

The key point here is that the output of a design team is input to a
working group, not a final document.  Such a document must not be
considered as more important than any other input to the working group.

Anyone can write an alternative proposal and ask the working group to
consider it. The decision on which document to work further on must be made
by the consensus of the working group. If design teams work as intended,
their output will be of a quality that speaks for itself.

Working group chairs should note that there is a potential of anti-trust
liability if a design team is formed with a restricted membership and then
the output is given priority over other input to the process.


Unless the IETF is going to provide counsel to all other efforts,
there is a very real risk that the output of such a design team
will be given weight greater than that of other groups or individuals.
That wouldn't work, as noted above, as it means the restricted
membership might end up with a near-automatic right to make the decision.

I continue to believe that having the *whole* affected working group
make these decisions is the most effective and transparent way to
get the work done.  That way it gets the benefit of all the perspectives
(be it that of the FSF, some WG participants' patent counsels, or the
real-life risk assessment of the developers involved).   It is already
possible to request the AD to get input from the IETF's patent counsel,
which is delivered to the IETF as a whole.  That costs money, of course,
and we don't do it for every document as a matter of course.  But
delivering that advice through this body doesn't seem to add much
to me.

Only my opinion, of course,
				Ted Hardie