Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt

From: David Ward <[email-masked]>
Date: Wed, 4 Mar 2009 16:40:38 -0600

Sue, Yakov -

This deadline has come and gone with zero comments on the re-LC of  
this draft. Given the comments and discussion on IPR disclosures on  
the IDR list in general, I (and the IESG) need a more concrete sign  
that the WG has consensus that the document should continue to  
progress towards publication.

------------

Related to IPR, I strongly encourage all IETF participants to read and  
understand:

       http://www.ietf.org/overview.html (read and understand the NOTE  
WELL)

       http://www.ietf.org/rfc/rfc3979.txt?number=3979

       http://www.ietf.org/rfc/rfc4879.txt

I refer the WG to these documents and pointers as well:

       http://www.ietf.org/rfc/rfc3669.txt?number=3669

       https://datatracker.ietf.org/ipr/

       http://wiki.tools.ietf.org/group/edu/attachment/wiki/IETF72/72newcomers.ppt 
   (page 48 - 56)

       Newcomer's training at the upcoming IETF held by the edu team  
on Sunday 2009.03.22 at 1300 in Imperial B (see https://datatracker.ietf.org/meeting/74/agenda.txt 
  for any changes)

If you have difficulty keeping up with IPR disclosures, here is an RSS  
feed of all IETF IPR disclosures:

feed:https://datatracker.ietf.org/feed/ipr/

If you believe that you'd like the ADs to spend some time in the  
RTGAREA WG meeting to provide some education on IPR issues, rule,  
requirements, etc at the IETF please contact us privately or mailto:[email-masked]

Thanks and hope it helps.

-DWard

On Feb 17, 2009, at 6:30 PM, Yakov Rekhter wrote:

