Follow-Up on Yesterday's PP IRT Discussion
Dear Colleagues, Following up on our discussion yesterday, I checked with the Legal team about a couple of items that were discussed. 1. With respect to the proposed edits to the PPAA that are related to data processing (see, e.g. Section 3.5.3 of the contract and the new draft Specification 8), provisions on these topics must be included in this contract, though these can be edited based on your feedback. If you have suggested edits to these new provisions, please send them to the list and we can discuss them on the call next week. If, as discussed yesterday, you believe the inclusion of these provisions raises more fundamental questions about status, in light of the pending ePDP on similar topics, we can also discuss that. As a reminder, the way the PPAA is drafted, any new ICANN Policy that is in conflict with current provisions (GDPR-related or otherwise) would supersede any conflicting provisions in this contract. 1. On the overall timeline, and additional deliverables, any additional GDPR-related changes will be based on IRT feedback. We have a couple of additional discussion topics that we didn't reach last week, which could require additional PPAA changes. We'll discuss these next week: * Are the disclosure frameworks intended to give Providers limited or no discretion on disclosure if other requirements in the framework are met? * What should requirements be for a Provider's logging of disclosure requests from third parties? We are continuing to review the contract for any copy-editing related issues, and I expect we will finish with those in the next week or so. I hope this is helpful. Please continue to consider these issues and share any feedback you have on-list. We can pick up on these issues next week. Thanks, and have a great weekend! Amy Amy E. Bivins Registrar Services and Engagement Senior Manager Registrar Services and Industry Relations Internet Corporation for Assigned Names and Numbers (ICANN) Direct: +1 (202) 249-7551 Fax: +1 (202) 789-0104 Email: amy.bivins@icann.org<mailto:amy.bivins@icann.org> www.icann.org<http://www.icann.org>
Hi Amy, re: temporary specification. Privacy/Proxy services are not bound by the current temp spec and will not be bound once accredited as their services are out of scope of the spec: Please review 1.2 of the temp Spec: "1.2. This Temporary Specification applies to all gTLD Registry Operators and ICANN-accredited Registrars." That's it. All additions of clauses based on the temp spec must therefore be removed again before we can go to public comment. Also, here are a few suggested additional edits: 3.2.2 During the Term of this agreement and for one year thereafter *- or the maximum duration allowed by applicable law, if shorter* - Provider shall ... 3.3 -remove in its entirety - we never proposed a public access RDS system by privacy services in the WG. It is also unclear whom the license is supposed to be granted to. 3.4. Add: This requirement is void if the data described in Sections [3.3.1 through 3.3.4] is already being escrowed by the sponsoring registrar. 3.5.3 Move information requirements to 3.8, unless a specific notice is absolutely required. 3.5.3.3 Replace by: Provider shall provide appropriate notice to a Customer upon each initial agreement regarding a Registered Name for which Provider is providing the Services. Such a notice should provide all legally required information in accordance with applicable data privacy laws (optional: which may include: 3.5.3.3.1, 3.5.3.3.2, 3.5.3.3.3, 3.5.3.3.4, 3.5.3.3.5, 3.5.3.3.6, 3.5.3.3.9, 3.5.3.3.10, 3.5.3.3.11, 3.5.3.3.13 (add: if applicable), 3.5.3.3.14.) 3.5.3.4: Remove completely, as this is invalid forced consent. 3.5.3.8 Remove: Unnecessary as already included in registration agreements. No need for duplication of representation. 3.6.1 change $4,000 to $400 3.17. add at the end: ...and to the extent permitted under applicable law. 3.18.2 Add: Provider shall not be required to allow transfers to registrars it has no agreement with as long as its data remains in the RDS at the time the transfer is requested. 7.2. Please add data processing equivalency language. Also remove the reference to the "specification in effect". Spec 2, Remove Sections 1.2.5, 1.3.1,1.3.2, 1.3.3, 1.3.5 - irrelevant for pp services. under Section 2 add: "...provided the Provider and the services provided by it are in scope of such a temporary policy." Spec 8: Strike then entire thing and replace it by general language that required provider to process data in accordance with any requirements of applicable law. Am 31.08.2018 um 21:09 schrieb Amy Bivins:
Dear Colleagues,
Following up on our discussion yesterday, I checked with the Legal team about a couple of items that were discussed.
1. With respect to the proposed edits to the PPAA that are related to data processing (see, e.g. Section 3.5.3 of the contract and the new draft Specification 8), provisions on these topics must be included in this contract, though these can be edited based on your feedback.
If you have suggested edits to these new provisions, please send them to the list and we can discuss them on the call next week. If, as discussed yesterday, you believe the inclusion of these provisions raises more fundamental questions about status, in light of the pending ePDP on similar topics, we can also discuss that.
As a reminder, the way the PPAA is drafted, any new ICANN Policy that is in conflict with current provisions (GDPR-related or otherwise) would supersede any conflicting provisions in this contract.
2. On the overall timeline, and additional deliverables, any additional GDPR-related changes will be based on IRT feedback. We have a couple of additional discussion topics that we didn’t reach last week, which could require additional PPAA changes. We’ll discuss these next week: 1. Are the disclosure frameworks intended to give Providers limited or no discretion on disclosure if other requirements in the framework are met? 2. What should requirements be for a Provider’s logging of disclosure requests from third parties?
We are continuing to review the contract for any copy-editing related issues, and I expect we will finish with those in the next week or so.
I hope this is helpful. Please continue to consider these issues and share any feedback you have on-list. We can pick up on these issues next week.
Thanks, and have a great weekend!
Amy
*Amy E. Bivins*
Registrar Services and Engagement Senior Manager
Registrar Services and Industry Relations
Internet Corporation for Assigned Names and Numbers (ICANN)
Direct: +1 (202) 249-7551
Fax: +1 (202) 789-0104
Email: amy.bivins@icann.org <mailto:amy.bivins@icann.org>
www.icann.org <http://www.icann.org>
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
-- 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@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@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.
Agree with Volker, thanks for pointing this out. Theo Volker Greimann schreef op 2018-09-04 01:52 PM:
Hi Amy,
re: temporary specification. Privacy/Proxy services are not bound by the current temp spec and will not be bound once accredited as their services are out of scope of the spec:
Please review 1.2 of the temp Spec: "1.2. This Temporary Specification applies to all gTLD Registry Operators and ICANN-accredited Registrars."
That's it. All additions of clauses based on the temp spec must therefore be removed again before we can go to public comment.
Also, here are a few suggested additional edits:
3.2.2 During the Term of this agreement and for one year thereafter *- or the maximum duration allowed by applicable law, if shorter* - Provider shall ...
3.3 -remove in its entirety - we never proposed a public access RDS system by privacy services in the WG. It is also unclear whom the license is supposed to be granted to.
3.4. Add: This requirement is void if the data described in Sections [3.3.1 through 3.3.4] is already being escrowed by the sponsoring registrar.
3.5.3 Move information requirements to 3.8, unless a specific notice is absolutely required.
3.5.3.3 Replace by: Provider shall provide appropriate notice to a Customer upon each initial agreement regarding a Registered Name for which Provider is providing the Services. Such a notice should provide all legally required information in accordance with applicable data privacy laws (optional: which may include: 3.5.3.3.1, 3.5.3.3.2, 3.5.3.3.3, 3.5.3.3.4, 3.5.3.3.5, 3.5.3.3.6, 3.5.3.3.9, 3.5.3.3.10, 3.5.3.3.11, 3.5.3.3.13 (add: if applicable), 3.5.3.3.14.)
3.5.3.4: Remove completely, as this is invalid forced consent.
3.5.3.8 Remove: Unnecessary as already included in registration agreements. No need for duplication of representation.
3.6.1 change $4,000 to $400
3.17. add at the end: ...and to the extent permitted under applicable law.
3.18.2 Add: Provider shall not be required to allow transfers to registrars it has no agreement with as long as its data remains in the RDS at the time the transfer is requested.
7.2. Please add data processing equivalency language. Also remove the reference to the "specification in effect".
Spec 2, Remove Sections 1.2.5, 1.3.1,1.3.2, 1.3.3, 1.3.5 - irrelevant for pp services.
under Section 2 add: "...provided the Provider and the services provided by it are in scope of such a temporary policy."
Spec 8: Strike then entire thing and replace it by general language that required provider to process data in accordance with any requirements of applicable law.
Am 31.08.2018 um 21:09 schrieb Amy Bivins:
Dear Colleagues,
Following up on our discussion yesterday, I checked with the Legal team about a couple of items that were discussed.
1. With respect to the proposed edits to the PPAA that are related to data processing (see, e.g. Section 3.5.3 of the contract and the new draft Specification 8), provisions on these topics must be included in this contract, though these can be edited based on your feedback.
If you have suggested edits to these new provisions, please send them to the list and we can discuss them on the call next week. If, as discussed yesterday, you believe the inclusion of these provisions raises more fundamental questions about status, in light of the pending ePDP on similar topics, we can also discuss that.
As a reminder, the way the PPAA is drafted, any new ICANN Policy that is in conflict with current provisions (GDPR-related or otherwise) would supersede any conflicting provisions in this contract.
2. On the overall timeline, and additional deliverables, any additional GDPR-related changes will be based on IRT feedback. We have a couple of additional discussion topics that we didn’t reach last week, which could require additional PPAA changes. We’ll discuss these next week: 1. Are the disclosure frameworks intended to give Providers limited or no discretion on disclosure if other requirements in the framework are met? 2. What should requirements be for a Provider’s logging of disclosure requests from third parties?
We are continuing to review the contract for any copy-editing related issues, and I expect we will finish with those in the next week or so.
I hope this is helpful. Please continue to consider these issues and share any feedback you have on-list. We can pick up on these issues next week.
Thanks, and have a great weekend!
Amy
*Amy E. Bivins*
Registrar Services and Engagement Senior Manager
Registrar Services and Industry Relations
Internet Corporation for Assigned Names and Numbers (ICANN)
Direct: +1 (202) 249-7551
Fax: +1 (202) 789-0104
Email: amy.bivins@icann.org <mailto:amy.bivins@icann.org>
www.icann.org <http://www.icann.org>
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
-- 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@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@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.
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
Thanks, Volker, for these detailed suggestions. If others have specific recommended edits or comments on these, please let me know by your EOD tomorrow and I'll distribute a markup of the spec before we meet on Thursday. Best, Amy -----Original Message----- From: Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl-bounces@icann.org> On Behalf Of gtheo Sent: Tuesday, September 4, 2018 8:11 AM To: gdd-gnso-ppsai-impl@icann.org Subject: Re: [Gdd-gnso-ppsai-impl] Follow-Up on Yesterday's PP IRT Discussion Agree with Volker, thanks for pointing this out. Theo Volker Greimann schreef op 2018-09-04 01:52 PM:
Hi Amy,
re: temporary specification. Privacy/Proxy services are not bound by the current temp spec and will not be bound once accredited as their services are out of scope of the spec:
Please review 1.2 of the temp Spec: "1.2. This Temporary Specification applies to all gTLD Registry Operators and ICANN-accredited Registrars."
That's it. All additions of clauses based on the temp spec must therefore be removed again before we can go to public comment.
Also, here are a few suggested additional edits:
3.2.2 During the Term of this agreement and for one year thereafter *- or the maximum duration allowed by applicable law, if shorter* - Provider shall ...
3.3 -remove in its entirety - we never proposed a public access RDS system by privacy services in the WG. It is also unclear whom the license is supposed to be granted to.
3.4. Add: This requirement is void if the data described in Sections [3.3.1 through 3.3.4] is already being escrowed by the sponsoring registrar.
3.5.3 Move information requirements to 3.8, unless a specific notice is absolutely required.
3.5.3.3 Replace by: Provider shall provide appropriate notice to a Customer upon each initial agreement regarding a Registered Name for which Provider is providing the Services. Such a notice should provide all legally required information in accordance with applicable data privacy laws (optional: which may include: 3.5.3.3.1, 3.5.3.3.2, 3.5.3.3.3, 3.5.3.3.4, 3.5.3.3.5, 3.5.3.3.6, 3.5.3.3.9, 3.5.3.3.10, 3.5.3.3.11, 3.5.3.3.13 (add: if applicable), 3.5.3.3.14.)
3.5.3.4: Remove completely, as this is invalid forced consent.
3.5.3.8 Remove: Unnecessary as already included in registration agreements. No need for duplication of representation.
3.6.1 change $4,000 to $400
3.17. add at the end: ...and to the extent permitted under applicable law.
3.18.2 Add: Provider shall not be required to allow transfers to registrars it has no agreement with as long as its data remains in the RDS at the time the transfer is requested.
7.2. Please add data processing equivalency language. Also remove the reference to the "specification in effect".
Spec 2, Remove Sections 1.2.5, 1.3.1,1.3.2, 1.3.3, 1.3.5 - irrelevant for pp services.
under Section 2 add: "...provided the Provider and the services provided by it are in scope of such a temporary policy."
Spec 8: Strike then entire thing and replace it by general language that required provider to process data in accordance with any requirements of applicable law.
Am 31.08.2018 um 21:09 schrieb Amy Bivins:
Dear Colleagues,
Following up on our discussion yesterday, I checked with the Legal team about a couple of items that were discussed.
1. With respect to the proposed edits to the PPAA that are related to data processing (see, e.g. Section 3.5.3 of the contract and the new draft Specification 8), provisions on these topics must be included in this contract, though these can be edited based on your feedback.
If you have suggested edits to these new provisions, please send them to the list and we can discuss them on the call next week. If, as discussed yesterday, you believe the inclusion of these provisions raises more fundamental questions about status, in light of the pending ePDP on similar topics, we can also discuss that.
As a reminder, the way the PPAA is drafted, any new ICANN Policy that is in conflict with current provisions (GDPR-related or otherwise) would supersede any conflicting provisions in this contract.
2. On the overall timeline, and additional deliverables, any additional GDPR-related changes will be based on IRT feedback. We have a couple of additional discussion topics that we didn’t reach last week, which could require additional PPAA changes. We’ll discuss these next week: 1. Are the disclosure frameworks intended to give Providers limited or no discretion on disclosure if other requirements in the framework are met? 2. What should requirements be for a Provider’s logging of disclosure requests from third parties?
We are continuing to review the contract for any copy-editing related issues, and I expect we will finish with those in the next week or so.
I hope this is helpful. Please continue to consider these issues and share any feedback you have on-list. We can pick up on these issues next week.
Thanks, and have a great weekend!
Amy
*Amy E. Bivins*
Registrar Services and Engagement Senior Manager
Registrar Services and Industry Relations
Internet Corporation for Assigned Names and Numbers (ICANN)
Direct: +1 (202) 249-7551
Fax: +1 (202) 789-0104
Email: amy.bivins@icann.org <mailto:amy.bivins@icann.org>
www.icann.org <http://www.icann.org>
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
-- 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@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@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.
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
Thanks, Volker. Excellent points raised. I support Volker’s suggested amendments. Sara Bockey GoDaddy | Senior Policy Manager +1 480-366-3616 sbockey@godaddy.com<mailto:sbockey@godaddy.com> This email message and any attachments hereto is intended for use only by the addressee(s) named herein and may contain confidential information. If you have received this email in error, please immediately notify the sender and permanently delete the original and any copy of this message and its attachments. From: Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl-bounces@icann.org> on behalf of Volker Greimann <vgreimann@key-systems.net> Reply-To: "gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org> Date: Tuesday, September 4, 2018 at 4:53 AM To: "gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org> Subject: Re: [Gdd-gnso-ppsai-impl] Follow-Up on Yesterday's PP IRT Discussion Hi Amy, re: temporary specification. Privacy/Proxy services are not bound by the current temp spec and will not be bound once accredited as their services are out of scope of the spec: Please review 1.2 of the temp Spec: "1.2. This Temporary Specification applies to all gTLD Registry Operators and ICANN-accredited Registrars." That's it. All additions of clauses based on the temp spec must therefore be removed again before we can go to public comment. Also, here are a few suggested additional edits: 3.2.2 During the Term of this agreement and for one year thereafter - or the maximum duration allowed by applicable law, if shorter - Provider shall ... 3.3 -remove in its entirety - we never proposed a public access RDS system by privacy services in the WG. It is also unclear whom the license is supposed to be granted to. 3.4. Add: This requirement is void if the data described in Sections [3.3.1 through 3.3.4] is already being escrowed by the sponsoring registrar. 3.5.3 Move information requirements to 3.8, unless a specific notice is absolutely required. 3.5.3.3 Replace by: Provider shall provide appropriate notice to a Customer upon each initial agreement regarding a Registered Name for which Provider is providing the Services. Such a notice should provide all legally required information in accordance with applicable data privacy laws (optional: which may include: 3.5.3.3.1, 3.5.3.3.2, 3.5.3.3.3, 3.5.3.3.4, 3.5.3.3.5, 3.5.3.3.6, 3.5.3.3.9, 3.5.3.3.10, 3.5.3.3.11, 3.5.3.3.13 (add: if applicable), 3.5.3.3.14.) 3.5.3.4: Remove completely, as this is invalid forced consent. 3.5.3.8 Remove: Unnecessary as already included in registration agreements. No need for duplication of representation. 3.6.1 change $4,000 to $400 3.17. add at the end: ...and to the extent permitted under applicable law. 3.18.2 Add: Provider shall not be required to allow transfers to registrars it has no agreement with as long as its data remains in the RDS at the time the transfer is requested. 7.2. Please add data processing equivalency language. Also remove the reference to the "specification in effect". Spec 2, Remove Sections 1.2.5, 1.3.1,1.3.2, 1.3.3, 1.3.5 - irrelevant for pp services. under Section 2 add: "...provided the Provider and the services provided by it are in scope of such a temporary policy." Spec 8: Strike then entire thing and replace it by general language that required provider to process data in accordance with any requirements of applicable law. Am 31.08.2018 um 21:09 schrieb Amy Bivins: Dear Colleagues, Following up on our discussion yesterday, I checked with the Legal team about a couple of items that were discussed. 1. With respect to the proposed edits to the PPAA that are related to data processing (see, e.g. Section 3.5.3 of the contract and the new draft Specification 8), provisions on these topics must be included in this contract, though these can be edited based on your feedback. If you have suggested edits to these new provisions, please send them to the list and we can discuss them on the call next week. If, as discussed yesterday, you believe the inclusion of these provisions raises more fundamental questions about status, in light of the pending ePDP on similar topics, we can also discuss that. As a reminder, the way the PPAA is drafted, any new ICANN Policy that is in conflict with current provisions (GDPR-related or otherwise) would supersede any conflicting provisions in this contract. 1. On the overall timeline, and additional deliverables, any additional GDPR-related changes will be based on IRT feedback. We have a couple of additional discussion topics that we didn’t reach last week, which could require additional PPAA changes. We’ll discuss these next week: a. Are the disclosure frameworks intended to give Providers limited or no discretion on disclosure if other requirements in the framework are met? b. What should requirements be for a Provider’s logging of disclosure requests from third parties? We are continuing to review the contract for any copy-editing related issues, and I expect we will finish with those in the next week or so. I hope this is helpful. Please continue to consider these issues and share any feedback you have on-list. We can pick up on these issues next week. Thanks, and have a great weekend! Amy Amy E. Bivins Registrar Services and Engagement Senior Manager Registrar Services and Industry Relations Internet Corporation for Assigned Names and Numbers (ICANN) Direct: +1 (202) 249-7551 Fax: +1 (202) 789-0104 Email: amy.bivins@icann.org<mailto:amy.bivins@icann.org> www.icann.org<http://www.icann.org> _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl -- 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@key-systems.net<mailto:vgreimann@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@key-systems.net<mailto:vgreimann@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.
Apologies for lateness, reading through - all I can say is very thorough Volker, I support all amendments. I also strongly back Volkers 4.6.1 comment, the fees were never discussed in the original WG, nor if memory serves were they put into the final report, lastly, in Dublin, ICANN54 were they ever even mentioned. I believe it is unjust that ICANN should underhandedly put these in. Totally unacceptable. As Cyrus was so keen to push this back to GNSO - I would support that too. My last point is ICANN "Fee workings" that have been provided to the IRT has not been substantive enough - I know I am flogging a dead horse but you have been told by MANY people now. Kind regards, Chris From: "Volker Greimann" <vgreimann@key-systems.net> To: gdd-gnso-ppsai-impl@icann.org Sent: Tuesday, 4 September, 2018 12:52:48 Subject: Re: [Gdd-gnso-ppsai-impl] Follow-Up on Yesterday's PP IRT Discussion Hi Amy, re: temporary specification. Privacy/Proxy services are not bound by the current temp spec and will not be bound once accredited as their services are out of scope of the spec: Please review 1.2 of the temp Spec: "1.2. This Temporary Specification applies to all gTLD Registry Operators and ICANN -accredited Registrars." That's it. All additions of clauses based on the temp spec must therefore be removed again before we can go to public comment. Also, here are a few suggested additional edits: 3.2.2 During the Term of this agreement and for one year thereafter - or the maximum duration allowed by applicable law, if shorter - Provider shall ... 3.3 -remove in its entirety - we never proposed a public access RDS system by privacy services in the WG. It is also unclear whom the license is supposed to be granted to. 3.4. Add: This requirement is void if the data described in Sections [3.3.1 through 3.3.4] is already being escrowed by the sponsoring registrar. 3.5.3 Move information requirements to 3.8, unless a specific notice is absolutely required. 3.5.3.3 Replace by: Provider shall provide appropriate notice to a Customer upon each initial agreement regarding a Registered Name for which Provider is providing the Services. Such a notice should provide all legally required information in accordance with applicable data privacy laws (optional: which may include: 3.5.3.3.1, 3.5.3.3.2, 3.5.3.3.3, 3.5.3.3.4, 3.5.3.3.5, 3.5.3.3.6, 3.5.3.3.9, 3.5.3.3.10, 3.5.3.3.11, 3.5.3.3.13 (add: if applicable), 3.5.3.3.14.) 3.5.3.4: Remove completely, as this is invalid forced consent. 3.5.3.8 Remove: Unnecessary as already included in registration agreements. No need for duplication of representation. 3.6.1 change $4,000 to $400 3.17. add at the end: ...and to the extent permitted under applicable law. 3.18.2 Add: Provider shall not be required to allow transfers to registrars it has no agreement with as long as its data remains in the RDS at the time the transfer is requested. 7.2. Please add data processing equivalency language. Also remove the reference to the "specification in effect". Spec 2, Remove Sections 1.2.5, 1.3.1,1.3.2, 1.3.3, 1.3.5 - irrelevant for pp services. under Section 2 add: "...provided the Provider and the services provided by it are in scope of such a temporary policy." Spec 8: Strike then entire thing and replace it by general language that required provider to process data in accordance with any requirements of applicable law. Am 31.08.2018 um 21:09 schrieb Amy Bivins: Dear Colleagues, Following up on our discussion yesterday, I checked with the Legal team about a couple of items that were discussed. 1. With respect to the proposed edits to the PPAA that are related to data processing (see, e.g. Section 3.5.3 of the contract and the new draft Specification 8), provisions on these topics must be included in this contract, though these can be edited based on your feedback. If you have suggested edits to these new provisions, please send them to the list and we can discuss them on the call next week. If, as discussed yesterday, you believe the inclusion of these provisions raises more fundamental questions about status, in light of the pending ePDP on similar topics, we can also discuss that. As a reminder, the way the PPAA is drafted, any new ICANN Policy that is in conflict with current provisions (GDPR-related or otherwise) would supersede any conflicting provisions in this contract. 1. On the overall timeline, and additional deliverables, any additional GDPR-related changes will be based on IRT feedback. We have a couple of additional discussion topics that we didn’t reach last week, which could require additional PPAA changes. We’ll discuss these next week: 1. Are the disclosure frameworks intended to give Providers limited or no discretion on disclosure if other requirements in the framework are met? 2. What should requirements be for a Provider’s logging of disclosure requests from third parties? We are continuing to review the contract for any copy-editing related issues, and I expect we will finish with those in the next week or so. I hope this is helpful. Please continue to consider these issues and share any feedback you have on-list. We can pick up on these issues next week. Thanks, and have a great weekend! Amy Amy E. Bivins Registrar Services and Engagement Senior Manager Registrar Services and Industry Relations Internet Corporation for Assigned Names and Numbers (ICANN) Direct: +1 (202) 249-7551 Fax: +1 (202) 789-0104 Email: amy.bivins@icann.org www.icann.org _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl -- 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@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@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. _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
I support Volker's recommended edits as well. Question for Amy - Has there been an official invite sent for this week's meeting? Thanks, Eric *Eric Rokobauer* Sr. Registrar Compliance Manager | Endurance International Group <http://endurance.com> 10 Corporate Drive, Suite 300, Burlington MA 01803 781.852.3445 On Tue, Sep 4, 2018 at 5:29 PM Chris Pelling <chris@netearth.net> wrote:
Apologies for lateness, reading through - all I can say is very thorough Volker, I support all amendments.
I also strongly back Volkers 4.6.1 comment, the fees were never discussed in the original WG, nor if memory serves were they put into the final report, lastly, in Dublin, ICANN54 were they ever even mentioned. I believe it is unjust that ICANN should underhandedly put these in. Totally unacceptable.
As Cyrus was so keen to push this back to GNSO - I would support that too.
My last point is ICANN "Fee workings" that have been provided to the IRT has not been substantive enough - I know I am flogging a dead horse but you have been told by MANY people now.
Kind regards,
Chris
------------------------------ *From: *"Volker Greimann" <vgreimann@key-systems.net> *To: *gdd-gnso-ppsai-impl@icann.org *Sent: *Tuesday, 4 September, 2018 12:52:48 *Subject: *Re: [Gdd-gnso-ppsai-impl] Follow-Up on Yesterday's PP IRT Discussion
Hi Amy,
re: temporary specification. Privacy/Proxy services are not bound by the current temp spec and will not be bound once accredited as their services are out of scope of the spec:
Please review 1.2 of the temp Spec: "1.2. This Temporary Specification applies to all gTLD Registry Operators and ICANN-accredited Registrars."
That's it. All additions of clauses based on the temp spec must therefore be removed again before we can go to public comment.
Also, here are a few suggested additional edits:
3.2.2 During the Term of this agreement and for one year thereafter *- or the maximum duration allowed by applicable law, if shorter* - Provider shall ...
3.3 -remove in its entirety - we never proposed a public access RDS system by privacy services in the WG. It is also unclear whom the license is supposed to be granted to.
3.4. Add: This requirement is void if the data described in Sections [3.3.1 through 3.3.4] is already being escrowed by the sponsoring registrar.
3.5.3 Move information requirements to 3.8, unless a specific notice is absolutely required.
3.5.3.3 Replace by: Provider shall provide appropriate notice to a Customer upon each initial agreement regarding a Registered Name for which Provider is providing the Services. Such a notice should provide all legally required information in accordance with applicable data privacy laws (optional: which may include: 3.5.3.3.1, 3.5.3.3.2, 3.5.3.3.3, 3.5.3.3.4, 3.5.3.3.5, 3.5.3.3.6, 3.5.3.3.9, 3.5.3.3.10, 3.5.3.3.11, 3.5.3.3.13 (add: if applicable), 3.5.3.3.14.)
3.5.3.4: Remove completely, as this is invalid forced consent.
3.5.3.8 Remove: Unnecessary as already included in registration agreements. No need for duplication of representation.
3.6.1 change $4,000 to $400
3.17. add at the end: ...and to the extent permitted under applicable law.
3.18.2 Add: Provider shall not be required to allow transfers to registrars it has no agreement with as long as its data remains in the RDS at the time the transfer is requested.
7.2. Please add data processing equivalency language. Also remove the reference to the "specification in effect".
Spec 2, Remove Sections 1.2.5, 1.3.1,1.3.2, 1.3.3, 1.3.5 - irrelevant for pp services.
under Section 2 add: "...provided the Provider and the services provided by it are in scope of such a temporary policy."
Spec 8: Strike then entire thing and replace it by general language that required provider to process data in accordance with any requirements of applicable law.
Am 31.08.2018 um 21:09 schrieb Amy Bivins:
Dear Colleagues,
Following up on our discussion yesterday, I checked with the Legal team about a couple of items that were discussed.
1. With respect to the proposed edits to the PPAA that are related to data processing (see, e.g. Section 3.5.3 of the contract and the new draft Specification 8), provisions on these topics must be included in this contract, though these can be edited based on your feedback.
If you have suggested edits to these new provisions, please send them to the list and we can discuss them on the call next week. If, as discussed yesterday, you believe the inclusion of these provisions raises more fundamental questions about status, in light of the pending ePDP on similar topics, we can also discuss that.
As a reminder, the way the PPAA is drafted, any new ICANN Policy that is in conflict with current provisions (GDPR-related or otherwise) would supersede any conflicting provisions in this contract.
1. On the overall timeline, and additional deliverables, any additional GDPR-related changes will be based on IRT feedback. We have a couple of additional discussion topics that we didn’t reach last week, which could require additional PPAA changes. We’ll discuss these next week: 1. Are the disclosure frameworks intended to give Providers limited or no discretion on disclosure if other requirements in the framework are met? 2. What should requirements be for a Provider’s logging of disclosure requests from third parties?
We are continuing to review the contract for any copy-editing related issues, and I expect we will finish with those in the next week or so.
I hope this is helpful. Please continue to consider these issues and share any feedback you have on-list. We can pick up on these issues next week.
Thanks, and have a great weekend!
Amy
*Amy E. Bivins*
Registrar Services and Engagement Senior Manager
Registrar Services and Industry Relations
Internet Corporation for Assigned Names and Numbers (ICANN)
Direct: +1 (202) 249-7551
Fax: +1 (202) 789-0104
Email: amy.bivins@icann.org
www.icann.org
_______________________________________________ Gdd-gnso-ppsai-impl mailing listGdd-gnso-ppsai-impl@icann.orghttps://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
-- 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@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:www.facebook.com/KeySystemswww.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUPwww.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@key-systems.net
Web: www.key-systems.net / www.RRPproxy.netwww.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated:www.facebook.com/KeySystemswww.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUPwww.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.
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
Hi Eric and all, There should be an invite (showing as coming from my email address) for the meeting series on your calendar. If not, please let me know—this is what I set up as the new “official” invite (we no longer have admin support for these calls) but if you would prefer a different format please let me know (this process is new to me, too, and I’m open to your suggestions!). Best, Amy From: Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl-bounces@icann.org> On Behalf Of Eric Rokobauer Sent: Tuesday, September 4, 2018 5:40 PM To: gdd-gnso-ppsai-impl@icann.org Subject: Re: [Gdd-gnso-ppsai-impl] Follow-Up on Yesterday's PP IRT Discussion I support Volker's recommended edits as well. Question for Amy - Has there been an official invite sent for this week's meeting? Thanks, Eric Eric Rokobauer Sr. Registrar Compliance Manager | Endurance International Group<http://endurance.com> 10 Corporate Drive, Suite 300, Burlington MA 01803 781.852.3445 On Tue, Sep 4, 2018 at 5:29 PM Chris Pelling <chris@netearth.net<mailto:chris@netearth.net>> wrote: Apologies for lateness, reading through - all I can say is very thorough Volker, I support all amendments. I also strongly back Volkers 4.6.1 comment, the fees were never discussed in the original WG, nor if memory serves were they put into the final report, lastly, in Dublin, ICANN54 were they ever even mentioned. I believe it is unjust that ICANN should underhandedly put these in. Totally unacceptable. As Cyrus was so keen to push this back to GNSO - I would support that too. My last point is ICANN "Fee workings" that have been provided to the IRT has not been substantive enough - I know I am flogging a dead horse but you have been told by MANY people now. Kind regards, Chris ________________________________ From: "Volker Greimann" <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> To: gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org> Sent: Tuesday, 4 September, 2018 12:52:48 Subject: Re: [Gdd-gnso-ppsai-impl] Follow-Up on Yesterday's PP IRT Discussion Hi Amy, re: temporary specification. Privacy/Proxy services are not bound by the current temp spec and will not be bound once accredited as their services are out of scope of the spec: Please review 1.2 of the temp Spec: "1.2. This Temporary Specification applies to all gTLD Registry Operators and ICANN-accredited Registrars." That's it. All additions of clauses based on the temp spec must therefore be removed again before we can go to public comment. Also, here are a few suggested additional edits: 3.2.2 During the Term of this agreement and for one year thereafter - or the maximum duration allowed by applicable law, if shorter - Provider shall ... 3.3 -remove in its entirety - we never proposed a public access RDS system by privacy services in the WG. It is also unclear whom the license is supposed to be granted to. 3.4. Add: This requirement is void if the data described in Sections [3.3.1 through 3.3.4] is already being escrowed by the sponsoring registrar. 3.5.3 Move information requirements to 3.8, unless a specific notice is absolutely required. 3.5.3.3 Replace by: Provider shall provide appropriate notice to a Customer upon each initial agreement regarding a Registered Name for which Provider is providing the Services. Such a notice should provide all legally required information in accordance with applicable data privacy laws (optional: which may include: 3.5.3.3.1, 3.5.3.3.2, 3.5.3.3.3, 3.5.3.3.4, 3.5.3.3.5, 3.5.3.3.6, 3.5.3.3.9, 3.5.3.3.10, 3.5.3.3.11, 3.5.3.3.13 (add: if applicable), 3.5.3.3.14.) 3.5.3.4<http://3.5.3.4>: Remove completely, as this is invalid forced consent. 3.5.3.8 Remove: Unnecessary as already included in registration agreements. No need for duplication of representation. 3.6.1 change $4,000 to $400 3.17. add at the end: ...and to the extent permitted under applicable law. 3.18.2 Add: Provider shall not be required to allow transfers to registrars it has no agreement with as long as its data remains in the RDS at the time the transfer is requested. 7.2. Please add data processing equivalency language. Also remove the reference to the "specification in effect". Spec 2, Remove Sections 1.2.5, 1.3.1,1.3.2, 1.3.3, 1.3.5 - irrelevant for pp services. under Section 2 add: "...provided the Provider and the services provided by it are in scope of such a temporary policy." Spec 8: Strike then entire thing and replace it by general language that required provider to process data in accordance with any requirements of applicable law. Am 31.08.2018 um 21:09 schrieb Amy Bivins: Dear Colleagues, Following up on our discussion yesterday, I checked with the Legal team about a couple of items that were discussed. 1. With respect to the proposed edits to the PPAA that are related to data processing (see, e.g. Section 3.5.3 of the contract and the new draft Specification 8), provisions on these topics must be included in this contract, though these can be edited based on your feedback. If you have suggested edits to these new provisions, please send them to the list and we can discuss them on the call next week. If, as discussed yesterday, you believe the inclusion of these provisions raises more fundamental questions about status, in light of the pending ePDP on similar topics, we can also discuss that. As a reminder, the way the PPAA is drafted, any new ICANN Policy that is in conflict with current provisions (GDPR-related or otherwise) would supersede any conflicting provisions in this contract. 1. On the overall timeline, and additional deliverables, any additional GDPR-related changes will be based on IRT feedback. We have a couple of additional discussion topics that we didn’t reach last week, which could require additional PPAA changes. We’ll discuss these next week: * Are the disclosure frameworks intended to give Providers limited or no discretion on disclosure if other requirements in the framework are met? * What should requirements be for a Provider’s logging of disclosure requests from third parties? We are continuing to review the contract for any copy-editing related issues, and I expect we will finish with those in the next week or so. I hope this is helpful. Please continue to consider these issues and share any feedback you have on-list. We can pick up on these issues next week. Thanks, and have a great weekend! Amy Amy E. Bivins Registrar Services and Engagement Senior Manager Registrar Services and Industry Relations Internet Corporation for Assigned Names and Numbers (ICANN) Direct: +1 (202) 249-7551 Fax: +1 (202) 789-0104 Email: amy.bivins@icann.org<mailto:amy.bivins@icann.org> www.icann.org<http://www.icann.org> _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl -- 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@key-systems.net<mailto:vgreimann@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@key-systems.net<mailto:vgreimann@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. _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
Thanks Volker, for your detailed review and specific suggestions. I can support many of them, see my reactions in line below. Steve Metalitz ________________________________ From: "Volker Greimann" <vgreimann@key-systems.net<mailto:vgreimann@key-systems.net>> To: gdd-gnso-ppsai-impl@icann.org<mailto:gdd-gnso-ppsai-impl@icann.org> Sent: Tuesday, 4 September, 2018 12:52:48 Subject: Re: [Gdd-gnso-ppsai-impl] Follow-Up on Yesterday's PP IRT Discussion Hi Amy, re: temporary specification. Privacy/Proxy services are not bound by the current temp spec and will not be bound once accredited as their services are out of scope of the spec: Please review 1.2 of the temp Spec: "1.2. This Temporary Specification applies to all gTLD Registry Operators and ICANN-accredited Registrars." That's it. All additions of clauses based on the temp spec must therefore be removed again before we can go to public comment. SM response: In general I agree with this, the Temp Spec does not directly apply here and we must avoid as much as possible injecting the Temp Spec into implementation of a policy that has been adopted after a full multistakeholder PDP process. Also, here are a few suggested additional edits: 3.2.2 During the Term of this agreement and for one year thereafter - or the maximum duration allowed by applicable law, if shorter - Provider shall ... SM comment: No objection to this change. 3.3 -remove in its entirety - we never proposed a public access RDS system by privacy services in the WG. It is also unclear whom the license is supposed to be granted to. SM comment: I don’t fully agree with Volker here. While some change to the provision might be needed, this is still useful as a statement of the subset of the data collected by Provider that would be subject to Disclosure, either under one of the Frameworks or otherwise. The reference to interactive, query-based access should be retained to make it clear that those registrars/registries not redacting the data of non-=EU registrations have a license to display it. Perhaps we should also add a reference to the items listed as being subject to Disclosure in accordance with this agreement. 3.4. Add: This requirement is void if the data described in Sections [3.3.1 through 3.3.4] is already being escrowed by the sponsoring registrar. SM comment: OK with this in principle but as I recall this was going to be spelled out in the “terms … specified by ICANN.” 3.5.3 Move information requirements to 3.8, unless a specific notice is absolutely required. SM comment: Not sure I understand Volker’s proposal here. The data accuracy provisions need to be part of the accreditation agreement (and thus enforceable by ICANN) and not just part of the Terms of Service enforceable by the Provider (though they certainly could be there as well). But I might be missing what Volker is driving at here. 3.5.3.3<http://3.5.3.3> Replace by: Provider shall provide appropriate notice to a Customer upon each initial agreement regarding a Registered Name for which Provider is providing the Services. Such a notice should provide all legally required information in accordance with applicable data privacy laws (optional: which may include: 3.5.3.3.1, 3.5.3.3.2, 3.5.3.3.3, 3.5.3.3.4, 3.5.3.3.5, 3.5.3.3.6, 3.5.3.3.9, 3.5.3.3.10, 3.5.3.3.11, 3.5.3.3.13 (add: if applicable), 3.5.3.3.14.) SM comment: Support this in principle, this is an example of where it would be inappropriate to import the Temp Spec into implementation of a consensus policy. Furthermore, some of these elements make little sense outside of the EU context, and there will continue to be Providers not subject to the GDPR, at least as to certain non-EU Customers. 3.5.3.4<http://3.5.3.4> Remove completely, as this is invalid forced consent. SM comment: I disagree. I am afraid Volker may be committing the error he has often warned us against of conflating a domain name registration service with the service provided by a P/P provider. In the latter case, the only subject matter of the contract itself involves the collection, processing and disclosure of data, not the provision of any other service, so it may be perfectly acceptable to rely upon consent for the processing activities, even if this legal basis is of less value in the case of a domain name registration service where the processing of e.g. contact data of the registrant is arguably more ancillary to the main point of the contract. 3.5.3.8<http://3.5.3.8> Remove: Unnecessary as already included in registration agreements. No need for duplication of representation. SM comment: Disagree, breach of this representation should be a basis for terminating the p/p service even if the registrar is not enforcing the obligation. In addition, as this provision has been in the draft PPAA since the beginning, and is not impacted by GDPR as far as I can tell, I question why it is being challenged at this point. Surely we should not be reopening issues that has already come to rest over the previous years…. 3.6.1 change $4,000 to $400 SM comment: I agree with Volker and the other registrars that the basis for ICANN org’s proposed fees has not been documented/justified, so I have no idea which of these numbers is the “right” one, but it is probably useful to have Volker’s proposal on the table. 3.17. add at the end: ...and to the extent permitted under applicable law. SM comment: I don’t object to this in principle (and as applicable to Disclosures outside the context of the Disclosure Frameworks) but would defer until we get to discussing the proposed edits to these Disclosure Frameworks. 3.18.2 Add: Provider shall not be required to allow transfers to registrars it has no agreement with as long as its data remains in the RDS at the time the transfer is requested. SM comment: Would like to hear more about why this addition is needed and what relationship if any it bears to GDPR and its impact on RDS. (See above as to re-opening settled issues.) 7.2. Please add data processing equivalency language. Also remove the reference to the "specification in effect". SM comment: Not sure what is being proposed here by Volker. Spec 2, Remove Sections 1.2.5, 1.3.1,1.3.2, 1.3.3, 1.3.5 - irrelevant for pp services. SM comment: True but I assume this is simply the same boilerplate definition of Consensus Policies used in other contexts, and wouldn’t tinkering with it here raise unnecessary questions about whether certain topics are no longer within ICANN’s remit? under Section 2 add: "...provided the Provider and the services provided by it are in scope of such a temporary policy." SM comment: This would seem self-evident but hard to object on substance, other than that tinkering with such standard language could raise unnecessary questions, as noted above. Also, see above as to re-opening settled issues. Spec 8: Strike then entire thing and replace it by general language that required provider to process data in accordance with any requirements of applicable law. SM comment: Support Volker here in general, for the same reasons as noted above under 3.5.3.3: Temp Spec language should not be injected into implementation of a consensus policy. Additionally , what is proposed here is so EU-specific as to be irrelevant to Providers to the extent they are not subject to EU jurisdiction. I take it that staff will seek to explain in tomorrow’s meeting why they think Volker’s approach is unacceptable. Am 31.08.2018 um 21:09 schrieb Amy Bivins: Dear Colleagues, Following up on our discussion yesterday, I checked with the Legal team about a couple of items that were discussed. 1. With respect to the proposed edits to the PPAA that are related to data processing (see, e.g. Section 3.5.3 of the contract and the new draft Specification 8), provisions on these topics must be included in this contract, though these can be edited based on your feedback. If you have suggested edits to these new provisions, please send them to the list and we can discuss them on the call next week. If, as discussed yesterday, you believe the inclusion of these provisions raises more fundamental questions about status, in light of the pending ePDP on similar topics, we can also discuss that. As a reminder, the way the PPAA is drafted, any new ICANN Policy that is in conflict with current provisions (GDPR-related or otherwise) would supersede any conflicting provisions in this contract. 2. On the overall timeline, and additional deliverables, any additional GDPR-related changes will be based on IRT feedback. We have a couple of additional discussion topics that we didn’t reach last week, which could require additional PPAA changes. We’ll discuss these next week: a. Are the disclosure frameworks intended to give Providers limited or no discretion on disclosure if other requirements in the framework are met? b. What should requirements be for a Provider’s logging of disclosure requests from third parties? We are continuing to review the contract for any copy-editing related issues, and I expect we will finish with those in the next week or so. I hope this is helpful. Please continue to consider these issues and share any feedback you have on-list. We can pick up on these issues next week. Thanks, and have a great weekend! Amy Amy E. Bivins Registrar Services and Engagement Senior Manager Registrar Services and Industry Relations Internet Corporation for Assigned Names and Numbers (ICANN) Direct: +1 (202) 249-7551 Fax: +1 (202) 789-0104 Email: amy.bivins@icann.org<mailto:amy.bivins@icann.org> www.icann.org<http://www.icann.org> _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl<https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl> -- 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@key-systems.net<mailto:vgreimann@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@key-systems.net<mailto:vgreimann@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. _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl<https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl>
Hi Steve, thank you for your helpful comments.
3.3 -remove in its entirety - we never proposed a public access RDS system by privacy services in the WG. It is also unclear whom the license is supposed to be granted to.
/SM comment: I don’t fully agree with Volker here. While some change to the provision might be needed, this is still useful as a statement of the subset of the data collected by Provider that would be subject to Disclosure, either under one of the Frameworks or otherwise. The reference to interactive, query-based access should be retained to make it clear that those registrars/registries not redacting the data of non-=EU registrations have a license to display it. Perhaps we should also add a reference to the items listed as being subject to Disclosure in accordance with this agreement. /
/The RDS is a registrar/registry obligation, PP services never had such an obligatuion and we also never proposed that. This does not affect the Relay or Disclosure obligations. Happy with replacing it with such a reference, as proposed./
//
3.5.3 Move information requirements to 3.8, unless a specific notice is absolutely required.
/SM comment: Not sure I understand Volker’s proposal here. The data accuracy provisions need to be part of the accreditation agreement (and thus enforceable by ICANN) and not just part of the Terms of Service enforceable by the Provider (though they certainly could be there as well). But I might be missing what Volker is driving at here. /
/My main point is that ensuring data accuracy never is a responsibility of a contracted party, it is the responsibility of the registrant. The contracted party may have an obligation to verify upon receipt of a complaint and to conduct cvertain operations regarding verification and validation, but ultimately the responsibility lies with the registrant and the contracted party may be required to enforce this obligation against the registrant. Therefore the correct place for such notices is the terms of service or the provider. Note that this obligation to provide notice is still enforceable by ICANN. /
//
3.5.3.3 <http://3.5.3.3> Replace by: Provider shall provide appropriate notice to a Customer upon each initial agreement regarding a Registered Name for which Provider is providing the Services. Such a notice should provide all legally required information in accordance with applicable data privacy laws (optional: which may include: 3.5.3.3.1, 3.5.3.3.2, 3.5.3.3.3, 3.5.3.3.4, 3.5.3.3.5, 3.5.3.3.6, 3.5.3.3.9, 3.5.3.3.10, 3.5.3.3.11, 3.5.3.3.13 (add: if applicable), 3.5.3.3.14.)
/SM comment: Support this in principle, this is an example of where it would be inappropriate to import the Temp Spec into implementation of a consensus policy. Furthermore, some of these elements make little sense outside of the EU context, and there will continue to be Providers not subject to the GDPR, at least as to certain non-EU Customers. /
/Agreed. Non-EU registrars with non-EU customers will not be bound by GDPR (but may be bound by the incoming Californian privacy laws, or other such laws elsewhere). Hmm, come to think of it, ICANN is based in California ;-)/
//
3.5.3.4 <http://3.5.3.4> Remove completely, as this is invalid forced consent.
/SM comment: I disagree. I am afraid Volker may be committing the error he has often warned us against of conflating a domain name registration service with the service provided by a P/P provider. In the latter case, the only subject matter of the contract itself involves the collection, processing and disclosure of data, not the provision of any other service, so it may be perfectly acceptable to rely upon consent for the processing activities, even if this legal basis is of less value in the case of a domain name registration service where the processing of e.g. contact data of the registrant is arguably more ancillary to the main point of the contract. /
/Hate to disagree, but forced consent is a no-go under the GDPR. Better base such processing by the provider on the need of processing for providing the service and to conclude a valid agreement./
//
3.5.3.8 <http://3.5.3.8> Remove: Unnecessary as already included in registration agreements. No need for duplication of representation.
/SM comment: Disagree, breach of this representation should be a basis for terminating the p/p service even if the registrar is not enforcing the obligation. In addition, as this provision has been in the draft PPAA since the beginning, and is not impacted by GDPR as far as I can tell, I question why it is being challenged at this point. Surely we should not be reopening issues that has already come to rest over the previous years…. /
/So basically you want the registrant to make the same (implicit) representation twice? Once to the registrar when requesting the registration and once to the privacy service provider? What is the added benefit here?/
//
3.17. add at the end: ...and to the extent permitted under applicable law.
/SM comment: I don’t object to this in principle (and as applicable to Disclosures outside the context of the Disclosure Frameworks) but would defer until we get to discussing the proposed edits to these Disclosure Frameworks. /
/I'd prefer to settle this now and not push issues ahead for later to avoid further delay, but I could live with it./
//
3.18.2 Add: Provider shall not be required to allow transfers to registrars it has no agreement with as long as its data remains in the RDS at the time the transfer is requested.
/SM comment: Would like to hear more about why this addition is needed and what relationship if any it bears to GDPR and its impact on RDS. (See above as to re-opening settled issues.) /
/No relation to RDS, but immense business and liability impact. If registration is move to registrar with privacy data intact and the privacy service has no agreement with that registrar, provider loses control over registration where it still formally is registered name holder. /
//
7.2. Please add data processing equivalency language. Also remove the reference to the "specification in effect".
/SM comment: Not sure what is being proposed here by Volker. /
/Basically, a reference to chatper 5 GDPR without spelling that out, indicating that for disclosure to happen, requester should evidence or represent that requester uses similar/equivalent data protection measures when processing the data, indicating the duration of expected processing, indicating whom the data would be provided to, etc. Required due to corresponding responsibility of provider bound by GDPR to ensure this. And for the specification in effect thing, we could change it to "any specification in effect binding upon providers" or similar. Current wording is too broad. /
//
Spec 2, Remove Sections 1.2.5, 1.3.1,1.3.2, 1.3.3, 1.3.5 - irrelevant for pp services.
/SM comment: True but I assume this is simply the same boilerplate definition of Consensus Policies used in other contexts, and wouldn’t tinkering with it here raise unnecessary questions about whether certain topics are no longer within ICANN’s remit? /
/I would prefer the agreement to be tailored to the services at hand. It is long enough as it is./ Best, Volker
Am 31.08.2018 um 21:09 schrieb Amy Bivins:
Dear Colleagues,
Following up on our discussion yesterday, I checked with the Legal team about a couple of items that were discussed.
1.With respect to the proposed edits to the PPAA that are related to data processing (see, e.g. Section 3.5.3 of the contract and the new draft Specification 8), provisions on these topics must be included in this contract, though these can be edited based on your feedback.
If you have suggested edits to these new provisions, please send them to the list and we can discuss them on the call next week. If, as discussed yesterday, you believe the inclusion of these provisions raises more fundamental questions about status, in light of the pending ePDP on similar topics, we can also discuss that.
As a reminder, the way the PPAA is drafted, any new ICANN Policy that is in conflict with current provisions (GDPR-related or otherwise) would supersede any conflicting provisions in this contract.
2.On the overall timeline, and additional deliverables, any additional GDPR-related changes will be based on IRT feedback. We have a couple of additional discussion topics that we didn’t reach last week, which could require additional PPAA changes. We’ll discuss these next week:
a.Are the disclosure frameworks intended to give Providers limited or no discretion on disclosure if other requirements in the framework are met?
b.What should requirements be for a Provider’s logging of disclosure requests from third parties?
We are continuing to review the contract for any copy-editing related issues, and I expect we will finish with those in the next week or so.
I hope this is helpful. Please continue to consider these issues and share any feedback you have on-list. We can pick up on these issues next week.
Thanks, and have a great weekend!
Amy
*Amy E. Bivins*
Registrar Services and Engagement Senior Manager
Registrar Services and Industry Relations
Internet Corporation for Assigned Names and Numbers (ICANN)
Direct: +1 (202) 249-7551
Fax: +1 (202) 789-0104
Email: amy.bivins@icann.org <mailto:amy.bivins@icann.org>
www.icann.org <http://www.icann.org>
_______________________________________________
Gdd-gnso-ppsai-impl mailing list
Gdd-gnso-ppsai-impl@icann.org <mailto:Gdd-gnso-ppsai-impl@icann.org>
https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
-- 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@key-systems.net <mailto:vgreimann@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@key-systems.net <mailto:vgreimann@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.
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org <mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
_______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl
-- 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@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@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.
100% agree with all of Volker’s comments. I also think at this juncture that there is probably quite a large gap between what the policy was that we worked on, what is being suggested for implementation and neither of them are connected to the legal realities we all live in now. -- Mr Michele Neylon Blacknight Solutions Hosting, Colocation & Domains https://www.blacknight.com/ https://blacknight.blog/ Intl. +353 (0) 59 9183072 Direct Dial: +353 (0)59 9183090 Personal blog: https://michele.blog/ Some thoughts: https://ceo.hosting/ ------------------------------- Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty Road,Graiguecullen,Carlow,R93 X265,Ireland Company No.: 370845 From: Gdd-gnso-ppsai-impl <gdd-gnso-ppsai-impl-bounces@icann.org> on behalf of Volker Greimann <vgreimann@key-systems.net> Reply-To: "gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org> Date: Tuesday 4 September 2018 at 12:53 To: "gdd-gnso-ppsai-impl@icann.org" <gdd-gnso-ppsai-impl@icann.org> Subject: Re: [Gdd-gnso-ppsai-impl] Follow-Up on Yesterday's PP IRT Discussion Hi Amy, re: temporary specification. Privacy/Proxy services are not bound by the current temp spec and will not be bound once accredited as their services are out of scope of the spec: Please review 1.2 of the temp Spec: "1.2. This Temporary Specification applies to all gTLD Registry Operators and ICANN-accredited Registrars." That's it. All additions of clauses based on the temp spec must therefore be removed again before we can go to public comment. Also, here are a few suggested additional edits: 3.2.2 During the Term of this agreement and for one year thereafter - or the maximum duration allowed by applicable law, if shorter - Provider shall ... 3.3 -remove in its entirety - we never proposed a public access RDS system by privacy services in the WG. It is also unclear whom the license is supposed to be granted to. 3.4. Add: This requirement is void if the data described in Sections [3.3.1 through 3.3.4] is already being escrowed by the sponsoring registrar. 3.5.3 Move information requirements to 3.8, unless a specific notice is absolutely required. 3.5.3.3 Replace by: Provider shall provide appropriate notice to a Customer upon each initial agreement regarding a Registered Name for which Provider is providing the Services. Such a notice should provide all legally required information in accordance with applicable data privacy laws (optional: which may include: 3.5.3.3.1, 3.5.3.3.2, 3.5.3.3.3, 3.5.3.3.4, 3.5.3.3.5, 3.5.3.3.6, 3.5.3.3.9, 3.5.3.3.10, 3.5.3.3.11, 3.5.3.3.13 (add: if applicable), 3.5.3.3.14.) 3.5.3.4: Remove completely, as this is invalid forced consent. 3.5.3.8 Remove: Unnecessary as already included in registration agreements. No need for duplication of representation. 3.6.1 change $4,000 to $400 3.17. add at the end: ...and to the extent permitted under applicable law. 3.18.2 Add: Provider shall not be required to allow transfers to registrars it has no agreement with as long as its data remains in the RDS at the time the transfer is requested. 7.2. Please add data processing equivalency language. Also remove the reference to the "specification in effect". Spec 2, Remove Sections 1.2.5, 1.3.1,1.3.2, 1.3.3, 1.3.5 - irrelevant for pp services. under Section 2 add: "...provided the Provider and the services provided by it are in scope of such a temporary policy." Spec 8: Strike then entire thing and replace it by general language that required provider to process data in accordance with any requirements of applicable law. Am 31.08.2018 um 21:09 schrieb Amy Bivins: Dear Colleagues, Following up on our discussion yesterday, I checked with the Legal team about a couple of items that were discussed. 1. With respect to the proposed edits to the PPAA that are related to data processing (see, e.g. Section 3.5.3 of the contract and the new draft Specification 8), provisions on these topics must be included in this contract, though these can be edited based on your feedback. If you have suggested edits to these new provisions, please send them to the list and we can discuss them on the call next week. If, as discussed yesterday, you believe the inclusion of these provisions raises more fundamental questions about status, in light of the pending ePDP on similar topics, we can also discuss that. As a reminder, the way the PPAA is drafted, any new ICANN Policy that is in conflict with current provisions (GDPR-related or otherwise) would supersede any conflicting provisions in this contract. 1. On the overall timeline, and additional deliverables, any additional GDPR-related changes will be based on IRT feedback. We have a couple of additional discussion topics that we didn’t reach last week, which could require additional PPAA changes. We’ll discuss these next week: a. Are the disclosure frameworks intended to give Providers limited or no discretion on disclosure if other requirements in the framework are met? b. What should requirements be for a Provider’s logging of disclosure requests from third parties? We are continuing to review the contract for any copy-editing related issues, and I expect we will finish with those in the next week or so. I hope this is helpful. Please continue to consider these issues and share any feedback you have on-list. We can pick up on these issues next week. Thanks, and have a great weekend! Amy Amy E. Bivins Registrar Services and Engagement Senior Manager Registrar Services and Industry Relations Internet Corporation for Assigned Names and Numbers (ICANN) Direct: +1 (202) 249-7551 Fax: +1 (202) 789-0104 Email: amy.bivins@icann.org<mailto:amy.bivins@icann.org> www.icann.org<http://www.icann.org> _______________________________________________ Gdd-gnso-ppsai-impl mailing list Gdd-gnso-ppsai-impl@icann.org<mailto:Gdd-gnso-ppsai-impl@icann.org> https://mm.icann.org/mailman/listinfo/gdd-gnso-ppsai-impl -- 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@key-systems.net<mailto:vgreimann@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@key-systems.net<mailto:vgreimann@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.
participants (8)
-
Amy Bivins -
Chris Pelling -
Eric Rokobauer -
gtheo -
Metalitz, Steven -
Michele Neylon - Blacknight -
Sara Bockey -
Volker Greimann