<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
{mso-style-priority:99;
mso-style-link:"Plain Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.PlainTextChar
{mso-style-name:"Plain Text Char";
mso-style-priority:99;
mso-style-link:"Plain Text";
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle23
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle24
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle25
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle26
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle27
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle28
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle29
{mso-style-type:personal;
color:#1F497D;}
span.EmailStyle32
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:671832720;
mso-list-type:hybrid;
mso-list-template-ids:527468524 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Anne,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks for your e-mails and sorry it has taken a couple of days for me to get back to this and recover enough to respond.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">First, I don’t think we should get hung up on the terminology we used for purposes of the triage exercise. At this point, it does not matter whether something is classified as a new idea or not. What is important is whether the idea has
enough support within the working group to merit further consideration and ultimately whether it would rise to the level of having Consensus support. So I would strongly encourage us to not dwell on the label that was used.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">With respect to the conversation on whether an applicant can elect to copy one application for a TLD (or certain fields from one application) into another application for a second TLD, or whether an applicant can provide one response to
a clarifying question and ask that that response be applied to all of its similarly situated applications, is by no means complete at this point. That said, I am still scratching my head (and this may be just me) to understand (a) what we are trying to prevent
/ protect against, (b) how the solution of not allowing copying of one answer to put into another application would achieve (a) above, and (c) why is this a concern for us.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">What I heard during the discussion (and correct me if I am wrong) was that we wanted to make sure that at least with respect to the description of the mission / purpose or each TLD, there was a concern that by having an option to copy another
application, we were encouraging applicants to not differentiate their TLD applications. So perhaps the argument for (a) above is that we are trying to prevent an applicant from submitting identical applications (albeit for separate strings). But where I
get confused is that the solution of not having an option for the system to copy an answer, we are
<i>not preventing copying from going on.</i> All we are doing is making applicants do this manually (which we cannot prevent)?
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">And I am also trying to understand the (c), <u>why are we concerned</u>. The BC stated in their comments that they thought copying from one response to another “<span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white">can
result in unknown mistakes and may increase chances of errors in the application.” My confusion is that if we force applicants to “copy” answers manually where identical answers make sense, then that could increase the chances for mistakes over having the
system do this in an automated fashion. And I still don’t understand why we should be concerned if there are similar answers. Leaving out Question 18 (mission/purpose) for the moment, why do we care if the following sections of each application are identical
except for having different strings:<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white"><o:p> </o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white">Applicant Information (Name, Address, Phone Number, Fax, E-mail, Website, etc.)<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white">Primary Contact for the application (Name, DOB, contact information, etc.)<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white">Proof of Legal Establishment<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white">Applicant Background (Directors, Officers, Major Shareholders, Criminal & Cybersquatting History, etc.)<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white">Registry Services (Question 23)<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white">Technical and Operational Capabilities (Question 24 - 29)<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white">Security (Question 30)<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white">Technical Architecture, Database Capabilities, diversity of hardware, software, suppliers, etc.<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white">DNS Services, Data Escrow, Registry Continuity, Failover Testing, Escalation Processes, DNSSEC<o:p></o:p></span></li><li class="MsoListParagraph" style="margin-left:0in;mso-list:l0 level1 lfo1"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white">Financial Information, Statements, etc.
<o:p></o:p></span></li></ul>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white">Even if the mission/purpose of each TLD is different, the reality is that all of the above information is most likely going to be identical. So, either they
will copy each of the answers manually (which is more prone to mistakes) or there can be an automated option to allow the automatic population of these fields which could actually reduce mistakes.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:"Arial",sans-serif;background:white">As Chair, for the record, this concept was supported by the Work Track that made this recommendation without any dissent prior to the Initial Report. As far
as the comments we got back, ICANN agreed with the recommendation, but expressed concern as to the complexity of implementing this. The only comment that disagreed was from the BC. Neustar, Lemarit, Fairwinds and the BRG supported the recommendation.<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This e-mail does not represent any form of decision or guidance by the Co-Chairs of the SubPro PDP, but is merely intended to provide some of my outstanding questions on the concerns. Thanks.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><b><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Jeff Neuman</span></b><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Senior Vice President <o:p></o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><b><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Com Laude | Valideus<br>
</span></b><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">1751 Pinnacle Drive
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Suite 600, McLean<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">VA 22102, USA<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"><br>
M: +1.202.549.5079<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">D: +1.703.635.7514<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">E:
</span><u><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#0563C1">jeff.neuman@comlaude.com</span></u><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"><br>
<a href="http://www.comlaude.com/"><span style="color:#0563C1">www.comlaude.com</span></a></span><u><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#0563C1"><o:p></o:p></span></u></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"><br>
Liability cannot be accepted for statements made which are clearly the sender’s own and not made on behalf of Com Laude USA or Valideus USA. This message is intended solely for the addressee and may contain confidential information. If you have received this
message in error, please send it back to us, and immediately and permanently delete it. Do not use, copy or disclose the information contained in this message or in any attachment.Com Laude USA and Valideus are trading names of Consonum, Inc.</span><u><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#0563C1"><o:p></o:p></span></u></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org>
<b>On Behalf Of </b>Aikman-Scalese, Anne<br>
<b>Sent:</b> Wednesday, March 13, 2019 4:47 PM<br>
<b>To:</b> Julie Hedlund <julie.hedlund@icann.org>; gnso-newgtld-wg@icann.org<br>
<b>Subject:</b> Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 13 March 2019<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks Julie. To Jeff and Cheryl, I don’t think the concerns raised by Kathy, Justine, and me in the Sub Pro call #3 about “rote duplicative answers” as to Question 18 constitute a “new idea”. These were rather
concerns expressed about moving forward with a policy recommendation to change the existing policy in the 2012 AGB. Requiring individual answers in Question 18 is not a “new idea”. It’s existing policy which should not be changed unless there is a strong
consensus in the WG in favor of doing so. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Based on what I have gleaned from our structure so far, it appears that Leadership could take the position that a “new idea” may only be recommended if it has unanimous or very strong support. (This doesn’t
mean the WG won’t reach Consensus as to repetitive information being filed in numerous applications at the same time in categories other than mission and purpose.) But the fact that this idea received support in public comment should not override concerns
of Working Group members relative to transparency and encouraging practices which facilitate public comment. So, in fact, rather than being a “new idea’, what you have is a lack of strong Consensus in the WG about this recommendation for the auto-fill capability
as it relates to questions dealing with mission and purpose. Again, that is NOT a policy change or a “new idea.”<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">This will come up again in relation to the disclosure of services at the time of application filing. So it would be good if Leadership could clarify EXACTLY how it intends to treat items that are characterized
as a “New Idea.” Call me crazy but I think everyone is still a bit confused as to the “disposition” going forward in relation to “new ideas”.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Thanks again for your willingness to bring this PDP “home”. It’s not an easy job and we really do appreciate Cheryl’s comment that “they said it couldn’t be done” but the work is getting done. My only point
is that characterizing something as a “new idea” in relation to the questions that were put out in the Initial Report should not be used as a way to cast aside an obvious lack of Consensus in the WG on a given recommendation. The WG will have to be careful
about this all the way through its deliberations in the coming months.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Safe return travels to all. I could not make it to Kobe but am planning to be in Marrakech and Montreal.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D">Anne<o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Gnso-newgtld-wg [<a href="mailto:gnso-newgtld-wg-bounces@icann.org">mailto:gnso-newgtld-wg-bounces@icann.org</a>]
<b>On Behalf Of </b>Julie Hedlund<br>
<b>Sent:</b> Wednesday, March 13, 2019 1:19 AM<br>
<b>To:</b> <a href="mailto:gnso-newgtld-wg@icann.org">gnso-newgtld-wg@icann.org</a><br>
<b>Subject:</b> [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 13 March 2019<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal"><strong><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:black">[EXTERNAL]</span></strong><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif;color:black"><o:p></o:p></span></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:12.0pt;font-family:"Times New Roman",serif">
<hr size="2" width="100%" align="center">
</span></div>
</div>
<p class="MsoPlainText">Dear Working Group members,<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Please see below the notes from the meetings at ICANN64 in Kobe on 13 March 2019. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript,
or the chat, which will be posted at: <a href="https://community.icann.org/display/NGSPP/2019-03-13+ICANN64+Kobe+-+New+gTLD+Subsequent+Procedures+PDP">
https://community.icann.org/display/NGSPP/2019-03-13+ICANN64+Kobe+-+New+gTLD+Subsequent+Procedures+PDP</a>.<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Please also see the attached referenced slides.<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText">Kind regards,<o:p></o:p></p>
<p class="MsoPlainText">Julie<o:p></o:p></p>
<p class="MsoPlainText">Julie Hedlund, Policy Director<o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoPlainText"><b>Notes and Action Items:</b><o:p></o:p></p>
<p class="MsoPlainText"> <o:p></o:p></p>
<p class="MsoNormal"><b>Session 3 of 3:<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>Topics that Might Warrant Closure</u>:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-- Show how we have assembled the topic review.<o:p></o:p></p>
<p class="MsoNormal">-- How to bring this to closure.<o:p></o:p></p>
<p class="MsoNormal">-- Next steps.<o:p></o:p></p>
<p class="MsoNormal">-- Still are some potential open topics that might need to go to the Implementation Review Team or do more work.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">See the Public Comment Tool: <a href="https://docs.google.com/spreadsheets/d/15zDdzlBwLCz5m2sNXui6N6pporbUq-lDFEwfh4rKi4A/edit#gid=1093601017">
https://docs.google.com/spreadsheets/d/15zDdzlBwLCz5m2sNXui6N6pporbUq-lDFEwfh4rKi4A/edit#gid=1093601017</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>1. Applicant Guidebook – Slide 20</u>:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-- Information on the slide is conceptual, not recommendation language.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>2. Systems – Slides 21-22</u>:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-- Question: Which of the recommendations are implementation guidance and which are policy? The first bullet (adequate time) would be more specific than policy; second bullet suggests implementation guidance. Also, change to “real-time
technical support” (delete “better”).<o:p></o:p></p>
<p class="MsoNormal">-- Both bullet points seem to be implementation guidance.<o:p></o:p></p>
<p class="MsoNormal">-- Prioritization would be key (such as identifying field requiring non-ASCII characters).<o:p></o:p></p>
<p class="MsoNormal">Christopher Wilkinson: <COMMENT>Ihave a general reservation abiout language which woud facilitate multiople applications from a single applicant. Particularly with regard to Geographical Names<COMMENT><o:p></o:p></p>
<p class="MsoNormal">Christopher Wilkinson: <COMMENT> permitting portfolio applications will result in further concentration, more warehousing and speculation and threaten the interests of international communities <COMMENT><o:p></o:p></p>
<p class="MsoNormal">-- Creating multiple identical applications doesn’t seem to serve the Applicant Guidebook Process. Comment from Business Constituency was to be able to respond to multiple applications with the same question. That this answer applies
to multiple applications.<o:p></o:p></p>
<p class="MsoNormal">-- Sections in some applications may be pretty much the same, so the ability to copy text over would be beneficial.<o:p></o:p></p>
<p class="MsoNormal">-- Should encourage clarity of what is expected in the answers. Would be helpful to know in advance what is expected of applicants.<o:p></o:p></p>
<p class="MsoNormal">Anne Aikman-Scalese (IPC): COMMENT: Answers to Question 18 should not be rote fill-in identical answers. COMMENT<o:p></o:p></p>
<p class="MsoNormal">Anne Aikman-Scalese (IPC): COMMENT: +1 to Justine 's request and to Kathy's observation re Question 18. We don't want to encourage super general language that is made more vague so that it can be applied automatically in numerous applications.
COMMENT<o:p></o:p></p>
<p class="MsoNormal">-- Should allow copy and pasting the same answer to purpose and mission, but how can we prevent that? Could do so by setting expectations.<o:p></o:p></p>
<p class="MsoNormal">-- The discussion was around efficiency and ease of use for applicants. We didn’t consider what to allow for which questions.<o:p></o:p></p>
<p class="MsoNormal">Christopher Wilkinson: <COMMENT> boilerplate replies from multiople applications will facilitate gaming to avoid substantive comments from other stakeholders and interested parties<COMMENT><o:p></o:p></p>
<p class="MsoNormal">Anne Aikman-Scalese (IPC): COMMENT: Re public comment on applications, cookie cutter answers are contrary to the principle of transparency. Applicants might easily construct such answers for the purpose of avoiding public comment. Justine's
request is important. COMMENT<o:p></o:p></p>
<p class="MsoNormal">-- The more complex we make the system the more costly it will be and difficult to use.<o:p></o:p></p>
<p class="MsoNormal">Anne Aikman-Scalese (IPC): COMMENT: It's demeaning to the comments to say they are "in the weeds" and they are not "high level". it just means you oppose them. COMMENT<o:p></o:p></p>
<p class="MsoNormal">-- To address the issue you’d have to have a policy recommendation that you can’t submit the exact same information across applications or within applications.<o:p></o:p></p>
<p class="MsoNormal">-- What is the problem we are trying to solve, at a high level? If you can cut and paste you will do it, but don’t know if that will avoid the issues being raised.<o:p></o:p></p>
<p class="MsoNormal">-- Seems that the problem is the pace the submission outpacing the ability of the community to review the volume of applications received.<o:p></o:p></p>
<p class="MsoNormal">-- New Idea: Maybe prohibit duplicative language if you are a portfolio applicant.<o:p></o:p></p>
<p class="MsoNormal">Anne Aikman-Scalese (IPC): COMMENT: It is not about solving a problem, it is about creating a new problem by making this recommendation. Jeff's suggestion to use languge that excepts the practice in relation to questions that go to Mission
and Purpose. That is not a policy change. COMMENT<o:p></o:p></p>
<p class="MsoNormal">Christopher Wilkinson: <COMMENT> one of the objectives of having several specialised rounds or batches is precisely to limit the volumes of applications to the capacity of the evaluation resources, over time <COMMENT><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>3. Communications – Slides 23-24</u>:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-- Bullet 1: Minimum of 4 months – shouldn’t be summarized; there was a variety of comments.<o:p></o:p></p>
<p class="MsoNormal">-- Bullet 2: Know what is in the GSE toolbox.<o:p></o:p></p>
<p class="MsoNormal">-- For the two bullets – not a lot of mention of studying of objectives and holes for applications; what are we looking to achieve by communications and outreach. Would be good to measure.<o:p></o:p></p>
<p class="MsoNormal">-- When we were talking about applicant support there were comments on how to measure success in future.<o:p></o:p></p>
<p class="MsoNormal">-- Communications is different from applicant support, but we need to look at both.<o:p></o:p></p>
<p class="MsoNormal">-- Open topics: The WG could do it, give it to an IRT, or recommend that ICANN Org do it.<o:p></o:p></p>
<p class="MsoNormal">Christopher Wilkinson: <COMMENT> communications periods will be critical for geographical names because very few of local stakeholders world wide have been participating in Wt5 etc. <COMMENT><o:p></o:p></p>
<p class="MsoNormal">Anne Aikman-Scalese (IPC): QUESTION Was there something in the public comments related to making real-time chat available for applicants? QUESTION<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>4. Universal Acceptance – Slide 25</u>:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-- UASG has been successful in promoting UA – getting several major email providers to be UA ready. The question is whether the Registries/Registrars are using those email services.<o:p></o:p></p>
<p class="MsoNormal">-- Might be too much to ask to expect Registries/Registrars to do what the major email providers do.<o:p></o:p></p>
<p class="MsoNormal">-- This sounds like more of an issue with all TLDs – why would we just put it in as a condition of a new TLD if it isn’t a condition for legacy TLDs?<o:p></o:p></p>
<p class="MsoNormal">-- ALAC – suggesting UA if the Registry/Registrar are owned by the same entity.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>5. Application Submission Periods – Slides 26-27</u>: Start on the next WG call.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Anne Aikman-Scalese (IPC): COMMENT: Re Topic 5, how do we take into account the Neustar proposal re windows within an application period? That should be captured. COMMENT<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="4" width="100%" align="center">
</div>
<p class="MsoNormal"><span style="font-size:7.5pt;font-family:"Arial",sans-serif;color:gray"><br>
This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message
or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying
to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.
</span><o:p></o:p></p>
</div>
</body>
</html>