- Gnso-newgtld-wg - lists.icann.org

Reminder: Deadline today, 16 June - Comments on Revised Draft Recommendations - Package 5
by Emily Barabas June 17, 2020

June 17, 2020

Dear all, As a reminder, today is the deadline to submit comments on package 5 revisions (details below). Kind regards, Emily From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Steve Chan <steve.chan(a)icann.org> Date: Saturday, 6 June 2020 at 02:03 To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] Deadline 16 June - Comments on Revised Draft Recommendations - Package 5 Dear all, The leadership team is releasing the fifth set of revised draft recommendations for your review. 1. There are 9 topics in package 5 here, beginning on page 74: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…>. Note that the Geographic Names report from Work Track 5 is provided separately, below. · 2.2.7 Metrics and Monitoring (This topic is intended to serve as an aggregation point for the metrics based recommendations from the various topics. Deliberations occurred in the context of the directly related topic.) · 2.5.4 Applicant Support (last discussed 26 Mar<https://community.icann.org/x/ZiOJBw>) · 2.4 Application Change Requests (last discussed 14 Apr<https://community.icann.org/x/nC2JBw>) · 2.7.1 Reserved Names (last discussed 23 Apr<https://community.icann.org/x/py2JBw>) · 2.8.1 Objections: GAC Early Warning and GAC Advice (last discussed 7 May<https://community.icann.org/x/u4PsBw>) · 2.8.2 Limited Challenge/Appeal Mechanism (formerly Accountability Mechanisms) (last discussed 20 Apr<https://community.icann.org/x/oy2JBw>). Note, an Annex is referenced in this section which will eventually mean the spreadsheet the WG developed here<https://docs.google.com/spreadsheets/d/1R4eU7C-HI5ikF5RtVhp5JRXKVVRn6R8WX8f…>. · 2.8.2 Post-Delegation Dispute Resolution Procedures (formerly Accountability Mechanisms) (last discussed 23 Apr<https://community.icann.org/x/py2JBw>) · 2.10.1 Base Registry Agreement (last discussed 9 Apr<https://community.icann.org/x/mS2JBw>) · 2.7.1.2 Geographic Names (last discussed by the full WG at ICANN66 in Montreal on 2 Nov 2019<https://community.icann.org/x/Ao7kBg>). The WT5 report is available here<https://community.icann.org/download/attachments/60490848/Work%20Track%205%…>, unchanged from when it was delivered to the full WG on 22 October 2019. 1. Please limit comments to items in the revised sections that you absolutely “cannot live with.” If there is text that you cannot accept, please fill out the attached form and send it to the WG by email. Please do not provide your input in any other format. 1. Because of the size of this particular package, the deadline for comments is Tuesday 16 June at 23:59 UTC 1. Comments will be tracked here: https://community.icann.org/x/JDKJBw. Best, Steve Steven Chan  Policy Director, GNSO Support Internet Corporation for Assigned Names and Numbers (ICANN) 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536  Email: steve.chan(a)icann.org<mailto:steve.chan@icann.org> Skype: steve.chan55 Mobile: +1.310.339.4410 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

3 2

Re: [Gnso-newgtld-wg] FW: IDN Variant - Activation or Application?
by Steve Chan June 16, 2020

June 16, 2020

Dear Anne, all, It may be helpful to review the entire set of documentation for IDN variant TLD management here: https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-0… Document three (https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations…) on this page provides the recommendations and analysis. To your question, I think sections 3.3 and 3.3.1 are most applicable. Section 3.3 references several RFCs and SAC060 to note that a conservative approach should be taken in allocating IDN variant TLDs; just because an IDN variant can be allocated does not mean that it should be allocated. Section 3.3.1 mentions that the study recommends that the application process and fee apply to variant labels, similar to any gTLD label, which is consistent and furthers the principle of conservative allocation of variants. To summarize and in response to your questions, based on my reading, the paper says IDN variants would be available for application (not simply activation) and only to the same entity. Best, Steve From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Date: Thursday, June 11, 2020 at 2:14 PM To: Jeff Neuman <jeff.neuman(a)comlaude.com> Cc: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] FW: IDN Variant - Activation or Application? Jeff, Does this ICANN document say the idn variant is available via Application? Or Activation? By the holder of the original idn TLD? Anne https://www.icann.org/en/system/files/files/idn-variant-tld-rationale-lgr-2… 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.

