[Gnso-ppsai-pdp-wg] Proposal contactability

Tue Aug 19 21:05:25 UTC 2014

As an alternative possibility so we don’t have issues with the general topic of reveal during our discussions, publish/disclose?

From: Mary Wong <mary.wong at icann.org<mailto:mary.wong at icann.org>>
Date: Tuesday, August 19, 2014 at 4:29 PM
To: PPSAI <gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>>
Subject: Re: [Gnso-ppsai-pdp-wg] Proposal contactability

Hello Griffin and everyone,

The terms used to describe “Reveal” in prior GNSO work on Whois and referred to in the document Griffin mentions were as follows:

THE GNSO’S TERMS OF REFERENCE FOR PROPOSED PRIVACY/PROXY RELAY/REVEAL STUDY (SEPTEMBER 2010: http://gnso.icann.org/issues/whois/whois-proxy-privacy-relay-reveal-studies-tor-29sep10-en.pdf)

  *   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

THE RELAY & REVEAL PRE-FEASIBILITY SURVEY REPORT (INTERISLE CONSULTING; AUGUST 2012:http://gnso.icann.org/en/issues/whois/whois-pp-survey-final-report-22aug12-en.pdf)

  *   For Reveal Handling - 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 be identified only by asking the Proxy to reveal the licensee’s identity.

Note that these are not “definitions” as the word is commonly understood. The Whois Review Team referred to the GNSO’s Whois studies in its Final Report but did not define it further.

As Griffin also highlights, this WG did discuss the terminology surrounding “Reveal” in its early discussions about grouping the Charter questions.  Having reviewed the transcripts for some of those meetings, I can confirm that the WG discussed the distinction between the “publication” of contact details/identity in Whois and the “disclosure” of those contact details/identity to another person. In relation to the proposed Publication category for the final grouping of Charter questions, some WG member were of the opinion that instead of creating a separate category that risked the WG further expanding its scope of work, the topic could generally be covered by discussions related to Reveal, including the consequences of terminating a proxy customer’s service

As such, this WG might wish to develop working definitions for certain terms associated with the various acts that have hitherto been generally described as a Reveal – for instance, “publication” could mean the disclosure of a person’s (I.e. the licensee or beneficial owner) identity/contact details in the Whois system, whereas “reveal” could mean the disclosure of that person’s identity/contact details to a third party requestor.

I hope this is helpful.

Cheers
Mary

Mary Wong
Senior Policy Director
Internet Corporation for Assigned Names & Numbers (ICANN)
Telephone: +1 603 574 4892
Email: mary.wong at icann.org<mailto:mary.wong at icann.org>

From: "GBarnett at sgbdc.com<mailto:GBarnett at sgbdc.com>" <GBarnett at sgbdc.com<mailto:GBarnett at sgbdc.com>>
Date: Tuesday, August 19, 2014 at 11:30 AM
To: Don Blumenthal <dblumenthal at pir.org<mailto:dblumenthal at pir.org>>, Mary Wong <mary.wong at icann.org<mailto:mary.wong at icann.org>>, "gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>" <gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>>
Subject: RE: [Gnso-ppsai-pdp-wg] Proposal contactability

All,

Regarding our discussion toward the end of today's call concerning differentiating between a limited disclosure or reveal of registrant identity to a particular third party versus revealing or publishing the registrant identity in the Whois: I was looking back at some early drafts of our Work Plan, and we had proposed making "Reveal" and "Publication" distinct and separate categories (in our draft, they would have been Category F, Reveal, and Category G, Publication; see the attached draft from back in January).

For whatever reason, this proposal was not adopted into our final Work Plan, which only contains the single "Reveal" category (Category F) (re-attaching the final version here for ease of reference).  The footnote in the Work Plan (Footnote 8) points to the definition of "Reveal" as it is defined in the "GNSO’s Terms of Reference for Whois studies," which I am having trouble locating.  Can someone locate this particular definition and share with the group? It may help us establish the terms we will use moving forward to refer to the disclosure of registrant identity to a particular third party (which in my mind is a "Reveal") versus the placement of the registrant identity/contact info in the Whois, thereby replacing the Privacy/Proxy information (which in my mind is a "Publication").  I agree that distinguishing between these types of actions is critical.

Hope this is helpful.

Thanks,

Griffin

Griffin M. Barnett
Silverberg, Goldman & Bikoff, LLP
1101 30th Street NW
Suite 120
Washington, DC 20007
(202) 944-3307
gbarnett at sgbdc.com
________________________________
From:gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounces at icann.org> [gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounces at icann.org>] on behalf of Don Blumenthal [dblumenthal at pir.org<mailto:dblumenthal at pir.org>]
Sent: Monday, August 18, 2014 12:28 PM
To: Mary Wong; gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>
Subject: Re: [Gnso-ppsai-pdp-wg] Proposal contactability

Thanks, Mary.

These documents are for reference for now. We will start the call around on the thread related to Volker’s proposal since it covers so many of the issues. The initial focus will be on email relay questions.

Thanks to Volker for raising a concrete framework for discussion and to those who carried the conversation forward since last Tuesday. Email discussion and mid-week drafting are critical if we plan to stay close to our schedule.

Talk to you tomorrow.

Don

From: Mary Wong <mary.wong at icann.org<mailto:mary.wong at icann.org>>
Date: Monday, August 18, 2014 at 12:10 PM
To: PPSAI <gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>>
Subject: Re: [Gnso-ppsai-pdp-wg] Proposal contactability

Dear all,

To aid in further discussions on the points several WG members have raised in response to Volker’s proposal, the WG Chairs have requested that staff circulate an updated Category E summary document, containing the fundamental questions currently being discussed on this list and the WG calls on Relay/Reveal. Essentially the attached is an update of the summary document previously circulated on E-1. Attached also are the most recent E-1 and E-2 templates.

In light of the ongoing list discussion, the proposed agenda for the meeting on Tuesday 19 August is therefore:

  1.  Roll Call/Updates to SOIs
  2.  Finalize discussions on Category E
  3.  Next steps

We will have all the attached documents and Volker’s proposal on hand in the Adobe Connect room for the meeting.

Please continue to circulate your suggestions, questions and comments on any of these to the list prior to the call!

Cheers
Mary

From: <Williams>, Todd <Todd.Williams at turner.com<mailto:Todd.Williams at turner.com>>
Date: Monday, August 18, 2014 at 11:19 AM
To: "James M. Bladel" <jbladel at godaddy.com<mailto:jbladel at godaddy.com>>, Volker Greimann <vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>>, "gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>" <gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>>
Subject: Re: [Gnso-ppsai-pdp-wg] Proposal contactability

Thanks James.  Quick question: if, as you note, most of your P/P customers engage the service to avoid being spammed – why is that objective/purpose not sufficiently protected by a standard that says “A provider must relay all electronic requests received (including emails and via web forms), but may implement commercially reasonable safeguards (including CAPTCHA) to filter out spam.”?

By asking the question I don’t necessarily mean to make a judgment on your “access whitelist” idea.  I’m just not sure I understand its utility on this specific question (relay), where a means to address the problem that it is trying to solve (i.e., spam) appears to have already been baked in.

Thanks.

TW.

From:gnso-ppsai-pdp-wg-bounces at icann.org<mailto:gnso-ppsai-pdp-wg-bounces at icann.org> [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On Behalf Of James M. Bladel
Sent: Sunday, August 17, 2014 6:23 PM
To: Volker Greimann; gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>
Subject: Re: [Gnso-ppsai-pdp-wg] Proposal contactability

Thanks to Volker for getting this conversation started.  I also share the belief that we should define a system that assures reporters their claims will be relayed by P/P services.  However, I disagree on some key points raised by Volker and others.

First, I do not believe there should be any attempt to filter submitted reports based on content.  That approach does not scale, and simply results in an arms race where would-be spammers attempt to circumvent the filters.  Also, I do not believe P/P services should relay —all—reports.  This treats the P/P email point of contact as an email “alias” for the beneficial user’s real address, and completely defeats the purpose of the service (most of our P/P customers engage the service to avoid being spammed).

I favor an approach that is modeled after ICANN’s Invalid WHOIS Reporting System, and one that many Registrars have implemented to guard against WHOIS harvesting – an access whitelist.  Speaking generally, such a system would require reporters to identify themselves when submitting a claim for relay.  Is reporter should also have to designate the email address from which relay claims will originate, and the service provider agrees to honor relay request from that Address without discriminating on its content.  The P/P service provider can then monitor the use of the relay system by each reporter, and suspend or terminate access for any reporter that is found to be abusing the system.

If this sounds familiar, it is blatantly copied from the EWG's proposed RDS concept. I think this idea has merit, and regardless of what happens to the rest of the EWG's recommendations, we should consider opportunities to implement this proposal in existing contexts.

Look forward to continuing our discussions on this point on Tuesday.

Thanks—

J.

From: Volker Greimann <vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>>
Date: Wednesday, August 13, 2014 at 4:27
To: "gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>" <gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>>
Subject: [Gnso-ppsai-pdp-wg] Proposal contactability

As Susan and Steve have repeatedly asked what my proposal would be to ensure contactability of the beneficial owner/registrant.

As a basis, a spec derivative of the WAP spec to the RAA would have to be developed. I took the liberty of modifying the WAP for this purpose as a basis for discussion.
This would bring the obligation of the privacy service provider to validate and verify the contact details to the same level of that of the registrar, thus ensuring the Service Provider has either accurate details or a duty to verify and validate.

Now, I would agree that some level of a contactibility guarantee is warranted. This could be something to this tune, as a basis for discussion:

"Service Provider are required provide a means for third parties to directly or indirectly communicate with the Beneficial Owner. Such means may include any of the following:
a) providing a postal mail forwarding address
b) providing a collective email point of contact for all domain names under the Service (such as abuse at service.provider<mailto:abuse at service.provider>)
c) providing an individual email point of contact for each domain name under the Service (such as string at domain.name<mailto:string at domain.name> or domain.name at service.provider<mailto:domain.name at service.provider>)
...
...

