Subject: Re: [tcpm] ipr and the tcp roadmap

From: "Reiner Ludwig (AC/EDD)" <[email-masked]>
Date: Fri, 26 Aug 2005 13:04:58 +0200

Sorry for this late reply, but I was out of e-mail coverage for some time.

I just want to add a few more facts for this group to consider, and will 
also add my personal view.

More facts:
-----------

* Ericsson has played by the IETF rules (RFC2026) right from the start: 
when I first presented Eifel at the IETF, I also declared that Ericsson 
might have IPR related to Eifel. Going even beyond RFC2026, Ericsson 
has even submitted http://www.ietf.org/ietf/IPR/ERICSSON-EIFEL ensuring 
that the research community would have no problem experimenting with the 
Eifel algorithm.

* Ericsson will continue to comply with RFC2026; in particular to Sec. 
10.3.2. (C):
       Where the IESG knows of rights, or claimed rights under (A), the
       IETF Executive Director shall attempt to obtain from the claimant
       of such rights, a written assurance that upon approval by the IESG
       of the relevant Internet standards track specification(s), any
       party will be able to obtain the right to implement, use and
       distribute the technology or works when implementing, using or
       distributing technology based upon the specific specification(s)
       under openly specified, reasonable, non-discriminatory terms.
       The Working Group proposing the use of the technology with respect
       to which the proprietary rights are claimed may assist the IETF
       Executive Director in this effort.  The results of this procedure
       shall not affect advancement of a specification along the
       standards track, except that the IESG may defer approval where a
       delay may facilitate the obtaining of such assurances.  The
       results will, however, be recorded by the IETF Executive Director,
       and made available.  The IESG may also direct that a summary of
       the results be included in any RFC published containing the
       specification.

* Ericsson has in 2000 already submitted such a "written assurance": 
http://www.ietf.org/ietf/IPR/ERICSSON-General which is also cited in 
http://www.ietf.org/ietf/IPR/ERICSSON-EIFEL

* It is an industry standard that licensing negotiations including the 
disclosure of licensing terms are only conducted under a non-disclosure 
agreement (NDA). I.e., without signing an NDA company A does not even 
get to see the licensing terms that company B would put on to the table.

* One company that approached Ericsson to obtain a license for the Eifel 
algorithm was not willing to sign the required NDA.

