ISSUE:    B.1

Obligations of privacy/proxy services made available in connection with registration re data escrow; Relay function; Reveal function

 

Priority:
 

RAA Final Report (High Priority Item)


Issue/Request

In the event ICANN establishes an accreditation program for proxy or privacy registration services, Registrar will accept proxy/privacy domain name registrations ONLY from ICANN accredited Proxy Registration Services. Registrar shall cooperate with ICANN to establish an ICANN accreditation program for proxy or privacy registrations.

Source: 
LEA Code of Conduct

Notes

Additional information regarding requests:  
LEA:
1) Registrants using privacy/proxy registration services will have authentic WHOIS information immediately published by the Registrar when registrant is found to be violating terms of service, including but not limited to the use of false data, fraudulent use, spamming and/or criminal activity.
2) Require registrars to collect and preserve contact data for beneficial registrant/licensee even when registration is channeled through proxy or privacy service made available in connection with the registration process.

RAA-DT:
1) Insert provisions in the RAA that require a registrar and its resellers to escrow privacy or proxy registration data, and at a minimum, disclose the points of contact for privacy or proxy service providers and a description of the privacy or proxy services offered to their customers.
2) Develop and implement the program in RAA Section 3.12.4 of the RAA giving ICANN the ability to establish or “make available a program granting recognition to resellers that escrow privacy or proxy registration data”.  Create a similar contractual provision in RAA Section 3.4.1 for registrars.
3) Explicit requirement for all proxy and private registration services to escrow contact data on beneficial registrant/licensee.
4) Conspicuous Notice
• “display a conspicuous notice to such customers at the time an election is made to utilize such privacy or proxy service that their data is not being escrowed.”  -- eliminate this clause
5) Insert in RAA Section 3.7.7.3 provisions that require privacy or proxy services to forward allegations of malicious conduct, cybersquatting, and other illegal activities to privacy or proxy service customers.
6) Develop contract language and/or advisories that clarify the language of RAA Section 3.7.7.3, including the definition of “reasonable evidence of actionable harm” with input from registrars and non-contracted parties.
7) The GNSO could discuss what forms of illegal malicious conduct and what standard of evidence should result in a requirement to reveal the contact information of customers of privacy or proxy services, consistent with procedures designed to respect any applicable protections for privacy and freedom of expression.
8) Specify circumstances under which proxy registration services are required to disclose actual contact data of beneficial registrants/licensees, and apply the same standards to private registration services.
9) Amend the language in RAA Section 3.7.7.3 as follows:  “A Registered Name Holder licensing use of a Registered Name accepts liability for harm caused by wrongful use of the Registered Name, unless it promptly (i.e. within five business days) discloses the current contact information provided by the licensee and the identity of the licensee to a party providing the Registered Name Holder reasonable evidence of actionable harm.”



Original LEA submission to the RAA-DT







 RAA-DT Final Report


Discussion Points

Description

Date Discussed

 

Registrars willing to comply with any commercially reasonable ICANN privacy/proxy service accreditation requirements.

Further discussion regarding “publication,” “authentication,” and  “reasonable evidence of actionable harm” standard.

Discussion of Registrar proposal.  

ICANN proposal to create an accreditation program for privacy and proxy providers.

Discussion of proposal for an accreditation program for privacy/proxy providers.

Discussion of immediate requirement for escrow, rather than implementing when accreditation program is established.

Discussion of  whether the  “reveal” request triggered when the privacy/proxy service’s terms of service are violated means that the underlying information is published in the WHOIS record or whether it is revealed to the requester.

Discussion on logistics of getting the proxy/privacy services to escrow data;   Query whether it would be part of registrars escrow with ICANN or through a separate escrow.

 Discussion of why privacy/proxy accreditation escrow is needed now vs. when the accreditation program is created.

18 Nov 2011


18 Nov 2011


8 Dec 2011

20 Dec 2011

17 Jan 2012

27 Jan 2012


27 Jan 2012



15 Feb 2012


15 Feb 2012

Proposed Text

Open


Status/Outcome

Under Discussion


Explanation

Open


COMMENTS:

Comments may be submitted using the “Add Comment” feature below.






To Leave a Comment on This Page:  Any user logged into Confluence will see an "Add Comment" button at the bottom of this page, which can be used to leave a comment.  To log in, click the "Log In" button on the gray control bar toward the top of the page, and enter your user name and password.  If you do not have a user name and password, please e-mail seth.greene@icann.org with "Log In" in the subject line. 

  • No labels

1 Comment

  1. Please share the "draft implementation text."  I still fail to understand how ICANN can contractually make a Registrar liable to a third party who claims "harm," actionable or otherwise, from the actions of a Registrant.  What's the point of including ineffectual language in a contract?

    --Wendy