[Gnso-epdp-team] RrSG Comment on Recommendation 10
alan at donuts.email
Fri Feb 1 10:34:28 UTC 2019
Thank you Greg and our SSAC colleagues for this,
However, with my privacy lawyer hat on, can we actually remind ourselves
here of the goal. The Goal here is to simply confirm that the registrar has
relayed the requestors communication.
The suggestion from our SSAC colleagues, has the Registrar, not only
maintaining this log, but creating a database of requestor data, email
addresses, metadata, and, for good measure, a positive obligation to
further monitor responses from those emails sent, so as to initiate an
action which may result in a suspension of a domain name.
Outside of the fact that a system of this size is likely complex and cost
prohibitive to smaller registrars, it ignores necessity and data
minimization and alas fails the privacy by default and privacy by design
tests. I'm sure that the very clever folks at the registrars can come up
with a much simpler and functional system along the lines of:
1. A communication request received is assigned a number e.g. #X
2. The number is provided to the requester (for their own reference) but
the registrars have no need to maintain a record of which requester is
assigned which number, just that request #X is made, and the system has
confirmed its relay of the message associated with #X.
3. Should ICANN compliance wish to test the fidelity of the system, that
is in their purview to do so to ensure the mechanics of the system. None of
the other data or actions are remotely necessary.
4. I would also suggest that we give the registrars a bone here and
state that nothing in our recommendation language should prevent the
registrar from taking appropriate actions to prevent excessive use or abuse
of the registrant contact process.
Now to display how number 4 may be achieved, but also noting that this is
not within ICANN's controllership and therefore outside of the ICANN policy
4a. A Registrar may, at their own discretion, keeps a sufficiently
anonymized log of requests (whereby the system pseudonymizes of somehow
anonymizes personal data of the requester but is capable of logging where
requestor (let's call him Y) has made 30000 requests #X ,#Z etc. This can
then be used to perhaps filter such future requests from that requestor. To
confirm this would be solely at the option of the regsitrar, abased on
their own needs, size, resources etc. The registrar would be controller
here, and ICANN base policy cannot dictate this. This would indeed be a
prudent step for a larger registrar to prevent abuse of the relay system,
and to avoid allegation that they are 'spamming' their registrants.
To that end. I think Sarah's' proposed wording with Kristina's addition
(and perhaps the clarification contained in 4 above) is still wholly
sufficient for the goal and purpose pursued.
[image: Donuts Inc.] <http://donuts.domains>
Senior Compliance & Policy Manager, Donuts Inc.
15-18 Earlsfort Terrace
Dublin 2, County Dublin
Please NOTE: This electronic message, including any attachments, may
include privileged, confidential and/or inside information owned by Donuts
Inc. . Any distribution or use of this communication by anyone other than
the intended recipient(s) is strictly prohibited and may be unlawful. If
you are not the intended recipient, please notify the sender by replying to
this message and then delete it from your system. Thank you.
On Thu, Jan 31, 2019 at 11:25 PM Greg Aaron <greg at illumintel.com> wrote:
> The SSAC team proposes a revised version of #2.
> A goal is to make measurement and compliance activity around this
> contractual requirement possible. The Temp Spec doesn't offer that, and the
> existing proposals don't yet either. The RrSG proposal says that no
> personal data about the activity will retained, and log format or content
> are not specified. If so, how will a registrar demonstrate that a message
> from any requestor was sent to the registrant?
> The below makes clear that the records about forwarding are for
> examination by ICANN Compliance (only). If someone who originated a
> message is concerned, they can make a complaint to ICANN. That is the same
> model that we have now for invalid WHOIS and abuse reporting complaints.
> We also assume that such records will be retained for only an appropriate
> Part of the recommendation below is based on an existing procedure in the
> RAA. so it is familiar. It creates no new personal data transfer, and
> there is already a “P”urpose defined for contracted parties to send
> personal data to Compliance. It does not require the registrar to keep the
> entire email message if they do not want to.
> Proposed text:
> "2) The EPDP Team recommends that Registrars must maintain records that
> demonstrate that the communication from the requestor was relayed by email
> to the Registered Name Holder. This information must include the
> requestor's identity as it was provided to the Registrar, the Registered
> Name Holder's email address, and a timestamp. Such records will be
> available to ICANN for compliance purposes, upon request. If Registrar
> receives a bounced email notification or non-delivery notification message,
> the Registrar must initiate re-verification of the registrant's contact
> data per the RAA's WHOIS Accuracy Program Specification, paragraph 4."
> *From:* Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> *On Behalf Of *Sarah
> *Sent:* Friday, January 25, 2019 4:14 PM
> *To:* gnso-epdp-team at icann.org
> *Subject:* [Gnso-epdp-team] RrSG Comment on Recommendation 10
> Hello All,
> For Recommendation 10, the RrSG has the following proposed new text:
> 1) In relation to facilitating email communication between third parties
> and the Registered Name Holder, the EPDP Team recommends that current
> requirements in the Temporary Specification that specify that a Registrar
> MUST provide an email address or a web form to facilitate email
> communication with the relevant contact, but MUST NOT identify the contact
> email address or the contact itself, remain in place.
> 2) The EPDP Team recommends Registrars MUST maintain Log Files, which
> shall not contain any Personal Information, and which shall contain
> confirmation that a relay of the communication between the requestor and
> the Registered Name Holder has occurred, not including the origin,
> recipient, or content of the message. The registrar cannot be reasonably
> expected to confirm, or attempt to confirm by any means, the receipt of any
> such relayed communication.
> 3) DELETE 3
> Sarah Wyld
> Domains Product Team
> +1.416 535 0123 Ext. 1392
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnso-epdp-team