<html 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)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"MS Gothic";
panose-1:2 11 6 9 7 2 5 8 2 4;}
@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;}
@font-face
{font-family:"\@MS Gothic";
panose-1:2 11 6 9 7 2 5 8 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:#0563C1;
text-decoration:underline;}
span.EmailStyle19
{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;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:12.0pt">Dear Working Group members,</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Please see below the notes from the meeting on 11 June at 2000 UTC.
<b><i>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,</i></b> which will be posted at:
<a href="https://community.icann.org/display/NGSPP/2020-06-11+New+gTLD+Subsequent+Procedures+PDP">
https://community.icann.org/display/NGSPP/2020-06-11+New+gTLD+Subsequent+Procedures+PDP</a>.</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Kind regards,<br>
Julie</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><b><span style="font-size:12.0pt">Notes and Action Items:</span></b><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
<p class="MsoNormal"><b>Actions:</b><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>Applicant Support (multipliers at auction):<o:p></o:p></u></p>
<p class="MsoNormal">ACTION ITEM: In the Implementation Guidance add language about researching a cap.<o:p></o:p></p>
<p class="MsoNormal">ACTION ITEM: Change to “However, assignments that become necessary because of changing of ownership due to death or retirement, etc., assignments to subsidiaries, etc., shall be permitted.” Delete the word “legitimate from the preceding
sentence. Check the chat for other examples from Paul McGrady.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>2.3 Role of Application Comment<o:p></o:p></u></p>
<p class="MsoNormal">b. Deliberations and rationale for recommendations and/or implementation guidelines<o:p></o:p></p>
<p class="MsoNormal">Rationale for Recommendation xx and Implementation Guidance xx (rationale 5):<o:p></o:p></p>
<p class="MsoNormal">ACTION ITEM: WG members should review section 2.4.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>General comment -- spell out acronyms when first used.<o:p></o:p></u></p>
<p class="MsoNormal">ACTION ITEM: Spell out acronyms when first used in a section.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>2.7.4 String Similarity Evaluation<o:p></o:p></u></p>
<p class="MsoNormal">Recommendation xx (rationale 2):<o:p></o:p></p>
<p class="MsoNormal">ACTION ITEM: Add implementation guidance that states that in the event intended use is unclear from the application to determine whether one string is a singular/plural of the other, ICANN should ask the applicant a clarifying question
to ascertain the intended use of such string.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>2.7.5 Internationalized Domain Names<o:p></o:p></u></p>
<p class="MsoNormal">Recommendation xx (Rationale 4):<o:p></o:p></p>
<p class="MsoNormal">ACTION ITEM: Add text that clarifies that the PDP WG is not addressing the process for applying or being granted an IDN TLD variant. Suggestion: “This working group has not discussed the process by which an existing registry operator could
apply for, or be given, an IDN variant of an existing TLD. Nor has it discussed who one would include in its application for a new gTLD its desire for an IDN Variant.”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>Notes:</b><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">1. Updates to Statements of Interest: No updates provided.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2. Applicant Support (multipliers at auction) page 6 in 2.1 Auctions: Mechanisms of Last Resort & 2.2 Private Resolution of Contention Sets (Including Private Auction):
<a href="https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing">
https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing</a> <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Proposed Language - Bid Credit/Multiplier for Applicant Support Recipients at Auction<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Implementation Guidance:<o:p></o:p></p>
<p class="MsoNormal">“All assignments after such time shall be governed under the then-current Registry Agreement standard provisions; provided that any Assignment or Change of Control after the third year, but prior to the seventh (7th) year, shall require
the applicant to repay the full amount of financial support received through the ASP Program plus an additional ten percent (10%).”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>Discussion</u>:<o:p></o:p></p>
<p class="MsoNormal">-- Another option: “To disincentivize “gaming” of the applicant support program by applicants who are applying on behalf of third parties, or with the intent to immediately transfer ownership to third parties, applicants who receive financial
support through the ASP Program will not be permitted to assign the relevant Registry Agreement within the first five (5) years of execution of the Registry Agreement unless they repay the repay the full amount of financial support received through the ASP
Program plus an additional ten percent (10%).<span style="font-family:"MS Gothic"">
</span>”<o:p></o:p></p>
<p class="MsoNormal">-- Suggest 3 years from the signing of the contract.<o:p></o:p></p>
<p class="MsoNormal">-- Need to make sure an ASP candidate can manage the finances and security.<o:p></o:p></p>
<p class="MsoNormal">-- Need to give some thought to the string. An ASP applicant might want to go with a generic string, especially if they wanted to raise money for their community.<o:p></o:p></p>
<p class="MsoNormal">-- Talked about this before in 2016 in Work Track 1 -- didn’t want to limit what an applicant could or couldn’t apply for. <o:p></o:p></p>
<p class="MsoNormal">-- Put into the context of other provisions, such as if an applicant is a community applicant and qualifies (CPE), then auctions won’t apply.<o:p></o:p></p>
<p class="MsoNormal">-- If they are one of many applicants then we are trying to even the playing field (or if they don’t qualify as community).<o:p></o:p></p>
<p class="MsoNormal">-- This is similar to spectrum auctions in the US and Brazil.<o:p></o:p></p>
<p class="MsoNormal">-- If we have two successful community applicants for the same string we haven’t come up with anything other than auctions to address it.<o:p></o:p></p>
<p class="MsoNormal">-- The funding for the ASP is limited, so maybe there is a ceiling or payback option.<o:p></o:p></p>
<p class="MsoNormal">-- If the bid credit is 25% then the applicant is only on the hook for 75%, but money is not being paid out.<o:p></o:p></p>
<p class="MsoNormal">-- A credit won’t work with a third party auctioneer -- the administrative fees -- but this would be limited to an ICANN auction.<o:p></o:p></p>
<p class="MsoNormal">-- In the public comments there was no support for giving priority to an applicant who gets applicant support.<o:p></o:p></p>
<p class="MsoNormal">-- Mechanism could just be a discount off of the price -- but we are saying that research should be done on the mechanism. We don’t have enough knowledge to determine the mechanism or cap. We could add language about researching a cap.<o:p></o:p></p>
<p class="MsoNormal">-- Could add something about being consistent with similar processes.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Re: “However, legitimate assignments (e.g., changing of ownership due to death or retirement, etc., assignments to subsidiaries, etc.) shall be permitted.”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-- Non-profits also have requirements that might involve legitimate assignments.<o:p></o:p></p>
<p class="MsoNormal">-- Let the Implementation Review Team focus on the legal language.<o:p></o:p></p>
<p class="MsoNormal">-- Mergers, name changes, entity restructuring,... the normal changes of an organization or company.<span style="font-family:"MS Gothic"">
</span><o:p></o:p></p>
<p class="MsoNormal">-- The word “legitimate” doesn’t seem to be the right term.<o:p></o:p></p>
<p class="MsoNormal">-- Not sure how the result of a recommendation coming out of an IRT on this could be anything other than policy. Not sure how this could be figured in a predictability framework, but the IRT needs to be able to develop this formula.<o:p></o:p></p>
<p class="MsoNormal">-- On the wording, what if it is changed to “assignments that become necessary due to death or retirement, the EBERO process, etc.” Another possibility could be lack of resources, or going out of business. Make sure it’s not different
from what would happen in EBERO.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: In the Implementation Guidance add language about researching a cap.</b><o:p></o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: Change to “However, assignments that become necessary because of changing of ownership due to death or retirement, etc., assignments to subsidiaries, etc., shall be permitted.” Delete the word “legitimate from the preceding
sentence. Check the chat for other examples from Paul McGrady.</b><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">3. Review "Can't Live With" comments on package 4: <a href="https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQLuQuo/edit?usp=sharing">
https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQLuQuo/edit?usp=sharing</a>:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2.3 Role of Application Comment<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">b. Deliberations and rationale for recommendations and/or implementation guidelines<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><u>Rationale for Recommendation xx and Implementation Guidance xx (rationale 5)</u>:<o:p></o:p></p>
<p class="MsoNormal">The Working Group notes that if an applicant proposes changes to the application in response to public comments, additional processes apply, including an additional public comment period, where applicable. Please see section xx Application
Change Requests for discussion of processes related to changes in the application [, with notification to the extent possible of those who made the requests for proposed changes].<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-- KK4.1 - Kathy Kleiman suggested adding an additional clause to this sentence. Rationale: "We have asked for ICANN to collect information about the commenters, including email, so it should be relatively easy to notify commenters that,
in response to public comment, a proposed change has been made (and fair too). Letting those providing the original comments know that a directly-related change has been proposed to the application and a public comment period has opened seems an easy follow-on
to continue the discussion and foster review the proposed change."<o:p></o:p></p>
<p class="MsoNormal">-- Staff note: The following is included under section 2.4 Application Change Requests: Implementation Guidance xx (rationale 2): Community members should have the option of being notified if an applicant submits an application change request
that requires a public comment period to be opened at the commencement of that public comment period.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: WG members should review section 2.4.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">General comment -- spell out acronyms when first used.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: Spell out acronyms when first used in a section.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2.7.4 String Similarity Evaluation<o:p></o:p></p>
<p class="MsoNormal"><u>Recommendation xx (rationale 2)</u>:<o:p></o:p></p>
<p class="MsoNormal">Applications will not automatically be placed in the same contention set because they appear visually to be a single and plural of one another but have different intended uses. For example, .SPRING and .SPRINGS could both be allowed if
one refers to the season and the other refers to elastic objects, because they are not singular and plural versions of the same word. However, if both are intended to be used in connection with the elastic object, then they will be placed into the same contention
set. Similarly, if an existing TLD .SPRING is used in connection with the season and a new application for .SPRINGS is intended to be used in connection with elastic objects, the new application will not be automatically disqualified.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">KK4.4 - Kathy Kleiman submitted a question: "What if they are both open gTLDs without specific use specified; or one is specific use, e.g., elastics, and one is open?"<o:p></o:p></p>
<p class="MsoNormal">-- What if we add implementation guidance that states that in the event intended use is unclear from the application to determine whether one string is a singular/plural of the other, ICANN should ask the applicant a clarifying question
to ascertain the intended use of such string?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: Add implementation guidance that states that in the event intended use is unclear from the application to determine whether one string is a singular/plural of the other, ICANN should ask the applicant a clarifying question
to ascertain the intended use of such string.<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">2.7.5 Internationalized Domain Names<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Original Text:<o:p></o:p></p>
<p class="MsoNormal">Recommendation xx (Rationale 4): IDN gTLDs identified as variants of already existing or applied for TLDs will be allowed provided they have the same registry operator and back-end registry service provider. This policy of cross-variant
TLD bundling must be captured in relevant Registry Agreements.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Text suggested by Justine:<o:p></o:p></p>
<p class="MsoNormal">[Recommendation xx (Rationale 4): IDN gTLDs deemed to be variants of already existing or applied for TLDs will not be allowed for separate application and allowed for activation by the same registry operator and back-end registry service
provider. This policy of cross-variant TLD bundling must be captured in relevant Registry Agreements.]<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">AAS4.4 - Anne Aikman Scalese: "Clarifying Question: Do we mean here that in the next round, no one can apply for “.casino” in Cyrillic script or .bible” in Hebrew script and that any TLD that exists now in the root bars all applications
by a third parties for the spelling/translation of that string in a different script? In other words, that only the original applicant may activate the equivalent idn?"<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">JC4.1 - Justine Chew proposed editing the text of this recommendation. Rationale: "The explanation provided by the At-Large IDN WG is as follows, The wording of this recommendation seems to expect that an IDN Variant TLD go through the
same "application process“ when in fact any IDN Variant TLD should only be "activated" not "applied for" by the same Registry Operator. This is consistent with how the 2012 round was envisioned and handled. Allowing IDN Variant TLDs to be "applied for" is
problematic for the concept of IDN Variants."<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-- This is a tough one. We never discussed doing anything but having the same application process. We would have to create a whole separate process then to apply for the Variant TLD.<o:p></o:p></p>
<p class="MsoNormal">-- Could say that the WG acknowledges that the process for getting an IDN TLD may not be going through the normal process, but the IRT should investigate this issue.<o:p></o:p></p>
<p class="MsoNormal">-- See: <a href="https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-analysis-25jan19-en.pdf">
https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-analysis-25jan19-en.pdf</a>, which was referenced in developing this section.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Alternative suggested language from Justine:<o:p></o:p></p>
<p class="MsoNormal">“"IDN gTLDs deemed to be variants of already existing or applied for TLDs will only be allowed to the same registry operator and back-end registry service provider. This policy of cross-variant TLD bundling must be captured in relevant
Registry Agreements."<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-- This implies that if you already have one variant you can just ask for the other variant.<o:p></o:p></p>
<p class="MsoNormal">-- Not sure how this is different from the old language.<o:p></o:p></p>
<p class="MsoNormal">-- It shouldn’t have to go through the application process, it should just be a request.<o:p></o:p></p>
<p class="MsoNormal">-- We need to say that there is future work on this and we are not addressing the process for applying or being granted an IDN TLD variant.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>ACTION ITEM: Add text that clarifies that the PDP WG is not addressing the process for applying or being granted an IDN TLD variant. Suggestion: “This working group has not discussed the process by which an existing registry operator
could apply for, or be given, an IDN variant of an existing TLD. Nor has it discussed who one would include in its application for a new gTLD its desire for an IDN Variant.”</b><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>