Subject: [regext] Call for adoption: draft-loffredo-regext-rdap-reverse-search

From: Antoin Verschuren <[email-masked]>
Date: Fri, 18 Jan 2019 17:04:20 +0100

Hi all,

As discussed on the mailinglist, we have selected 5 documents that people most want to be added to our milestone list.
To be able to to that the documents should first be adopted as working group documents.
This is a formal adoption request for draft-loffredo-regext-rdap-reverse-search

The draft is available here:
https://datatracker.ietf.org/doc/draft-loffredo-regext-rdap-reverse-search/

Please review this draft to see if you think it is suitable for adoption by REGEXT, and comment to the list, clearly stating your view.
Please also indicate if you are willing to contribute text, review, be a document shepherd, etc.

This call for adoption ends 25 Januari 2019.
If there are no objections, and we receive enough consensus for adoption, the chairs will consider this document adopted.

Thanks,

Your REGEXT co-chairs Jim and Antoin.

- -- 
Antoin Verschuren

Tweevoren 6, 5672 SB Nuenen, NL
M: +31 6 37682392

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 18 Jan 2019 17:33:21 +0100

I support adoption 

Mario

Inviato da iPhone

> Il giorno 18 gen 2019, alle ore 17:04, Antoin Verschuren <[email-masked]> ha scritto:
> 
> Hi all,
> 
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: Maurizio Martinelli <[email-masked]>
Date: Fri, 18 Jan 2019 22:35:22 +0100

I support its adoption.

Kind regards,
Maurizio Martinelli

Inviato da iPhone

---

From: Eduardo Alvarez <[email-masked]>
Date: Wed, 23 Jan 2019 01:06:25 +0000

I support adoption and I am willing to contribute.

--Eduardo A.

On 1/18/19, 8:10 AM, "regext on behalf of Antoin Verschuren" <[email-masked] on behalf of [email-masked]> wrote:

    Hi all,

    The draft is available here:
    https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dloffredo-2Dregext-2Drdap-2Dreverse-2Dsearch_&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=O7ITuRnXwk6qMuIoFxnUSSBCEHKX3tGQWUrU8TIydBk&m=ZW6xvydVLHGNfttKK01GoGmBIa18K_sxTXYdb1bwDoA&s=_neOeDCxdnz05WMPfof9rZc4JPK5LLkZy6g16D5g1-A&e=

    
    Thanks,

    - -- 
    Antoin Verschuren

    

    _______________________________________________
    regext mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_regext&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=O7ITuRnXwk6qMuIoFxnUSSBCEHKX3tGQWUrU8TIydBk&m=ZW6xvydVLHGNfttKK01GoGmBIa18K_sxTXYdb1bwDoA&s=LHQA1kPAYIkuVRiz_hQPdGLauW-ybHRYS0vSnKNTmG4&e=

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 23 Jan 2019 12:37:40 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Antoin Verschuren
> Sent: Friday, January 18, 2019 11:04 AM
> To: Registration Protocols Extensions <[email-masked]>
> Subject: [EXTERNAL] [regext] Call for adoption: draft-loffredo-regext-rdap-
> reverse-search
>
> Hi all,
>
> As discussed on the mailinglist, we have selected 5 documents that people
> most want to be added to our milestone list.
> Please review this draft to see if you think it is suitable for adoption by
> REGEXT, and comment to the list, clearly stating your view.

I support adoption and am willing to review the document and contribute text.

Scott

---

From: Niels ten Oever <[email-masked]>
Date: Wed, 23 Jan 2019 13:55:31 +0100

> I support adoption and am willing to review the document and contribute text.

I strongly object to the adoption of this document as it currently stands. 

In this draft, there are no privacy considerations, and the report that is being cited to legitimize this approach has not been adopted by ICANN the organization or the community and was very controversial at the time of publication. The report is being miscited as being produced by ICANN itself, which was not the case. 

There is also no limitation or specific use defined, which makes this protocol in direct violation of with the GDPR.

This needs serious rework before we can adopt this as WG document imho.

Best,

Niels