> Folks,
>
> Given the recent IPR disclosure (https://datatracker.ietf.org/ipr/ 
> 1088)
> associated with the flow-spec draft
> (http://www.ietf.org/internet-drafts/draft-ietf-idr-flow-spec-05.txt )
> we are going to re-WG-LC the document and rerun the publication
> process.
>
> The deadline for comments is 3/2/2009.
>
> Sue & Yakov.
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: Tony Li <[email-masked]>
Date: Wed, 04 Mar 2009 15:02:04 -0800

David Ward wrote:
> Sue, Yakov -
> 
> This deadline has come and gone with zero comments on the re-LC of this 
> draft. Given the comments and discussion on IPR disclosures on the IDR 
> list in general, I (and the IESG) need a more concrete sign that the WG 
> has consensus that the document should continue to progress towards 
> publication.

I feel that the document, while technically worthy, should not progress 
given these IPR claims.

Please note that this is my blanket policy on any technology with 
outstanding IPR claims without royalty-free licensing, and is not 
specific to this work, its authors, or the employer's of the authors.

Regards,
Tony

---

From: Ross Callon <[email-masked]>
Date: Wed, 4 Mar 2009 18:25:20 -0500

I assume that this discussion is about the recent Juniper disclosure (if
there is another disclosure from another company please let me know).
The terms that are in the Juniper IPR disclosure include (I just got
this by googling the disclosure):

	If this standard is adopted, Juniper will not assert any patents
owned
	or controlled by Juniper against any party for making, using,
selling,
	importing or offering for sale a product that implements the
standard,
	provided, however that Juniper retains the right to assert its
patents
	(including the right to claim past royalties) against any party
that
	asserts a patent it owns or controls (either directly or
indirectly)
	against Juniper or any of Juniper's affiliates or successors in
title 	or against any products of Juniper or any products of any of
Juniper's
	affiliates either alone or in combination with other products;
and
	Juniper retains the right to assert its patents against any
product or
	portion thereof that is not necessary for compliance with the
standard.

Isn't this the legal words for "free if you don't try to inflict your
IPR against us"? I am pretty sure that these words were pretty much
copied from IPR disclosures to the IETF by other companies. 

I don't see how this contradicts your desire for "royalty-free
licensing". 

I do see that there would be some advantage in having the IETF come up
with preferred IETF words for disclosures with the goal of "free if you
don't try to inflict your IPR against us". However, agreeing to words
that we all like would be pretty obviously outside of the scope of IDR. 

Ross

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: 04 March 2009 18:02
To: David Ward
Cc: Yakov Rekhter; Ross Callon; [email-masked]
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt

> This deadline has come and gone with zero comments on the re-LC of
this 

Regards,
Tony

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 04 Mar 2009 15:30:30 -0800

Ross,

Ref: https://datatracker.ietf.org/ipr/1106/

It says:

"Royalty-bearing licenses will be available to anyone who prefers that
option."

Cheers,
R.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 04 Mar 2009 15:30:54 -0800

Hi Tony,

There seems to six basic types of licensing:

– Royalty-free license of right
– Royalty-bearing license of right
– Royalty-free discretionary license
– Royalty-bearing discretionary license
– Royalty-free voluntary license
– Royalty-bearing voluntary license

The draft in question is disclosed as "royalty-bearing license of 
right". The same terms are used in many other disclosures from many 
vendors with drafts and RFCs already in place.

I think as co-author of this draft I agree with your opinion and I hope 
it can be re-disclosed as royalty-free. That would make it fully 
complaint with rfc3979 expectations.

Many thx,
R.

---

From: Tony Li <[email-masked]>
Date: Wed, 04 Mar 2009 15:38:24 -0800

Hi Ross,

> I don't see how this contradicts your desire for "royalty-free

The problem is that this is just suspended royalties, not truly 
royalty-free.  Even with the defensive clause, it implies that there is 
a future quid-pro-quo.

Imagine company A provides technology X under these terms.  Now, company 
B comes along and implements X.  In the meantime, A discovers this and 
intentionally infringes B's IPR on technology Y.  If B sues A for 
intentional infringement on Y, then A sues B over X.  How is that fair?

If companies are going to be altruistic and contribute to the standards 
process, then they should simply contribute.  If not, they should stay 
home and stay proprietary.

Under the IETF rules, the WG gets to decide on how to proceed and given 
that we can live without this technology, I would prefer to simply pass 
on it.  Nothing personal all around.

Regards,
Tony

---

From: Ross Callon <[email-masked]>
Date: Wed, 4 Mar 2009 19:07:51 -0500

The problem with your argument is that companies that did not contribute
to the work almost certainly have filed patents on at least the same
idea (whether motivated by this work, or independent of it). Thus, if
the people who actually do the work in the IETF say "we give up all
rights to patents that we have on this work", then the other companies,
who did not contribute, can go to court and say that they own the
technology (since they also have patents on the same thing, and they
didn't give up their rights since they didn't need to because they
didn't contribute the work -- even if they were sitting in the back of
the room at the time). 

To me the right result of standards is that any company can use the
resulting standards without royalty. The text in this disclosure is the
closest that I have seen (I am not a lawyer) to allowing anyone to use
the standard without any royalty. What you are proposing would defeat
this, specifically by requiring companies who did the work to pay
royalties to companies or people who did not do the work. This would be
a severe disincentive to anyone who would consider contributing to IETF
efforts in the future.

A related point is that the words in this disclosure are almost
identical (the company name has been changed) from multiple other
disclosures by other companies related to different documents. The IETF
has lots of standards that are covered by disclosures just like this
one. Should we remove all of them? 

In your example, if we believe in standards, and if the technologies are
closely related, then X and Y should both be standardized in the IETF,
and both should be subject to the same "don't sue us and you can use it
for free" terms. 

Ross

-----Original Message-----
From: Tony Li [mailto:[email-masked]] 
Sent: 04 March 2009 18:38
To: Ross Callon
Cc: Yakov Rekhter; [email-masked]; David Ward
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-flow-spec-05.txt

Hi Ross,

Regards,
Tony

---

From: Tony Li <[email-masked]>
Date: Wed, 04 Mar 2009 21:53:31 -0800

Hi Ross,

> didn't contribute the work -- even if they were sitting in the back of

This assumes that everyone has patents on everything.  In any sane 
(stipulate optimism) world, only one of those is valid.  Further, I'm 
not suggesting that folks give up their rights.  Rather, they give 
royalty-free licenses.

> a severe disincentive to anyone who would consider contributing to IETF

We share the goal, but we disagree on the outcome.  The only ones who 
get paid are those that have valid claims and did not participate. 
Can't stop those folks anyhow...

> one. Should we remove all of them? 

As Dave points out, I've opposed all of them equally.  ;-)   While I'm 
not Quixotic enough to undo water under the bridge, I'm still more than 
happy to add to the set.

> and both should be subject to the same "don't sue us and you can use it

Or... both should just be royalty-free.  Same outcome.  ;-)