Service Provider must inform potential complainants about the accepted means of communication on its website. Service provider may refuse to forward, process or even accept communications sent by a non-accepted means of communication. In case forwarding of postal communications is offered, Service Provider may charge complainant reasonable handling fees and costs for the forwarding service and defer the forwarding of communications until payment is received.

Service Provider may refuse to forward spam, duplicate messages, purchase or business inquiries, harrassing communications, anonymous communications and/or unwanted communications. Service Provider is authorized to update or modify the means of communication from time to time. Service Provider is authorized to blacklist complainants with a history of abusing the provided means of communication."

All subject to further discussion, ofc.

I realize this draft goes into detail more than we should in this WG, but having been asked for a proposal, I felt it necessary in order to move the discussion ahead.
Terms:
Service Provider - Privacy/Proxy Service Provider
Beneficial Owner - Replaces "Registrant"
filter - not deliver to Beneficial owner
Service - the privacy/proxy services

--

Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.

Mit freundlichen Grüßen,

Volker A. Greimann

- Rechtsabteilung -

Key-Systems GmbH

Im Oberen Werk 1

66386 St. Ingbert

Tel.: +49 (0) 6894 - 9396 901

Fax.: +49 (0) 6894 - 9396 851

Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>

Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net>www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com>

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:

www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>www.twitter.com/key_systems<http://www.twitter.com/key_systems>

