This purpose description seems to be a significant case of mission creep by including non-technical uses under the commitment  of section 1.2(a)(i), which should remain focussed on the technical role of ICANN of maintaining a secure, stable and resiliant DNS.

Adding in fraud or crime prevention expends the scope beyond that contemplated in the bylaws and should be rejected.

The best definition of this purpose is included in the bylaws under the scope of the Security, Stability, and Resiliency Review as well as the Annexes G1 and G2, none of which provide for such a broad interpretation of this purpose.

This purpose is a technical function with some elements regulating the behaviour of those parties that a delegated elements of this technical functions, e.g. the contracted parties, with regard to this technical function.

Best,

Volker

Thanks, Benedict.

 

Given the proximity to ICANN63, we took the liberty of sending this language to the full team so that we can discuss in Barcelona.

Thanks again for taking the lead on this!

 

Best regards,

 

Marika, Berry and Caitlin

 

From: Benedict Addis <bee@theale.co.uk>
Date: Tuesday, October 16, 2018 at 6:21 AM
To: Kurt Pritz <kurt@kjpritz.com>
Cc: Stephanie Perrin <stephanie.perrin@mail.utoronto.ca>, Thomas Rickert <epdp@gdpr.ninja>, Lindsay Hamilton-Reid <lindsay.hamilton-reid@fasthosts.com>, Caitlin Tubergen <caitlin.tubergen@icann.org>, "gnso-epdp-lead@icann.org" <gnso-epdp-lead@icann.org>
Subject: [Ext] Re: [GNSO-EPDP-Lead] Purpose B Small Team

 

Dear all,

 

On Kurt’s suggestion, I propose the following Purpose B that relies directly on the language in Recitals 47, 49 and 50.

 

[ICANN requires that registration data is processed for the purpose of...]

 

maintaining the security, stability and resiliency of the Domain Name System. This will involve the disclosure of existing registration data to legitimate third parties, for the following reasons only: 1) fraud prevention; 2) network and information security; and 3) indicating possible criminal acts, or threats to public security.

 

I think that for ICANN, disclosure will happen under 6(1)f. Third parties will require a lawful basis of their own for their processing, governed by a common set of standards that we’ll discuss when we come to the access discussion.

 

Thoughts?

B

 

_______________________________________________
Gnso-epdp-team mailing list
Gnso-epdp-team@icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdp-team

-- 
Volker A. Greimann
General Counsel and Policy Manager
KEY-SYSTEMS GMBH

T: +49 6894 9396901
F: +49 6894 9396851
W: www.key-systems.net

Key-systems is a company registered in Germany with Registration No.: HR B 18835 - Saarbruecken: CEO: Alexander Siffrin
Registered Offices: Im Oberen Werk 1, DE-66386 St. Ingbert, Germany

Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358.
Registered Offices: 35-39 Moorgate, London, EC2R 6AR.