April 2020 - Gnso-newgtld-wg

Re: [Gnso-newgtld-wg] NAME COLLISIONS TOPIC FOR discussion later in April
by Aikman-Scalese, Anne April 17, 2020

April 17, 2020

Hi Jeff. I did not want to take up time in the call today to raise this in AOB. Do we have invitations out to the NCAP Co-Chairs for the right date for our Name Collisions topic? Thank you, Anne From: Aikman-Scalese, Anne Sent: Wednesday, April 15, 2020 3:22 PM To: 'Jeff Neuman' <jeff.neuman(a)comlaude.com>; gnso-newgtld-wg(a)icann.org Cc: Cheryl Langdon-Orr (cheryl(a)hovtek.com.au) <cheryl(a)hovtek.com.au>; Justine Chew (justine.chew(a)gmail.com) <justine.chew(a)gmail.com>; gregshatanipc(a)gmail.com; James Galvin <jgalvin(a)afilias.info>; 'Patrik Fältström' <paf(a)frobbit.se> Subject: FW: NAME COLLISIONS TOPIC FOR discussion later in April Hi Jeff and Cheryl, Have we invited the Co-Chairs of the Name Collision Analysis Project to the WG call on name collisions? I believe they indicated a willingness to attend. Thank you, Anne From: Aikman-Scalese, Anne Sent: Friday, April 3, 2020 3:27 PM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: NAME COLLISIONS TOPIC FOR discussion later in April Dear WG Members, Study 1 of the Name Collision Analysis Project (NCAP) is linked below for those interested in some light weekend reading: https://www.icann.org/en/system/files/files/ncap-study-1-report-12feb20-en.… It contains a "Name Collision Primer" which may be helpful to those not previously involved with Work Track 4 work on this topic. (Sub Pro work is specifically discussed beginning on page 30 of this report.) Public comment closed March 31. One goal of the NCAP is to help guide the Board toward a standard for analysis of name collision risk applicable to evaluation in the next round. This comes about as a result of follow-up work on the ICANN Board resolution pasted below: Resolved (2017.11.02.30), the Board requests the ICANN Security and Stability Advisory Committee to conduct a study in a thorough and inclusive manner that includes technical experts (such as members of IETF working groups, technical members of the GNSO, and other technologists), to present data, analysis and points of view and provide advice to the Board on a range of questions that include, but are not limited to, the following: (1) a proper definition for name collision and the underlying reasons why strings that manifest name collisions are so heavily used; (2) the role that negative answers currently returned from queries to the root for these strings play in the experience of the end user, including in the operation of existing end systems; (3) the harm to existing users that may occur if Collision Strings were to be delegated, including harm due to end systems no longer receiving a negative response and additional potential harm if the delegated registry accidentally or purposely exploited subsequent queries from these end systems, and any other types of harm; (4) possible courses of action that might mitigate harm; (5) factors that affect potential success of the courses of actions to mitigate harm; (6) potential residual risks of delegating Collision Strings even after taking actions to mitigate harm; (7) suggested criteria for determining whether an undelegated string should be considered a string that manifest name collisions, (i.e.) placed in the category of a Collision String; (8) suggested criteria for determining whether a Collision String should not be delegated, and suggested criteria for determining how remove an undelegated string from the list of Collision Strings; and (9) measures to protect against intentional or unintentional creation of situations, such as queries for undelegated strings, which might cause such strings to be placed in a Collision String category, and research into risk of possible negative effects, if any, of creation of such a collision string list. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman(a)lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image003.png@01D61418.8FB9AFD0] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 2000 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> [cid:image004.jpg@01D61418.8FB9AFD0] Because what matters to you, matters to us.(tm) ________________________________ 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

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

