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@illumintel.com<mailto:greg@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@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Sarah Wyld Sent: Friday, January 25, 2019 4:14 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
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@icann.org] On Behalf Of Alan Greenberg Sent: Friday, February 1, 2019 10:10 AM To: Alan Woods <alan@donuts.email>; Greg Aaron <greg@illumintel.com> Cc: GNSO EPDP <gnso-epdp-team@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@illumintel.com<mailto:greg@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@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Sarah Wyld Sent: Friday, January 25, 2019 4:14 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
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@icann.org> on behalf of "Mueller, Milton L" <milton@gatech.edu> Date: Friday, February 1, 2019 at 9:37 AM To: Alan Greenberg <alan.greenberg@mcgill.ca>, Alan Woods <alan@donuts.email>, Greg Aaron <greg@illumintel.com> Cc: GNSO EPDP <gnso-epdp-team@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@icann.org] On Behalf Of Alan Greenberg Sent: Friday, February 1, 2019 10:10 AM To: Alan Woods <alan@donuts.email>; Greg Aaron <greg@illumintel.com> Cc: GNSO EPDP <gnso-epdp-team@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@illumintel.com<mailto:greg@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@icann.org<mailto:gnso-epdp-team-bounces@icann.org>> On Behalf Of Sarah Wyld Sent: Friday, January 25, 2019 4:14 PM To: gnso-epdp-team@icann.org<mailto:gnso-epdp-team@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@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org<mailto:Gnso-epdp-team@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
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-07dec... accordingly. Thanks. Alex ___________ *Alex Deacon* Cole Valley Consulting alex@colevalleyconsulting.com +1.415.488.6009 On Fri, Feb 1, 2019 at 10:45 AM Matt Serlin <matt@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@icann.org> on behalf of "Mueller, Milton L" <milton@gatech.edu> *Date: *Friday, February 1, 2019 at 9:37 AM *To: *Alan Greenberg <alan.greenberg@mcgill.ca>, Alan Woods <alan@donuts.email>, Greg Aaron <greg@illumintel.com> *Cc: *GNSO EPDP <gnso-epdp-team@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@icann.org] *On Behalf Of *Alan Greenberg *Sent:* Friday, February 1, 2019 10:10 AM *To:* Alan Woods <alan@donuts.email>; Greg Aaron <greg@illumintel.com> *Cc:* GNSO EPDP <gnso-epdp-team@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@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@icann.org> On Behalf Of Sarah Wyld
Sent: Friday, January 25, 2019 4:14 PM
To: gnso-epdp-team@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@icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
Thank you Matt and Milton, I believe you are both correct on this. @Alex this still equates to a positive obligation on the registrar to monitor for response and a new system and is the creation of a procedure that is outside the envisaged scope of the recommendation, which is merely that a registrar will pass on a communication, and log that they have attempted same; a simple task that has been unnecessarily complicated. Alan [image: Donuts Inc.] <http://donuts.domains> Alan Woods Senior Compliance & Policy Manager, Donuts Inc. ------------------------------ The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland <https://www.facebook.com/donutstlds> <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 Fri, Feb 1, 2019 at 8:58 PM Alex Deacon <alex@colevalleyconsulting.com> wrote:
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-07dec... accordingly.
Thanks.
Alex
___________ *Alex Deacon* Cole Valley Consulting alex@colevalleyconsulting.com +1.415.488.6009
On Fri, Feb 1, 2019 at 10:45 AM Matt Serlin <matt@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@icann.org> on behalf of "Mueller, Milton L" <milton@gatech.edu> *Date: *Friday, February 1, 2019 at 9:37 AM *To: *Alan Greenberg <alan.greenberg@mcgill.ca>, Alan Woods <alan@donuts.email>, Greg Aaron <greg@illumintel.com> *Cc: *GNSO EPDP <gnso-epdp-team@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@icann.org] *On Behalf Of *Alan Greenberg *Sent:* Friday, February 1, 2019 10:10 AM *To:* Alan Woods <alan@donuts.email>; Greg Aaron <greg@illumintel.com> *Cc:* GNSO EPDP <gnso-epdp-team@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@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@icann.org> On Behalf Of Sarah Wyld
Sent: Friday, January 25, 2019 4:14 PM
To: gnso-epdp-team@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@icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
_______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
Dear EPDP Team: Thank you for your discussion and proposed resolution of Recommendation 10 (email communication). In an effort to bring this issue to a close, we are proposing a potential path forward below. The updated language includes both an addition from SSAC (records will be made available to ICANN compliance) as well an addition from the RySG (registrars may take reasonable and appropriate action to prevent abuse). We also note Recommendation 3 specifically provides that the EPDP Team’s work shall not affect the accuracy of registration data under the current ICANN contracts and consensus policies. Accordingly, registrars are still required to reverify a registered name holder’s email address if the registrar receives information suggesting that the contact information is incorrect. This would include a bounced email notification or non-delivery notification message in response to a registrar-initiated communication. As this requirement can be found in paragraph 4 of the Whois Accuracy Program Specification in the RAA, the request to add this requirement to the language of the recommendation is unnecessary. As you review the below language, please keep in mind the principles agreed in Toronto: (1) registrars have to maintain log files associated with the transmission of communications from the Registrar to the Registered Name Holder, and (2) ICANN Compliance could then enforce the maintenance of log files if a complaint is filed. Please review this revised wording with your groups in preparation for tomorrow’s call. If the revised language, which is bold for emphasis, presents any issues, please note the issue to the list and prepare a proposed resolution to be discussed during tomorrow’s call. 1) The EPDP Team recommends that the 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. 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. Such records will be available to ICANN for compliance purposes, upon request. Nothing in this recommendation should be construed to prevent the registrar from taking reasonable and appropriate action to prevent the abuse of the registrar contact process. Note: in relation to 1), this matches the requirements in Section 2.5.1 of Appendix A to the Temporary Specification Note: The EPDP notes operational difficulties having to do with contacting registered name holders through webforms (where there is no confirmation that the message sent was received) and pseudonymized email addresses. Therefore, the registrar cannot be reasonably expected to confirm, or attempt to confirm by any means, the receipt of any such relayed communication. It is recommended the GNSO Council initiates work to develop a reliable, safe ways of contacting registrants in cases where their email cannot be displayed. Thank you. Best regards, Marika, Berry, and Caitlin From: Gnso-epdp-team <gnso-epdp-team-bounces@icann.org> on behalf of Alan Woods <alan@donuts.email> Date: Tuesday, February 5, 2019 at 1:50 AM To: Alex Deacon <alex@colevalleyconsulting.com> Cc: GNSO EPDP <gnso-epdp-team@icann.org> Subject: Re: [Gnso-epdp-team] RrSG Comment on Recommendation 10 Thank you Matt and Milton, I believe you are both correct on this. @Alex this still equates to a positive obligation on the registrar to monitor for response and a new system and is the creation of a procedure that is outside the envisaged scope of the recommendation, which is merely that a registrar will pass on a communication, and log that they have attempted same; a simple task that has been unnecessarily complicated. Alan [donuts.domains]Alan Woods Senior Compliance & Policy Manager, Donuts Inc. The Victorians, 15-18 Earlsfort Terrace Dublin 2, County Dublin Ireland [facebook.com] [twitter.com] [linkedin.com] 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 Fri, Feb 1, 2019 at 8:58 PM Alex Deacon <alex@colevalleyconsulting.com> wrote: 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-07dec... [gnso.icann.org] accordingly. Thanks. Alex ___________ Alex Deacon Cole Valley Consulting alex@colevalleyconsulting.com +1.415.488.6009 On Fri, Feb 1, 2019 at 10:45 AM Matt Serlin <matt@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@icann.org> on behalf of "Mueller, Milton L" <milton@gatech.edu> Date: Friday, February 1, 2019 at 9:37 AM To: Alan Greenberg <alan.greenberg@mcgill.ca>, Alan Woods <alan@donuts.email>, Greg Aaron <greg@illumintel.com> Cc: GNSO EPDP <gnso-epdp-team@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@icann.org] On Behalf Of Alan Greenberg Sent: Friday, February 1, 2019 10:10 AM To: Alan Woods <alan@donuts.email>; Greg Aaron <greg@illumintel.com> Cc: GNSO EPDP <gnso-epdp-team@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: A communication request received is assigned a number e.g. #X 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. 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. 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 [twitter.com] [linkedin.com] 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@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@icann.org> On Behalf Of Sarah Wyld Sent: Friday, January 25, 2019 4:14 PM To: gnso-epdp-team@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team _______________________________________________ Gnso-epdp-team mailing list Gnso-epdp-team@icann.org https://mm.icann.org/mailman/listinfo/gnso-epdp-team
participants (6)
-
Alan Greenberg -
Alan Woods -
Alex Deacon -
Caitlin Tubergen -
Matt Serlin -
Mueller, Milton L