[Gnso-ppsai-pdp-wg] Missing Annex

McGrady, Paul D. PMcGrady at winston.com
Tue Apr 7 14:08:10 UTC 2015


Thanks Volker, but I think you are mistaken.  The current status quo is that all WHOIS information must be accurate.  We are taking about granting a limited exception to that rule through accrediting privacy/proxy services to provide their information in lieu of the registrant's information.  The discuss is what happens if the provider gets a request for reveal which it acts on erroneously.  While this may lead to a breach of contract count to be heard in a court where the parties to the P/P services agreement have agreed to have disputes heard, it doesn't lead to a cause of action for privacy violations in every jurisdiction and even if it did I'm not sure that is ICANN's role to be the enforcer of such rights.  Regarding your comments on the EU privacy directive, without addressing the substance of the comment, it evidences that there is no supranational privacy right as - even under your model - it would not apply if the P/P service had no EU customers.

This is a very slippery slope and I again ask someone to point me to a document which indicates that this is within our scope.  Thanks much.

From: gnso-ppsai-pdp-wg-bounces at icann.org [mailto:gnso-ppsai-pdp-wg-bounces at icann.org] On Behalf Of Volker Greimann
Sent: Tuesday, April 07, 2015 8:49 AM
To: gnso-ppsai-pdp-wg at icann.org
Subject: Re: [Gnso-ppsai-pdp-wg] Missing Annex

Hi paul,

in fact we are doing the opposite, i.e. defining when something the registrant already has can/most/should be taken away and we are making certain that any such removal of a position the registrant is in tune with his rights.

The current status quo is that the registrant has privacy.

The question now is: When can this be taken away and for what reasons and what protections are needed to ensure that this violation can not occur when it would violate the rights of the registrant.

As to your comments, there already are quasi supranational privacy laws:

no matter where you are located as a service provider, if you serve customers from the EU, EU data privacy laws applies to your handling of that customers data. So under current EU law, you will have to protect the privacy rights of European customers. Now enforcement of that may be another issue, but the legal basis is as above.

Best,

Volker

Am 07.04.2015 um 15:26 schrieb McGrady, Paul D.:
I'm becoming very concerned that we are getting way off track here by attempting to create supranational privacy rights and then put the burden of interpretation of such supranational privacy rights on providers and the enforcement of whether or not the providers got it right onto ICANN.  Before we go further, I would really like for someone to point out where we think we get this scope, because I'm not at all sure that ICANN has the remit to create and enforce supranational privacy rights (so I think it is very likely that we don't either).  Can someone point me to the appropriate document?  Absent a pre-existing supranational privacy right, it seems to me that the "process" for any violation of national privacy rights would be for the abused party to take action in the courts if a cause of action exists.  I don't see how in the world we are going annex 200+ countries privacy laws...

Best,
Paul



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 Kathy Kleiman
Sent: Tuesday, April 07, 2015 8:08 AM
To: gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>
Subject: Re: [Gnso-ppsai-pdp-wg] Missing Annex

Hi Steve and All,
I think we need to add a missing Annex - one to cover the process that should take place when a Requester or the Trademark/Copyright Owner to which it is reporting disclose the Revealed Data in way that is not consistent with the limitations agreed to in the disclosure -- e.g., publishes the data or passes it on to other third parties (who presumably misuse it- which is how the Provider might learn of the misuse).  This action could, of course, compromise the safety and security of individuals and organizations.

I volunteer to work with others to write such an Annex by next week...

Best,
Kathy

:
Just a brief note that could facilitate our discussion tomorrow with regard to the "Annex" to the draft disclosure framework.  (Thanks Mary for recirculating this text.)
As the title spells out, the document sets forth "Some options for resolving disputes arising from alleged false statements leading to improper disclosures."  The Annex is not intended to address any appeal mechanism regarding a disclosure request, but only the consequences of a request wrongfully granted because based on false pretenses.
In this document, "some" options basically boils down to two options.  Under the first option, a requestor would agree to submit such disputes to an arbitrator.  (The other party to the dispute, the privacy/proxy service provider, would presumably agree to this method as well, as part of its accreditation process.)  The document provides some more detail about the arbitration process, though certainly much more work would need to be done to implement it.
Under the second option, the requestor would agree, for purposes of such wrongful disclosure disputes, to submit to the jurisdiction of the courts in the territory where the service provider is located.
Our discussions over the past few weeks may have made the last paragraph of the Annex document less relevant. It is based on the assumption that, under either option, not all requestors would necessarily be required to agree.  As specified in section I.b.iv of the overall document, a service provider could, if it chose, institute a "trusted requestor" program to facilitate processing of requests from reliable sources.  The last paragraph of the Annex says that a service  provider could, if it chose, make such an agreement a condition of entry into a "trusted requestor" program, if it had one.  This last paragraph may be irrelevant if the group decides that some dispute resolution process should be available whenever the service provider believes it has wrongfully disclosed based on false pretenses.  But ultimately the group still needs to decide whether there will be such a mandatory dispute resolution process, and if so, which process it will be (arbitration, or litigation in the service provider's home court).
                Looking forward to our discussion tomorrow.

Steve Metalitz

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 Mary Wong
Sent: Monday, April 06, 2015 10:05 AM
To: gnso-ppsai-pdp-wg at icann.org<mailto:gnso-ppsai-pdp-wg at icann.org>
Subject: [Gnso-ppsai-pdp-wg] Agenda and documents for WG call on 7 April 2014

Dear WG members,

The proposed agenda for the next WG call on 7 April 2014 is as follows:

  1.  Roll call/updates to SOI
  2.  Continue deliberations on Category F, specifically: (a) attestation/signatory for Requests; (b) Section III.C(5); (c) non-use of high-volume automated processes; and (d) the Annex.
  3.  Next steps/next meeting
Please also find attached an updated version of the draft disclosure framework for agenda item #2. This version accepts all the changes up to last week (excluding prior suggested changes to the type of information required on a Requestor), and adds the recent language suggested by Val on attestation, Todd and Volker on III.C(5) (in square brackets as two alternate versions), and a final paragraph/sentence on the automation issue, based on language previously suggested by Todd and a suggestion by James to look at the specific language in the 2013 RAA applicable to this type of activity.

The draft Annex 1 is also attached - it preserves the original text that was presented to the WG several weeks ago, since the WG chairs thought it would be easier to review that way in order to ensure that everyone is clear about the options being offered.

Thanks and 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>








_______________________________________________

Gnso-ppsai-pdp-wg mailing list

Gnso-ppsai-pdp-wg at icann.org<mailto:Gnso-ppsai-pdp-wg at icann.org>

https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg


The contents of this message may be privileged and confidential. Therefore, if this message has been received in error, please delete it without reading it. Your receipt of this message is not intended to waive any applicable privilege. Please do not disseminate this message without the permission of the author.



_______________________________________________

Gnso-ppsai-pdp-wg mailing list

Gnso-ppsai-pdp-wg at icann.org<mailto:Gnso-ppsai-pdp-wg at icann.org>

https://mm.icann.org/mailman/listinfo/gnso-ppsai-pdp-wg



--

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.






The contents of this message may be privileged and confidential. Therefore, if this message has been received in error, please delete it without reading it. Your receipt of this message is not intended to waive any applicable privilege. Please do not disseminate this message without the permission of the author.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-ppsai-pdp-wg/attachments/20150407/4bb9e3ec/attachment-0001.html>


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