[Gnso-epdp-team] RrSG Comment on Recommendation 10

[Alex Deacon]

Hi,

I must have read a different email from Greg because I didn't see any
language describing registrar obligations for when a registrant does not
respond to an inbound inquiry.   IMO the crux of the issue is described at
the end of Greg's proposed text for 2).   i.e. " 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."     As
Greg states this ensures measurement and compliance activity around this
contractual requirement is possible - something I very much support.

I'll note we had this same discussion during the PPSAI PDP, where it was
made clear that "failure of “delivery” of a communication is not to be
equated with the failure of a customer to “respond” to a request,
notification or other type of communication.".    In fact I suggest we can
reference/leverage/repurpose the language in Recommendation 17 (Regarding
Further Provider Actions When There Is A Persistent Delivery Failure of
Electronic Communications)  of the PPSAI final report starting on page 14
of
https://gnso.icann.org/sites/default/files/filefield_48305/ppsai-final-07dec15-en.pdf
accordingly.


Thanks.

Alex


___________
*Alex Deacon*
Cole Valley Consulting
alex at colevalleyconsulting.com
+1.415.488.6009



On Fri, Feb 1, 2019 at 10:45 AM Matt Serlin <matt at brandsight.com> wrote:

> I agree with Milton on this…seems like we are opening a can of worms for
> Compliance to investigate every instance of a non-response when in reality,
> non-response by a registrant should absolutely be expected as registrants
> get any number of inquires and have ZERO obligation to respond to anything.
>
>
>
> If registrars start to get compliance requests to investigate why someone
> simply did not respond to an inbound inquiry, we have created an absolute
> nightmare of a policy and my fellow registrar folk will have their
> pitchforks out for their RrSG reps on this group ☺
>
>
>
> ms
>
>
>
> *From: *Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> on behalf of
> "Mueller, Milton L" <milton at gatech.edu>
> *Date: *Friday, February 1, 2019 at 9:37 AM
> *To: *Alan Greenberg <alan.greenberg at mcgill.ca>, Alan Woods
> <alan at donuts.email>, Greg Aaron <greg at illumintel.com>
> *Cc: *GNSO EPDP <gnso-epdp-team at icann.org>
> *Subject: *Re: [Gnso-epdp-team] RrSG Comment on Recommendation 10
>
>
>
> Maybe I do not understand what you are saying, AlanG, but your statement
> below seems mistaken.
>
> Party X sends some kind of a request which is supposed to be relayed to a
> RNH. The registrar forwards it and assign it a number, as AlanW suggests
> below.
>
> Party X gets no response and becomes concerned. They ask ICANN compliance
> to look into the accuracy of the Whois record. Compliance can check the
> full Whois record.
>
>
>
> Further, the concern about “requests not being relayed” is very different
> from “requests being relayed to a non-viable contact address.” The former
> is a registrar failure (and I am not sure WHY exactly a registrar would
> fail to forward a request), the latter is an accuracy problem for which the
> RNH is responsible.
>
>
>
> Seems to me these more complicated procedures for tracking email delivery
> and responses are simply a way for certain private parties to offload the
> costs of their monitoring and enforcement activities onto Registrars (and
> indirectly, RNHs). We oppose that.
>
>
>
> --MM
>
>
>
> *From:* Gnso-epdp-team [mailto:gnso-epdp-team-bounces at icann.org] *On
> Behalf Of *Alan Greenberg
> *Sent:* Friday, February 1, 2019 10:10 AM
> *To:* Alan Woods <alan at donuts.email>; Greg Aaron <greg at illumintel.com>
> *Cc:* GNSO EPDP <gnso-epdp-team at icann.org>
> *Subject:* Re: [Gnso-epdp-team] RrSG Comment on Recommendation 10
>
>
>
> Alan, "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."
> does not give compliance the ability to address complaints that messages
> are seemingly not being relayed (or are being relayed to a non-viable
> contact address).
>
> Alan
>
> At 01/02/2019 05:34 AM, Alan Woods wrote:
>
>
> 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
> reach:
>
> 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.
>
> Kind regards,
>
> Alan
>
>
>
>
>
> Alan Woods
> Senior Compliance & Policy Manager, Donuts Inc.
> ------------------------------
>
> The Victorians,
> 15-18 Earlsfort Terrace
> Dublin 2, County Dublin
> Ireland
>
>   <https://twitter.com/DonutsInc>
> <https://www.linkedin.com/company/donuts-inc>
>
> 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
> term.
>
>
>
> 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 Wyld
>
> 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
>
>
>
> Tucows
>
>
>
> +1.416 535 0123 Ext. 1392
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
>
> Gnso-epdp-team mailing list
>
> Gnso-epdp-team at icann.org
>
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190201/83d03b81/attachment-0001.html>