-- 
Niels ten Oever
Researcher and PhD Candidate
Datactive Research Group
University of Amsterdam

PGP fingerprint	   2458 0B70 5C4A FD8A 9488  
                   643A 0ED8 3F3A 468A C8B3

---

From: Andy Newton <[email-masked]>
Date: Wed, 23 Jan 2019 10:22:08 -0500

> In this draft, there are no privacy considerations, and the report that is being cited to legitimize this approach has not been adopted by ICANN the organization or the community and was very contr…

It is just a draft. I hope we are not trying to get people in the habit of
submitting final works into IETF wgs.

I think the ICANN citation can be safely dropped, and the privacy
considerations from RFC 7482/7483 adopted.

> There is also no limitation or specific use defined, which makes this protocol in direct violation of with the GDPR.

So are we to subject the consideration of all IETF work against the laws of all
nation-states, or are you proposing we simply use the directives of the EU as
the gold standard upon which IETF drafts are to be considered?

-andy

---

From: Andy Newton <[email-masked]>
Date: Wed, 23 Jan 2019 10:30:01 -0500

> Please also indicate if you are willing to contribute text, review, be a document shepherd, etc.

First, I wish to thank Mario and his co-authors for opening this line of work.
I have a few comments on this draft (and I'll let the chairs determine if I'm
agreeing with adoption or not).

1. From an operational point of few, I think there maybe a need differentiate
the support of the different searches. In my (limited opinion), the requirement
to support reverse searches by handle and email address are different than the
requirement to support reverse search of name and physical address. Therefore,
I think operators and policy people need a way to differentiate the various
searches in their documentation. Perhaps this can be done by breaking the
searches into multiple drafts and therefore registry A can say the support RFC
XXXX while registry B can say they support RFC YYYY. Just a thought.

2. I don't know if we want to tackle the issue of distributing reverse
searches. But that is an issue here.

3. The complexity of the query parameters makes me wonder if we should consider
another mechanism for these more complex extensions... One such mechanism would
be a general extension of using POST with GraphQL, and then doing profiles of
reverse search (and other things) on top of that.

-andy

---

From: Mario Loffredo <[email-masked]>
Date: Wed, 23 Jan 2019 19:15:02 +0100

Hi Andy,

thanks for your feedback. My comments are below.

> XXXX while registry B can say they support RFC YYYY. Just a thought.

Honestly, I don't see any difference but, anyway, we can discuss about 
that.

Another point of discussion could be if we need other reverse search 
capabilities not limited to the classic domains-entities relationship 
and currently uncovered by RDAP.

> searches. But that is an issue here.

What do you mean exactly for "distributing search"? Do you mean "across 
different RDAP servers" ?

> reverse search (and other things) on top of that.

I have thought to the use of a POST method as well as to GraphQL but I 
didn't want to propose something outside the constraints of RFC7482 :-)

I think this proposal is related to the other two drafts (partial 
response, sorting-and-paging) and to the implementation of more complex 
queries.

Regards,

Mario

-- 
Dr. Mario Loffredo
Servizi Internet e Sviluppo Tecnologico
CNR - Istituto di Informatica e Telematica
via G. Moruzzi 1, I-56124 PISA, Italy
E-Mail: [email-masked]
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

---

From: "John Levine" <[email-masked]>
Date: 23 Jan 2019 14:26:17 -0500

>There is also no limitation or specific use defined, which makes this protocol in direct violation of with the GDPR.

I'm sorry, but that assertion is not even wrong.

The GDPR affects entities that process or control data related to EU
people.  It is not about technical specifications that someone subject
to the GDPR might use at some future time.  It's up to the processors
and controllers to figure out if they're subject to the GDPR and if so
how their processing complies with it (keeping in mind that "consent"
is pretty low on the list of criteria.)

I don't plan to further engage with this unfounded line of argument.

For anyone interested in actual work, the ICANN EPDP on this topic is
grinding along and it seems reasonably likely that they will have sort
of reverse search, maybe plain text, maybe hashed identifiers so you
can ask questions like what are all the domains with the same contact
address as this one without knowing what the contact address is.

R's,
John

