[IRT.RegDataPolicy] Re. 18 9.5.4.2
Sarah Wyld
swyld at tucows.com
Mon Oct 21 15:21:27 UTC 2019
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> *On
> Behalf Of *Theo Geurts
> *Sent:* Thursday, October 17, 2019 8:42 AM
> *To:* Sarah Wyld <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 <mailto:lseufer at namespace.com>
>
>
>
>
>
> _______________________________________________
>
> 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=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 <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=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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20191021/4a9feffd/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/irt.regdatapolicy/attachments/20191021/4a9feffd/signature.asc>
More information about the IRT.RegDataPolicy
mailing list