Thanks, Rod and apologies for the crossed wires. I would like to suggest that the DT focuses on the version that you just circulated and ignores mine. It may be worth though considering including the footnote to address Ayden’s main concern concerning the list of users – would that be acceptable? As a reminder, the proposed language of the footnote is as follows: “The DT recognizes that the list of users will ultimately need to be narrowly defined to allow for authorized / authenticated access to agreed upon data elements. This applies to all instances in this document where users are mentioned”. Best regards, Marika From: Rod Rasmussen <rod@rodrasmussen.com> Date: Thursday, November 9, 2017 at 12:14 To: Marika Konings <marika.konings@icann.org> Cc: Richard Leaning <rleaning@ripe.net>, "gnso-rds-pdp-7@icann.org" <gnso-rds-pdp-7@icann.org> Subject: [Ext] Re: [Gnso-rds-pdp-7] Proposed roll-up purposes Ugh, I just got done drafting THIS version of the document incorporating the things we’d discussed and some of Ayden’s language that helped make the statements more clear. I don’t have time to reconcile the two right now, but the reordering under purposes we discussed and the explanatory language prior to the details are the most important things from my angle. Most of Ayden’s comments/edits fell into what I would call “questions” or “re-factoring to fit into a particular view on how things should be rather than are” so they were left unaddressed at this stage. Happy to talk further about things like accreditation, appropriate data for purposes etc. in future stages, but what’s in there now is what is actually being done and should be presented that way whether it is eventually agreed to or not - those are policy decisions we need to weigh in on. Just a side note on one change - being a white man married to a black woman, I find the whole idea that terms of art like whitelist/blacklist/graylist are somehow offensive racially is just plain silly. That being said, I changed the white list term to “allow list” which is an actual term of art - safelist is not in this context that I’m aware of (no one would publish a “safe” list since that could create a major liability problem). Marika, think I could impose upon you to merge these two versions? Thanks! Rod On Nov 9, 2017, at 9:19 AM, Marika Konings <marika.konings@icann.org<mailto:marika.konings@icann.org>> wrote: Dear All, Thank you for all your feedback to date. I’ve made an attempt to integrate the different comments in the attached version. Note that I’ve included the overall purpose statements as circulated by Rod to the list. With regards to defining users, I’ve attempted to find a middle way between the different positions expressed by adding the following footnote to the first reference of users: “The DT recognizes that the list of users will ultimately need to be narrowly defined to allow for authorized / authenticated access to agreed upon data elements. This applies to all instances in this document where users are mentioned”. Ayden, Rod, Dick, is this acceptable to reflect that ultimately there will need to be a defined list but that we are not necessarily there yet? I’ve also included some of the edits suggested by Ayden that did not relate specifically to this point but appeared focused on correcting / clarifying some of the language. Ayden, I noticed that you also included a number of questions which hopefully DT members will be able to respond to. Also note that I left references to data elements as they were as this is also an area that will see further discussion (maybe another footnote would be appropriate in that regard to reflect that references to data elements are in certain instances based on what is currently available but in others are assuming innovation / change?). I look forward to receiving your feedback. As noted, the objective is to circulate the final version to the WG by tomorrow so please share your comments as soon as possible. Best regards, Marika From: <gnso-rds-pdp-7-bounces@icann.org<mailto:gnso-rds-pdp-7-bounces@icann.org>> on behalf of Richard Leaning <rleaning@ripe.net<mailto:rleaning@ripe.net>> Date: Thursday, November 9, 2017 at 04:33 To: Rod Rasmussen <rod@rodrasmussen.com<mailto:rod@rodrasmussen.com>> Cc: "gnso-rds-pdp-7@icann.org<mailto:gnso-rds-pdp-7@icann.org>" <gnso-rds-pdp-7@icann.org<mailto:gnso-rds-pdp-7@icann.org>> Subject: Re: [Gnso-rds-pdp-7] Proposed roll-up purposes Dear WG7 I agree with Rod with everything he has posted on this thread. Ayden - I think you have a point but am not sure how we list every single ‘user’ that’s going to be one massive list and we are sure to leave someone of because collective we just don’t know who use’s it. So am happy for now to keep with the wording that Rod as suggested. Cheers Dick Richard Leaning External Relations RIPE NCC On 8 Nov 2017, at 20:01, Rod Rasmussen <rod@rodrasmussen.com<mailto:rod@rodrasmussen.com>> wrote: Ayden, You raise important points that deserve a lot of careful discussion, review, and debate, but for future discussion, not the current “inventory” project of what actually is happening. If anything, the last version of the paper isn’t broad enough in this category, to whit, actors we didn’t list may include nearly anyone attempting to either track down the source of an online abuse they have experienced or attempting to determine the authenticity of a website or e-mail communication. Fake job sites, confidence scams, tax refund ripoffs, bogus escrow services, and a whole host of fraud targeting individual Internet users are constantly being set-up as websites and communicated with via e-mail, SMS, and other messaging services. A very large portion of these are reported to authorities because individuals receiving solicitations do their homework to determine the veracity of a claim. Whois plays a big part in that, as people can use it to see when, where and how a domain involved with these scams is registered and controlled. In my prior work for companies, many of these sites were reported by average customers who did their own research to protect themselves and were thoughtful enough to report it to others for action. We will have plenty of time to debate whether or not continuing to allow people to do this kind of research with the benefit of RDS data fits into privacy laws or not, but that doesn’t change the reality of how things are done today. I strongly encourage us to stick with the facts of what is happening and how people would *like* to use data to create the universe of information we then debate about how they actually *can* use the data in the future. Limiting things now or leaving out important actors, uses, etc. at this stage is moving the debate inappropriately to the fact gathering side of the equation. I don’t believe you were in attendance at the session I presented at in Abu Dhabi (as I wasn’t able to attend others) but a lot of these issues you raise were discussed in that session. In particular, the topics of how fine-grained we need to be vs. creating purposes that don’t stretch on towards infinity were quite interesting to try to get our arms around. Frankly, that is going to be one of the very hardest balances to strike, and we’re going to need to look to how others dealing with GDPR and other privacy requirements end up dealing with similar issues. Our proposal at this point is to present things in these broader buckets as a way of getting a handle on the issues while still preserving the more fine-grained details of who, what, why, etc. different data is accessed so we don’t lose that information should it be required at the end of the process we go through. Cheers, Rod On Nov 8, 2017, at 1:31 AM, Ayden Férdeline <ayden@ferdeline.com<mailto:ayden@ferdeline.com>> wrote: Hi, Apologies that I was unable to attend yesterday's call. I understand that we are not yet at the stage where we are assessing the validity of a purpose, so I have been trying to avoid entering into that arena, however I find it very problematic the broad categories of users who supposedly need access to all of this data: "regulatory authorities, law enforcement, cybersecurity professionals, IT administrators, automated protection systems and other incident responders" This is simply too broad. These parties may have a legitimate need for domain meta data (though I question what "IT administrators" and "other incident responders" are - I think we should define all user types and strike these two out, rather than have something so open-ended listed), but they do not necessarily have a need for registrant contact information. In some instances, perhaps. I would also like to strike "etc" from the final sentence of investigation, notification, and reputation, because it is too expansive. Thanks. —Ayden -------- Original Message -------- Subject: [Gnso-rds-pdp-7] Proposed roll-up purposes Local Time: 8 November 2017 6:15 AM UTC Time: 8 November 2017 06:15 From: rod@rodrasmussen.com<mailto:rod@rodrasmussen.com> To: gnso-rds-pdp-7@icann.org<mailto:gnso-rds-pdp-7@icann.org> I’m going to leave off the “consequences of not providing information" for now - that’s not part of the purpose. However, we should work on that separately and include that feedback as part of our final product. Investigation: The following information is to be made available to regulatory authorities, law enforcement, cybersecurity professionals, IT administrators, automated protection systems and other incident responders for the purpose of enabling identification of the nature of the registration and operation of a domain name linked to abuse and/or criminal activities to facilitate the eventual mitigation and resolution of the abuse identified: Domain metadata (registrar, registration date, nameservers, etc.), Registrant contact information, Registrar contact Information, DNS contact, etc.. Notification: The following information is collected and made available for the purpose of enabling notification by regulatory authorities, law enforcement, cybersecurity professionals, IT administrators, automated protection systems and other incident responders of the appropriate party (registrant, providers of associated services, registrar, etc), of abuse linked to a certain domain name registration to facilitate the mitigation and resolution of the abuse identified: Registrant contact information, Registrar contact Information, DNS contact, etc.. Reputation: The following information is to be made available to organizations running automated protection systems for the purpose of enabling the establishment of reputation for a domain name to facilitate the provision of services and acceptance of communications from the domain name examined: Domain metadata (registrar, registration date, nameservers, etc.), Registrant contact information, Registrar contact Information, DNS contact, etc.. We should chat more about the particulars here, but these cover the concepts. I would argue that the first and third are purely a “display” purpose, but the second could be used as justification of collection. If nothing else, collecting an “abuse contact” requires number two for justification at all. Cheers, Rod _______________________________________________ Gnso-rds-pdp-7 mailing list Gnso-rds-pdp-7@icann.org<mailto:Gnso-rds-pdp-7@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-7 <DraftingTeam7-CrimInvAbuseMit-9 November 2017.docx>