---

From: Andy Newton <[email-masked]>
Date: Wed, 23 Jan 2019 15:31:42 -0500

Mario,

My response is in-line

On Wed, Jan 23, 2019 at 07:15:02PM +0100, Mario Loffredo wrote:
> Honestly, I don't see any difference but, anyway, we can discuss about that.
> 
> capabilities not limited to the classic domains-entities relationship and
> currently uncovered by RDAP.

I'm not really raising a technical issue. It's really about operators feeling
the need to support all the queries in the draft vs just some and how they
would communicate that to their consituencies.

Let me think about it some more.

> different RDAP servers" ?

Yes.

> I think this proposal is related to the other two drafts (partial response,
> sorting-and-paging) and to the implementation of more complex queries.

Ok. If you considered it but found the approach less-than-desirable, that's
good enough for me.

-andy

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 24 Jan 2019 10:01:10 +0100

Hi Andy,

my comments below.

> Let me think about it some more.
ok
>> different RDAP servers" ?
I think that distributed search can be implemented by RDAP clients 
without changing anything on server side.

Clients could load information from bootstrap IANA registries to provide 
users with a list of TLDs among which users could select those involved 
in the search.

Then clients could distribute the query to the corresponding RDAP 
servers, collect the responses and present the results as a single response.

The implementation by servers of capabilities like partial response and 
advancing querying/filtering could reduce the risks to obtain truncated 
results.

> Ok. If you considered it but found the approach less-than-desirable, that's

Beyond the compliance with RFC7482, there are some other reasons to opt 
for the standard approach (GET method) rathen than a POST/GraphQL approach.

POST/GraphQL is a more comprehensive solution addressing all the issues 
connected with both query and result set management  but it is harder to 
implement by RDAP providers and more difficult for RDAP users.

 From server-side perspective, the use of the GET method enables a more  
modular solution. Each RDAP provider can decide which addtional query 
capabilty to implement (e.g. sorting, paging, partial response, and so 
on) with a relatively small effort. In addition, GET is more consistent 
with the use of links and, in my opinion, links are fundamental to make 
servers be as self-descriptive as possible.

 From user perspective, GET is more suitable: GET requests can be 
cached, remain in the browser history, can be bookmarked.

Probably, those features have inspired you and Scott when writing RFC 7482.

Basically, RDAP users need neither an ad-hoc client nor a REST plugin in 
their web browsers in order to interact with an RDAP server.  RDAP 
clients should provide more advanced capabilities like 
self-configuration and distributed search.

However, GET is a bit less elegant than POST when dealing with complex 
queries but it seems to me an acceptable compromise.

The query defined in reverse search draft is based on a JSON expression 
as well as the current implementation of complex queries by .it RDAP 
public test server as described in the white paper available here 
<https://www.iit.cnr.it/sites/default/files/TR%2007-2018.pdf>

I would like to know if this vision of RDAP is shared by other members :-)

mario

---

From: Niels ten Oever <[email-masked]>
Date: Thu, 24 Jan 2019 11:36:53 +0100

> address as this one without knowing what the contact address is.

I totally agree with John here: let's await what comes out of the ICANN EPDP and see whether this is actually something that is warranted and build it to that spec. 

Best,

Niels

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 24 Jan 2019 12:19:55 +0000

> From: regext <[email-masked]> On Behalf Of Niels ten Oever
> Sent: Thursday, January 24, 2019 5:37 AM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [regext] Call for adoption: draft-loffredo-regext-
> rdap-reverse-search
>
>
>
> >> There is also no limitation or specific use defined, which makes this
> protocol in direct violation of with the GDPR.
> >
> I totally agree with John here: let's await what comes out of the ICANN EPDP
> and see whether this is actually something that is warranted and build it to
> that spec.

ICANN isn't the only potential user of this technology. I'd like to make sure that this draft can address any ICANN-specific use cases, but I don't think we should sit around and wait for one particular constituent to get its act together. Assuming that we have non-ICANN use cases to consider, it would make more sense to start work now and defer completion until we're comfortable that all anticipated use cases are addressed.

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 24 Jan 2019 14:44:16 +0100

