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

Fri Feb 8 09:21:25 UTC 2019

 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 at 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 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 <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>
>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190208/38659bd3/attachment.html>