[IRT.RegDataPolicy] IRT Liaison report on Rec7 during the 20Aug2020 GNSO Council Meeting
Alex Deacon
alex at colevalleyconsulting.com
Wed Sep 9 20:17:16 UTC 2020
Hi Amr,
A quick response to your email.
Agree with Sarah (and Roger) on this. The Consensus Policy language that is
> being drafted needs to be consistent with the intent of the policy
> recommendation, and the intent is quite clear in that 2 conditions must be
> met prior to transfer of Registration Data from a Registrar to a Registry
> may occur. I don’t understand why this is even up for debate.
Because adding that language directly contradicts the Thick WHOIS
consensus policy (it turns a requirement to transfer into an option to
transfer). As you clearly state the IRT is not empowered to amend policy
recommendations adopted by the GNSO Council and the ICANN Board, so we
should really stop trying to do this.
Alex
___________
*Alex Deacon*
Cole Valley Consulting
alex at colevalleyconsulting.com
+1.415.488.6009
On Wed, Sep 9, 2020 at 12:28 PM Amr Elsadr <aelsadr at icannpolicy.ninja>
wrote:
> Hi,
>
> Agree with Sarah (and Roger) on this. The Consensus Policy language that
> is being drafted needs to be consistent with the intent of the policy
> recommendation, and the intent is quite clear in that 2 conditions must be
> met prior to transfer of Registration Data from a Registrar to a Registry
> may occur. I don’t understand why this is even up for debate. The IRT is
> not empowered to amend policy recommendations adopted by the GNSO Council
> and the ICANN Board, so we should really stop trying to do this.
>
> The language Roger proposed is clearly consistent with the language in the
> policy recommendation, and the level of detail in it is quite sufficient to
> address how each data element is meant to be dealt with as per the Phase 1
> Final Report.
>
> To suggest that this language may be dropped because B&B said that a legal
> basis does exist is incorrect. The obligations that Contracted Parties must
> comply with are determined by the Consensus Policy language, not by legal
> memos from B&B. Those memos were only meant to provide legal advice to the
> EPDP Team during the course of it developing policy recommendations.
>
> On a more substantive and separate issue, legal advice from B&B is only
> one reference on the legal status of transfer of data across jurisdictions.
> If Contracted Parties are going to implement the Registration Data Policy,
> they need to be sure (to the extent possible) that they are compliant with
> GDPR. If the Schrems II case as well as input provided by the IWGDPT to
> ICANN provide additional clarity on how to do this, then there’s no reason
> to ignore them.
>
> To me, there seems to be a couple of instances where the advice from B&B
> is consistent with the other two references, but some instances where there
> may be conflict. All the advice is in agreement that a legal basis must
> exist, and that commensurate measures (including a data processing
> agreement, for example) must be in place in order to address the increased
> security risks resulting from transfer and duplication of Registration Data
> records resulting from the “thick” whois policy.
>
> Where the B&B memo is different is they claim the policy itself provides a
> suitable legal basis, which is justified by benefits yielded as a result of
> “thick” whois. The IWGDPT, on the other hand, says that the transfer of
> data from Registrars to Registries should be justified by a technical
> necessity to do so, not a convenience. Otherwise, it recommends that the
> data stays put.
>
> These may not be issues for this IRT to resolve, but either way, it
> doesn’t impact what must be included in the Consensus Policy language. The
> rules for that are significantly clearer than interpretation of data
> protection regulation, and not open to debate.
>
> Thanks.
>
> Amr
>
> On Sep 9, 2020, at 8:10 PM, Sarah Wyld <swyld at tucows.com> wrote:
>
> Hello team,
> I'd like us to return to Roger's initial email, which I think had some
> very valuable points in it that have been a bit passed over. I've attached
> it here for reference (hope it comes through).
> Recommendation #7 says the data "must be transferred from registrar to
> registry provided an appropriate legal basis exists and data processing
> agreement is in place."
> Whether the Thick Whois Transition Policy is itself the grounds for a
> legitimate interest in the data or not is beside the point; our duty in
> this IRT is to implement the recommendations, and omitting that language
> from the final Policy would mean we lose requirements which the Phase 1
> EPDP team found important enough to specifically include in the
> recommendation.
> If a Registry's implementation of the Thick Whois Transition Policy is
> such that all the data elements listed in Rec 7 are required, then that's
> fine as long as the registry provides an appropriate data processing
> agreement to the registrar. But it's not appropriate for us as the IRT to
> modify the Policy by removing this requirement.
> Thank you,
> Sarah
>
>
> --
> Sarah Wyld
> Domains Product Team
> Tucows
> +1.416 535 0123 Ext. 1392
>
>
>
> On 9/9/2020 12:21 PM, King, Brian via IRT.RegDataPolicy wrote:
>
> Thanks, Stephanie.
>
> Yes, whether a registry is in the US or on the moon, SCCs are a lawful way
> to transfer data out of Europe. Ironically the “problem” as you say is
> actually part of the solution to reconciling Thick WHOIS with the Phase 1
> policy since they address concerns raised about cross-border data transfer.
>
>
> To your final point below, the Bird & Bird legal advice was obtained
> post-GDPR, so we don’t need to rely on legal advice received during the
> Thick WHOIS PDP.
>
> Since we have legal advice confirming that a legal basis exists, and we
> have identified a lawful way of transferring Thick WHOIS data across
> borders, it seems there are no further reasonable concerns requiring the
> conditional language in Rec 7, and we can proceed with the language
> suggested by Staff.
>
> *Brian J. King*
> Director of Internet Policy and Industry Affairs, IP Group
>
> T +1 443 761 3726
> *clarivate.com <http://clarivate.com/>*
>
> *From:* Stephanie E Perrin <stephanie at digitaldiscretion.ca>
> <stephanie at digitaldiscretion.ca>
> *Sent:* Wednesday, September 9, 2020 10:59 AM
> *To:* King, Brian <Brian.King at markmonitor.com>
> <Brian.King at markmonitor.com>; irt.regdatapolicy at icann.org
> *Subject:* Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
> I am aware. However, lets be clear. Verisign is the gorilla in this
> room. Are they not in the US? I will not belabor the competition issues
> that underlined the whole thick thin decision so many years ago (which
> still in my view persist and justify keeping Verisgn thin) but we are
> talking here about a US transfer, in the main.
> SCCs are another matter, as Schrems himself says. Another problem for
> another day.
> Finally, the legal advice that the Thick PDP received in my view was
> woefully off base. We should not, in all conscience, point to that
> decision, based on that advice.
> Cheers
> SP
> On 2020-09-09 9:59 a.m., King, Brian wrote:
>
> Hi Stephanie and team,
>
> In their memo, Bird & Bird cites to at least the Thick WHOIS Final Report
> and the ICANN Board Resolution adopting it, both of which contain the
> rationale for implementing Thick WHOIS.
>
> To be clear, Schrems II is a red herring. EU/US Privacy Shield never
> covered data transfer from EU-based registrars to registries in any non-US
> jurisdiction, and was never going to be the solution for Thick WHOIS data
> transfer. A different lawful transfer mechanism has always been required,
> using standard contractual clauses (SCCs) for example (
> https://ec.europa.eu/info/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__ec.europa.eu_info_law_law-2Dtopic_data-2Dprotection_international-2Ddimension-2Ddata-2Dprotection_standard-2Dcontractual-2Dclauses-2Dscc-5Fen&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=B26njLf88JPq19QisV3W53Gh6cbitmWV2kzdPgYBJHk&s=iVYMueKcIMHA9fqRenrlrbjwG-g8OaYfkr5kbUOZ5FU&e=>
> ).
>
> Without giving legal advice, this is a big part of why ICANN facilitated a
> standardized RRA Amendment to cover data processing between registries and
> registrars:
> https://www.icann.org/resources/pages/rra-amendment-procedure-gtld-registration-data-specs-2018-07-02-en
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_pages_rra-2Damendment-2Dprocedure-2Dgtld-2Dregistration-2Ddata-2Dspecs-2D2018-2D07-2D02-2Den&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=B26njLf88JPq19QisV3W53Gh6cbitmWV2kzdPgYBJHk&s=ioTrFnFrIDEn79jdeB5UNI9A4XFo5t65Ml60irHgt3Y&e=>.
> Those familiar with SCCs will find the language in the RRA Amendment
> template very familiar.
>
> *Brian J. King*
> Director of Internet Policy and Industry Affairs, IP Group
>
> T +1 443 761 3726
> *clarivate.com <http://clarivate.com/>*
>
>
> *From:* IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org>
> <irt.regdatapolicy-bounces at icann.org> *On Behalf Of *Stephanie E Perrin
> *Sent:* Tuesday, September 8, 2020 6:26 PM
> *To:* irt.regdatapolicy at icann.org
> *Subject:* Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
> The Bird and Bird opinion as to the legal basis of the transfer of the
> data to the registry under the thick policy is very curious. I wonder if
> someone can point me to the briefing material that they received on the
> rational for the Thick WHois policy, and the previous "thin Policy".
> I completely agree with Theo that post Schrems II, the transfer of
> personal data to the registry without a technical reason to do so is
> difficult to justify.
> Stephanie Perrin
>
> On 2020-09-08 3:35 p.m., Theo Geurts wrote:
>
> As long the IWGDPT does not change their opinion of the below.
> And taking in account the Schrems II decision ie no more privacy shield
> (which was not taken into account by B&B) and NOW should be taken into
> account, a legal basis is required and by the logic of Brian we can simply
> agree that we leave the recommendation approved by the board as is and
> include a legal basis. If this things ends at the DPA's I rather side with
> the opinion of the IWGDPT (the DPA's of this world) than rely my legal
> basis of B&B where I could not consult on.
> Oh two pointers , adequacy standard, well as it is now, the USA will not
> reach that standard unless things will change a lot in favor of data
> protection. And the technology to permit the data to remain in the
> jurisdiction of the registrar, well we have that for decades now and RDAP
> even makes things easier..
>
> *ICANN should explicitly address the issue of transborder dataflow in its
> policies, and ensure that data transfers ensure adequate data protection is
> maintained. 19 2013 Registrar Accreditation
> Agreement, https://www.icann.org/resources/pages/approved-withspecs-2013-09-17-en
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_pages_approved-2Dwithspecs-2D2013-2D09-2D17-2Den&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ksGqw06mx_8tgEzKe_n3S7oqAZSXndVQSnz8Y-V60vs&s=QyAr_YqzyezwNSZCrb5yOmtXQ7c1xAMot81z4Lf40GA&e=> -
> 9 - The issue of where the data is held has not been a subject of previous
> commentary from the IWGDPT. It is the understanding of the IWGDPT that
> under the recently completed new policy known as “Thick WHOIS”, registrars
> who formerly maintained the data of gTLD registrants themselves and
> provided WHOIS access through port 43, are now transferring the data to the
> registries, including the big registries such as .com, .net, and others.
> This represents 75% of the gTLD registrations, which means there will be
> significant transfers of personal data to the United States, where, for
> instance, the largest registry operator Verisign holds its data. It is
> important that data be protected in a manner that ensures continuous
> protection to the “adequacy” standard, and that registrants are aware of
> this transfer. If technology permits the data to remain in the jurisdiction
> of the registrant or registrar, we would recommend limiting dataflows to
> only those which are absolutely necessary. *
> Thanks,
> Theo
> Op 8-9-2020 om 19:18 schreef King, Brian via IRT.RegDataPolicy:
>
> Hi all,
>
> If it helps to break the tie here, Bird & Bird confirmed that a legal
> basis exists.
> https://community.icann.org/download/attachments/102138857/ICANN%20-%20Memo%20on%20thick%20Whois%5B1%5D.docx?version=1&modificationDate=1552176734000&api=v2
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_download_attachments_102138857_ICANN-2520-2D-2520Memo-2520on-2520thick-2520Whois-255B1-255D.docx-3Fversion-3D1-26modificationDate-3D1552176734000-26api-3Dv2&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ksGqw06mx_8tgEzKe_n3S7oqAZSXndVQSnz8Y-V60vs&s=EwHaGp_32rcjqSp00faUarwmCiR8S32uNt6tZZM2xw0&e=>
>
> Summarizing that memo for our purposes, there is a 6.1.f. legal basis for
> thick WHOIS. Full stop. They were neither dubious nor ambiguous about it,
> even by lawyer standards.
>
> Bird & Bird concluded that there is a legitimate interest, the data is
> necessary for those purposes, and the impact to the data subject is
> negligible. So, they concluded that there is a legal basis under 6.1.f.
>
> The language “provided an appropriate legal basis exists” is not necessary
> because Bird & Bird assures us that a legal basis exists.
>
> *Brian J. King*
> Director of Internet Policy and Industry Affairs, IP Group
>
> T +1 443 761 3726
> *clarivate.com <http://clarivate.com/>*
> <image001.jpg>
>
> *From:* IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org>
> <irt.regdatapolicy-bounces at icann.org> *On Behalf Of *Roger D Carney
> *Sent:* Friday, September 4, 2020 3:38 PM
> *To:* irt.regdatapolicy at icann.org
> *Subject:* Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
> Good Afternoon,
>
> Thanks Alex, no worries about the name, I always blame that other Rodger
> for anything that goes wrong:).
>
> So, for clarity, you are not against using the language from
> recommendation 7?
>
> What you are suggesting is adding additional language, is that correct?
>
> I am a bit confused by your assertion that "...without agreement that
> legal basis exists in all cases then the IRT explicitly kills Thick
> WHOIS...". I cannot figure out how to connect the dots from "...without
> agreement that legal basis exists in all cases..." to the "...IRT
> explicitly kills Thick WHOIS...", as this has never been the case. The
> Thick WHOIS Policy (all Consensus Policies) are always dependent on legal
> basis and within the Thick Policy it even recognized possible conflicts
> with law. Consensus Policy is just one consideration and not the deciding
> consideration, CPs must follow the law and then follow Policy as it can
> within that legal framework.
>
> I am surprised that the idea that "legal basis exists in all cases" is
> even a thought as this has been known not to be true for a long time.
> Consensus Policy cannot determine legal basis and should never strive to,
> that should be purposefully left outside of policy which is why the
> Registration Data Policy cannot state "...legal basis exists in all
> cases...".
>
> I think we all agree that The Thick WHOIS Policy is a Consensus Policy
> today (even with full implementation yet to be realized as final
> implementation details/actions are awaiting "*the GNSO Council makes a
> determination on whether to take action on updates to relevant policies and
> procedures (which could include additional policy work, guidance, or other
> actions to be determined) impacting the Thick WHOIS Transition Policy*").
> I think we also all agree that Phase 1 Recommendations did modify the Thick
> WHOIS Policy but did not overturn it entirely. So, unless there is a GNSO
> Policy Development Process that eliminates the Thick WHOIS Policy than all
> CPs will need to abide by that Policy, but obviously in context of their
> respective legal frameworks, which I believe is what the Recommendation 7
> language correctly allows for and this suggested new language does not.
>
> Have a great weekend (holiday weekend for some), talk to you all next week!
>
>
> Thanks
> Roger
>
>
> ------------------------------
> *From:* Alex Deacon <alex at colevalleyconsulting.com>
> <alex at colevalleyconsulting.com>
> *Sent:* Thursday, September 3, 2020 6:35 PM
> *To:* Alex Deacon <alex at colevalleyconsulting.com>
> <alex at colevalleyconsulting.com>
> *Cc:* Roger D Carney <rcarney at godaddy.com> <rcarney at godaddy.com>;
> irt.regdatapolicy at icann.org <irt.regdatapolicy at icann.org>
> <irt.regdatapolicy at icann.org>
> *Subject:* Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
> Notice: This email is from an external sender.
>
> sorry - Roger, not Rodger!
> ___________
> *Alex Deacon*
> Cole Valley Consulting
> alex at colevalleyconsulting.com
> +1.415.488.6009
>
>
>
> On Thu, Sep 3, 2020 at 4:30 PM Alex Deacon <alex at colevalleyconsulting.com>
> wrote:
>
> Rodger,
>
> Sure - but If we use the language in the recommendation ("provided a legal
> basis exists") *without* an indication or agreement that a legal basis
> exists in all cases then the IRT explicitly "kills" Thick WHOIS - which is
> also consensus policy approved by the interior community including the GNSO
> and ICANN Board. So....
>
> Alex
>
>
> ___________
> *Alex Deacon*
> Cole Valley Consulting
> alex at colevalleyconsulting.com
> +1.415.488.6009
>
>
>
> On Thu, Sep 3, 2020 at 4:07 PM Roger D Carney <rcarney at godaddy.com> wrote:
>
> Good Evening,
>
> Thanks Alex. I agree that some people are over thinking this and I believe
> stepping beyond the scope of the IRT.
>
> I will disagree with you on the "wishy-washy language". What I suggested
> is to use the exact wording from the recommendation which was approved by
> the entire community including the GNSO and ICANN Board. By using the
> proposed language from staff (and not using the language from the
> recommendation) it is clear that Policy is being created outside of the
> Policy Development Process.
>
> Can someone provide logic/reasoning why this IRT would not use the
> language from the recommendation? The only argument I have heard is that
> some believe that the "...legal basis..." already exists. But that is not a
> reason for Policy language modification, that is a reason for compliance.
> Using the language from the recommendation does not hinder this compliance
> argument.
>
> If we remove this language, the IRT has created new policy. We have
> discussed and changed (and documented the reasons for the change) other
> recommendation language based on typos, unintentional drafting errors, and
> intent. But it is clear that this recommendation is correct in language and
> intent, everyone agrees that "...legal basis..." must exist, I have not
> heard anyone argue against that, so once again: Why not use the language
> from the recommendation?
>
>
> Thanks
> Roger
>
>
> ------------------------------
> *From:* Alex Deacon <alex at colevalleyconsulting.com>
> *Sent:* Thursday, September 3, 2020 5:22 PM
> *To:* Roger D Carney <rcarney at godaddy.com>
> *Cc:* irt.regdatapolicy at icann.org <irt.regdatapolicy at icann.org>
> *Subject:* Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
> Notice: This email is from an external sender.
>
> We seem to be over thinking this - or perhaps hoping to find a solution in
> the vague, wishy-washy and open-to-broad-interpretation language in the
> policy.
>
> As we discussed this all comes down to legal basis.
>
> Scenario One
> · A legal basis exists for the transfer of Thick WHOIS data from
> registrars to registries in all cases. This satisfies the "provided an
> appropriate legal basis exists" condition of Rec #7.
> · A DPA is drafted that supports and details this transfer. This
> satisfies the "data process agreement is in place" clause of Rec #7
> · The OneDoc details which data elements MUST be transferred.
> · Rec #7 is satisfied per policy and the Thick WHOIS consensus
> policy stands. There is no impasse/conflict.
> Scenario Two
> · A legal basis does not exist for the transfer of Thick WHOIS
> data from registrars to registries - for any case. The "provided an
> appropriate legal basis exists" condition is not met.
> · The IRT has just killed the Thick WHOIS consensus policy.
> I suppose there may be a Scenario Three where a legal basis exists in only
> some cases. But either way this scenario would also kill the Thick WHOIS
> consensus policy.
>
>
> Alex
>
>
> ___________
> *Alex Deacon*
> Cole Valley Consulting
> alex at colevalleyconsulting.com
> +1.415.488.6009
>
>
>
> On Wed, Sep 2, 2020 at 10:40 AM Roger D Carney <rcarney at godaddy.com>
> wrote:
>
> Good Afternoon,
>
> Sorry, I thought I had sent this a while back and just found it in my
> drafts.
>
> I have been thinking more about this over the past few weeks (since our
> meeting with the Board and gaining additional insight into their thinking)
> and I would like to suggest taking Marc's point a little further and more
> direct. If we go back to what I believe was the original language in the
> OneDoc (and the language that is in the Final Report) and state:
>
> These elements MUST be transferred:
>
> Domain Name
> Registrar Whois Server
> Registrar URL
> Registrar
> Registrar IANA ID
> Registrar Abuse Contact Email
> Registrar Abuse Contact Phone
> Domain Status(es)
> These elements MUST be transferred, if collected or generated:
>
> Name Server(s)
> Name Server IP Address(es)
> These elements MUST be transferred provided an appropriate legal basis
> exists and data processing agreement is in place:
>
> Registrant Name
> Registrant Street
> Registrant City
> Registrant Country
> Registrant Phone
> Registrant Email
> These elements MUST be transferred provided an appropriate legal basis
> exists and data processing agreement is in place, if collected or generated:
>
> Registrant Organization
> Registrant State/province
> Registrant Postal code
> Registrant Phone ext
> Registrant Fax
> Registrant Fax ext
> Tech Name
> Tech Phone
> Tech Email
> These elements MAY be transferred:
>
> Registrar Registration Expiration Date
> Reseller
> Hopefully, I didn't miss anything.
>
> This is exactly what the recommendation states and I believe this is what
> everyone in this group is saying. I believe the only difference within the
> group is that some believe that "an appropriate legal basis" already
> exists, and others believe that this needs to be determined ongoing by
> ICANN Compliance and the respective contracted parties. The interesting
> thing to me is, that no matter which side of this difference you are on,
> using the recommendation language works to your end.
>
> This IRT does not have the responsibility nor the ability, of globally
> determining that "appropriate legal basis exists". As Marc points out this
> is bigger than Consensus Policies and Contracts, and this cannot be
> codified in Policy and must be left to ICANN Compliance and the contracted
> party.
>
> As nice as it would be to create a simple Policy statement for this issue,
> I do not believe that is possible. The Phase 1 team purposely crafted this
> language and I see no logical reason for this IRT to change that language,
> again it seems like everyone (Phase 1, IRT/IPT, Board, Council) agrees the
> language is correct so let's use it and leave "legal" determinations up to
> those that are legally responsible.
>
>
> Thanks
> Roger
>
>
> ------------------------------
> *From:* IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org> on behalf
> of Sebastien at registry.godaddy <Sebastien at registry.godaddy>
> <Sebastien at registry.godaddy>
> *Sent:* Wednesday, August 26, 2020 2:42 AM
> *To:* Anderson, Marc <mcanderson at verisign.com>; swyld at tucows.com <
> swyld at tucows.com>; irt.regdatapolicy at icann.org <
> irt.regdatapolicy at icann.org>
> *Subject:* Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
> Notice: This email is from an external sender.
>
> Hi Marc, Sarah and Team,
>
> I fully appreciate your points and concerns.
> I can’t speak to what the Council sees as its own remit on this matter,
> but I agree that it is not by itself able to pass legal judgement, it would
> need to rely on advice.
>
> This said, I reported on Thursday verbally to the Council that a question
> would be posed on the matter of Legal Basis, on instructions from this
> group given to me, equally verbally, on Wednesday.
> I also promised the Council a written statement containing the said
> question.
>
> My reports to the Council are my responsibility only, but this is
> effectively the second report I give in a row which is subsequently
> disavowed by one party or another.
> A month ago I reported that we were close to a consensus on going back to
> the recommendation wording because I had obtained that understanding from
> the different members of the IRT with whom I interacted.
>
> For the credibility of this process, and in part for my own, I will ask
> going forward that liaison reports be drafted and approved by the team in
> writing.
> Further and in the interest of time, I suggest that either we are able to
> agree on an appropriate answer to the Council in the coming 10 days
> (halfway to the next Council meeting), or I will need to go back to it with
> the fact that the IRT is indeed at an impasse.
> This answer may be based on the “path forward” document if we can obtain
> consensus on it, on the Legal Basis question if that is the pre-requisite,
> it can also be based on any third option the group sees fit; but we do need
> to come back to the Council with something.
>
> In June the Council resolved to ask the IRT via its liaison if indeed
> there was an issue with Recommendation 7 which required Council’s
> assistance to resolve.
> We will have taken the better part of 3 months to come to this conclusion,
> but if we are not able to resolve this as the IRT, it is my responsibility
> to come back to the Council with that answer.
>
>
> I remain of course open to all suggestions, offered on this list or via
> any other channel.
>
> Kindly,
>
>
>
>
> *Sebastien Ducos*
> GoDaddy Registry | Senior Client Services Manager
> [image: Image removed by sender. signature_2061024682]
> +61449623491
> Level 8, 10 Queens Road
> Melbourne, VIC, Australia
> 3004
>
> sebastien at registry.godaddy
> www.linkedin.com/in/sebastienducos
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_sebastienducos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ddb2R34v_iarUT2F1OWXjsfV9xL0QTRwXYgakb2v-z4&s=ZxAHO1cWP390CIU2OK2YaBqAfTLKq0C7IzkgHDMNZCk&e=>
>
>
> *From: *"Anderson, Marc" <mcanderson at verisign.com>
> *Date: *Wednesday, 26 August 2020 at 12:16 am
> *To: *Sebastien Ducos <Sebastien at registry.godaddy>
> <Sebastien at registry.godaddy>, "swyld at tucows.com" <swyld at tucows.com>, "
> irt.regdatapolicy at icann.org" <irt.regdatapolicy at icann.org>
> *Subject: *RE: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
> Notice: This email is from an external sender.
>
> Hi Sebastien,
>
> Thank you for circulating this draft and for the ongoing work to resolve
> the Rec 7 issue. I can understand your thinking behind trying to get an
> answer from the Council that can help resolve the disagreement, but I don’t
> believe the question you’ve posed is the best one to ask, or even an
> appropriate question to put to the Council.
>
> First off, I share Sarah’s concerns that the question as written is beyond
> the scope of the Council. We cannot ask the Council to make a legal
> judgment for the Contracted Parties. The Council’s role is to manage the
> policy development process, not adjudicate how those policies apply to and
> are enforced with Contracted Parties. That’s very squarely the job of
> ICANN’s Compliance Department.
>
> Moreover, my recollection of developing this recommendation during Phase 1
> is that the reference to a “legal basis” was not intended to refer ONLY to
> ICANN Consensus Policies. So again, it becomes inappropriate to ask the
> Council to make a determination as to whether a legal basis does indeed
> exist for the transfer of all data in all cases. As I mentioned during the
> call on Wednesday, if that had been the intended outcome of the Phase 1
> deliberations, then that is what the policy recommendation would reflect.
> But that’s not what the Phase 1 WG concluded – instead, it concluded that
> the transfer of certain data elements would be optional.
>
> Rather than posing this question to Council, I think it makes much more
> sense to go back to your original plan and send them your written analysis
> document. The fundamental question here is how Rec 7 should be reflected in
> the Consensus Policy. That should have a straightforward answer. But we
> keep getting caught up in trying to interpret or preempt how the policy
> will later be enforced, and that’s not what either the IRT or the Council
> is here to do. So I think it makes sense to refocus our question to Council
> on how the recommendation should be implemented, as you describe in your
> paper.
>
> Best,
> Marc
>
>
> *From:* IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org> *On
> Behalf Of *Sebastien at registry.godaddy
> *Sent:* Monday, August 24, 2020 12:42 PM
> *To:* Sarah Wyld <swyld at tucows.com>; irt.regdatapolicy at icann.org
> *Subject:* [EXTERNAL] Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7
> during the 20Aug2020 GNSO Council Meeting
>
> Hi Sarah,
>
> In my view this replaces my earlier "suggested path to resolution"
> document for now.
> I believe that depending on the answer to this question we may or not be
> able to resolve Rec 7.
> If the Council’s answer to this doesn’t help us resolve Rec 7, we will
> then review the previous document in light of the answer and send that too.
>
> I got an acknowledgment of reception on our Rec 12 question but no answer
> so far. I will chase it.
>
> Kindly,
>
>
>
>
> *Sebastien Ducos*
> GoDaddy Registry | Senior Client Services Manager
> [image: Image removed by sender. signature_1571866922]
> +61449623491
> Level 8, 10 Queens Road
> Melbourne, VIC, Australia
> 3004
>
> sebastien at registry.godaddy
> www.linkedin.com/in/sebastienducos
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_sebastienducos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ddb2R34v_iarUT2F1OWXjsfV9xL0QTRwXYgakb2v-z4&s=ZxAHO1cWP390CIU2OK2YaBqAfTLKq0C7IzkgHDMNZCk&e=>
>
>
> *From: *"IRT.RegDataPolicy" <irt.regdatapolicy-bounces at icann.org> on
> behalf of Sarah Wyld <swyld at tucows.com>
> *Organisation: *Tucows
> *Date: *Monday, 24 August 2020 at 6:30 pm
> *To: *"irt.regdatapolicy at icann.org" <irt.regdatapolicy at icann.org>
> *Subject: *Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
> Notice: This email is from an external sender.
>
> Hi Sebastien,
> Thank you for sharing this on the list.
> How does this request below relate to your "suggested path to resolution"
> document, are they both being provided to the Council? I notice that the
> question to Council at the end of the letter in this thread below is
> different from the conclusion you reached in the document, and the question
> below would lead the GNSO Council to provide legal guidance to the
> Contracted Parties, was that your intent?
> And a separate question, but since I'm already writing -- I think you were
> going to ask the Council for an update on the consultation between the
> ICANN Board and GNSO Council on the portions of Rec #12 not adopted by the
> Board. Do you have any further info for us on this topic?
> Thank you,
> Sarah W
>
>
>
>
> --
>
> Sarah Wyld
>
> Domains Product Team
>
> Tucows
>
> +1.416 535 0123 Ext. 1392
>
>
>
> On 8/21/2020 6:15 PM, Ducos, Sebastien via IRT.RegDataPolicy wrote:
>
> Dear IRT,
>
> As per our discussion during our IRT call on 19Aug2020, I reported
> yesterday (20Aug2020) to the GNSO Council the IRT’s request for
> clarification on the prior existence of a Legal Basis to support the
> transfer of data under Rec 7.
>
> For clarity, I now have to present the said request in writing. I propose
> the following wording, but invite your input.
> As has been the case all along in this exercise, this is not a reflexion
> of my personal point of view, but should represent the different points of
> view of the IRT. Please ensure yours is reflected.
>
> For the sake of council members who may not all be as familiar with the
> topic as we are, I would like to submit a limited relevant number of
> reference documents for their review.
> Please confirm that the ones I have included are indeed relevant and the
> links I have provided are the most direct to the latest/final versions of
> the said documents.
>
>
>
> [Date]
> RE: EPDP Phase 1 Recommendation 7 – Legal Basis
>
> Dear GNSO Council,
>
> In an attempt to resolve a different in interpretation of the EPDP Phase I
> Recommendation 7, the IRT is seeking clarification with regards to the
> existence of legal basis which covers the transfer of data (including
> personal data) from Registrars to Registries, in all cases.
>
> Recommendation 7 states:
> *“The EPDP Team recommends that the specifically-identified data elements
> under “[t]ransmission of registration data from Registrar to Registry”, as
> illustrated in the aggregate data elements workbooks, must be transferred
> from registrar to registry provided an appropriate legal basis exists and
> data processing agreement is in place. In the aggregate, these data
> elements are:”*
>
> [followed by the list of data points that may be transferred, some marked
> as Mandatory (The domain name, fields pertaining to the Registrar and
> Domain Statuses), others as Optional (contact fields, name servers,
> Registrar expiry date and Reseller)]
> Ref:
> https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf
> <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf__;!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTovu3GBdw$>
>
>
> The IRT remains divided in the interpretation of the mention “*provided
> an appropriate legal basis exists and data processing agreement is in place*”
> with:
>
> - Parties who consider the mention key as in their view a legal basis
> may not exist in all cases and must be established for each TLD,
> - Parties who consider the mention relevant, view the legal basis as
> pre-established under Consensus Policy and expect that the currently
> negotiated data processing agreement (between ICANN and the CPH) will
> reflect the said legal basis,
> - Parties who consider legal basis established in all cases in this
> context, and seek to remove the sentence for the avoidance of confusion.
>
>
>
> Further, each party cites in its argument:
>
> - The EPDP Phase I Final Report and the underlying work -
> https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf
> <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf__;!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTovu3GBdw$>
> - Existing Consensus Policy including but not limited to the Thick
> RDDS (WHOIS) Transition Policy -
> https://www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en
> <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en__;!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTomhXpJgw$>
> - The “Bird & Bird memo” of 8 March 2019 “Advice on the legal basis
> for transferring Thick WHOIS” -
> https://community.icann.org/download/attachments/102138857/ICANN%20-%20Memo%20on%20thick%20Whois%5B1%5D.docx?version=1&modificationDate=1552176734000&api=v2
> <https://urldefense.com/v3/__https:/community.icann.org/download/attachments/102138857/ICANN*20-*20Memo*20on*20thick*20Whois*5B1*5D.docx?version=1&modificationDate=1552176734000&api=v2__;JSUlJSUlJQ!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTpLToewLQ$>
>
> and related public comments submitted in the context of the above.
>
>
> Question to the GNSO Council:
>
> - Does the GNSO Council advise that there exists under Consensus
> Policy and in accordance with GDPR a legal basis which covers the transfer
> of data, including personal data, between Registrar and Registries in all
> cases?
>
>
>
> [IRT Liaison signature]
>
>
>
> Kindly,
>
>
>
>
> *Sebastien Ducos*
> GoDaddy Registry | Senior Client Services Manager
> *Error! Filename not specified.*
> +61449623491
> Level 8, 10 Queens Road
> Melbourne, VIC, Australia
> 3004
>
> sebastien at registry.godaddy
> www.linkedin.com/in/sebastienducos
> <https://urldefense.com/v3/__https:/www.linkedin.com/in/sebastienducos__;!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTpZ-jSKMQ$>
>
>
>
>
>
> _______________________________________________
>
> IRT.RegDataPolicy mailing list
>
> IRT.RegDataPolicy at icann.org
>
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy <https://urldefense.proofpoint.com/v2/url?u=https-3A__secure-2Dweb.cisco.com_1OEoNdxT16nMOvMsIRx8GP2NvFjfPzY90GCaTDAlYLrheb0q5NSuZhDNw1miPs7v1aTjEnLfu1iYc1LX4SO-5FqA4jGuH7dPtGlDL4heP4fO4m8JOuhSV8K-2DAIM1p6fMmYRaBJoyHtCf0sK5nz62HvKaB2oMILJvTQQS877HtX9Htd02-5Fel9maOvePOsrKw6KyApQyXf8MmTV2V-2Dj1PWSM-2DVUcTDREgcKPy14i4HfavXtrkKmLgABUFLgjyerPvVxJ80GjBQAv0keMwIilybTaMyA_https-253A-252F-252Fmm.icann.org-252Fmailman-252Flistinfo-252Firt.regdatapolicy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ddb2R34v_iarUT2F1OWXjsfV9xL0QTRwXYgakb2v-z4&s=KLJkq7Vq7fzujRK1VNyZAeS7EkYHcZhoxBgirU0K3g4&e=>
>
>
>
> _______________________________________________
>
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://urldefense.proofpoint.com/v2/url?u=https-3A__secure-2Dweb.cisco.com_1-5FgLCmgxtwq5vuSnO6tRZRBaOMKLU2Cfp7580qddkqWtBYLdHC1hW3T3ALKM-5FFP2PzWNq-5FXVBvaReX263DLlBc5js-5Ft-5FIcGjfnVvmDhfxzkVEG6YmOT9Tr-2D3rwMKLj-2DwPF2amiiI-5FTeCpifUJ3d3lSa8NdsCh6wN59PfiI8NHzW3jgJyBzdq4BD-2DrsMu-2D9WgyFT8yX8mNrP8j8fp5xiAi8DgPtjDatOaSRa9cmxAoW2Qx-5Fo3873Rq-2DTnhEh-5FDJROpA57azLTS5i0bjLMLAVMDdg_https-253A-252F-252Fwww.icann.org-252Fprivacy-252Fpolicy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ddb2R34v_iarUT2F1OWXjsfV9xL0QTRwXYgakb2v-z4&s=6G8mwioS_tODoX0N-c-3rhpjZkiyhHeAqJN0SS6ltyc&e=>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__secure-2Dweb.cisco.com_14afZUZDeDbzaeDq33YJ9L34hLIqB96yD7CsZC2t-2D5BJ0hUhrGisHIeEe09II5le2R7vE7BBe0G3Da1FOrdeNtnitF8FWcPicaCx2W1BCoRxDmk5iCBL3aOR9k00xBQ6zAMYzXRBaGA0d6dJLcVEFofmQGcI0aUFxeTyh3VaT8CIE4hdFiqC-5F4RmPrBgFmVoVwNLNCmVeXGEyVSNb76obx1JFxGkZ0ofQ3ZNtyWmzhF4HXKAtCLUf7G6Wzw2KixmPs7TYCB1mMXLpVdgtYIdRJw_https-253A-252F-252Fwww.icann.org-252Fprivacy-252Ftos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ddb2R34v_iarUT2F1OWXjsfV9xL0QTRwXYgakb2v-z4&s=eudZ1_IpoOLA6oCzBRNJxccYYjCZtsMuYlsegXVH94w&e=>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
>
> _______________________________________________
> IRT.RegDataPolicy mailing list
> IRT.RegDataPolicy at icann.org
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_irt.regdatapolicy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ddb2R34v_iarUT2F1OWXjsfV9xL0QTRwXYgakb2v-z4&s=OExqdlvfsUQWutZaacbgEaQOvzG9M5US9IjCbNQDW_o&e=>
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ddb2R34v_iarUT2F1OWXjsfV9xL0QTRwXYgakb2v-z4&s=K5VkAXwehcks30fw6qY4n6H25bKYH-UaONSpRtWzTI8&e=>)
> and the website Terms of Service (https://www.icann.org/privacy/tos
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ddb2R34v_iarUT2F1OWXjsfV9xL0QTRwXYgakb2v-z4&s=g71qLt1Z8pU7NX9sEFPd1hDho7LPCbt9gHeeiBUoDpM&e=>).
> You can visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
>
> _______________________________________________
> IRT.RegDataPolicy mailing list
> IRT.RegDataPolicy at icann.org
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_irt.regdatapolicy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ddb2R34v_iarUT2F1OWXjsfV9xL0QTRwXYgakb2v-z4&s=OExqdlvfsUQWutZaacbgEaQOvzG9M5US9IjCbNQDW_o&e=>
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ddb2R34v_iarUT2F1OWXjsfV9xL0QTRwXYgakb2v-z4&s=K5VkAXwehcks30fw6qY4n6H25bKYH-UaONSpRtWzTI8&e=>)
> and the website Terms of Service (https://www.icann.org/privacy/tos
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMF-g&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ddb2R34v_iarUT2F1OWXjsfV9xL0QTRwXYgakb2v-z4&s=g71qLt1Z8pU7NX9sEFPd1hDho7LPCbt9gHeeiBUoDpM&e=>).
> You can visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
>
> Confidentiality note: This e-mail may contain confidential information
> from Clarivate. If you are not the intended recipient, be aware that any
> disclosure, copying, distribution or use of the contents of this e-mail is
> strictly prohibited. If you have received this e-mail in error, please
> delete this e-mail and notify the sender immediately.
>
>
>
> _______________________________________________
>
> IRT.RegDataPolicy mailing list
>
> IRT.RegDataPolicy at icann.org
>
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_irt.regdatapolicy&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ksGqw06mx_8tgEzKe_n3S7oqAZSXndVQSnz8Y-V60vs&s=iG_F1nCub45el613v3AYkcy4A3bUOfBVWv8pxAluYyE&e=>
>
>
>
> _______________________________________________
>
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ksGqw06mx_8tgEzKe_n3S7oqAZSXndVQSnz8Y-V60vs&s=WGwzmeViH27GhE9OgSjzdfbWj76ZSLWdvPqqYvFx1ow&e=>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ksGqw06mx_8tgEzKe_n3S7oqAZSXndVQSnz8Y-V60vs&s=Csdh9yPfmEEoKUR9NXnUpa0AbzhqnA0wcILVDB1ncMQ&e=>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
>
>
>
>
> _______________________________________________
>
> IRT.RegDataPolicy mailing list
>
> IRT.RegDataPolicy at icann.org
>
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_irt.regdatapolicy&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ksGqw06mx_8tgEzKe_n3S7oqAZSXndVQSnz8Y-V60vs&s=iG_F1nCub45el613v3AYkcy4A3bUOfBVWv8pxAluYyE&e=>
>
>
>
> _______________________________________________
>
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ksGqw06mx_8tgEzKe_n3S7oqAZSXndVQSnz8Y-V60vs&s=WGwzmeViH27GhE9OgSjzdfbWj76ZSLWdvPqqYvFx1ow&e=>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMGaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=ksGqw06mx_8tgEzKe_n3S7oqAZSXndVQSnz8Y-V60vs&s=Csdh9yPfmEEoKUR9NXnUpa0AbzhqnA0wcILVDB1ncMQ&e=>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
>
> Confidentiality note: This e-mail may contain confidential information
> from Clarivate. If you are not the intended recipient, be aware that any
> disclosure, copying, distribution or use of the contents of this e-mail is
> strictly prohibited. If you have received this e-mail in error, please
> delete this e-mail and notify the sender immediately.
>
> Confidentiality note: This e-mail may contain confidential information
> from Clarivate. If you are not the intended recipient, be aware that any
> disclosure, copying, distribution or use of the contents of this e-mail is
> strictly prohibited. If you have received this e-mail in error, please
> delete this e-mail and notify the sender immediately.
>
> _______________________________________________
> IRT.RegDataPolicy mailing listIRT.RegDataPolicy at icann.orghttps://mm.icann.org/mailman/listinfo/irt.regdatapolicy
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
>
> Good Afternoon,
>
> Sorry, I thought I had sent this a while back and just found it in my
> drafts.
>
> I have been thinking more about this over the past few weeks (since our
> meeting with the Board and gaining additional insight into their thinking)
> and I would like to suggest taking Marc's point a little further and more
> direct. If we go back to what I believe was the original language in the
> OneDoc (and the language that is in the Final Report) and state:
>
> These elements MUST be transferred:
> Domain Name
> Registrar Whois Server
> Registrar URL
> Registrar
> Registrar IANA ID
> Registrar Abuse Contact Email
> Registrar Abuse Contact Phone
> Domain Status(es)
>
> These elements MUST be transferred, if collected or generated:
> Name Server(s)
> Name Server IP Address(es)
>
> These elements MUST be transferred provided an appropriate legal basis
> exists and data processing agreement is in place:
> Registrant Name
> Registrant Street
> Registrant City
> Registrant Country
> Registrant Phone
> Registrant Email
>
> These elements MUST be transferred provided an appropriate legal basis
> exists and data processing agreement is in place, if collected or generated:
> Registrant Organization
> Registrant State/province
> Registrant Postal code
> Registrant Phone ext
> Registrant Fax
> Registrant Fax ext
> Tech Name
> Tech Phone
> Tech Email
>
> These elements MAY be transferred:
> Registrar Registration Expiration Date
> Reseller
>
> Hopefully, I didn't miss anything.
>
> This is exactly what the recommendation states and I believe this is what
> everyone in this group is saying. I believe the only difference within the
> group is that some believe that "an appropriate legal basis" already
> exists, and others believe that this needs to be determined ongoing by
> ICANN Compliance and the respective contracted parties. The interesting
> thing to me is, that no matter which side of this difference you are on,
> using the recommendation language works to your end.
>
> This IRT does not have the responsibility nor the ability, of globally
> determining that "appropriate legal basis exists". As Marc points out this
> is bigger than Consensus Policies and Contracts, and this cannot be
> codified in Policy and must be left to ICANN Compliance and the contracted
> party.
>
> As nice as it would be to create a simple Policy statement for this issue,
> I do not believe that is possible. The Phase 1 team purposely crafted this
> language and I see no logical reason for this IRT to change that language,
> again it seems like everyone (Phase 1, IRT/IPT, Board, Council) agrees the
> language is correct so let's use it and leave "legal" determinations up to
> those that are legally responsible.
>
>
> Thanks
> Roger
>
>
> ------------------------------
> *From:* IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org> on behalf
> of Sebastien at registry.godaddy <Sebastien at registry.godaddy>
> *Sent:* Wednesday, August 26, 2020 2:42 AM
> *To:* Anderson, Marc <mcanderson at verisign.com>; swyld at tucows.com <
> swyld at tucows.com>; irt.regdatapolicy at icann.org <
> irt.regdatapolicy at icann.org>
> *Subject:* Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
> Notice: This email is from an external sender.
>
>
> Hi Marc, Sarah and Team,
>
>
> I fully appreciate your points and concerns.
> I can’t speak to what the Council sees as its own remit on this matter,
> but I agree that it is not by itself able to pass legal judgement, it would
> need to rely on advice.
>
>
> This said, I reported on Thursday verbally to the Council that a question
> would be posed on the matter of Legal Basis, on instructions from this
> group given to me, equally verbally, on Wednesday.
> I also promised the Council a written statement containing the said
> question.
>
>
> My reports to the Council are my responsibility only, but this is
> effectively the second report I give in a row which is subsequently
> disavowed by one party or another.
> A month ago I reported that we were close to a consensus on going back to
> the recommendation wording because I had obtained that understanding from
> the different members of the IRT with whom I interacted.
>
>
> For the credibility of this process, and in part for my own, I will ask
> going forward that liaison reports be drafted and approved by the team in
> writing.
> Further and in the interest of time, I suggest that either we are able to
> agree on an appropriate answer to the Council in the coming 10 days
> (halfway to the next Council meeting), or I will need to go back to it with
> the fact that the IRT is indeed at an impasse.
> This answer may be based on the “path forward” document if we can obtain
> consensus on it, on the Legal Basis question if that is the pre-requisite,
> it can also be based on any third option the group sees fit; but we do need
> to come back to the Council with something.
>
>
> In June the Council resolved to ask the IRT via its liaison if indeed
> there was an issue with Recommendation 7 which required Council’s
> assistance to resolve.
> We will have taken the better part of 3 months to come to this conclusion,
> but if we are not able to resolve this as the IRT, it is my responsibility
> to come back to the Council with that answer.
>
>
>
>
> I remain of course open to all suggestions, offered on this list or via
> any other channel.
>
>
> Kindly,
>
>
> *Sebastien Ducos*
> GoDaddy Registry | Senior Client Services Manager
> <Outlook-signature_.png>
> +61449623491
> Level 8, 10 Queens Road
> Melbourne, VIC, Australia
> 3004
> sebastien at registry.godaddy
> www.linkedin.com/in/sebastienducos
>
>
>
>
> *From: *"Anderson, Marc" <mcanderson at verisign.com>
> *Date: *Wednesday, 26 August 2020 at 12:16 am
> *To: *Sebastien Ducos <Sebastien at registry.godaddy>, "swyld at tucows.com" <
> swyld at tucows.com>, "irt.regdatapolicy at icann.org" <
> irt.regdatapolicy at icann.org>
> *Subject: *RE: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
>
> Notice: This email is from an external sender.
>
>
> Hi Sebastien,
>
>
> Thank you for circulating this draft and for the ongoing work to resolve
> the Rec 7 issue. I can understand your thinking behind trying to get an
> answer from the Council that can help resolve the disagreement, but I don’t
> believe the question you’ve posed is the best one to ask, or even an
> appropriate question to put to the Council.
>
>
> First off, I share Sarah’s concerns that the question as written is beyond
> the scope of the Council. We cannot ask the Council to make a legal
> judgment for the Contracted Parties. The Council’s role is to manage the
> policy development process, not adjudicate how those policies apply to and
> are enforced with Contracted Parties. That’s very squarely the job of
> ICANN’s Compliance Department.
>
>
> Moreover, my recollection of developing this recommendation during Phase 1
> is that the reference to a “legal basis” was not intended to refer ONLY to
> ICANN Consensus Policies. So again, it becomes inappropriate to ask the
> Council to make a determination as to whether a legal basis does indeed
> exist for the transfer of all data in all cases. As I mentioned during the
> call on Wednesday, if that had been the intended outcome of the Phase 1
> deliberations, then that is what the policy recommendation would reflect.
> But that’s not what the Phase 1 WG concluded – instead, it concluded that
> the transfer of certain data elements would be optional.
>
>
> Rather than posing this question to Council, I think it makes much more
> sense to go back to your original plan and send them your written analysis
> document. The fundamental question here is how Rec 7 should be reflected in
> the Consensus Policy. That should have a straightforward answer. But we
> keep getting caught up in trying to interpret or preempt how the policy
> will later be enforced, and that’s not what either the IRT or the Council
> is here to do. So I think it makes sense to refocus our question to Council
> on how the recommendation should be implemented, as you describe in your
> paper.
>
>
> Best,
> Marc
>
>
>
>
> *From:* IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org> *On
> Behalf Of *Sebastien at registry.godaddy
> *Sent:* Monday, August 24, 2020 12:42 PM
> *To:* Sarah Wyld <swyld at tucows.com>; irt.regdatapolicy at icann.org
> *Subject:* [EXTERNAL] Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7
> during the 20Aug2020 GNSO Council Meeting
>
>
> Hi Sarah,
>
>
> In my view this replaces my earlier "suggested path to resolution"
> document for now.
> I believe that depending on the answer to this question we may or not be
> able to resolve Rec 7.
> If the Council’s answer to this doesn’t help us resolve Rec 7, we will
> then review the previous document in light of the answer and send that too.
>
>
> I got an acknowledgment of reception on our Rec 12 question but no answer
> so far. I will chase it.
>
>
> Kindly,
>
>
>
>
> *Sebastien Ducos*
> GoDaddy Registry | Senior Client Services Manager
> <Outlook-signature_.png>
> +61449623491
> Level 8, 10 Queens Road
> Melbourne, VIC, Australia
> 3004
> sebastien at registry.godaddy
> www.linkedin.com/in/sebastienducos
>
>
>
>
> *From: *"IRT.RegDataPolicy" <irt.regdatapolicy-bounces at icann.org> on
> behalf of Sarah Wyld <swyld at tucows.com>
> *Organisation: *Tucows
> *Date: *Monday, 24 August 2020 at 6:30 pm
> *To: *"irt.regdatapolicy at icann.org" <irt.regdatapolicy at icann.org>
> *Subject: *Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting
>
>
> Notice: This email is from an external sender.
>
>
> Hi Sebastien,
> Thank you for sharing this on the list.
> How does this request below relate to your "suggested path to resolution"
> document, are they both being provided to the Council? I notice that the
> question to Council at the end of the letter in this thread below is
> different from the conclusion you reached in the document, and the question
> below would lead the GNSO Council to provide legal guidance to the
> Contracted Parties, was that your intent?
> And a separate question, but since I'm already writing -- I think you were
> going to ask the Council for an update on the consultation between the
> ICANN Board and GNSO Council on the portions of Rec #12 not adopted by the
> Board. Do you have any further info for us on this topic?
> Thank you,
> Sarah W
>
>
>
>
>
>
>
> --
>
> Sarah Wyld
>
> Domains Product Team
>
> Tucows
>
> +1.416 535 0123 Ext. 1392
>
>
>
> On 8/21/2020 6:15 PM, Ducos, Sebastien via IRT.RegDataPolicy wrote:
>
> Dear IRT,
>
>
> As per our discussion during our IRT call on 19Aug2020, I reported
> yesterday (20Aug2020) to the GNSO Council the IRT’s request for
> clarification on the prior existence of a Legal Basis to support the
> transfer of data under Rec 7.
>
>
> For clarity, I now have to present the said request in writing. I propose
> the following wording, but invite your input.
> As has been the case all along in this exercise, this is not a reflexion
> of my personal point of view, but should represent the different points of
> view of the IRT. Please ensure yours is reflected.
>
>
> For the sake of council members who may not all be as familiar with the
> topic as we are, I would like to submit a limited relevant number of
> reference documents for their review.
> Please confirm that the ones I have included are indeed relevant and the
> links I have provided are the most direct to the latest/final versions of
> the said documents.
>
>
>
>
>
>
> [Date]
> RE: EPDP Phase 1 Recommendation 7 – Legal Basis
>
>
> Dear GNSO Council,
>
>
> In an attempt to resolve a different in interpretation of the EPDP Phase I
> Recommendation 7, the IRT is seeking clarification with regards to the
> existence of legal basis which covers the transfer of data (including
> personal data) from Registrars to Registries, in all cases.
>
>
> Recommendation 7 states:
> *“The EPDP Team recommends that the specifically-identified data elements
> under “[t]ransmission of registration data from Registrar to Registry”, as
> illustrated in the aggregate data elements workbooks, must be transferred
> from registrar to registry provided an appropriate legal basis exists and
> data processing agreement is in place. In the aggregate, these data
> elements are:”*
>
> [followed by the list of data points that may be transferred, some marked
> as Mandatory (The domain name, fields pertaining to the Registrar and
> Domain Statuses), others as Optional (contact fields, name servers,
> Registrar expiry date and Reseller)]
> Ref:
> https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf
> <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf__;!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTovu3GBdw$>
>
>
>
>
> The IRT remains divided in the interpretation of the mention “*provided
> an appropriate legal basis exists and data processing agreement is in place*”
> with:
>
> - Parties who consider the mention key as in their view a legal basis
> may not exist in all cases and must be established for each TLD,
> - Parties who consider the mention relevant, view the legal basis as
> pre-established under Consensus Policy and expect that the currently
> negotiated data processing agreement (between ICANN and the CPH) will
> reflect the said legal basis,
> - Parties who consider legal basis established in all cases in this
> context, and seek to remove the sentence for the avoidance of confusion.
>
>
>
>
> Further, each party cites in its argument:
>
> - The EPDP Phase I Final Report and the underlying work -
> https://gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf
> <https://urldefense.com/v3/__https:/gnso.icann.org/sites/default/files/file/field-file-attach/epdp-gtld-registration-data-specs-final-20feb19-en.pdf__;!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTovu3GBdw$>
> - Existing Consensus Policy including but not limited to the Thick
> RDDS (WHOIS) Transition Policy -
> https://www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en
> <https://urldefense.com/v3/__https:/www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en__;!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTomhXpJgw$>
> - The “Bird & Bird memo” of 8 March 2019 “Advice on the legal basis
> for transferring Thick WHOIS” -
> https://community.icann.org/download/attachments/102138857/ICANN%20-%20Memo%20on%20thick%20Whois%5B1%5D.docx?version=1&modificationDate=1552176734000&api=v2
> <https://urldefense.com/v3/__https:/community.icann.org/download/attachments/102138857/ICANN*20-*20Memo*20on*20thick*20Whois*5B1*5D.docx?version=1&modificationDate=1552176734000&api=v2__;JSUlJSUlJQ!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTpLToewLQ$>
>
> and related public comments submitted in the context of the above.
>
>
>
>
> Question to the GNSO Council:
>
> - Does the GNSO Council advise that there exists under Consensus
> Policy and in accordance with GDPR a legal basis which covers the transfer
> of data, including personal data, between Registrar and Registries in all
> cases?
>
>
>
>
> [IRT Liaison signature]
>
>
>
>
>
>
> Kindly,
>
>
>
>
> *Sebastien Ducos*
> GoDaddy Registry | Senior Client Services Manager
> [image: signature_1081474336]
> +61449623491
> Level 8, 10 Queens Road
> Melbourne, VIC, Australia
> 3004
> sebastien at registry.godaddy
> www.linkedin.com/in/sebastienducos
> <https://urldefense.com/v3/__https:/www.linkedin.com/in/sebastienducos__;!!N14HnBHF!sCWU7y9IbaKHs6GMHTcYVyVtmbssBSq1aPdTMDjtwrN2EavylO7yn8IgebUbvTpZ-jSKMQ$>
>
>
>
>
>
>
> _______________________________________________
>
> IRT.RegDataPolicy mailing list
>
> IRT.RegDataPolicy at icann.org
>
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy <https://secure-web.cisco.com/1OEoNdxT16nMOvMsIRx8GP2NvFjfPzY90GCaTDAlYLrheb0q5NSuZhDNw1miPs7v1aTjEnLfu1iYc1LX4SO_qA4jGuH7dPtGlDL4heP4fO4m8JOuhSV8K-AIM1p6fMmYRaBJoyHtCf0sK5nz62HvKaB2oMILJvTQQS877HtX9Htd02_el9maOvePOsrKw6KyApQyXf8MmTV2V-j1PWSM-VUcTDREgcKPy14i4HfavXtrkKmLgABUFLgjyerPvVxJ80GjBQAv0keMwIilybTaMyA/https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Firt.regdatapolicy>
>
>
>
> _______________________________________________
>
> By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy <https://secure-web.cisco.com/1_gLCmgxtwq5vuSnO6tRZRBaOMKLU2Cfp7580qddkqWtBYLdHC1hW3T3ALKM_FP2PzWNq_XVBvaReX263DLlBc5js_t_IcGjfnVvmDhfxzkVEG6YmOT9Tr-3rwMKLj-wPF2amiiI_TeCpifUJ3d3lSa8NdsCh6wN59PfiI8NHzW3jgJyBzdq4BD-rsMu-9WgyFT8yX8mNrP8j8fp5xiAi8DgPtjDatOaSRa9cmxAoW2Qx_o3873Rq-TnhEh_DJROpA57azLTS5i0bjLMLAVMDdg/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy>) and the website Terms of Service (https://www.icann.org/privacy/tos <https://secure-web.cisco.com/14afZUZDeDbzaeDq33YJ9L34hLIqB96yD7CsZC2t-5BJ0hUhrGisHIeEe09II5le2R7vE7BBe0G3Da1FOrdeNtnitF8FWcPicaCx2W1BCoRxDmk5iCBL3aOR9k00xBQ6zAMYzXRBaGA0d6dJLcVEFofmQGcI0aUFxeTyh3VaT8CIE4hdFiqC_4RmPrBgFmVoVwNLNCmVeXGEyVSNb76obx1JFxGkZ0ofQ3ZNtyWmzhF4HXKAtCLUf7G6Wzw2KixmPs7TYCB1mMXLpVdgtYIdRJw/https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
>
>
> *From: *Roger D Carney <rcarney at godaddy.com>
> *Subject: **Re: [IRT.RegDataPolicy] IRT Liaison report on Rec7 during the
> 20Aug2020 GNSO Council Meeting*
> *Date: *September 2, 2020 at 7:40:21 PM GMT+2
> *To: *"irt.regdatapolicy at icann.org" <irt.regdatapolicy at icann.org>
>
>
> _______________________________________________
> IRT.RegDataPolicy mailing list
> IRT.RegDataPolicy at icann.org
> https://mm.icann.org/mailman/listinfo/irt.regdatapolicy
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20200909/3c6882c9/attachment-0001.html>
More information about the IRT.RegDataPolicy
mailing list