Public Comment CloseStatement



Call for
Comments Open
Call for
Vote OpenVote CloseDate of SubmissionStaff Contact and EmailStatement Number

21 December 2018


15Y, 0N, 0A

19 December 2018

21 December 2018

02 January 2019

06 January 2019

21 December 2018


Hide the information below, please click here 


The final version to be submitted, if the draft is ratified, will be placed here by upon completion of the vote. 

Note: final version includes cover letter with ALAC ratification information and copy of the Word Doc.


The final draft version to be voted upon by the ALAC will be placed here before the vote is to begin.


The first draft submitted will be placed here before the call for comments begins. The Draft should be preceded by the name of the person submitting the draft and the date/time. If, during the discussion, the draft is revised, the older version(S) should be left in place and the new version along with a header line identifying the drafter and date/time should be placed above the older version(s), separated by a Horizontal Rule (available + Insert More Content control).

Revised draft submitted by Alan Greenberg, 20 December 2018

Significant changes to answers to questions 29, 30, 44, 45, 145, 147.

Draft submitted by Alan Greenberg, 09 December 2018.


  1. The first draft of the EPDP Response is now uploaded. It is essentially the same as that presented on the CPWG call on 28 Nov 2018.

    One point on which there was significant discussion on the call was whether we should support geographic differentiation - that is, only apply redaction if the geographic location of the registrar/registry and the registrant warrant it or allow contracted parties ot redact for all registrations. When this was previously discussed, there was quite a divide between those who felt we should differentiate, and those who felt that a contracted party could decide whether to do it or not (ie a registrar, for instance) could decide to treat all registrants as if they were in the EU, and similarly a registrar outside of the EU (with no connection there) could also redact all data.

    One of the things that has changed is that the European Data Protection Board has recently issued a document making it clear that an organization with NO presence or processing in the EU, offering services through the web, could have EU-based customers and not be subject to the GDPR - IF they do not explicitly target EU customers. Simple availability of a website in the EU does not constitute targeting. That take a large number of contracted parties who many of us had thought would be subject to the GDPR out of the game. See

    On the CPWG when the question as ask about supporting geographic differentiation (oe Registrars/Registries should only redact when GDPR requires it, the overwhelming number agree (via check marks or voiced comments). This position is reflected in answers 86 and 89.

    Please add your comments or thoughts on any of the replies here.

  2. Comment from Holly:

    Hi Alan

    For some reason, I wasn’t able to comment on the wiki. So this is what I would have said:

    My one word of caution is back to first principles.  WE are so focussed on the GDPR that we forget that other jurisdictions also have privacy legislation that  could well oblige the registrar/reseller to not publish personal information/some personal information of the registrant.  So I”d rather stay with a position that allows all registrars/resellers - in whatever jurisdiction globally - to respect their national privacy legislation - as is currently allowed under the RAA - the ability to comply with national laws.  So that comes close to the view originally agreed upon as you penned it: ‘those who felt that a contracted party could decide whether to do it or not’.  Perhaps reword, but accept that contracted parties may well be subject to their own privacy laws in jurisdictions outside of the EU.


    1. My reply:

      I agree that we should be drafting something more specific that just for GDPR, but we are where we are and time constraints do not give us that luxury. But local law may well be more stringent than GDPR, or less so. And ultimately local law wins. Hopefully various laws do not conflict (such as if one country were to rule that ALL registrations were to be made public).

      ICANN entered into this with the intent of being 100% GDPR (or ultimately other law) compliant, but keeping as  much of what we were doing before as is compliant. The draft statement is aligned with that. So yes, a contracted party MUST be able to comply with whatever laws apply. That is not their "choice". What we are talking about is whether they should be allowed to make up new rules that are not law and ICANN should  simply say "sure, go ahead". THAT I feel is what we are saying no to.

      Regarding "Perhaps reword, but accept that contracted parties may well be subject to their own privacy laws in jurisdictions outside of the EU.", I think that is a GREAT addition to our comment, not just for this particular question, but as an over-riding principle that we need to remember. I think there is a place to put it and I will!


    2. I share Holly's concern even as I recognize that the ePDP WG Charter binds the team to a certain focus.   

      1. To be clear, I have no problem making it clear that all contracted parties are allowed to and indeed must follow all laws/regulations to which they are subject, and am happy to add such a statement.

        The question is whether they should be able to redact virtually all information even if they are NOT subject to laws/regulations that require it.

  3. Thanks Alan and Hadia for this intial draft, after a quick read here are 2 minor points i like to state:

    item 50: I do think response is partly Yes/No(i actually do not think both should have been merge together in a question). That said, I suggest we should be more explicit about billing contact by stating clearly that they should remain none-public. I don't think the last part is necessary (to say ALAC has not idea of what a billing contact is used for is strange, if not for anything a typical registrant would know its used for payment).

    item 70: I indeed agree with the rationale

    item 77: I think its not just "displaying" that the question was referring to. The process of identification goes beyond just display, so while i agree with the intent of our text in leaving it to the registrant to decide, i suggest that we use the actual wording intended in the original question which is identification.

    1. Seun thanks for taking the time to do this!

      Q 50: I agree neither Yes not No is the right answer, but the form requires one answer. I though a No would get more attention.

      There is a typo in the answer regarding billing contact - it should have been "Billing contacts are not part of the public WHOIS and the ALAC has no concern with what is done with them."

      To be clear, the Billing Contact is vestigial (you can Google it if you are not familiar with the word but it refers to something that may have had a purpose once but no longer has any function). Pre-GDPR, it was not displayed in the public WHOIS, and it is not used by Registrars (who have their own non-WHOIS account information).

      Q70: Thanks!

      Q77: I don't think that the phrase "...subject to the registrant being given and option to consent to be identified." properly conveys the intent. I would make a wording change in our answer though saying "...subject to the registrant being given an option to consent to the allow the information to be publicly published/displayed."

  4. Rather than changing the uploaded document, I shall put my comments here and then we can make one edit to the document with all the agreed upon changes

    Recommendation #1

    Purpose 6

    22. Support Purpose intent with wording changes

    23. Suggested edit " for resolution of disputes regarding or relating to domain names"

    or "for resolution of disputes regarding or relating to the registration and/or usage of domain names"

    24. Please provide rationale for your recommendation:

    Dispute procedures like the UDRP and the URS deal with disputes related to both the registration and usage of the domain names. In relation to the URS one of the reasons for the request for a rapid suspension of a website is offensive website content. According to section 1.2.4 of the URS the content of the complaint may include a copy of the offending portion of the website content.

    section 3-IX of the UDRP says" the complaint should describe the grounds on which the complaint is made including in particular why the domain names should be considered as having been registered and being used in bad faith."

    and section 3-viii of the UDRP also refers to the usage of the domain name.

    In addition annex G-1 of the bylaws says "as opposed to  the use of such domain names, but including where such policies take into account use of the domain names"

    Offensive website content and trademark abuse have direct harmful effects on individual Internet users who could be confused or victims of fraud activities. Therefore the ALAC finds it essential that ICANN dispute procedures continue post the implementation of the GDPR without impediment to the utmost extent possible.

    1. Allowing disputes related to the use of domain names will not fly as it is counter to explicit terms in the ICANN Bylaws. The reference to the phrase used in Annex G-1 is a specific carve-out.

      Other types of fraudulent or illegal activity that may be identified bby how the domain is being used are not addressed by formal dispute processes but by contractual terms which require contracted parties to react promptly o reports of such activities.

      Not sure if this reply is complete, but must go catch a flight and will review further later.

      1. So my other suggestion is to either say "concerning or relating to domain names" with out saying registration or usage or 

        say "for resolution of disputes regarding or relating to the registration of domain names (as opposed to  the use of such domain names, but including where such policies take into account use of the domain name)"

        1. You wouldn't believe the amount of time that was spent hammering out the language in the Bylaws. Using any language but that is going to prolong the debate.

          Let's talk when I am home tomorrow or on the weekend.

  5. Recommendation #1

    28. Enter Additional comments to Recommendation #1

    The ALAC sees that activities like the WHOIS Accuracy Reporting System (ARS) and the use of the WHOIS registration data by the office of the chief technology officer (OCTO) for training and outreach are not fulfilled through the aforementioned purposes. In addition ICANN needs to continuously advance its operational and administrative role in relation to the stability, reliability, and security of the Internet and to do so research is needed. Therefore ALAC recommends adding an additional purpose that can address the aforementioned needs.

    Question #1 For community Input

    29. If you recommend additional purposes for processing registration data, please enumerate and write them here, keeping in mind compliance with GDPR

    ALAC recommends adding a purpose for research. This additional purpose is to fulfill the needs of activities like the Accuracy Reporting System (ARS) carried by the global domains division (GDD), the training and outreach conducted by OCTO and other ICANN research needs required for the advancement of the Internet and its global outreach. 

    30. Under the GDPR processing personal data for the purpose of research is a lawful legitimate purposes with safeguards identified in article 89 and explanations provided in recital 159. For ICANN to continue exercising its role in accordance to its bylaws research is required and this is to ensure the security and stability of the Internet and mitigate any threats. In addition publishing the results of the research would benefit the community. 

    With regard to the use by the OCTO office: ICANN is responsible for the DNS and this involves fully understanding all aspects of it. Activities may include addressing DNS threats and potentially developing an evolution of it or a dissimilar replacement. To do that it needs to have access to all aspects of the DNS. If ICANN were a typical controller, it would have access to all of the data to begin with, and this would be covered under secondary processing provisions, but since ICANN is not in possession of the data, we must make sure that it has suitable access.

    Accuracy Reporting System (ARS): The ARS was created in response to recommendations complied by the 2012 WHOIS Review Team (RT). ICANN committed to proactively identify inaccurate gTLD WHOIS contact data and forward this data to gTLD registrars for follow-up. The ARS has demonstrated that when domains are selected randomly, nearly 40% have suspect contact information. Article 5.1.d of the GDPR requires data to be accurate with regard to the purpose for which it is being processed therefore to be in compliance with the GDPR and for the integrity of the data of the RDS the ARS should be allowed to continue.


  6. Recommendation #4 Data Elements

    Question #2

    44. If you believe additional data elements should be collected/ generated,please enumerate which additional elements should be collected /generated

    The ALAC sees that a new field that requires the registrant to determine if he/she is a legal or natural person should be added to the data elements collected. In addition the Administration Contact (Admin-C)  and the Technical Contact (Tech-C) should be reinstated.  

    45. Please provide the rationale for your answer

    A new field that determines if the registrant is a natural or legal person is required because the scope of the GDPR is the processing of the personal data of natural persons and not legal persons and though the EPDP team has not yet reached a decision in relation to differentiating between natural and legal persons - because of concerns related to the contracted parties liability in this regard -  collecting this information and keeping it on records even if no differentiation would be made in the processing of the data based on this information makes sense. Previously the WHOIS data had the organization field from which you could tell if the domain belonged to a natural or legal person now and without this field there is no other means through which you could determine if the domain belongs to a natural or legal person. Collecting the information that determines if the domain name owner is a natural or legal person even if we are not going to act upon it is necessary to protect the rights of the natural individual Internet users.  

    The ALAC sees that the administration contact (Admin-C) should be reinstated because though in cases of private domain name registrations i.e. personal domain name registrations it makes sense that the domain owner is also the administrator, many legal entities (companies) might like to leave the task of the domain administration to a specialized domain administrator to handle all the company's domain names. Since the Admin-C acts on behalf of the domain owner and has full access rights to the domain name, registrars are not at risk if they provide this option to the registrants to whom this field is necessary. The technical contact (Tech-C) is a field that might be required by some natural and legal domain owners and in cases where the domain name has been delegated its own name server and in the absence of the zone administrator contact (Zone-C) which gives the contact for the person responsible for the maintenance of the domain name server the Tech-C becomes necessary for some registrants and we note that the Tech-C does not need to be a person it can be a general term like the IT department of a company or any other non personal contact. We note as well that Registrant provided data must not be unilaterally removed without due consultation with the data provider there should be a clear understanding on how the existing data in these fields (when it is unique to those fields) will be handled by registrars and registries. Registrants have provided contact data in good faith and that data must be honored by the Registrar/Registry. If it is to be changed, there must be a process developed to ensure that the registrant agrees. To do otherwise is having the controller/processors alter registrant data without their approval and is counter to the intent of the GDPR.

  7. 49. Please provide the rationale for your answer.

    All registrants should be given the option of providing the data. The concept that if a registrant wants to provide this data, they need to look around for a registrar that allows its entry is ridiculous. Registering a domain name and they taking care of it is a sufficiently complicated task that adding a “search” part of the process, when a potential registrant does not even know that the field exists or may not exist for a given registrar adds a level of complexity that would be difficult to document and deceptive to not ensure that a registrant understands their options. In addition and with regard to the registrars feeling at risk about providing tech or admin fields the EDPB mentions in its letter directed to ICANN on July 5 2018 that during the registration process it should be made clear to the registrant that they are free to (1) designate the same person as the registrant (or its representative) as the administrative or technical contact or (2) provide contact information which does not directly identify the administrative or technical contact person concerned (e.g. That is the EDPB does acknowledge that such fields could be necessary for some of the registrants and puts the aforementioned recommendation in relation to the admin and tech fields. Therefore the ALAC recommends making the admin and tech fields mandatory for the registrar to provide as an option to the registrants while noting in writing the EDPB recommendation in this regard.   

  8. Recommendation #8  Data Redaction

    70.Please provide rationale for your answer above.
    There are a number of reasons it should not be redacted.
    - For web sites (and other Internet resources) that are nominally commercial, Internet users should have
    SOME ability to know who is behind it (or if it
    is being hidden by Privacy/Proxy). Without the Organization
    field, there is NOTHING.
    - The Temp Spec has required the Organization filed to be displayed and there has not been any evident major
    issue about it.
    - It is an OPTIONAL field to fill in and Registrants can be warned that it will be displayed if filled in. So there is no reason to NOT display it.

    The ALAC would also like to note that the Admin-C field should be reinstated and should appear like the Tech field in this regard

  9. Recommendation #22 updates to existing consensus policies 

    142. If you do not support Recommendation #22, please provide proposed edits or changes here

    The ALAC would like to note that migration from thin to thick registries should be respected and that the registrars and registry operator of .COM, .NET and .JOBS  should comply with the announcement made by  ICANN on 25 October 2018 which states that

    • By 31 May 2019: The registry operator must begin accepting Thick WHOIS data from registrars for existing registrations in .COM, .NET and .JOBS.
    • By 30 November 2019: All registrars must send Thick WHOIS data to the registry operator for all new registrations in .COM, .NET and .JOBS.
    • By 31 May 2020: All registrars are required to complete the transition to Thick WHOIS data for all registrations in .COM, .NET and .JOBS.


  10. Other Comments & Submission
    147. Are there any other comments or issues you would like to raise pertaining to the Initial Report? If yes, please enter your comments here. If applicable,
    please specify the section or page number in the Initial Report to which your comments refer

    With regard to recommendation # 2 Standardized Access the ALAC would like to note that since this initial report attempts to answer the gating questions necessary to start access discussions it is essential that the EPDP team establishes a date for the discussions about access to commence. 

    The ALAC would also like to note that collecting the data that differentiates between natural and legal persons is essential even if there is no differentiation in the processing of the data in this regard. The GDPR applies only to natural persons and not legal ones and ICANN does not make its own laws, therefore if we are seeking compliance this information should be known even if not acted upon, this is primarily to protect the rights of the natural persons to whom the GDPR applies.

  11. Hi All,

    I have updated today question 2 -44 adding a field that requires the registrant to state if he is a natural or legal person and have updated 147(other comments and suggestions). What I initially did with all the comments is that I incorporated Alan's edits with my edits. Alan and I are waiting for your comments.

  12. A revised draft has been uploaded, addressing the the comments submitted here as well as other issues that have arisen.

    There are minor changes throughout and major changes to questions 29, 30, 44, 45, 145 and 147.

    This draft is now largely complete. Further changes should be in light of typos or specific errors. The final version will be submitted on Friday, 21 December and ratified after the fact by the ALAC.