November 2020 - Gnso-newgtld-wg

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Monday, 09 November 15:00 UTC
by Julie Hedlund Nov. 5, 2020

Nov. 5, 2020

Dear WG Members, Please find below the proposed agenda for the regular WG meeting on Monday, 09 November 2020 at 15:00 UTC for 90 minutes. Note: For the schedule of the upcoming meeting topics, please see the Work Plan at: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn…. WG members are requested to review scheduled topics and comments prior to the meetings. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: <https://docs.google.com/spreadsheets/d/1x9vbkFUNEAb55oEPCFRsdrDlowh06zIUBiU…> https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Topic 31: Objections<https://docs.google.com/spreadsheets/d/1Pk3SadfiropKdD387FrgELdulfZuTbUCivf…> Topic 30: GAC Early Warning/GAC Consensus Advice<https://docs.google.com/spreadsheets/d/1Pk3SadfiropKdD387FrgELdulfZuTbUCivf…> Topic 28: Role of Application Comment<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> 1. 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>. Best, Julie Julie Hedlund, Policy Director

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 05 November 03:00 UTC
by Julie Hedlund Nov. 5, 2020

Nov. 5, 2020

Dear Working Group members, Please see below the notes from the working sessions on 05 November at 03: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/display/NGSPP/2020-11-05+New+gTLD+Subsequent+Pr…. Kind regards, Julie == Notes and Action Items: Action Items: Topic 15: Application Fees<https://docs.google.com/spreadsheets/d/1rOqfucddhWhYK8u3-O7IHg772BpjEIGhlmC…> Row 13 -- Dotzon GmbH re: IG 15.8 modification: excess fees must be returned to applicants ACTION ITEM: Add that ICANN may want to spread out the cost. Not as Implementation Guidance. Row 24 -- Christa Taylor (Individual) re: Fee floor evaluation; excess fee uses; periodic review; timely return of excess fees; determining fees ACTION ITEM: Revise the language of the recommendation along the lines that Christa is suggesting: From Christa: “15.8 In the event, the excess fees are less than an agreed-upon amount for example, $1k then those funds should be used for the purpose as outlined in recommendation 15.9.” Row 23 – RySG re: Fee floor evaluation; excess fee uses; periodic review; timely return of excess fees; determining fees ACTION ITEMS: Revise the Recommendation: 1) Change the refund to be refund or credit towards future fees where applicable; 2) If you can't find that entity or, you know, there's no entity to claim that refund, then it would go towards one of the purposes set forth and 15.9. ACTION ITEM: Staff to check to see how the US47k was derived in the 2012 round. Row 26 – ICANN Board re: Further examine concepts: excess fees, closure, round. ACTION ITEM: Leadership will put suggested Implementation Guidance language out on the list for the WG to consider: Could provide Implementation Guidance to the IRT that if ICANN can determine its budget to cover historical, evaluation, and contingency costs, it could release refunds on a percentage basis depending on how many applications are final. Row 27 – ICANN Org re: multiple comments ACTION ITEM: Revise the Recommendation and Implementation Guidance to put 15.5, 15.6, and 15.7 directly into Recommendation 15.4. Leave 15.8 as the only Implementation Guidance for Recommendation 15.4. Topic 36: Base Registry Agreement<https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONz…> Row 12 -- Intellectual Property Constituency (IPC) and PETILLION Law Firm re: “Accordingly, the IPC advocates for strict limitations on exemptions from the base RA, if any, which must not weaken existing rights protection mechanisms or public interest commitments otherwise present in the RA.” ACTION ITEM: Revise the recommendation to make it clear that consensus policy should not be the subject of individual RA negotiations. Rows 17 and 29 – ALAC re: Enforce prohibition on fraudulent/deceptive practices in PIC or base RA/Answer to Community Question: Both PIC and RA ACTION ITEM: Leadership will put the question out to the list for the WG to consider: “PICDRP does allow in theory "both options", but ALAC does not like the requirement that someone needs to allege and show how they have been harmed by the action. Does WG want to address this? Row 18 – ICANN Org re: Concern about custom RAs; clear rationale for exemptions; request clarity from WG on recommendation 36.3 and provisions; lack of clarity concerning aspects of recommendation 36.4. ACTION ITEM: Add language to Recommendation 36.3 that a clear rationale must accompany any exemption request. Notes: 1. Updates to Statements of Interest: None provided. 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: Topic 15: Application Fees<https://docs.google.com/spreadsheets/d/1rOqfucddhWhYK8u3-O7IHg772BpjEIGhlmC…> Row 13 -- Dotzon GmbH re: IG 15.8 modification: excess fees must be returned to applicants Leadership Comments: Should we provide more clarity around "cost recovery period" Discussion: -- It needs to consider expenses that go beyond one round i.e. systems. -- For the next round we may want some note as IG an acknowledgement that ICANN will be developing new systems and they may want to space that out among new rounds. -- Might be something that we recover over a period of time. -- Cost recovery should be based on that particular round. Could leave it to ICANN/IRT to determine how to do this. -- On cost definition: from 2012 round, the answer has been that the costs are ongoing and there continues to be risk. -- But we are making a number of changes to the evaluation process so how will ICANN know how much everything will cost this time? Also the changes we make could result in more litigation and disputes. So is it really that easy to determine? ACTION ITEM: Add that ICANN may want to spread out the cost. Not as Implementation Guidance. Row 24 -- Christa Taylor (Individual) re: Fee floor evaluation; excess fee uses; periodic review; timely return of excess fees; determining fees Leadership Comments: 15.5 - Already discussed 15.8 - Excess fees should have at least $1k go to 15.9 purposes. 15.9 - Excess fees could be a credit towards future ICANN Payments. If the excess is less than $1 then the excess goes to something. Could we say if there is some amount that was to hard to do a refund, then it should go to on of these other areas. Re: From Christa: “15.8 In the event, the excess fees are less than an agreed-upon amount for example, $1k then those funds should be used for the purpose as outlined in recommendation 15.9. This will help ICANN remain efficient while ensuring the costs related to the return of the fees do not exceed the resources required to return the excess to applicants. These funds could be used for items in Recommendation 15.9.” Discussion: -- Won't we know whether there is an excess for some time after the round as there could be potential disputes or litigation later which would normally be paid for from application fees. -- We do recommend a separate work track or team for AS. -- We could say that the IRT should work with the AS work track. -- Could keep this at a high level. Just give guidance to the IRT. -- There were metrics that we wanted developed by the IRT. -- If we have an understanding of how USD47k was derived, then we can at least consider if that formula could be retained for IRT to work on. ACTION ITEM: Revise the language of the recommendation along the lines that Christa is suggesting: From Christa: “15.8 In the event, the excess fees are less than an agreed-upon amount for example, $1k then those funds should be used for the purpose as outlined in recommendation 15.9.” Row 23 – RySG re: Fee floor evaluation; excess fee uses; periodic review; timely return of excess fees; determining fees Leadership Comments: Move first $1k of excess fees (From each application) into contingency fund) Do we need to provide more information on determination of Applicant Support Fees -- maybe leave for the IRT? But is there a principle that we can rely on that was used the last time? Option: Maybe the percentage discount used in the 2012 round could be leveraged for future rounds. Discussion: -- Could start as a baseline from the 2012 round. -- Could use the excess fees as credits for future services, instead of as a refund. -- Could use the excess fees for those items mentioned in Recommendation 15.9, such as an education/awareness campaign. -- Question: Why do we need to build a system to deal with unfixable refunds? For non-profits by default they go to the Secretary of State of California. Answer: We think we’d rather have the funds go to the new gTLD program and specifically the purposes in Recommendation 15.9. ACTION ITEMS: Revise the Recommendation: 1) Change the refund to be refund or credit towards future fees where applicable; 2) If you can't find that entity or, you know, there's no entity to claim that refund, then it would go towards one of the purposes set forth and 15.9. ACTION ITEM: Staff to check to see how the US47k was derived in the 2012 round. Row 25 -- GAC-France re: Concerns about fee floor Leadership Comments: We believe this was intended, but transparency requirement to setting fees should apply to setting the Fee Floor as well. ACTION ITEM: Revise the recommendation to apply the transparency requirement to both the establishment of the fee, as well as the establishment of the floor. Row 26 – ICANN Board re: Further examine concepts: excess fees, closure, round. Leadership Comments: Important to consider when a round is closed IF we are to refund applicants. Leadership believes that looking at a schedule of refunds, or a percentage basis rather than a full refund may be more palatable. (eg., once 50% of apps are "final", then an estimate of excess be determined and payment of 25% of the estimate is paid and then apply a scale after that point). Could set aside part of the payment for continency items and the rest could be available for refund. ACTION ITEM: Leadership will put suggested Implementation Guidance language out on the list for the WG to consider: Could provide Implementation Guidance to the IRT that if ICANN can determine its budget to cover historical, evaluation, and contingency costs, it could release refunds on a percentage basis depending on how many applications are final. Row 27 – ICANN Org re: multiple comments Leadership Comments: -- 15.2 ICANN Org wants a Uniform Charge regardless of whether a registry uses a pre-evaluated RSP. Although more complex from billing, it should be relatively easy. If applicant checks box for using a Pre-evaluated RSP, the fee is less. -- 15.3 Historical Costs should not include any work not directly related to the next round. This means, for example, the NCAP project should not be billed to the next round, nor should any of the work of the CCT Review Team or the SubPro. Only true development costs, personnel costs, etc. once program is approved. -- 15.4 - Leadership believes that 15.5, 15.6 and 15.7 are "musts", and 15.8 is should and therefore the first three are part of the recommendation. -- 15.5 - WG is leaving it to ICANN/implementation as to who determines the "Floor". 15.5/6 Rationale - The WG is NOT saying that the Fee Floor should be the primary mechanism for enforcing the Bona Fide intention requirement. The WG does not believe the Fee Floor should be set at an artificially high amount. ACTION ITEM: Revise the Recommendation and Implementation Guidance to put 15.5, 15.6, and 15.7 directly into Recommendation 15.4. Leave 15.8 as the only Implementation Guidance for Recommendation 15.4. Topic 36: Base Registry Agreement<https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONz…> General Leadership Comment: Should be noted that ALL constituencies and SGs of GNSO (except IPC) either support the section or have no opinion. And IPC only objection is on negotiating exceptions to RPMs. Row 10 -- National Association of Boards of Pharmacy (NABP) re: apply to all subsequent TLDs; Category 1 Safeguards should apply to Registry Operators Leadership Comments: Leadership believes that this relates the fact that Safeguards only require provisions in a Registry-Registrar Agreement, but may not necessarily not require enforcement. Row 11 -- Swiss Government OFCOM re: RA operational criteria should be binding Leadership Comments: Do we want to take up this issue or is it a broader issue (like DNS Abuse) that if reviewed, should be done in a wholistic manner? Row 12 -- Intellectual Property Constituency (IPC) and PETILLION Law Firm re: “Accordingly, the IPC advocates for strict limitations on exemptions from the base RA, if any, which must not weaken existing rights protection mechanisms or public interest commitments otherwise present in the RA.” Leadership Comments: Does the WG want to make a statement saying that the, the working group does not believe that a consensus policy should be the subject of individual negotiations? Discussion: -- We didn’t put this out for public comment, but it’s not controversial. When we talked about flexibility in our recommendation we don’t think anyone thought this meant that someone could negotiate out of consensus policies. -- You could hypothetically have a situation where a registry wanted to negotiate out of a non-consensus policy, such as indemnity. ACTION ITEM: Revise the recommendation to make it clear that consensus policy should not be the subject of individual RA negotiations. Rows 17 and 29 – ALAC re: Enforce prohibition on fraudulent/deceptive practices in PIC or base RA/Answer to Community Question: Both PIC and RA Leadership Comments: PICDRP does allow in theory "both options", but ALAC does not like the requirement that someone needs to allege and show how they have been harmed by the action. Does WG want to address this? ACTION ITEM: Leadership will put the question out to the list for the WG to consider: “PICDRP does allow in theory "both options", but ALAC does not like the requirement that someone needs to allege and show how they have been harmed by the action. Does WG want to address this? Row 18 – ICANN Org re: Concern about custom RAs; clear rationale for exemptions; request clarity from WG on recommendation 36.3 and provisions; lack of clarity concerning aspects of recommendation 36.4. Leadership Comments: 1. A Rationale should be provided with an exemption request. This seems like a clarification. 2. ICANN Org wants to know why process was not clear. Response: WG found that although exemptions could be granted, few if any were granted and there was no criteria explaining what could and what could not be accepted. 3. Re - 36.4: As pointed out in the .Feedback case, ICANN did not believe it had the right to terminate the Agreement based on Fraud even when it was found by an independent party. Its not outside any organization's remit to cancel a contract based on fraud. If it wants to rely on a third party to make that determination, ICANN could always take the issue to Court for a declaratory judgment if it wants. 4. Re - Applicability to existing TLDs, that can be said of everything we add. But existing TLDs are not within our scope. Discussion: -- Question: From ICANN Org – “Is there an identified set of provisions that could be sought an exemption from versus others that were more fundamental and could not, or is it just open ended -- anybody who wants to propose an exemption or negotiate any provision can just send ICANN a request with a rationale, depending on which it is, those are very different processes to try to build.” Answer: Jeff Neuman -- Once we exclude the consensus policies I don't think that was intended to exclude any other provisions that could be requested or changes that can be requested. We're pretty much asking, ICANN can you tell us what that process is and be clear and transparent about it. The recommendation was not intended to just cover the provisions that already have the built-in exemption. It was intended for other provisions, but not intended to negotiate consensus policies. ACTION ITEM: Add language to Recommendation 36.3 that a clear rationale must accompany any exemption request.

