ICANN’s contract with the USA Expires.

https://www.icann.org/news/blog/cheers-to-the-multistakeholder-community

So it has been done, and we are on our way. Years of discussions come to an end? Not likely but we have a significant milestone here.

The ICANN board is more accountable now and can be replaced.

The GAC aka governments can no longer take over the interwebz.

The USA demonstrated to the world that it takes the multi-stakeholder model serious and as such, it is out of the grasp of the UN or the ITU. Imagine the UN run the internet 😉 Ted Cruz and some other idiots who demonstrated clearly

Ted Cruz and some other idiots who demonstrated clearly that they have no idea how the internet runs can pack it in. The internet will keep on working as it is. Beside ICANN only has a clerical function when it comes to the internet and is not the content policy or has any mandate when it comes to content. ICANN can only create policies through the stakeholder model wich is a bottom-up process and not a top-down process.

Theo Geurts ICANN community member.

Thick WHOIS Migration Part two, The Draft V5

As I am on a roll this morning lets’ zoom in the Thick WG latest draft and provide it with some early comments and background detail. thick-transition-policy-draft-v5-20160929-clean-with-comment

Redline version in full:

Thick Whois Transition Policy for .COM, .NET and .JOBS

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, and “MAY” in this document are to be interpreted as described in RFC 2119, which is available at http://www.ietf.org/rfc/rfc2119.txt.

Scope:

This Policy SHALL apply to the Registry Operators for the .COM, .NET and .JOBS gTLDs, as well as all Registrars sponsoring domain name registrations in the .COM, .NET and .JOBS gTLDs.

Definitions:

  • Thin (Registration): domain name for which the Registry Operator maintains and provides only technical information (e.g., name servers, statuses, creation date) and the Sponsoring Registrar associated with the domain name. Contact information for these domain names is maintained only by the sponsoring Registrar.
  • Thick (Registration): domain name for which the sponsoring Registrar provides a copy of the associated contact information to the Registry Operator. Registry Operator maintains the technical information (e.g., name servers, statuses, creation date) and the sponsoring Registrar associated with the domain name. Contact information for the domain name is maintained by the sponsoring Registrar.
  • Existing Domain Name: domain name created, or in pendingCreate status, before 1 May 2018.
  • Transition Progress Metrics: metrics created by Registry Operator and communicated regularly to Registrars and ICANN to allow measurement of progress of the transition from Thin to Thick, including at least the total number of domains managed by Registrar, number and percentage of domain with contact objects attached
  1. Effective Dates:
    1. All new domain name registrations MUST be submitted as Thick starting on 1 May 2018 at the latest.
    2. All registration data for Existing Domain Names MUST have been migrated from Thin to Thick by 1 February 2019.
  2. The following requirements apply to Registry Operators only:
    1. Registry Operator MUST deploy an EPP mechanism by 1 August 2017 for registrars to migrate registration data for Existing Domain Names (i.e., the transition from Thin to Thick).
    2. Registry Operator MUST upon request provide an alternative bulk transfer mechanism by 1 February 2018 for registrars to migrate data for Existing Domain Names (i.e., the transition from Thin to Thick). The request MUST be made by 1 August 2017.
    3. By 1 May 2017, Registry Operator MUST provide to applicable Registrars and ICANN, documentation reflecting the system changes necessary to support the requirements of Sections 2.1 concerning relevant Operating Test Environments (OT&E) available to Registrars and by 1 August 2017 for Section 2.2.
    4. Starting 1 August 2017, Registry Operator MUST support all contact commands specified in RFC5733 as described in this provision. The EPP contact fields <contact:id>, <contact:postalInfo>, and <contact:authInfo> will be REQUIRED by the Registry Operator. Registry Operator MUST accept but MUST NOT require all other registration data elements that enable it to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the “Base Registry Agreement approved on 9 January 2014” (“Base Registry Agreement”) and the Registry Registration Data Directory Services Consistent Labeling and Display Policy.
    5. Starting 1 May 2018, Registry Operator MUST require Thick Registration data for an EPP domain object <create> command as described in this provision. Registry Operator MUST require all registration data elements that enable it to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the “Base Registry Agreement approved on 9 January 2014” (“Base Registry Agreement”) and the Registry Registration Data Directory Services Consistent Labeling and Display Policy.
    6. Between 1 August 2017 and 1 February 2019, Registry Operator SHALL provide Transition Progress Metrics to each registrar at minimum Monthly by the first day of the next month at 23:59 UTC.
    7. Between 1 August 2017 and 1 February 2019, Registry Operator SHALL provide to ICANN all Transition Progress Metrics for all registrars at minimum Monthly by the first day of the next month at 23:59 UTC.
    8. Registry Operator SHALL implement the requirements of the Registry Registration Data Directory Services Consistent Labeling and Display Policy (“CL&D Policy”) in conjunction with Section 1 of Specification 4 of the “Base Registry Agreement approved on 9 January 2014” (“Base Registry Agreement”) by 1 August 2017.
    9. Starting 1 May 2018, Registry Operator MUST comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the “Base Registry Agreement approved on 9 January 2014” (“Base Registry Agreement”) and the Registry Registration Data Directory Services Consistent Labeling and Display Policy for other than Existing Domain Names.
    10. Between 1 August 2017 and 1 February 2019, for Existing Domain Names, for the following RDDS Output fields where no data exists in the Shared Registration System (SRS), the Registry Operator MAY treat the following RDDS fields as Optional as described in section 1.2 of the “RDAP Operational Profile for gTLD Registries and Registrars” if implementing RDAP, and in the case of Whois port 43 and Web-Whois, as described in clarification 1 of the “Advisory: Clarifications to the Registry Agreement, and the 2013 Registrar Accreditation Agreement (RAA) regarding applicable Registration Data Directory Service (Whois) Specifications”:
  • Registry Registrant/Admin/Tech ID
  • Registrant/Admin/Tech Name
  • Registrant/Admin/Tech Street
  • Registrant/Admin/Tech City
  • Registrant/Admin/Tech Country
  • Registrant/Admin/Tech Phone
  • Registrant/Admin/Tech Email
    1. The “Billing” contact is optional.  Registry Policy may define if it is required, optional or not supported.  If supported the Billing contact information must be displayed as described in the “Advisory: Clarifications to the Registry Agreement, and the 2013 Registrar Accreditation Agreement (RAA) regarding applicable Registration Data Directory Service (Whois) Specifications” (section 22).
  1. The following requirements apply to Registrars only:
    1. Between 1 August 2017 and 1 February 2019, Registrars MUST migrate to the relevant Registry Operator all required fields of Existing Domain Names that are available in the Registrar database that enable the Registry Operator to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the “Base Registry Agreement approved on 9 January 2014” (“Base Registry Agreement”) and the Registry Registration Data Directory Services Consistent Labeling and Display Policy.
    2. Registrars MAY provide complete Thick Registration data to Registry Operator that enable it to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the “Base Registry Agreement approved on 9 January 2014” (“Base Registry Agreement”) and the Registry Registration Data Directory Services Consistent Labeling and Display Policy, upon creation of new domain name registrations starting 1 August 2017.
    3. Registrars MUST provide complete Thick Registration data to Registry Operator that enable it to comply with WHOIS (available via port 43) and web-based directory services requirements described in Section 1 of Specification 4 of the “Base Registry Agreement approved on 9 January 2014” (“Base Registry Agreement”) and the Registry Registration Data Directory Services Consistent Labeling and Display Policy, upon creation of new domain name registrations starting 1 May 2018.