April 16, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 16 April 2020 at 20:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/ny2JBw> (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

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

April 16, 2020

Dear Working Group members, Please see below the notes from the meeting on 16 April 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-04-16+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: Recommendation xx (rationale 3): ACTION ITEM: Consider changing “In service of” to “For the sake of transparency” or other phrase. Limited New gTLD Appeals Processes: ACTION ITEM: Third Row -- Column C: Potential Affected Parties: remove brackets from “Members of the contention set, if applicable” ACTION ITEM: Apply the concept to all of Column G: Who Bears the Costs? that unless there is a fundamental failure a typical win will not result in a refund. The appeals fees should be modest and accessible.  Row 15 -- Community Priority Evaluation: ACTION ITEM: Column E, Arbiter of Challenge: Change “Existing Evaluator Entity - Different individual Evaluator?” to “ultimate decision maker - Different ultimate decision maker” Notes: 1. Updates to Statements of Interest: No updates provided. 2. Discussion of Final Report Topics: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… a. 2.8.2 Limited Appeal/Challenge Mechanism and Post-Delegation Dispute Resolution Procedures – page 77 Recommendation xx (rationale 3): In service of transparency, clear procedures and rules must be established for challenge/appeal processes as described in the Implementation Guidance below. ACTION ITEM: Change “In service of” to “For the sake of transparency”. Implementation Guidance xx (rationale 6): The Working Group’s guidance on the arbiter for each type of challenge/appeal is summarized here: https://docs.google.com/spreadsheets/d/1R4eU7C-HI5ikF5RtVhp5JRXKVVRn6R8WX8f…. In the case of challenges to evaluation decisions, the arbiter should typically be an individual from the existing evaluator entity who did not conduct the original evaluation. In the case of an appeal of an objection decision, the arbiter will typically be a panelist or multiple panelists from the entity that handled the original objection, but will not be the same panelist(s) that provided the original objection decision. Discussion: -- Object to the phrase “evaluator entity”. ICANN shouldn’t delegate the evaluation of the the gTLD. -- At least one of the reasons to have this appeal/challenge process is to ensure that where an entity makes a decision there is a path to seek reconsideration, rather than having to try to bring an acct mechanism against icann for an act of the entity i.e we were recognising that there are entities and building in an improvement why on earth wouldn't KPMG be able to assess financial matters? -- I think that there have to be evaluation entities - e.g. WIPO - their procedures are widely respected. -- Where ICANN has a financial interest they shouldn’t be the evaluator. It ensures more objectivity. -- It seems like a benefit and not a flaw to have these various third-parties performing the evaluations/dispute resolutions. With appropriate oversight/transparency/appeals…which is what these recommendations/implementation guidance is intended to achieve . -- There is a lack of transparency, so no assurance of competence in the evaluations. -- ICANN can take responsibility for the work done by third parties. Limited New gTLD Appeals Processes: https://docs.google.com/spreadsheets/d/1R4eU7C-HI5ikF5RtVhp5JRXKVVRn6R8WX8f… Discussion: Second Row -- Column C: Potential Affected Parties Re: [- Members of the contention set, if applicable (suggestion from WG member)] -- this is in brackets. -- Not sure when it would ever come up. Third Row -- Column C: Potential Affected Parties Re: [- Members of the contention set, if applicable (suggestion from WG member)] [- Third parties (suggestion from WG members)] -- Support for members of the contention set and also third parties from Paul McGrady. ACTION ITEM: Third Row -- Column C: Potential Affected Parties: remove brackets from “Members of the contention set, if applicable” First Row -- Background Screening -- Column G: Who Bears the Cost -- Applicant - Should there be a partial refund if Applicant wins? -- Does the partial refund compound the "buddy down the hall" problem we already have? Now the co-employee will not only have to say his colleague is wrong, but his company has to also pay? Seems like that won't happen much. -- The legal and technical work of these evaluations should be, as much as possible, pro bono. -- This is an issue of oversight: It is not a simple question of correct or incorrect. There are different judgements and ways of looking at things. A partial refund would only come if something was sanctionable, not just being overruled. -- We have an example from the Accountability Mechanism for a reconsideration request. Similar to what we are talking about with the appeals process. It was shown that the evaluators didn’t do their job the way that they were supposed to do it. We are not sure who paid to do the second evaluation for the CPE. -- Given there are still excess funds available from 2012, it seems possible that the cost has been absorbed in some way by ICANN with the excess funds.  -- If the appeal is won there shouldn’t be a refund unless there was a fundamental failure to apply the standards. -- For the typical win/loss there should be no refund. -- Access to a challenge or appeal (which is great) can easily become inaccessible due to costs.  ACTION ITEM: Apply the concept to all of Column G: Who Bears the Costs? that unless there is a fundamental failure a typical win will not result in a refund. The appeals fees should be modest and accessible.  Row 4 -- String Similarity: -- Question: Is there any sort of objective algorithm that they are supposed to use? Answer: No. There is a test that they have used that is manual to weigh factors, not automated. -- If there is a Row 9 -- Geographic Names: -- Question: What do we mean by “Designation as a geographic name”? Answer: It is shorthand; Should include “as prescribed by the AGB”-- one that would have other requirements associated with it. -- Looking at the first outcome that might warrant challenge -- designation as a geographic name -- it is possible that an entity might not want that designation. There may be third parties other than the applicant that might want to challenge that designation. -- Question: Which evaluation challenge do you take up in the objection process if you object to the designation of a geographic name? Answer: Not sure what objection they could use. -- Question: What about something that hasn’t been designated a geographic name but someone other than the applicant wants it to be designated? Row 15 -- Community Priority Evaluation: -- Does this acknowledge that there is more transparency around the evaluators? Don’t think that this text sufficiently addresses the CPE process -- it wasn’t an evaluator, there were two evaluators and they had a team. There were layers of people involved none of which were known. There needs to be more clarity on who is different if it is being challenged. -- Who is it then? It needs to be someone other than the people involved in the evaluation? -- Suggesting that we need to be clear because if there is a person overseeing the evaluators that isn’t taken off the case will there be undue influence. Could the entire team be different? -- Who needs to change -- the evaluators, the manager of the evaluators, the administrative support? -- Could we say something like “the ultimate decision makers have to be different from the decision makers the first time”? But we don’t know who the decision makers were. But we have recommendations in the CPE section should ensure that we would know. -- This is one of the reasons why we want to see more community participation in the selection of the evaluators. We put that into the evaluation section. ACTION ITEM: Column E, Arbiter of Challenge: Change “Existing Evaluator Entity - Different individual Evaluator?” to “ultimate decision maker - Different ultimate decision maker”.

1 0

Re: [Gnso-newgtld-wg] Prioritization of IDNs proposal (Proportional Prioritization)
by Alan Greenberg April 16, 2020

April 16, 2020

Jeff, I support your original proposal subject to notes below). The 120 rule seems to be just too small a detail and I am not sure it can be justified. I agree that priority should be explicitly requested (with the warned implication that if delegated early, they must be prepared to launch). I presume that all decisions on who is in a round or which IDNs are selected is a random selection. Alan At 2020-04-13 10:33 PM, Jeff Neuman wrote: >Thanks Anne. The Applicant Guidebook did talk >about using batches of 500 if there are more >than 500 applications. I will dig that up ad >then create an affirmation for that. So, it >looks like we may have a possible workable solution. > >Would love to hear more feedback on the >proposal. Tomorrow, I will re-write the >proposal based on the feedback and create an example. > >Jeff Neuman >Senior Vice President >Com Laude | Valideus >D: +1.703.635.7514 >E: <mailto:jeff.neuman@comlaude.com>jeff.neuman(a)comlaude.com > >From: Aikman-Scalese, Anne <AAikman(a)lrrc.com> >Sent: Monday, April 13, 2020 4:51 PM >To: Jeff Neuman <jeff.neuman(a)comlaude.com>; >alexander(a)schubert.berlin; gnso-newgtld-wg(a)icann.org >Subject: RE: [Gnso-newgtld-wg] Prioritization of >IDNs proposal (Proportional Prioritization) > >Hi Jeff, >Thanks assuming the 2012 round had 120 idn applicants, I would say: >1. If there are 120 idn applicants (or fewer) >who check the box that they want priority, >process those first. Those who donât request >priority get thrown into the remaining random >batches and treated the same as all other applications. >. >2. If more than 120 idn applicants want >priority, I would go with your recommended >system, but I would say that we should be >processing no fewer than 50 idn applications per >batch if that many have applied for priority processing. > >It might help if we were to come up with a >âbatch sizeâ and >ârandomizationâ recommendation in >collaboration with ICANN GDD. Then we would >have more of a basis for recommending something >Anne > >From: Jeff Neuman <<mailto:jeff.neuman@comlaude.com>jeff.neuman(a)comlaude.com> >Sent: Monday, April 13, 2020 1:07 PM >To: Aikman-Scalese, Anne ><<mailto:AAikman@lrrc.com>AAikman(a)lrrc.com>; ><mailto:alexander@schubert.berlin>alexander(a)schubert.berlin; ><mailto:gnso-newgtld-wg@icann.org>gnso-newgtld-wg(a)icann.org >Subject: RE: [Gnso-newgtld-wg] Prioritization of >IDNs proposal (Proportional Prioritization) > >[EXTERNAL] > >Yes, I am making an assumption because we are >creating a process that needs to not only apply >to the next round, but needs to be >repeatable. Without knowing a specific volume >in advance, I am making a proposal based on a formula. > >So, If I understand your modification, it would be: > > * If there are <120 IDN applications, those > applicants that want priority will be processed prior to non-IDN applications. > * If there are >120 IDN applications, 120 of > the IDN applications will be processed before > any non-IDN applications. The remainder of the > IDN applications shall be processed in the following manner: > * In the first batch of 500, which > includes the 120 initially reviewed IDN > applications, the remaining 380 applications > shall be randomized including all IDN and non-IDN applications. > * The other batches shall work according to the example below. > >Example >In a batch of 500, priority #1-120 must be IDNs; >121-500 can be either IDN or non-IDN >applications. In other words if a particular >IDN application is not chosen in #1-50, it would >have a equal chance of being selected in 51-500. > >In the next batch of 500 (Applications >#501-1000), #501 - #550 must be IDN (if there >are any left), and #551-1000 can be either IDN or non-IDN > >In the next batch of 500 (Applications #1001 >15000), #1001 - #1050 must be IDN (if any are >left), and #1051 -1500 can be either IDN or non-IDN..etc > >Thus in a round with more than 1500 application, >there would be a guarantee of evaluating at >least 150 IDN applications PLUS any IDN >applications showing up in the randomized >drawings for the remaining 1,350 spots. > >I hope this works as a reasonable compromise. > > > >Jeff Neuman >Senior Vice President >Com Laude | Valideus >D: +1.703.635.7514 >E: <mailto:jeff.neuman@comlaude.com>jeff.neuman(a)comlaude.com > >From: Aikman-Scalese, Anne <<mailto:AAikman@lrrc.com>AAikman(a)lrrc.com> >Sent: Monday, April 13, 2020 3:53 PM >To: Jeff Neuman ><<mailto:jeff.neuman@comlaude.com>jeff.neuman(a)comlaude.com>; ><mailto:alexander@schubert.berlin>alexander(a)schubert.berlin; ><mailto:gnso-newgtld-wg@icann.org>gnso-newgtld-wg(a)icann.org >Subject: RE: [Gnso-newgtld-wg] Prioritization of >IDNs proposal (Proportional Prioritization) > >Hi Jeff it appears the logic relates to DELAY >in prrocessing idn applications. The assumption >appears to be that there are TONS of IDN >applications. NOT SURE THIS ASSUMPTION IS CORRECT. > >I was just suggesting a friendly amendment, IF >THERE ARENâT MORE IDN APPLICATIONS THAN LAST >TIME, why not let them move forward? If there >are a bunch more, as assumed by your hypo, then >we could RATION the processing of idn >applications not sure that 10% is rright and >would welcome others views on this. > >No silos here just a questioon re the >underlying assumption of extreme DELAY. >Anne > >From: Gnso-newgtld-wg ><<mailto:gnso-newgtld-wg-bounces@icann.org>gnso-newgtld-wg-bounces(a)icann.org> >On Behalf Of Jeff Neuman >Sent: Monday, April 13, 2020 12:40 PM >To: ><mailto:alexander@schubert.berlin>alexander(a)schubert.berlin; ><mailto:gnso-newgtld-wg@icann.org>gnso-newgtld-wg(a)icann.org >Subject: Re: [Gnso-newgtld-wg] Prioritization of >IDNs proposal (Proportional Prioritization) > >[EXTERNAL] > >All, > >Sorry, I took it as a given that an IDN that did >not want priority could opt out of prioritization. So that will be baked in. > >To respond to Anne, the public comment was mixed >on whether there should be prioritization. Many >commenters opposed ANY priority. Yes, some proposed them having priority. > >So, if we can think outside the box, I ask you >to critique the proposal with the following rules: > > * ASSUME ONLY PRIORITY FOR THOSE APPLICANTS THAT WANT IT, and > * ASSUME YOU CANNOT PICK ALL IDNS HAVE > PRIORITY nor CAN YOU PICK NO IDNs HAVE PRIORITY. > >Sorry, for the ALL CAPS, but I want us to try to >see what we can live with and not stick to our silos. > >Thanks in advance for trying again. > >Jeff Neuman >Senior Vice President >Com Laude | Valideus >D: +1.703.635.7514 >E: <mailto:jeff.neuman@comlaude.com>jeff.neuman(a)comlaude.com > >From: Gnso-newgtld-wg ><<mailto:gnso-newgtld-wg-bounces@icann.org>gnso-newgtld-wg-bounces(a)icann.org> >On Behalf Of Alexander Schubert >Sent: Monday, April 13, 2020 3:24 PM >To: <mailto:gnso-newgtld-wg@icann.org>gnso-newgtld-wg(a)icann.org >Subject: Re: [Gnso-newgtld-wg] Prioritization of >IDNs proposal (Proportional Prioritization) > >Hi, > >I think we have to bake the >priority-request-issue already into the application: > >In my mind it doesnât make any sense if we >proactively prioritize applicants that then wonât launch their TLDs. > >Any application that has a âsunrise periodâ >provision in their application and is seeking >prioritization should be forced to execute such >sunrise within XX month after TLD testing. If >you have a sunrise period and want prioritization: then execute your sunrise. > >Hence we should require applicants to indicate >already in their application whether they >request a potentially available prioritization. >If you donât yet know how or when you start >up: donât ask for prioritization. > >Thanks, > >Alexander > > > >From: Gnso-newgtld-wg >[<mailto:gnso-newgtld-wg-bounces@icann.org>mailto:gnso-newgtld-wg-bounces@icann.org] >On Behalf Of Maxim Alzoba >Sent: Monday, April 13, 2020 7:46 PM >To: Rubens Kuhl <<mailto:rubensk@nic.br>rubensk(a)nic.br> >Cc: <mailto:gnso-newgtld-wg@icann.org>gnso-newgtld-wg(a)icann.org >Subject: Re: [Gnso-newgtld-wg] Prioritization of >IDNs proposal (Proportional Prioritization) > >Why don't we add (in some ICANN style legal language) > >"Chosen IDN applicants have the right not to use >the results of such prioritization, and in this case >the respective applications will fall into non-prioritized batches". > >P.s: I think saying "or they go into the end of >the queue" is another extreme and we need to avoid that too. > >Sincerely Yours, > >Maxim Alzoba >Special projects manager, >International Relations Department, >FAITID > >Current UTC offset: +3.00 (.Moscow) > > > >On 13 Apr 2020, at 19:07, Rubens Kuhl ><<mailto:rubensk@nic.br>rubensk(a)nic.br> wrote: > > >What if the IDN applicant prefers not being a >first mover ? That was the case of brands in 2012, for instance. > >While I'm happy providing priority if the IDN >applicant wants it, although evaluation priority >address just one of the many issues faced by >IDNs, I don't think we should prioritise >applications that want exactly the opposite. > > >Rubens > > >On 13 Apr 2020, at 12:55, Jeff Neuman ><<mailto:jeff.neuman@comlaude.com>jeff.neuman(a)comlaude.com> wrote: > >All, > >In an effort to offer a compromise between those >that favor the prioritization of all IDN >applications and those that do not favor the >prioritization, I wanted to see if I could provide a compromise solution. > >Background >The prioritization of IDN applications was a >decision made by ICANN org well after all >applications were submitted in 2012 and made a >lot of sense to the community for the following >reasons. (1) There were only approximate 115 >IDN applications out of 1930 (about 6% of the >applications); (2) it was the first round to >ever accept applications for new IDN gTLDs, (3) >part of the rationale for the first expansion >was for innovation and expansion of the name >space to the global community and (4) it was a >good thing to do for the increased globalization of the Internet. > >Those in favor of prioritization of IDNs still >believe that despite not being the first round, >reasons (3) and (4) are still worthy of >pursuing. Many who are not in favor of >prioritization are afraid that the next round >could see thousands of new applications >including thousands of IDNs. To prioritize all >IDNs up front could take months or even years >(in theory) before a new non-IDN could be processed. > >Proposal Proportional Prioritization> >What is we stated that the first 10% of each >batch of applications must consist of IDN >applications until there are no more IDN >applications. Therefore, if ICANN wants to >create batches of 500 applications, the first 50 >of each application batch processed must be >IDNs. The remaining 450 would be random (of >both IDN and Non-IDN applications). > >Example >In a batch of 500, priority #1-50 must be IDNs; >51-500 can be either IDN or non-IDN >applications. In other words if a particular >IDN application is not chosen in #1-50, it would >have a equal chance of being selected in 51-500. > >In the next batch of 500 (Applications >#501-1000), #501 - #550 must be IDN (if there >are any left), and #551-1000 can be either IDN or non-IDN > >In the next batch of 500 (Applications #1001 >1500), #1001 - #1050 must be IDN (if any are >left), and #1051 -1500 can be either IDN or non-IDN..etc > >Thus in a round with more than 1500 application, >there would be a guarantee of evaluating at >least 150 IDN applications PLUS any IDN >applications showing up in the randomized >drawings for the remaining 1,350 spots. > >I hope this works as a reasonable compromise. > > >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: <mailto:jeff.neuman@comlaude.com>jeff.neuman(a)comlaude.com ><http://www.comlaude.com/>www.comlaude.com > ><image003.jpg> > > >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 ><https://comlaude.com/>www.comlaude.com_______________________________________________ >Gnso-newgtld-wg mailing list ><mailto:Gnso-newgtld-wg@icann.org>Gnso-newgtld-wg(a)icann.org >https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg >_______________________________________________ >By submitting your personal data, you consent to >the processing of your personal data for >purposes of subscribing to this mailing list >accordance with the ICANN Privacy Policy >(<https://www.icann.org/privacy/policy>https://www.icann.org/privacy/policy) >and the website Terms of Service >(<https://www.icann.org/privacy/tos>https://www.icann.org/privacy/tos) >You can visit the Mailman link above to change >your membership status or configuration, >including unsubscribing, setting digest-style >delivery or disabling delivery altogether (e.g., for a vacation), and so on. > > >_______________________________________________ >Gnso-newgtld-wg mailing list ><mailto:Gnso-newgtld-wg@icann.org>Gnso-newgtld-wg(a)icann.org >https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg >_______________________________________________ >By submitting your personal data, you consent to >the processing of your personal data for >purposes of subscribing to this mailing list >accordance with the ICANN Privacy Policy >(<https://www.icann.org/privacy/policy>https://www.icann.org/privacy/policy) >and the website Terms of Service >(<https://www.icann.org/privacy/tos>https://www.icann.org/privacy/tos) >You can visit the Mailman link above to change >your membership status or configuration, >including unsubscribing, setting digest-style >delivery or disabling delivery altogether (e.g., for a vacation), and so on. > > > >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 <https://comlaude.com>www.comlaude.com > > > >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. > >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 <https://comlaude.com>www.comlaude.com > > >---------- > >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. > >---------- >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 <https://comlaude.com>www.comlaude.com >_______________________________________________ >Gnso-newgtld-wg mailing list >Gnso-newgtld-wg(a)icann.org >https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg >_______________________________________________ >By submitting your personal data, you consent to >the processing of your personal data for >purposes of subscribing to this mailing list >accordance with the ICANN Privacy Policy >(https://www.icann.org/privacy/policy) and the >website Terms of Service >(https://www.icann.org/privacy/tos) You can >visit the Mailman link above to change your >membership status or configuration, including >unsubscribing, setting digest-style delivery or >disabling delivery altogether (e.g., for a vacation), and so on.

