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
- [dhcwg] IPR disclosure and <draft-ietf-dhc-subscr… Ralph Droms
- Re: [dhcwg] IPR disclosure and <draft-ietf-dhc-su… Ted Lemon
- RE: [dhcwg] IPR disclosure and <draft-ietf-dhc-su… Steve Gonczi
- Re: [dhcwg] IPR disclosure and <draft-ietf-dhc-su… Bud Millwood