Page History

Dear SO/AC Chair,

As you may be aware, the GNSO Council recently initiated a Policy Development Process (PDP) on Privacy & Proxy Services Accreditation Issues. As part of its efforts to obtain input from the broader ICANN Community at an early stage of its deliberations, the Working Group that has begun to explore questions related to these issues is looking for any input or information that may help inform our deliberations.

Below you will find an overview of the issues that the WG has been assigned to address in its charter. We would appreciate it very much if you would examine the items and provide any input that your group may have to the GNSO Secretariat (gnso.secretariat@gnso.icann.org). If you cannot submit your input, but your group would like to contribute, please let us know when we can expect to receive your contribution so that we can plan accordingly. While we would like your thoughts on all items, responses to a subset still will be helpful. Please feel free also to suggest modifications to or additional questions that your group believes useful for the WG to address.

Your input will be valuable for informing the WG as we begin our work. We have included a list of relevant definitions at the end of this document in the hope that they will be of assistance to your group in providing input. For further background information on our WG’s activities to date and to follow our work as we move forward, see https://community.icann.org/x/9iCfAg.

With best regards,

Don Blumenthal, Chair of the Privacy & Proxy Services Accreditation Issues PDP Working Group

QUESTIONS FOR WHICH THE WG WAS CHARTERED AND IS SEEKING INPUT

This RAA PDP Working Group (WG) was created to provide the GNSO Council with policy recommendations regarding the issues identifiedduring the 2013 RAA negotiations, including recommendations made by law enforcement and GNSO workinggroups, that were not addressed during the 2013 RAA negotiations but are otherwise suited for a PDP. These issues focus onthe accreditation of Privacy & Proxy Services.

