Subject: IPR issues in RFC 3552, etc.

From: David Jablon <[email-masked]>
Date: Tue, 12 Aug 2003 12:11:12 -0400

Dear IPR WG members,

On August 2, 2003 I expressed a serious concern to the Internet Architecture Board (IAB) about some remarks in RFC 3552.  I believe that this document should not have been published in this form, and should not remain published in this form, and that publication of this document sets an extremely bad precedent for the IETF.  In my August 2 communication I requested information on how to proceed in trying to rectify this situation, and have to date received no such information from the IAB.

I am now writing to the Intellectual Property Rights (IPR) Working Group (WG) specifically because this is an IPR issue, and one that may be especially relevant in light of the recent work of this WG in reviewing IETF IPR policy.

Furthermore, this issue has led me to review some of the drafts that are currently in Last Call in this WG, which are related to this issue.  I would like to comment on those, despite yesterday's deadline, and I believe the WG would be wise to delay approval of at least some of these documents until the issues that I'm raising can be considered.

There are many concerns I have about handling IPR policy in the IETF, but there is one particularly offensive section in RFC 3552 that I will highlight here:

"A number of protocols ([EKE], [SPEKE], [SRP]) allow one to securely bootstrap a user's password into a shared key which can be used as input to a cryptographic protocol. One major obstacle to the deployment of these protocols has been that their Intellectual Property status is extremely unclear."

The second sentence is clearly an Intellectual Property (IP) statement regarding three techniques named in the first sentence.

I will focus my attention on this remark, where I see several serious issues:

1. It makes a statement about the IP status of the EKE, SPEKE, and SRP methods.

2. It further characterizes the IP status of these methods as "extremely unclear".

3. It further characterizes the deployment of these methods as being hampered by the allegedly extremely unclear IP status.

4. It makes these statements and characterizations without any written justification in this document.

5. At least some of these statements and characterizations are believed to be false by interested parties.

These issues combine to make the offending statement a clear violation of at least two important parts of the IETF's IPR policy as expressed in RFC2026.

	10.1.  General Policy
	In all matters of intellectual property rights and procedures, the intention is
	to benefit the Internet community and the public at large, while respecting
	the legitimate rights of others.

and

	10.4.  Notices
	(A)  Standards track documents shall include the following notice:
	"The IETF takes no position regarding the validity or scope of any
	intellectual property or other rights that might be claimed to pertain to the
	implementation or use of the technology described in this document or the
	extent to which any license under such rights might or might not be
	available; ..."

I will not address the fourth and fifth issues in detail in the remainder of this memo, except to say that they are a real concern, and may related to important issues for the IPR WG to consider.  Suffice it to say that there are parties offended by this section of RFC 3552.

The violation of 10.1 should be obvious.  The violation of 10.4 is perhaps more subtle.

The specific language of 10.4 states limitations on the positions the IETF takes regarding the IPR of technology that are *specified* in a document, rather than technology that is merely discussed or referenced in a document.  One might argue that this simply imposes no rules for what the IETF says about IPR in regards to technology that is discussed in a casual manner, and since this RFC itself does not specify technology, then 10.4 should not apply.

Such a narrow interpretation of 10.4 would be truly perverse, and contrary to the spirit of fair and reasonable practice.  It would permit anyone who manages to slip an off-hand IPR statement into any IETF document to block any chosen technology from ever again being standardized in the IETF.  The mere fact that an IETF IPR statement then exists, and remains published, means that no standards track document can honestly include the 10.4 Notice that says that the IETF has NOT taken an IP position in the technology, and thus cannot be compliant with RFC 2026.  This is just one of the perverse situations that RFC 3552 creates.

I'd like to presume that this is simply an unintended consequence of an ill-considered remark.  However, if this was truly the intention of parties in the IAB then they should be ashamed, and larger concerns exist than what I've outlined so far.

I do not have time at the moment to suggest a proper remedy; I am probably not the person to do that, and I am probably not the only offended party.  I do believe that the best solution will require some interaction, and hopefully some lessons can be learned from this to help the IPR WG in its plans to refine the processes for handling IPR issues.

Sincerely,

David Jablon

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

---

From: Pekka Savola <[email-masked]>
Date: Wed, 13 Aug 2003 14:57:31 +0300 (EEST)

On Tue, 12 Aug 2003, David Jablon wrote:
[...]
> "A number of protocols ([EKE], [SPEKE], [SRP]) allow one to securely
> bootstrap a user's password into a shared key which can be used as input
> to a cryptographic protocol. One major obstacle to the deployment of
> these protocols has been that their Intellectual Property status is
> extremely unclear."
[...]
> 3. It further characterizes the deployment of these methods as being
> hampered by the allegedly extremely unclear IP status.
> 

