Subject: IETF IPR, EU EECC AND CJEU SCHREMS2 compliance

From: Tglassey1 <[email-masked]>
Date: Wed, 23 Sep 2020 09:19:02 +0000

The IETF IPR working group needs to be reopened. The reasons are that copyright and co-copyright standings for parties who have patent protected ip included into network protocols needs to be addressed.

As evidence of this co-copyright holders have monetization demand rights for any and all uses of their ip in co-copyright controlled publications.

Any IETF standard containing a patents methods becomes co-copyright controlled upon ietf publication.

This is further complicated by the COURT OF JUSTICE OF THE EU, and it's SCHREMS2 (#311/18) ruling, and the expansion of the areas called OVER THE TOP (OTT) of the internet regulated through the EU EECC legislation.

As such the general standards for IETF copyright controlled publications need a new publication boilerplate taking co-copyright into account and amending a existing copyrights that fail to address this based on a vote by the technology based engineering terms who mistakenly declared the previous IETF COPYRIGHT limited and free of co-copyright standings and the rights accorded to co-copyright holders. Finally, IETF standards (including rfc and internet draft publications) must also declare themselves bound by any key legislation where those are used or published in any form for review.

Best to you all.

//Ts Glassey

---

From: Tglassey1 <[email-masked]>
Date: Thu, 24 Sep 2020 15:36:16 +0000

1) Schrems2 is Court of Justice of the European Union case 311/18. It set aside SAFE HARBOUR rules between the US and EU. https://europeanlawblog.eu/2020/07/17/the-schrems-ii-judgment-of-the-court-of-justice-and-the-future-of-data-transfer-regulation/

2) EECC is the new European Electronic Communications Code Standards which now include IETF Internet Data Protocols and their uses under GDPR (GLOBAL DAYA PROTECTION DIRECTIVE). https://en.m.wikipedia.org/wiki/European_Electronic_Communications_Code and https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32018L1972

In order to allow existing and new IETF standards to be used in the EU, IETF standards, their use models, and the licensing controlling them must meet the hurdle of being able to be operated under GDPR as well as the grouping for EU nations. This has been brewing for 2 years now so it should not be a surprise.

As just one of many implications... For IETF protocols with patent protected or derived methods this has serious effects for the vendors using them. It also means any and all protocols derived from controlled IP that is already in place must be brought into compliance with this new set of hurdles.

This dual head-butt to the radically complicated the idea of patent derivatives in IETF protocols, and for those already in peoduction, their licensing must meet these new tests.

Already deployed IETF protocols will have to be revised under co-copyright standings and this creates a huge problem for VENDORS like apple ios, Google android, Microsoft networking, virtual computing, and many others as well.

There are serious reasons pending why IETF needs to reopen the IPR group to address these issues, and ongoing ones as well in global Internet compliance.

//Todd glassey

-------- Original Message --------
On Sep 23, 2020, 21:50, Michael Richardson wrote:

> please post an ID revising our process.
>
> I have no idea about what the SCHREMS2 ruling means, I just know that "RAND"
> is a useless kind of license for open source.
>
> --
> ] Never tell me the odds! | ipv6 mesh networks [
> ] Michael Richardson, Sandelman Software Works | IoT architect [
> ] [email-masked] http://www.sandelman.ca/ | ruby on rails [

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 25 Sep 2020 16:28:59 +0100

[cc: trimmed to [email-masked]]

Tglassey1 wrote on 24/09/2020 16:36:
> There are serious reasons pending why IETF needs to reopen the IPR group 
> to address these issues, and ongoing ones as well in global Internet 
> compliance.

Todd,

ianal.

As I understand it, GDPR (General Data Protection Regulations) refers 
only to protection of personally identifiable information (PII).

Can you identify how PII concerns intersect with intellectual property 
concerns, and what shortcomings you see at the IETF that need to be 
addressed?

Nick

---

From: Tglassey1 <[email-masked]>
Date: Sun, 27 Sep 2020 05:26:43 +0000

Nick,
GDPR requirements will include submitters info, and in many instances their IP ADDRESS. You are right transfer of privacy controlled info but courts in the US and EU have already constrained session connection info as part of that.

These clearly impact rights under the existing IETF ipr scheme, and here is the real ticker, it must be integrated into the "LEGAL Aspects section" of each protocol project (ID, RFC, BCP) pertaining to the uses of IETF protocols.

This is the first time such a time bomb has ever been attached to the standard practices focuments itself, but IETF standards have never had to have a "publication use control" pertaining to localization before, which this new hurdle is tied to, and they do now.

It might make sense to create a blanket "GDPR localization" boilerplate , but localization use rules for protocols are now a reality, and they definitely impact BCP79.

Also in considering GDPR localization and the scope of its importance, the EU EECC which goes into effect in 3 months, makes most all IETF protocols regulated under EU law there in the EU/EEA as well "as what they refer to as OVER THE TOP communication instances", so there is also a requirement to address that change as well in that same context.

FWIW The Court of Justice of the European Union ruling against Facebook in Schrems2 has serious "protocol specific use instances" for blocking under GDPR communications between non GDPR entities and those practicing GDPR methods. The issue is when there is no control practice acknowledgement or methods capable in the protocol it makes the protocol standard itself unusable in those jurisdictions.

As I mentioned above, this type of thing was never contemplated when the boilerplate copyright and IPR rights were done as BCP79 by Scott Bradener and Jorge Contreras esq. but they are certainly here now.

At the very least BCP79 must be updated, but I would suggest more is needed and that is a protocol data flow auditing practice for each key protocol, security and dns ones especially. Finally new TLS and other certificate management routines as well, because personal connection certificates and per-session keys used by individuals are clearly controlled by these new mandates. In fact any published instances of those protocols should be updated with at least a "we are capable of being used under GDPR and EECC" or a statement saying the obvious.

There is a lot of stuff to be updated. Just my two cents...

Best to you sir, and the group.

//Todd Glassey

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 28 Sep 2020 14:17:13 +0000

This sounds like something the LLC should get a legal opinion on.  Not something for a working group.

---

From: Tglassey1 <[email-masked]>
Date: Mon, 28 Sep 2020 20:26:18 +0000

There are plenty of legal techies here who can make an initial analysis.

Waiting will be costly in having to make immediate knee jerk reactions...

//Tsg