Subject: RE: WG IPR guidelines (draft-brim-ipr-wg-guidelines-00.txt)

From: "Christian Huitema" <[email-masked]>
Date: Mon, 14 Oct 2002 16:11:02 -0700

> From: Scott W Brim [mailto:[email-masked]]
> 
> On Sun, Oct 13, 2002 05:52:10PM -0400, John Klensin wrote:
> > (4) At the end of 4.2, it might be worth commenting that PEM
> > ultimately largely failed, perhaps at least in part because the
> > encumbered technology, and the need to buy specific software to
> > implement the standard, was a bar to implementation and
> > deployment.
> 
> Did PEM "ultimately largely fail" because of IPR encumbrance?  Were
> there other factors, and if so what were they?

There were several other factors. The RSA patents would not have
prevented a deployment of PEM outside the US, and my team in France
actually worked on an implementation back then, but we did not deploy it
successfully. Among the other factors:

1) PEM was wrongly or rightly perceived as competing with PGP
2) Managing security certificates is probably harder than we thought
3) PEM was not well integrated with MIME, which appeared at about the
same time
4) Export of crypto was still regulated at the time; indeed, even use of
encryption was regulated in France until a few years ago

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 21 Oct 2002 13:22:24 -0400

One more comment on this, then I'll drop it.

--On Monday, 21 October, 2002 12:00 -0400
[email-masked] wrote:

> On Fri, Oct 18, 2002 05:19:46PM -0400, John C Klensin
> allegedly wrote:
>> The "note" I'm referring to is the entire last paragraph of
>> section 1, where "encumbered technology contributions" are
>> explicitly called out.
>> 
>> Suggestion:
>> 
>> (i)	In the abstract, change "how IPR issues" to "how IPR
>> 	issues, especially those concerned with encumberances on
>> 	the use of technology".
> 
> I can't see the usefulness of adding this text, either in the
> abstract or in the last paragraph of section 1.  Working
> groups will only be impacted by technology-related IPR.
> That's all that will appear in their umwelt.  Since they won't
> have to discriminate between technology-related and
> non-technology-related IPR, adding the extra words would just
> make the draft harder to digest without adding anything
> useful.  IMHO.

Actually, as has been discussed in an earlier subthread, WGs
have been "impacted" several times by arguments about rights to
the text they propose to put in their documents.  Several of our
current practices -- parts of the "Note Well" text and the
attempts to clarify rights in I-Ds included-- have been
influenced by those disputes about, e.g., whether a WG has the
right to lift text out of an I-D while changing editors.
Draft-brim-ipr-wg-guidelines-00.txt doesn't seem to addresses
that set of issues (nor do I think it should) and it is exactly
that intentional omission which I'm trying to get clarified.

regards,
    john

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 22 Oct 2002 17:18:26 -0400

In message <15810172.1035306835@localhost>, John C Klensin writes:

>>> 
>> 
>> John, I'm a bit confused here.  If things like "who owns the
>> text in a  working group I-D" have been problematic in the
>> past, why shouldn't it  be in this document?
>
>Because 
>
>	* it should be in Scott's document about submissions, 
>	
>	* this document doesn't really talk about that subject,
>	and because 
>	
>	* confusion among rules that apply to the rights in the
>	actual technologies that this doc does cover and those
>	copyright issues is one of the major areas in which we
>	have had problems with 2026 in the past.
>
>My hope is that, by separating the two, and being very explicit
>about what each document covers, we can make progress toward
>clarity.

Fair enough, though Brim's document ("Scott" is a multicast address 
here -- a phenomenon I'm very familiar with...) is Informational, and 
could in principle be used to explain cases from both of Bradner's 
documents.

		--Steve Bellovin, http://www.research.att.com/~smb (me)
		http://www.wilyhacker.com ("Firewalls" book)