Geschäftsführer: Alexander Siffrin

Handelsregister Nr.: HR B 18835 - Saarbruecken

Umsatzsteuer ID.: DE211006534

Member of the KEYDRIVE GROUP

www.keydrive.lu<http://www.keydrive.lu>

Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.

--------------------------------------------

Should you have any further questions, please do not hesitate to contact us.

Best regards,

Volker A. Greimann

- legal department -

Key-Systems GmbH

Im Oberen Werk 1

66386 St. Ingbert

Tel.: +49 (0) 6894 - 9396 901

Fax.: +49 (0) 6894 - 9396 851

Email: vgreimann at key-systems.net<mailto:vgreimann at key-systems.net>

Web: www.key-systems.net<http://www.key-systems.net> / www.RRPproxy.net<http://www.RRPproxy.net>www.domaindiscount24.com<http://www.domaindiscount24.com> / www.BrandShelter.com<http://www.BrandShelter.com>

Follow us on Twitter or join our fan community on Facebook and stay updated:

www.facebook.com/KeySystems<http://www.facebook.com/KeySystems>www.twitter.com/key_systems<http://www.twitter.com/key_systems>

CEO: Alexander Siffrin

Registration No.: HR B 18835 - Saarbruecken

V.A.T. ID.: DE211006534

Member of the KEYDRIVE GROUP

www.keydrive.lu<http://www.keydrive.lu>

This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.

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