[Gnso-rds-pdp-1] Drafting Team 2

[Greg Aaron]

I object to the language because: 
1)  It says gate the data, and make people prove their use case before they can obtain it.  Talking about gated access at this point is premature and unnecessary.  The exercise is to state use cases, not any conditions to be imposed.  That is a reason why the other work teams have not baked gated access into their work.  
2)   The proposal is problematic on the merits.  Are we going to require these users to prove their need before they can get gated access?   I question that premise.  And I feel certain there's no way practical way to manage gated access for millions of people.  

Please do not assume that some "average Internet users" don't know how to use WHOIS.  Nor should we assume that they can or should get some other kind of "help" from unnamed sources.  Clearly some "average" Internet users know how to use WHOIS.   And then there's a set of knowledgeable users who do know how to use WHOIS to reach out to a contact about an issue.   They all have legitimate uses cases here.

Let's use a concrete example:  people who need to complain about being victimized online.   Yes it's in the cybercrime area, but the issue is the same -- these are "ordinary" Internet users who have a legitimate use, and who may not know know ahead of time that they need to access domain data.  
To make a complaint about victimization to the FBI, you can fill out a form here: https://www.ic3.gov/complaint/default.aspx/   Many of the people who do so include domain data (see the form fields), which they get by using WHOIS.  In 2016, people sent in 298,000 reports using that form.  

All best,
--Greg

 


-----Original Message-----
From: James Galvin [mailto:jgalvin at afilias.info] 
Sent: Friday, November 17, 2017 10:05 AM
To: Greg Aaron <gca at icginc.com>
Cc: Susan Kawaguchi <susankpolicy at gmail.com>; gnso-rds-pdp-1 at icann.org
Subject: Re: [Gnso-rds-pdp-1] Drafting Team 2



On 15 Nov 2017, at 1:02, Greg Aaron wrote:

> I will not be able to attend a drafting team call tomorrow.
>
> The below definitions from Susan are problematic.
>
> This new Technical Resolution definition is actually very narrow and 
> excludes the examples we have been talking about.  For example, if 
> your hosting has been compromised and is serving malware, or your 
> website is broken, neither of those is technically “related to the
> DNS”, i.e. resolution services.   Yes stuff is being served over the 
> DNS, but it’s not at root a ‘DNS problem’.  So the current language 
> could be misconstrued to cover an extremely limited set of 
> circumstances, and that’s not what we meant to do.
> I propose instead: "Information collected to enable contact of the 
> relevant contacts to facilitate tracing, identification, and 
> resolution of incidents related to services associated with the domain 
> name.”

I agree with this change.


> I also don’t find this qualification workable or necessary, and 
> suggest it be scrapped: “Use of such data should ordinarily be limited 
> to those who are affected by such issues, or by those persons who are 
> tasked (directly or indirectly) with the resolution of such matters on 
> their behalf."
> That gets us back into some of the chicken-or-egg access conversations 
> that have taken place in the WG.  Should the data be accessible to 
> (”limited to”) only those who can prove they need it?  But how do
> you know you need it before the problem presents itself?   And if you 
> find you are affected and need the info, how are you then going to go 
> about being authorized to see it?   It’s not like one knows ahead of 
> time that a site will serve malware at you.  Or in a parallel case, if 
> someone will cybersquat on your new company name.  Consumers sometimes 
> want to look up domain ownership – but would we require them to get 
> authorized to do so, either pre-need or at the time of need?

I’m less inclined to agree with this change.

I am always challenged by the idea that we need to provide a solution for the average Internet user.  I frankly just don’t believe that on average they will ever do the things we like to believe they will.

If the average user has trouble I’m more inclined to believe they are going to seek help, and I’m more inclined to believe that help will have the resources necessary to help them.

I would prefer to keep the words as presented by Susan.

Jim




> All best,
> --Greg
>
>
> From: Gnso-rds-pdp-1 [mailto:gnso-rds-pdp-1-bounces at icann.org] On 
> Behalf Of Susan Kawaguchi
> Sent: Tuesday, November 14, 2017 1:35 AM
> To: gnso-rds-pdp-1 at icann.org
> Subject: [Gnso-rds-pdp-1] Drafting Team 2
>
> Hello All,
>
> Since Michele is out sick I am trying to help move things forward.  We 
> will be discussing all the drafting team's work tomorrow on the 
> working group call.  We need someone from the DT to provide the final 
> document and present the definition and high level overview of your 
> work.
>
> Please let me know who will present for DT1
>
> The leadership has been encouraging the DT's to standardized the 
> format of the definition and to focus on the "information collected".
> I have suggested changes to the definition below but up to the DT to 
> revise the definition.
>
> Technical Resolution
>
> "Information collected to enable contact of the relevant contacts to 
> facilitate tracing, identification and resolution of incidents, which 
> relate, either entirely or in part, to technical issues relating to 
> the DNS.
>
> Use of such data should ordinarily be limited to those who are 
> affected by such issues, or by those persons who are tasked (directly 
> or indirectly) with the resolution of such matters on their behalf."
>
> Academic Research
>
>
> "Information collected to enable use of aggregate WHOIS data elements 
> by researchers and other similar persons, as a source for academic or 
> other public interest studies or research,  relating either solely or 
> in part, to the use of the DNS."
>
>
> Talk to you all tomorrow.
>
> Susan


> _______________________________________________
> Gnso-rds-pdp-1 mailing list
> Gnso-rds-pdp-1 at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-1