[Gnso-epdp-team] Recommendation on privacy/proxy data.
Alan Woods
alan at donuts.email
Tue Feb 5 10:40:38 UTC 2019
Thanks all for a thorough back and forth on this! I find the conversation
has moved on in my day's absence ! Reviewing the thread, I do find myself
in line with the NCSG viewpoint of this, and indeed with Alan's last
statement on this.
1) Identification of the Data Subject is no longer limited to from within
the data set of the controller, but whether there are other avenues, which
in the time of 'big data' and 'advanced research methods', can identify the
data subject from other data also available out there. The risk can be
certainly lowered, where that other data is not ordinarily available, or
the data is beyond the reach of such research methods, but when we are
talking about registrants of domain names, and where such domain names
usually are associated with websites, there is a much larger likelihood
that identification or the data necessary to identify the data subject is
present. [Need I remind that in this sphere, all it takes is 1 complaint
from an aggrieved data subject to start the cycle of pain] For our purposes
that's enough, there are currently too many variables and potentials, and
whereas 'big hitter' like Microsoft may (perhaps erroneously) deem their
own risk is acceptable, that's their choice, but we cannot take the choice
away. Smaller more financially exposed CPs might not be so 'sure'. The
simple fact is where we are unable to demonstrate how we actually control
the risk, we cannot make policy tending towards the reckless enhancement
the risk of the CPs.
2) Ayden has provide a very solid example of how the law has evolved on
this matter, and I must disagree with Hadia's interpretation of both the
GDPR and ECJ jurisprudence on this. I believe Ayden's interpretation to be
more closely aligned with the Court's stance.
3) Alan G's final point is that "*Why not leave it to the registrar to
decide*". I believe, as we are prone to do in such conversations, come full
circle. I therefore restate my suggested permissive wording, allowing for a
registrar (or registry) to publish, where like for instance Microsoft, that
they believe that their risk is acceptable.
RECOMMENDATION XX
*In the case of a domain name registration where a privacy/proxy service
used (e.g. where data associated with a natural person is
masked), Registrar (and Registry where applicable) MAY include in the
public WHOIS and return in response to any query full WHOIS data, which may
also include the existing privacy/proxy pseudonymized email.*
(NOTE: to your original point Alex, this does not render the recommendation
useless,as our experience with ICANN compliance is such that what ICANN
policy permits, is equally as important as what policy prohibits .)
Great conversation all!
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 Tue, Feb 5, 2019 at 2:04 AM Alan Greenberg <alan.greenberg at mcgill.ca>
wrote:
> Ayden, Why not leave it to the registrar to decide. We have heard an awful
> lot about potential for contracted party risk. They can make their own
> decision. And those who have already implemented secure anonymized e-mail
> do not have to scrap it and implement something completely new, as they
> would if we follow your suggestion.
>
> Alan
>
>
> At 04/02/2019 08:00 PM, Ayden Férdeline wrote:
>
> Hi Alan G.,
>
> I happen to agree that this could be an implementation issue. However, we
> must balance the cost of implementing such a complex system and rolling it
> out globally against the benefits to registrants, who are ultimately those
> who will bare its cost. In light of this consideration, and in recognizing
> the harm that could arise from an improper implementation, I cannot find
> myself supporting this proposal. I see no benefit to the registrant of the
> publication of a pseudonymised email that would not otherwise be achieved
> by making them contactable through a web form.
>
> Kind regards,
>
> Ayden Férdeline
>
>
> †††††††Original Message ††††††â€
> On Monday, February 4, 2019 7:19 PM, Alan Greenberg <
> alan.greenberg at mcgill.ca> wrote:
>
> That *may* apply in some cases but certainly not all. There are European
> registrars that use anonymized addresses that change regularly (such as
> weekly, daily or oftener). There is no way to correlate them with
> previously published data.
>
> It also addresses the worry that the anonymized address can be used for
> SPAM.
>
> This is an implementation issue. Each registrar can use a technique which
> meets their needs and reduces their risk.
>
> Alan
>
>
>
> At 04/02/2019 06:20 PM, Ayden Férdeline wrote:
>
> I agree with Milton̢۪s interpretation.
>
> We also have case law that can help us understand the meaning of where
> pseudonymisation is “reasonably likely†to lead to the ide
> identification of a data subject.
>
> In *Breyer v Germany*, the Court of Justice of the European Union̢۪s
> ruling mirrors much of the de debate we are having here, and it found that
> pseudonymized data is almost always personal data. (While this case was a
> judgment on the 1995 Data Protection Directive and not the GDPR, the text
> of Recital 26 in the GDPR and in the Directive differ very little in
> substance.)
>
> In light of this, and given the relative ease with which historical WHOIS
> records can be retrieved, I believe it is only prudent that pseudonymised
> email addresses are not published.
>
> Best wishes,
>
> Ayden
>
>
> ††††††¬ †Original Message ††â€Ã¢€ †â€
> â€
> On Monday, February 4, 2019 1:57 PM, Mueller, Milton L <milton at gatech.edu>
> wrote:
>
>
> Marc:
>
>
>
> I have paraphrased this as:
>
>
>
> “If a processor were to publish or disclose multltiple personal data,
> one of which was a pseudonym, and if that collection of data could be used
> to render the pseudonym identifiable, then the pseudonym would be
> considered to be personal data. However, if the processor were to publish
> a pseudonym, and a third party were to subsequently locate additional data,
> available from different processors or even from the same processor in a
> different context, and were then able to use these separate data to unmask
> the pseudonym and render it identifiable, such third party correlation
> ability would NOT require the processor to treat the pseudonym as personal
> data.â€
>
>
>
>
>
> I don̢۪t find your lawyers̢۪ opinion very conviy convincing, Marc. She
> is saying that even if it̢۪s knownown for a fact that the pseudonym can
> be combined with other data elements that are readily accessible to anyone
> to identify the subject, it is not personally identifiable simply because
> all the data isn̢۪t in one place. Th That doesn̢۪t pass the giggle test.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> * Second, the Whois DOES publish additional, multiple personal data, such
> as country, state, city, nameserver, domain name, etc. all of which when
> combined could be used to identify. Dr. Milton L Mueller Professor,
> School of Public Policy <http://spp.gatech.edu/> Georgia Institute of
> Technology Internet Governance Project http://internetgovernance.org/
> <http://internetgovernance.org/> /marksv From:* Gnso-epdp-team <
> gnso-epdp-team-bounces at icann.org> *On Behalf Of *Alex Deacon
> *Sent:* Saturday, February 2, 2019 11:57 AM
> *To:* Alan Woods <alan at donuts.email>
> *Cc:* EPDP <gnso-epdp-team at icann.org >
> *Subject:* Re: [Gnso-epdp-team] Recommendation on privacy/proxy data.
>
>
>
> Thanks Alan. As always I appreciate your input and views. A few thoughts
> and questions on your proposed solution.
>
>
>
> First, given all of the "MAYs" in your suggested update, it is not clear
> to me how this will be translated in the implementation phase.
> Specifically it is a no-op from a compliance point of view. I understand
> this may be the main reason for your update, but we end up with a
> Recommendation with little value.
>
>
>
> Second, given the general agreement that we avoid "squishy" language in
> our purposes and recommendations, the language you propose is unclear (to
> me at least). If a Registrar or Registry decides to not return P/P data or
> the "existing p/p pseudonymized email†does that mean no email adddress
> will be available in a public response? If so that seems to go against our
> existing Contractibility purpose (Purpose 3). (Alan G made this point I
> believe.) Or does this language assume that there will be a Registrar
> pseudonymized email that points to a P/P pseudonymized email? Both seem
> problematic.
>
>
>
> Third, regarding the language you point out in Recital 26 of the GDPR, its
> not clear to me it applies in the privacy/proxy context, where the only the
> psuedonymized email could be seen as personal. Perhaps this would be a
> good question to pose to Ruth. From what I understand if a processor were
> to publish or disclose multiple personal data, one of which was a
> pseudonym, and if that collection of data could be used to render the
> pseudonym identifiable, then the pseudonym would be considered to be
> personal data. For responses that only included P/P data this wouldn't be
> the case.
>
>
>
> Fourth, I appreciate your concern that it may not be possible to figure
> out a P/P provider and suggest we can use the language in the RAA (Section
> 2) to be more specific here - essentially limit it (for now) to affiliated
> services. e.g. “For any Proxy S Service or Privacy Service offered by
> the Registrar or its Affiliates, including any of Registrar's or its
> Affiliates' P/P services distributed through Resellers, and used in
> connection with Registered Names Sponsored by the Registrar,". In the
> future, and once the PPIRT completes, all accredited P/P services will be
> flagged in RDS/WHOIS (PPSAI Recommendation 4) so this issue will be
> solved.
>
>
>
> Finally, I continue to believe we can find a pragmatic solution where we
> eliminate (or perhaps minimize) the situation where P/P data is returned in
> response to a "reasonable disclosure" request. It is a very inefficient
> use of time/cycles for both the requestor and person responsible for
> manually processing these requests. This was the main reason for the Temp
> Spec language and this new Recommendation. If we can't address this issue
> in this new Rec then perhaps language needs to be added to Rec 12 to
> address this case....
>
>
>
> Apologies for the long email.
>
>
>
> Alex
>
>
>
>
>
> ___________
>
> *Alex Deacon*
>
> Cole Valley Consulting
>
> alex at colevalleyconsulting.com
>
> +1.415.488.6009
>
>
>
>
>
>
>
> On Fri, Feb 1, 2019 at 4:47 AM Alan Woods <alan at donuts.email> wrote:
>
> Thank you Alex for reopening this matter.
>
> From a practicality POV the inclusion of a pseudonymised email in a
> publication is a disclosure of public data, as a pseudonymised email, is
> still an email for a data subject. It may be in a form the data subject
> does not recognize, but I believe a number of excellent and practical
> examples, such as auto-relay / auto out of office responses could easily
> identify the non-pseudonymised email and lead to identification of the Data
> Subject.
>
> I refer you recital 26 of the GDPR:
>
> "…Perrsonal data whiich have undergone pseudonymisation, which could be
> attributed to a natural person by the use of additional information should
> be considered to be information on an identifiable natural person..."
>
>
> Alas the recommendation as worded, although I understand the practicality
> that is driving it, does not properly address data protection concerns.
> There is a lot of back and of forth possible on whether pseudonymisation
> may count as anonymization when published to a 3rd party, however in the
> context of Domain Names, where the domain name, and even the associated
> content, could be capable of linking the individual to the pseudonymised
> data (which is completely outside of outside of our control, but still
> relevant to our risk assessment), we need to tread carefully; more
> carefully than the ePDP has either the time or the scope to consider.
>
> To refer again to our goal : We must look to the state of the data that is
> in the RDDS currently, and whether the publication of individual data
> currently used would be data protection compliant or not. In its current
> state, with the myriad the uncertainties, it is not, therefore our
> recommendation must be not to publish.
>
> SOLUTION
>
> Allow the registrar / registry to consider (as Controller) the feasibility
> and the risk as it applies to them? Unless we, at this late stage, the ePDP
> can provide an actual means or suggestion as to implementation of how a
> registrar / registry can effectively figure out who is a P&P provider and
> thus publish those only details without an increase to risk, then our
> choice is plain.
>
> If the recommendation is to stand, use of MAY, and other permissive
> language, as opposed to a 'must' will allow each CP to assess the risk as
> they see it, as it all comes down to the fact that the ePDP cannot force
> the CPs to assume higher risk to appease some.
>
>
>
> Recommendation XX
>
> In the case of a domain name registration where a privacy/proxy service
> used (e.g. where data associated with a natural person is masked),
> Registrar (and Registry where applicable) MAY include in the public WHOIS
> and return in response to any query full WHOIS data, which may also include
> the existing privacy/proxy pseudonymized email.
>
>
>
> Kind regards,
>
> Alan
>
>
>
>
>
> Alan Woods
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> Senior Compliance & Policy Manager, Donuts Inc.
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> ------------------------------
>
>
>
>
>
>
>
>
> The Victorians,
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> 15-18 Earlsfort Terrace
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0> Dublin
> 2, County Dublin
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
> Ireland
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> 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.
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> On Fri, Feb 1, 2019 at 12:57 AM Alex Deacon
> <alex at colevalleyconsulting.com> wrote:
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
>
> All,
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> Our review of ICANN's input on Temp Spec topics that were not covered by
> the Initial Report reminded me that we had at one point discussed ensuring
> that the current Temp Spec language on how Privacy/Proxy data should be
> handled (Appendix A 2.6) should added as a recommendation. Something
> along the lines of -
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
>
> Recommendation XX
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> In the case of a domain name registration where a privacy/proxy service
> used (e.g. where data associated with a natural person is masked),
> Registrar MUST include in the public WHOIS and return in response to any
> query full WHOIS data, including the existing privacy/proxy pseudonymized
> email.
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> There are two reasons why this is useful, IMO.
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> First, given the time and effort needed to properly process "reasonable
> disclosure" requests by Registrars it seems useful to avoid a situation
> where non-public data is quickly found to be P/P service data. Avoiding
> this situation and simply including P/P data in the the initial response
> would make life better for all involved.
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> Second, there is no need to redact information that is already "redacted"
> (by definition) by the P/P service. Also, given P/P services list the
> information of a legal person (in the case of a registrar affiliated
> service provider) in the place of the RNH's info it seems further redaction
> is unnecessary.
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> Happy to discuss further on a future call.
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> Thanks.
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> Alex
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> ___________
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> Alex Deacon
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> Cole Valley Consulting
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> alex at colevalleyconsulting.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
>
> +1.415.488.6009
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Ccd7ec2e952744fc76eb608d68948bdc7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636847342852603079&sdata=QwaxAMupO7ehwbSmN9I%2FFKwgNNr%2FP0th2kuQW6EHb9U%3D&reserved=0>
> _______________________________________________ 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/20190205/9f01a661/attachment-0001.html>
More information about the Gnso-epdp-team
mailing list