2 1

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 16 June 0300 UTC
by Julie Hedlund June 16, 2020

June 16, 2020

Dear Working Group members, Please see below the notes from the meeting on 16 June at 0300 UTC. 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: https://community.icann.org/display/NGSPP/2020-06-16+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: Package 3: 2.3.3 Applicant Freedom of Expression a. Recommendations and/or implementation guidelines Implementation Guidance xx: As the ICANN organization and community incorporate human rights into ICANN’s processes in line with the recommendations of CCWG-Accountability Work Stream 2, they may want to [should] consider the application of this work to elements of the New gTLD Program. ACTION ITEM: The WG agrees to change “they may want to” to “they should”, per the standard language for implementation guidance. Package 4: 2.7.5 Internationalized Domain Names a. Recommendations and/or implementation guidelines Recommendation xx (Rationale 4): ACTION ITEM: Accept the suggested edits in Recommendation xx (Rationale 4). ACTION ITEM: Investigate definition of variant and add as footnote. Added citation directing to IDN Variant TLD Implementation: Motivation, Premises and Framework, which discusses the definition and provides examples. Rationale for Recommendation xx (rationale 4): ACTION ITEM: Delete “owned and” before “operated” and add “if delegated” after “service provider”. 2.7.7 Applicant Reviews: Technical/Operational, Financial and Registry Services Registry Services Recommendation xx (rationale 11): ACTION ITEM: The WG agrees to add “base” before “Registry Agreement”. 2.7.8 Name Collisions a. Recommendations and/or implementation guidelines Implementation Guidance xx (Rationale 4): ACTION ITEM: Move the additional language to the rationale section. ACTION ITEM: Replace the previous text with the next text suggested: Implementation Guidance xx (Rationale 4): The ICANN community should develop name collision risk criteria and a test to provide information to an applicant for any given string after the application window closes so that the applicant can determine if they should move forward with evaluation. Implementation Guidance (Rationale 5) ACTION ITEM: Add text in brackets and delete text in strike out: ICANN should also seek to identify aggravated risk strings [in advance of the next application window opening and whether it would], which would be expected to require a specific name collision mitigation framework. However, all applied-for strings should be subject to a DNS Stability evaluation to determine whether they represent a high, aggravated, or low risk of name collision. ACTION ITEM: Move the text on the DNS Stability Evaluation into a separate Implementation Guidance. Rationale for Affirmation xx (Rationale 3): ACTION ITEM: The WG agreed to include the additional text, but not the text that begins “the working group has been advised Co-Chairs of the NCAP...” Also, the WG agreed to delete the associated footnote. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review “Can’t Live With” comments on package 3 – additional comment from Anne Aikman-Scalese on page 38. See the Production document at: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL…. 2.3.3 Applicant Freedom of Expression a. Recommendations and/or implementation guidelines Implementation Guidance xx: As the ICANN organization and community incorporate human rights into ICANN’s processes in line with the recommendations of CCWG-Accountability Work Stream 2, they may want to [should] consider the application of this work to elements of the New gTLD Program. ACTION ITEM: The WG agrees to change “they may want to” to “they should”, per the standard language for implementation guidance. 3. Review “Can’t Live With” comments on package 4, start on page 57: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… 2.7.5 Internationalized Domain Names a. Recommendations and/or implementation guidelines Recommendation xx (Rationale 4): Discussion: -- Decided on the last call not to accept the alternate language. -- There is work that will be initiated by the GNSO Council on this, as we point out in the rationale. -- Need to be identified as “IDN” variants specifically, and “IDN gTLDs”; replace “allowed provided they” with “only if they”. -- With respect to translations – it’s possible for a variant to be a translation, but not all translations are variants. -- We are specifically calling out the variant, as opposed to the translation. Can we give the IRT more information? Look at Recommendation xx (Rationale 2): “Recommendation xx (rationale 2): Compliance with Root Zone Label Generation Rules (RZ-LGR) must be required for the generation of IDN TLDs and variants labels, including the determination of whether the label is blocked or allocatable.” -- People are confused by what is a variant and what is a translation. Can we put in examples? -- Need to keep it as simple and as accurate as possible. ACTION ITEM: Accept the suggested edits in Recommendation xx (Rationale 4). ACTION ITEM: Investigate definition of variant and add as footnote. Added citation directing to IDN Variant TLD Implementation: Motivation, Premises and Framework, which discusses the definition and provides examples. Rationale for Recommendation xx (rationale 4): ACTION ITEM: Delete “owned and” before “operated” and add “if delegated” after “service provider”. 2.7.7 Applicant Reviews: Technical/Operational, Financial and Registry Services Registry Services Recommendation xx (rationale 11): -- Suggestion from Rubens to add “base” before “Registry Agreement”. ACTION ITEM: The WG agrees to add “base” before “Registry Agreement”. 2.7.8 Name Collisions a. Recommendations and/or implementation guidelines Implementation Guidance xx (Rationale 4): Discussion: -- Additional suggested language seems more appropriate for the rationale section. -- No need to mention Jeff Neuman, we can say that there are some participants that are some working group members that are participants in the NCAP. We don't even need to say that weekly conference calls or anything but just to say that there's an NCAP group, which I think we mentioned in the rationale. -- There also is suggested alternative text for the Implementation Guidance (Rationale 4). This was suggested by Jim Prendergast to align with what Jim Galvin told us on the 30 April call. ACTION ITEM: Move the additional language to the rationale section. ACTION ITEM: Replace the previous text with the next text suggested: Implementation Guidance xx (Rationale 4): The ICANN community should develop name collision risk criteria and a test to provide information to an applicant for any given string after the application window closes so that the applicant can determine if they should move forward with evaluation. Implementation Guidance (Rationale 5) Discussion: -- The additional language with the reference to dependencies is more appropriate to be included in the rationale section. -- Include text that the identification of risk strings should happen in advance of the next application window opening, but don’t include that it should be published in the Applicant Guidebook. -- Limiting to say that it must be published in the AGB. -- But we want to give as much information in advance. -- This is going out for public comment. We don’t want to be too prescriptive at this point. -- Put the text on the DNS Stability Evaluation as a separate Implementation Guidance. ACTION ITEM: Add text in brackets and delete text in strike out: ICANN should also seek to identify aggravated risk strings [in advance of the next application window opening and whether it would], which would be expected to require a specific name collision mitigation framework. However, all applied-for strings should be subject to a DNS Stability evaluation to determine whether they represent a high, aggravated, or low risk of name collision. ACTION ITEM: Move the text on the DNS Stability Evaluation into a separate Implementation Guidance. Rationale for Affirmation xx (Rationale 3): ACTION ITEM: The WG agreed to include the additional text, but not the text that begins “the working group has been advised Co-Chairs of the NCAP...” Also, the WG agreed to delete the associated footnote.

