Apologies for missing the core of this discussion while I was on a long holiday. For the use cases published at https://community.icann.org/display/NGRDSTRWMO/RDS+PDP+WG+Example+Use+Cases I see a major omission, whois used for business intelligence. Is there someone actively working on that? Is it too late for me to contribute? Thanks On Sun, Jul 31, 2016 at 9:47 PM, Mark Svancarek via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org> wrote:

+1

*From:* gnso-rds-pdp-wg-bounces@icann.org [mailto: gnso-rds-pdp-wg-bounces@icann.org] *On Behalf Of *Farell Folly *Sent:* Wednesday, July 27, 2016 6:42 AM *To:* Shane Kerr <shane@time-travellers.org> *Cc:* RDS PDP WG <gnso-rds-pdp-wg@icann.org> *Subject:* Re: [gnso-rds-pdp-wg] Use cases: Fundamental, Incidental, and Theoretical

+1 Shane

Best Regards @__f_f__ about.me/farell <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fabout.me%2ff...> ________________________________. Mail sent from my mobile phone. Excuse for brievety.

Le 27 juil. 2016 13:27, "Shane Kerr" <shane@time-travellers.org> a écrit :

All,

[ Apologies for the length. I need get back to my actual job, so don't have time to make this shorter. ]

I propose that:

* We should have a way to reject some use cases * Part of that motivation should be whether it is actually needed for DNS

This is not important now, but it will be at some point. It might be helpful to keep this in mind as we work on use cases.

---------------------------------------------------------------------

My thinking is that we have three basic types of use cases:

Primary ======= These use cases are necessary to actually be able to use the DNS itself. There are very few of these - almost all around configuring data that is needed for the DNS protocol to work.

For example, you can get a domain in NL.EU.ORG <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fNL.EU.ORG&da...> with only an e-mail address, and this is not published anywhere. (Even the e-mail address is not strictly necessary. One could set up a system based strictly on login to a web page.)

The recent thought-experiment (aborted because it is not in our work plan) about finding the minimum set of data needed to run the DNS would have been a good start for defining these use cases.

Incidental ========== The vast majority of use cases that we see today exist only as an artifact of the way that WHOIS works.

A long time ago a system was established that publishes certain information; without much thought about the long-term impact of the setup. Over the years people have found all kinds of creative, useful, and nefarious things to do with this information. However, storing or accessing this information has very little or nothing to do with actually making DNS work.

For example, the DNS protocol certainly does not care what my fax number is, but anyone who looks up my domain name will see it. (Don't worry, I won't be doxed! I don't have a fax because this isn't 1986.) Likewise DNS software doesn't care when a domain was created. And so on.

The use cases here include using RDS to track down criminals, research trademark disputes, create mass-mailing portfolios, looking for domain drop dates, and most of what people actually use WHOIS for today.

Note that I definitely include technical uses that are outside of the needs of the DNS protocol itself. So, for example, having a way to contact a DNS operator when something is wrong falls into this category.

Theoretical =========== We have seen a couple of proposed use cases that seem to be ideas that people have for useful or harmful ways that RDS can be used, but that do not exist today (at least not that anyone can fully document).

For example, there seems to be a desire to use the RDS as a way to issue warrants for information about registrants. While this may be useful, this is not possible today (even with RDAP, I note). Likewise concerns about using RDS to generate to generate lists of political enemies probably fits into this category.

---------------------------------------------------------------------

Discussion ==========

I bring this up because eventually we should be able reject certain use cases. (As an NCUC member, I expect to push back hard against a lot of use cases defined for business or law-enforcement purposes.)

I think that what I called "primary" use cases have to be accommodated. I think there may be some disagreement about the details, but these should be relatively easy to come to consensus on.

On the other hand, I think that both what I called "incidental" and "theoretical" use cases need to be motivated more strongly.

There will probably be a natural tendency to prioritize existing uses of WHOIS - what I call "incidental" - because someone has some existing processes that depend on these. I think that this is wrong, and that any use of WHOIS outside of what is needed by DNS needs to be equally-well motivated.

That's about it.

Cheers,

-- Shane

_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmm.icann.or...>

_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

-- [image: Donuts Inc.] <http://www.donuts.domains> *Elaine Pruis*, Vice President, Operations *Donuts Inc. <http://www.donuts.domains>* 10500 NE 8th Street, Suite 350, Bellevue Washington, 98004, U.S.A. | Telephone: 509.899.3161 [image: Twitter] <https://twitter.com/DonutsInc>[image: Facebook] <https://www.facebook.com/donutstlds>[image: Linked In] <http://www.linkedin.com/company/donuts-inc->

...

Theoretical =========== We have seen a couple of proposed use cases that seem to be ideas that people have for useful or harmful ways that RDS can be used, but that do not exist today (at least not that anyone can fully document).

For example, there seems to be a desire to use the RDS as a way to issue warrants for information about registrants. While this may be useful, this is not possible today (even with RDAP, I note).

It not only is possible today, it's also "common" (although thankfully not frequent) Registrars get served warrants for details about registrants, and the _only_ information from WHOIS that's "needed" or used for such cases is the name of the Registrar. I had the pleasure of meeting Chris Tarbell, ex-FBI Cyber Crime, at HostingCon last week - asked about WHOIS/domain data he said "we dont use it" Last year at the UKNOF event in Sheffield I spent quite some time talking with some amazing people from the UK CyberCrime departments - asked the same questions, they confirmed that although whois _might_ be looked at to see if it matches _data they already have_ for confirmation, it's not used or relied on. Which beggars the question, should "LawEnforcement" use cases even be part of the discussions ? Rob -- Rob Golding rob.golding@astutium.com Astutium Ltd, Number One Poultry, London. EC2R 8JR * domains * hosting * vps * servers * cloud * backups *

Hi Elaine, Thank you for preparing this use case. I just wanted to respond to this statement in the story: The registrant data is made anonymous (names removed and replaced with a number) for this analysis because the analyst is interested in the broad effect of the promo and personal information is not necessary to answer the questions posed. In the scenario you described, the data is anonymised, but it is not deindividualised, because the sum of the data you are retaining can be used to connect this data back to one specific person or entity, which indeed you are doing. In consequence, while some data elements have been stripped back, it would be very easy for a malicious actor to identify a person or group of vulnerable persons which may be registering domain names. There are other ethical considerations here too. Knowing how registrants behave can be used to employ incentives to encourage or discourage behaviour, which could potentially be used to chill speech. For example, if the WHOIS output was blended with another data source and one was to know that X (i.e. a disabled war veteran) is registering a number of domain names related to Y (i.e. historical civil rights activists he/she admired), the registrar could create disincentives for registering such domain names by creating a conditionality (i.e. anyone living in country Z registering domain names likely related to Y is shown a premium charge of 500%). Because good business analysts are able to identify hidden correlations which we cannot predict today in our use cases, there is the danger that the incentives which are created will be problematic or not sufficiently transparent. In addition, there is the danger that bots will infiltrate the RDS and identify vacant, high-value domain names for the purposes of cybersquatting, spamming, or impersonation, by picking up on the same patterns that legitimate registrants are following. Best wishes, Ayden On Sun, Aug 7, 2016 11:39 PM, Elaine Pruis elaine@donuts.email wrote: Hi, Attached is a whois use case describing an analysis of bulk whois data. This is one version of hundreds of ways analysts use the data to understand trends across the industry. On Mon, Aug 1, 2016 at 8:44 PM, Gomes, Chuck < cgomes@verisign.com > wrote: Feel free to prepare one Elaine but please get it done this week. Chuck From: gnso-rds-pdp-wg-bounces@icann. org [mailto: gnso-rds-pdp-wg- bounces@icann.org ] On Behalf Of Elaine Pruis Sent: Monday, August 01, 2016 1:28 PM Cc: RDS PDP WG Subject: Re: [gnso-rds-pdp-wg] Use cases: Fundamental, Incidental, and Theoretical Apologies for missing the core of this discussion while I was on a long holiday. For the use cases published at https://community.icann. org/display/NGRDSTRWMO/RDS+ PDP+WG+Example+Use+Cases I see a major omission, whois used for business intelligence. Is there someone actively working on that? Is it too late for me to contribute? Thanks On Sun, Jul 31, 2016 at 9:47 PM, Mark Svancarek via gnso-rds-pdp-wg < gnso-rds-pdp-wg@icann.org > wrote: +1 From: gnso-rds-pdp-wg-bounces@icann. org [mailto: gnso-rds-pdp-wg- bounces@icann.org ] On Behalf Of Farell Folly Sent: Wednesday, July 27, 2016 6:42 AM To: Shane Kerr < shane@time-travellers.org > Cc: RDS PDP WG < gnso-rds-pdp-wg@icann.org > Subject: Re: [gnso-rds-pdp-wg] Use cases: Fundamental, Incidental, and Theoretical +1 Shane Best Regards @__f_f__ about.me/farell ______________________________ __. Mail sent from my mobile phone. Excuse for brievety. Le 27 juil. 2016 13:27, "Shane Kerr" < shane@time-travellers.org > a écrit : All, [ Apologies for the length. I need get back to my actual job, so don't have time to make this shorter. ] I propose that: * We should have a way to reject some use cases * Part of that motivation should be whether it is actually needed for DNS This is not important now, but it will be at some point. It might be helpful to keep this in mind as we work on use cases. ------------------------------ ------------------------------ --------- My thinking is that we have three basic types of use cases: Primary ======= These use cases are necessary to actually be able to use the DNS itself. There are very few of these - almost all around configuring data that is needed for the DNS protocol to work. For example, you can get a domain in NL.EU.ORG with only an e-mail address, and this is not published anywhere. (Even the e-mail address is not strictly necessary. One could set up a system based strictly on login to a web page.) The recent thought-experiment (aborted because it is not in our work plan) about finding the minimum set of data needed to run the DNS would have been a good start for defining these use cases. Incidental ========== The vast majority of use cases that we see today exist only as an artifact of the way that WHOIS works. A long time ago a system was established that publishes certain information; without much thought about the long-term impact of the setup. Over the years people have found all kinds of creative, useful, and nefarious things to do with this information. However, storing or accessing this information has very little or nothing to do with actually making DNS work. For example, the DNS protocol certainly does not care what my fax number is, but anyone who looks up my domain name will see it. (Don't worry, I won't be doxed! I don't have a fax because this isn't 1986.) Likewise DNS software doesn't care when a domain was created. And so on. The use cases here include using RDS to track down criminals, research trademark disputes, create mass-mailing portfolios, looking for domain drop dates, and most of what people actually use WHOIS for today. Note that I definitely include technical uses that are outside of the needs of the DNS protocol itself. So, for example, having a way to contact a DNS operator when something is wrong falls into this category. Theoretical =========== We have seen a couple of proposed use cases that seem to be ideas that people have for useful or harmful ways that RDS can be used, but that do not exist today (at least not that anyone can fully document). For example, there seems to be a desire to use the RDS as a way to issue warrants for information about registrants. While this may be useful, this is not possible today (even with RDAP, I note). Likewise concerns about using RDS to generate to generate lists of political enemies probably fits into this category. ------------------------------ ------------------------------ --------- Discussion ========== I bring this up because eventually we should be able reject certain use cases. (As an NCUC member, I expect to push back hard against a lot of use cases defined for business or law-enforcement purposes.) I think that what I called "primary" use cases have to be accommodated. I think there may be some disagreement about the details, but these should be relatively easy to come to consensus on. On the other hand, I think that both what I called "incidental" and "theoretical" use cases need to be motivated more strongly. There will probably be a natural tendency to prioritize existing uses of WHOIS - what I call "incidental" - because someone has some existing processes that depend on these. I think that this is wrong, and that any use of WHOIS outside of what is needed by DNS needs to be equally-well motivated. That's about it. Cheers, -- Shane ______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/ listinfo/gnso-rds-pdp-wg ______________________________ _________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/ listinfo/gnso-rds-pdp-wg -- Elaine Pruis , Vice President, Operations Donuts Inc. 10500 NE 8th Street, Suite 350, Bellevue Washington, 98004, U.S.A. | Telephone: 509.899.3161 -- Elaine Pruis , Vice President, Operations Donuts Inc. 10500 NE 8th Street, Suite 350, Bellevue Washington, 98004, U.S.A. | Telephone: 509.899.3161 Ayden Férdeline Statement of Interest

Hi Having just returned from a conference, I've had opportunity to review some of the Support Tickets handled in my absence, as we do every month-end anyway, but paid special attention to those relating to domains. I've excluded many (as the logs don't show a whois was done), which largely consist of: * how do I renew * how do I cancel * will you take payment automatically type questions and limited this to real "use cases" where a WHOIS has been part of either the affected party needing data/contact info (if server logs show a whois query from that user), or during the investigation by registrar staff (where the server logs show a whois from our staff ips) or where whois data was pasted into the ticket, from the last 7 days ... I'll try and layout to the 'template format' tomorrow: #1 End User: My Email Stopped Working at the Weekend Actual Issue: Domain expired on Friday Details accessed from WHOIS: domain name, expiry date, registrar name Resolution: we're only the host, directed to contact their registrar (client had not actually looked at domain/whois, we wouldnt have needed to look to know we're not the registrar) #2 End User: Everything down, I can't PING www.*REDACTED* Actual Issue: Host "vanished" as nameservers no longer online/responding/serving records Details accessed from WHOIS: domain name, expiry date, registrar name, nameservers Resolution: Informed to try and contact their host another method, if that fails, will need to find a new one and update their domain. Provided details of wayback machine and our hosting plans (whois data not actually needed as we have all the data in our system anyway) #3 End User: Manual Domain Renewal Actual Issue: Registrant failed to renew domain/disabled renewal Details accessed from WHOIS: domain name, expiry date, registrar name Resolution: provided link to client portal to login and instructions on renewal (whois data not actually needed as we have all the data in our system anyway) #4 End User: domain transfer still pending after 2 weeks - help! Actual Issue: Domain is still locked at losing registrar Details accessed from WHOIS: domain name, epp status, registrar name Resolution: suggested to login to current registrar (where is claims to be unlocked) and re-lock and unlock again, and advise use when done to restart the transfer process (client had already been emailled the lock/status data at the start of the transfer process) #5 End User: My website is down again Actual Issue: Domain has 2 valid (responding with A record) nameservers and 2 invalid namesrevers Details accessed from WHOIS: domain name, nameservers Resolution: client added the nameservers for their hosting instead of replacing the nameservers already on the domain, support removed the additional 2 namesrevers for them and instructions on clearing cache provided (had client looked at whois they may have spotted this themselves - whois data not actually needed as we have all the data in our system anyway) #6 End User: Domain showing as Expired but paid for Actual Issue: Registrant had failed to pay us for renewal, but paid a scammer instead Details accessed from WHOIS: domain name, expiry date, status code, registrar Resolution: client educated about domain scams, payment taken by phone by us (registrar) for renewal and renewal processed, told to contact card issuer regarding the "directory service" $75 payment they made to the scammer (whois data not actually needed as we have all the data in our system anyway) #7 End User: URGENT Unable to access website/email - *REDACTED* expired ? Actual Issue: Domain has expired as renewal not paid, redirects to renewal required page Details accessed from WHOIS: domain name, expiry date, registrar name Resolution: Registrant had ignored upcoming domain expiry notices, and renewal invoice ( email address exists and is valid but they're not regularly monitoring it). They couldn't/didn't get the post-expiry notices ( which woudl have equally been ignored anyway ) as the contact email was @thedomain. Registrant couldn't now login and pay as no recollection of password, and reminders unable to be sent (as contact is @thedomain which has expired). Details validated "offline", renewal processed on their behalf to get back online and both email and paper copies of invoice sent - and now showing as paid. (whois data not actually needed as we have all the data in our system anyway) #8 End User: Assigning www.*REDACTED* Actual Issue: Designer wants to "hand-off" the billing/management/ownership of domain and hosting to end-user Details accessed from WHOIS: domain name, registrant name Resolution: Designer reminded on how to have their client signup directly to agree to our T&Cs and about our service-push process. Domain is currently in name of designer (as all of theirs are) so they're the RNH, so (as per their previous similar requests) a change-of-owner process will need to be followed which old and new registrant will need to take part in (whois data not actually needed as we have all the data in our system anyway) #9 End User: My website has been hijacked Actual Issue: Accessing domain in a browser shows a hosting company sales/holding page Details accessed from WHOIS: domain name, nameservers, registrar name, registrant name Resolution: no changes have been made recently to the domain (last update was Feb 2015) and the hosting account (with us) is active but no traffic since 29/July (domain is not expired) It would appear they'd used the DNS service(s) included in their previous hosting to repoint the domain to the new hosting rather than updating the nameservers at their registrar (not us), and that hosting account no longer exists at the host. Advised to first contact the previous host as the domain is in the name of the host, to get nameservers and "ownership" sorted out, then to transfer the domain to us so they can manage it all in one place I'm personally dissapointed in the final use-case, as it used the "personal details" about the registrant, which conflicts with our opinion about what information should be 'public' - although not strictly needed in providing the support (as the advice to contact the old host / dns provider would have been the same without that, but it did highlight an issue the client was unaware of) Rob

Great question, Elaine. Out of curiosity, did we get an answer? Thanks, Fabricio Vayra PARTNER 700 Thirteenth Street, N.W. Suite 600 Washington, DC 20005-3960 D. +1.202.654.6255 F. +1.202.654.9678 E. FVayra@perkinscoie.com<mailto:FVayra@perkinscoie.com> [cid:image001.jpg@01D054C5.01001EE0] From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Elaine Pruis Sent: Monday, August 08, 2016 6:10 PM To: Rob Golding Cc: RDS PDP WG Subject: Re: [gnso-rds-pdp-wg] Use cases: Actual / Real Thanks for the actual/real use case examples. You wrote: (whois data not actually needed as we have all the data in our system anyway) Do you think if the customers knew to look at whois they would have been able to sort out any of these issues themselves? On Wed, Aug 3, 2016 at 5:42 PM, Rob Golding <rob.golding@astutium.com<mailto:rob.golding@astutium.com>> wrote: Hi Having just returned from a conference, I've had opportunity to review some of the Support Tickets handled in my absence, as we do every month-end anyway, but paid special attention to those relating to domains. I've excluded many (as the logs don't show a whois was done), which largely consist of: * how do I renew * how do I cancel * will you take payment automatically type questions and limited this to real "use cases" where a WHOIS has been part of either the affected party needing data/contact info (if server logs show a whois query from that user), or during the investigation by registrar staff (where the server logs show a whois from our staff ips) or where whois data was pasted into the ticket, from the last 7 days ... I'll try and layout to the 'template format' tomorrow: #1 End User: My Email Stopped Working at the Weekend Actual Issue: Domain expired on Friday Details accessed from WHOIS: domain name, expiry date, registrar name Resolution: we're only the host, directed to contact their registrar (client had not actually looked at domain/whois, we wouldnt have needed to look to know we're not the registrar) #2 End User: Everything down, I can't PING www.*REDACTED*<http://www.*REDACTED*> Actual Issue: Host "vanished" as nameservers no longer online/responding/serving records Details accessed from WHOIS: domain name, expiry date, registrar name, nameservers Resolution: Informed to try and contact their host another method, if that fails, will need to find a new one and update their domain. Provided details of wayback machine and our hosting plans (whois data not actually needed as we have all the data in our system anyway) #3 End User: Manual Domain Renewal Actual Issue: Registrant failed to renew domain/disabled renewal Details accessed from WHOIS: domain name, expiry date, registrar name Resolution: provided link to client portal to login and instructions on renewal (whois data not actually needed as we have all the data in our system anyway) #4 End User: domain transfer still pending after 2 weeks - help! Actual Issue: Domain is still locked at losing registrar Details accessed from WHOIS: domain name, epp status, registrar name Resolution: suggested to login to current registrar (where is claims to be unlocked) and re-lock and unlock again, and advise use when done to restart the transfer process (client had already been emailled the lock/status data at the start of the transfer process) #5 End User: My website is down again Actual Issue: Domain has 2 valid (responding with A record) nameservers and 2 invalid namesrevers Details accessed from WHOIS: domain name, nameservers Resolution: client added the nameservers for their hosting instead of replacing the nameservers already on the domain, support removed the additional 2 namesrevers for them and instructions on clearing cache provided (had client looked at whois they may have spotted this themselves - whois data not actually needed as we have all the data in our system anyway) #6 End User: Domain showing as Expired but paid for Actual Issue: Registrant had failed to pay us for renewal, but paid a scammer instead Details accessed from WHOIS: domain name, expiry date, status code, registrar Resolution: client educated about domain scams, payment taken by phone by us (registrar) for renewal and renewal processed, told to contact card issuer regarding the "directory service" $75 payment they made to the scammer (whois data not actually needed as we have all the data in our system anyway) #7 End User: URGENT Unable to access website/email - *REDACTED* expired ? Actual Issue: Domain has expired as renewal not paid, redirects to renewal required page Details accessed from WHOIS: domain name, expiry date, registrar name Resolution: Registrant had ignored upcoming domain expiry notices, and renewal invoice ( email address exists and is valid but they're not regularly monitoring it). They couldn't/didn't get the post-expiry notices ( which woudl have equally been ignored anyway ) as the contact email was @thedomain. Registrant couldn't now login and pay as no recollection of password, and reminders unable to be sent (as contact is @thedomain which has expired). Details validated "offline", renewal processed on their behalf to get back online and both email and paper copies of invoice sent - and now showing as paid. (whois data not actually needed as we have all the data in our system anyway) #8 End User: Assigning www.*REDACTED*<http://www.*REDACTED*> Actual Issue: Designer wants to "hand-off" the billing/management/ownership of domain and hosting to end-user Details accessed from WHOIS: domain name, registrant name Resolution: Designer reminded on how to have their client signup directly to agree to our T&Cs and about our service-push process. Domain is currently in name of designer (as all of theirs are) so they're the RNH, so (as per their previous similar requests) a change-of-owner process will need to be followed which old and new registrant will need to take part in (whois data not actually needed as we have all the data in our system anyway) #9 End User: My website has been hijacked Actual Issue: Accessing domain in a browser shows a hosting company sales/holding page Details accessed from WHOIS: domain name, nameservers, registrar name, registrant name Resolution: no changes have been made recently to the domain (last update was Feb 2015) and the hosting account (with us) is active but no traffic since 29/July (domain is not expired) It would appear they'd used the DNS service(s) included in their previous hosting to repoint the domain to the new hosting rather than updating the nameservers at their registrar (not us), and that hosting account no longer exists at the host. Advised to first contact the previous host as the domain is in the name of the host, to get nameservers and "ownership" sorted out, then to transfer the domain to us so they can manage it all in one place I'm personally dissapointed in the final use-case, as it used the "personal details" about the registrant, which conflicts with our opinion about what information should be 'public' - although not strictly needed in providing the support (as the advice to contact the old host / dns provider would have been the same without that, but it did highlight an issue the client was unaware of) Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_gnso-2Drds-2Dpdp-2Dwg&d=CwMFaQ&c=XRWvQHnpdBDRh-yzrHjqLpXuHNC_9nanQc6pPG_SpT0&r=6lUxzkhJPN5qts-Nve5TYqxoGjP81z1kCvXgsmw-MiQ&m=tW6GxQQCLdM5efUjUA5iequaNB7eqqeuaiGAvvrTV3Q&s=JrQuzCEqg-88kUlFfjxPKeOAq86atBS5BWvFHGwgIK0&e=> -- [Donuts Inc.]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.donuts.domains&d=CwM...> Elaine Pruis, Vice President, Operations Donuts Inc.<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.donuts.domains&d=CwM...> 10500 NE 8th Street, Suite 350, Bellevue Washington, 98004, U.S.A. | Telephone: 509.899.3161 [Twitter]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_DonutsInc&d=CwMFaQ&c=XRWvQHnpdBDRh-yzrHjqLpXuHNC_9nanQc6pPG_SpT0&r=6lUxzkhJPN5qts-Nve5TYqxoGjP81z1kCvXgsmw-MiQ&m=tW6GxQQCLdM5efUjUA5iequaNB7eqqeuaiGAvvrTV3Q&s=Sd1Eda5VL259-tAlli3_HbUF3sq1TlyPDyAHnj6H8SU&e=>[Facebook]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.facebook.com_donutstlds&d=CwMFaQ&c=XRWvQHnpdBDRh-yzrHjqLpXuHNC_9nanQc6pPG_SpT0&r=6lUxzkhJPN5qts-Nve5TYqxoGjP81z1kCvXgsmw-MiQ&m=tW6GxQQCLdM5efUjUA5iequaNB7eqqeuaiGAvvrTV3Q&s=2cn47QkqC5Q9iIzRaUtVbqsrCfrBmGz7VKoTPw_u5cw&e=>[Linked In]<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.linkedin.com_company...> ________________________________ NOTICE: This communication may contain privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents. Thank you.

Rob - I'd agree, and that's why WHOIS delivered via browser plugin could do the trick. Of course, a conversation for another time, as is whether consumers could be "trained." -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Rob Golding Sent: Monday, August 15, 2016 8:02 AM To: RDS PDP WG Subject: Re: [gnso-rds-pdp-wg] Use cases: Actual / Real On 2016-08-08 23:09, Elaine Pruis wrote:

Thanks for the actual/real use case examples. You wrote: (whois data not actually needed as we have all the data in our system anyway) Do you think if the customers knew to look at whois they would have been able to sort out any of these issues themselves?

I used to dream of that circumstance, but it's rare and getting less and less likely. We're 20+ years too late to start expecting users to be "trained" before they're handed a computer. End-users want things "done for them" finding it easier to ask than follow and "self help". Even on industry forums it seems the norm now is to post a FAQ, even when an existing thread and answer is already on the same page - people are simply too lazy to scroll-down and/or read :( Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li... ________________________________ NOTICE: This communication may contain privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents. Thank you.

Most modern browsers (Edge, Chrome, and soon Safari IIRC) won’t support plug-ins anymore. From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Ayden Férdeline Sent: Monday, August 15, 2016 8:25 AM To: Vayra, Fabricio (Perkins Coie) <FVayra@perkinscoie.com> Cc: RDS PDP WG <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] Use cases: Actual / Real Browser plugins are inherently insecure. Most security experts would advise against enabling such tools, but, as you acknowledged, this is a discussion for another time. - Ayden -------- Original Message -------- Subject: Re: [gnso-rds-pdp-wg] Use cases: Actual / Real Local Time: August 15, 2016 3:44 PM UTC Time: August 15, 2016 2:44 PM From: FVayra@perkinscoie.com<mailto:FVayra@perkinscoie.com> To: rob.golding@astutium.com,gnso-rds-pdp-wg@icann.org<mailto:rob.golding@astutium.com,gnso-rds-pdp-wg@icann.org> Rob - I'd agree, and that's why WHOIS delivered via browser plugin could do the trick. Of course, a conversation for another time, as is whether consumers could be "trained." -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Rob Golding Sent: Monday, August 15, 2016 8:02 AM To: RDS PDP WG Subject: Re: [gnso-rds-pdp-wg] Use cases: Actual / Real On 2016-08-08 23:09, Elaine Pruis wrote:

Thanks for the actual/real use case examples. You wrote: (whois data not actually needed as we have all the data in our system anyway) Do you think if the customers knew to look at whois they would have been able to sort out any of these issues themselves?

I used to dream of that circumstance, but it's rare and getting less and less likely. We're 20+ years too late to start expecting users to be "trained" before they're handed a computer. End-users want things "done for them" finding it easier to ask than follow and "self help". Even on industry forums it seems the norm now is to post a FAQ, even when an existing thread and answer is already on the same page - people are simply too lazy to scroll-down and/or read :( Rob _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li... ________________________________ NOTICE: This communication may contain privileged or other confidential information. If you have received it in error, please advise the sender by reply email and immediately delete the message and any attachments without copying or disclosing the contents. Thank you. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg

Chuck, I still think a little bit like a software engineer. When writing requirements for a software system there are functional requirements and non-functional requirements. Functional requirements come from use cases (these are the related to actually doing a task, for example "when a copyright holder requests the date of birth and mother's maiden name of any registrant, the system will provide it"). Non-functional requirements are important but not related to any particular use case (for example, "an RDS must be accessible 24x7 with 99.99% availability for queries"). So while use cases are merely a tool to getting requirements, I think that all functional requirements probably should be linked to a use case. If not, they are unneeded and we should eliminate them. Rejecting use cases also means rejecting a bunch of associated requirements. Cheers, -- Shane At 2016-07-27 13:42:36 +0000 "Gomes, Chuck" <cgomes@verisign.com> wrote:

Shane,

Thanks for your thoughts and in particular your categorization of use cases.

I want to point out that use cases are not an end in themselves but rather a means to help us understand the issues related to various possible RDS requirements that we will be considering. So I do not think that we need to accept or reject use cases. We will though have to accept or reject or modify possible RDS requirements in our deliberation phase and that is where some of your arguments will come into play.

The WG could decide to only approve requirements that are actually needed for DNS or it could decide to not be so restrictive but decisions in that regard will be made in our deliberation step (Work Plan task 12).

In our discussion of use cases it is of course appropriate to accept or reject elements of them but not for the goal of making any final decisions.

Chuck

-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Shane Kerr Sent: Wednesday, July 27, 2016 9:24 AM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] Use cases: Fundamental, Incidental, and Theoretical

All,

[ Apologies for the length. I need get back to my actual job, so don't have time to make this shorter. ]

I propose that:

* We should have a way to reject some use cases * Part of that motivation should be whether it is actually needed for DNS

This is not important now, but it will be at some point. It might be helpful to keep this in mind as we work on use cases.

---------------------------------------------------------------------

My thinking is that we have three basic types of use cases:

Primary ======= These use cases are necessary to actually be able to use the DNS itself. There are very few of these - almost all around configuring data that is needed for the DNS protocol to work.

For example, you can get a domain in NL.EU.ORG with only an e-mail address, and this is not published anywhere. (Even the e-mail address is not strictly necessary. One could set up a system based strictly on login to a web page.)

The recent thought-experiment (aborted because it is not in our work plan) about finding the minimum set of data needed to run the DNS would have been a good start for defining these use cases.

Incidental ========== The vast majority of use cases that we see today exist only as an artifact of the way that WHOIS works.

A long time ago a system was established that publishes certain information; without much thought about the long-term impact of the setup. Over the years people have found all kinds of creative, useful, and nefarious things to do with this information. However, storing or accessing this information has very little or nothing to do with actually making DNS work.

For example, the DNS protocol certainly does not care what my fax number is, but anyone who looks up my domain name will see it. (Don't worry, I won't be doxed! I don't have a fax because this isn't 1986.) Likewise DNS software doesn't care when a domain was created. And so on.

The use cases here include using RDS to track down criminals, research trademark disputes, create mass-mailing portfolios, looking for domain drop dates, and most of what people actually use WHOIS for today.

Note that I definitely include technical uses that are outside of the needs of the DNS protocol itself. So, for example, having a way to contact a DNS operator when something is wrong falls into this category.

Theoretical =========== We have seen a couple of proposed use cases that seem to be ideas that people have for useful or harmful ways that RDS can be used, but that do not exist today (at least not that anyone can fully document).

For example, there seems to be a desire to use the RDS as a way to issue warrants for information about registrants. While this may be useful, this is not possible today (even with RDAP, I note). Likewise concerns about using RDS to generate to generate lists of political enemies probably fits into this category.

---------------------------------------------------------------------

Discussion ==========

I bring this up because eventually we should be able reject certain use cases. (As an NCUC member, I expect to push back hard against a lot of use cases defined for business or law-enforcement purposes.)

I think that what I called "primary" use cases have to be accommodated. I think there may be some disagreement about the details, but these should be relatively easy to come to consensus on.

On the other hand, I think that both what I called "incidental" and "theoretical" use cases need to be motivated more strongly.

There will probably be a natural tendency to prioritize existing uses of WHOIS - what I call "incidental" - because someone has some existing processes that depend on these. I think that this is wrong, and that any use of WHOIS outside of what is needed by DNS needs to be equally-well motivated.

That's about it.

Cheers,

-- Shane

Chuck, Great, that makes sense. We do need requirements, but I guess we don't necessarily need a fully documented use case for each as long as the usage is clear. Cheers, -- Shane At 2016-07-27 15:15:19 +0000 "Gomes, Chuck" <cgomes@verisign.com> wrote:

Shane,

I agree with a slight qualification: all requirements should be linked to a usage but not necessarily a 'use case'. At present we have no intent to create an all-inclusive set of 'use cases' so we might not be able to create a one-to-one map of requirements to use cases but we should be able to do that for uses.

Chuck

-----Original Message----- From: Shane Kerr [mailto:shane@time-travellers.org] Sent: Wednesday, July 27, 2016 10:16 AM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] Use cases: Fundamental, Incidental, and Theoretical

Chuck,

I still think a little bit like a software engineer. When writing requirements for a software system there are functional requirements and non-functional requirements.

Functional requirements come from use cases (these are the related to actually doing a task, for example "when a copyright holder requests the date of birth and mother's maiden name of any registrant, the system will provide it").

Non-functional requirements are important but not related to any particular use case (for example, "an RDS must be accessible 24x7 with 99.99% availability for queries").

So while use cases are merely a tool to getting requirements, I think that all functional requirements probably should be linked to a use case. If not, they are unneeded and we should eliminate them. Rejecting use cases also means rejecting a bunch of associated requirements.

Cheers,

-- Shane

At 2016-07-27 13:42:36 +0000 "Gomes, Chuck" <cgomes@verisign.com> wrote:

...

Shane,

Thanks for your thoughts and in particular your categorization of use cases.

I want to point out that use cases are not an end in themselves but rather a means to help us understand the issues related to various possible RDS requirements that we will be considering. So I do not think that we need to accept or reject use cases. We will though have to accept or reject or modify possible RDS requirements in our deliberation phase and that is where some of your arguments will come into play.

The WG could decide to only approve requirements that are actually needed for DNS or it could decide to not be so restrictive but decisions in that regard will be made in our deliberation step (Work Plan task 12).

In our discussion of use cases it is of course appropriate to accept or reject elements of them but not for the goal of making any final decisions.

Chuck

-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Shane Kerr Sent: Wednesday, July 27, 2016 9:24 AM To: gnso-rds-pdp-wg@icann.org Subject: [gnso-rds-pdp-wg] Use cases: Fundamental, Incidental, and Theoretical

All,

[ Apologies for the length. I need get back to my actual job, so don't have time to make this shorter. ]

I propose that:

* We should have a way to reject some use cases * Part of that motivation should be whether it is actually needed for DNS

This is not important now, but it will be at some point. It might be helpful to keep this in mind as we work on use cases.

---------------------------------------------------------------------

My thinking is that we have three basic types of use cases:

Primary ======= These use cases are necessary to actually be able to use the DNS itself. There are very few of these - almost all around configuring data that is needed for the DNS protocol to work.

For example, you can get a domain in NL.EU.ORG with only an e-mail address, and this is not published anywhere. (Even the e-mail address is not strictly necessary. One could set up a system based strictly on login to a web page.)

The recent thought-experiment (aborted because it is not in our work plan) about finding the minimum set of data needed to run the DNS would have been a good start for defining these use cases.

Incidental ========== The vast majority of use cases that we see today exist only as an artifact of the way that WHOIS works.

A long time ago a system was established that publishes certain information; without much thought about the long-term impact of the setup. Over the years people have found all kinds of creative, useful, and nefarious things to do with this information. However, storing or accessing this information has very little or nothing to do with actually making DNS work.

For example, the DNS protocol certainly does not care what my fax number is, but anyone who looks up my domain name will see it. (Don't worry, I won't be doxed! I don't have a fax because this isn't 1986.) Likewise DNS software doesn't care when a domain was created. And so on.

The use cases here include using RDS to track down criminals, research trademark disputes, create mass-mailing portfolios, looking for domain drop dates, and most of what people actually use WHOIS for today.

Note that I definitely include technical uses that are outside of the needs of the DNS protocol itself. So, for example, having a way to contact a DNS operator when something is wrong falls into this category.

Theoretical =========== We have seen a couple of proposed use cases that seem to be ideas that people have for useful or harmful ways that RDS can be used, but that do not exist today (at least not that anyone can fully document).

For example, there seems to be a desire to use the RDS as a way to issue warrants for information about registrants. While this may be useful, this is not possible today (even with RDAP, I note). Likewise concerns about using RDS to generate to generate lists of political enemies probably fits into this category.

---------------------------------------------------------------------

Discussion ==========

I bring this up because eventually we should be able reject certain use cases. (As an NCUC member, I expect to push back hard against a lot of use cases defined for business or law-enforcement purposes.)

I think that what I called "primary" use cases have to be accommodated. I think there may be some disagreement about the details, but these should be relatively easy to come to consensus on.

On the other hand, I think that both what I called "incidental" and "theoretical" use cases need to be motivated more strongly.

There will probably be a natural tendency to prioritize existing uses of WHOIS - what I call "incidental" - because someone has some existing processes that depend on these. I think that this is wrong, and that any use of WHOIS outside of what is needed by DNS needs to be equally-well motivated.

That's about it.

Cheers,

-- Shane