[IRT.RegDataPolicy] IRT Liaison report on Rec7 during the 20Aug2020 GNSO Council Meeting

Roger D Carney rcarney at godaddy.com
Fri Sep 11 15:14:11 UTC 2020


Good Morning,

Thanks Sebastien, I think this makes sense, but I have a concern with Brian's recent comment about him (he said we, I am guessing that means BC but I am not sure) not able to agree that Council can "call the shots or adjudicate."

If Brian is correct and Council has no authority to resolve IRT disputes, then I am not sure it is worth anyone's time to pursue this with Council.

I think it is true that Org has the responsibility for creating policy from these recommendations, but I also believe that in cases of IRT dispute, Council does specifically have authority to resolve.

So, before we put more work into this can you and Dennis educate the IRT on the process and let the IRT know if Council does have the authority to resolve this dispute?


Thanks
Roger


________________________________
From: IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org> on behalf of Sebastien at registry.godaddy <Sebastien at registry.godaddy>
Sent: Friday, September 11, 2020 9:46 AM
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.



Thank you all for your comments over the last 2 weeks and the attempts made to clarifying what our message(s)/question(s) to the Council should be.

I am not sure we have a conclusion, but I certainly see material to move forward.



Monday (14 September) is the deadline for me to submit our work to the Council.

After 2 somewhat contradicting verbal reports during the last 2 Council meetings, I am now asked to provide a written report.



I have promised Pam and Rafik, who were extremely helpful to me in this endeavour to run my submission past them first.

Given their Geographic location, I would like this to be sent to them by 00:00 UTC on Monday at the very latest.

I also remain committed to the group, not to share anything externally that hasn’t not been first vetted by the group.



With this in mind and in an attempt to get a statement approved by the group in the next 48 hours, may I suggest to?



  *   Take Amr’s questions with Roger’s rewording:
     *   if the Council believes there is no conflict between Rec 7 and the Thick WHOIS Policy then the recommendation language is correctly added back in as stated in the recommendation, and;
     *   if the Council believes there is a conflict between Rec 7 and the Thick WHOIS Policy then Council should provide direction on how to resolve the perceived conflict.
  *   I would then like to the provide background information I initially prepared for the “Proposed path forward” document I emailed on 10 August (see attached); the first 2 pages of the document only.
  *   I would also include Roger’s suggested language as emailed to the list on 2 September, as well as Alex’s Scenarios 1 & 2 as shared on 3 September; to ensure we offer a good view of the breath of points of views within the group.



I’ll compile this in the next few hours for the group’s review.





Stephanie, Brian and Theo, I hear all the pros and cons regarding B&B and other legal arguments, but frankly I don’t have the legal depth be able to assess any of it; and I am not sure the Council does either. I am happy to reference it, but I can’t peg anything on it.

Sarah, Marc and Rubens, and everyone else who participated, thank you for your valuable input.



Kindly,





Sebastien Ducos

GoDaddy Registry | Senior Client Services Manager

[signature_1159238717]

+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://www.linkedin.com/in/sebastienducos>





From: "IRT.RegDataPolicy" <irt.regdatapolicy-bounces at icann.org> on behalf of Theo Geurts <gtheo at xs4all.nl>
Date: Friday, 11 September 2020 at 2: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.



Makes sense Roger, thanks.

Theo

Op 11-9-2020 om 13:22 schreef Amr Elsadr:

Hi,



Yes…, this strikes me as the logical follow-up to an answer to this question by the GNSO Council, and support its inclusion. Sounds good to me.



Thanks.



Amr



On Sep 11, 2020, at 1:13 PM, Roger D Carney <rcarney at godaddy.com<mailto:rcarney at godaddy.com>> wrote:



Good Morning,



+1 Amr, I was thinking along the same lines of a question.



But I also think it is important to know if everyone in the IRT (including staff) is supportive of the outcome, before taking this question forward. And what I mean by that is:

  *   if the Council believes there is no conflict between Rec 7 and the Thick WHOIS Policy then the recommendation language is correctly added back in as stated in the recommendation, and;
  *   if the Council believes there is a conflict between Rec 7 and the Thick WHOIS Policy then Council should provide direction on how to resolve the perceived conflict.

I also think that if the IRT supports these outcomes then these outcomes should be part of the question as well, so as to aid the Council in making their decision.



