AT-LARGE GATEWAY

At-Large Website

ALAC

RALOs

At-Large Regional Policy Engagement Program (ARPEP)

At-Large Governance

At-Large Reports

Policy Comments & Advice

Working Groups

ICANN Meetings

At-Large Summit (ATLAS III)

At-Large Review Implementation Plan Development

ALAC and RALO Elections, Selections, and Appointments

At-Large Priority Activities - 2021

Public Comment CloseStatement
Name 

Status

Assignee(s)

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

07 July 2017

Revised ICANN Procedure for Handling WHOIS Conflicts with Privacy Law: Process and Next Steps

ADOPTED

13Y, 0N, 1A

Christopher Wilkinson

Assisted by:

Olivier Crépin-Leblond, Bastiaan Goslings, Werner Hülsmann, Andrei Kolesnikov, Yrjö Länsipuro, Annette Mühlberg, Valentina Pavel, Rainer Rodewald, and Erich Schweighofer 

02 June 2017

26 June 2017

07 July 2017

12 July 2017

07 July 2017

Eleeza Agopian
eleeza.agopian@icann.org

AL-ALAC-ST-0717-01-01-EN

Hide the information below, please click here 

Brief Overview

Purpose: This public comment proceeding seeks to obtain community input on the effectiveness of the updated ICANN Procedure for Handling WHOIS Conflicts with Privacy Law (WHOIS Procedure), which was recently revised to incorporate an "Alternative Trigger," in addition to the existing trigger to invoke the procedure.

Current Status: This assessment is posted for public comment in response to a Generic Names Supporting Organization (GNSO) Council request. Public comment is sought on the assessment of the practicality and feasibility of the additional trigger recently added to the WHOISProcedure, in comparison to the existing trigger to invoke the WHOIS Procedure as well as other triggers.

Next Steps: ICANN will review and summarize the feedback and report back accordingly to the GNSO Council. As directed by the ICANN Procedure for Handling WHOIS Conflicts with Privacy Law, this assessment is intended to inform the next periodic review of the WHOIS Procedure, which will commence no later than 1 October 2017.

Section I: Description and Explanation

In response to a Generic Names Supporting Organization (GNSO) Council request, ICANN staff has published an assessment of the revised ICANN Procedure for Handling WHOIS Conflicts with Privacy Law (WHOIS Procedure), which was made effective on 18 April 2017. Specifically, this paper is intended to collect input on the assessment of the practicality and feasibility of the "Alternative Trigger" recently added in Step One of the WHOIS Procedure, in comparison to the existing trigger to invoke the procedure as well as other triggers previously discussed by the community. Given that the WHOIS Procedure has recently been updated, and no registrar or registry operator to date has formally invoked the procedure, this analysis is based on community discussions and input received during the previous review of the procedure that will allow for evaluation of the triggers required for invoking the procedure. It also draws upon ICANN's experience administering other processes where a contracted party is seeking ICANN's approval for new services, or waiving certain contractual requirements, as a point of comparison for the implementation of the procedure.

The existing trigger in the original WHOIS Procedure allows a registry operator or ICANN-accredited registrar to invoke the procedure if they are in receipt of a notification of an action that its compliance with WHOIS obligations are prevented by local laws. With the additional trigger, a registry operator or ICANN-accredited registrar may now also invoke the procedure by providing ICANN with a written statement from the applicable government agency responsible for enforcing its data privacy laws indicating that a WHOIS obligation in an ICANN contract conflicts with such applicable national law.

This paper outlines a set of questions for discussion that the ICANN community, including contracted parties, data protection agencies, law enforcement and other relevant parties may want to consider regarding the revised WHOIS Procedure and the process itself. The community is encouraged to offer thoughtful comments on utility of the triggers in the updated WHOISProcedure or suggestions on how to move forward with the review. Feedback is especially important to ensure that all issues that need to be considered are identified and examined in the upcoming review.

Section II: Background

