[Gnso-ppsai-pdp-wg] FW: Privacy and Protection Service Accreditation Issues Working Group

Kathy Kleiman kathy at kathykleiman.com
Tue Jan 14 14:15:00 UTC 2014


Hi Jim and All,
We like and appreciate the word "alleged" before unproven allegations - 
thank you. The reordering is good.  A few additional updates:
- The title of "maintenance" means different things to technical groups 
and lawyer groups. Basic registration issues are not generally
maintenance" issues, so they are now broken out further.

-  Whether "commercial entities" should be barred from proxy/privacy 
remains a misleading question. As we have discussed, all larger 
noncommercial organizations are "incorporated as a way to obtain 
insurance and other liability protections (or even as a threshold 
requirement to become a 501(c)(3) tax-deductible charity in the US).  
You should not have to be a lawyer to understand this subtlety or to 
understand the implications of this question - so it is broken out below.

- Similarly, the issue of publication should be flagged - the 
publication of the contact data in the open Whois , and not just 
available to the requestor, is one to make clear./

//Updates below in italics.

/With the good work of the WG, we recommend these changes be percolated 
across all the documents we are working on and releasing - to SGs, ACs, 
SOs, etc.

Best,
Kathy
:
>
> Dear All,
>
> Although the question groupings are still being completed, it may be 
> helpful to our audience if we grouped the questions in the letters in 
> some logical, categorical manner, even if that grouping is but a draft.
>
> To address the substantive content of the questions, it seems that the 
> ultimate issue is set forth in the first question: "What, if any, are 
> the types of Standard Services Practices that should be adopted and 
> published by ICANN-accredited privacy/proxy service providers?" The 
> questions following it address that main issue.  Most of the issues 
> and questions could be subsumed under the following general categories:
>
>  · *MAINTENANCE* of privacy/proxy services;
>
>  · *CONTACT* point provided by each privacy/proxy service;
>
>  · *RELAY* of complaints to the privacy/proxy customer; and
>
>  · *REVEAL* of privacy/proxy customers' identities.
>
> If we followed this categorization, the issues and questions would be 
> grouped as follows:
>
> *_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? Should there be any  forms of 
> non-compliance that would trigger cancellation or suspension of 
> registrations?  If so, which?
>
> 4.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?
>
> 5.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 bound 
> to the same standards as accredited service providers?
>
> *_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.
>
_/*Basic Registration Issues*/_
>
> 4.Should ICANN-accredited privacy/proxy service providers distinguish 
> between domain names registered or used for commercial with those 
> registered or used for personal purposes? Specifically, is the use of 
> privacy/proxy services appropriate when a domain name is registered or 
> used 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?
>
/ 7. Should privacy/proxy services be available for noncommercial 
organizations (note: many noncommercial organization are incorporated as 
"companies" for insurance, liability and "charity" classification 
purposes)?/
>
> *_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 forms of malicious conduct, if any, should be covered by a 
> designated published point of contact at an ICANN-accredited 
> privacy/proxy service provider?
>
> *_RELAY _*
>
> 1.What, if any, baseline minimum standardized relay processes 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?
>
> *_REVEAL _*
>
> 1.What, if any, baseline minimum standardized reveal processes  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 /by private parties/?
>
/2a. Should the Registrant be notified of the "reveal" of it/his/her 
contact data to a private party?/
>
> 3. What forms of alleged malicious conduct, if any, and what 
> evidentiary standard would be sufficient to trigger such disclosure? 
> What specific violations, if any, would be sufficient to trigger such 
> disclosure/**by private parties/?
>
> 4. What safeguards, if any, should be put in place to ensure adequate 
> protections for privacy and freedom of expression? /For prevention of 
> stalking and harassment? For Protection against anti-competitive acts 
> among competitors? /Should these standards vary depending on whether 
> the website is being used for commercial or non-commercial purposes?
>
/4a? Publication: When should the contact information of a Registrant be 
not only published, but revealed in the 24*7 Whois database?//  Must the 
Registrant be notified by publication? Should the registrant have the 
option to give up the domain name rather than having the contact data 
published? /What safeguards or remedies should be available in cases 
where publication is found to have been unwarranted?
>
> 5. What circumstances, if any, would warrant access to registrant data 
> by law enforcement agencies?
>
> 6. 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)?
>
> Please let me know if this categorization is helpful.
>
> Jim
>
> James L. Bikoff
>
> Silverberg, Goldman & Bikoff, LLP
>
> 1101 30th Street, NW
>
> Suite 120
>
> Washington, DC 20007
>
> Tel: 202-944-3303
>
> Fax: 202-944-3306
>
> jbikoff at sgbdc.com <mailto:jbikoff at sgbdc.com>
>
>
>
> _______________________________________________
> Gnso-ppsai-pdp-wg mailing list
> Gnso-ppsai-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140114/bea0d8ef/attachment-0001.html>


More information about the Gnso-ppsai-pdp-wg mailing list