1 0

Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 05 November 2020 at 03:00 UTC
by Andrea Glandon Nov. 5, 2020

Nov. 5, 2020

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

Post Call | New gTLD Subsequent Procedures Working Group | Monday , 02 November 2020 at 20:00 UTC
by Andrea Glandon Nov. 2, 2020

Nov. 2, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Monday, 02 November 2020 at 20:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/2YXzC> (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, 05 November 03:00 UTC
by Julie Hedlund Nov. 2, 2020

Nov. 2, 2020

Dear WG Members, Please find below the proposed agenda for the regular WG meeting on Thursday, 05 November 2020 at 03:00 UTC for 90 minutes. Note: For the schedule of the upcoming meeting topics, please see the Work Plan at: https://docs.google.com/spreadsheets/d/1ftMpOLkeLaJAHrUZ6dy1vTR6Ja_VGTKQ5Kn…. WG members are requested to review scheduled topics and comments prior to the meetings. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at: <https://docs.google.com/spreadsheets/d/1x9vbkFUNEAb55oEPCFRsdrDlowh06zIUBiU…> https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: -- Topic 15: Application Fees<https://docs.google.com/spreadsheets/d/1rOqfucddhWhYK8u3-O7IHg772BpjEIGhlmC…> -- Topic 36: Base Registry Agreement<https://docs.google.com/spreadsheets/d/1mkfwWZtyGAOdIbN3LsgNtDnVs6ehPmgrONz…> 1. 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>. Best, Julie Julie Hedlund, Policy Director

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 November 20:00 UTC
by Julie Hedlund Nov. 2, 2020

Nov. 2, 2020

Dear Working Group members, Please see below the notes from the working sessions on 02 November at 20: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/display/NGSPP/2020-11-02+New+gTLD+Subsequent+Pr…. Kind regards, Julie == Notes and Action Items: Action Items: a. Topic 20: Application Change Requests<https://docs.google.com/spreadsheets/d/1jS1m66MxbJRWhhQQTZBpyZnIuWm4ncpJFki…> Row 10 – IPC/ Row 11 – INTA/Row 12 – GBOC/Row 19 -- Brand Registry Group, Inc Re: .Brand TLD meeting criteria qualifies as .Brand TLD ACTION ITEM: Make it clear in the recommendation that changing the string to a descriptor word that is not in the trademark could qualify for Spec 13. Row 21 – ICANN Org Re: Terminology of Public Comment period; scope for changes; processing delays; other questions ACTION ITEM: Revise the term “comment period” to a term that is not associated with a public policy comment period. Re: The .Brand evaluation would need to occur during the application phase in order to allow .brands to change their strings. (a) Should ICANN just do them for the .brands that want to change their strings or (b) should there be a check box on the application to be considered to be a .brand during the actual initial evaluation? If (b), we would need to work in. ACTION ITEM: Clarify that .brands that want to change their strings will need to be evaluated. Row 21: RrSG Re: Only registries are responsible for complying with the PIC. ACTION ITEM: Move the RrSG comment to PICs. b. Topic 24: String Similarity Evaluations<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 13 – RySG/Row 14 – GoDaddy Registry/ Row 15 -- GMO Brights Consulting Inc./Row 24 – ICANN Board. Re: Opposes rules relying on "intended use" ; Supports allowing singular and plural versions for .Brands only/ Opposes rules relying on "intended use" Re: Opposes rules relying on "intended use" ACTION ITEM: Leadership will put the options on singulars and plurals into questions to the WG and post on the list. Row 24 -- ICANN Board Re: Include Recommendations and IG for objective evaluation criteria to determine "different intended uses", concerns about PICs and compliance with Bylaws. ACTION ITEM: Schedule call with Board liaisons and Co-Chairs. Come back to this one. c. Topic 35: Auctions<https://docs.google.com/spreadsheets/d/1kmZRLAsW6wlTyQ8LA3KhOQzU1UABL9zCPWw…> ACTION ITEM: Leadership sent a call for Volunteers for Small Team. Notes: 1. Updates to Statements of Interest: None provided. 2. Review draft Final Report Public Comments – to prepare see the links to the Public Comment Review Tool on the wiki at:https://community.icann.org/display/NGSPP/h.+Published+Draft+reports and review the following topics and comments: a. Topic 20: Application Change Requests<https://docs.google.com/spreadsheets/d/1jS1m66MxbJRWhhQQTZBpyZnIuWm4ncpJFki…> Row 10 – IPC/ Row 11 – INTA/Row 12 – GBOC/Row 19 -- Brand Registry Group, Inc Re: .Brand TLD meeting criteria qualifies as .Brand TLD Leadership Comments: JJN: I believe this was the intent of the recommendation, so if WG concurs, this is just to add clarity. Discussion: -- Question: If the .brand applicant decided to change the string, it would not have to be trademark? Answer: We said it had to be a trademark and descriptive word that matched their TM registration. Question: With the descriptor it would still qualify for Spec 13, even if it’s not the trademark. -- 'Trademarked term AND a descriptor word that is not in itself necessarily part of a Trade mark That is the proposed intention Yes @Jim an edge case of course. -- Kinda. The term would be taken from a statement of goods or services for a registration that they do have. -- So for example, .DELTA could be given to the airline and the faucet company could change its string to .DELTAFAUCETS but not .DELTACELLPHONE. -- Well that was the agreed intent (as is clear from the rationale), the point is that this should be expressed in the recommendation (or at a minimum in the implementation guidance) any not just in the rationale, where it might be overlooked years down the line. ACTION ITEM: Make it clear in the recommendation that a changing the string to a descriptor word that is not in the trademark could qualify for Spec 13. Row 14 – Thomas Barrett (Individual) Re: Allow applicants to revise string Row 15 – Swiss Government OFCOM Re: Existing criteria too vague Leadership Comments: Already resolved. Row 16 -- dotBERLIN GmbH & Co. KG and Hamburg Top-Level-Domain GmbH Re: Don't allow applicant to revise string Leadership Comments: Noted as only comment opposing .brands being allowed to change string. Row 17 -- InfoNetworks LLC Re: Concerns about impact of application changes on GAC early warning/third party objections Leadership Comments: Noted. No need to discuss. Row 20 – ICANN Board Re: Could increase cost and complexity. Leadership Comments: Noted. Row 21 – ICANN Org Re: Terminology of Public Comment period; scope for changes; processing delays; other questions Leadership Comments: -- Change "comment period' to something that is not associated with policy public comment period ACTION ITEM: Revise the term “comment period” to a term that is not associated with a public policy comment period. -- Re: Are there certain areas of application that should not be able to be changed (eg., answers relating to CPE) -- The .Brand evaluation would need to occur during the application phase in order to allow .brands to change their strings. (a) Should ICANN just do them for the .brands that want to change their strings or (b) should there be a check box on the application to be considered to be a .brand during the actual initial evaluation? If (b), we would need to work in process. Discussion: -- It does seem that there is momentum to identify .brands up front. -- Could just identify only the ones that are in contention, but could be useful to have them all identified up front. -- Question: Are there any other exceptions or privileges for .brands beside this? -- It is clear that .brands that want to change their strings will need to be evaluated that they qualify for Spec 13. This could be figured out in the IRT. -- We could just recognize that .brands that want to change their strings will need to be evaluated. How this will be done could be in the IRT. ACTION ITEM: Clarify that .brands that want to change their strings will need to be evaluated. -- Re: .brand string change must be in same language/script as the TLD string and in Trademark Registration provided. Re: 3. Criterion (e) states that a change to an applied-for string as a result of a contention set must “[comply] with all New gTLD Program requirements.” ICANN org understands this to mean that the new applied-for string would need to pass evaluation and objection phases as did the original applied-for string. Is this a correct understanding? -- Re: #3 - yes - change to the ICANN wording? -- #4 - Understood, but this is an exception to the exact textual match and will only be used in rare occasions. This is no more complex than or controversial than TM+ 50 rule, so there is experience in applying this. b. Topic 24: String Similarity Evaluations<https://docs.google.com/spreadsheets/d/1YJJDm9mdmSssXav1P08Uhw6Ofyp0KtfTX8Q…> Row 10 – Dotzon/Row 11 -- PETILLION Law Firm Re: Supports allowing singular/plural Leadership Comments: Discussed previously and resolved. Row 12 -- ZHOU, LiGuo (Individual) Re: Supports allowing singular and plural versions for .Brands Leadership Comments: We covered this already. Row 13 – RySG/Row 14 – GoDaddy Registry Re: Opposes rules relying on "intended use" ; Supports allowing singular and plural versions for .Brands only/ Opposes rules relying on "intended use" Leadership Comments: Registries support plural/singular prohibition, but only exception would be for brands and Code of conduct Exemptees, not for other applications. Does not support "intended use". Does WG want to revisit? Row 15 -- GMO Brights Consulting Inc. Re: Opposes rules relying on "intended use" Leadership Comments: Opposes any exemptions from plural/singular. Discussion: -- There are also some comments that do raise concerns about the “intended use” elements. Maybe consider them too? -- Given that this was only held by one group and some members in that group, we may decide not to consider it. But it may be worth discussion as it relates to the “intended use” elements. -- We are saying that plurals/singulars should not be allowed unless the applicant can show that they have different intended uses for the strings. But some commenters noted that it is difficult to enforce on intended use and may introduce unpredictability. -- SSAC did say that they had concerns about trying to figure out intended use and it is subjective. -- The three options are: 1) no plurals or singulars; 2) no plurals/singulars except .brand; 3) no plurals/singulars except with intended us. -- What harm are we trying to avoid and which of these is best tailors to avoid that harm without unintended consequences. -- The fact that intended use has popped up as an issue in comments throughout the draft recommendations means it’s probably something we need to address. -- Exemption for .brand make sense, as per the RySG. -- It’s hard to tell what harm there is because the 2012 round singulars and plurals are held by the same entities. -- Intended use can be enforced by contract/compliance. -- Almost comes back to contention set resolution. If they have the same intended purpose and they are in the same round, then they are in the same contention set. -- They don't have to be restricted per se, they simply have to require the registrants to abide by the intent, at risk of cancellation of the domain if they don't. -- Should intended use be in the voluntary commitments section given concerns about enforcing content regulation. -- Question: What happens if one applicant wants to stick to intended use and the other applicant wants to get in contention? which route is taken? Answer: The plural will go into contention regardless of what the singular wants to do – it depends on what it is in contention with. -- We could say that only .brands are allowed to have plurals and singulars – no intended use; or we can say no plurals and singulars. ACTION ITEM: Leadership will put the options on singulars and plurals into questions to the WG and post on the list. Row 17 -- Anthony Lee (Individual) Re: Consider complicated situation for ideograph character. Leadership Comments: May need to refer this to IDN PDP? Row 18: Dotzon Re: Study whether consumers are confused. Leadership Comments: Noted. But these studies can be overly expensive and not produce useful results as they are normally on a case-by-base basis. Row 19: PETILLION Law Firm Re: Consider possibility for single applicant to apply for singular and plural of same word. Leadership Comments: New issue? Row 20: ccNSO Council Re: Develop common approach between ccTLD and gTLD practice. Leadership Comments: We discussed and disagreed because of the fact that there are a number of other elements present in gTLD evaluations not in ccTLDs. Row 21: RrSG Re: Only registries are responsible for complying with the PIC. Leadership Comments: Move to PICs. ACTION ITEM: Move the RrSG comment to PICs. Row 24: ICANN Board Re: Include Recommendations and IG for objective evaluation criteria to determine "different intended uses", concerns about PICs and compliance with Bylaws. Leadership Comments: Relates to overarching issue of whether according to the Bylaws whether they can enforce compliance on intended use. ACTION ITEM: Schedule call with Board liaisons and Co-Chairs. Come back to this one. Row 25: ALAC Re: Concerns about conflicts with strings applied for in 2012 but unresolved/not delegated. Leadership Comments: If found to be similar they should be on hold until resolved. Raise with the WG. Row 26: ICANN Org Re: Multiple Issues Leadership Comments: -- First item -- noted. -- Re: Rec 24.3 -- check with the WG on plurals of acronym; if it is not in the dictionary then it would fall outside the rule, and therefore be allowed. -- On languages - we said it was singulars and plurals in the same language. -- On inflections -- considered and not covered intentionally. -- On intended use -- discussed that. -- On PICs -- this is noted. c. Topic 35: Auctions<https://docs.google.com/spreadsheets/d/1kmZRLAsW6wlTyQ8LA3KhOQzU1UABL9zCPWw…> -- There are very few commenters who support this as is. -- There are diverse responses from those who don’t support. ACTION ITEM: Leadership sent a call for Volunteers for Small Team: We would like to put together a small group to work on seeing if there is a way to take into consideration all of the comments to come up with a proposed solution that could address most of the comments while also keeping in mind the questions posed by the Board. We would like to give 14 days for this group to see if they can come up with improvements to the recommendations. If they can come up with a proposal, that will then be brought back to the full WG at that point in time. Volunteers on the Call: Paul McGrady, Donna Austin, Jim Prendergast. From Jeff Neuman’s email: http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-November/003565.html: GENERAL OBSERVATIONS FROM COMMENTS Some observations are as follows: 1. The only complete support was voiced by a few individuals. 2. The IPC viewed the recommendations as not ideal, but could in theory accept. But that said they are not in favor of using sealed bids for brands (See Below). 3. A number of groups has no opinion, some of whom however, stated that that was because their own members had differing opinions. 1. ICANN Board Comments: * The Board encourages the PDP WG to provide a rationale why the resolution of contention sets should not be conducted in a way such that any net proceeds would benefit the global Internet community rather than other competing applicants. * If private resolution is allowed, they would like to know why we only bring some of the aspects of the private resolution into the program (i.e., some transparency requirements, intent, etc.). * Wants to know if promises/statements in support of the notion of “bona fide” intent can be changed at a later time or is it just a promise/statement that covers that specific moment and time. * Concerned about subjectively trying to determine the state of mind of applicants – Wants the WG “to provide a clear problem statement of what types of behavior or abuse the requirement of bona fide applications is meant to address; then could then use such a statement to provide objective criteria for assessing the bona fide nature of an application. * Wants us to confirm that a statement of bona fide intent is required of ALL applications as opposed to just those in auctions. – Leadership believes intent was for ALL applications. * Board provides a hypothetical of an applicant that applies for 20 TLDs, but only intends on operating 5 of them. i. Does that mean that for the 15 they don’t take that they were not made with a bona fide intent? ii. Does ICANN need to get all investors and those with controlling interests in every application to certify intent. * To SUM UP: Wants more Objectivity. 1. After those comments, the rest of the comments are all over the place. I don’t mean that in a negative way, its just that they cover the wide range of the spectrum from: * Private Resolution of Contention Sets i. NCSG does not believe that parties should be able to pay each other for withdrawing apps – Not in Favor of Private Auctions ii. Galway Strategy Group – cites Board comments and believes private auctions will cause reputational harm to ICANN. iii. Article 19 does not support private auctions iv. ALAC concerned about gaming the process through private auctions and thus does not support them. v. GoDaddy not concerned with issues raised on private auction * Mechanism of the Last Resort Auction i. BRG (Brand Registry Group), BC and IPC do not supporting sealed bids ii. BC and ALAC prefer Vickrey Auction iii. Commercial and Noncommercial entities should not be in auction with each other – GAC iv. Concerned that the only way to change or withdraw their bid is to withdraw the entire application - RySG * “Bona Fide” Intentions i. Standard too vague – Article 19 ii. Criteria provided are subjective and can be gamed (thus not predictable) – BC iii. Wants both ICANN and Evaluators to ask CQs on Bona Fide intentions – GoDaddy iv. Not sufficiently defined; neither are the punitive measures; Does not believe this addresses Board concerns - GAC v. Does not believe that bona fide intent is incredibly difficult to quantify – RySG vi. Bona Fide requirements are completely unenforceable – Galway Strategy Group vii. Too Subjective – ALAC **I have not included ICANN Org comments in this summary because in general they do not take a view on these issues, but rather ask detailed questions on implementing the bona fide intention aspect and whether this needs a specific evaluation, etc. In other words, if we continue down the ‘Bona Fide” Intention path, then we will need to address these questions (or refer them to the IRT_).

1 0

Auctions Discussion (Topic 35)
by Jeff Neuman Nov. 2, 2020

Nov. 2, 2020

All, In preparation for Monday's Working Group call, you have probably noticed that the topic of Auctions / Mechanisms of Last resort (Topic 35: "Auctions" for short) is listed as the last topic of discussion. Leadership had a call on Friday (we now have 2 calls per week, in addition to the full working group 2 calls per week so that we can be prepared for the meetings. During that call, Leadership reviewed each of the comments on Auctions. How to Move Forward: Below you see my summary of the comments - which should not substitute for your review of the comments. We would like to put together a small group to work on seeing if there is a way to take into consideration all of the comments to come up with a proposed solution that could address most of the comments while also keeping in mind the questions posed by the Board. We would like to give 14 days for this group to see if they can come up with improvements to the recommendations. If they can come up with a proposal, that will then be brought back to the full WG at that point in time. Therefore, we are not inclined to cover Auctions in great detail on the call. **Word of Caution: For those that believe that if we cannot come to an agreement on this issue, that the ICANN Board will just adopt the status quo (namely, the way it was implemented in 2012), I would STRONGLY encourage you to read their comments - especially the first comment on asking the Working Group in essence to justify why the WG believes that funds generated from the resolution of contention sets should not be used to "benefit the global Internet community rather than competing applicants." Leadership believes that this is an implicit message from the Board that unless we can come up with a good reason to allow private auctions, it is not something that they look upon with favor. We can be wrong of course, but this is what we read into their comments. GENERAL OBSERVATIONS FROM COMMENTS Some observations are as follows: 1. The only complete support was voiced by a few individuals. 2. The IPC viewed the recommendations as not ideal, but could in theory accept. But that said they are not in favor of using sealed bids for brands (See Below). 3. A number of groups has no opinion, some of whom however, stated that that was because their own members had differing opinions. 1. ICANN Board Comments: * The Board encourages the PDP WG to provide a rationale why the resolution of contention sets should not be conducted in a way such that any net proceeds would benefit the global Internet community rather than other competing applicants. * If private resolution is allowed, they would like to know why we only bring some of the aspects of the private resolution into the program (i.e., some transparency requirements, intent, etc.). * Wants to know if promises/statements in support of the notion of "bona fide" intent can be changed at a later time or is it just a promise/statement that covers that specific moment and time. * Concerned about subjectively trying to determine the state of mind of applicants - Wants the WG "to provide a clear problem statement of what types of behavior or abuse the requirement of bona fide applications is meant to address; then could then use such a statement to provide objective criteria for assessing the bona fide nature of an application. * Wants us to confirm that a statement of bona fide intent is required of ALL applications as opposed to just those in auctions. - Leadership believes intent was for ALL applications. * Board provides a hypothetical of an applicant that applies for 20 TLDs, but only intends on operating 5 of them. i. Does that mean that for the 15 they don't take that they were not made with a bona fide intent? ii. Does ICANN need to get all investors and those with controlling interests in every application to certify intent. * To SUM UP: Wants more Objectivity. 1. After those comments, the rest of the comments are all over the place. I don't mean that in a negative way, its just that they cover the wide range of the spectrum from: * Private Resolution of Contention Sets i. NCSG does not believe that parties should be able to pay each other for withdrawing apps - Not in Favor of Private Auctions ii. Galway Strategy Group - cites Board comments and believes private auctions will cause reputational harm to ICANN. iii. Article 19 does not support private auctions iv. ALAC concerned about gaming the process through private auctions and thus does not support them. v. GoDaddy not concerned with issues raised on private auction * Mechanism of the Last Resort Auction i. BRG (Brand Registry Group), BC and IPC do not supporting sealed bids ii. BC and ALAC prefer Vickrey Auction iii. Commercial and Noncommercial entities should not be in auction with each other - GAC iv. Concerned that the only way to change or withdraw their bid is to withdraw the entire application - RySG * "Bona Fide" Intentions i. Standard too vague - Article 19 ii. Criteria provided are subjective and can be gamed (thus not predictable) - BC iii. Wants both ICANN and Evaluators to ask CQs on Bona Fide intentions - GoDaddy iv. Not sufficiently defined; neither are the punitive measures; Does not believe this addresses Board concerns - GAC v. Does not believe that bona fide intent is incredibly difficult to quantify - RySG vi. Bona Fide requirements are completely unenforceable - Galway Strategy Group vii. Too Subjective - ALAC **I have not included ICANN Org comments in this summary because in general they do not take a view on these issues, but rather ask detailed questions on implementing the bona fide intention aspect and whether this needs a specific evaluation, etc. In other words, if we continue down the 'Bona Fide" Intention path, then we will need to address these questions (or refer them to the IRT_). [cid:image003.png@01D6B091.89302A70] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com

2 1

ICANN's Ability to Act (Without Using Predictability Model)
by Jeff Neuman Nov. 2, 2020

Nov. 2, 2020

All. On the last cast, towards the end of the call, when dealing with Systems (Topic 14)<https://docs.google.com/spreadsheets/d/1QY2ChMLEvTNIumpKl65XTVcSYNMaUhucE1Y…>, ICANN Org made the following Comment: 1. Our Recommendation from Draft Final Report: ""in service of transparency, once the systems are in use, ICANN should communicate any system changes that may impact applicants or the application process. Processes described under Topic 2: Predictability should be followed." 1. ICANN Org Comment: "ICANN org would like to note that for issues related to security and stability, as well as the proper functioning of systems, ICANN org cannot be constrained to the processes outlined under Topic 2. ICANN org will need to respond rapidly to any issue that may fall under these categories." Discussion - 1. Under Predictability (Topic 2)<https://docs.google.com/spreadsheets/d/11HrbnRk2Sf5FvdOuynJyXfkLrzQAD1jkYpR…>, another version of this came up and has been discussed in the last email exchange to which Donna, Anne and I responded. In that discussion, ICANN said that it needed "the right to act in emergency situations, including taking actions in line with the Board or officers' fiduciary responsibilities." 1. Donna, Anne and I agreed that in true emergencies, ICANN does need to be able to act in emergency situations. We also agreed that it was critical that ICANN be transparent when it acts, and that Board would need to inform the SPIRT leadership within [X] hours of doing so. If the action results in a halt to the program or is likely to encounter considerable delays for applicants the Board would need to provide a communication to affected applicants immediately. 2. I had suggested narrowing the scope of what constitutes emergencies, but Donna and Anne did not necessarily think that would be possible. 1. Here, under Systems<https://docs.google.com/spreadsheets/d/1QY2ChMLEvTNIumpKl65XTVcSYNMaUhucE1Y…>, ICANN Org has broadened this to not just include "emergency situations", but also any issues "related to security and stability as well as the proper functioning of systems." 1. This is a much more expansive list of situations where ICANN would not have to use the Predictability Model. 2. In line with the above, it certainly makes sense that any issues that created an emergency situation with respect to the systems, should allow ICANN to act quickly without the use of the Predictability Model. I could see this including things like responding to a data breach or other imminent security vulnerability. We could also see responding to other forms of Cyberattack, DDoS, etc. Question: However, is the Working Group concerned that the language "related to" and "Proper functioning of systems' is too wide an opening to allow ICANN to always make changes without using the Predictability Model / SPIRT? For example, one could argue that the creation of Digital Archery was an act related to security and stability. Changing the Pre Delegation Testing Requirements could easily be related to security and stability, etc. Jeff Neuman Recommendation: We should be consistent in setting out when ICANN Org / Board should be excused from using the Predictability Model to act. Certainly Emergency Situations should be covered with the Transparency requirements discussed in #1 above. Perhaps stating something like: "With respect to its operation and administration of the systems, ICANN must retain the ability to act in emergency situations, including those where immediate action is necessary to remedy any service interruption, interference, service obstruction or other imminent threat to the systems; provided that ICANN provides notice to all impacted users of the affected system(s) as soon as reasonably practicable after such action has been taken along, and if such action involves any downtime to the system(s), it shall provide updates to impacted users as to when normal service can be restored." Thoughts? [cid:image003.png@01D6AEF0.2589CBE0] Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff(a)jjnsolutions.com<mailto:jeff@jjnsolutions.com> http://jjnsolutions.com

4 4