[Gnso-ppsai-pdp-wg] Missing Annex
Volker Greimann
vgreimann at key-systems.net
Tue Apr 7 13:48:23 UTC 2015
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] *On Behalf Of *Kathy Kleiman
> *Sent:* Tuesday, April 07, 2015 8:08 AM
> *To:* 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
> 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
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.facebook.com/KeySystems
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
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
Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:
www.facebook.com/KeySystems
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
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/20150407/42a45326/attachment-0001.html>
More information about the Gnso-ppsai-pdp-wg
mailing list