[IRT.RegDataPolicy] Re. 18 9.5.4.2

Thu Oct 24 12:12:54 UTC 2019

+1 Sarah and Luc

On Wed, Oct 23, 2019 at 4:38 AM Luc SEUFER <lseufer at namespace.com> wrote:

> Morning Sarah,
>
>
>
> I agree with you, we could do without it.
>
>
>
> Luc
>
>
>
>
>
> *From: *"IRT.RegDataPolicy" <irt.regdatapolicy-bounces at icann.org> on
> behalf of Sarah Wyld <swyld at tucows.com>
> *Organisation: *Tucows
> *Date: *Monday, 21 October 2019 at 17:19
> *To: *"King, Brian" <Brian.King at markmonitor.com>, Theo Geurts <
> gtheo at xs4all.nl>, "irt.regdatapolicy at icann.org" <
> irt.regdatapolicy at icann.org>
> *Subject: *Re: [IRT.RegDataPolicy] Re. 18 9.5.4.2
>
>
>
> Good morning all,
>
> I'm happy with a more general "if the request is denied, there needs to be
> an explanation" type of requirement -- which is exactly what we have in
> 9.5.4 itself. It seems to me like 9.5.4.2 was written specifically to
> accommodate an example provided in the Rec 18 text, but it is unnecessarily
> specific and can be removed entirely without losing anything valuable from
> our Policy text.
>
> Thanks,
>
> --
>
> Sarah Wyld
>
> Domains Product Team
>
> Tucows
>
> +1.416 535 0123 Ext. 1392
>
>
>
>  On 10/20/2019 4:33 PM, King, Brian wrote:
>
> How about simply, “If the Registrar or Registry Operator denies a request,
> the Registrar or Registry Operator MUST…” ?
>
>
>
> An explanation is warranted for any given denial, and every other grounds
> for denial would actually be much easier to articulate than 6.1.f.
>
>
>
> *Brian J. King *
> Director of Internet Policy and Industry Affairs
>
>
>
> T +1 443 761 3726
> * markmonitor.com <http://www.markmonitor.com>*
>
>
>
>
> *MarkMonitor *Protecting companies and consumers in a digital world
>
>
>
> *From:* IRT.RegDataPolicy <irt.regdatapolicy-bounces at icann.org>
> <irt.regdatapolicy-bounces at icann.org> *On Behalf Of *Theo Geurts
> *Sent:* Thursday, October 17, 2019 8:42 AM
> *To:* Sarah Wyld <swyld at tucows.com> <swyld at tucows.com>;
> irt.regdatapolicy at icann.org
> *Subject:* Re: [IRT.RegDataPolicy] Re. 18 9.5.4.2
>
>
>
> I agree with most of your points, Luc.
>
> I also think that the current language could result in a request bomb by
> automated systems.
>
> Regarding the less professional actors who will use the balancing act to
> game the system, that is pure criminal behavior, and we have laws to deal
> with such "actors."
>
> @Sarah very valid points. I like the changes.
>
> I am not sure how this all will work with resellers and wholesale
> registrars. At the moment I leave the disclosure requests to the resellers
> who act as the data controller for the registrant data.
>
> Theo
>
>
>
> On 17-10-2019 14:27, Sarah Wyld wrote:
>
> Thanks Luc for putting this in writing, it's a good explanation.
>
> I would support a change like the proposed one, indicating that the
> explanation should be limited such that it does not infringe on the data
> subject's rights.
>
> Related -- it does seem a bit odd to refer to one specific Article of the
> GDPR and then also say "or other privacy legislation". The balancing test
> is only from 6(1)f, not from other legislation also. Personally I would say
> that we should try to be regulation-agnostic instead of referring to the
> GDPR specifically, but since I think many IRT members wouldn't support
> removing that sentence entirely, perhaps we can remove the "or other
> privacy legislation" bit?
>
> With both Luc's and my changes, we'd end up with:
>
> 9.5.4.2 If the Registrar or Registry Operator denies a request under
> Article 6(1)(f) of GDPR, the Registrar or Registry Operator MUST explain to
> the fullest extent possible how the balancing test was applied, without
> infringing upon the data subject's right to privacy.
>
> Looking forward to feedback, thank you.
>
> --
>
> Sarah Wyld
>
> Domains Product Team
>
> Tucows
>
> +1.416 535 0123 Ext. 1392
>
>
>
>  On 10/17/2019 5:59 AM, Luc SEUFER wrote:
>
> Hi Brian, Susan et alia,
>
>
>
> As I don’t think I was quite eloquent in my explanation regarding my
> concerns as to the current wording of 9.5.4.2, please allow me to have a
> second try in writing.
>
>
>
> Recommendation 18 states that
>
>
>
> *“Responses where disclosure of data (in whole or in part) has been denied
> should include: rationale sufficient for the requestor to understand the
> reasons for the decision, including, for example, an analysis and
> explanation of how the balancing test was applied (if applicable)”*
>
>
>
> The current wording states
>
>
>
> *“If the Registrar or Registry Operator denies a request under Article
> 6(1)(f) of GDPR or other privacy legislation, the Registrar or Registry
> Operator MUST explain how the balancing test was applied.”*
>
>
>
>
>
> My issue with this wording -asides from the fact that it goes a tad astray
> from the recommendation - is that it would require us to be too detailed in
> our explanation of the balance test failure.
>
>
>
> The disclosure constitutes a data processing act between the data
> controller (CPH) and a third party (the requestor). Asides from the
> guarantees the requestor will have to give and the obligations they will
> have to accept to become a processor; the first element to examine is the
> lawfulness of the processing.
>
> In this case, the legal basis is the legitimate interest of the requestor,
> which shall be subject to strict scrutiny. (This also why I said in regards
> to 9.3.2 that the CPH will always need to know the jurisdiction of the
> requestor.)
>
>
>
> The outcomes of the balancing test will depend on several elements, which,
> if explained in too much detail to the requestor, will prove problematic.
>
>
>
> For example, in the case of a blogger criticizing a government, a
> political party, government, religion...  the fact that the requestor is
> based in a country where such critics could lead to a death sentence  would
> definitely lead to a failed test. As you can imagine going in so much
> details would go against the right to privacy of the registrant.
>
>
>
> Similarily in case, a registrant would have registered a domain name for a
> future business venture, and the requestor is one of their competitors, the
> reason for the balance test failure cannot be disclosed.
>
>
>
> Those are just two examples I have encountered and we are only a
> medium-size registrar. I am sure other CPs would have many similar ones.
>
>
>
> This being said, I suppose you fear that modifying this provision could
> open a door for some "less professional" actors to automatically reply that
> the balance test failed without even conducting one.  Howevever, I think
> this can be averted by modifying the clause as follows:
>
>
>
> "If the Registrar or Registry Operator denies a request under Article
> 6(1)(f) of GDPR or other privacy legislation, the Registrar or Registry
> Operator shall explain the reasons for the denial as much as possible
> without breaching its obligations vis-a-vis the privacy rights of the
> Registrant."
>
>
>
> Luc
>
>
>
> ______________
>
>
>
>
> Luc Seufer
> Chief Legal Officer
> Namespace
>
> 21, rue Léon Laval
> L-3372 Leudelange
> Luxembourg
>
> Tel.: +352 27 220 166
> Mobile: +352 691 600 417
> Fax.: +352 20 300 166
> Mailto: lseufer at namespace.com
>
>
>
>
>
>
> _______________________________________________
>
> 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=DwMDaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=TKn_SBXpvb-EKwigl8XoeBI3Z9irIEPMeZaSt3z_zts&s=Fqs3p1ymQqHTiViP2PVFPohjJY4GLn2YWSGzuX0O_5w&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=DwMDaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=TKn_SBXpvb-EKwigl8XoeBI3Z9irIEPMeZaSt3z_zts&s=9cntesqDYPevlqG3idcrvLZu5XURM_e2_mGQQ7swtoM&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=DwMDaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=TKn_SBXpvb-EKwigl8XoeBI3Z9irIEPMeZaSt3z_zts&s=kLxuBkPiXx23L_xzuqRZGWQH_yNginYKXkEbuveiMYw&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=DwMDaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=TKn_SBXpvb-EKwigl8XoeBI3Z9irIEPMeZaSt3z_zts&s=Fqs3p1ymQqHTiViP2PVFPohjJY4GLn2YWSGzuX0O_5w&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=DwMDaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=TKn_SBXpvb-EKwigl8XoeBI3Z9irIEPMeZaSt3z_zts&s=9cntesqDYPevlqG3idcrvLZu5XURM_e2_mGQQ7swtoM&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=DwMDaQ&c=OGmtg_3SI10Cogwk-ShFiw&r=qQNCXqU_XE2XIdXbawYmk-YDflYH6pd8ffXlzxU37OA&m=TKn_SBXpvb-EKwigl8XoeBI3Z9irIEPMeZaSt3z_zts&s=kLxuBkPiXx23L_xzuqRZGWQH_yNginYKXkEbuveiMYw&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
>
> _______________________________________________
> 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/20191024/f8f39c8d/attachment.html>