In November 2005, the GNSO concluded a policy development process (PDP) establishing a procedure to allow gTLD registry operators and ICANN-accredited registrars to demonstrate when they are prevented by local laws from fully complying with the provisions of their respective ICANN contracts regarding personal data in WHOIS. The ICANN Board of Directors adopted the recommendations in May 2006 and directed staff to develop such a procedure. A contracted party that credibly demonstrates that it is legally prevented from complying with its WHOIS obligations can invoke the procedure, which became effective in January 2008. To date, the procedure has never been invoked. ICANN launched a review of the procedure in May 2014 and concluded that review with the recently adopted update to the WHOIS Procedure.

Following a Call for Volunteers addressed to all interested parties, an Implementation Advisory Group (IAG) was formed to review the implementation of the policy recommendations and began its work in January 2015. The IAG devoted most of its time to discussing whether additional triggers to invoke the procedure should be incorporated and, if so, how to ensure that they remain consistent with the existing policy.

In May 2016, the IAG submitted its final report [PDF, 155 KB] to the GNSO Council and recommended that the WHOIS Procedure be revised to incorporate an "Alternative Trigger," in addition to the existing trigger to invoke the procedure. In February 2017, the GNSO Council passed a resolution adopting IAG's recommendation and confirmed that the modification to the WHOIS Procedure does not change the intent of the original GNSO policy recommendations.

Section III: Relevant Resources

Section IV: Additional Information

Section V: Reports

Staff Contact

Eleeza Agopian
eleeza.agopian@icann.org

 

FINAL VERSION TO BE SUBMITTED IF RATIFIED

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

 

FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC

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

ICANN Procedure For Handling WHOIS Conflicts with Privacy Law

The At-Large Advisory Committee wishes to respond to the public consultation. Although At-Large members participated in the WHOIS-IAG during 2016, we do not believe that the comments of our members as well of others looking for a truly implementable solution were adequately taken into consideration by the IAG and the ICANN staff in the final draft now under public consultation.

I.          The procedure, as eventually revised on the basis of the IAG report, would include significant shortcomings which ALAC does not accept:

  1. The Procedure does not create a level playing field among Registrars. On the contrary, Registrars (and some Registries) subject to privacy laws would have to undertake an onerous case-by-case procedure to obtain the right from ICANN to respect their domestic privacy laws. Whereas Registrars operating out of other jurisdictions would be free to ignore privacy laws which pertain elsewhere. That outcome is inconsistent with ICANN's responsibility for maintaining the conditions of fair competition among Registries and Registrars.
  2. The Procedure is manifestly inefficient: We have been informed that the pre-existing procedure has hardly ever been used! Which means in practice, that Registrars subject to privacy laws have effectively functioned outside applicable local law and their Registrants' personal data have been potentially exposed to bulk downloads and other abuses, without their authorisation and possibly without their knowledge.

    We see no elements in the revised procedure to suggest that in future the procedure would be more regularly used and implemented.
  3. The Procedure still requires that the local agency responsible for compliance shall be empowered to enforce the law (Paragraphs 1a), ii), (f) and (g) of the Procedure). On the contrary there are many regulatory agencies responsible for the implementation of public policy that do not have, in and of themselves, the power of enforcement. ICANN's position presupposes that applicable law can be ignored until it is “enforced”. ALAC cannot support such an anti-social attitude to applicable laws.
  4. The International Legal environment for privacy protection is rapidly evolving:
    We understand that, at least in the European Union and associated countries, the General Data Protection Regulation (GDPR) will shortly introduce a more stringent, uniform and enforceable data protection law throughout that jurisdiction. This would render the proposed ICANN Procedure obsolete.

Independently of the EU GDPR, the ALAC rejects the proposed Procedure for the reasons outlined in Points 1-3, above.

Although this is not the place to address the GDPR in detail, and if our recommendations below are not retained, we suggest that the proposed Procedure should be put on hold, until the implications of GDPR for ICANN have been thoroughly reviewed.



II.        Alternative approaches

The ALAC recommends that ICANN adopt an entirely different approach to the protection of privacy in all DNS related applications, notably WHOIS and its successor implementations. It proposes two alternative approaches, one long term and one short term:

II.A     The preferred long-term policy would be for ICANN to study globally, international best practice in privacy protection, which might arrive in the form of GDPR or indeed any other local privacy law.

It is not unusual for ICANN to implement best practice that goes beyond current applicable local laws:

- Trademark protection in the DNS clearly goes beyond anything that can be ensured on the basis of national laws alone;

- we are not aware of any network security policies elsewhere which go beyond SSAC's advice and implementation in ICANN's operations;

- we expect that the global protection of geographical terms and geographical indications throughout the DNS will in due course in practice extend beyond those provided for by national laws alone.

Accordingly, we have no hesitation to formally request that ICANN study global best practices in the matter of the protection of personal data with the aim to find a satisfactory solution for all parties.

II.B      In the short term, we note that the WHOIS IAG was offered an alternative “easier” solution to the issue in the form of a “block exemption” for EU-based and other Registries and Registrars subject to local privacy laws incompatible with ICANN contracts and procedures. That option was rejected by the IAG and ICANN staff.

The ALAC prefers this option at the present time, as a short term solution until another more elaborate long term solution is found. II.B is the only solution that would be immediately workable.

The ALAC is on record for supporting accurate WHOIS records and whilst understanding the complexity of this topic, it is sensitive of the need to balance the Privacy of individuals with the identification of companies trading on the Internet and the needs of those dealing with cyber abuses such as phishing, malware and spam. The ALAC understands that ICANN will be attempting to satisfy GDPR issues as a matter of priority, but as an interim short term position we would support a block exemption.

 

FIRST DRAFT SUBMITTED

The first draft submitted will be placed here before the call for comments begins.

DRAFT Rev 2 02/06/2017

ICANN Procedure For Handling WHOIS Conflicts with Privacy Law

Response to the public consultation

The At Large Advisory Committee wishes to respond to the public consultation. Although a few of our members participated in the WHOIS-IAG during 2016, we are not satisfied that their advice and other contributions have been adequately taken into consideration by the IAG and the ICANN staff in the final draft now under public consultation.

I. The procedure, as eventually revised on the basis of the IAG report, would include still significant shortcomings which ALAC cannot accept in the interest of the privacy of Internet users.:

  1. The Procedure does not create a level playing field among Registrars. On the contrary, Registrars (and some Registries) subject to privacy laws would have to undertake an onerous case-by-case procedure to obtain the right from ICANN to respect their domestic privacy laws. Whereas Registrars operating out of other jurisdictions would be free to ignore privacy laws which pertain elsewhere. (Point 5, below refers.) That outcome is inconsistent with ICANN's responsibility for maintaining the conditions of fair competition among Registries and Registrars.

  2. The Procedure is manifestly inefficient: We have been informed that the pre-existing procedure has hardly ever been used! Which means in practice, that Registrars subject to privacy laws have effectively functioned outside applicable local law and their Registrants' personal data have been potentially exposed to bulk downloads and other abuses, without their authorisation and possibly without their knowledge. Although we see some elements in the revised procedure that in future the procedure would be more regularly used and implemented, however, it is still far too bureaucratic: 

  3. The revised Procedure would still require a “notification of an investigation, litigation, regulatory processing or other governmental or civil action”, or, as an alternative trigger, a written statement from the agency, e.g. the local data protection authority, that Registry or Registrar may violate local law in fulfilling the he RAA. It is an excessive work for many Data Protection Authorities, Registries and Registrars, to establish evident facts. No Registry or Registrar based in Europe can comply with both GDPR and RAA. ALAC cannot support such an anti-social attitude to applicable laws where Registries and Registrars have to be subject to a formal investigation procedure in order to start the procedure.

  4. The international legal environment for privacy protection is rapidly evolving: We understand that – at least in the European Union and associated countries – the General Data Protection Regulation (GDPR) – will shortly introduce a more stringent, uniform and enforceable data protection law throughout that jurisdiction. This would render the proposed ICANN Procedure obsolete and superfluous. 

  5. The Procedure is not inclusive: ICANN's position ignores that several million .com/.net/.org domain etc. names are registered by European individuals or businesses  with a US-based registrar that publishes personal data that are not allowed to be published under the GDPR. Although this is not the place to address the GDPR in detail, we suggest that the proposed Procedure should be put on hold, until the implications of GDPR for ICANN have been thoroughly reviewed.

    Meanwhile – independently of the EU GDPR – ALAC rejects the proposed Procedure for the reasons outlined in Points 1-3, above.

II. An Alternative approach:

ALAC recommends that ICANN adopt an entirely different approach to the proaction of privacy in all DNS related applications, notably WHOIS and its successor implementations.

II.A The preferred policy would be for ICANN to implement globally, international best practice in privacy protection. Currently that would appear to be the EU GDPR, although there may well be enhancements arising from better implementations elsewhere.

It is not unusual for ICANN to implement best practice that goes beyond current applicable local laws:

  • Trademark protection in the DNS clearly goes beyond anything that can be ensured on the basis of national laws alone;
  • we are not aware of any network security policies elsewhere which go beyond SSAC's advice and implementation in ICANN's operations;
  • we expect that the global protection of geographical terms and geographical indications throughout the DNS will in due course in practice extend beyond those provided for by national laws alone.

Accordingly, we have no hesitation to formally request that ICANN implement global best practice in the matter of the protection of personal data.

II.B We note that the WHOIS IAG was offered an alternative 'easier' solution to the issue in the form of a 'block exemption' for EU-based and other Registries and Registrars subject to local privacy laws incompatible with ICANN contracts and procedures. That option was also rejected by the IAG and ICANN staff.

ALAC does not support this option at the present time, on the understanding that:

(a) the 'Best Practices' option II.A will be implemented quickly, and

(b) the proposed Procedure will be withdrawn.

