[Gnso-epdp-team] Proposed path for additional topics flagged

[Amr Elsadr]

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 at 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 at 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_gnso&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=7_PQAir-9nJQ2uB2cWiTDDDo5Hfy5HL9rSTe65iXLVM&m=5DXgId95wrCsHi--pxTiJD7bMB9r-T5ytCn7od3CF2Q&s=Cg5uQf0yAfw-qlFZ0WNBfsLmmtBNUiH0SuI6Vg-gXBQ&e=) and visiting the [GNSO Newcomer pages](https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_sites_gnso.icann.org_files_gnso_presentations_policy-2Defforts.htm-23newcomers&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=7_PQAir-9nJQ2uB2cWiTDDDo5Hfy5HL9rSTe65iXLVM&m=5DXgId95wrCsHi--pxTiJD7bMB9r-T5ytCn7od3CF2Q&s=tT-E2RoAucUb3pfL9zmlbRdq1sytaEf765KOEkBVCjk&e=).
>
> <Issues flagged for discussion - 6 Feb 2019.docx>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190207/80db1c8e/attachment-0001.html>