My very own personal view (not necessarily Ericsson's view):
------------------------------------------------------------

* The members of TSVWG, and the IESG knew for a long time that Ericsson 
had declared that Ericsson might have IPR related to Eifel. Still, both 
the TSVWG and the IESG approved RFC4015 as Proposed Standard. Thus, I 
don't understand on what basis the TCPM WG would not list RFC4015 under 
the "standard mechanisms" section of the TCP roadmap document. To me 
that would seem like the TCPM WG could overrule decisions that have 
already been made by the TSVWG and the IESG. At this point, RFC4015 is a 
standards track specification, and the way I understand how the IETF 
works only the IESG can change that status. Please, correct me if I'm wrong.

* I would not be suprised if the mentioned company that is not willing 
to sign the NDA required to enter into licensing negotiations with 
Ericsson is the same company that seems to leave the impression within 
the IETF that Ericsson was not acting reasonable in its licensing business.

* I want to make this very explicit: Ericsson is a fair player that will 
stick to its assurance: http://www.ietf.org/ietf/IPR/ERICSSON-General. 
And I'm sure that in the near future there will be companies that will 
be able to attest that.

///Reiner

Mark Allman wrote:
>  
> Folks-
> 
> We tried to start some discussion about IPR-ed RFCs within the TCP
> roadmap document some time back, but were not what one might call
> "clear" on the subject.  So, this is a second try.  To make sure this
> note is correct on the IPR issues Scott Bradner has reviewed it.
> 
> To step back for a moment and remind folks...  When Jon Peterson was
> doing his AD review of the TCP roadmap after it passed WGLC he sent us a
> query as to whether the WG had discussed the inclusion and/or placement
> of the Eifel response algorithm (RFC 4015) with regards to the IPR claim
> filed about this document.  The answer to Jon's question is that the WG
> did not consider the question and so process-wise we need to back-track
> and think about whether or how this statement impacts the roadmap.
> 
> The facts:
> 
>   * RFC 4015 has been published as a proposed standard.
> 
>   * According to IETF policy, Ericsson has filed an IPR statement on RFC
>     4015 (& RFC 3522).  The statement is at:
> 
>        http://www.ietf.org/ietf/IPR/ERICSSON-EIFEL
> 
>     Loosely speaking the statement grants open source operating systems
>     the ability to use Eifel without paying royalties, but non-open
>     source implementations are not covered.
> 
>   * We (Scott) know of at least one case in which Ericsson has, in fact,
>     has requested royalties in exchange for a license to use the
>     technology in RFC 4015.
> 
>   * Currently, the TCP roadmap (draft-ietf-tcpm-tcp-roadmap-04.txt)
>     lists the Eifel response algorithm (RFC 4015) in section 3 on
>     "standard enhancements".  The first sentence in that section says...
> 
>        "This section describes recommended TCP modifications that
>        improve performance and security."
> 
> The question on the table is then with the above context how (if at all)
> should RFC 4015 be handled in the roadmap document?  The space of
> possible ways to handle Eifel in the roadmap is something like this ...
> 
> (1) We can remove mention from the roadmap all together.
> 
> (2) We can leave the roadmap exactly how it is.  That is, the WG can
>     decide that the IPR issues do not merit the changing of the
>     classification of the technology at all.
> 
> (3) We can move the RFC 4015 item (including all text) from the
>     "standard mechanisms" section of the document to some other existing
>     place in the document - for instance the "experimental extensions"
>     section.  (This would require a bit of change to the header of the
>     "experimental extensions" section in that it would need to indicate
>     inclusiveness for things that we need more licensing experience with
>     (for instance).)
> 
> (4) We could create a new section of the document that explicitly has no
>     recommendation attached to the items listed within.
> 
> RFC 4015 naturally falls within the "standard mechanisms" if you just
> look at its current status (PS) and the placement of other changes with
> the same status.  So, any movement of RFC 4015 from that location will
> have to be explained in the document.  This is another area of general
> confusion as far as IPR goes --- at least to some of us.  Our
> discussions with Scott indicate:
> 
>   * While we can discuss the IPR in all its gory detail, its
>     implications, etc. on the mailing list the document cannot comment
>     on the IPR itself.  The IETF does not make IPR judgments -- even if
>     individual members might use such judgments as part of their input
>     to the process.  Therefore, the document cannot say that we think
>     the IPR claim is bogus and wouldn't stand up, or that we think the
>     license is fair, or it's not, etc.
> 
>   * To justify the placement of Eifel somewhere besides where it would
>     naturally fall we can comment on the WG's decision making process
>     within the document.  That is, we can say that we have placed RFC
>     4015 in section X following a WG discussion about the IPR claimed on
>     the technology outlined within 4015.
> 
> We need to hear thoughts on which path folks think we should be taking
> with regards to the inclusion and the placement of RFC 4015 within the
> roadmap such that we can clear up this process issue and get the
> document back in the hands of the IESG.
> 
> Thanks in advance!
> 
> Mark & Ted
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tcpm

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

---

From: Tim Shepard <[email-masked]>
Date: Fri, 26 Aug 2005 07:58:32 -0400

> get to see the licensing terms that company B would put on to the table.

I have never heard of anything like that.

Even if it is "industry standard", it is the first time I've heard
anyone allege that one has to sign an NDA to learn what the
"reasonable, non-discriminatory terms" are.  

It would seem that the NDA is to ensure that no one can ever discover
(and disclose) that the terms are in fact *not* non-discriminatory.

If in fact the terms are non-discriminatory, then there can be no
reason to require an NDA to divulge what the terms are.

I cannot think of any other reason.

The patent and the lack of a general license available to everyone
makes the value of deploying this technology less than the cost of the
hassle.   So it would be appropriate for the IETF to move this off of
the standards track, because of the patent.

			-Tim Shepard
			 [email-masked]

---

From: Mark Allman <[email-masked]>
Date: Fri, 26 Aug 2005 09:22:06 -0400

Thanks for the note Reiner!

> had declared that Ericsson might have IPR related to Eifel. Still,
> both the TSVWG and the IESG approved RFC4015 as Proposed
> Standard. Thus, I don't understand on what basis the TCPM WG would not
> list RFC4015 under the "standard mechanisms" section of the TCP
> roadmap document. To me that would seem like the TCPM WG could
> overrule decisions that have already been made by the TSVWG and the
> IESG. At this point, RFC4015 is a standards track specification, and
> the way I understand how the IETF works only the IESG can change that
> status. Please, correct me if I'm wrong.

Let's try to be more clear.  No matter if or where or how RFC 4015 is
cited in the roadmap (even when the roadmap becomes an RFC itself), RFC
4015's status will not be changed from Proposed Standard.  RFC 4015's
status could be changed from Proposed Standard by other means.  But, the
roadmap document is an informational, non-normative, document and the
document makes zero mention of changing RFC 4015's status.

In other words, even if the roadmap document were to list RFC 4015 in
the "experimental extensions" section of the document for whatever
reason (e.g., because the WG/IETF does not want to "strongly encourage"
RFC 4015's use or because of concerns about RFC 4015 depending on
experimental RFCs or whatever else) that does not mean that a TCP
implementation that supports RFC 4015 is any more or less standards
compliant than if the roadmap were to list RFC 4015 in the "standard
mechanisms" section.

Folks- from the recent meeting in Paris and the comments on the list it
would seem as if consensus is that RFC 4015 should be moved to the
"experimental extensions" section of the roadmap.  If you disagree,
please speak up soon because we'd really like to get this issue closed
and get the document moving again.

allman

---

From: Joe Touch <[email-masked]>
Date: Fri, 26 Aug 2005 06:40:37 -0700

Reiner Ludwig (AC/EDD) wrote:
...
> My very own personal view (not necessarily Ericsson's view):

The sections of the document reflect, IMO, more of the actual status of
the document than IETF standards-track, e.g., some experimental
extensions are informational.

In that same spirit, some standards-track docs are experimental as well,
in the sense that although PS, they may appear not to be gaining
momentum to go to DS.

Joe

---

From: Ted Faber <[email-masked]>
Date: Fri, 26 Aug 2005 08:22:05 -0700

> the standards track, because of the patent.

While that's a defensible opinion, it's not the issue on the table.
That issue is where the roadmap places Eifel in its structure.  That
structure is related to the IETF standards structure, but not isomorphic
to it.

I'm not sure how one might move an published IETF standard off the
standards track, but that's not what tcpm is trying to do right now.

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Reiner Ludwig <[email-masked]>
Date: Sat, 27 Aug 2005 08:42:29 +0200

Hi Mark,

all of what you wrote in your e-mail below is fine with me.

With my previous mail to this list I just wanted to point out clearly 
that 'company_A requests royalties for a technology' is not equivalent 
with 'company_A is "bad"'. I know, nobody said that Ericsson was "bad", 
but certain statements made in e-mails or on corridors at IETF meetings 
can be easily misunderstood.

This IPR/licensing stuff is every day business in the industry. And as 
long as this is carried out under reasonable and fair terms there is 
nothing wrong with that. The industry (not only in IT) is quite 
different from the collaborative research community. Companies that 
don't protect their development investments with IPR can get bitten. I'm 
sure that most companies that develop technology of some sort would 
agree to that.

I have met a number of people, in particular from the academic side of 
the research community, that are not really aware of that, or even have 
the simplistic attitude "IPR = Evil". And from my personal experience I 
must say that one has a good chance to meet such people within the IETF.

Concerning the roadmap document I would like to make the following 
proposal. Rename the section "standard mechanisms" to "recommended 
mechanisms". Maybe add that the word 'recommended' has nothing to do 
with how it's defined in RFC2119.

Then I would be fine with putting RFC4015 into the "experimental 
extensions" section if there is text that explains why RFC4015 (being a 
standards track spec.) is not placed into the "recommended mechanisms" 
section.

///Reiner

---

From: Reiner Ludwig <[email-masked]>
Date: Mon, 29 Aug 2005 09:12:47 +0200

... and adding on second thought ...

> standards track spec.) is not placed into the "recommended mechanisms" 

Maybe we could also change the section heading "experimental 
extensions" to simply "extensions". I think the current section headings 
are too easily associated with RFC status. And, the RFC status 
'experimental' has this negative touch of being a 
technology/specification that the IETF is not really convinced of.

///Reiner

---

From: Joe Touch <[email-masked]>
Date: Tue, 30 Aug 2005 11:42:48 -0700

Reiner Ludwig wrote:
>> extensions" section if there is text that explains why RFC4015 (being
>> a standards track spec.) is not placed into the "recommended
>> mechanisms" section.
> 
> Maybe we could also change the section heading "experimental extensions"
> to simply "extensions". I think the current section headings are too
> easily associated with RFC status. And, the RFC status 'experimental'
> has this negative touch of being a technology/specification that the
> IETF is not really convinced of.

The document has sections labelled 'standard', 'experimental', and
'historic', none of which necessarily corresponds to RFC status.
Although we might continue to wordsmith the document ad infinitum to
ensure that _everyone_ is clear on that point, IMO the doc is sufficient
as-is - esp given the explanation in the intro.

Joe