RDS Statement of Purpose
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
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"? 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"? 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)? 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. 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@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@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Greg, It is undoubtedly best if Jim Galvin respond to your questions but I inserted my thoughts below. Chuck From: Greg Shatan [mailto:gregshatanipc@gmail.com] Sent: Thursday, September 08, 2016 3:21 PM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose 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"? [Chuck Gomes] To me the definition of the life-cycle of a domain name is simply the time period from registration to deletion. Obviously, that isn’t very helpful in terms of creating understanding of what is needed in the RDS, so I definitely think we need to add more to clarify that. In my mind, supporting the life-cycle of a domain name includes a variety of possible things to include registrant needs, registry/registrar needs, user needs, legal needs, privacy needs, etc. 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? [Chuck Gomes] Any support provided by the RDS must be provided for the domain name from registration to deletion and possibly after deletion. At a minimum it must support a domain name during its full life-cycle and possibly after its life-cycle. 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"? 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)? [Chuck Gomes] I think that it provides a minimum time limit rather than being a primary purpose. 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. 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@verisign.com<mailto:cgomes@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@icann.org<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Chuck, Minor nit... At 2016-09-08 19:50:00 +0000 "Gomes, Chuck" <cgomes@verisign.com> 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"? [Chuck Gomes] To me the definition of the life-cycle of a domain name is simply the time period from registration to deletion. Obviously, that isn’t very helpful in terms of creating understanding of what is needed in the RDS, so I definitely think we need to add more to clarify that. In my mind, supporting the life-cycle of a domain name includes a variety of possible things to include registrant needs, registry/registrar needs, user needs, legal needs, privacy needs, etc.
"from registration to deletion" is a bit too narrow. We may also want to consider the pre-registration phase (such as waiting lists, new gTLD holding periods for specific registrants, and so on). Also, after deletion some information may be needed for archival or historical purposes (I believe when I was at ARIN we created an internal tool called WHOWAS for this kind of thing, but that was almost 20 years ago so my memory may be even more flawed than usual). But basically that's it. :) Cheers, -- Shane
I chose to use the terms creation to expiration, reserving registration to be used to describe the process of associating an identity with the domain name. A question I would ask is if reserving a domain name could be one type of creation? If so, another type could be when it is assigned to a registrant. There may be other types. Similarly, archiving a domain name (or its contact information) could be a sub-step of expiration, that could in fact be optional. More generally, what I’m asking is if you really believe we need to have an additional endpoint at each end or if the steps you are calling out are part of the existing end points? Thanks, Jim On 8 Sep 2016, at 23:26, Shane Kerr wrote:
Chuck,
Minor nit...
At 2016-09-08 19:50:00 +0000 "Gomes, Chuck" <cgomes@verisign.com> 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"? [Chuck Gomes] To me the definition of the life-cycle of a domain name is simply the time period from registration to deletion. Obviously, that isn’t very helpful in terms of creating understanding of what is needed in the RDS, so I definitely think we need to add more to clarify that. In my mind, supporting the life-cycle of a domain name includes a variety of possible things to include registrant needs, registry/registrar needs, user needs, legal needs, privacy needs, etc.
"from registration to deletion" is a bit too narrow. We may also want to consider the pre-registration phase (such as waiting lists, new gTLD holding periods for specific registrants, and so on). Also, after deletion some information may be needed for archival or historical purposes (I believe when I was at ARIN we created an internal tool called WHOWAS for this kind of thing, but that was almost 20 years ago so my memory may be even more flawed than usual).
But basically that's 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
Agreed Shane. If we use the term 'domain name life-cycle', we will need to agree on a definition, which may or may not include start and end points earlier and later than I suggested. Chuck -----Original Message----- From: Shane Kerr [mailto:shane@time-travellers.org] Sent: Thursday, September 08, 2016 11:27 PM To: Gomes, Chuck Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose Chuck, Minor nit... At 2016-09-08 19:50:00 +0000 "Gomes, Chuck" <cgomes@verisign.com> 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"? [Chuck Gomes] To me the definition of the life-cycle of a domain name is simply the time period from registration to deletion. Obviously, that isn’t very helpful in terms of creating understanding of what is needed in the RDS, so I definitely think we need to add more to clarify that. In my mind, supporting the life-cycle of a domain name includes a variety of possible things to include registrant needs, registry/registrar needs, user needs, legal needs, privacy needs, etc.
"from registration to deletion" is a bit too narrow. We may also want to consider the pre-registration phase (such as waiting lists, new gTLD holding periods for specific registrants, and so on). Also, after deletion some information may be needed for archival or historical purposes (I believe when I was at ARIN we created an internal tool called WHOWAS for this kind of thing, but that was almost 20 years ago so my memory may be even more flawed than usual). But basically that's it. :) Cheers, -- Shane
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@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@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
+1 on James' responses. My minimalist view is that anything contractually required is absolute minimum, and anything legally required in a jurisdiction is absolute minimum for that jurisdiction. (The final policy and resulting software design will accommodate the vagaries of jurisdictions.) The use cases discussions allow us to determine which additional "certain events" beyond the absolute minimum are sufficient to address the lifecycle. /marksv -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of James Galvin Sent: Thursday, September 8, 2016 1:03 PM To: Greg Shatan <gregshatanipc@gmail.com> Cc: gnso-rds-pdp-wg@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@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@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
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
"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@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of James Galvin Sent: Thursday, September 8, 2016 4:03 PM To: Greg Shatan <gregshatanipc@gmail.com> Cc: gnso-rds-pdp-wg@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@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@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
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Greg, I disagree with your conclusion here: 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. If something is enshrined in ICANN policy, and one is obligated to do it, then it is very much part of “supporting the lifecycle” in my opinion. It’s a task within the Registered portion chart to which you’ve linked. Ironically, I think you may be the one applying an exclusionary or reductive lens. /marksv -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Friday, September 9, 2016 10:48 AM To: James Galvin <jgalvin@afilias.info>; Greg Shatan <gregshatanipc@gmail.com> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose "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@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of James Galvin Sent: Thursday, September 8, 2016 4:03 PM To: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@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@verisign.com<mailto:cgomes@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@icann.org<mailto:gnso-rds-pdp-wg@icann.org>
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>
_______________________________________________ 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 _______________________________________________ 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
Dear Mark: The “ljfecycle” of a domain name is commonly understood as the series of states that a domains goes through from creation to deletion. These are associated with various grace periods and registration term measured in years. These are illustrated in the chart at https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en The lifecycle of a gTLD domain is primarily the result of two forces. One force is commercial – for example, you pay to register a domain for a year-term basis, and the Add Grace Period exists do registrars can recover from mistakes and fraud. The other force is policy – for example we have Redemption Grace Period because the community thought it was not good that some people were losing their domains because they failed to renew them in a timely fashion. A contact change, a nameserver change, etc. do not “support the lifecycle.” Such operations do not change what phase of the lifecycle the domain is in, and a domain will move through the lifecycle regardless of whether these operations have occurred. Instead, they are examples of domain management or domain operations. UDRP is an ICANN policy, and registrants are obligated to follow it. It was not instituted to “support the lifecycle”, URDP involves only a tiny percentage of domain names, and it’s not a domain management or operational task. UDRP was instituted to settle a conflict between two parties. A successful challenge may result in a domain management task, such as a registrant-to-registrant transfer. But the UDRP’s reason for being and function do not “support the lifecycle.” UDRP is not a servant of the lifecycle. In other words: lifecycle is a result and a servant; it is not a cause or justification of policy. All best, --Greg From: Mark Svancarek [mailto:marksv@microsoft.com] Sent: Friday, September 9, 2016 2:27 PM To: Greg Aaron <gca@icginc.com>; James Galvin <jgalvin@afilias.info>; Greg Shatan <gregshatanipc@gmail.com> Cc: gnso-rds-pdp-wg@icann.org Subject: RE: [gnso-rds-pdp-wg] RDS Statement of Purpose Greg, I disagree with your conclusion here: 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. If something is enshrined in ICANN policy, and one is obligated to do it, then it is very much part of “supporting the lifecycle” in my opinion. It’s a task within the Registered portion chart to which you’ve linked. Ironically, I think you may be the one applying an exclusionary or reductive lens. /marksv -----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 Greg Aaron Sent: Friday, September 9, 2016 10:48 AM To: James Galvin <jgalvin@afilias.info<mailto:jgalvin@afilias.info>>; Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose "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@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of James Galvin Sent: Thursday, September 8, 2016 4:03 PM To: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@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@verisign.com<mailto:cgomes@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@icann.org<mailto:gnso-rds-pdp-wg@icann.org>
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>
_______________________________________________ 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 _______________________________________________ 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
Sorry, Greg, I am completely confused by your terminology - your explanation below decreased my understanding of your intent rather than improving it. Perhaps someone else can weigh in on this point to clarify. If not, I propose that we use different verbiage than "support the lifecycle", as Holly suggested elsewhere, since it does not seem to be consistently used by all in the group. ________________________________ From: Greg Aaron <gca@icginc.com> Sent: Saturday, September 10, 2016 2:17:17 PM To: Mark Svancarek; James Galvin; Greg Shatan Cc: gnso-rds-pdp-wg@icann.org Subject: RE: [gnso-rds-pdp-wg] RDS Statement of Purpose Dear Mark: The “ljfecycle” of a domain name is commonly understood as the series of states that a domains goes through from creation to deletion. These are associated with various grace periods and registration term measured in years. These are illustrated in the chart at https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en The lifecycle of a gTLD domain is primarily the result of two forces. One force is commercial – for example, you pay to register a domain for a year-term basis, and the Add Grace Period exists do registrars can recover from mistakes and fraud. The other force is policy – for example we have Redemption Grace Period because the community thought it was not good that some people were losing their domains because they failed to renew them in a timely fashion. A contact change, a nameserver change, etc. do not “support the lifecycle.” Such operations do not change what phase of the lifecycle the domain is in, and a domain will move through the lifecycle regardless of whether these operations have occurred. Instead, they are examples of domain management or domain operations. UDRP is an ICANN policy, and registrants are obligated to follow it. It was not instituted to “support the lifecycle”, URDP involves only a tiny percentage of domain names, and it’s not a domain management or operational task. UDRP was instituted to settle a conflict between two parties. A successful challenge may result in a domain management task, such as a registrant-to-registrant transfer. But the UDRP’s reason for being and function do not “support the lifecycle.” UDRP is not a servant of the lifecycle. In other words: lifecycle is a result and a servant; it is not a cause or justification of policy. All best, --Greg From: Mark Svancarek [mailto:marksv@microsoft.com] Sent: Friday, September 9, 2016 2:27 PM To: Greg Aaron <gca@icginc.com>; James Galvin <jgalvin@afilias.info>; Greg Shatan <gregshatanipc@gmail.com> Cc: gnso-rds-pdp-wg@icann.org Subject: RE: [gnso-rds-pdp-wg] RDS Statement of Purpose Greg, I disagree with your conclusion here: 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. If something is enshrined in ICANN policy, and one is obligated to do it, then it is very much part of “supporting the lifecycle” in my opinion. It’s a task within the Registered portion chart to which you’ve linked. Ironically, I think you may be the one applying an exclusionary or reductive lens. /marksv -----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 Greg Aaron Sent: Friday, September 9, 2016 10:48 AM To: James Galvin <jgalvin@afilias.info<mailto:jgalvin@afilias.info>>; Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose "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@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of James Galvin Sent: Thursday, September 8, 2016 4:03 PM To: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@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@verisign.com<mailto:cgomes@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@icann.org<mailto:gnso-rds-pdp-wg@icann.org>
_______________________________________________
gnso-rds-pdp-wg mailing list
gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>
_______________________________________________ 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 _______________________________________________ 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 My conclusion might have been a bit hasty. I'd like to wait for a definition of life-cycle s well as the requirements for data 'supporting the life-cycle of a domain name' before I further elaborate. If the life-cycle includes the entire useful life of a domain name with no limit in time, than my conclusion will be valid. If the definition is more limited, than I will retract this conclusion. Nathalie On Sunday, September 11, 2016 8:33 PM, Mark Svancarek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote: #yiv5432382732 #yiv5432382732 -- _filtered #yiv5432382732 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv5432382732 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv5432382732 #yiv5432382732 p.yiv5432382732MsoNormal, #yiv5432382732 li.yiv5432382732MsoNormal, #yiv5432382732 div.yiv5432382732MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;}#yiv5432382732 a:link, #yiv5432382732 span.yiv5432382732MsoHyperlink {color:#0563C1;text-decoration:underline;}#yiv5432382732 a:visited, #yiv5432382732 span.yiv5432382732MsoHyperlinkFollowed {color:#954F72;text-decoration:underline;}#yiv5432382732 p.yiv5432382732MsoPlainText, #yiv5432382732 li.yiv5432382732MsoPlainText, #yiv5432382732 div.yiv5432382732MsoPlainText {margin:0in;margin-bottom:.0001pt;font-size:11.0pt;}#yiv5432382732 p.yiv5432382732msonormal0, #yiv5432382732 li.yiv5432382732msonormal0, #yiv5432382732 div.yiv5432382732msonormal0 {margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv5432382732 span.yiv5432382732PlainTextChar {}#yiv5432382732 span.yiv5432382732EmailStyle20 {color:windowtext;}#yiv5432382732 .yiv5432382732MsoChpDefault {font-size:10.0pt;} _filtered #yiv5432382732 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv5432382732 div.yiv5432382732WordSection1 {}#yiv5432382732 #yiv5432382732 #yiv5432382732 -- P {margin-top:0;margin-bottom:0;}#yiv5432382732 Sorry, Greg, I am completely confused by your terminology - your explanation below decreased my understanding of your intent rather than improving it. Perhaps someone else can weigh in on this point to clarify. If not, I propose that we use different verbiage than "support the lifecycle", as Holly suggested elsewhere, since it does not seem to be consistently used by all in the group. From: Greg Aaron <gca@icginc.com> Sent: Saturday, September 10, 2016 2:17:17 PM To: Mark Svancarek; James Galvin; Greg Shatan Cc: gnso-rds-pdp-wg@icann.org Subject: RE: [gnso-rds-pdp-wg] RDS Statement of Purpose Dear Mark: The “ljfecycle” of a domain name is commonly understood as the series of states that a domains goes through from creation to deletion. These are associated with various grace periods and registration term measured in years. These are illustrated in the chart at https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en The lifecycle of a gTLD domain is primarily the result of two forces. One force is commercial – for example, you pay to register a domain for a year-term basis, and the Add Grace Period exists do registrars can recover from mistakes and fraud. The other force is policy – for example we have Redemption Grace Period because the community thought it was not good that some people were losing their domains because they failed to renew them in a timely fashion. A contact change, a nameserver change, etc. do not “support the lifecycle.” Such operations do not change what phase of the lifecycle the domain is in, and a domain will move through the lifecycle regardless of whether these operations have occurred. Instead, they are examples ofdomain management or domain operations. UDRP is an ICANN policy, and registrants are obligated to follow it. It was not instituted to “support the lifecycle”,URDP involves only a tiny percentage of domain names, and it’s not a domain management or operational task. UDRP was instituted to settle a conflict between two parties. A successful challenge may result in a domain management task, such as a registrant-to-registrant transfer. But the UDRP’s reason for being and function do not “support the lifecycle.” UDRP is not a servant of the lifecycle. In other words: lifecycle is a result and a servant; it is not a cause or justification of policy. All best, --Greg From: Mark Svancarek [mailto:marksv@microsoft.com] Sent: Friday, September 9, 2016 2:27 PM To: Greg Aaron <gca@icginc.com>; James Galvin <jgalvin@afilias.info>; Greg Shatan <gregshatanipc@gmail.com> Cc: gnso-rds-pdp-wg@icann.org Subject: RE: [gnso-rds-pdp-wg] RDS Statement of Purpose Greg, I disagree with your conclusion here: 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. If something is enshrined in ICANN policy, and one is obligated to do it, then it is very much part of “supporting the lifecycle” in my opinion. It’s a task within the Registered portion chart to which you’ve linked. Ironically, I think you may be the one applying an exclusionary or reductive lens. /marksv -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Friday, September 9, 2016 10:48 AM To: James Galvin <jgalvin@afilias.info>; Greg Shatan <gregshatanipc@gmail.com> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose "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@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of James Galvin Sent: Thursday, September 8, 2016 4:03 PM To: Greg Shatan <gregshatanipc@gmail.com> Cc: gnso-rds-pdp-wg@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@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@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 _______________________________________________ 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 _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Folks Is it really important if something is inside or outside of a ‘lifecycle’. The question we are really asking is whether/in what circumstances the data is used as part of the whole process of managing a domain. What we are all asking is who now has access to the data, in what circumstances, and for what purpose(s). Holly On 10 Sep 2016, at 4:26 am, Mark Svancarek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote:
Greg, I disagree with your conclusion here:
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.
If something is enshrined in ICANN policy, and one is obligated to do it, then it is very much part of “supporting the lifecycle” in my opinion. It’s a task within the Registered portion chart to which you’ve linked.
Ironically, I think you may be the one applying an exclusionary or reductive lens.
/marksv
-----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Greg Aaron Sent: Friday, September 9, 2016 10:48 AM To: James Galvin <jgalvin@afilias.info>; Greg Shatan <gregshatanipc@gmail.com> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose
"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@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of James Galvin Sent: Thursday, September 8, 2016 4:03 PM To: Greg Shatan <gregshatanipc@gmail.com> Cc: gnso-rds-pdp-wg@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@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@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
_______________________________________________ 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 _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
+1. There are various important, valid purposes for which domain registration is used by a variety of stakeholders. Focusing on "lifecycle" or primary/secondary purposes is a red herring. From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Holly Raiche Sent: Sunday, September 11, 2016 12:03 AM To: Mark Svancarek <marksv@microsoft.com> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose Folks Is it really important if something is inside or outside of a 'lifecycle'. The question we are really asking is whether/in what circumstances the data is used as part of the whole process of managing a domain. What we are all asking is who now has access to the data, in what circumstances, and for what purpose(s). Holly On 10 Sep 2016, at 4:26 am, Mark Svancarek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> wrote: Greg, I disagree with your conclusion here: 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. If something is enshrined in ICANN policy, and one is obligated to do it, then it is very much part of "supporting the lifecycle" in my opinion. It's a task within the Registered portion chart to which you've linked. Ironically, I think you may be the one applying an exclusionary or reductive lens. /marksv -----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 Greg Aaron Sent: Friday, September 9, 2016 10:48 AM To: James Galvin <jgalvin@afilias.info<mailto:jgalvin@afilias.info>>; Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose "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@icann.org<mailto:gnso-rds-pdp-wg-bounces@icann.org> [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of James Galvin Sent: Thursday, September 8, 2016 4:03 PM To: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@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@verisign.com<mailto:cgomes@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@icann.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
We also need to consider that the life-cycle of the domain is not entirely under the control of the registrant whom provided the data, which then brings in Privacy law for example. The life-cycle meaning for this purpose would need to be very well defined. Kind regards, Chris From: "Greg Shatan" <gregshatanipc@gmail.com> To: "Gomes, Chuck" <cgomes@verisign.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 8 September, 2016 20:21:03 Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose 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"? 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"? 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)? 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. 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@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@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
As ICANN defines it at the moment, the registrant shown in Whois are the “owner” and the one who has control. So I agree with you Chris there must be a definition which are clear on this -- Med vänliga hälsningar / Kind Regards / Med vennlig hilsen Benny Samuelsen Registry Manager - Domainexpert Nordreg AB - ICANN accredited registrar IANA-ID: 638 Phone: +46.852529100 Direct: +47.32260201 Mobile: +47.40410200
On 09 Sep 2016, at 09:09, Chris Pelling <chris@netearth.net> wrote:
We also need to consider that the life-cycle of the domain is not entirely under the control of the registrant whom provided the data, which then brings in Privacy law for example. The life-cycle meaning for this purpose would need to be very well defined.
Kind regards,
Chris
From: "Greg Shatan" <gregshatanipc@gmail.com> To: "Gomes, Chuck" <cgomes@verisign.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 8 September, 2016 20:21:03 Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose
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"?
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"?
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)?
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.
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@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@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
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Just to make sure I understand, my description of the life cycle carefully did not speak to when a domain name is under control of a registrant or not. I was carefully leaving that question as a detail inside of the events we decide that are part of the life cycle. This allows us, for example, to include “reserving” names inside of creation, which would make the domain name under the control of the registry versus the registrant. As I understand your point, you are reminding us that the point at which a domain name is under control of registrant versus not will have downstream effects when we consider privacy laws. Do I have that right or have I misunderstood? Jim On 9 Sep 2016, at 3:09, Chris Pelling wrote:
We also need to consider that the life-cycle of the domain is not entirely under the control of the registrant whom provided the data, which then brings in Privacy law for example. The life-cycle meaning for this purpose would need to be very well defined.
Kind regards,
Chris
From: "Greg Shatan" <gregshatanipc@gmail.com> To: "Gomes, Chuck" <cgomes@verisign.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 8 September, 2016 20:21:03 Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose
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"?
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"?
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)?
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.
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@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@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
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Chris, could you expand on this point with some examples. Shane Kerr suggested that creation to deletion was not a complete life cycle by suggesting we include “reserved” names that are declared before creation. I asked if “reserved” (and “archived”) are really separate end points or just a detail inside of creation and deletion. What do you think? Jim On 9 Sep 2016, at 3:09, Chris Pelling wrote:
We also need to consider that the life-cycle of the domain is not entirely under the control of the registrant whom provided the data, which then brings in Privacy law for example. The life-cycle meaning for this purpose would need to be very well defined.
Kind regards,
Chris
From: "Greg Shatan" <gregshatanipc@gmail.com> To: "Gomes, Chuck" <cgomes@verisign.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 8 September, 2016 20:21:03 Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose
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"?
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"?
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)?
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.
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@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@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
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi Jim, My point was in regard domains that cannot be deleted or when the deletion request is rejected by the registry and is never allowed to complete. For example domains that Verisign have on serverHold is an example. The domains "life-cycle" would normally be when a registrant registers the domain, renewals/transfers in between, then no longer wants a domain, it enters RGP, if not renewed by Registrant, then generally deleted by the registrar sending an EPP command to the registry, registrant can still redeem in Redemption period at a higher price and if at that point the registrant does not redeem it, At any point the registrant can request their domain be deleted (and they on some panels can do this themselves) at which point it immediately enters RGP. Kind regards, Chris From: "James Galvin" <jgalvin@afilias.info> To: "chris" <chris@netearth.net> Cc: "Greg Shatan" <gregshatanipc@gmail.com>, "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Friday, 9 September, 2016 13:30:33 Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose Chris, could you expand on this point with some examples. Shane Kerr suggested that creation to deletion was not a complete life cycle by suggesting we include “reserved” names that are declared before creation. I asked if “reserved” (and “archived”) are really separate end points or just a detail inside of creation and deletion. What do you think? Jim On 9 Sep 2016, at 3:09, Chris Pelling wrote:
We also need to consider that the life-cycle of the domain is not entirely under the control of the registrant whom provided the data, which then brings in Privacy law for example. The life-cycle meaning for this purpose would need to be very well defined.
Kind regards,
Chris
From: "Greg Shatan" <gregshatanipc@gmail.com> To: "Gomes, Chuck" <cgomes@verisign.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 8 September, 2016 20:21:03 Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose
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"?
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"?
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)?
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.
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@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@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
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Chris, It might be helpful for those not directly involved in the domain name registration business to share some examples of when a domain is not under the control of the registrant. Chuck From: Chris Pelling [mailto:chris@netearth.net] Sent: Friday, September 09, 2016 3:09 AM To: Greg Shatan Cc: Gomes, Chuck; gnso-rds-pdp-wg Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose We also need to consider that the life-cycle of the domain is not entirely under the control of the registrant whom provided the data, which then brings in Privacy law for example. The life-cycle meaning for this purpose would need to be very well defined. Kind regards, Chris ________________________________ From: "Greg Shatan" <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> To: "Gomes, Chuck" <cgomes@verisign.com<mailto:cgomes@verisign.com>> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Sent: Thursday, 8 September, 2016 20:21:03 Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose 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"? 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"? 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)? 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. 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@verisign.com<mailto:cgomes@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@icann.org<mailto: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<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi Chuck, Sure, from my (registrar) point of view there can be a few, that I have personally witnessed, other registrars may know of others that they have been subjected too. UDRP (Domain Name Dispute Resolution Policies) - Domain is locked at time of request of information by UDRP provider, thus domain remains locked for that period of the panel making a decision. Lock completed by Registrar in this case. URS (Uniform Rapid Suspension) - Essentially domain is suspended by the Registry in this case ( I have not had one of these yet so hazy ) Registrar domain suspension - This could be locked by registrar, for abuse of ToS / AUP for example, domain would then enter normal RGP, Redemption and deletion. serverHold Status - This is a funny one, and can happen for a number of reasons, I have personally had a registry simply suspend the domain name, tells the registrar "oh its by court order" in which case you might get a copy of the court order , or better than that "sealed court order" where you get nothing - nowt - not a sausage from the registry and you have no comeback, left in limbo and the registrant has no idea (sometimes) why the domain is now dead. In this state, registrar cannot delete domain, make changes too or anything at registry. On WHOIS however in a thin environment, the registrar does still have the option to make changes to the registrant data. The above is not exhaustive. Kind regards, Chris From: "Gomes, Chuck" <cgomes@verisign.com> To: "chris" <chris@netearth.net>, "Greg Shatan" <gregshatanipc@gmail.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Friday, 9 September, 2016 14:52:25 Subject: RE: [gnso-rds-pdp-wg] RDS Statement of Purpose Chris, It might be helpful for those not directly involved in the domain name registration business to share some examples of when a domain is not under the control of the registrant. Chuck From: Chris Pelling [mailto:chris@netearth.net] Sent: Friday, September 09, 2016 3:09 AM To: Greg Shatan Cc: Gomes, Chuck; gnso-rds-pdp-wg Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose We also need to consider that the life-cycle of the domain is not entirely under the control of the registrant whom provided the data, which then brings in Privacy law for example. The life-cycle meaning for this purpose would need to be very well defined. Kind regards, Chris From: "Greg Shatan" < gregshatanipc@gmail.com > To: "Gomes, Chuck" < cgomes@verisign.com > Cc: "gnso-rds-pdp-wg" < gnso-rds-pdp-wg@icann.org > Sent: Thursday, 8 September, 2016 20:21:03 Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose 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"? 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"? 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)? 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. 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@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@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
It will be a good exercise for us to populate this diagram, or one equivalent to it, with the list of activities and proposed endpoints. https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en It would be a similar discussion to that for use cases. /marksv From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Chris Pelling Sent: Friday, September 9, 2016 8:02 AM To: Gomes, Chuck <cgomes@verisign.com> Cc: gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose Hi Chuck, Sure, from my (registrar) point of view there can be a few, that I have personally witnessed, other registrars may know of others that they have been subjected too. UDRP (Domain Name Dispute Resolution Policies) - Domain is locked at time of request of information by UDRP provider, thus domain remains locked for that period of the panel making a decision. Lock completed by Registrar in this case. URS (Uniform Rapid Suspension) - Essentially domain is suspended by the Registry in this case ( I have not had one of these yet so hazy ) Registrar domain suspension - This could be locked by registrar, for abuse of ToS / AUP for example, domain would then enter normal RGP, Redemption and deletion. serverHold Status - This is a funny one, and can happen for a number of reasons, I have personally had a registry simply suspend the domain name, tells the registrar "oh its by court order" in which case you might get a copy of the court order , or better than that "sealed court order" where you get nothing - nowt - not a sausage from the registry and you have no comeback, left in limbo and the registrant has no idea (sometimes) why the domain is now dead. In this state, registrar cannot delete domain, make changes too or anything at registry. On WHOIS however in a thin environment, the registrar does still have the option to make changes to the registrant data. The above is not exhaustive. Kind regards, Chris ________________________________ From: "Gomes, Chuck" <cgomes@verisign.com<mailto:cgomes@verisign.com>> To: "chris" <chris@netearth.net<mailto:chris@netearth.net>>, "Greg Shatan" <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Sent: Friday, 9 September, 2016 14:52:25 Subject: RE: [gnso-rds-pdp-wg] RDS Statement of Purpose Chris, It might be helpful for those not directly involved in the domain name registration business to share some examples of when a domain is not under the control of the registrant. Chuck From: Chris Pelling [mailto:chris@netearth.net] Sent: Friday, September 09, 2016 3:09 AM To: Greg Shatan Cc: Gomes, Chuck; gnso-rds-pdp-wg Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose We also need to consider that the life-cycle of the domain is not entirely under the control of the registrant whom provided the data, which then brings in Privacy law for example. The life-cycle meaning for this purpose would need to be very well defined. Kind regards, Chris ________________________________ From: "Greg Shatan" <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> To: "Gomes, Chuck" <cgomes@verisign.com<mailto:cgomes@verisign.com>> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Sent: Thursday, 8 September, 2016 20:21:03 Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose 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"? 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"? 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)? 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. 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@verisign.com<mailto:cgomes@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@icann.org<mailto: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<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Good idea Mark. Chuck From: Mark Svancarek [mailto:marksv@microsoft.com] Sent: Friday, September 09, 2016 12:37 PM To: Chris Pelling; Gomes, Chuck Cc: gnso-rds-pdp-wg Subject: RE: [gnso-rds-pdp-wg] RDS Statement of Purpose It will be a good exercise for us to populate this diagram, or one equivalent to it, with the list of activities and proposed endpoints. https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en It would be a similar discussion to that for use cases. /marksv 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 Chris Pelling Sent: Friday, September 9, 2016 8:02 AM To: Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>> Cc: gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose Hi Chuck, Sure, from my (registrar) point of view there can be a few, that I have personally witnessed, other registrars may know of others that they have been subjected too. UDRP (Domain Name Dispute Resolution Policies) - Domain is locked at time of request of information by UDRP provider, thus domain remains locked for that period of the panel making a decision. Lock completed by Registrar in this case. URS (Uniform Rapid Suspension) - Essentially domain is suspended by the Registry in this case ( I have not had one of these yet so hazy ) Registrar domain suspension - This could be locked by registrar, for abuse of ToS / AUP for example, domain would then enter normal RGP, Redemption and deletion. serverHold Status - This is a funny one, and can happen for a number of reasons, I have personally had a registry simply suspend the domain name, tells the registrar "oh its by court order" in which case you might get a copy of the court order , or better than that "sealed court order" where you get nothing - nowt - not a sausage from the registry and you have no comeback, left in limbo and the registrant has no idea (sometimes) why the domain is now dead. In this state, registrar cannot delete domain, make changes too or anything at registry. On WHOIS however in a thin environment, the registrar does still have the option to make changes to the registrant data. The above is not exhaustive. Kind regards, Chris ________________________________ From: "Gomes, Chuck" <cgomes@verisign.com<mailto:cgomes@verisign.com>> To: "chris" <chris@netearth.net<mailto:chris@netearth.net>>, "Greg Shatan" <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Sent: Friday, 9 September, 2016 14:52:25 Subject: RE: [gnso-rds-pdp-wg] RDS Statement of Purpose Chris, It might be helpful for those not directly involved in the domain name registration business to share some examples of when a domain is not under the control of the registrant. Chuck From: Chris Pelling [mailto:chris@netearth.net] Sent: Friday, September 09, 2016 3:09 AM To: Greg Shatan Cc: Gomes, Chuck; gnso-rds-pdp-wg Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose We also need to consider that the life-cycle of the domain is not entirely under the control of the registrant whom provided the data, which then brings in Privacy law for example. The life-cycle meaning for this purpose would need to be very well defined. Kind regards, Chris ________________________________ From: "Greg Shatan" <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> To: "Gomes, Chuck" <cgomes@verisign.com<mailto:cgomes@verisign.com>> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Sent: Thursday, 8 September, 2016 20:21:03 Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose 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"? 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"? 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)? 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. 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@verisign.com<mailto:cgomes@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@icann.org<mailto: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<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Thanks a lot Chris. I think your examples will help everyone understand corner cases. Chuck From: Chris Pelling [mailto:chris@netearth.net] Sent: Friday, September 09, 2016 11:02 AM To: Gomes, Chuck Cc: Greg Shatan; gnso-rds-pdp-wg Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose Hi Chuck, Sure, from my (registrar) point of view there can be a few, that I have personally witnessed, other registrars may know of others that they have been subjected too. UDRP (Domain Name Dispute Resolution Policies) - Domain is locked at time of request of information by UDRP provider, thus domain remains locked for that period of the panel making a decision. Lock completed by Registrar in this case. URS (Uniform Rapid Suspension) - Essentially domain is suspended by the Registry in this case ( I have not had one of these yet so hazy ) Registrar domain suspension - This could be locked by registrar, for abuse of ToS / AUP for example, domain would then enter normal RGP, Redemption and deletion. serverHold Status - This is a funny one, and can happen for a number of reasons, I have personally had a registry simply suspend the domain name, tells the registrar "oh its by court order" in which case you might get a copy of the court order , or better than that "sealed court order" where you get nothing - nowt - not a sausage from the registry and you have no comeback, left in limbo and the registrant has no idea (sometimes) why the domain is now dead. In this state, registrar cannot delete domain, make changes too or anything at registry. On WHOIS however in a thin environment, the registrar does still have the option to make changes to the registrant data. The above is not exhaustive. Kind regards, Chris ________________________________ From: "Gomes, Chuck" <cgomes@verisign.com<mailto:cgomes@verisign.com>> To: "chris" <chris@netearth.net<mailto:chris@netearth.net>>, "Greg Shatan" <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Sent: Friday, 9 September, 2016 14:52:25 Subject: RE: [gnso-rds-pdp-wg] RDS Statement of Purpose Chris, It might be helpful for those not directly involved in the domain name registration business to share some examples of when a domain is not under the control of the registrant. Chuck From: Chris Pelling [mailto:chris@netearth.net] Sent: Friday, September 09, 2016 3:09 AM To: Greg Shatan Cc: Gomes, Chuck; gnso-rds-pdp-wg Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose We also need to consider that the life-cycle of the domain is not entirely under the control of the registrant whom provided the data, which then brings in Privacy law for example. The life-cycle meaning for this purpose would need to be very well defined. Kind regards, Chris ________________________________ From: "Greg Shatan" <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> To: "Gomes, Chuck" <cgomes@verisign.com<mailto:cgomes@verisign.com>> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org<mailto:gnso-rds-pdp-wg@icann.org>> Sent: Thursday, 8 September, 2016 20:21:03 Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose 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"? 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"? 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)? 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. 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@verisign.com<mailto:cgomes@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@icann.org<mailto: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<mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
What is meant by drop-catch activity? Nathalie On Friday, September 9, 2016 12:43 PM, "Gomes, Chuck" <cgomes@verisign.com> wrote: #yiv0569762419 #yiv0569762419 -- _filtered #yiv0569762419 {font-family:Cambria;panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0569762419 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv0569762419 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;} _filtered #yiv0569762419 {font-family:Verdana;panose-1:2 11 6 4 3 5 4 4 2 4;} _filtered #yiv0569762419 {panose-1:2 15 7 4 3 5 4 3 2 4;}#yiv0569762419 #yiv0569762419 p.yiv0569762419MsoNormal, #yiv0569762419 li.yiv0569762419MsoNormal, #yiv0569762419 div.yiv0569762419MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0569762419 h2 {margin-right:0in;margin-left:0in;font-size:18.0pt;}#yiv0569762419 a:link, #yiv0569762419 span.yiv0569762419MsoHyperlink {color:blue;text-decoration:underline;}#yiv0569762419 a:visited, #yiv0569762419 span.yiv0569762419MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv0569762419 p.yiv0569762419MsoAcetate, #yiv0569762419 li.yiv0569762419MsoAcetate, #yiv0569762419 div.yiv0569762419MsoAcetate {margin:0in;margin-bottom:.0001pt;font-size:8.0pt;}#yiv0569762419 span.yiv0569762419Heading2Char {color:#4F81BD;font-weight:bold;}#yiv0569762419 span.yiv0569762419BalloonTextChar {}#yiv0569762419 span.yiv0569762419EmailStyle20 {color:#1F497D;}#yiv0569762419 span.yiv0569762419EmailStyle21 {color:#1F497D;}#yiv0569762419 .yiv0569762419MsoChpDefault {font-size:10.0pt;} _filtered #yiv0569762419 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv0569762419 div.yiv0569762419WordSection1 {}#yiv0569762419 Thanks a lot Chris. I think your examples will help everyone understand corner cases. Chuck From: Chris Pelling [mailto:chris@netearth.net] Sent: Friday, September 09, 2016 11:02 AM To: Gomes, Chuck Cc: Greg Shatan; gnso-rds-pdp-wg Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose Hi Chuck, Sure, from my (registrar) point of view there can be a few, that I have personally witnessed, other registrars may know of others that they have been subjected too. UDRP (Domain Name Dispute Resolution Policies) - Domain is locked at time of request of information by UDRP provider, thus domain remains locked for that period of the panel making a decision. Lock completed by Registrar in this case. URS (Uniform Rapid Suspension) - Essentially domain is suspended by the Registry in this case ( I have not had one of these yet so hazy ) Registrar domain suspension - This could be locked by registrar, for abuse of ToS / AUP for example, domain would then enter normal RGP, Redemption and deletion. serverHold Status - This is a funny one, and can happen for a number of reasons, I have personally had a registry simply suspend the domain name, tells the registrar "oh its by court order" in which case you might get a copy of the court order , or better than that "sealed court order" where you get nothing - nowt - not a sausage from the registry and you have no comeback, left in limbo and the registrant has no idea (sometimes) why the domain is now dead. In this state, registrar cannot delete domain, make changes too or anything at registry. On WHOIS however in a thin environment, the registrar does still have the option to make changes to the registrant data. The above is not exhaustive. Kind regards, Chris From:"Gomes, Chuck" <cgomes@verisign.com> To: "chris" <chris@netearth.net>, "Greg Shatan" <gregshatanipc@gmail.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Friday, 9 September, 2016 14:52:25 Subject: RE: [gnso-rds-pdp-wg] RDS Statement of Purpose Chris, It might be helpful for those not directly involved in the domain name registration business to share some examples of when a domain is not under the control of the registrant. Chuck From: Chris Pelling [mailto:chris@netearth.net] Sent: Friday, September 09, 2016 3:09 AM To: Greg Shatan Cc: Gomes, Chuck; gnso-rds-pdp-wg Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose We also need to consider that the life-cycle of the domain is not entirely under the control of the registrant whom provided the data, which then brings in Privacy law for example. The life-cycle meaning for this purpose would need to be very well defined. Kind regards, Chris From:"Greg Shatan" <gregshatanipc@gmail.com> To: "Gomes, Chuck" <cgomes@verisign.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 8 September, 2016 20:21:03 Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose 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"? 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"? 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)? 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. 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@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@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 _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Basically where a registrar will have back orders for the domain name and will be waiting for the domain to be dropped by the registry so that it can quickly register the domain and then sell it on at a huge mark up. Sent from Chris on the move... On Fri, Sep 9, 2016 at 5:53 PM +0100, "nathalie coupet" <nathaliecoupet@yahoo.com> wrote: What is meant by drop-catch activity? Nathalie On Friday, September 9, 2016 12:43 PM, "Gomes, Chuck" <cgomes@verisign.com> wrote: #yiv0569762419 #yiv0569762419 -- _filtered #yiv0569762419 {font-family:Cambria;panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv0569762419 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv0569762419 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;} _filtered #yiv0569762419 {font-family:Verdana;panose-1:2 11 6 4 3 5 4 4 2 4;} _filtered #yiv0569762419 {panose-1:2 15 7 4 3 5 4 3 2 4;}#yiv0569762419 #yiv0569762419 p.yiv0569762419MsoNormal, #yiv0569762419 li.yiv0569762419MsoNormal, #yiv0569762419 div.yiv0569762419MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv0569762419 h2 {margin-right:0in;margin-left:0in;font-size:18.0pt;}#yiv0569762419 a:link, #yiv0569762419 span.yiv0569762419MsoHyperlink {color:blue;text-decoration:underline;}#yiv0569762419 a:visited, #yiv0569762419 span.yiv0569762419MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv0569762419 p.yiv0569762419MsoAcetate, #yiv0569762419 li.yiv0569762419MsoAcetate, #yiv0569762419 div.yiv0569762419MsoAcetate {margin:0in;margin-bottom:.0001pt;font-size:8.0pt;}#yiv0569762419 span.yiv0569762419Heading2Char {color:#4F81BD;font-weight:bold;}#yiv0569762419 span.yiv0569762419BalloonTextChar {}#yiv0569762419 span.yiv0569762419EmailStyle20 {color:#1F497D;}#yiv0569762419 span.yiv0569762419EmailStyle21 {color:#1F497D;}#yiv0569762419 .yiv0569762419MsoChpDefault {font-size:10.0pt;} _filtered #yiv0569762419 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv0569762419 div.yiv0569762419WordSection1 {}#yiv0569762419 Thanks a lot Chris. I think your examples will help everyone understand corner cases. Chuck From: Chris Pelling [mailto:chris@netearth.net] Sent: Friday, September 09, 2016 11:02 AM To: Gomes, Chuck Cc: Greg Shatan; gnso-rds-pdp-wg Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose Hi Chuck, Sure, from my (registrar) point of view there can be a few, that I have personally witnessed, other registrars may know of others that they have been subjected too. UDRP (Domain Name Dispute Resolution Policies) - Domain is locked at time of request of information by UDRP provider, thus domain remains locked for that period of the panel making a decision. Lock completed by Registrar in this case. URS (Uniform Rapid Suspension) - Essentially domain is suspended by the Registry in this case ( I have not had one of these yet so hazy ) Registrar domain suspension - This could be locked by registrar, for abuse of ToS / AUP for example, domain would then enter normal RGP, Redemption and deletion. serverHold Status - This is a funny one, and can happen for a number of reasons, I have personally had a registry simply suspend the domain name, tells the registrar "oh its by court order" in which case you might get a copy of the court order , or better than that "sealed court order" where you get nothing - nowt - not a sausage from the registry and you have no comeback, left in limbo and the registrant has no idea (sometimes) why the domain is now dead. In this state, registrar cannot delete domain, make changes too or anything at registry. On WHOIS however in a thin environment, the registrar does still have the option to make changes to the registrant data. The above is not exhaustive. Kind regards, Chris From:"Gomes, Chuck" <cgomes@verisign.com> To: "chris" <chris@netearth.net>, "Greg Shatan" <gregshatanipc@gmail.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Friday, 9 September, 2016 14:52:25 Subject: RE: [gnso-rds-pdp-wg] RDS Statement of Purpose Chris, It might be helpful for those not directly involved in the domain name registration business to share some examples of when a domain is not under the control of the registrant. Chuck From: Chris Pelling [mailto:chris@netearth.net] Sent: Friday, September 09, 2016 3:09 AM To: Greg Shatan Cc: Gomes, Chuck; gnso-rds-pdp-wg Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose We also need to consider that the life-cycle of the domain is not entirely under the control of the registrant whom provided the data, which then brings in Privacy law for example. The life-cycle meaning for this purpose would need to be very well defined. Kind regards, Chris From:"Greg Shatan" <gregshatanipc@gmail.com> To: "Gomes, Chuck" <cgomes@verisign.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Thursday, 8 September, 2016 20:21:03 Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose 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"? 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"? 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)? 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. 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@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@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 _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
I think the important point here from a privacy perspective is that the registrant information is not under the individual's control, from the moment it is given to the registrar. They have access and correction rights/requirements, but they do not control the data. We perhaps need a diagram that tracks that data and maps it to the life cycle of a domain (which is a different diagram). There will be points of connection where registrant data is entering new spheres (ie is shared) and some of these existing shares may not conform to data protection law. Given the lack of case law in this area, I think it is worth pointing out here that most of the focus in ICANN privacy discussions has been on the public directory (WHOIS) and the data retention requirement. (less on escrow). I am unaware of a DPA focus on the RPMS and their use of data, but if anyone knows otherwise I would be grateful for the information. cheers Stephanie Perrin On 2016-09-09 03:09, Chris Pelling wrote:
We also need to consider that the life-cycle of the domain is not entirely under the control of the registrant whom provided the data, which then brings in Privacy law for example. The life-cycle meaning for this purpose would need to be very well defined.
Kind regards,
Chris
------------------------------------------------------------------------ *From: *"Greg Shatan" <gregshatanipc@gmail.com> *To: *"Gomes, Chuck" <cgomes@verisign.com> *Cc: *"gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> *Sent: *Thursday, 8 September, 2016 20:21:03 *Subject: *Re: [gnso-rds-pdp-wg] RDS Statement of Purpose
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"?
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"?
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)?
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.
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@verisign.com <mailto:cgomes@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@icann.org <mailto: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
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi Greg, in the industry, the life cycle of a domain refers to the stages a domain goes through from birth to death, err, from registration to deletion. See also: https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en This may vary from TLD to TLD and on the terms of your registrar. The minimum standard would in this context be a display of the current status of the domain in its life cycle, for example: pending delete for a domain about to die, err, deleted. As a primary purpose, the domain registration data minimum should include everything necessary to the management of the domain lifecycle. Best, Volker Am 08.09.2016 um 21:21 schrieb Greg Shatan:
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"?
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"?
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)?
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.
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@verisign.com <mailto:cgomes@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@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <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
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
I believe we are in agreement but just to be sure let me ask a specific question related to the diagram you referenced. In that diagram, a registrant identity would be associated with a domain from the point immediately after the “available” cloud to the point just before the “released” cloud. Further, I could imagine, going back to a comment that Share Kerr made, that a parallel line exists for names that are reserved by a registry, i.e., the “registrant” (or contact information) for a reserved name is the registry. My reason for suggesting a separate path is because the events that affect the life cycle of a reserved name are different than those that affect a registered name. Do you agree? Jim On 9 Sep 2016, at 6:07, Volker Greimann wrote:
Hi Greg,
in the industry, the life cycle of a domain refers to the stages a domain goes through from birth to death, err, from registration to deletion. See also:
https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en
This may vary from TLD to TLD and on the terms of your registrar.
The minimum standard would in this context be a display of the current status of the domain in its life cycle, for example: pending delete for a domain about to die, err, deleted. As a primary purpose, the domain registration data minimum should include everything necessary to the management of the domain lifecycle.
Best,
Volker
Am 08.09.2016 um 21:21 schrieb Greg Shatan:
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"?
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"?
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)?
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.
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@verisign.com <mailto:cgomes@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@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <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
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
Hi James, thanks for your questions. I think ICANN wanted to demonstrate a basic standard sample life cycle of a domain, hence the reference to a typical domain. There may be differences from TLD to TLD and also between domains depending on what the circumstances of their registration are. Heck, life cycles may be different even between registrars depending on the contractual framework between registrar and registrant. As for non-registered reserved names, I do not consider those as domains in the standard domain life cycle, but rather as "unborn" domains. Registered reserved names are again different. Some of those will be registered through a registrar normally (see Uniregistry premium model) and therefore will follow the standard life cycle closely, while others will be registered by the registry under the "100 names model" and exhibit a unique life cycle as no registrar is involved. Best, Volker Am 09.09.2016 um 14:26 schrieb James Galvin:
I believe we are in agreement but just to be sure let me ask a specific question related to the diagram you referenced.
In that diagram, a registrant identity would be associated with a domain from the point immediately after the “available” cloud to the point just before the “released” cloud.
Further, I could imagine, going back to a comment that Share Kerr made, that a parallel line exists for names that are reserved by a registry, i.e., the “registrant” (or contact information) for a reserved name is the registry. My reason for suggesting a separate path is because the events that affect the life cycle of a reserved name are different than those that affect a registered name.
Do you agree?
Jim
On 9 Sep 2016, at 6:07, Volker Greimann wrote:
Hi Greg,
in the industry, the life cycle of a domain refers to the stages a domain goes through from birth to death, err, from registration to deletion. See also:
https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en
This may vary from TLD to TLD and on the terms of your registrar.
The minimum standard would in this context be a display of the current status of the domain in its life cycle, for example: pending delete for a domain about to die, err, deleted. As a primary purpose, the domain registration data minimum should include everything necessary to the management of the domain lifecycle.
Best,
Volker
Am 08.09.2016 um 21:21 schrieb Greg Shatan:
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"?
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"?
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)?
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.
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@verisign.com <mailto:cgomes@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@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <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
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.
Mit freundlichen Grüßen,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems
Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung. Mit freundlichen Grüßen, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Geschäftsführer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
Chuck, I would like to offer the following contribution on the "life cycle of a domain" discussion thread regarding a particular business model that exists but is NOT widely known. Pending Create is an EPP functionality that allows Registrars to submit requests for domain names to a Registry Operator. In the case of VeriSign's implementation of Pending Create for its backend clients, the information provided by the Registrant to the Registrar is forwarded to the Registry Operator and is publicly made available via the standard whois output. During this Pending Create period the registrant has no control over the domain name as it does not appear in the zone file, but does appear in publicly available Whois data. Now one of two things can happen. If the Registry Operator "approves" the qualification of the registrant to register in the TLD, the name is placed into an active state and resolves via the zone file for that TLD. The domain name's creation/renewal date is the date of original submission, even though the registrant did not have full use of the domain name from the initial entry into the authoritative database of the Registry. The other thing that could happen is that the Registry Operator rejects the domain name based upon the Registrant failing to meet the requirements. For those Registry Operators using the VRSN system, after the Registry Operator rejects the domain name, the name is removed from the authoritative database (i.e. no more whois queries will be associated with this domain) and the registrar is given a full refund. A slight variation of the Pending Create functionality in connection the VeriSign system is what happens with the Registry Operator does nothing, i.e. does not affirmative approve or reject a domain name. In this case the domain name is automatically dropped and the registrar is refunded after a set period of time as identified by the Registry Operator. Now Afilias' implementation of Pending Create is slightly different. Afilias' use of the Pending Create functionality has been extensively used in connection with End Date Sunrises, where a Registry Operator will queue multiple requests for the same domain name from multiple registrars/registrants. The Registry Operator then has to decide how to prioritize the multiple requests, e.g. auction, RFP, etc. Now because Afilias' implementation of the Pending Create could have multiple requests for the same domain name, it is NOT possible to do a public Whois query for this domain. I guess the point I am trying to raise with this regrettably long email is that while the life cycle of a domain name was largely uniform pre 2012, the growth of brand and other restrictive TLD that will be using the Pending Create functionality as part of the domain name life cycle does not neatly fit into a single box. I hope this helps. Best regards, Michael -----Original Message----- From: gnso-rds-pdp-wg-bounces@icann.org [mailto:gnso-rds-pdp-wg-bounces@icann.org] On Behalf Of Volker Greimann Sent: Friday, September 9, 2016 8:35 AM To: James Galvin <jgalvin@afilias.info> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose Hi James, thanks for your questions. I think ICANN wanted to demonstrate a basic standard sample life cycle of a domain, hence the reference to a typical domain. There may be differences from TLD to TLD and also between domains depending on what the circumstances of their registration are. Heck, life cycles may be different even between registrars depending on the contractual framework between registrar and registrant. As for non-registered reserved names, I do not consider those as domains in the standard domain life cycle, but rather as "unborn" domains. Registered reserved names are again different. Some of those will be registered through a registrar normally (see Uniregistry premium model) and therefore will follow the standard life cycle closely, while others will be registered by the registry under the "100 names model" and exhibit a unique life cycle as no registrar is involved. Best, Volker Am 09.09.2016 um 14:26 schrieb James Galvin:
I believe we are in agreement but just to be sure let me ask a specific question related to the diagram you referenced.
In that diagram, a registrant identity would be associated with a domain from the point immediately after the available cloud to the point just before the released cloud.
Further, I could imagine, going back to a comment that Share Kerr made, that a parallel line exists for names that are reserved by a registry, i.e., the registrant (or contact information) for a reserved name is the registry. My reason for suggesting a separate path is because the events that affect the life cycle of a reserved name are different than those that affect a registered name.
Do you agree?
Jim
On 9 Sep 2016, at 6:07, Volker Greimann wrote:
Hi Greg,
in the industry, the life cycle of a domain refers to the stages a domain goes through from birth to death, err, from registration to deletion. See also:
https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en
This may vary from TLD to TLD and on the terms of your registrar.
The minimum standard would in this context be a display of the current status of the domain in its life cycle, for example: pending delete for a domain about to die, err, deleted. As a primary purpose, the domain registration data minimum should include everything necessary to the management of the domain lifecycle.
Best,
Volker
Am 08.09.2016 um 21:21 schrieb Greg Shatan:
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"?
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"?
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)?
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.
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@verisign.com <mailto:cgomes@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@icann.org <mailto:gnso-rds-pdp-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg <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
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verf gung.
Mit freundlichen Gr en,
Volker A. Greimann - Rechtsabteilung -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems
Gesch ftsf hrer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
Der Inhalt dieser Nachricht ist vertraulich und nur f r den angegebenen Empf nger bestimmt. Jede Form der Kenntnisgabe, Ver ffentlichung oder Weitergabe an Dritte durch den Empf nger ist unzul ssig. Sollte diese Nachricht nicht f r Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen.
--------------------------------------------
Should you have any further questions, please do not hesitate to contact us.
Best regards,
Volker A. Greimann - legal department -
Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net
Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com
Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems
CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534
Member of the KEYDRIVE GROUP www.keydrive.lu
This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone.
_______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
-- Bei weiteren Fragen stehen wir Ihnen gerne zur Verf gung. Mit freundlichen Gr en, Volker A. Greimann - Rechtsabteilung - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook: www.facebook.com/KeySystems www.twitter.com/key_systems Gesch ftsf hrer: Alexander Siffrin Handelsregister Nr.: HR B 18835 - Saarbruecken Umsatzsteuer ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu Der Inhalt dieser Nachricht ist vertraulich und nur f r den angegebenen Empf nger bestimmt. Jede Form der Kenntnisgabe, Ver ffentlichung oder Weitergabe an Dritte durch den Empf nger ist unzul ssig. Sollte diese Nachricht nicht f r Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder telefonisch in Verbindung zu setzen. -------------------------------------------- Should you have any further questions, please do not hesitate to contact us. Best regards, Volker A. Greimann - legal department - Key-Systems GmbH Im Oberen Werk 1 66386 St. Ingbert Tel.: +49 (0) 6894 - 9396 901 Fax.: +49 (0) 6894 - 9396 851 Email: vgreimann@key-systems.net Web: www.key-systems.net / www.RRPproxy.net www.domaindiscount24.com / www.BrandShelter.com Follow us on Twitter or join our fan community on Facebook and stay updated: www.facebook.com/KeySystems www.twitter.com/key_systems CEO: Alexander Siffrin Registration No.: HR B 18835 - Saarbruecken V.A.T. ID.: DE211006534 Member of the KEYDRIVE GROUP www.keydrive.lu This e-mail and its attachments is intended only for the person to whom it is addressed. Furthermore it is not permitted to publish any content of this email. You must not use, disclose, copy, print or rely on this e-mail. If an addressing or transmission error has misdirected this e-mail, kindly notify the author by replying to this e-mail or contacting us by telephone. _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
On 9 Sep 2016, at 9:46, Michael D. Palage wrote:
During this Pending Create period the registrant has no control over the domain name as it does not appear in the zone file, but does appear in publicly available Whois data.
I think this is the most important point in your comment Michael. Your statement asserts that registrant “control” of a domain name is dependent on whether or not the domain name appears in the zone file. While you provide an excellent example in support of this in your description of pendingCreate, I believe your assertion to tightly-couple “control” with “zone presence” is inappropriate. There are several statuses during which a domain name will not appear in a zone file and a registrant still has primary “control” of a domain name, e.g., pendingDelete, at which time a registrant could take action to get a domain name restored. I consider this “control” in this case because no other registrant can acquire the domain name during this period. I would propose another way to think about pendingCreate as follows: First, I am not going to speak to the question of access to data via directory services at this time. That is a separate discussion we are not having yet. This discussion is strictly about the purpose of registration data. In a pendingCreate situation where more than one registrant may have asserted the create event, all of the aforementioned registrants share the “control” of a domain name. This “control” must be resolved to a single registrant before the pendingCreate expires or the create event itself expires and the domain name is returned to the “available pool”, i.e., all registrants lose “control” of a domain name. Jim
Jim, Thanks for constructive feedback. I was not trying to advocate that the appearance in the zone file meant anything. I was just trying to document different life cycle states that may or may not be readily available to the public. One of the main reasons I joined this group is because I have a number of clients that would like to try some "innovation" within in the domain name industry and they view the RDS/Whois as a potential source of innovation. Sadly all too often policy discussions get high jacked by commercial interest focused primarily on the .COM and other legacy operators. By way of example, the "volumes" explicitly set forth in the Redemption Grace Period were based largely, if not solely, on what made sense for .COM transactions. Best regards, Michael -----Original Message----- From: James Galvin [mailto:jgalvin@afilias.info] Sent: Friday, September 9, 2016 10:32 AM To: Michael D. Palage <michael@palage.com> Cc: gnso-rds-pdp-wg@icann.org Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose On 9 Sep 2016, at 9:46, Michael D. Palage wrote:
During this Pending Create period the registrant has no control over the domain name as it does not appear in the zone file, but does appear in publicly available Whois data.
I think this is the most important point in your comment Michael. Your statement asserts that registrant control of a domain name is dependent on whether or not the domain name appears in the zone file. While you provide an excellent example in support of this in your description of pendingCreate, I believe your assertion to tightly-couple control with zone presence is inappropriate. There are several statuses during which a domain name will not appear in a zone file and a registrant still has primary control of a domain name, e.g., pendingDelete, at which time a registrant could take action to get a domain name restored. I consider this control in this case because no other registrant can acquire the domain name during this period. I would propose another way to think about pendingCreate as follows: First, I am not going to speak to the question of access to data via directory services at this time. That is a separate discussion we are not having yet. This discussion is strictly about the purpose of registration data. In a pendingCreate situation where more than one registrant may have asserted the create event, all of the aforementioned registrants share the control of a domain name. This control must be resolved to a single registrant before the pendingCreate expires or the create event itself expires and the domain name is returned to the available pool , i.e., all registrants lose control of a domain name. Jim
I would have to agree here with James, control of the domain has no relevance to if it exists in the DNS Zone or not. The registrant could remove the nameservers entirely - its removed from the zone servers, but, the registrant still has "control" over the domain name. Kind regards, Chris From: "James Galvin" <jgalvin@afilias.info> To: "Michael D. Palage" <michael@palage.com> Cc: "gnso-rds-pdp-wg" <gnso-rds-pdp-wg@icann.org> Sent: Friday, 9 September, 2016 15:32:07 Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose On 9 Sep 2016, at 9:46, Michael D. Palage wrote:
During this Pending Create period the registrant has no control over the domain name as it does not appear in the zone file, but does appear in publicly available Whois data.
I think this is the most important point in your comment Michael. Your statement asserts that registrant “control” of a domain name is dependent on whether or not the domain name appears in the zone file. While you provide an excellent example in support of this in your description of pendingCreate, I believe your assertion to tightly-couple “control” with “zone presence” is inappropriate. There are several statuses during which a domain name will not appear in a zone file and a registrant still has primary “control” of a domain name, e.g., pendingDelete, at which time a registrant could take action to get a domain name restored. I consider this “control” in this case because no other registrant can acquire the domain name during this period. I would propose another way to think about pendingCreate as follows: First, I am not going to speak to the question of access to data via directory services at this time. That is a separate discussion we are not having yet. This discussion is strictly about the purpose of registration data. In a pendingCreate situation where more than one registrant may have asserted the create event, all of the aforementioned registrants share the “control” of a domain name. This “control” must be resolved to a single registrant before the pendingCreate expires or the create event itself expires and the domain name is returned to the “available pool”, i.e., all registrants lose “control” of a domain name. Jim _______________________________________________ gnso-rds-pdp-wg mailing list gnso-rds-pdp-wg@icann.org https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
participants (14)
-
benny＠nordreg.se -
Chris Pelling -
Gomes, Chuck -
Greg Aaron -
Greg Shatan -
Holly Raiche -
James Galvin -
Mark Svancarek -
Michael D. Palage -
nathalie coupet -
Shane Kerr -
Stephanie Perrin -
Victoria Sheckler -
Volker Greimann