[gnso-rds-pdp-wg] RDS Statement of Purpose

Fri Sep 9 17:48:22 UTC 2016

"Supporting the lifecycle" is different from "managing a domain".   For example a contact update or a nameserver change is not a lifecycle issue.  Yes those tasks are allowed to take place at certain phases in the lifecycle, but that's the extent to which they are related to lifecycle.   See https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en for a graphic of the typical gTLD domain lifecycle.  (Yes, there are some exceptions like Pending Create etc.) 

We know RDS needs to provide data that lets parties manage domains, and an RDS must reflect info related to domain management tasks.   An example is the registrar-to-registrar transfer.  In ICANN policy, registrants have the right to use the registrar or their choice.  Info provided by WHOIS tells the name of the current sponsoring registrar, whether there are transfer-prohibited or pending transfer statuses on a domain, and the registrant listed in WHOIS is the party designated in ICANN policy as a party that has the right to request a transfer.  There are many other examples.

I think Greg Shatan brought up some good questions.  I do not know whether Jim is suggesting "managing the lifecycle" as a minimum standard (i.e. RDS must at a minimum support the life-cycle of a domain name, to which other elements can be added), or a limiting standard (i.e., RDS must not do more than support the life-cycle of a domain name, to which other elements can be added only if they fit within the "life-cycle of a domain name"), or a "primary purpose" standard, where other elements can be added, but they would not be considered a "primary purpose".

I do know that published registration data has uses and justifications for its existence and use other than managing the domain's lifecycle.  For example there is the need to identify a registrant for various legal purposes, some of which (like UDRP) are enshrined in current ICANN policy.  So "supporting the lifecycle" may be a mechanical and possibly exclusionary or reductive lens through which to view the issues.  

Jim said his thinking is adapted from SAC054.  Both Jim and I are co-authors of that paper.  I note the following; there was a thread about this on this list back in March:

1.   SAC054 does not list all the purposes for which data is collected, and does not purport to.  SAC054 focuses narrowly on data elements used to MANAGE the domain lifecycle and operations.  In other words, it focuses on some operational purposes, and there may be other legitimate purposes.  There may be data elements that are important or have a legitimate purpose other than functional management.

2.   SAC054 says: "This document contains an enumeration of commonly used data elements. It is not a list or recommendation of which elements are or should be mandatory versus optional.  Some technical specifications (notably the Extensible Provisioning Protocol (EPP) RFCs) denote certain data elements as mandatory to collect, and ICANN gTLD contracts make certain fields mandatory to display in directory services.”

3.   SAC054 says: "The SSAC makes no policy assertions; rather, it presents the data model as a candidate or straw man for community discussion and consideration and as a basis for further development."

All that to say that Jim's proposed construct leaves a lot of issues to discuss. 

All best,
--Greg

-----Original Message-----
From: gnso-rds-pdp-wg-bounces at icann.org [mailto:gnso-rds-pdp-wg-bounces at icann.org] On Behalf Of James Galvin
Sent: Thursday, September 8, 2016 4:03 PM
To: Greg Shatan <gregshatanipc at gmail.com>
Cc: gnso-rds-pdp-wg at icann.org
Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose

Greg, excellent questions, which I said on the call when you asked them. 
  I believe that all of these questions deserve some discussion so we can understand the effect of different answers.

I have added inline some thoughts that I have regarding your questions.  
I am, of course, very interested in what others think.

On 8 Sep 2016, at 15:21, Greg Shatan wrote:

> I expressed a concern about this on the call (it may have been in the 
> chat), along the following lines:  What exactly is meant by "the 
> life-cycle of a domain name"?

I start with a minimalist view when thinking about this question, adapted from SAC054.  A domain name comes in to existence, certain events may affect the domain name, and then the domain name expires.  
The data that is collected would only be data necessary to support creation, the selected events, and finally the expiration of the domain name.

In my model, this much is self-evident, i.e., I think this is the minimum definition of a life cycle.  So, I would split your question in
two: a) is this the absolute minimum?  b) is this sufficient?

