Subject: [dhcwg] draft-ietf-dhc-agentopt-radius-04.txt submitted for publication

From: Ralph Droms <[email-masked]>
Date: Thu, 12 Feb 2004 17:28:30 -0500

draft-ietf-dhc-agentopt-radius-04.txt has been revised to address comments
from an IESG-sponsored reviewer prior to IETF last call, and has been
submitted for publication at www.ietf.org (it should be announced sooon).
It's now ready for reconsideration by the IESG.

Because this document has been part of the recent discussion of IPR issues
on the dhcwg mailing list, I want to bring the document's status to the
attention of the WG.  This document contains a Terms of Use section with a
pointer to an IPR statement, http://www.ietf.org/ietf/IPR/CISCO-8021X.txt,
in accordance with the guidelines in RFC 2026.  Are there any objections to
returning the document to the IESG for reconsideration?

- Ralph

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Feb 2004 20:27:44 -0500

On Feb 12, 2004, at 5:28 PM, Ralph Droms wrote:
> Are there any objections to returning the document to the IESG for 
> reconsideration?

It sounds like you folks have some patent applications pending, and 
can't talk about exactly what's covered.   I think it might be best if 
the WG waited until the patents were made public before making a 
decision on this.   It's possible that the patents don't actually apply 
to the option, but just to what you're doing with 802.1x, and then 
there'd be no need for people to worry about infringing if they 
implemented this draft.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 12 Feb 2004 21:06:55 -0500

I'll find out when we can talk about what's covered.

However, hypothetically speaking, if we can't talk about what's covered
until, for example, a patent is actually granted, you might have to ask
me to come out of retirement to explain it.

- Ralph

At 08:27 PM 2/12/2004 -0500, Ted Lemon wrote:
>It sounds like you folks have some patent applications pending, and can't 
>talk about exactly what's covered.   I think it might be best if the WG 
>waited until the patents were made public before making a decision on 
>this.   It's possible that the patents don't actually apply to the option, 
>but just to what you're doing with 802.1x, and then there'd be no need for 
>people to worry about infringing if they implemented this draft.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Feb 2004 22:08:15 -0500

> me to come out of retirement to explain it.

 From my side, I'm willing to wait.   This is functionality I don't 
think is particularly useful, although it's certainly cool, and it 
requires a conforming DHCP implementation to be subject to the 
possibility of having to pay royalties (although I know Cisco's current 
practice is not to charge royalties in this case, it's still a 
potential risk down the road).

I would be curious to know what the position of other wg members is on 
this.

---

From: John Schnizlein <[email-masked]>
Date: Sat, 14 Feb 2004 07:24:29 -0500

The purpose of agentopt-radius is to enable interoperation of network
components. Blocking progress to an RFC would prevent the allocation 
of the code for this sub-option of the relay-agent information option.
The result is not necessarily to prevent use of the idea, but it would
require a vendor-specific solution. 

 From a practical perspective, advancing this document is just about
defining the sub-option so that everybody can use it. It does not
require anybody to use it. Advancing the document is not endorsing
the idea, just enabling others to interoperate with it.

The reason for the patent application was to protect us from claims by 
others that they invented the idea and were entitled to compensation.
This protects everyone, but since compensation is usually sought from 
a source with deep pockets, the company needs it. As you noted, Cisco's
practice has been to defend its rights and promote interoperation,
rather than to earn royalties. My protective intent in this application
was reviewed and determined consistent with corporate policy.

In my opinion, it is not possible to separate the patent from the use
of this sub-option. Further elaboration of the details of the patent
would not change this. Waiting for a patent award is blocking the
sub-option.

The utility of the idea will be proved (or disproved) in practice, but
my opinion is that others should have the opportunity to interoperate
with it, which is what is enabled by the proposed standard. Because 
you do not see enough utility to choose to participate now is not 
a very good reason to block progress that others might value.

Since it is reasonable to balance potential utility against risk, 
consider the risk. Courts decide what is reasonable (which is why the
new IETF RFCs on IPR don't define it). Courts tend to treat deception 
and misdirection harshly. It would be risky for a company to establish 
long-standing support of specifications for the purpose of 
interoperation, without any demand for royalties, and then later
demand royalties without good reason. The amount of risk depends on 
how much can be lost, which sometimes means how much you have. There 
is no certainty here because courts sometimes decide in ways that 
surprise us.

Regarding surprises, we agree that filing a statement on the (obscure)
web site, which is unfortunately the best the IETF can require now,
does not provide sufficient clarity. That is why we included a clear 
statement of the fact that there was a patent application in every 
version of our draft since November 2001. 

The alternatives are clear: enable interoperation with the sub-option,
or block it with (indeterminate) delay until IPR issues are resolved.
My opinion is that it would be unfair to block it now, after years of
work, because of new demands for a royalty-free IPR statement. 

John

At 10:08 PM 2/12/2004, Ted Lemon wrote:
>>However, hypothetically speaking, if we can't talk about what's 
>>covered until, for example, a patent is actually granted, you 
>>might have to ask me to come out of retirement to explain it.
>
> From my side, I'm willing to wait.   This is functionality I don't think is particularly useful, although it's certainly cool, and it requires a conforming DHCP implementation to be subject to the possibility of having to pay royalties (although I know Cisco's current practice is not to charge royalties in this case, it's still a potential risk down the road).
>
>I would be curious to know what the position of other wg members is on this.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Feb 2004 12:51:34 -0500

Egads, I don't have any objection to allocating an option code as a 
transport for some information.   I just object to a standard that, if 
I implement it, subjects me to a possible royalty.   If a server or 
client implementation of this option (not the technique that it 
enables, but the option itself) does not infringe, I have no immediate 
problem (I still would rather that the underlying protocol were 
unencumbered, but I'm not interested in fighting that battle).   This 
is why I was asking for clarification of exactly what is covered.