Yoda says:”purpose you shall have.”

Or when I returned from Copenhagen ICANN 58, you shall have a purpose.

I have been struggling with the upcoming EU GDPR for a year now. Read the GDPR, read a few books and it just didn’t sink in, let alone I could figure out how to attack this thing on ICANN level or at the Registrar I work for.

For more than a year the RDS WG, the group that is working on a replacement for the WHOIS, has been collecting requirements on what is required for this RDS. The number of requirements we gathered is insane, over 1000 requirements.

We heard from about every stakeholder what they need, and in every discussion, privacy would come up, and how that should work, usually such discussion would look more like a trench war, as most folks think privacy does not equal the abuse problems we are facing.
But ICANN 58 a group of EU Data Commissioners assisted us, including the U.N. Special Rapporteur on the right to privacy and Caroline Goemans-Dorny INTERPOL’s data protection officer.

During the RDS session on Wednesday, something happened that provided me with total clarity. We were running out of time, and we did not really get into the question session we prepared. At one point the Chair of the RDS WG fired off like four questions at once, related to a thin WHOIS output that was shown on the slides.

The U.N. Special Rapporteur said:”I will answer all your questions, with one question,” what is the purpose?
This almost Yoda-like response gave me a real sense of clarity.
Why do we put an expiry date in the WHOIS?
Why do put a create date in the WHOIS?
Why do we put an update date in the WHOIS?

My cell phone subscription is not being published in a public directory, nor is it mentioned when I upgraded my cell phone subscription in a public directory. At that point, it was clear to me that this was not about thin or thick WHOIS, we put the cart before the horse.
I expressed my gratitude in public to the U.N. Special Rapporteur.
After the session I was having a smoke and saw the U.N. Special Rapporteur leave the building real quick, rushing to a taxi (busy person) and just when he hailed a taxi he spotted me, walked up to me, shook my hand and said:”Thank you for the support, and I have the feeling you now have a clear vision on what purpose is”.

I have it for sure, and the entire EU GDPR makes sense now. The EU GDPR is Europe setting a very high ambition trying to create logic in how you process or collect data. The EU GDPR text itself does not provide clear answers; it just shows ambition.

All your current processes need to be re-evaluated, and you have to ask what the purpose is? If you have a clear purpose and you can motivate it, then most likely you are on the right track. The EU GDPR can provide more guidance.
If however you encounter a situation and you ask what the purpose is, and the answer is dodgy, shady or not clear, or the answer is, it is nice to have, then you are most likely on the wrong track.

How does this guide me when it comes to the RDS and the WHOIS?
Simple, the WHOIS is a “nice to have,” that completely spiraled out of control and has no place in this day and age.

RDS? Even though we are still in its early stages, it seems we are working on a compromise to keep everyone happy. Keeping everyone happy and yet complying with the law, is not possible, so the current purpose of RDS will turn into a failure.

Later this week I will go more into detail why RDS will never work and what is required and how we should combat abuse, though I did not figure out the abuse part, yet.

Theo Geurts ICANN RDS WG member.

This blog post was created while listening to:

ASOP Global Internet Pharmacy Safety E-Commerce Leadership Award.

And I won it, at ICANN 58 in Copenhagen.

And it did not cost me a much energy at all. That is the deciding factor how I won the award. Connecting key players (LEA’s), connecting key actors (Registries & Registrars) and as such the internet became safer, consulting, advising, participation, things, that give me energy. And if it gives one energy, it all becomes easy.

The award was handed to me by ASOP.EU. Their goal:

An early objective for the coalition will be to develop and issue a ‘call for action’ inviting the European authorities to evaluate policies and legal measures to tackle illegal online sales and launch a dialogue with key stakeholders including internet intermediaries to take action against illegal online pharmacies.  The coalition will play a valuable role in demonstrating broad-based support for urgent action to tackle this patient safety threat. It should rapidly become a trusted partner of the authorities as measures are developed to deal with illegal online pharmacies.

The award looks like this:

I guess the photo does not do complete justice to the award. It was however so large (and heavy) that I asked the hotel staff to have UPS ship it back to me, as there was no way it would fit in my carry-on luggage.

ICANN 58 took place in this great convention center, Bella Sky in Copenhagen. Expect more updates soon.

ASOP press release can be read here.

 

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.