23 Comments

  1. Olivier Crepin-Leblond

    Comment suggestion for a FIRST DRAFT from Christopher Wilkinson:

    DRAFT

     

    ICANN Procedure For Handling WHOIS Conflicts with Privacy Law

     

    Response to the public consultation, scheduled time limit: 12 June 2017.

     

    The At Large Advisory Committee wishes to respond to the public consultation. Although a few of our members participated in the WHOIS-IAG during 2016, we are not satisfied that their advice and other contributions have been adequately taken into consideration by the IAG and the ICANN staff in the final draft now under public consultation.

     

    I.          The procedure, as eventually revised on the basis of the IAG report, would include significant shortcomings which ALAC does not accept:

     

    1. The Procedure does not create a level playing field among Registrars. On the contrary, Registrars (and some Registries) subject to privacy laws would have to undertake an onerous case-by-case procedure to obtain the right from ICANN to respect their domestic privacy laws. Whereas Registrars operating out of other jurisdictions would be free to ignore privacy laws which pertain elsewhere. That outcome is inconsistent with ICANN's responsibility for maintaining the conditions of fair competition among Registries and Registrars.

      2.         The Procedure is manifestly inefficient: We have been informed that the pre-existing procedure has hardly ever been used! Which means in practice, that Registrars subject to privacy laws have effectively functioned outside applicable local law and their Registrants' personal data have been potentially exposed to bulk downloads and other abuses, without their authorisation and possibly without their knowledge.

      We see no elements in the revised procedure to suggest that in future the procedure would be more regularly used and implemented.

      3.         The Procedure still requires that the local agency responsible for compliance shall be empowered to enforce the law (Paragraphs 1a), ii), (f) and (g) of the Procedure). On the contrary there are many regulatory agencies responsible for the implementation of public policy that do not have, in and of themselves, the power of enforcement. ICANN's position presupposes that applicable law can be ignored until it is 'enforced'. ALAC cannot support such an anti-social attitude to applicable laws.

    4.         The International Legal environment for privacy protection is rapidly evolving:
    We understand that – at least in the European Union and associated countries – the General Data Protection Regulation (GDPR) – will shortly introduce a more stringent, uniform and enforceable data protection law throughout that jurisdiction. This would render the proposed ICANN Procedure obsolete and superfaitatoire.

    Although this is not the place to address the GDPR in detail, we suggest that the proposed Procedure should be put on hold, until the implications of GDPR for ICANN have been thoroughly reviewed.


    Meanwhile – independently of the EU GDPR – ALAC rejects the proposed Procedure for the reasons outlined in Points 1-3, above.


    II.        An Alternative approach:

    ALAC recommends that ICANN adopt an entirely different approach to the proaction of privacy in all DNS related applications, notably WHOIS and its successor implementations.

    II.A     The preferred policy would be for ICANN to implement globally, international best practice in privacy protection. Currently that would appear to be the EU GDPR, although there may well be enhancements arising from better implementations elsewhere.

    It is not unusual for ICANN to implement best practice that goes beyond current applicable local laws:

    -           Trademark protection in the DNS clearly goes beyond anything that can be ensured on the basis of national laws alone;

    -           we are not aware of any network security policies elsewhere which go beyond SSAC's advice and implementation in ICANN's operations;

    -           we expect that the global protection of geographical terms and geographical indications throughout the DNS will in due course in practice extend beyond those provided for by national laws alone.

    Accordingly, we have no hesitation to formally request that ICANN implement global best practice in the matter of the protection of personal data.

    II.B      We note that the WHOIS IAG was offered an alternative 'easier' solution to the issue in the form of a 'block exemption' for EU-based and other Registries and Registrars subject to local privacy laws incompatible with ICANN contracts and procedures. That option was also rejected by the IAG and ICANN staff.

    ALAC does not support this option at the present time, on the understanding that:

    (a)       the 'Best Practices' option II.A will be implemented quickly, and

    (b)       the proposed Procedure will be withdrawn.



    ___________________


    1. Alan Greenberg

      Christopher, several comment:

      Your point I is largely identifying why the revised procedures are not acceptable. I’m not sure we need to go into that as the fact that they are generally found to be inacceptable is why this PC exists. I’m not arguing against removing this section, but questioning whether we need this level of detail?

      My understanding that the new RDS which we are laboriously working on will address these issues as you suggest in section II, but I thought the point of this entire consultation was what do we do with the current WHOIS given that we are not ready to implement some new system (far from it!) and we have to deal with the reality of today’s contracts.

      Can you please elaborate on exactly what you see as the “international best practice in privacy protection”?

  2. Christopher Wilkinson

    Dear Alan:

    As you know, I find this Wiki medium very difficult, but here goes:

    > they are generally found to be unacceptable … is why this PC exists

    I am not sure about that. Unacceptable to who? On the contrary, for a year I had to deal with entrenched support for the system from the TM industry, senior ICANN staff, and with the relatively passive acquiescence of the Registries and Registrars.
    The object being apparently to make it as difficult as possible for an EU or Canadian Registrar to conform to local privacy laws.

    BTW, until Olivier raised it I had no idea that this PC existed. I was not alone.

    > the new RDS…

    I have heard about that for years, and reached the personal conclusion some time ago that I shall believe that when I see it. Meanwhile …
    If Registrars start getting fines from EU/GDPR for publishing unprotected personal data, then perhaps we shall see some movement. (The spontaneous invention of the GDPR session in ICANN59 is perhaps a forerunner.)

    > “international best practice in privacy protection”?

    I would happily leave that to legal experts. From what I have heard over the years, Canadian privacy law would be a great improvement.
    There should be an EU/GDPR speaker at the ICANN59 session.

    Regards, Christopher

    PS: Now, my problem with the Wiki medium: who can read this? e.g. Olivier asked me to respond to you. OK. Hecho. But where do I send his copy to Olivier?

  3. Alan Greenberg

    Christopher, the problem with best practices for privacy is that balancing privacy laws with reasonable access to those who need it requires different levels of access to different groups, a capability that the WHOIS protocol cannot support.

    Your post on the Wiki is fine and Olivier automatically has a copy now.



  4. Christopher Wilkinson

    Dear Alan: I agree that is a large part of the problem, but we knew that 20 years ago. C.

  5. Andrey Kolesnikov

    In some national legal environments the (physical) data localization demanded with strict enforcement to the level of state agencies to be responsible for cross border data exchange. For example, Russian registries and registrars must keep information in house and route any formal request to open registrant data from any foreign organization via process demanded by state. The formalization of this regulation might be a solution. Today it works as individual exemption given by ICANN staff to registry/registrar. I believe Russia is not alone on this legal path.

  6. Alan Greenberg

    The entire privacy issue with regard to Whois (and successors) is far more nuanced than this comment. At-Large has a significant issue with relation to abuse which makes use of domain names and we cannot ignore this in any discussion. To focus just on privacy ignores a large part of the issue.

    It is unclear to what extent the RDS PDP will resolve these issues, but my understanding is that this public comment is not to address the long-term issue but to address how to handle registrar concerns with following local law until we can revise the entire system.

    I will find it hard to support such a wide-ranging comment, particularly in that it addresses only the privacy issues.

    1. Olivier Crepin-Leblond

      I think that what the Statement is stating is that with the incoming GDPR (which, by the way will be discussed in a session in Joburg), ICANN has no option for a temporary plaster/fix on a case by case basis. Because a temporary fix is only going to get the pressure cooker to come to a higher pressure, until the whole issue will explode...

      Why is ICANN appearing to be dragging its feet for this?

      When it comes to the Statement only addressing the privacy issues, this is a draft from several EURALO ALSes and I therefore invite all other RALOs to comment and add any other angles that should be added.

  7. Olivier Crepin-Leblond

    I think that the end of the current text is ambiguous. It reads as though we reject all of the proposals, including II.A and II.B:

    ALAC does not support this option at the present time, on the understanding that:

    (a)       the 'Best Practices' option II.A will be implemented quickly, and

    (b)       the proposed Procedure will be withdrawn.


    Let's be quite objective about this. In the Statement, we say that we reject the proposed procedure. We also say that we would ideally like to see the Best Practices Option II.A be undertaken – but let's be clear, do we really think that ICANN would be able to come up with such a silver bullet and implement it "quickly"? So whilst we might ideally like to see II.A implemented, what we can realistically expect at present is for II.B to be considered again.

    It was rejected by the IAG & Staff. Shouldn't we ask that this issue be re-opened, and shouldn't we explicitly say that until another more elaborate long term solution is found, II.B is the ONLY solution that would be immediately workable?

  8. Christopher Wilkinson

    Good evening:

    I have seen the comments from Olivier and Alan. I think we can work around those concerns constructively:

    1.  We are now working on a collective position paper, so apart from editing the first draft, my point of view is of no greater merit to that of our colleagues. Nothing more.
    2. I agree with Olivier that option IIB is a valid fall-back EURALO position for the EU+ R&Rs, but as I said earlier, ALAC should ideally aim for a global solution.
    3. I recognise Alan's concerns, mais il ne faut pas surcharger la barque.
      1. the existence of the procedure pre-supposes that privacy law may be taken into account, somehow. Albeit in this context with extreme difficulty;
      2. But other IAG-WG participants and staff insisted that my proposals were out of scope. i.e. the IAG WG was only allowed to address the 'implementation' of the pre-existing  procedure.
      3. Consequently, the IAG-WG did not address the uses (acceptable or otherwise) of published WHOIS. That would have been a fortiori even further out of scope! Should ALAC wish to address the entire privacy issue, this is not the place to try to do so.

        Next time, perhaps

        CW

  9. Christopher Wilkinson

    Good afternoon: Where does this consultation stand now? Are there any other drafting proposals forthcoming?

    Have any other RALOS responded to the consultation? I note that ALAC will be asked to vote on the text on 29 June.

    I suggest that it would be timely to close this phase of the discussion soon with a view to the more general discussion of EU/GDPR in ICANN59, 27th June.

    Regards, CW

  10. Bastiaan Goslings

    Before I comment on the content, I want to be sure I understand the difference between the 'triggers' and the 'waiver' procedure.

    The RAA Data Retention Waiver process deals with 'collecting or retaining one or more data elements in the manner required by the specification' that 'violates applicable law', right? While this 'Revised ICANN Procedure for Handling WHOIS Conflicts with Privacy Law' is about the publically displaying of collected data? Or is the Waiver process part of this procedure?

  11. Christopher Wilkinson

    Bastiaan: I think that the distinctions derive from the language of the IAG Report.

    The 'waiver' refers to the decision by ICANN to remove ('waive') the publication requirements, after the full procedure has been completed.

    The 'trigger' is the documentation required to initiate the procedure which would in principle give rise to the requested 'waiver'.

    The 'alternative trigger' was the IAG proposal for a somewhat simplified requirements to initiate the procedure.

    Comment: Insofar as the IAG was told that to date the procedure had hardly ever been used (¿zero?), there was no data as to what the effect of the trigger is on obtaining the waiver.

    Hope this is clear enough.


    CW




  12. Christopher Wilkinson

    Rainer Rodevald:    I wonder if there is any example of a database where

    purchased goods and there respective owners are public

    available worldwide?

  13. Christopher Wilkinson

    for 'there' read 'their'


    cw



    1. Olivier Crepin-Leblond

      Not to my knowledge.

  14. Olivier Crepin-Leblond

    A lot of email traffic has also happened. I will now post some of the emails that were shared amongst participants in the discussion;

    Valentina Pavel (APTI):

    In response to the “Revised ICANN Procedure for Handling WHOIS Conflicts with Privacy Law; Process and Next Steps” (see https://community.icann.org/x/MgjfAw), the Association for Technology and Internet (www.apti.ro) would like to submit the following comments to be taken into consideration for drafting the At-Large Advisory Committee (ALAC) position.
     
    First a few general remarks. We would like to underline that the criteria for accessing WHOIS data should be very clear and transparent in terms of who has access to the data and under which conditions. Also, we strongly recommend that the WHOIS data should not be public by default. The user should have the possibility to make such data public, but it should be an individual decision. At the same time, we firmly believe that data anonymization systems such as privacy/proxy services should be actively encouraged. For our previously submitted comments on WHOIS please see: http://www.apti.ro/sites/default/files/WHOISprivacy-ICANNpubliccomment7JULY2015_0.pdf
     
    On the specific question of “alternative trigger”, we are against implementing such a measure. In some countries obtaining a written statement from competent authorities (predominantly data protection authorities) might not be possible. Data protection authorities might not be willing to reply to such a request, unless a formal investigation is undergoing. Therefore, in these cases, registries or registrars might only be able to obtain such a document, unless they are already liable for sanction for not respecting national laws. Therefore, the only real option to obtain a waiver would still be to go for the currently existing trigger - notification of an action that the registry’s or registrar’s compliance with WHOIS obligations are prevented by local laws. Evidently, this does not resolve or add to the current policy status.
     
    Our recommendation is to require registries or registrars to seek for valid independent and external certification systems charged with acknowledging its national data protection obligations, indicating that the particular WHOIS fulfils the national/regional data protection law. This statement should be then submitted to ICANN. In our view such a system would be much more useful as it demonstrates that registries and registrars are compliant with data protection laws (including the soon to be enforced EU GDPR - General Data Protection Regulation). This option has the advantage that it could be performed without the involvement of a data protection authority, which, as stated above, might refuse or reply that it is not in its mandate to issue declarations regarding the registries’ or registrars’ compliance as it is not a certification body.
     
    In conclusion, we believe the current “alternative trigger” does not represent a viable and efficient mechanism. The requirement of a valid certification system should be recommended as a viable option since it creates real effects both for safeguarding privacy rights, but also for assuring legal stability to registries and registrars.


    Best,


    Valentina Pavel
    Association for Technology and Internet - ApTI
    privacy.apti.ro & apti.ro


  15. Olivier Crepin-Leblond

    Werner Hülsmann (DVD) - Datenschutzverein


     
    If I would have a contract with somebody else and there is a clause in
this contract, which is in conflict with the law, then this clause is
void. So, if there are clauses in the WHOIS-regulation, which are in
conflict to any law, then this clauses in the contracts are void. 

So for me would be the question: How can ICANN come to a
WHOIS-regulation which is compatible to the GDPR. Here ICANN should
cooperate with the Article 29 Working Partyto come to a solution.

Kind Regards,

Werner






  16. Christopher Wilkinson

    Thank you Olivier. You are seeing e-mail traffic which does not reach me. Which List does it come from?

    1.    Werner Hülsmann:    I accept the logic of your position, but experience is that European gTLD Registrars would rather risk illegality than risk loosing their RRA contract with ICANN.

    2.    Valentina Pavel: In short, you agree entirely with the draft ALAC comment. Thankyou. To the best of my knowledge, gTLD Registrant WHOIS data IS publicly available. There is no record of who accesses this data and for what purpose. (I asked precisely that question during the ICANN59 GDPR session, and have not yet received a reply.)

    May I suggest that APTI post an independent comment on your own account in support of the ALAC position, including your text, below.

    Regards to you all

    Christopher Wilkinson

    1. Olivier Crepin-Leblond

      Dear Christopher,


      as I solicited individual ALSes for comments, they responded to me, CC'ing Yrjö, Wolf and Staff, thus not a mailing list. I did ask staff to transcribe responses to the WIKI but noticed that this was not done hence I did it now, although a little late. Sorry.

  17. Bastiaan Goslings

    For what it's worth, timing wise - I support the final version of this draft statement. For the record, with regard to comments made by Valentina (APTI) and Werner:

    • Valentina: I completely agree with your 'general remarks'. When it comes to the 'recommendation' though, I'd expect 'independent and external certification systems' to bring significant costs for registrars/registries. IMO undeservedly as ICANN is the one trying to contractually enforce something that is non-compliant with applicable local data protection legislation.
    • Werner: I understand what you are saying, and I agree, - the thing is that ICANN contracts already require the WHOIS to publicly reflect personal data, which is not allowed by datatprotection regimes like the one we have in the Netherlands. And as the draft statement explicitly says, 'this is not the place to address the GDPR in detail', and 'independently of the EU GDPR' etc


  18. Bastiaan Goslings

    Forgot to add:

    I especially endorse the comment 'The preferred policy would be for ICANN to implement globally, international best practice in privacy protection. Currently that would appear to be the EU GDPR, although there may well be enhancements arising from better implementations elsewhere.'

    This is also the position of the Council of Europe as far as I understand, i.e. that there should be one one global policy in this area reflected in the ICANN-contracts for registrars and registries.


  19. Holly Raiche

    I am going to abstain.  I was on the WG that came up with this proposal.  It is decidedly second best, but until ICANN can come up with something better, it offers a temporary, and admittedly inefficient way, for affected Registrars not to be breaking the law.  The ad hoc team that ICANN has just established to deal with this issue before the GDPR comes into effect should come up with something better.  But right now, EU registrars are already in breach and wanted a way through.  Naturally, there should be a better, gobal policy - but there isn't. Not now. And this is about now.  Yes, one way through is to recognised that clause in the ICANN contract to the effect that law takes precedence.  And part of me  would like to run with that.  But this is one way through now - until someone can do better.