[gnso-rds-pdp-wg] Use cases: Fundamental, Incidental, and Theoretical

[Shane Kerr]

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 at 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 at time-travellers.org] 
> Sent: Wednesday, July 27, 2016 10:16 AM
> To: Gomes, Chuck
> Cc: gnso-rds-pdp-wg at 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 at 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 at icann.org 
> > [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of Shane Kerr
> > Sent: Wednesday, July 27, 2016 9:24 AM
> > To: gnso-rds-pdp-wg at 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
> >   
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160727/0b2b08a4/attachment.sig>