Amr, I'm going to consider your point regarding the Consensus policies, but I will give a hard disagreement on your point regarding dropping the Ry T&Cs. The collection of the RNH data (noting data as the minimum data set for Purpose 1(b) only and thus for the purposes of 1 b only) for the registrar is 6(1)b. This is because it negates the balancing test, and is necessary to fulfill the contract that they have for the registration of a domain. The collection is 'necessary' as we are agreeing that the RRA and by extension the RAs require the collection of the data for the purpose of the registration of a domain name, and for the application of both registrar T&Cs and the Registry T&Cs. Both are legitimate business needs. Re Article 6 (1) - the issue with the way the workbooks were designed is that it assumes that the registry collection and the registrar collection are the same thing. They are not. The transfer of the data under 1(b) to the registry is under 6(1)b (or F if ta registrar want) - but it is a processing action of the registrar The collection of the data by the Registry (as a result of the transfer from the registrar) is 6(1)f (vis a vis) the registry. The Registry Terms and Conditions are, by the terms of the RRA, to be passed on in the registration agreement. It is necessary for the registrar to pass them on, not to incorporate them as that registrar's T&Cs (although some also choose to do so), but that you specifically accept the T&Cs of the registry operator to register X domain. So it is incorrect that it is only the Rr T&Cs apply, both the Rr's T&Cs as applied by the Rr (of your choice) and the Ry (of your choice insofar as you choose that TLD) apply to the registrant's use and benefit of that domain. Both may be applied by the registrar (as we, as a matter of courtesy and indeed to not affect as much as possible, the contractual relationship between the Rr and the RNH, we prefer the registrar to have the contact with the registrant) but not all registrars are 'responsive' (and noting we have no real discretion in accepting registrars who meet the onboarding requirements). the registry must retain the that ability (which is vital) to apply its own T&Cs, as is expected by the RRA (and the transfer is objectively quite legitimate for that purpose). Still haven't gotten around to contemplating your other point, but this email is already too long! :) Alan [image: Donuts Inc.] <http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ------------------------------ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://www.facebook.com/donutstlds> <https://twitter.com/DonutsInc> <https://www.linkedin.com/company/donuts-inc> Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you. On Thu, Feb 7, 2019 at 1:00 PM Amr Elsadr <aelsadr@icannpolicy.ninja> wrote:

Hi,

Gratitude to the leadership team and staff support team for providing this. I’ve fallen behind, and am still catching up, on several email threads, and found the document Marika circulated to be very helpful. In the meantime, if my comments below are part of discussions that have moved on, my apologies, but I figured I’d share them anyway.

Two of the listed topics stood out to me, and I would appreciate further discussion on each of them:

1. On recommendation 9 (Org field), specifically, the highlighted text provided by the BC saying:

"After the implementation phase-in period, the ORG FIELD will no longer be REDACTED by either the registry or registrar."

I’m not exactly clear on where this text would be placed, or under what conditions the BC is requesting that the Org field not be redacted. The condition for publication of this field is already clearly included in the draft final report, so am curious whether this is referring to the same condition (if so, isn’t it redundant?) or a different one that I am not aware of. Clarification on this would be very much appreciated.

2. On recommendation 1, purpose b, I’m uncomfortable with the proposed addition of *“and relevant registry agreements and registrar accreditation agreements”* to this purpose. In fact, I’m also uncomfortable with the addition of *ICANN Consensus Policies* to this purpose as well.

The EPDP Team agreed on Article 61b as the lawful basis for A-PA1 (collection of registration data) in this purpose, due to the contractual relationship between the RNH and the registrar, and the need to perform this processing activity to fulfill the contract. To me, this requires the agreement between the registrar and RNH to be the only authoritative agreement/policy/terms & conditions (take your pick) determining what the rights of the RNH are established concerning a registered name, as well as ensuring that the RNH may exercise those rights. This is from the RNH/data subject perspective, of course.

Adding relevant RA, RAA or ICANN Consensus Policies to this purpose suggests that if any of these conflict with the agreement between the registrar and RNH exist, those rights, and the ability of the RNH to exercise them might be in question. This should not be the case.

Of course, these conflicts should not exist either. However, taking into account the time it takes to implement Consensus Policies, the time between developing Consensus Policy language, making the necessary changes to RAs and the RAA and reaching policy effective dates may create time-limited inconsistencies between them and the agreements between registrars and RNHs. In situations like this, it does not strike me as reasonable to hold RNHs accountable to policies and agreements to which it is not a party to, and the legal basis (using 61b) for collecting the registration data under A-PA1 would not be applicable.