1 0

Post Call / New gTLD Subsequent Procedures Working Group / Tuesday, 16 June 2020 at 03:00 UTC
by Julie Bisland June 16, 2020

June 16, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Tuesday, 16 June 2020 at 03:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/2wAdC> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members can join the call, observers can listen to the recordings and read the transcript afterwards. Please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> if you would like to change your status from observer to member. For additional information, you may consult the mailing list archives <http://mm.icann.org/pipermail/gnso-newgtld-wg/> and the main wiki page<https://community.icann.org/x/RgV1Aw>. Thank you. Kind regards Julie

1 0

Informational RFC to create Private Namespace TLDs
by Jeff Neuman June 15, 2020

June 15, 2020

All, I thought I would forward this new Informational RFC put out by two employees working in ICANN's OCTO group. https://datatracker.ietf.org/doc/draft-arends-private-use-tld/?include_text… This proposed informational draft is not as technical as most of them. In fact, I would argue that although this has been filed to be dealt with at the IETF level, it really should be dealt with within ICANN's Multi-stakeholder processes as opposed to the IETF. It relates to a topic we have discussed before - Special Use Domains. In this draft, the authors argue that there should be strings that are reserved at the top level to allow entities to create private internets. There are a bunch of reasons to do this and some of them are articulated in the draft. I am not commenting on the merits of the RFC and not making an argument for or against. However, this is the type of thing I would think that the ICANN Community should have the ability to influence as opposed to circumventing the ICANN multi-stakeholder processes by going to the IETF to get these reserved as "special use" domains. Remember, we are recommending that Special Use domains that go through the IETF should be accounted for by being reserved from delegation by ICANN. Previously special use domains that were reserved had a particular technical purpose, but this one doesn't seem to fall into that category. Although we have completed our section on Special Use domains, I wanted to bring this to everyone's attention in case they had some thoughts. Jeff Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive Suite 600, McLean VA 22102, USA M: +1.202.549.5079 D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> www.comlaude.com<http://www.comlaude.com/> [cid:image001.jpg@01D642FB.4F946C80] ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com>