Hi all,

> ICANN isn't the only potential user of this technology. I'd like to make sure that this draft can address any ICANN-specific use cases, but I don't think we should sit around and wait for one parti…

+ 1

I believe that nobody here is thinking to a misuse of this technology.

Each RDAP provider implementing this capability is subject (like each 
WHOIS provider has been subject so far) to some law about personal data 
protection defining de facto the legal use.

If WG members agree that it is wothwhile for RDAP users, we should move 
forward and be sure that RDAP providers will rely on policies described 
in RFC7481 to control its availability, just in the same way people 
adopt security measures to control the access to systems, applications, 
services, and so on.

That being said, in order to avoid any misunderstanding, I'm changing 
the draft to better explain some permissible use cases.

mario

---

From: Gavin Brown <[email-masked]>
Date: Thu, 24 Jan 2019 14:05:01 +0000

I support adoption of this document.

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.

---

From: Andy Newton <[email-masked]>
Date: Thu, 24 Jan 2019 10:16:55 -0500

On Thu, Jan 24, 2019 at 02:44:16PM +0100, Mario Loffredo wrote:
> Each RDAP provider implementing this capability is subject (like each WHOIS
> provider has been subject so far) to some law about personal data protection
> defining de facto the legal use.
> 
> forward and be sure that RDAP providers will rely on policies described in
> RFC7481 to control its availability, just in the same way people adopt
> security measures to control the access to systems, applications, services,
> and so on.
> 
> That being said, in order to avoid any misunderstanding, I'm changing the
> draft to better explain some permissible use cases.

I agree with both Scott and Mario here.

Additionally, the discussion on this list with Mario has satisified my
reservations, and I fully support the adoption of this document.

-andy

---

From: "John Levine" <[email-masked]>
Date: 24 Jan 2019 13:15:13 -0500

>warranted and build it to that spec. 

Please stop trying to put words in my mouth.

Regardless of what comes out of the ICANN EPDP, this feature will be
useful to anyone who wants to use it.  There are after all several
hundred ccTLDs that are not in the EU.  Even if for some reason you
believe (wrongly) that the GDPR is a bar to implementing this in the
EU, it isn't in other countries.

R's,
John

---

From: Gustavo Lozano <[email-masked]>
Date: Thu, 24 Jan 2019 22:59:12 +0000

I support adoption and willing to review.

> Sent: Friday, January 18, 2019 08:04
> Subject: [Ext] [regext] Call for adoption:
draft-loffredo-regext-rdap-reverse-
> search
most
> want to be added to our milestone list.
> To be able to to that the documents should first be adopted as working
group
> documents.
> This is a formal adoption request for
draft-loffredo-regext-rdap-reverse-search
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__datatracker.ietf.org_doc_draft-2Dloffredo-2Dregext-2Drdap-2Dreverse-
> 2Dsearch_&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r
> =VbweciUcwYQpIOZDSxl0ezGd1hGDtd-
> 0BvgAgfmwfE0&m=MuyCgmYOfQlZxsvdrdgQVt1y6H0rCfEhLDJPyMzLrzo&s=kU
> xOx0Nw4D6T7B2V4dyDgIJU33Kkj4KC-CnS_2BrpB8&e=
> 
> Please review this draft to see if you think it is suitable for adoption
by REGEXT,
> and comment to the list, clearly stating your view.
> Please also indicate if you are willing to contribute text, review, be a
document
> shepherd, etc.
> If there are no objections, and we receive enough consensus for adoption,
the
> chairs will consider this document adopted.
> 
> Thanks,
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_regext&d=DwICAg&c=FmY1u3PJp6wrcrwl
> l3mSVzgfkbPSS6sJms7xcl4I5cM&r=VbweciUcwYQpIOZDSxl0ezGd1hGDtd-
> 0BvgAgfmwfE0&m=MuyCgmYOfQlZxsvdrdgQVt1y6H0rCfEhLDJPyMzLrzo&s=q4i
> 0FhA5G_8k3ueOlypIvWa0AMXT0RPzmADmSPKQE3k&e=