Thoughts?





Thanks

Roger





________________________________

From: IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org<mailto:irt.regdatapolicy-bounces at icann.org>> on behalf of Amr Elsadr <aelsadr at icannpolicy.ninja<mailto:aelsadr at icannpolicy.ninja>>
Sent: Friday, September 11, 2020 4:38 AM
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,

If I’m not mistaken, we’re quickly running out of time to meet the deadline to submit a question to the GNSO Council in time for its September meeting. Sebastian will likely need us to come to some kind of conclusion on how to interact with the Council on by Monday. If I’m not mistaken, identifying reaching this conclusion is the primary objective of this thread.

Like others, I don’t believe asking the Council to adjudicate on the existence (or the lack thereof) of a valid legal basis to transfer Registration Data from Registrars to Registries is the best approach. Instead, and perhaps more appropriately, should we ask the GNSO Council to provide guidance on whether it believes there is a conflict between the “thick” Whois Policy and Recommendation #7 in the EPDP Phase 1 Final Report?

This question seems to be at the heart of the disagreement among members of the IRT, and sounds to me like something the Council would be better suited to provide guidance on.

Thanks.

Amr

> On Sep 10, 2020, at 9:16 PM, Rubens Kuhl <rubensk at nic.br<mailto:rubensk at nic.br>> wrote:
>
> Alex,
>
> That assumption is wrong. A legal basis is also required in the Thick WHOIS policy, as listed inhttps://www.icann.org/resources/pages/thick-whois-transition-policy-2017-02-01-en
>
> Implementation Note
> Where a conflict exists between local privacy laws and requirements included in this Policy, ICANN Procedure for Handling WHOIS Conflicts with Privacy Law is available for Registry Operators and Registrars
>
> Deference to laws are also present in the RAA and RA. Since we are talking about data from registrars, this is the RAA section:
> https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en
>
> 3.7.2 Registrar shall abide by applicable laws and governmental regulations.
>
> So if everything is already constrained by law, saying a new policy is also constrained by law changes nothing.
>
>
> Rubens
>
>
>
>
>> On 10 Sep 2020, at 14:15, Alex Deacon <alex at colevalleyconsulting.com<mailto:alex at colevalleyconsulting.com>> wrote:
>>
>> Again let's not overcomplicate things.
>>
>> I appreciate the argument that we should keep the "provided an appropriate legal basis exists" language as that the IRT is not empowered to amend policy recommendations adopted by the GNSO Council and the ICANN Board.
>>
>> It has also been stated numerous times that a legal basis doesn't exist.  (As you know I don't agree but whatever...)
>>
>> So I'm simply pointing out that if we include that language in the one doc the IRT explicitly amends policy recommendations adopted by the GNSO Council and the ICANN board (Thick WHOIS) which everyone is admonishing me not to do.
>>
>> This is the jam we are in - don't kill the messenger.
>>
>> Alex
>>
>>
>>
>>
>> ___________
>> Alex Deacon
>> Cole Valley Consulting
>> alex at colevalleyconsulting.com<mailto:alex at colevalleyconsulting.com>
>> +1.415.488.6009
>>
>>
>>
>> On Wed, Sep 9, 2020 at 2:23 PM Rubens Kuhl <rubensk at nic.br<mailto:rubensk at nic.br>> wrote:
>>
>>
>>> On 9 Sep 2020, at 15:10, Sarah Wyld <swyld at tucows.com<mailto: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.
>>>
>>
>> And if the IPT tries removing that language without an IRT consensus, this would be fast grounds to an RfR or to an IRP.
>>
>> If the legal basis exists, there is no problem in keeping the exact recommendation language since it always be true, right ?
>>
>>
>> Rubens
>>
>>
>> _______________________________________________
>> IRT.RegDataPolicy mailing list
>> IRT.RegDataPolicy at icann.org<mailto: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<mailto: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.<signature.asc>


_______________________________________________
IRT.RegDataPolicy mailing list
IRT.RegDataPolicy at icann.org<mailto: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<mailto: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/20200911/042154e4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-signature_.png
Type: image/png
Size: 52021 bytes
Desc: Outlook-signature_.png
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20200911/042154e4/Outlook-signature_-0001.png>


More information about the IRT.RegDataPolicy mailing list