4 6

FW: NAME COLLISIONS TOPIC FOR discussion later in April
by Aikman-Scalese, Anne April 15, 2020

April 15, 2020

Hi Jeff and Cheryl, Have we invited the Co-Chairs of the Name Collision Analysis Project to the WG call on name collisions? I believe they indicated a willingness to attend. Thank you, Anne From: Aikman-Scalese, Anne Sent: Friday, April 3, 2020 3:27 PM To: gnso-newgtld-wg(a)icann.org Subject: NAME COLLISIONS TOPIC FOR discussion later in April Dear WG Members, Study 1 of the Name Collision Analysis Project (NCAP) is linked below for those interested in some light weekend reading: https://www.icann.org/en/system/files/files/ncap-study-1-report-12feb20-en.… It contains a "Name Collision Primer" which may be helpful to those not previously involved with Work Track 4 work on this topic. (Sub Pro work is specifically discussed beginning on page 30 of this report.) Public comment closed March 31. One goal of the NCAP is to help guide the Board toward a standard for analysis of name collision risk applicable to evaluation in the next round. This comes about as a result of follow-up work on the ICANN Board resolution pasted below: Resolved (2017.11.02.30), the Board requests the ICANN Security and Stability Advisory Committee to conduct a study in a thorough and inclusive manner that includes technical experts (such as members of IETF working groups, technical members of the GNSO, and other technologists), to present data, analysis and points of view and provide advice to the Board on a range of questions that include, but are not limited to, the following: (1) a proper definition for name collision and the underlying reasons why strings that manifest name collisions are so heavily used; (2) the role that negative answers currently returned from queries to the root for these strings play in the experience of the end user, including in the operation of existing end systems; (3) the harm to existing users that may occur if Collision Strings were to be delegated, including harm due to end systems no longer receiving a negative response and additional potential harm if the delegated registry accidentally or purposely exploited subsequent queries from these end systems, and any other types of harm; (4) possible courses of action that might mitigate harm; (5) factors that affect potential success of the courses of actions to mitigate harm; (6) potential residual risks of delegating Collision Strings even after taking actions to mitigate harm; (7) suggested criteria for determining whether an undelegated string should be considered a string that manifest name collisions, (i.e.) placed in the category of a Collision String; (8) suggested criteria for determining whether a Collision String should not be delegated, and suggested criteria for determining how remove an undelegated string from the list of Collision Strings; and (9) measures to protect against intentional or unintentional creation of situations, such as queries for undelegated strings, which might cause such strings to be placed in a Collision String category, and research into risk of possible negative effects, if any, of creation of such a collision string list. Anne Anne E. Aikman-Scalese Of Counsel 520.629.4428 office 520.879.4725 fax AAikman(a)lrrc.com<mailto:AAikman@lrrc.com> _____________________________ [cid:image003.png@01D609CC.5E2575E0] Lewis Roca Rothgerber Christie LLP One South Church Avenue, Suite 2000 Tucson, Arizona 85701-1611 lrrc.com<http://lrrc.com/> [cid:image005.jpg@01D609CC.5E2575E0] Because what matters to you, matters to us.(tm) ________________________________ 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

Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 14 April at 3:00 UTC - some notes on the GAC letter
by Jorge.Cancio＠bakom.admin.ch April 15, 2020