Implementation Notes

  1. Where a conflict exists between local privacy laws and requirements included in this Policy, ICANN’s Procedure for Handling WHOIS Conflicts with Privacy Laws is available for Registry Operators and Registrars

 

Theo Geurts ICANN IRT member

Completely and totally not related music video but still one helluva song.

Thick Whois Migration Verisign

I have been at the IRT for the Thick WHOIS Verisign Migration for some time now (early NOV 2015).

All was well, till we received a draft from Verisign that there might be some issues. This memo wich has been prepared for the GNSO highlights some potential issues.

I’ll publish it in full:

DRAFT

To: GNSO Council

From Thick Whois IRT

Date: xx August 2016

Re: Notice of Unanticipated Thick Whois Privacy Issues

In accordance with Recommendation #3 of the GNSO Council Consensus Policy Recommendations on Thick Whois adopted by the ICANN Board on 7 February 2014 (the “Thick Whois Policy”), the Thick Whois Implementation Review Team (“IRT”) is hereby providing notice to the GNSO Council that privacy issues have emerged from the thin to thick data transition discussions that were not anticipated by the August 29, 2013 Expert Working Group Memo (the “EWG Memo”) and that appear to require additional policy consideration by the GNSO Council so that appropriate action can be taken as the Thick Whois Policy implementation process continues to move forward.

Specifically, and as outlined in more detail below, the recent invalidation of the US-EU Safe Harbor Program and the adoption of the new EU-US “Privacy Shield” framework, the adoption of the General Data Protection Regulation (“GDPR”) in the European Union (“EU”) and the ongoing legal challenges and scrutiny regarding transfers of personal data to the US from the EU have resulted in significant uncertainty regarding data privacy requirements associated with the collection, storage, transmission and display of personally identifiable information (PII), specifically thick Whois data, that should be addressed as the implementation of the Thick Whois Policy moves forward.

Recommendation #3 of the Thick Whois Policy states:

As part of the implementation process a legal review of law applicable to the transition of data from a thin to thick model that has not already been considered in the Expert Working Group (EWG) memo is undertaken and due consideration is given to potential privacy issues that may arise from the discussions on the transition from thin to thick Whois, including, for example, guidance on how the long-standing contractual requirement that registrars give notice to, and obtain consent, from each registrant for uses of any personally identifiable data submitted by the registrant should apply to registrations involved in the transition. Should any privacy issues emerge from these transition discussions that were not anticipated by the WG and which would require additional policy consideration, the Implementation Review Team is expected to notify the GNSO Council of these so that appropriate action can be taken.

