<html><head></head><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_ym19_1_1473687200316_66609"><span id="yui_3_16_0_ym19_1_1473687200316_66611">Chuck</span></div><div id="yui_3_16_0_ym19_1_1473687200316_66609"><span><br></span></div><div id="yui_3_16_0_ym19_1_1473687200316_66609"><span id="yui_3_16_0_ym19_1_1473687200316_66653">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. </span></div><div id="yui_3_16_0_ym19_1_1473687200316_66609"><span id="yui_3_16_0_ym19_1_1473687200316_66888">If the life-cycle includes the entire useful life of a domain name with no limit in time, than my conclusion will be valid. </span></div><div id="yui_3_16_0_ym19_1_1473687200316_66609" dir="ltr"><span>If the definition is more limited, than I will retract this conclusion. </span></div><div></div><div id="yui_3_16_0_ym19_1_1473687200316_66435"> </div><div class="signature" id="yui_3_16_0_ym19_1_1473687200316_66437">Nathalie </div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"><font size="2" face="Arial"> On Sunday, September 11, 2016 8:33 PM, Mark Svancarek via gnso-rds-pdp-wg <gnso-rds-pdp-wg@icann.org> wrote:<br></font></div> <br><br> <div class="y_msg_container"><div id="yiv5432382732"><style>#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 </style><div>
<style type="text/css">#yiv5432382732 #yiv5432382732 -- P {margin-top:0;margin-bottom:0;}#yiv5432382732 </style>
<div id="yiv5432382732divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri, Arial, Helvetica, sans-serif;">
<div>Sorry, Greg, I am completely confused by your terminology - your explanation below decreased my understanding of your intent rather than improving it.
</div>
<div><br clear="none">
</div>
<div>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.<br clear="none">
</div>
</div>
<hr style="display:inline-block;width:98%;" tabindex="-1">
<div class="yiv5432382732yqt2245363265" id="yiv5432382732yqt08201"><div dir="ltr" id="yiv5432382732divRplyFwdMsg"><font face="Calibri, sans-serif" style="font-size:11pt;" color="#000000"><b>From:</b> Greg Aaron <gca@icginc.com><br clear="none">
<b>Sent:</b> Saturday, September 10, 2016 2:17:17 PM<br clear="none">
<b>To:</b> Mark Svancarek; James Galvin; Greg Shatan<br clear="none">
<b>Cc:</b> gnso-rds-pdp-wg@icann.org<br clear="none">
<b>Subject:</b> RE: [gnso-rds-pdp-wg] RDS Statement of Purpose</font>
<div> </div>
</div>
<div>
<div class="yiv5432382732WordSection1">
<div class="yiv5432382732MsoNormal"><a rel="nofollow" shape="rect" name="_MailEndCompose" href="">Dear Mark:</a></div>
<div class="yiv5432382732MsoNormal"><span style=""> </span></div>
<div class="yiv5432382732MsoNormal"><span style="">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 </span><a rel="nofollow" shape="rect" target="_blank" href="https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en"><span style="">https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en</span><span style=""></span></a><span style="">
</span></div>
<div class="yiv5432382732MsoNormal"><span style=""> </span></div>
<div class="yiv5432382732MsoNormal"><span style="">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. </span></div>
<div class="yiv5432382732MsoNormal"><span style=""> </span></div>
<div class="yiv5432382732MsoNormal"><span style="">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
<i>domain management</i> or <i>domain operations</i>. </span></div>
<div class="yiv5432382732MsoNormal"><span style=""> </span></div>
<div class="yiv5432382732MsoNormal"><span style="">UDRP is an ICANN policy, and registrants are obligated to follow it. It was not instituted to “support the lifecycle”,
</span><span style="">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.</span></div>
<div class="yiv5432382732MsoNormal"><span style=""> </span></div>
<div class="yiv5432382732MsoNormal"><span style="">In other words: lifecycle is a result and a servant; it is not a cause or justification of policy.</span></div>
<div class="yiv5432382732MsoNormal"><span style=""> </span></div>
<div class="yiv5432382732MsoNormal"><span style="">All best,</span></div>
<div class="yiv5432382732MsoNormal"><span style="">--Greg</span></div>
<div class="yiv5432382732MsoNormal"><span style=""> </span></div>
<div class="yiv5432382732MsoNormal"><span style=""> </span></div>
<span style=""></span>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in;">
<div class="yiv5432382732MsoNormal"><b>From:</b> Mark Svancarek [mailto:marksv@microsoft.com] <br clear="none">
<b>Sent:</b> Friday, September 9, 2016 2:27 PM<br clear="none">
<b>To:</b> Greg Aaron <gca@icginc.com>; James Galvin <jgalvin@afilias.info>; Greg Shatan <gregshatanipc@gmail.com><br clear="none">
<b>Cc:</b> gnso-rds-pdp-wg@icann.org<br clear="none">
<b>Subject:</b> RE: [gnso-rds-pdp-wg] RDS Statement of Purpose</div>
</div>
</div>
<div class="yiv5432382732MsoNormal"> </div>
<div class="yiv5432382732MsoPlainText">Greg, I disagree with your conclusion here:</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText" style="margin-left:1.0in;"><i>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.
</i></div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">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.</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">Ironically, I think you may be the one applying an exclusionary or reductive lens.</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">/marksv</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">-----Original Message-----<br clear="none">
From: <a rel="nofollow" shape="rect" ymailto="mailto:gnso-rds-pdp-wg-bounces@icann.org" target="_blank" href="mailto:gnso-rds-pdp-wg-bounces@icann.org">gnso-rds-pdp-wg-bounces@icann.org</a> [<a rel="nofollow" shape="rect" ymailto="mailto:gnso-rds-pdp-wg-bounces@icann.org" target="_blank" href="mailto:gnso-rds-pdp-wg-bounces@icann.org">mailto:gnso-rds-pdp-wg-bounces@icann.org</a>] On Behalf Of Greg Aaron<br clear="none">
Sent: Friday, September 9, 2016 10:48 AM<br clear="none">
To: James Galvin <<a rel="nofollow" shape="rect" ymailto="mailto:jgalvin@afilias.info" target="_blank" href="mailto:jgalvin@afilias.info">jgalvin@afilias.info</a>>; Greg Shatan <<a rel="nofollow" shape="rect" ymailto="mailto:gregshatanipc@gmail.com" target="_blank" href="mailto:gregshatanipc@gmail.com">gregshatanipc@gmail.com</a>><br clear="none">
Cc: <a rel="nofollow" shape="rect" ymailto="mailto:gnso-rds-pdp-wg@icann.org" target="_blank" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br clear="none">
Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">"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 <a rel="nofollow" shape="rect" target="_blank" href="https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en">
<span style="color:windowtext;text-decoration:none;">https://www.icann.org/resources/pages/gtld-lifecycle-2012-02-25-en</span></a> for a graphic of the typical gTLD domain lifecycle. (Yes, there are some exceptions like Pending Create etc.)
</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">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.</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">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".</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">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.
</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">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:</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">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.</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">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.”</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">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."</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">All that to say that Jim's proposed construct leaves a lot of issues to discuss.
</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">All best,</div>
<div class="yiv5432382732MsoPlainText">--Greg</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">-----Original Message-----</div>
<div class="yiv5432382732MsoPlainText">From: <a rel="nofollow" shape="rect" ymailto="mailto:gnso-rds-pdp-wg-bounces@icann.org" target="_blank" href="mailto:gnso-rds-pdp-wg-bounces@icann.org">
<span style="color:windowtext;text-decoration:none;">gnso-rds-pdp-wg-bounces@icann.org</span></a> [<a rel="nofollow" shape="rect" ymailto="mailto:gnso-rds-pdp-wg-bounces@icann.org" target="_blank" href="mailto:gnso-rds-pdp-wg-bounces@icann.org"><span style="color:windowtext;text-decoration:none;">mailto:gnso-rds-pdp-wg-bounces@icann.org</span></a>] On
Behalf Of James Galvin</div>
<div class="yiv5432382732MsoPlainText">Sent: Thursday, September 8, 2016 4:03 PM</div>
<div class="yiv5432382732MsoPlainText">To: Greg Shatan <<a rel="nofollow" shape="rect" ymailto="mailto:gregshatanipc@gmail.com" target="_blank" href="mailto:gregshatanipc@gmail.com"><span style="color:windowtext;text-decoration:none;">gregshatanipc@gmail.com</span></a>></div>
<div class="yiv5432382732MsoPlainText">Cc: <a rel="nofollow" shape="rect" ymailto="mailto:gnso-rds-pdp-wg@icann.org" target="_blank" href="mailto:gnso-rds-pdp-wg@icann.org"><span style="color:windowtext;text-decoration:none;">gnso-rds-pdp-wg@icann.org</span></a></div>
<div class="yiv5432382732MsoPlainText">Subject: Re: [gnso-rds-pdp-wg] RDS Statement of Purpose</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">Greg, excellent questions, which I said on the call when you asked them.
</div>
<div class="yiv5432382732MsoPlainText"> I believe that all of these questions deserve some discussion so we can understand the effect of different answers.</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">I have added inline some thoughts that I have regarding your questions.
</div>
<div class="yiv5432382732MsoPlainText">I am, of course, very interested in what others think.</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">On 8 Sep 2016, at 15:21, Greg Shatan wrote:</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">> I expressed a concern about this on the call (it may have been in the
</div>
<div class="yiv5432382732MsoPlainText">> chat), along the following lines: What exactly is meant by "the
</div>
<div class="yiv5432382732MsoPlainText">> life-cycle of a domain name"?</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">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.
</div>
<div class="yiv5432382732MsoPlainText">The data that is collected would only be data necessary to support creation, the selected events, and finally the expiration of the domain name.</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">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</div>
<div class="yiv5432382732MsoPlainText">two: a) is this the absolute minimum? b) is this sufficient?</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">> </div>
<div class="yiv5432382732MsoPlainText">> Also, is this meant to be a minimum standard (i.e., RDS must, at a
</div>
<div class="yiv5432382732MsoPlainText">> minimum, support the life-cycle of a domain name), to which other
</div>
<div class="yiv5432382732MsoPlainText">> elements can be added?</div>
<div class="yiv5432382732MsoPlainText">> </div>
<div class="yiv5432382732MsoPlainText">> Or is this meant to be a limiting standard (i.e., RDS must not do more
</div>
<div class="yiv5432382732MsoPlainText">> than support the life-cycle of a domain name), to which other elements
</div>
<div class="yiv5432382732MsoPlainText">> can be added only if they fit within the "life-cycle of a domain
</div>
<div class="yiv5432382732MsoPlainText">> name"?</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">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.</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">> </div>
<div class="yiv5432382732MsoPlainText">> Or is this meant to be a "primary purpose" standard, where other
</div>
<div class="yiv5432382732MsoPlainText">> elements can be added, but they would not be considered a "primary
</div>
<div class="yiv5432382732MsoPlainText">> purpose"</div>
<div class="yiv5432382732MsoPlainText">> (which</div>
<div class="yiv5432382732MsoPlainText">> has a significant downstream effect, e.g., in certain privacy
</div>
<div class="yiv5432382732MsoPlainText">> legislation)?</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">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.</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">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.</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">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.</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">> </div>
<div class="yiv5432382732MsoPlainText">> Finally, I would ask which of the use cases that we have on our list
</div>
<div class="yiv5432382732MsoPlainText">> fall within "the life-cycle of a domain name" and which do not? (I
</div>
<div class="yiv5432382732MsoPlainText">> suppose this last question is intertwined with my first question
</div>
<div class="yiv5432382732MsoPlainText">> above.</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">This is a discussion we need to have in this working group.</div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText"> </div>
<div class="yiv5432382732MsoPlainText">> </div>
<div class="yiv5432382732MsoPlainText">> Depending on what other participants believe the answers to these
</div>
<div class="yiv5432382732MsoPlainText">> questions should be, and what their effect may be, I may have
</div>
<div class="yiv5432382732MsoPlainText">> significant concerns about this statement.</div>
<div class="yiv5432382732MsoPlainText">> </div>
<div class="yiv5432382732MsoPlainText">> Greg</div>
<div class="yiv5432382732MsoPlainText">> </div>
<div class="yiv5432382732MsoPlainText">> On Thu, Sep 8, 2016 at 2:52 PM, Gomes, Chuck <<a rel="nofollow" shape="rect" ymailto="mailto:cgomes@verisign.com" target="_blank" href="mailto:cgomes@verisign.com"><span style="color:windowtext;text-decoration:none;">cgomes@verisign.com</span></a>></div>
<div class="yiv5432382732MsoPlainText">> wrote:</div>
<div class="yiv5432382732MsoPlainText">> </div>
<div class="yiv5432382732MsoPlainText">>> In our call earlier this week there seemed to be support for one
</div>
<div class="yiv5432382732MsoPlainText">>> element of a RDS Statement of Purpose as suggested by Jim Galvin:</div>
<div class="yiv5432382732MsoPlainText">>> “The RDS should support the life cycle of a domain name.” No one on
</div>
<div class="yiv5432382732MsoPlainText">>> the call disagreed with this; if anyone not on the call has comments
</div>
<div class="yiv5432382732MsoPlainText">>> on this please communicate so on this list prior to our call next
</div>
<div class="yiv5432382732MsoPlainText">>> week. Also, if any one who was on the call has comments that you did
</div>
<div class="yiv5432382732MsoPlainText">>> not share, please do so before next week’s meeting.</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> Also, it would be helpful if everyone could be thinking about answers
</div>
<div class="yiv5432382732MsoPlainText">>> to the following questions:</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> · What are the criteria for a statement of purpose?</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> · What elements, if any, from the EWG statement of purpose
</div>
<div class="yiv5432382732MsoPlainText">>> should</div>
<div class="yiv5432382732MsoPlainText">>> be reflected in the statement of purpose?</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> · What other elements need to be reflected in the statement
</div>
<div class="yiv5432382732MsoPlainText">>> of</div>
<div class="yiv5432382732MsoPlainText">>> purpose?</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> We plan to discuss these questions in next week’s meeting but
</div>
<div class="yiv5432382732MsoPlainText">>> comments would be appreciated on the list before then.</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> Chuck</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> Here’s the EWG statement of purpose that we discussed in our meeting
</div>
<div class="yiv5432382732MsoPlainText">>> earlier this week:</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> To help guide the EWG in its deliberations, the group developed a</div>
<div class="yiv5432382732MsoPlainText">>> high-level statement of purpose from which to test its conclusions
</div>
<div class="yiv5432382732MsoPlainText">>> and</div>
<div class="yiv5432382732MsoPlainText">>> recommendations, as follows:</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> In support of ICANN’s mission to coordinate the global Internet’s
</div>
<div class="yiv5432382732MsoPlainText">>> system</div>
<div class="yiv5432382732MsoPlainText">>> of unique identifiers, and to ensure the stable and secure operation
</div>
<div class="yiv5432382732MsoPlainText">>> of the</div>
<div class="yiv5432382732MsoPlainText">>> Internet’s unique identifier system, information about gTLD domain
</div>
<div class="yiv5432382732MsoPlainText">>> names is</div>
<div class="yiv5432382732MsoPlainText">>> necessary to promote trust and confidence in the Internet for all</div>
<div class="yiv5432382732MsoPlainText">>> stakeholders.</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> Accordingly, it is desirable to design a system to support domain
</div>
<div class="yiv5432382732MsoPlainText">>> name</div>
<div class="yiv5432382732MsoPlainText">>> registration and maintenance which:</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> · Provides appropriate access to accurate, reliable, and
</div>
<div class="yiv5432382732MsoPlainText">>> uniform</div>
<div class="yiv5432382732MsoPlainText">>> registration data</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> · Protects the privacy of personal information</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> · Enables a reliable mechanism for identifying, establishing
</div>
<div class="yiv5432382732MsoPlainText">>> and</div>
<div class="yiv5432382732MsoPlainText">>> maintaining the ability to contact Registrants</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> · Supports a framework to address issues involving
</div>
<div class="yiv5432382732MsoPlainText">>> Registrants,</div>
<div class="yiv5432382732MsoPlainText">>> including but not limited to: consumer protection, investigation of</div>
<div class="yiv5432382732MsoPlainText">>> cybercrime, and intellectual property protection</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> · Provides an infrastructure to address appropriate law</div>
<div class="yiv5432382732MsoPlainText">>> enforcement needs</div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">>> _______________________________________________</div>
<div class="yiv5432382732MsoPlainText">>> gnso-rds-pdp-wg mailing list</div>
<div class="yiv5432382732MsoPlainText">>> <a rel="nofollow" shape="rect" ymailto="mailto:gnso-rds-pdp-wg@icann.org" target="_blank" href="mailto:gnso-rds-pdp-wg@icann.org"><span style="color:windowtext;text-decoration:none;">gnso-rds-pdp-wg@icann.org</span></a></div>
<div class="yiv5432382732MsoPlainText">>> <a rel="nofollow" shape="rect" target="_blank" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">
<span style="color:windowtext;text-decoration:none;">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</span></a></div>
<div class="yiv5432382732MsoPlainText">>> </div>
<div class="yiv5432382732MsoPlainText">> _______________________________________________</div>
<div class="yiv5432382732MsoPlainText">> gnso-rds-pdp-wg mailing list</div>
<div class="yiv5432382732MsoPlainText">> <a rel="nofollow" shape="rect" ymailto="mailto:gnso-rds-pdp-wg@icann.org" target="_blank" href="mailto:gnso-rds-pdp-wg@icann.org"><span style="color:windowtext;text-decoration:none;">gnso-rds-pdp-wg@icann.org</span></a></div>
<div class="yiv5432382732MsoPlainText">> <a rel="nofollow" shape="rect" target="_blank" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg">
<span style="color:windowtext;text-decoration:none;">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</span></a></div>
<div class="yiv5432382732MsoPlainText">_______________________________________________</div>
<div class="yiv5432382732MsoPlainText">gnso-rds-pdp-wg mailing list</div>
<div class="yiv5432382732MsoPlainText"><a rel="nofollow" shape="rect" ymailto="mailto:gnso-rds-pdp-wg@icann.org" target="_blank" href="mailto:gnso-rds-pdp-wg@icann.org"><span style="color:windowtext;text-decoration:none;">gnso-rds-pdp-wg@icann.org</span></a></div>
<div class="yiv5432382732MsoPlainText"><a rel="nofollow" shape="rect" target="_blank" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"><span style="color:windowtext;text-decoration:none;">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</span></a></div>
<div class="yiv5432382732MsoPlainText">_______________________________________________</div>
<div class="yiv5432382732MsoPlainText">gnso-rds-pdp-wg mailing list</div>
<div class="yiv5432382732MsoPlainText"><a rel="nofollow" shape="rect" ymailto="mailto:gnso-rds-pdp-wg@icann.org" target="_blank" href="mailto:gnso-rds-pdp-wg@icann.org"><span style="color:windowtext;text-decoration:none;">gnso-rds-pdp-wg@icann.org</span></a></div>
<div class="yiv5432382732MsoPlainText"><a rel="nofollow" shape="rect" target="_blank" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg"><span style="color:windowtext;text-decoration:none;">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</span></a></div>
</div>
</div></div>
</div></div><br><div class="yqt2245363265" id="yqt27918">_______________________________________________<br clear="none">gnso-rds-pdp-wg mailing list<br clear="none"><a shape="rect" ymailto="mailto:gnso-rds-pdp-wg@icann.org" href="mailto:gnso-rds-pdp-wg@icann.org">gnso-rds-pdp-wg@icann.org</a><br clear="none"><a shape="rect" href="https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg" target="_blank">https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg</a></div><br><br></div> </div> </div> </div></div></body></html>