Tony

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 5 Mar 2009 09:04:06 -0800

Dave,

> progress towards publication.

Agreed. 

With this in mind I'd like to ask members of the WG to reply to
this e-mail with either "yes" or "no" (where "yes" means progress
draft-ietf-idr-flow-spec towards standardization, and "no" means
do not progress draft-ietf-idr-flow-spec towards standardization).

Please note that (a) silence does not count either way, and (b) a
handful of "yes" or "no" does not make consensus either way.

The deadline for response is March 19, 2009.

Yakov.

---

From: Cayle Spandon <[email-masked]>
Date: Thu, 5 Mar 2009 12:35:52 -0500

> do not progress draft-ietf-idr-flow-spec towards standardization).

yes

---

From: Rahul Aggarwal <[email-masked]>
Date: Thu, 5 Mar 2009 10:59:59 -0800

Hi Yakov,

Yes.

rahul

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 05 Mar 2009 12:36:05 -0800

Hi Yakov,

Since the only reason for WG last re-call was the IPR disclosure and
since other WG members already voiced the concern regarding current
royalty-bearing license wouldn't it be much more effective to hold this
WG last call till the IPR rights are sorted out ?

By sorted out I would consider either of the below:

* A statement from the author of the last disclosure to this WG that the 
disclosure https://datatracker.ietf.org/ipr/1106/ is a final one.

* A new disclosure resubmission with clear royalty-free license of right.

Many thx,
R.

---

From: Tony Li <[email-masked]>
Date: Thu, 05 Mar 2009 19:22:22 -0800

> do not progress draft-ietf-idr-flow-spec towards standardization).

No thank you.

Tony

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 6 Mar 2009 10:52:19 +0200

Yakov,

I've held back from replying until now because of my job affiliation,  
but since you ask:

Yes.

I'd like to think that I would have said the same regardless of  
affiliation though it's hard to prove a hypothetical.

FWIW I've read the current arguments related to IPR issues.  My  
*personal* feeling about this is that I think the current situation  
with IPR is pretty awful, but that problem and its remedies are both  
far beyond the scope of what the IETF is competent and able to  
accomplish.  Although the IETF is famous for trying to boil the ocean,  
it would be great to skip that step this time.

IMO the (corrected) licensing terms that were disclosed are nearly the  
least repulsive possible, and probably the least repulsive that it's  
reasonable to expect.

Making the best of a bad situation,

--John

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 06 Mar 2009 01:06:39 -0800

Hi John,

> least repulsive possible, and probably the least repulsive that it's 

Just FYI I examined few other IPR disclosures and apparently there are 
many more offering royality-free licences yet containing protection 
against patent litigations. They apparently can go together just fine.

Example:

Subject to the terms and conditions of this License, Google hereby 
grants to You a perpetual, worldwide, non-exclusive, no-charge, 
royalty-free, irrevocable (except as stated in this License) patent 
license for patents necessarily infringed by implementation (in whole or 
in part) of this specification. If You institute patent litigation 
against any entity (including a cross-claim or counterclaim in a 
lawsuit) alleging that the implementation of the specification 
constitutes direct or contributory patent infringement, then any patent 
licenses for the specification granted to You under this License shall 
terminate as of the date such litigation is filed.

Btw:

Results 1-10 of about 2,150 for "royalty-free" AND IPR. (0.14 seconds)
Results 1-10 of about 198 for "royalty-bearing" AND IPR. (0.24 seconds)

SRC: http://www.googlesyndicatedsearch.com/u/ietf
The query results are self explanatory :).

Cheers,
R.

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 6 Mar 2009 11:39:27 +0200

Robert,

Summary, I think you're not correct in characterizing the current  
disclosure as "royalty-bearing".

I don't see how the license you quoted is very different from the one  
published with the recent (corrected) IPR disclosure (http://www.ietf.org/ietf/IPR/juniper-ipr-draft-ietf-idr-flow-spec-03.txt 
):

"If this standard is adopted, Juniper will not assert any patents  
owned or controlled by Juniper against any party for making, using,  
selling, importing or offering for sale a product that implements the  
standard, provided, however that Juniper retains the right to assert  
its patents (including the right to claim past royalties) against any  
party that asserts a patent it owns or controls (either directly or  
indirectly) against Juniper or any of Juniper's affiliates or  
successors in title or against any products of Juniper or any products  
of any of Juniper's affiliates either alone or in combination with  
other products; and Juniper retains the right to assert its patents  
against any product or portion thereof that is not necessary for  
compliance with the standard."

There are some differences between this and the license you quote, and  
I'm not a lawyer so prefer to avoid a detailed analysis of those  
differences, but to a first approximation the above paragraph is the  
same as what you mention: a royality-free licence containing  
protection against patent litigation.  The following paragraph does  
mention royalties:

but it's only provided as an option for those who don't choose the  
mutually assured destruction version provided by the first paragraph.   
This is an *expansion* of the options available, not a reduction.  The  
license you quote below is substantially the same as the first  
paragraph quoted above, but omits the expansion of options provided by  
the second paragraph quoted above.  (I don't think this makes any real  
difference; the patent holder can choose to offer a royalty-bearing  
license whether or not that is explicitly stated in the IPR disclosure.)

I would have thought this to be obvious, but the mere presence of the  
string "royalty-bearing" in the IPR statement is absolutely not a  
reason to characterize the overall terms as royalty-bearing rather  
than royalty-free.  For this reason, I think the search results you  
cite, far from being "self explanatory", are basically meaningless.

Perhaps it was a marketing error not to use the string "royalty-free"  
in the IPR statement.

--John

On Mar 6, 2009, at 11:06 AM, Robert Raszuk wrote:

> Hi John,
>
>> IMO the (corrected) licensing terms that were disclosed are nearly  
>> the least repulsive possible, and probably the least repulsive that  
>> it's reasonable to expect.
>
> Just FYI I examined few other IPR disclosures and apparently there  
> are many more offering royality-free licences yet containing  
> protection against patent litigations. They apparently can go  
> together just fine.
>
> Example:
>
> license for patents necessarily infringed by implementation (in  
> whole or in part) of this specification. If You institute patent  
> litigation against any entity (including a cross-claim or  
> counterclaim in a lawsuit) alleging that the implementation of the  
> specification constitutes direct or contributory patent  
> infringement, then any patent licenses for the specification granted  
> to You under this License shall terminate as of the date such  
> litigation is filed.
>
> Btw:
>

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 6 Mar 2009 11:40:29 +0200

Robert,

> There seems to six basic types of licensing:
...
> right".

Is this your own legal interpretation or is there some document which  
specifically says "royalty-bearing license of right" about this  
particular draft?  If so, a citation would help.

--John

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 06 Mar 2009 03:23:26 -0800

Hi John,

> Perhaps it was a marketing error not to use the string "royalty-free" in 
> the IPR statement.

Can this supposedly a "marketing error" just be corrected by 
resubmission of a new disclosure and we can finish this so non technical 
thread soon ?

Cheers,
R.

---

From: John Leslie <[email-masked]>
Date: Fri, 6 Mar 2009 09:52:27 -0500

IANAL, but