As required by Recommendation #3, ICANN staff conducted a legal review of law applicable to the transition of data from a thin to thick model and communicated the results of this review to the IRT in a Legal Review Memorandum dated 8 June 2015 (the “Legal Review Memo”). The Legal Review Memo focused its analysis on a survey of data protection laws within the EU and based on that analysis advised the IRT that “there are some important and legitimate questions relating to data protection obligations under local law that must be addressed” as a part of the Thick Whois Policy implementation. The Legal Review Memo further advised the IRT that the legal requirements regarding the disclosure and transfer of personal data to the relevant registries “trigger particular attention” in relation to the implementation of the Thick Whois Policy. (p. 6)

In the short period since the Legal Review Memo was provided to the IRT highlighting the importance of addressing the law in the EU regarding the disclosure and transfer of personal data as a part of the transition, that law has entered an unprecedented period of change and uncertainty. The US-EU “Safe Harbor Program”, which previously provided one means by which to lawfully transfer personal data from the EU to the US, was invalidated in October 2015 and the replacement “EU- US Privacy Shield” announced in February 2016 was just recently adopted by the European Commission on 12 July 2016.1

In the wake of the invalidation of the US-EU Safe Harbor Program and the development of the EU-US Privacy Shield, the use of consent to effectuate transfers of personal data, which the Legal Review Memo identified as “likely to be the most expedient way of addressing the transition to thick Whois” (p. 10), has been called into question by regulators in the EU, particularly in the context of large and/or repeated transfers of personal data. Both the Irish and German data protection regulators, for example, have indicated that reliance on consent, standing alone, may be problematic and German regulators have determined that consent is not valid for “massive or routine” transfers of personal data.2

The law in the EU regarding personal data protection, in general, has also entered a state of uncertainty and change since the EWG considered the privacy issues associated with the transition, as the new GDPR was adopted on May 4, 2016, and will go into effect on May 25, 2018.3

The GDPR establishes a substantially more restrictive compliance landscape regarding the consent-based processing of personal data. For instance, the European Commission’s fact sheet on the GDPR notes that consent “will have to be given by means of a clear affirmative action before a company can process your personal data.”4 The new GDPR may, therefore, have a significant impact on the Thick Whois transition when it comes into force, particularly with regard to reliance on registrant consent for effectuating the transition.

The IRT believes that the invalidation of the US-EU Safe Harbor Program, the development of the EU-US Privacy Shield, the adoption of the new GDPR by the European Commission and decisions by regulators raise new privacy issues not anticipated by the EWG that require additional policy consideration by the GNSO Council, particularly with respect to the potential use of registrant consent to effectuate the Thick Whois transition. Moreover, as Legal Review Memo recognized, EU data protection laws “embody international principles which serve as a basis for many data protection laws around the world.” (p. 3) In addition to the uncertainty caused by changes in EU laws, members of the IRT are also aware of other jurisdictions which have, or are in the process of, enacting regulations with a potential direct impact on thick Whois policies and procedures, such as laws that require personal data to be hosted locally within a particular jurisdiction. The proliferation of these laws and applicability to the collection, storage, transmission and display of personal data should be a consideration for all gTLD registries and registrars, and in particular for the transition of gTLDs from a thin to thick Whois model.

1 See European Commission Press Release, “European Commission launches EU-U.S. Privacy Shield: stronger protection for transatlantic data flows” (available at http://europa.eu/rapid/press-release_IP-16-2461_en.htm).

2 See Data Protection Commissioner of Ireland, “Transfer Abroad” Guidance (available at https://www.dataprotection.ie/docs/Transfers-Abroad/y/37.htm); Conference of the Data Protection Commissioners of the German Federation and the German States, DSK Position Paper on Safe Harbor Invalidation (available at https://www.datenschutz.hessen.de/ft-europa.htm#entry4521).

3 See European Commission, “Reform of EU data protection rules” (available at http://ec.europa.eu/justice/data-protection/reform/index_en.htm).

4 See European Commission Factsheet, “How does the data protection reform strengthen citizens’ rights?” (available at http://ec.europa.eu/justice/data-protection/reform/index_en.htm)

My problem here? Well as an EU Registrar we never cared much about Safe Harbor. After all, we never sent any personal data to Verisign to register .com or .net domain names. So safe harbor was never on our radar, least not on mine. Now it does, and a lot of our business depend on having a reliable process. Privacy Shield is the follow up for the invalidated Safe Harbor. Lawyers in Europe tell me that Privacy Shield will not last long, couple a years max.

So yes, I am sorta paralyzed on what to do here. We got a lot of business riding on this for sure, and it looks like we are moving into uncertain waters. On the flip side, the current system is not great also. It won’t be long till some EU privacy regulator comes knocking on our door when it comes to our WHOIS server and the data being published there.

Are we going to buy some time by shifting the legal burden to Verisign or in the long run we have created a single point of failure, and we discover in time that the system has failed? I have no idea.

Theo Geurts

ICANN IRT Member