These inconsistencies might be mitigated by including references to ICANN Consensus Policies and the RAA in the registrar/RNH agreement, but even in this situation, it is still this agreement that remains the authoritative one in determining the RNH rights. Furthermore, absent a direct agreement between the RNH and the registry operating the applicable gTLD, the same could be argued for registry terms, conditions and policies, which should be relayed to the RNH by its chosen registrar.

I would prefer if we strike any mention of the RA, the RAA or ICANN Consensus Policies as well as Registry terms conditions and policies from purpose 1b, and only keep the reference to the Registrar terms, conditions and policies.

Thanks.

Amr

On Feb 6, 2019, at 7:20 PM, Marika Konings <marika.konings@icann.org> wrote:

Dear EPDP Team,

The leadership team has reviewed the additional topics that were put forward for EPDP Team consideration by the deadline and has suggested a path forward in the attached document. Please do have a look to make sure that you are comfortable with the proposed path forward and confirm that it aligns with the EPDP Team discussions to date. We would like to especially draw your attention item 3 (optional tech contact), item 6 (redaction) and item 11 (purpose 1). If your group is not comfortable with the proposed path forward for any of the topics in the table, please flag this as soon as possible, preferably prior to tomorrow’s meeting so it can be added to the agenda for tomorrow’s meeting, but no later than *Thursday 7 February COB*.

Best regards,

Caitlin, Berry and Marika

*Marika Konings* *Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) * *Email: marika.konings@icann.org <marika.konings@icann.org> *

*Follow the GNSO via Twitter @ICANN_GNSO* *Find out more about the GNSO by taking our interactive courses <https://urldefense.proofpoint.com/v2/url?u=http-3A__learn.icann.org_courses_...> and visiting the GNSO Newcomer pages <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gns...>. *

<Issues flagged for discussion - 6 Feb 2019.docx>

_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team

Dear Marika, I understand and appreciate very much all you good works However, acceptance it otherwise of a text is a matter to be decided by Kurt and then by the team Please kindly confier the separation of responsibilities of the Team and it’s chair and that of the supporting secretariat Regards Kavouss Sent from my iPhone

On 9 Feb 2019, at 15:12, Marika Konings <marika.konings@icann.org> wrote:

FYI, noting the concerns expressed in relation to the proposed change to purpose 1, no updates were made in the latest version of the Final Report so the original language as agreed (and put forward in the consensus call) remains.

Best regards,

Caitlin, Berry and Marika

From: Alan Woods <alan@donuts.email> Date: Friday, February 8, 2019 at 03:23 To: Amr Elsadr <aelsadr@icannpolicy.ninja> Cc: Marika Konings <marika.konings@icann.org>, "gnso-epdp-team@icann.org" <gnso-epdp-team@icann.org> Subject: [Ext] Re: [Gnso-epdp-team] Proposed path for additional topics flagged

Amr,

I'm going to consider your point regarding the Consensus policies, but I will give a hard disagreement on your point regarding dropping the Ry T&Cs.

The collection of the RNH data (noting data as the minimum data set for Purpose 1(b) only and thus for the purposes of 1 b only) for the registrar is 6(1)b. This is because it negates the balancing test, and is necessary to fulfill the contract that they have for the registration of a domain. The collection is 'necessary' as we are agreeing that the RRA and by extension the RAs require the collection of the data for the purpose of the registration of a domain name, and for the application of both registrar T&Cs and the Registry T&Cs. Both are legitimate business needs.

Re Article 6 (1) - the issue with the way the workbooks were designed is that it assumes that the registry collection and the registrar collection are the same thing. They are not.

The transfer of the data under 1(b) to the registry is under 6(1)b (or F if ta registrar want) - but it is a processing action of the registrar The collection of the data by the Registry (as a result of the transfer from the registrar) is 6(1)f (vis a vis) the registry.

The Registry Terms and Conditions are, by the terms of the RRA, to be passed on in the registration agreement. It is necessary for the registrar to pass them on, not to incorporate them as that registrar's T&Cs (although some also choose to do so), but that you specifically accept the T&Cs of the registry operator to register X domain. So it is incorrect that it is only the Rr T&Cs apply, both the Rr's T&Cs as applied by the Rr (of your choice) and the Ry (of your choice insofar as you choose that TLD) apply to the registrant's use and benefit of that domain. Both may be applied by the registrar (as we, as a matter of courtesy and indeed to not affect as much as possible, the contractual relationship between the Rr and the RNH, we prefer the registrar to have the contact with the registrant) but not all registrars are 'responsive' (and noting we have no real discretion in accepting registrars who meet the onboarding requirements). the registry must retain the that ability (which is vital) to apply its own T&Cs, as is expected by the RRA (and the transfer is objectively quite legitimate for that purpose).