2 1

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 11 June 2000 UTC
by Julie Hedlund June 15, 2020

June 15, 2020

Dear Working Group members, Please see below the notes from the meeting on 11 June at 2000 UTC. 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: https://community.icann.org/display/NGSPP/2020-06-11+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: Applicant Support (multipliers at auction): ACTION ITEM: In the Implementation Guidance add language about researching a cap. 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. 2.3 Role of Application Comment b. Deliberations and rationale for recommendations and/or implementation guidelines Rationale for Recommendation xx and Implementation Guidance xx (rationale 5): ACTION ITEM: WG members should review section 2.4. General comment -- spell out acronyms when first used. ACTION ITEM: Spell out acronyms when first used in a section. 2.7.4 String Similarity Evaluation Recommendation xx (rationale 2): 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. 2.7.5 Internationalized Domain Names Recommendation xx (Rationale 4): 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.” Notes: 1. Updates to Statements of Interest: No updates provided. 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): https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… Proposed Language - Bid Credit/Multiplier for Applicant Support Recipients at Auction Implementation Guidance: “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%).” Discussion: -- 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%). ” -- Suggest 3 years from the signing of the contract. -- Need to make sure an ASP candidate can manage the finances and security. -- 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. -- Talked about this before in 2016 in Work Track 1 -- didn’t want to limit what an applicant could or couldn’t apply for. -- Put into the context of other provisions, such as if an applicant is a community applicant and qualifies (CPE), then auctions won’t apply. -- If they are one of many applicants then we are trying to even the playing field (or if they don’t qualify as community). -- This is similar to spectrum auctions in the US and Brazil. -- If we have two successful community applicants for the same string we haven’t come up with anything other than auctions to address it. -- The funding for the ASP is limited, so maybe there is a ceiling or payback option. -- If the bid credit is 25% then the applicant is only on the hook for 75%, but money is not being paid out. -- A credit won’t work with a third party auctioneer -- the administrative fees -- but this would be limited to an ICANN auction. -- In the public comments there was no support for giving priority to an applicant who gets applicant support. -- 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. -- Could add something about being consistent with similar processes. Re: “However, legitimate assignments (e.g., changing of ownership due to death or retirement, etc., assignments to subsidiaries, etc.) shall be permitted.” -- Non-profits also have requirements that might involve legitimate assignments. -- Let the Implementation Review Team focus on the legal language. -- Mergers, name changes, entity restructuring,... the normal changes of an organization or company.  -- The word “legitimate” doesn’t seem to be the right term. -- 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. -- 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. ACTION ITEM: In the Implementation Guidance add language about researching a cap. 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. 3. Review "Can't Live With" comments on package 4: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL…: 2.3 Role of Application Comment b. Deliberations and rationale for recommendations and/or implementation guidelines Rationale for Recommendation xx and Implementation Guidance xx (rationale 5): 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]. -- 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." -- 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. ACTION ITEM: WG members should review section 2.4. General comment -- spell out acronyms when first used. ACTION ITEM: Spell out acronyms when first used in a section. 2.7.4 String Similarity Evaluation Recommendation xx (rationale 2): 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. 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?" -- 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? 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. 2.7.5 Internationalized Domain Names Original Text: 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. Text suggested by Justine: [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.] 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?" 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." -- 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. -- 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. -- See: https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations…, which was referenced in developing this section. Alternative suggested language from Justine: “"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." -- This implies that if you already have one variant you can just ask for the other variant. -- Not sure how this is different from the old language. -- It shouldn’t have to go through the application process, it should just be a request. -- 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. 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.”

3 3

ICANN68: GNSO Sessions - How to Get Organized and Remote Participation Details
by Julie Bisland June 12, 2020

June 12, 2020

