<html>
<body>
Chuck and all,<br><br>
It seems that we may be struggling with terminology.<br><br>
The "User/Purpose" charter question tasks this WG with
recommending requirements and policies for "permissible users"
and "permissible purposes."<br><br>
In contrast, "use cases" are a tool for exploring real-world
scenarios to help the WG consider possible requirements related to not
only users and purposes, but also data access and collection needs,
privacy and data protection considerations, and the other questions posed
by the charter.<br><br>
To illustrate these terms and how they relate:<br><br>
Each EWG <u>example use case</u> often pertains to the same kind of
<u>user</u>, the same kind of <u>purpose</u>, or the same kinds of
<u>data</u>. For example, the EWG mapped all <u>four use cases</u> that
Michele presented in last week's call to a <u>single purpose</u> Domain
Name Control:<br><br>
<img src="cid:.0" width=449 height=177 alt="Emacs!"><br><br>
However, the EWG did NOT recommend or even publish <u>use cases</u>. The
above set of use cases were concrete examples used by the EWG to
understand and then deliberate upon one <u>purpose</u> they eventually
agreed to call "Domain Name Control."<br><br>
Ultimately, the EWG recommended <u>permissible and impermissible users
and purposes</u> [UP-D01-R04 thru R15], the need for a <u>policy</u> that
clearly defines what is permissible/impermissible [UP-D01-R21], and
related <u>guiding principles</u> such as [UP-D01-R02] "gTLD
registration data must be collected, validated, and disclosed for
permissible purposes only" and [DE-D01-R06] "The only data
elements that must be collected are those with at least one permissible
purpose," etc. For example, [UP-D01-R04] describes the purpose
"Domain Name Control" and recommends that it be
permissible.<br><br>
I hope this specific example of one purpose and associated use cases is
helpful to better understand how these terms are used in the WG's
charter, and also how the EWG's use cases relate to the EWG's
recommendations.<br><br>
Best, Lisa<br><br>
<br>
At 09:15 AM 7/27/2016, Gomes, Chuck wrote:<br>
<blockquote type=cite class=cite cite="">Shane,<br><br>
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.<br><br>
Chuck<br><br>
-----Original Message-----<br>
From: Shane Kerr
[<a href="mailto:shane@time-travellers.org" eudora="autourl">
mailto:shane@time-travellers.org</a>] <br>
Sent: Wednesday, July 27, 2016 10:16 AM<br>
To: Gomes, Chuck<br>
Cc: gnso-rds-pdp-wg@icann.org<br>
Subject: Re: [gnso-rds-pdp-wg] Use cases: Fundamental, Incidental, and
Theoretical<br><br>
Chuck,<br><br>
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.<br><br>
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").<br><br>
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").<br><br>
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.<br><br>
Cheers,<br><br>
--<br>
Shane<br><br>
At 2016-07-27 13:42:36 +0000<br>
"Gomes, Chuck" <cgomes@verisign.com> wrote:<br><br>
> Shane,<br>
> <br>
> Thanks for your thoughts and in particular your categorization of
use cases.<br>
> <br>
> 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.<br>
> <br>
> 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).<br>
> <br>
> 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.<br>
> <br>
> Chuck<br>
> <br>
> -----Original Message-----<br>
> From: gnso-rds-pdp-wg-bounces@icann.org <br>
>
[<a href="mailto:gnso-rds-pdp-wg-bounces@icann.org" eudora="autourl">
mailto:gnso-rds-pdp-wg-bounces@icann.org</a>] On Behalf Of Shane
Kerr<br>
> Sent: Wednesday, July 27, 2016 9:24 AM<br>
> To: gnso-rds-pdp-wg@icann.org<br>
> Subject: [gnso-rds-pdp-wg] Use cases: Fundamental, Incidental, and
<br>
> Theoretical<br>
> <br>
> All,<br>
> <br>
> [ Apologies for the length. I need get back to my actual job, so
don't<br>
> have time to make this shorter. ]<br>
> <br>
> I propose that:<br>
> <br>
> * We should have a way to reject some use cases<br>
> * Part of that motivation should be whether it is actually needed
for<br>
> DNS<br>
> <br>
> 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.<br>
> <br>
>
---------------------------------------------------------------------<br>
> <br>
> My thinking is that we have three basic types of use cases:<br>
> <br>
> Primary<br>
> =======<br>
> 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.<br>
> <br>
> For example, you can get a domain in NL.EU.ORG with only an e-mail
<br>
> address, and this is not published anywhere. (Even the e-mail
address <br>
> is not strictly necessary. One could set up a system based strictly
on <br>
> login to a web page.)<br>
> <br>
> 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.<br>
> <br>
> Incidental<br>
> ==========<br>
> The vast majority of use cases that we see today exist only as an
artifact of the way that WHOIS works.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> 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.<br>
> <br>
> Theoretical<br>
> ===========<br>
> 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).<br>
> <br>
> 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.<br>
> <br>
>
---------------------------------------------------------------------<br>
> <br>
> Discussion<br>
> ==========<br>
> <br>
> I bring this up because eventually we should be able reject certain
<br>
> use cases. (As an NCUC member, I expect to push back hard against a
<br>
> lot of use cases defined for business or law-enforcement
purposes.)<br>
> <br>
> I think that what I called "primary" use cases have to be
accommodated.<br>
> I think there may be some disagreement about the details, but these
should be relatively easy to come to consensus on.<br>
> <br>
> On the other hand, I think that both what I called
"incidental" and "theoretical" use cases need to be
motivated more strongly.<br>
> <br>
> 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.<br>
> <br>
> That's about it.<br>
> <br>
> Cheers,<br>
> <br>
> --<br>
> Shane<br>
> <br>
_______________________________________________<br>
gnso-rds-pdp-wg mailing list<br>
gnso-rds-pdp-wg@icann.org<br>
<a href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" eudora="autourl">
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></blockquote>
</body>
</html>