Still haven't gotten around to contemplating your other point, but this email is already too long! :)

Alan

[donuts.domains]

Alan Woods

Senior Compliance & Policy Manager, Donuts Inc.

The Victorians,

15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland

[facebook.com] [twitter.com] [linkedin.com]

Please NOTE: This electronic message, including any attachments, may include privileged, confidential and/or inside information owned by Donuts Inc. . Any distribution or use of this communication by anyone other than the intended recipient(s) is strictly prohibited and may be unlawful. If you are not the intended recipient, please notify the sender by replying to this message and then delete it from your system. Thank you.

On Thu, Feb 7, 2019 at 1:00 PM Amr Elsadr <aelsadr@icannpolicy.ninja> wrote: Hi,

Gratitude to the leadership team and staff support team for providing this. I’ve fallen behind, and am still catching up, on several email threads, and found the document Marika circulated to be very helpful. In the meantime, if my comments below are part of discussions that have moved on, my apologies, but I figured I’d share them anyway.

Two of the listed topics stood out to me, and I would appreciate further discussion on each of them:

1. On recommendation 9 (Org field), specifically, the highlighted text provided by the BC saying:

"After the implementation phase-in period, the ORG FIELD will no longer be REDACTED by either the registry or registrar."

I’m not exactly clear on where this text would be placed, or under what conditions the BC is requesting that the Org field not be redacted. The condition for publication of this field is already clearly included in the draft final report, so am curious whether this is referring to the same condition (if so, isn’t it redundant?) or a different one that I am not aware of. Clarification on this would be very much appreciated.

2. On recommendation 1, purpose b, I’m uncomfortable with the proposed addition of “and relevant registry agreements and registrar accreditation agreements” to this purpose. In fact, I’m also uncomfortable with the addition of ICANN Consensus Policies to this purpose as well.

The EPDP Team agreed on Article 61b as the lawful basis for A-PA1 (collection of registration data) in this purpose, due to the contractual relationship between the RNH and the registrar, and the need to perform this processing activity to fulfill the contract. To me, this requires the agreement between the registrar and RNH to be the only authoritative agreement/policy/terms & conditions (take your pick) determining what the rights of the RNH are established concerning a registered name, as well as ensuring that the RNH may exercise those rights. This is from the RNH/data subject perspective, of course.

Adding relevant RA, RAA or ICANN Consensus Policies to this purpose suggests that if any of these conflict with the agreement between the registrar and RNH exist, those rights, and the ability of the RNH to exercise them might be in question. This should not be the case.

Of course, these conflicts should not exist either. However, taking into account the time it takes to implement Consensus Policies, the time between developing Consensus Policy language, making the necessary changes to RAs and the RAA and reaching policy effective dates may create time-limited inconsistencies between them and the agreements between registrars and RNHs. In situations like this, it does not strike me as reasonable to hold RNHs accountable to policies and agreements to which it is not a party to, and the legal basis (using 61b) for collecting the registration data under A-PA1 would not be applicable.

These inconsistencies might be mitigated by including references to ICANN Consensus Policies and the RAA in the registrar/RNH agreement, but even in this situation, it is still this agreement that remains the authoritative one in determining the RNH rights. Furthermore, absent a direct agreement between the RNH and the registry operating the applicable gTLD, the same could be argued for registry terms, conditions and policies, which should be relayed to the RNH by its chosen registrar.

I would prefer if we strike any mention of the RA, the RAA or ICANN Consensus Policies as well as Registry terms conditions and policies from purpose 1b, and only keep the reference to the Registrar terms, conditions and policies.

Thanks.

Amr

On Feb 6, 2019, at 7:20 PM, Marika Konings <marika.konings@icann.org> wrote:

Dear EPDP Team,

The leadership team has reviewed the additional topics that were put forward for EPDP Team consideration by the deadline and has suggested a path forward in the attached document. Please do have a look to make sure that you are comfortable with the proposed path forward and confirm that it aligns with the EPDP Team discussions to date. We would like to especially draw your attention item 3 (optional tech contact), item 6 (redaction) and item 11 (purpose 1). If your group is not comfortable with the proposed path forward for any of the topics in the table, please flag this as soon as possible, preferably prior to tomorrow’s meeting so it can be added to the agenda for tomorrow’s meeting, but no later than Thursday 7 February COB.

Best regards,

Caitlin, Berry and Marika

Marika Konings Vice President, Policy Development Support – GNSO, Internet Corporation for Assigned Names and Numbers (ICANN) Email: marika.konings@icann.org

Follow the GNSO via Twitter @ICANN_GNSO Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages.

<Issues flagged for discussion - 6 Feb 2019.docx>

_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team