---

From: Gurshabad Grover <[email-masked]>
Date: Fri, 25 Jan 2019 10:12:19 +0530

On 23/01/19 6:25 PM, Niels ten Oever wrote:
> [...]
> [...]

I agree with Niels:

* Since the document starts with outlining privacy concerns as being of
primary import and relevance to the discussion around reverse search,
the document would naturally benefit from adding privacy considerations.

* The reference to a ICANN WG's recommendations as "... ICANN itself, in
its report about Next-Gen Registration Directory Service (RDS) ..." is
also problematic.

Thank you.
Gurshabad

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 25 Jan 2019 10:32:40 +0100

> EU, it isn't in other countries.

If a registrant is living in the EU, or a EU citizen, they would be covered by GDPR protections, so its impact is quite significant. As you know, ICANN and the industry is seeking to find one compliance model. I do not see why we would deviate from that.

All the best,

Niels

---

From: Tom Harrison <[email-masked]>
Date: Fri, 25 Jan 2019 10:42:51 +0000

On Fri, Jan 18, 2019 at 05:04:20PM +0100, Antoin Verschuren wrote:
> ...

I support adoption and am willing to contribute/review.

-Tom

---

From: "John R Levine" <[email-masked]>
Date: 25 Jan 2019 09:14:08 -0500

> If a registrant is living in the EU, or a EU citizen, they would be covered by GDPR protections, so its impact is quite significant. As you know, ICANN and the industry is seeking to find one compl…

I pretty sure nothing has changed since Wednesday, so I guess we're 
done.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 25 Jan 2019 15:21:26 +0100

On 1/25/19 3:14 PM, John R Levine wrote:
> I pretty sure nothing has changed since Wednesday, so I guess we're done.

The final decision on this is planned to be made in April:

https://community.icann.org/pages/viewpage.action?pageId=88574682&preview=/88574682/102142026/EPDP_summary_timeline_20190116.pdf

---

From: "John R Levine" <[email-masked]>
Date: 25 Jan 2019 09:28:17 -0500

> https://community.icann.org/pages/viewpage.action?pageId=88574682&preview=/88574682/102142026/EPDP_summary_timeline_20190116.pdf

Not that it's relevant here, but I am a member of the ICANN SSAC 
subcommittee that supports the SSAC reps on the EPDP group, and I talk to 
them about its progress or lack thereof several times a week.  I think 
it's fair to assume that I know at least as much about what it's doing as 
anyone else here.  I was also a member of the IAOC when we figured out 
what the IETF needed to do to be GDPR compliant (not much.)

But once again, the IETF is not ICANN, working groups are not GDPR data 
controllers, nor are we GDPR data processors.  This entire argument is a 
waste of everyone's time.

Regards,

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 25 Jan 2019 15:39:54 +0100

On 1/25/19 3:28 PM, John R Levine wrote:
> Not that it's relevant here, but I am a member of the ICANN SSAC subcommittee that supports the SSAC reps on the EPDP group, and I talk to them about its progress or lack thereof several times a week.  I think it's fair to assume that I know at least as much about what it's doing as anyone else here.  

I do not doubt anything of this. Would you agree that the decision of the EPDP impacts how RDAP reverse search should be developed and implemented?

> I was also a member of the IAOC when we figured out what the IETF needed to do to be GDPR compliant (not much.)
> 

Because the IETF does not implement the protocols or holds the data. But if the IETF produces protocols which are non-GDPR compliant upon implementation, and are violating human rights, that is imho not something we should want. 

Best,

Niels

> But once again, the IETF is not ICANN, working groups are not GDPR data controllers, nor are we GDPR data processors.  This entire argument is a waste of everyone's time.
> 
> Regards,

---

From: Andy Newton <[email-masked]>
Date: Fri, 25 Jan 2019 10:02:26 -0500

> its report about Next-Gen Registration Directory Service (RDS) ..." is

If the authors removed this introductory text, would you drop your objections?

-andy

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 25 Jan 2019 16:05:40 +0100

Hi Andy,

> If the authors removed this introductory text, would you drop your objections?

