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

Fri Sep 11 12:30:04 UTC 2020

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
> 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/eba3c7cb/attachment-0001.html>