[IRT.RegDataPolicy] IRT Liaison report on Rec7 during the 20Aug2020 GNSO Council Meeting
Stephanie E Perrin
stephanie at digitaldiscretion.ca
Tue Sep 8 22:25:42 UTC 2020
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
> - 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
>>
>> 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_
>>
>> D39D107B
>>
>> *From:* IRT.RegDataPolicy <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>
>> *Sent:* Thursday, September 3, 2020 6:35 PM
>> *To:* Alex Deacon <alex at colevalleyconsulting.com>
>> *Cc:* Roger D Carney <rcarney at godaddy.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.
>>
>> sorry - Roger, not Rodger!
>>
>> ___________
>>
>> *Alex Deacon*
>>
>> Cole Valley Consulting
>>
>> alex at colevalleyconsulting.com <mailto:alex at colevalleyconsulting.com>
>>
>> +1.415.488.6009
>>
>> On Thu, Sep 3, 2020 at 4:30 PM Alex Deacon
>> <alex at colevalleyconsulting.com
>> <mailto: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 <mailto:alex at colevalleyconsulting.com>
>>
>> +1.415.488.6009
>>
>> On Thu, Sep 3, 2020 at 4:07 PM Roger D Carney
>> <rcarney at godaddy.com <mailto: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
>> <mailto:alex at colevalleyconsulting.com>>
>> *Sent:* Thursday, September 3, 2020 5:22 PM
>> *To:* Roger D Carney <rcarney at godaddy.com
>> <mailto:rcarney at godaddy.com>>
>> *Cc:* irt.regdatapolicy at icann.org
>> <mailto:irt.regdatapolicy at icann.org>
>> <irt.regdatapolicy at icann.org
>> <mailto: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
>> <mailto:alex at colevalleyconsulting.com>
>>
>> +1.415.488.6009
>>
>> On Wed, Sep 2, 2020 at 10:40 AM Roger D Carney
>> <rcarney at godaddy.com <mailto: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
>> <mailto: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
>> <mailto:mcanderson at verisign.com>>; swyld at tucows.com
>> <mailto:swyld at tucows.com> <swyld at tucows.com
>> <mailto:swyld at tucows.com>>; irt.regdatapolicy at icann.org
>> <mailto:irt.regdatapolicy at icann.org>
>> <irt.regdatapolicy at icann.org
>> <mailto: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 removed by sender. signature_2061024682
>>
>> +61449623491
>>
>> Level 8, 10 Queens Road
>>
>> Melbourne, VIC, Australia
>>
>> 3004
>>
>>
>> sebastien at registry.godaddy
>> <mailto: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
>> <mailto:mcanderson at verisign.com>>
>> *Date: *Wednesday, 26 August 2020 at 12:16 am
>> *To: *Sebastien Ducos <Sebastien at registry.godaddy>,
>> "swyld at tucows.com <mailto:swyld at tucows.com>"
>> <swyld at tucows.com <mailto:swyld at tucows.com>>,
>> "irt.regdatapolicy at icann.org
>> <mailto:irt.regdatapolicy at icann.org>"
>> <irt.regdatapolicy at icann.org
>> <mailto: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
>> <mailto: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
>> <mailto:swyld at tucows.com>>; irt.regdatapolicy at icann.org
>> <mailto: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 removed by sender. signature_1571866922
>>
>> +61449623491
>>
>> Level 8, 10 Queens Road
>>
>> Melbourne, VIC, Australia
>>
>> 3004
>>
>>
>> sebastien at registry.godaddy
>> <mailto: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
>> <mailto:irt.regdatapolicy-bounces at icann.org>> on behalf
>> of Sarah Wyld <swyld at tucows.com <mailto:swyld at tucows.com>>
>> *Organisation: *Tucows
>> *Date: *Monday, 24 August 2020 at 6:30 pm
>> *To: *"irt.regdatapolicy at icann.org
>> <mailto:irt.regdatapolicy at icann.org>"
>> <irt.regdatapolicy at icann.org
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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 <mailto: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
>>
>> _______________________________________________
>> 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.
>
> _______________________________________________
> 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/20200908/d9572209/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 4440 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20200908/d9572209/image001-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 429 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20200908/d9572209/image002-0001.jpg>
More information about the IRT.RegDataPolicy
mailing list