I'm removing that text from the new version as well as I'm adding a 
"Privacy Consideration" section.

Regards,

mario

---

From: Thomas Corte <[email-masked]>
Date: Fri, 25 Jan 2019 16:18:48 +0100

Hello Niels,

On 1/25/19 15:39, Niels ten Oever wrote:

> But if the IETF produces protocols which are non-GDPR compliant upon implementation, and are violating human rights, that is imho not something we should want. 

Why should the IETF, a *global* organization, restrict its protocols to
ensure GDPR compliance, i.e. a piece of legislation only applicable in
the *European Union* and nowhere else?

Best regards,

Thomas

-- 
____________________________________________________________________
     |       |
     | knipp |            Knipp  Medien und Kommunikation GmbH
      -------                    Technologiepark
                                 Martin-Schmeißer-Weg 9
                                 44227 Dortmund
                                 Deutschland

     Dipl.-Informatiker          Tel:    +49 231 9703-0
     Thomas Corte                Fax:    +49 231 9703-200
     Stellvertretender Leiter    SIP:    [email-masked]
     Software-Entwicklung        E-Mail: [email-masked]

                                 Registereintrag:
                                 Amtsgericht Dortmund, HRB 13728

                                 Geschäftsführer:
                                 Dietmar Knipp, Elmar Knipp

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 25 Jan 2019 16:51:30 +0100

> I do not doubt anything of this. Would you agree that the decision of the EPDP impacts how RDAP reverse search should be developed and implemented?

No because I don't believe that someone is thinking to an uncontrolled 
implementation and, even if someone is so crazy to do that, he will be 
responsible for that, not the capability. RDAP was born to overcome the 
WHOIS limitations. The policies described in RFC7481 allow RDAP servers 
to provide capabilities according the user profiles and there are a 
number of operators legitimated (in terms of GDPR lawful bases) to use 
RDAP reverse search.

> Because the IETF does not implement the protocols or holds the data. But if the IETF produces protocols which are non-GDPR compliant upon implementation, and are violating human rights, that is imh…

According to that view, WHOIS should have been stopped even before the 
entry into force of GDPR and, after that time, also fully GDPR compliant 
WHOIS implementations should have been switched off because other 
non-GDPR compliant implementations were still running.

Can we distinguish between the technology and the use/misuse of the 
technology ? If we don't make this distinction, why don't we shutdown 
Internet ??

Anyway, a new version of the draft will be available soon. Hopefully, 
this new version will fix the controversial points.

Regards,

mario

---

From: Niels ten Oever <[email-masked]>
Date: Fri, 25 Jan 2019 17:21:51 +0100

Hi Thomas,

> the *European Union* and nowhere else?

I fully agree that the IETF does not need to restrict its protocols to the legislations of one geographical area. But I think the IETF should help implementers to not violate the human rights of end-users, and consider regulation when implementing. The IETF can seek to do so by thoroughly analyzing the potential impacts of the protocols that are produced in and published by the IETF and report on the in privacy, security and human rights considerations. 

Best,

Niels

PS The legislation not only applicable in the European Union, but anywhere in the world where the data of EU citizens or residents is held.

---

From: Taras Heichenko <[email-masked]>
Date: Sun, 27 Jan 2019 12:39:41 +0200

Hi all

> On Jan 25, 2019, at 18:21, Niels ten Oever <[email-masked]> wrote:
> 

I am new to this list so I am sorry if I say something wrong but...
Any law of any state has priority over tech standard on the territory of this state. So including GDPR into tech standard has no any sense.
Moreover it is wrongly because if legislator changes GDPR then the tech standard must be changed because it contradicts the law. So till now I
have not seen any reason to insert GDPR into tech standard. I should say that if GDPR was included into the tech standard, our registry 
would not implement this extension. I think our registry is not the only one because it is impossible to mix tech standards with legislation.

> PS The legislation not only applicable in the European Union, but anywhere in the world where the data of EU citizens or residents is held.

There are lot of cases where citizen of EU is not any side of agreement.

--
Best regards

Taras Heichenko
[email-masked]