Re: [dhcwg] IPR disclosure and <draft-ietf-dhc-subscriber-id-06.txt>

Ted Lemon <mellon@fugue.com> Wed, 02 June 2004 06:02 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03381; Wed, 2 Jun 2004 02:02:17 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVNqv-00076d-5f; Wed, 02 Jun 2004 00:59:49 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1BVN6B-0003hU-Fk for dhcwg@megatron.ietf.org; Wed, 02 Jun 2004 00:11:31 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22250 for <dhcwg@ietf.org>; Wed, 2 Jun 2004 00:11:27 -0400 (EDT)
Received: from ietf-mx.ietf.org ([132.151.6.1] helo=ietf-mx) by ietf-mx with esmtp (Exim 4.32) id 1BVN67-0001ga-Op for dhcwg@ietf.org; Wed, 02 Jun 2004 00:11:27 -0400
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1BVN58-0001C7-00 for dhcwg@ietf.org; Wed, 02 Jun 2004 00:10:27 -0400
Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1BVN49-0000hq-00 for dhcwg@ietf.org; Wed, 02 Jun 2004 00:09:25 -0400
Received: from [10.0.1.170] (dsl081-147-128.chi1.dsl.speakeasy.net [64.81.147.128]) by toccata.fugue.com (Postfix) with ESMTP id E3A071B2D15 for <dhcwg@ietf.org>; Tue, 1 Jun 2004 23:08:49 -0500 (CDT)
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Resent-Date: Tue, 01 Jun 2004 23:09:25 -0500
Message-Id: <A267FAFC-B44A-11D8-9004-000A95D9C74C@fugue.com>
Content-Transfer-Encoding: 7bit
Resent-To: dhcwg@ietf.org
Resent-Message-Id: <7FB2A258-B44A-11D8-9004-000A95D9C74C@fugue.com>
From: Ted Lemon <mellon@fugue.com>
Subject: Re: [dhcwg] IPR disclosure and <draft-ietf-dhc-subscriber-id-06.txt>
Resent-From: Ted Lemon <mellon@fugue.com>
Date: Tue, 01 Jun 2004 23:08:27 -0500
To: Ralph Droms <rdroms@cisco.com>
X-Mailer: Apple Mail (2.618)
Resent-Date: Wed, 02 Jun 2004 00:09:25 -0400
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60
Content-Transfer-Encoding: 7bit
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: 7bit

"Reasonable and Non-discriminatory" sounds really nice and comforting, 
but what does it actually mean?   "Reasonable" has no explicit, 
enforceable meaning whatsoever.   It implies that the fee charged for 
use of the technology will be affordable, but by whom?   And why imply 
it - why not just say it?   Sure, in a court of law, "reasonable" is 
better protection than nothing, but it's not much better.   
"Non-discriminatory" implies that all implementors will be subject to 
the same fee structure, which may be unaffordable to some without going 
against the meaning of the phrase.

Generally speaking, what geeks like us mean when they say "reasonable 
and non-discriminatory" is "there won't be a fee or any patent 
enforcement unless you take patent enforcement action against us 
first."   I think this is even what the legal folks writing these IPR 
notices intend when they write them.   The problem is that the language 
they are using actually means something else, and provides no 
protection at all to implementors of RFCs where such implementations 
would infringe.   Like using sprintf when you should have used 
snprintf, this does us no harm in the usual case, but could do us great 
harm if something goes wrong.   This is not an idle worry - we have all 
seen, on many occasions, IPR holding companies do their worst with IP 
rights that were originally acquired as protection, not as a revenue 
source, after a failed dot-com's assets were purchased by someone else.

For my own part, I am against putting the working group's stamp of 
approval on technology that is encumbered under the "reasonable and 
non-discriminatory" label, not because I do not trust the intentions of 
those who wrote the IPR statements, nor because I don't trust the 
intentions of those whose names are on the patents, but simply because 
those people may not be the people who wind up enforcing the IPR 
statements in the future, and the IPR statements provide plenty of 
wiggle-room for much more draconian enforcement.

My vote is to put both these drafts on the back burner until owners of 
the intellectual property rights associated with them submit IPR 
declarations stating that they will not charge for the use of this 
technology except in cases where the user of the technology has taken 
some kind of IPR enforcement action against them.   I think this is 
what they intend anyway, which is great, but I don't think it's 
unreasonable to ask to have it in writing before we proceed.   The 
involved parties here are reasonable people, so I see no reason to 
think that, given a reason for doing so, they will not do the right 
thing.

I would like to point out, by the way, that this is a quite mainstream 
viewpoint, and is  not in conflict with the latest IETF RFCs on 
intellectual property rights.   I would suggest reading the whole of 
each RFC, not just choice selections from them.  I mention this only 
because the last time this came up, someone (I forget who) said that it 
was the IESG's job to figure this stuff out.   In fact the IETF policy 
on this is pretty clear - it's generally up to the working group to 
make the tradeoff as to whether or not to write specifications that use 
patented technology.   It's certainly allowed for the IESG or the IETF 
as a whole to intervene if it's perceived that the working group has 
made a mistake, but the onus is on the working group to make the 
initial call.

So let us not make a mistake - let us hold these drafts back until we 
get IPR statements that are clear, that protect the owners of the IP 
rights, but that do not needlessly endanger implementors of these RFCs.


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg