Subject: IPR Disclosure Deutsche Telekom AG's Statement about IPR related to draft-ietf-6man-ipv6only-flag

From: IETF Secretariat <[email-masked]>
Date: Thu, 06 Dec 2018 08:53:54 -0800

Dear Bob Hinden, Brian E. Carpenter:

An IPR disclosure that pertains to your Internet-Draft entitled "IPv6
Router Advertisement IPv6-Only Flag" (draft-ietf-6man-ipv6only-flag) was
submitted to the IETF Secretariat on  and has been posted on the "IETF Page
of Intellectual Property Rights Disclosures"
(https://datatracker.ietf.org/ipr/3356/). The title of the IPR disclosure is
"Deutsche Telekom AG's Statement about IPR related to
draft-ietf-6man-ipv6only-flag"

Thank you

IETF Secretariat

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Dec 2018 18:04:38 +0100

So is Deutsche Telekom risking asking me "Reasonable and 
Non-Discriminatory License to All Implementers with Possible 
Royalty/Fee" for some implementation of IPv6-Only flag I've done in 
scapy earlier?

That may kill it.

Better told me that before :-)

Alex

Le 06/12/2018 à 17:53, IETF Secretariat a écrit :
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 6 Dec 2018 18:22:25 +0100 (CET)

> Better told me that before :-)

Read the patent before you decide if it applies or not. I am not sure.

An IPR disclosure is an FYI for something that might be relevant and the 
IETF requests people to do that if anyone thinks its relevant.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Thu, 6 Dec 2018 09:44:34 -0800

This is all surprising news to me (and I suspect Brian too).

Bob

> On Dec 6, 2018, at 8:53 AM, IETF Secretariat <[email-masked]> wrote:
>

---

From: Loganaden Velvindron <[email-masked]>
Date: Thu, 6 Dec 2018 21:48:41 +0400

I read about it. I'm quite surprised. bz implemented his code in
freebsd just through reading the I-D afaik.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Dec 2018 20:08:40 +0100

> Read the patent before you decide if it applies or not. I am not sure.

I will read it and I will not be sure, like you, thank you.

> IETF requests people to do that if anyone thinks its relevant.

But, better without having to read another IPR.

And yes, better some approximate RAND conditions than no conditions and 
unknown situations.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Dec 2018 08:39:38 +1300

> Royalty/Fee" for some implementation of IPv6-Only flag I've done in 

Not really. It's "RAND reciprocity", a very standard form of license conditions that you will find on many IETF IPR disclosures, and which is within the range of conditions acceptable under BCP79, which we all agree to every time we read the Note Well and continue participating in the IETF.

Whether the claimed IPR actually applies to the draft is a matter for each implementer to decide, of course. I have no opinion on that at the moment.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 7 Dec 2018 08:47:17 +1300

> freebsd just through reading the I-D afaik.

That's irrelevant. The date claimed for the patent is in 2016, which is before the draft and before bz's own related draft. On the other hand, you might decide that the relevant patent claim is obvious (and therefore invalid), that it doesn't apply to the draft anyway, or that the "RAND reciprocity" condition is acceptable.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 7 Dec 2018 07:07:27 +1100

> This is all surprising news to me (and I suspect Brian too).

By my reading of the patent, it seems to be describing a mechanism
where a possible packet receiver conveys a policy or signal to a
sender, so the sender can delay or drop packets that the receiver
knows or thinks won't be received or accepted.

https://patents.google.com/patent/EP2897333A1/en

I think a number of things would qualify as prior art for this patent,
as they all existed well before 2014.

- TCP windowing

- IPv4 ICMP Source Quench

- BGP Outbound Route filters

Regards,
Mark.

---

From: "Lubashev, Igor" <[email-masked]>
Date: Thu, 6 Dec 2018 21:16:20 +0000

That's how I'd read the claims, too.  Adding to the list:

* All ICMP error messages

* ECN

* IEEE 802.3x Pause frames (though maybe not covering dependent claims requiring non-directly connected nodes)

Claim 8 claims a policy/signal info that travels from the receiver to the sender in a "protected" manner.  It could be argued that abovementioned signals traveling over IPSec tunnels and/or encrypted L2 links qualify as prior art, too.

"TCP windowing" and "ECN" (and "pause frames") seem especially valuable prior art for Claims 7 & 12, since they work in both directions concurrently.

- Igor

> -----Original Message-----
> From: Mark Smith <[email-masked]>
> Sent: Thursday, December 06, 2018 3:07 PM
> To: Bob Hinden <[email-masked]>
> Cc: 6man WG <[email-masked]>
> Subject: Re: IPR Disclosure Deutsche Telekom AG's Statement about IPR
> related to draft-ietf-6man-ipv6only-flag
> 
> By my reading of the patent, it seems to be describing a mechanism where a
> possible packet receiver conveys a policy or signal to a sender, so the sender
> can delay or drop packets that the receiver knows or thinks won't be
> received or accepted.
> 
> I think a number of things would qualify as prior art for this patent, as they all
> existed well before 2014.
> 
> - TCP windowing
> 
> > > An IPR disclosure that pertains to your Internet-Draft entitled
> > > "IPv6 Router Advertisement IPv6-Only Flag"
> > > (draft-ietf-6man-ipv6only-flag) was submitted to the IETF
> > > Secretariat on  and has been posted on the "IETF Page of Intellectual
> Property Rights Disclosures"
> > > (https://datatracker.ietf.org/ipr/3356/). The title of the IPR
> > > disclosure is "Deutsche Telekom AG's Statement about IPR related to

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Dec 2018 08:52:08 +0100

Were it to be just RAND as known in other licenses I know it would be 
fine.  (those interested can find many of them on the IETF IPR 
declarations website; pick a favourite RFC and check whether IPR and 
licensing applies; read and understand the licenses; the best ones are 
just RAND).

but this one adds "with Possible Royalty/Fee"

only they can know what 'Possible' means.

It may mean 'yes', it may mean 'no'.

I may or may not want to hear about it.

I may have written such code and I may have not written it.

---

From: Ole Troan <[email-masked]>
Date: Fri, 7 Dec 2018 09:22:28 +0100

This is not a suitable list for discussing IPR licensing terms.
https://ietf.org/standards/ipr/

Ole

> On 7 Dec 2018, at 08:52, Alexandre Petrescu <[email-masked]> wrote:
> 
> Were it to be just RAND as known in other licenses I know it would be fine.  (those interested can find many of them on the IETF IPR declarations website; pick a favourite RFC and check whether IPR and licensing applies; read and understand the licenses; the best ones are just RAND).
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 7 Dec 2018 10:41:19 -0000

Surely it is a fine place to discuss IPR that has been disclosed against a working group document and where the working group may want to consider its position with respect to that IPR and whether to re-open the draft and arrive at a different solution that is not encumbered by the IPR.

Individuals will want to consider whether they think the IPR truly cover the draft, whether the IPR would stand up in court in the light of various considerations such as prior art, and whether the licensing terms are acceptable to them. While the first two of those issues are not things I would choose to express a public opinion on without first taking out suitable insurance, I believe that the working group participants may have questions and information to share that would help everyone make up their own minds. 

With regard to the third point, I freely accept that each person and commercial concern has the right to set out whatever licensing terms they want for IPR they own. I am saddened whenever a company chooses terms that are more strict than "will not assert unless asserted against, with RAND available" (sometimes known as MAD terms) within the IETF. When that happens I think that it is beneficial to look at the technical work to determine whether there is a solution available that circumvents the IPR, but is otherwise technically sound. Of course, that is not always possible, and people may make a trade-off that leads to there being no will in the working group to do so (for example, belief that the first two points make it unnecessary, cost-benefit, belief that the majority of companies have protection through their own portfolios, etc.), and that is also fine. This is an easy position to test within the working group without having to have a detailed discussion of the legal details: the chairs could (but I am not asking them to do this) as the question "Would the working group like to spend some time seeing whether there is an alternate approach that is not encumbered by IPR?"

Thanks,
Adrian
-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Ole Troan
Sent: 07 December 2018 08:22
To: Alexandre Petrescu <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: IPR Disclosure Deutsche Telekom AG's Statement about IPR related to draft-ietf-6man-ipv6only-flag

Ole

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Dec 2018 11:41:58 +0100

I agree Ole, the best place to discuss conditions is elsewhere.

At this time, now, I would like to ask that the draft is not a place to 
list my name.  Please remove my name from the draft Acknowledgments.  I 
do not want to be subject to the Conditions.

(it is with sorrow that I ask it, but that's the way it is)

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 8 Dec 2018 08:44:28 +1300

> do not want to be subject to the Conditions.

Sorry, but Acknowledgments are a matter of fact: X made useful comments.
They don't imply any responsibility. And if by "Conditions" you mean
our obligations under BCP79, there is no escape clause. As the Note Well
says "By participating in the IETF, you agree to follow IETF processes
and policies."

I also suggest reading https://tools.ietf.org/html/rfc3669. A few years
old, but still helpful.

     Brian

> .

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 7 Dec 2018 22:24:28 -0500

+1. I just wanted to point out that the IETF will make no determination about the validity of any particular IPR claim as specified in RFC3979 and derived from the principles established in Section 10 of RFC2026. Specifically, IETF RFCs will have a notice added (described in Section 5 of RFC3979) that will contain a disclaimer of validity. Let’s not try to go down this road to see whether the IPR disclosure is relevant or not. Of course, the WG needs to decide what to do with the draft armed with the knowledge that this ipr disclosure exists. 

Thanks
Suresh

> On Dec 7, 2018, at 3:22 AM, Ole Troan <[email-masked]> wrote:
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 9 Dec 2018 18:35:36 +0100

> Sorry, but Acknowledgments are a matter of fact: X made useful comments.

I agree with you.  It makes sense.

But then, how about the Implementation status section.

> I also suggest reading https://tools.ietf.org/html/rfc3669. A few years

Well.

The way I read the IETF participation conditions is that if I hold an 
IPR I should say it.

I do not read it as saying that if I implement something then I must be 
ready to pay licenses to somebody.

As a matter of professional conduct, I know by my training that if I 
implement something I may ask somebody to pay, and certainly not 
vice-versa.  By same training, I learned that sometimes I need to 
implement for other reasons than money.

These are my conditions, thank you.

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Dec 2018 08:29:16 +1300

> But then, how about the Implementation status section.

Author hat on: I'd be happy to remove that mention of your name.
(That section will be removed if the draft becomes an RFC.)

> ready to pay licenses to somebody.

Indeed not, because that's a legal matter over which the IETF has
no control. An implementer (and that includes me, because I also
used scapy to generate the flag bit) has to make his or her own
decision. One could use https://datatracker.ietf.org/ipr/search/
before implementing any IETF specification or draft.

    Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Sun, 9 Dec 2018 20:49:41 +0100

> (That section will be removed if the draft becomes an RFC.)

Thank you for much.  That is my desire.

> before implementing any IETF specification or draft.

I agree with you, it works in general.

In other cases, like this one, the implementer (myself) may have gone 
too fast to implement.  I should have waited that IPR declarations are 
made first.

This is why, maybe, the questions of (1) whether implementations are 
available, and (2) whether IPR exists, should be synchronized.

Alex

---

From: Christian Huitema <[email-masked]>
Date: Sun, 9 Dec 2018 14:40:29 -0800

> available, and (2) whether IPR exists, should be synchronized. 

Alexandre,

There is no way that the IETF can wait for all IPR declarations before
publishing a specification. In most cases, we just don't know about it.
If the patent is held by a company engaged in the IETF process, we will
get an IPR declaration at some point, typically a few months after the
engineer participating in the WG notifies the company's management,
lawyers or patent department about the possible conflict. If the company
is not engaged in the IETF process, we may only learn about it when
someone gets sued.

On the other hand, I have yet to hear about someone getting sued for
publishing a non commercial test tool similar to scapy. I don't think
that you have much to fear. At worst, the scapy project is going to be
asked to remove the functionality if the IPR holder is particularly
aggressive. I would be really surprised if Deutsche Telekom tried that.

-- Christian Huitema