April 15, 2020

Dear all I was finally able to listen to the portion of the call, where the GAC leadership letter regarding the timeline was discussed. Personally, I don’t recall that the “worst case scenario” notion/interpretation of the timeline presented in ICANN 67 were communicated as clearly during ICANN 67. In fact, during our GAC discussions we were basing all our intersessional planning on the SubPro timeline as communicated (and presented by Jeff and Cheryl). That is why we have planned, first, a consultation and compilation on the 5 subjects discussed in ICANN 67 (which is ongoing), and then, second, discuss further in ICANN 68 with a view to preparing a potential GAC input to the public comment period which was envisaged for after ICANN 68… In addition to those “expectations”, now we have the COVID-19 situation, where many of us have to devote our scarce resources to more urgent matters. Hence, as the GAC leadership letter points out, I personally hope that the timeline of the PDP WG may stay more or less in line with what was communicated or, at least, understood by us in ICANN 67, and that it in any case allows us to prepare, discuss and consolidate meaningful GAC inputs on the SubPro issues following the two planned steps of (1) compilation of GAC Members’ views; (2) GAC input to the public comment period… Best regards Jorge Von: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> Im Auftrag von Emily Barabas Gesendet: Dienstag, 14. April 2020 13:18 An: gnso-newgtld-wg(a)icann.org Betreff: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 14 April at 3:00 UTC Dear Working Group members, Please see below the notes from the meeting on 14 April at 3:00 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/x/nC2JBw Kind regards, Emily ACTION ITEMS: ACTION ITEM (Base Registry Agreement): Include question for public comment about Code of Conduct exemption. ACTION ITEM (Base Registry Agreement): Include question for public comment about whether contractual provision stating that the RO will not engage in fraudulent and deceptive practices should be in the form of a PIC. ACTION ITEM: Under “Recommendation xx (rationale 2): The addition of Registry Voluntary Commitments must require public comment.” Ensure that this recommendation includes all items discussed that must require public comment. ACTION ITEM (Application Change Requests): Include recommendation for .brands to be able to change the applied-for string under narrow circumstances. Include question for public comment on whether there should be other circumstances where the applicant can change the applied-for string and also request input on whether any additional guardrails are needed. NOTES: 1. Review Agenda/Updates to Statements of Interest - Request from WG member to ensure that there is sufficient time to discuss the letter from the GAC under AOB. - Request noted by leadership. Ten minutes will be left at the end of the call. - First batch of draft final sections will go out today. These will be sent with a form for members to fill out and send by email if there are items that they “can’t live with.” Comments should include proposed edits to resolve the identified issue. These proposed edits should be in line with previous discussions. - The sections that will be released are: Systems, Communications, Fees, Applicant Guidebook, Application Submission Period - WG members will have 7 days to review the sections and provide feedback. - Confirmation that this is an additional refinement step. This is not a consensus call. There will be an opportunity to make any final adjustments in the weeks before the report is published for public comment. - Consensus call will take place after final revisions are made following public comment. 2. Discussion of Final Report Topics: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> a. 2.10.1 Base Registry Agreement, Section C New Issues, start on page 77 - Topic under part C – Code of Conduct exemption for registries that have made a good faith effort to get registrars to carry the TLD, but were unable to do so. Should this be a recommendation or IG? - Question – do we know how many registries are in this position? - Answer – there is only anecdotal evidence of this issue. Data is not available. - Question – what are the current grounds for exemption? - Answer – the only way to gain an exemption currently is included at the end of Spec 9. They have to meet all criteria. They have to be a single registrant TLD. They may not qualify for Spec 13. They have to provide a justification that there is no harm to the public interest by having the exemption. See https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… - Some support expressed for including this item as a recommendation to support innovation. - Counter-argument – this only impacted a few registries is the 2012 round, registries should do due diligence before they apply to make sure there is a distribution channel. - Question – what is the standard for evaluating candidates for this exemption? - Answer – there are no purely objective standards to determine what constitutes a good faith effort. Registries should be able to show the reached out to registrars. The WG would need to leave some discretion to ICANN org. - Suggestion – include proposed standards in the question that goes out for public comment. Question could include request for input on how to evaluate those seeking the exemption. - Some support for including as a question for public comment. ACTION ITEM (Base Registry Agreement): Include question for public comment about Code of Conduct exemption. - Discussion topic - contractual provision stating that the RO will not engage in fraudulent and deceptive practices. - Agreement that there should be a question for public comment about whether this should be a PIC. ACTION ITEM (Base Registry Agreement): Include question for public comment about whether contractual provision stating that the RO will not engage in fraudulent and deceptive practices should be in the form of a PIC. b. 2.4 Application Change Requests, page 79 - Comment – need to make sure that the previous discussions under other topics are reflected in this section regarding which types changes require public comment. ACTION ITEM: Under “Recommendation xx (rationale 2): The addition of Registry Voluntary Commitments must require public comment.” Ensure that this recommendation includes all items discussed that must require public comment. - From the 2012 round, there was a list of items that do not require public comment. The challenge of listing all items that do require a public comment is that you might miss something. The Working Group might want to include an exemplary list of items that require public comment and may also include items that will not require public comment, drawing on the list from 2012. - WG members are encouraged to provide feedback on this item on the mailing list. - Note that ICANN Org requested that the WG provide additional guidance with respect to Recommendation xx (rationale 3) – details of this request are included as a comment in the document. - This recommendation touches on a few different issues and may need to be reworked. - It may make sense to revisit these recommendations after the section has been revised and see if the ICANN org concerns are addressed. -Review of proposal to allow applicants to change the applied-for string in part c of the section. There are currently no recommendations on this topic. - We have ruled out the ability of applicants to change the string under all circumstances. We are focused on some possible, narrow exceptions, specifically: - in response to an objection, for example GAC Advice – example: The GAC issues advice against a brand name, but is comfortable with the a TLD that includes the name plus “company.” - Two or more .brand applicants apply for the same string. The parties agree that one or both applicants change the applied for string. Example – two brands apply for .sas, one of the applicants could change the applied-for string to .sassoftware or similar. - In both cases, changes would be subject to public comment and would trigger an opportunity for objections. The new string must not create a new contention set or expand an existing contention set. - Concern expressed about potential gaming. WG would need to narrowly define circumstances where this is allowed to prevent gaming. - Some support expressed for this narrow solution as a common-sense approach, noting that there needs to be a process and criteria for implementation. - Feedback that if this proposal becomes a recommendation, their needs to be appropriate guardrails in place. - If this is included as a recommendation, it should be accompanied by a question for public comment. - Is this proposal too limited? Should there be other circumstances where a change should be permitted? - From one perspective, if guardrails are in place (public comment, ability to object, no new contention set), the proposal could be broader, might not even need to limited to brands. - Suggestion that the discussion of guardrails should be more specific – must need to comply with all other rules of the program related to applied-for strings (name collisions, IDN variants, etc). - Some support had been expressed on previous calls for the proposal only if it is narrowly tailored. ACTION ITEM (Application Change Requests): Include recommendation for .brands to be able to change the applied-for string under narrow circumstances. Include question for public comment on whether there should be other circumstances where the applicant can change the applied-for string and also request input on whether any additional guardrails are needed. - What about allowing a change, using the same guardrails, in response to other types of objections, not only GAC Advice? - Feedback from ICANN org – the proposal regarding .brands changing the applied-for string could potentially change the criteria used for Spec 13. Under the current criteria, one of the things that is looked at is whether the string is an exact match of a trademark. - Response – they would first have to qualify to be a .brand, only in that circumstance would they qualify to change the applied-for string. The new string would also need to be considered at brand TLD, which would be a narrow exception to the exact match. - Comment: From a common sense perspective, it makes sense to have an exception, but is it unfair to companies who would like to apply for the exact match of their brand name and it is not available for some reason, but they can’t apply for an alternate string as a .brand. - Example: GE could not apply for .ge, but they were told that something like .gecompany could not be a .brand and they would have to apply for an exemption to create a quasi-.brand. - Possible alternative if the WG does not believe the new string should be eligible as a .brand - the new string could be eligible for a Code of Conduct exemption instead. 3. AOB - Letter from the GAC - GAC raised concerns about the current timeline that the PDP is following in light of COVID-19 and would like to see the PDP follow the worst-case scenario timeline included in the GNSO Project Change Request. - Suggestion from WG member – Submit a Final Report on the current schedule covering all topics except the 5 that most interest the GAC and then submit a supplemental Final Report after ICANN68 that focuses on the five issues that most interest the GAC. - Jeff’s response – The GAC has already given really good feedback on those five issues that the WG can take back and discuss. It is too early at this stage to know if we need to proceed with a new plan. - The PCR presents a worst case scenario, so it is unclear why the GAC is relying on that document. This is something that the WG should continue to discuss. - Cheryl’s response – there could be an opportunity to collect additional input from the GAC on the five topics as long as it doesn’t impact the overall timeline of the report. - Jeff’s response – we will welcome the GAC’s response during the public comment period. - Question - the Work Plan still reflects a start date of the public comment period of July 20, is this current? - Response - the current goal is to get the report out before ICANN68. The Work Plan needs to be updated to reflect this. - Comment – is there a way to enable additional GAC input on the topic that interest them during ICANN68? - Note that SubPro co-chairs spent a significant amount of time with the GAC during ICANN67 ensuring that GAC members were up to speed and had an opportunity to provide input. - Suggestion to reduce frequency of calls. - Leadership would like to keep the current frequency to continue the current momentum. - In slides for ICANN67, we said the timeline depicted was a worst case scenario, but there is still likely an opportunity for outreach to the GAC, in particular from the Council. The Council may want to connect with the GAC about its renewed emphasis on building more conservative timelines for projects, which may result in projects moving ahead of those timelines.