As part of its deliberations on the matter, the RAA PDP WG was asked to, at a minimum, consider those issues detailed in theStaff Briefing Paper published on 16 September 2013 and included in the WG Charter (seehttps://community.icann.org/display/gnsopnpsrvaccrdtwg/WG+Charter). The WG has organized the questions in the hope that it adds clarity.

I. MAIN ISSUES

1. What, if any, are the types of Standard Service Practices that should be adopted and published by ICANN-accredited privacy/proxy service providers? 
2. Should ICANN distinguish between privacy and proxy services for the purpose of the accreditation process?  
3. What are the contractual obligations, if any, that if unfulfilled would justify termination of customer access by ICANN-accredited privacy/proxy service providers? 
4. What types of services should be covered, and would be the forms of non-compliance that would trigger cancellation or suspension of registrations? 
5. What are the effects of the privacy and proxy service specification contained in the 2013 RAA? Have these new requirements improved WHOIS quality, registrant contactability and service usability?
6. What should be the contractual obligations of ICANN accredited registrars with regard to accredited privacy/proxy service providers? Should registrars be permitted to knowingly accept registrations where the registrant is using unaccredited service providers that are however bound to the same standards as accredited service providers?  

II. MAINTENANCE  

1. Should ICANN-accredited privacy/proxy service providers be required to label WHOIS entries to clearly show when a registration is made through a privacy/proxy service?
2. Should ICANN-accredited privacy/proxy service providers be required to conduct periodic checks to ensure accuracy of customer contact information; and if so, how?
3. What rights and responsibilities should customers of privacy/proxy services have? What obligations should ICANN-accredited privacy/proxy service providers have in managing these rights and responsibilities? Clarify how transfers, renewals, and PEDNR policies should apply.
4. Should ICANN-accredited privacy/proxy service providers distinguish between domain names used for commercial vs. personal purposes? Specifically, is the use of privacy/proxy services appropriate when a domain name is registered for commercial purposes?
5. Should there be a difference in the data fields to be displayed if the domain name is registered or used for a commercial purpose, or by a commercial entity instead of a natural person? 
6. Should the use of privacy/proxy services be restricted only to registrants who are private individuals using the domain name for non-commercial purposes?

III. CONTACT  

1. What measures should be taken to ensure contactability and responsiveness of the providers? 
2. Should ICANN-accredited privacy/proxy service providers be required to maintain dedicated points of contact for reporting abuse? If so, should the terms be consistent with the requirements applicable to registrars under Section 3.18 of the RAA?
3. Should full WHOIS contact details for ICANN-accredited privacy/proxy service providers be required?
4. What are the forms of alleged malicious conduct, if any, that would be covered by a designated published point of contact at an ICANN-accredited privacy/proxy service provider?

IV. RELAY  

1. What, if any, are the baseline minimum standardized relay processes that should be adopted by ICANN-accredited privacy/proxy service providers?
2. Should ICANN-accredited privacy/proxy service providers be required to forward to the customer all allegations of illegal activities they receive relating to specific domain names of the customer? 

V. REVEAL

1. What, if any, are the baseline minimum standardized reveal processes that should be adopted by ICANN-accredited privacy/proxy service providers?
2. Should ICANN-accredited privacy/proxy service providers be required to reveal customer identities for the specific purpose of ensuring timely service of cease and desist letters? 
3. What forms of alleged malicious conduct, if any, and what evidentiary standard would be sufficient to trigger such disclosure? What specific alleged violations, if any, would be sufficient to trigger such publication?
4. What safeguards must be put in place to ensure adequate protections for privacy and freedom of expression?
5. What safeguards or remedies should be available in cases where publication is found to have been unwarranted?
6. What circumstances, if any, would warrant access to registrant data by law enforcement agencies?
7. What clear, workable, enforceable and standardized processes should be adopted by ICANN-accredited privacy/proxy services in order to regulate such access (if such access is warranted)? 

LIST OF RELEVANT DEFINITIONS

(1)   Privacy & Proxy Services

The following definitions are those used by the GNSO in the various WHOIS studies it commissioned between 2010-2012 (http://gnso.icann.org/issues/whois/whois-working-definitions-study-terms-18feb09.pdf):

• Privacy services hide customer details from going into WHOIS. Privacy service providers, which may include registrars and resellers, may offer alternate contact information and mail forwarding services while not actually shielding the domain name registrant’s identity. By shielding the user in these ways, these services are promoted as a means of protecting personal privacy, free speech and human rights and avoiding personal data misuse.
• Proxy services protect users’ privacy by having a third-party register the name. The third-party is most often the proxy service itself. The third-party allows the user to access and use the domain name through a separate agreement or some other arrangement directly with the user. Proxy service providers may include web design, law, and marketing firms; web hosts, registrar subsidiaries, resellers and individuals.

NOTE: The 2013 Registrar Accreditation Agreement contains a temporary specification relating to Privacy & Proxy Services, which refers to these services as follows (http://www.icann.org/en/resources/registrars/raa/approved-with-specs-27jun13-en.pdf):

1.1 "P/P Customer" means, regardless of the terminology used by the P/P Provider, the licensee, customer, beneficial user, beneficiary, or other recipient of Privacy Services and Proxy Services.

1.2 "Privacy Service" is a service by which a Registered Name is registered to its beneficial user as the Registered Name Holder, but for which alternative, reliable contact information is provided by the P/P Provider for display of the Registered Name Holder's contact information in the Registration Data Service (Whois) or equivalent services.

 1.3 "Proxy Service" is a service through which a Registered Name Holder licenses use of a Registered Name to the P/P Customer in order to provide the P/P Customer use of the domain name, and the Registered Name Holder's contact information is displayed in the Registration Data Service (Whois) or equivalent services rather than the P/P Customer's contact information.

 1.4 "P/P Provider" or "Service Provider" is the provider of Privacy/Proxy Services, including Registrar and its Affiliates, as applicable. 

(2)   Relay & Reveal Requests

The following descriptions are taken from the GNSO’s Terms of Reference for a proposed Proxy & Privacy Relay & Reveal Study in 2010 (http://gnso.icann.org/issues/whois/whois-proxy-privacy-relay-reveal-studies-tor-29sep10-en.pdf):

• For many domains, Registered Name Holders can be reached directly at addresses obtained from WHOIS. However, for Privacy/Proxy-registered domains, Registered Name Holders or third party licensees cannot be reached directly via WHOIS- published addresses. Instead, communication relay requests may be sent to the Privacy/Proxy service provider published in WHOIS, or attempted using addresses obtained from other sources, websites or communications associated with the domain.

For many domains (including those registered via Privacy services), the Registered Name Holder's identity is published directly in WHOIS. However, for domains registered via Proxy services, the name of the licensee is not published in WHOIS; third party licensees can typically only be identified by asking the Proxy to reveal the licensee's identity, given reasonable evidence of actionable harm

In addition to background information, an overview of the WG's deliberations and community input received to date, the Initial Report [LINK] contains the following preliminary recommendations:

Proposed Recommendation to Charter Question A

Recommendation #1: The WG recommends that reporting requirements be incorporated into the TDRP policy. Outcomes of all rulings by Dispute Resolution Providers1 should be published on Providers' website, except in exceptional cases. The Group recommends publishing reports that follow the example of the Asian Domain Name Dispute Resolution Centre (ADNDRC).2 These reports should include at a minimum: a) Information about parties involved in the dispute; b) The full decision of the case; c) The date of the implementation of the decision

Recommendation #2: The WG recommends that the TDRP be amended to include language along the lines of this revised version of the UDRP: 'The relevant Dispute Resolution Provider shall report any decision made with respect to a transfer dispute initiated under the TDRP. All decisions under this Policy will be published in full over the Internet, except when a Dispute Resolution Panel determines, in an exceptional case, to redact portions of its decision. In any event, the portion of any decision determining a complaint to have been brought in bad faith shall be published.'

Proposed Recommendation to Charter Question B

Recommendation #3: The WG recommends that the TDRP be amended as follows: "Transfers from a Gaining Registrar to a third registrar, and all other subsequent transfers, are null and void if the Gaining Registrar acquired sponsorship from the Registrar of Record through an invalid transfer,** as determined through the dispute resolution process set forth in the Transfer Dispute Resolution Policy."*

Recommendation #4: The WG recommends that a domain name be returned to the original Registrar of Record if it is found through a TDRP procedure that a non-IRTP compliant domain name transfer has occurred. TheTDRP as well as guidelines to registrars, registries and third party dispute providers should be modified accordingly.

Recommendation #5: The WG recommends that the statute of limitation to launch a TDRP be extended from current 6 months to 12 months from the initial transfer. This is to provide registrants the opportunity to become aware of fraudulent transfers when they would no longer receive their registrar's annual WDRP notification.

Recommendation #6: The WG recommends that if a request for enforcement is initiated under the TDRP the relevant domain should be 'locked' against further transfers. The TDRP as well as guidelines to registrars, registries and third party dispute providers should be modified accordingly.

*NB: The Working Group would like to encourage Public Comment on the question of whether costs would need to be refunded to registrars in case of negating/reversing transfers under a multiple-hop scenario.

** NB: The Working Group would like to encourage Public Comment on whether in this context there is a need to clearly define 'invalid transfer'; and if so, how.

Proposed Recommendation to Charter Question C

The WG does not recommend that dispute options for registrants be developed and implemented as part of the current TDRP.

Recommendation #7: The WG recommends that the GNSO ensure that IRTP-C inter-registrant transfer recommendations are implemented and include appropriate dispute-resolution mechanisms. The IRTP-C and IRTP-D Implementation Review Teams should determine whether the inter-registrant transfer use cases documented in Appendix [?] have been addressed. If there are use cases that have not been addressed by the implementation of IRTP-C-2, the Implementation Review Teams are charged with formulating a request for an Issue Report to review the remaining use cases and consider whether any additional dispute resolution mechanisms (or changes to the TDRP) should be developed. That request should then be forwarded to theGNSO Council for consideration.

Recommendation #8: The WG recommends that the TDRP be modified to eliminate the First Level (Registry) layer of the TDRP.***  

Observation: The WG observes that the information on the ICANN website describing registrant options with regard to inter-registrar and inter-registrant transfers is not as clearly formulated and prominently displayed as it should be. The recommendations for Charter question D below address this issue in detail.

***NB: The Working Group would like to encourage Public Comment on the issue of whether to remove the registry layer from the TDRP.

Proposed Recommendation to Charter Question D

Recommendation #9: The WG recommends that ICANN create and maintains a one-stop website containing all relevant information concerning disputed transfers and potential remedies to registrants. This should include: a) Improvements to the ICANN website regarding the display of information on the Inter Registrar Transfer Policy and the Transfer Dispute Resolution Policy is regularly updated; b) Links to the relevant information for registrants on the ICANN website being clearly worded and prominently displayed on the ICANN home page. This will contribute to improving visibility and content of the ICANN website that is devoted to offering guidance to registrants with transfer issues; c) ICANN Compliance clearly indicates on its FAQ/help section under which circumstances it can assist registrants with transfer disputes. This should include situations when registrants can ask ICANN Compliance to insist on registrars taking action on behalf of said registrant; d) Improvements in terms of accessibility and user-friendliness should be devoted especially to these pages:

http://www.icann.org/en/help/dispute-resolution#transfer

http://www.icann.org/en/resources/registrars/transfers/name-holder-faqs

http://www.icann.org/en/resources/registrars/transfers/text

Links to these registrant help-website should also be prominently displayed on internic.net and iana.org in order to assure further that registrants have easy access to information

Recommendation #10: The WG recommends that, as best practice, ICANN accredited Registrars prominently display a link on their website to this ICANN registrant help site. Registrars may chose to add this link to those sections of their website that already contains Registrant-relevant information such as the Registrant Rights and Responsibilities, the WHOIS information and/or other relevant ICANN-required links as noted under 3.16 of the 2013 RAA.

Proposed Recommendation to Charter Question E

Recommendation #11: The WG recommends that no additional penalty provisions be added to the existing policy. The WG concludes that the penalty structures introduced in the 2009 RAA and the 2013 RA are sufficiently nuanced to deal with IRTP violations.

Recommendation #12: The WG recommends that, as a matter of principle, GNSO Consensus Policy should avoid policy-specific sanctions. Rather, it is desirable that the overarching RAA and RA penalty structures be drafted in a way that assures uniformity and consistency of policy violation penalties .

Proposed Recommendation to Charter Question F

The WG does not recommend the elimination of FOAs.

1 The Working Group recommends in Charter question C to remove the Registry as the first dispute resolution layer of the TDRP. Therefore, despite wording of Charter question A, no reporting requirements for the Registries are included here.

2 See four ADNDRC Reports on TDRP decisions: http://www.adndrc.org/mten/TDRP_Decisions.php?st=6

.