>
> Also, is this meant to be a minimum standard (i.e., RDS must, at a 
> minimum, support the life-cycle of a domain name), to which other 
> elements can be added?
>
> Or is this meant to be a limiting standard (i.e., RDS must not do more 
> than support the life-cycle of a domain name), to which other elements 
> can be added only if they fit within the "life-cycle of a domain 
> name"?

This distinction is something the working group should discuss as it considers the question of what is meant by the life cycle of a domain name.

>
> Or is this meant to be a "primary purpose" standard, where other 
> elements can be added, but they would not be considered a "primary 
> purpose"
> (which
> has a significant downstream effect, e.g., in certain privacy 
> legislation)?

This distinction is something the working group should discussion.  I believe that if we can create a minimalist definition of the life cycle of a domain name, then that would likely become the “primary purpose”.  This is important because it has downstream effects as you say.

In particular, if we agree to a primary purpose, I would say the elements in support of that become mandatory for all registries/registrars.  Secondary purposes may or may not be required, depending on whether that secondary purpose is something that a registry is required to support, i.e., if it supports the secondary purpose then the additional elements become mandatory, otherwise they are optional.

My point here is that not all existing use cases should be part of the primary purpose, in my opinion of course, and thus there may be some elements that would no longer need to be collected.

>
> Finally, I would ask which of the use cases that we have on our list 
> fall within "the life-cycle of a domain name" and which do not?  (I 
> suppose this last question is intertwined with my first question 
> above.

This is a discussion we need to have in this working group.

>
> Depending on what other participants believe the answers to these 
> questions should be, and what their effect may be, I may have 
> significant concerns about this statement.
>
> Greg
>
> On Thu, Sep 8, 2016 at 2:52 PM, Gomes, Chuck <cgomes at verisign.com>
> wrote:
>
>> In our call earlier this week there seemed to be support for one 
>> element of a RDS Statement of Purpose as suggested by Jim Galvin:  
>> “The RDS should support the life cycle of a domain name.”  No one on 
>> the call disagreed with this; if anyone not on the call has comments 
>> on this please communicate so on this list prior to our call next 
>> week. Also, if any one who was on the call has comments that you did 
>> not share, please do so before next week’s meeting.
>>
>>
>>
>> Also, it would be helpful if everyone could be thinking about answers 
>> to the following questions:
>>
>> ·         What are the criteria for a statement of purpose?
>>
>> ·         What elements, if any, from the EWG statement of purpose 
>> should
>> be reflected in the statement of purpose?
>>
>> ·         What other elements need to be reflected in the statement 
>> of
>> purpose?
>>
>> We plan to discuss these questions in next week’s meeting but 
>> comments would be appreciated on the list before then.
>>
>>
>>
>> Chuck
>>
>>
>>
>> Here’s the EWG statement of purpose that we discussed in our 
>> meeting
>> earlier this week:
>>
>>
>>
>> To help guide the EWG in its deliberations, the group developed a
>> high-level statement of purpose from which to test its conclusions 
>> and
>> recommendations, as follows:
>>
>> In support of ICANN’s mission to coordinate the global Internet’s 
>> system
>> of unique identifiers, and to ensure the stable and secure operation 
>> of the
>> Internet’s unique identifier system, information about gTLD domain 
>> names is
>> necessary to promote trust and confidence in the Internet for all
>> stakeholders.
>>
>> Accordingly, it is desirable to design a system to support domain 
>> name
>> registration and maintenance which:
>>
>> ·         Provides appropriate access to accurate, reliable, and 
>> uniform
>> registration data
>>
>> ·         Protects the privacy of personal information
>>
>> ·         Enables a reliable mechanism for identifying, establishing 
>> and
>> maintaining the ability to contact Registrants
>>
>> ·         Supports a framework to address issues involving 
>> Registrants,
>> including but not limited to: consumer protection, investigation of
>> cybercrime, and intellectual property protection
>>
>> ·        Provides an infrastructure to address appropriate law
>> enforcement needs
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> gnso-rds-pdp-wg mailing list
>> gnso-rds-pdp-wg at icann.org
>> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg at icann.org
https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg