[Gnso-ppsai-pdp-wg] Proposal contactability

Mon Aug 18 01:45:18 UTC 2014

Thanks for putting forward a proposal regarding relay.  It is helpful to have a concrete proposal to discuss.

I have a couple of concerns.  First, let's remember that the purpose of the relay function should be to facilitate contact by a third party to the privacy/proxy service customer, in order to address a problem (including but not limited to a legal problem) associated with the use of a domain name registered by that customer (via the p/p service).  Yes, like any other communications channel, there is a risk that this one will be abused, and I am not opposed to measures aimed at managing that risk.  But let's remember that the third party requester is depending on this channel to help fix a problem, and refusing to forward that message eliminates any value to that channel in achieving that purpose.  On the other hand, the potential harm to the customer if a message is improperly relayed  - receiving an unwanted or unanticipated message --- is, I believe, in most cases minimal, and of course the failure to forward could increase the legal or other jeopardy which the customer faces.  This is why a presumption that all messages would be relayed is justified in the vast majority of cases.  I repeat that there is a case to be made for giving the provider some ability to refuse to forward limited and defined categories of abusive communications, but let's not let the exception swallow the rule.

Second, in today's environment, e-mail is the expected means of communication, both between the provider and its customer, and between the third party requester and the customer, via the provider.  In the vast majority of cases, we do not send hard copy and we don't expect or require providers to forward hard copy.  So the idea that a provider could establish the policy that it will ONLY forward hard copy, and that it will NOT forward e-mail, is a non-starter for various reasons.  Let's focus our discussion on the obligation to forward e-mail , which is what is involved 99.99% of the time (the method that the p/p provider uses to communicate with its customer generally).

Third, we have a serious problem with the concept that the provider would refuse to forward something unless the requester pays for forwarding.  The provider is operating an commercial business that includes an obligation to forward e-mail.  We don't see any reason why the cost of that forwarding (which in most cases will be microscopic) should not be borne by the provider and folded into the price it charges the customer.  It certainly should not be imposed on an innocent third party who is prevented from contacting the customer directly and is simply using this channel to try to reach the customer in order to solve a problem.  Even in the very limited set of cases in which it might be necessary to forward hard copy (because the customer has provided a bogus e-mail address to the provider and thus the forwarded e-mail is undeliverable), the principle is the same - I don't see the justification for imposing a cost on the complainant/victim because the customer has made himself unreachable via the p/p service.

There are a number of other issues with ths proposal but I wanted to get these on the table. -vicky

vicky sheckler | senior vice president, deputy general counsel | recording industry association of america | 1025 F street, NW 10th floor | washington, dc 20004 |  202.775.0101 (m) |  202.857.9603 (d) |  703-732-3714 (c)

[WMM_email_sig]

From: gnso-ppsai-pdp-wg-bounces at icann.org [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On Behalf Of Volker Greimann
Sent: Wednesday, August 13, 2014 5:28 AM
To: 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/20140818/45d8b729/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 14480 bytes
Desc: image001.jpg
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20140818/45d8b729/image001-0001.jpg>