Dear all, The one-stop wiki page for all your Remote Participation queries is now available. This wiki page covers remote participation details for all GNSO open virtual meetings. In addition to this, ICANN Meetings’ Team has put together an updated ICANN meeting website which allows you to download all GNSO-related meetings to your inbox calendar in one go. 2 LINKS TO BOOKMARK NOW: ICANN68 Meeting Schedule [68.schedule.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__68.schedule.icann.org_…> GNSO Remote Participation Wiki Page<https://community.icann.org/x/a4EEC> Step 1 - Create a profile and your personalized ICANN68 schedule Go to the Meeting Schedule webpage and create a profile and login. Every session on the Full Agenda can be selected and added to your individual schedule by clicking the [cid:image001.png@01D640B1.DE9E1760] (blue ‘+’ box) in the upper right corner of each meeting. This adds it to your individual schedule, My Agenda, which you can then add to your calendar. See next step. Step 2 - To import your schedule into your calendar: once you’ve added all your chosen meetings to your schedule, click on [cid:image002.png@01D640B1.DE9E1760] (View My Agenda) * Click the down arrow next to Export * Select Export My Agenda (ics) * Open the exported meetings .ics and add to your chosen calendar * For Microsoft Outlook, right-click on the exported meetings .ics file and choose Show in Folder Right-click on the file, and select Open with Microsoft Outlook. Save & Close. Note: Your Agenda can only be exported from the desktop app; the ICANN68 phone app does not offer this feature Step 3 - All remote participation sessions will use Zoom rooms. You can find the Zoom room links for public meetings on the ICANN68 Meeting Schedule [68.schedule.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__68.schedule.icann.org_…> and on the <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_…> GNSO Remote Participation Wiki Page<https://community.icann.org/x/a4EEC>. PLEASE ENSURE YOU HAVE UPDATED YOUR ZOOM APP TO THE LATEST VERSION (5.0) TO ACCESS ICANN68 SESSIONS. Please download the latest Zoom app [zoom.us]<https://urldefense.proofpoint.com/v2/url?u=https-3A__zoom.us_download&d=DwM…> on your participation device (mobile or desktop computer). Need to learn or brush-up on using Zoom? Check out the Joining a Zoom Meeting Tutorial [support.zoom.us]<https://urldefense.proofpoint.com/v2/url?u=https-3A__support.zoom.us_hc_en-…>. Step 4 - Download the mobile app by searching for “ICANN Meetings” in your app stores. There are three options to connect your audio: 1) Via VoIP, choose Computer Audio (from a smartphone choose Call using Internet Audio) 2) Getting a dial out from Zoom to your phone, choose Call Me (from a smartphone choose Call My Phone) 3) Phoning into the audio bridge (access numbers and Meeting ID are provided for that option), choose Telephone Audio (from a smartphone choose Dial in) If you cannot log into the Zoom room, but wish to connect via telephone only, you can dial into the meeting. Please refer to the GNSO Remote Participation Wiki Page<https://community.icann.org/x/a4EEC> for access numbers and individual Meeting IDs. For all GNSO meeting related queries (RP or others), please email us at: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> and we will be more than happy to assist! Kind regards, GNSO SO/AC Support team -- Julie Bisland GNSO SO/AC Support coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: 79613b691cb8a6c1 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 16 June at 03:00 UTC for 90 Minutes
by Julie Hedlund June 12, 2020

June 12, 2020

Dear all, Please find below the proposed agenda for the call on Tuesday, 16 June 2020 at 03:00 UTC for 90 minutes. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Review "Can't Live With" comments on package 3 – additional comment from Anne Aikman-Scalese on page 38: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… 3. Review "Can't Live With" comments on package 4, start on page 57: https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… 4. 2.1 Auctions: Mechanisms of Last Resort & 2.2 Private Resolution of Contention Sets (Including Private Auction), Hybrid Proposal 2+, starting on page 10: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… 5. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Kind regards, Julie

1 1

Post Call / New gTLD Subsequent Procedures Working Group / Thursday, 11 June 2020 at 20:00 UTC
by Julie Bisland June 11, 2020

June 11, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 11 June 2020 at 20:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/1wAdC> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members can join the call, observers can listen to the recordings and read the transcript afterwards. Please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> if you would like to change your status from observer to member. For additional information, you may consult the mailing list archives <http://mm.icann.org/pipermail/gnso-newgtld-wg/> and the main wiki page<https://community.icann.org/x/RgV1Aw>. Thank you. Kind regards Julie

1 0

FW: IDN Variant - Activation or Application?
by Aikman-Scalese, Anne June 11, 2020

June 11, 2020

Jeff, Does this ICANN document say the idn variant is available via Application? Or Activation? By the holder of the original idn TLD? Anne ________________________________ https://www.icann.org/en/system/files/files/idn-variant-tld-rationale-lgr-2… ________________________________ 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.

1 0