John G. Scudder <[email-masked]> wrote:
> published with the recent (corrected) IPR disclosure 
> (http://www.ietf.org/ietf/IPR/juniper-ipr-draft-ietf-idr-flow-spec-03.txt ):
> 
> protection against patent litigation.

   I see nothing in there that looks like a license: it is rather a
promise not to sue under certain conditions.

   While the Google version clearly grants a license, albeit revokable:
" 
" Subject to the terms and conditions of this License, Google hereby  
" grants to You a perpetual, worldwide, non-exclusive, no-charge,
" royalty-free, irrevocable (except as stated in this License) patent   
" license for patents necessarily infringed by implementation (in whole or
" in part) of this specification. If You institute patent litigation
" against any entity (including a cross-claim or counterclaim in a
" lawsuit) alleging that the implementation of the specification
" constitutes direct or contributory patent infringement, then any patent
" licenses for the specification granted to You under this License shall
" terminate as of the date such litigation is filed.

   The differences are rather substantial:

- Google will not seek royalties predating the date of filing;

- Google grants the license whether or not a standard is adopted;

- Google revokes only for a suit over _this_ specification;

- Google doesn't reserve "not necessary for compliance".

   IMHO, while Juniper's current language may or may not be the best
we can hope for, it simply isn't a royalty-free license.

   While I dislike playing lawyer games, I'm afraid we ignore these
differences at significant peril.

   It's not that I expect Juniper managment to become unreasonable:
I don't expect them to file litigation over this. It's what happens
when companies enter bankruptcy: a whole new set of lawyers take
over, interested _only_ in maximizing the value against which they
can charge for what lawyers do -- and not the least bit interested
in carrying on the original vision of the company's founders.

   In today's times, any company faces increased risk of bankruptcy.
And it doesn't need to be Jupiter: any two-bit company can start
the meltdown by filing patent-infringement litigation. Any other
company can contribute to the meltdown by exercising the rights
reserved in IPR claims like Jupiter's.

   So, while I'm not exactly _happy_ living in a world of Google
IPR filings, I'm a whole lot happier with that than a world of
Jupiter IPR filings.

   Bottom line: I'd like to give Jupiter more time to think it over,
and not progress flow-spec to standard right yet.

--
John Leslie <[email-masked]>

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 6 Mar 2009 17:23:23 +0200

>   IANAL, but

Nor am I of course, and in my experience the IETF is at its very worst  
when engineers try to play lawyer.  Although I'm not a lawyer I have  
gotten opinions on a few things from counsel from time to time, one of  
which I'll relate below.

> promise not to sue under certain conditions.

Not being a lawyer I will not comment on the above other than to point  
out that you aren't either.  If someone wants to make a decision based  
on allegations that the IPR disclosure language does or doesn't have  
certain consequences, or is or isn't a "license", IMO they would do  
well to do so based on a competent legal opinion.

> we can hope for, it simply isn't a royalty-free license.

Same comment applies -- I respectfully don't wish to rely on your  
opinion on technical legal matters, of which this is one.

>   While I dislike playing lawyer games,

In that case I suggest you get an opinion from a competent lawyer  
instead of, as you put it, playing lawyer games.

> in carrying on the original vision of the company's founders.

This is the part I actually got opinion from counsel over.  Their  
opinion was that Juniper's public commitments to the IETF would  
continue to be binding on successors.  Thus it is not a matter of  
simply having to trust in the good will of the (hypothetical)  
successor -- there's a binding, written legal commitment.  Get your  
own legal opinion if it's sufficiently important to you, of course.

> reserved in IPR claims like Jupiter's.

I think you meant Juniper, not Jupiter, but whoever you meant, what  
some hypothetical third party ("two-bit company") might or might not  
do seems irrelevant to the case under discussion.

--John

---

From: Ron Bonica <[email-masked]>
Date: Fri, 6 Mar 2009 14:19:20 -0500

+1

John G. Scudder wrote:
> *personal* feeling about this is that I think the current situation with
> IPR is pretty awful, but that problem and its remedies are both far
> beyond the scope of what the IETF is competent and able to accomplish. 
> Although the IETF is famous for trying to boil the ocean, it would be
> great to skip that step this time.
> 
>>> on Sunday 2009.03.22 at 1300 in Imperial B (see
>>> https://datatracker.ietf.org/
>> meeting/74/agenda.txt
>>>  for any changes)
>>>
>>>
>>>
>>> requirements, etc at the IETF please contact us privately or
>>> mailto:rtg-ads@t
>> ools.ietf.org
>>>

---

From: Tony Li <[email-masked]>
Date: Fri, 06 Mar 2009 15:26:21 -0800

+1

Tony

---

From: Paul Jakma <[email-masked]>
Date: Sat, 7 Mar 2009 20:08:47 +0000 (GMT)

> and not progress flow-spec to standard right yet.

This seems the most prudent move all round for now (giving the 
lawyers more time to hone the language does not prejudice the 
existence of the specification, albeit in draft form). I.e.:

No.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Kites rise highest against the wind -- not with it.
 		-- Winston Churchill

---

From: Danny McPherson <[email-masked]>
Date: Sun, 8 Mar 2009 11:29:36 -0600

I've avoided comment on this in detail as well, for a
number of reasons - specifically, as a co-author, an
implementer, one of the earliest evangelists, and very
heavily pushing operational deployment, all after working
with Juniper on implementation interoperability and spec
refinement over the earlier years of the draft.

Myself and *many* others helped push for this type of
capability in the late 2002 and early 2003 timeframe, as
it seemed a natural evolution to both destination and
source-based blackhole routing, and some BGP community-
based hacks that folks were doing already that provided
some flow-specesque capabilities.  Apparently, Juniper
had a separate parallel effort underway as well.

The fact that Robert, who was at Cisco at the time, was
"fully aware about Juniper's authors filing the patent
application for this work" surprises me, given that I
certainly wasn't, and while I can't speak for others
"authoritatively", I'm pretty sure Jared wasn't either.
The necessity for third party disclosure here comes to
mind, as Thomas pointed out, given that Robert was a
co-author as well, and we all presumably subscribed to
what was outlined in the boilerplate of every iteration
of the draft.

I've long understood the IETF IPR rules and the absolute
need for disclosure - and this has certainly been cemented
in my mind since I saw the flow-spec disclosure only a
few months ago on a draft that had been baking since 2003.
Personally, it's extremely disappointing to have invested
a considerable amount of time and effort into internal
development, interoperability testing with Juniper, spec
refinement, and operational deployment and operational
community education, only to find out some five years later
that your co-authors have IPR claims in this area.

So, to speak in fairness, I asked myself the question: would
I have behaved differently had I known about the IPR?  The
answer was yes, certainly.  As a matter of fact, my company
has made several concerted decisions to avoid working on,
or continuing work on, solutions based on technologies that
are not openly available.

When I talked to Pedro after the first disclosure and
explained why this was such a concern, and engaged with
several other colleagues (many of which I consider friends)
at Juniper on the topic, I was pretty bitter at first.  I
did get pushback from one individual there, but that seems
to have simply been the result of their lack of understanding
of IETF process and related IPR rules - and why they're NOT
simply "legalese", "mechanical", "overhead" "standards
politics" - but absolutely necessary, and why not following
these rules undermines the very foundation of open standards
development.

However, "it is what it is", and that's all water under the
bridge now..

I can say that from my perspective Pedro and several other
IETF participants from Juniper seem to have made virtuous
efforts to remedy my concerns as an IETF participant and
co-author, which are of course separate from the concerns
of my employer.  Furthermore, given that extreme tardiness
of disclosure and the associated ill-effects was my chief
concern, you can't completely ameliorate that.  I do
believe this incident has educated many folks, for the
better, and hope to avoid predicaments of this sort in the
future.

All that said...

I'm fine with the content of the disclosure, and believe the
work has merit.  There are other ways to accomplish the goals
as well, but those are well beyond IDR and heavier if openly
specified and using other machinery.  I would like to see this
document published, presumably as standards track.

-danny