1 0

Post Call / New gTLD Subsequent Procedures Working Group call / Tuesday, 14 April 2020 at 03:00 UTC
by Andrea Glandon April 14, 2020

April 14, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Tuesday, 14 April 2020 at 03:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/nC2JBw> (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 Andrea

1 0

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 16 April at 20:00 UTC
by Julie Hedlund April 14, 2020

April 14, 2020

Dear all, Please find below the proposed agenda for the call on Thursday, 16 April 2020 at 20:00 UTC for 120 minutes. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Discussion of Final Report Topics: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… * 2.8.2 Limited Appeal/Challenge Mechanism and Post-Delegation Dispute Resolution Procedures – page 77 3. 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 Julie Hedlund, Policy Director

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 14 April at 3:00 UTC
by Emily Barabas April 14, 2020

April 14, 2020

Dear Working Group members, Please see below the notes from the meeting on 14 April at 3:00 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/x/nC2JBw Kind regards, Emily ACTION ITEMS: ACTION ITEM (Base Registry Agreement): Include question for public comment about Code of Conduct exemption. ACTION ITEM (Base Registry Agreement): Include question for public comment about whether contractual provision stating that the RO will not engage in fraudulent and deceptive practices should be in the form of a PIC. ACTION ITEM: Under “Recommendation xx (rationale 2): The addition of Registry Voluntary Commitments must require public comment.” Ensure that this recommendation includes all items discussed that must require public comment. ACTION ITEM (Application Change Requests): Include recommendation for .brands to be able to change the applied-for string under narrow circumstances. Include question for public comment on whether there should be other circumstances where the applicant can change the applied-for string and also request input on whether any additional guardrails are needed. NOTES: 1. Review Agenda/Updates to Statements of Interest - Request from WG member to ensure that there is sufficient time to discuss the letter from the GAC under AOB. - Request noted by leadership. Ten minutes will be left at the end of the call. - First batch of draft final sections will go out today. These will be sent with a form for members to fill out and send by email if there are items that they “can’t live with.” Comments should include proposed edits to resolve the identified issue. These proposed edits should be in line with previous discussions. - The sections that will be released are: Systems, Communications, Fees, Applicant Guidebook, Application Submission Period - WG members will have 7 days to review the sections and provide feedback. - Confirmation that this is an additional refinement step. This is not a consensus call. There will be an opportunity to make any final adjustments in the weeks before the report is published for public comment. - Consensus call will take place after final revisions are made following public comment. 2. Discussion of Final Report Topics: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…> a. 2.10.1 Base Registry Agreement, Section C New Issues, start on page 77 - Topic under part C – Code of Conduct exemption for registries that have made a good faith effort to get registrars to carry the TLD, but were unable to do so. Should this be a recommendation or IG? - Question – do we know how many registries are in this position? - Answer – there is only anecdotal evidence of this issue. Data is not available. - Question – what are the current grounds for exemption? - Answer – the only way to gain an exemption currently is included at the end of Spec 9. They have to meet all criteria. They have to be a single registrant TLD. They may not qualify for Spec 13. They have to provide a justification that there is no harm to the public interest by having the exemption. See https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… - Some support expressed for including this item as a recommendation to support innovation. - Counter-argument – this only impacted a few registries is the 2012 round, registries should do due diligence before they apply to make sure there is a distribution channel. - Question – what is the standard for evaluating candidates for this exemption? - Answer – there are no purely objective standards to determine what constitutes a good faith effort. Registries should be able to show the reached out to registrars. The WG would need to leave some discretion to ICANN org. - Suggestion – include proposed standards in the question that goes out for public comment. Question could include request for input on how to evaluate those seeking the exemption. - Some support for including as a question for public comment. ACTION ITEM (Base Registry Agreement): Include question for public comment about Code of Conduct exemption. - Discussion topic - contractual provision stating that the RO will not engage in fraudulent and deceptive practices. - Agreement that there should be a question for public comment about whether this should be a PIC. ACTION ITEM (Base Registry Agreement): Include question for public comment about whether contractual provision stating that the RO will not engage in fraudulent and deceptive practices should be in the form of a PIC. b. 2.4 Application Change Requests, page 79 - Comment – need to make sure that the previous discussions under other topics are reflected in this section regarding which types changes require public comment. ACTION ITEM: Under “Recommendation xx (rationale 2): The addition of Registry Voluntary Commitments must require public comment.” Ensure that this recommendation includes all items discussed that must require public comment. - From the 2012 round, there was a list of items that do not require public comment. The challenge of listing all items that do require a public comment is that you might miss something. The Working Group might want to include an exemplary list of items that require public comment and may also include items that will not require public comment, drawing on the list from 2012. - WG members are encouraged to provide feedback on this item on the mailing list. - Note that ICANN Org requested that the WG provide additional guidance with respect to Recommendation xx (rationale 3) – details of this request are included as a comment in the document. - This recommendation touches on a few different issues and may need to be reworked. - It may make sense to revisit these recommendations after the section has been revised and see if the ICANN org concerns are addressed. -Review of proposal to allow applicants to change the applied-for string in part c of the section. There are currently no recommendations on this topic. - We have ruled out the ability of applicants to change the string under all circumstances. We are focused on some possible, narrow exceptions, specifically: - in response to an objection, for example GAC Advice – example: The GAC issues advice against a brand name, but is comfortable with the a TLD that includes the name plus “company.” - Two or more .brand applicants apply for the same string. The parties agree that one or both applicants change the applied for string. Example – two brands apply for .sas, one of the applicants could change the applied-for string to .sassoftware or similar. - In both cases, changes would be subject to public comment and would trigger an opportunity for objections. The new string must not create a new contention set or expand an existing contention set. - Concern expressed about potential gaming. WG would need to narrowly define circumstances where this is allowed to prevent gaming. - Some support expressed for this narrow solution as a common-sense approach, noting that there needs to be a process and criteria for implementation. - Feedback that if this proposal becomes a recommendation, their needs to be appropriate guardrails in place. - If this is included as a recommendation, it should be accompanied by a question for public comment. - Is this proposal too limited? Should there be other circumstances where a change should be permitted? - From one perspective, if guardrails are in place (public comment, ability to object, no new contention set), the proposal could be broader, might not even need to limited to brands. - Suggestion that the discussion of guardrails should be more specific – must need to comply with all other rules of the program related to applied-for strings (name collisions, IDN variants, etc). - Some support had been expressed on previous calls for the proposal only if it is narrowly tailored. ACTION ITEM (Application Change Requests): Include recommendation for .brands to be able to change the applied-for string under narrow circumstances. Include question for public comment on whether there should be other circumstances where the applicant can change the applied-for string and also request input on whether any additional guardrails are needed. - What about allowing a change, using the same guardrails, in response to other types of objections, not only GAC Advice? - Feedback from ICANN org – the proposal regarding .brands changing the applied-for string could potentially change the criteria used for Spec 13. Under the current criteria, one of the things that is looked at is whether the string is an exact match of a trademark. - Response – they would first have to qualify to be a .brand, only in that circumstance would they qualify to change the applied-for string. The new string would also need to be considered at brand TLD, which would be a narrow exception to the exact match. - Comment: From a common sense perspective, it makes sense to have an exception, but is it unfair to companies who would like to apply for the exact match of their brand name and it is not available for some reason, but they can’t apply for an alternate string as a .brand. - Example: GE could not apply for .ge, but they were told that something like .gecompany could not be a .brand and they would have to apply for an exemption to create a quasi-.brand. - Possible alternative if the WG does not believe the new string should be eligible as a .brand - the new string could be eligible for a Code of Conduct exemption instead. 3. AOB - Letter from the GAC - GAC raised concerns about the current timeline that the PDP is following in light of COVID-19 and would like to see the PDP follow the worst-case scenario timeline included in the GNSO Project Change Request. - Suggestion from WG member – Submit a Final Report on the current schedule covering all topics except the 5 that most interest the GAC and then submit a supplemental Final Report after ICANN68 that focuses on the five issues that most interest the GAC. - Jeff’s response – The GAC has already given really good feedback on those five issues that the WG can take back and discuss. It is too early at this stage to know if we need to proceed with a new plan. - The PCR presents a worst case scenario, so it is unclear why the GAC is relying on that document. This is something that the WG should continue to discuss. - Cheryl’s response – there could be an opportunity to collect additional input from the GAC on the five topics as long as it doesn’t impact the overall timeline of the report. - Jeff’s response – we will welcome the GAC’s response during the public comment period. - Question - the Work Plan still reflects a start date of the public comment period of July 20, is this current? - Response - the current goal is to get the report out before ICANN68. The Work Plan needs to be updated to reflect this. - Comment – is there a way to enable additional GAC input on the topic that interest them during ICANN68? - Note that SubPro co-chairs spent a significant amount of time with the GAC during ICANN67 ensuring that GAC members were up to speed and had an opportunity to provide input. - Suggestion to reduce frequency of calls. - Leadership would like to keep the current frequency to continue the current momentum. - In slides for ICANN67, we said the timeline depicted was a worst case scenario, but there is still likely an opportunity for outreach to the GAC, in particular from the Council. The Council may want to connect with the GAC about its renewed emphasis on building more conservative timelines for projects, which may result in projects moving ahead of those timelines.

1 0

Prioritization of IDNs proposal (Proportional Prioritization)
by Jeff Neuman April 14, 2020

April 14, 2020

All, In an effort to offer a compromise between those that favor the prioritization of all IDN applications and those that do not favor the prioritization, I wanted to see if I could provide a compromise solution. Background The prioritization of IDN applications was a decision made by ICANN org well after all applications were submitted in 2012 and made a lot of sense to the community for the following reasons. (1) There were only approximate 115 IDN applications out of 1930 (about 6% of the applications); (2) it was the first round to ever accept applications for new IDN gTLDs, (3) part of the rationale for the first expansion was for innovation and expansion of the name space to the global community and (4) it was a good thing to do for the increased globalization of the Internet. Those in favor of prioritization of IDNs still believe that despite not being the first round, reasons (3) and (4) are still worthy of pursuing. Many who are not in favor of prioritization are afraid that the next round could see thousands of new applications including thousands of IDNs. To prioritize all IDNs up front could take months or even years (in theory) before a new non-IDN could be processed. Proposal - Proportional Prioritization What is we stated that the first 10% of each batch of applications must consist of IDN applications until there are no more IDN applications. Therefore, if ICANN wants to create batches of 500 applications, the first 50 of each application batch processed must be IDNs. The remaining 450 would be random (of both IDN and Non-IDN applications). Example In a batch of 500, priority #1-50 must be IDNs; 51-500 can be either IDN or non-IDN applications. In other words if a particular IDN application is not chosen in #1-50, it would have a equal chance of being selected in 51-500. In the next batch of 500 (Applications #501-1000), #501 - #550 must be IDN (if there are any left), and #551-1000 can be either IDN or non-IDN In the next batch of 500 (Applications #1001 - 1500), #1001 - #1050 must be IDN (if any are left), and #1051 -1500 can be either IDN or non-IDN.....etc Thus in a round with more than 1500 application, there would be a guarantee of evaluating at least 150 IDN applications PLUS any IDN applications showing up in the randomized drawings for the remaining 1,350 spots. I hope this works as a reasonable compromise. 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:image003.jpg@01D6118A.666A9B70] ________________________________ 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>

6 12