<aside>
I'm sure that for example SCO certainly believes all the IPR
situation of Linux kernel is very clear and everybody should immediately
contact them to obtain a very reasonable $199/$699 license
[http://www.sco.com/scosource/description.html]. Truth is very probably
quite near the opposite, but of course SCO does not like to see the
situation that way.
</aside>

I.e., some _invididuals_ have determined that the licensing of EKE, SPEKE,
and SRP is extremely unclear.  They're allowed to say so (putting that in
an IAB document may have been a bit bad judgment, unless they have very
strong opinions on this, I can't tell).

Certainly at least those parties whose alleged IPR is allegedly infringed
are always willing to state that the IPR status is crystal clear and are
almost always willing to give very "reasonable" and clear licenses.

But that still does not change the facts for the consumers of those 
technologies.

Note: I haven't participated in the creation of that RFC, nor do I know 
the details of EKE, SPEKE and SRP IPR status in detail.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Scott W Brim <[email-masked]>
Date: Wed, 13 Aug 2003 08:06:56 -0400

I suspect they simply meant that the WG participants were unclear about
the status.  

In any case I don't see how your mail affects anything in what the IPR
WG has produced.  The most you could possibly be pointing out is a
failure in application of the policies/procedures, not any defect in the
policies/procedures themselves.

---

From: David Jablon <[email-masked]>
Date: Wed, 13 Aug 2003 13:56:57 -0400

Scott,

Well, the related issue I was thinking of was the case study of the IPS SRP
situation in the Guidelines draft, which I believe should be expanded to
present alternate viewpoints.

It might be possible to learn something from that.
But I don't know for sure.

-- David

At 08:06 AM 8/13/03 -0400, Scott W Brim wrote:
[...]

---

From: Scott W Brim <[email-masked]>
Date: Wed, 13 Aug 2003 15:00:27 -0400

> But I don't know for sure.

It might be possible to learn from the fact that there were alternative
views?  An interesting thought.  If you're willing to wait to explore
that, there will definitely be another version in the future.  I'll save
this mail.

If you want to see specific text changed in the current version before
it goes to (informational) RFC, please provide details.  

..swb

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Aug 2003 09:52:27 +0200

I'm confused.

If this is an appeal under RFC 2026, the route is Area Director, then IESG,
and only then IAB. (And presumably some members of the IAB would recuse
themselves.)

And I can't find anything in the message suggesting changes to the drafts
being produced by the IPR WG.

So I'm not sure why this was cross-posted to these two lists at this time.

Regards
    Brian

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 

NEW ADDRESS <[email-masked]> PLEASE UPDATE ADDRESS BOOK

---

From: Geoff Huston <[email-masked]>
Date: Thu, 14 Aug 2003 20:33:30 +1000

For the information of WG members, and to assist placing David's message in context,
the IAB has made the following response to David.

(David had queried the IAB on the wording of a section of RFC3552).

regards,

   Geoff Huston

-----

Date: Sun, 10 Aug 2003 20:33:09 +1000
To: David Jablon <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: IP opinions in IETF documents
Cc: [email-masked]

David,

Thanks for your note to the IAB.

The IAB has reviewed the comments made in RFC3552, and notes that the observation made there regarding lack of clarity of IPR issues in this area appears to be a reasonable external observation, given the number of interested parties and the nature of their various IPR claims. It is noted that the statement in that document is an observation on historical impediments to deployment of SPEKE and similar technologies, and does not speak to the future of such technologies.

As noted on the IETF's IPR web page, "the IESG/IETF take no position regarding the validity or scope of any intellectual property right or other rights that might be claimed to pertain to the implementation or use of the technology, or the extent to which any license under such rights might or might not be available." We would see the comments made in RFC 3552 as being entirely consistent with this position.

Regards,
Geoff Huston
Executive Director, IAB

---

From: David Jablon <[email-masked]>
Date: Tue, 19 Aug 2003 01:24:19 -0400

At 03:00 PM 8/13/2003 -0400, Scott W Brim wrote:
>On Wed, Aug 13, 2003 01:56:57PM -0400, David Jablon allegedly[?] wrote:
>> [...] I believe [the IPS SRP case study in the Guidelines draft] should be expanded to
>views? [...]

Um, no.  I was suggesting that it might be possible to learn something
if a reporter of the IPS SRP case solicited, listened to, and reported
on the various points of view.

Even besides my concerns, I think it's a fascinating case that can
reveal a lot about what can go right, and wrong, when dealing with IPR issues.
I can think of maybe six different viewpoints, and dealing with these in a way
that's respectful of everybody's IPR, etc. is no easy task, so I'm in
no way belittling the current effort to date.

>[...] An interesting thought.  If you're willing to wait to explore

In case I wasn't clear, I think it would be a mistake to publish this as
an informational RFC due to the incomplete description of that case.

I doubt that most of the participants in that case read this mailing list,
and I happened upon it only by circumstance.  It might require some
outreach to get the necessary feedback to provide a full story.
Just a thought.

-- David

---

From: Scott W Brim <[email-masked]>
Date: Tue, 19 Aug 2003 09:13:48 -0400

> an informational RFC due to the incomplete description of that case.

Could you please send me a much more detailed piece of mail, saying not
only what you think is wrong (specifically) but also suggesting
replacement text?  First let's do it direct, without CCing the group,
and we'll bring our recommended changes back to the list.  OK?

..swb