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

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

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 14 April at 03:00 UTC
by Julie Hedlund April 13, 2020

April 13, 2020

Dear all, Please find below the proposed agenda for the call on Tuesday, 14 April 2020 at 03:00 UTC for 90 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.10.1 Base Registry Agreement, Section C New Issues, start on page 77 * 2.4 Application Change Requests, page 79 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

3 2

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

April 9, 2020

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

April 9, 2020

Dear Working Group members, Please see below the notes from the meeting on 09 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-09+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: 2.8.1 Objections [All Sub-Sections Except GAC Early Warning and GAC Advice - Not Yet Completed] c. New issues raised in deliberations since publication of the Initial Report, if applicable. String Confusion Objection: ACTION ITEM: Make sure there is time in the Work Plan for the WG to discuss the GAC’s Advice in Category 1 and develop a response to the GAC’s Advice and how to address highly regulated or sensitive strings. Note that the WG should also look at the morality and public order objection. b. 2.10.1 Base Registry Agreement Recommendation xx: ACTION ITEM: Change the text based on text in brackets and strikethrough: “Recommendation xx: There must be a clearer, structured, and efficient method for [applying and negotiating for] obtaining exemptions to certain requirements [provisions] of the [Base] Registry Agreement, [subject to minimum 30-day public comment period] which allows ICANN [Org] to consider unique aspects of registry operators and TLD strings, as well as provides ICANN [Org] the ability to accommodate a rapidly changing marketplace. [Could encourage applicants to identify requests to amend RA at the time of application submission.]” Recommendation xx: ACTION ITEM: Change the text based on strikethrough: “Recommendation xx: ICANN must add a contractual provision [in the form of a mandatory Public Interest Commitment] stating that the Registry Operator will not engage in fraudulent or deceptive practices.” Formulate a question for the public comment period about what form this should take (rep, warranty, PIC, etc.). Notes: 1. Updates to Statements of Interest: -- Kristine Dorrain is switching to a different role at Amazon and so she will not be representing Amazon on this PDP WG. 2. Discussion of Final Report Topics: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… a. 2.8.1 Objections [All Sub-Sections Except GAC Early Warning and GAC Advice - Not Yet Completed], continue discussion on page 73 c. New issues raised in deliberations since publication of the Initial Report, if applicable. String Confusion Objection: Proposal that there should be grounds for a String Confusion Objection if an applied-for string is an exact translation of an existing string that is in a highly regulated sector, and the applied-for string would not employ the same safeguards as the existing string, subject to the applicant’s governing law. Discussion: -- Options discussed on the last call 1) whether to formally adopt some level of PICs that would have requirements built into the contract (GAC Category 1) so there wouldn’t be an objection; 2) not adopt GAC Category 1 and have a dispute process where you allow a dispute to be filed based on the fact that it’s an exact translation and you don’t have the same requirements that others have, or 3) no recommendation either way. -- In comments received, suggestion that with the potential for confusion from the end user the verified/restricted TLD should build in assurance that a registrant is properly credentialed, such as in medicine. If you have a word similar in meaning then an end user might assume that the same restriction/credentials would apply. Makes sense that it could be standing for objection. Not sure that would take the place of having GAC Category 1 formally adopted. -- Reluctant to accept the clause, “subject to the applicant’s governing law”. Added that text because if you can file an objection that an applicant doesn’t implement all of the safeguards the registry currently has because some are contrary to the applicant’s applicable laws. -- Suggest changing it to “subject to applicable laws”. -- Yes, to applicable law, not just the applicant's applicable to where the registrant is based and to where it does business. -- This has to do with consumer confusion, but not about the string. It is about the business practice. -- Not sure the way to do this is through the String Confusion Objection. -- We are discussing this because it did receive quite a bit of support from commenters, but there was opposition from the Registry SG, Registrar SG, and .brand registries. -- If we go forward with this then we have to recognize that we are massively changing string confusion, or need to find another way to deal with it. -- The reason it is “applicants governing law” is because applying all law would eliminate the ability for these strings in different languages to exist. -- Isn’t the issue not just a countries regulation of pharmacies, but it is a global issue that the string represents a highly regulated industry -- isn’t this something for the GAC to get involved in, or in addition to an objection, such as having standing for the GAC to join in. -- Think we can agree that this doesn’t fit into the String Confusion Objection and that this may involve other parties. This also should be connected to the whole notion of Category 1 in general. We need to reserve time to talk about how we address strings in highly regulated industries. So when we talk about Category 1 in the work plan we also should talk about this issue. -- Has anyone looked at the morality and public order objection? ACTION ITEM: Make sure there is time in the Work Plan for the WG to discuss the GAC’s Advice in Category 1 and develop a response to the GAC’s Advice and how to address highly regulated or sensitive strings. Note that the WG should also look at the morality and public order objection. b. 2.10.1 Base Registry Agreement, page 74 Recommendation xx: There must be a clearer, structured, and efficient method for [applying and negotiating for] [obtaining] exemptions to certain requirements [provisions] of the [Base] Registry Agreement, [subject to minimum 30-day public comment period] which allows ICANN [Org] to consider unique aspects of registry operators and TLD strings, as well as provides ICANN [Org] the ability to accommodate a rapidly changing marketplace. [Could encourage applicants to identify requests to amend RA at the time of application submission.] Discussion: -- Don’t understand the need for this recommendation -- to allow for exemptions. This is way to broadly defined. -- Wondering if "applying for exemptions" or "negotiating for exemptions" rather than "obtaining exemptions"  would be better. Also clarify what we mean by “ICANN”. -- Some TLDs couldn’t launch because they couldn’t get registrars, such as in South America. There are other things that have come up where applicants have wanted to make changes in the contract, but there was no way to do it. -- The biggest one was Specification 13 that is an exemption of certain requirements of the Registry Agreement. That is why this recommendation is so important. -- Isn’t Specification 13 the exception that proves the rule? Seems like this undermines everything we’ve done. -- Without a structured and clear process it can take years to make a commonsense change. -- Question: How is this different to an Application Change Request? Answer: This is after the application and isn’t changing part of that application; it is a change request but after the application has been approved. -- One way to handle this is to put this in the public portion of the application -- that the applicant doesn’t want to adhere to X provision of the RA. We should recommend that this is in the public portion of the application. -- One possibility could be a question in the application asking whether the registry plans to ask for any changes to the Registry Agreement and then explain them. -- The .brand perspective in the last round was that you couldn’t mention your intention without revealing your business plan. It made sense to have multiple .brands approaching ICANN Org to negotiate and not on an individual basis to get Specification 13. -- Don’t think we should be requiring applicants to pre-seek exemptions in their applications. -- If there is a known change that the applicant wants to make to the RA, think we should ask them to make that clear in the application, but only if it is known when the application is submitted. -- Important to note that ICANN came out with a new base RA after the applications were in and some were approved. We hope we are guarding against that happening again. ACTION ITEM: Change the text based on text in brackets and strikethrough: “Recommendation xx: There must be a clearer, structured, and efficient method for [applying and negotiating for] obtaining exemptions to certain requirements [provisions] of the [Base] Registry Agreement, [subject to minimum 30-day public comment period] which allows ICANN [Org] to consider unique aspects of registry operators and TLD strings, as well as provides ICANN [Org] the ability to accommodate a rapidly changing marketplace. [Could encourage applicants to identify requests to amend RA at the time of application submission.]” Recommendation xx: ICANN must add a contractual provision [in the form of a mandatory Public Interest Commitment] stating that the Registry Operator will not engage in fraudulent or deceptive practices. Discussion: -- We need to decide if this is a PIC or this is just a stand-alone provision in the Registry Agreement. If a "PIC", then it can be enforced by a third party in addition to ICANN. -- This is too broad. No one would sign up to such a contractual requirement. -- Question: In a situation where there is a PICDRP where the panelists found that there was fraud and ICANN Org said we can’t do anything since fraud isn’t a basis to go after a registry. How would we address that? Answer: We could state that registries must comply with applicable law and if they were found not to be in compliance then they would be out of compliance. -- But the RA doesn’t say which law applies. It’s the law that governs the parties -- ICANN and where the registry is located. -- You can say what is the applicable law for those parties. -- Add “under applicable law”? -- We aren’t recommending changes to the Base RA but we can recommend a PIC. -- Fraudulent and deceptive practices is specific. -- So the issue here is that Spec 11 Section 3(a) already requires ROs to require in their RRAs that registrars prohibit fraudulent and deceptive practices (hence the PIC hook) but such provision was found not to apply to the RO itself. So if "fraudulent and deceptive practices" is specific enough in the existing Spec 11 language it should be specific enough to apply to the RO itself. -- Suggest we could say, “fraudulent or deceptive practices under applicable law”. -- We can mirror the language already in Spec 11 3(a) which is already bound by applicable law. Just make it clear that the prohibited activities apply to the RO itself, not just downstream. -- Take out “in the form of a mandatory PIC”. Ask a question to the community as to whether it should be a warranty or a PIC. ACTION ITEM: Change the text based on strikethrough: “Recommendation xx: ICANN must add a contractual provision [in the form of a mandatory Public Interest Commitment] stating that the Registry Operator will not engage in fraudulent or deceptive practices.” Formulate a question for the public comment period about what form this should take (rep, warranty, PIC, etc.). 3. AOB: Letter from GAC. -- GAC notes that the WG is moving more quickly than the timeline stated in the Project Change Request in moving up the publication of the Draft Final Report. -- Concern that there won’t be enough time for the GAC to participate and provide input before publication. -- The Project Change Request noted that this was the worst case scenario and that the WG would try to work more quickly. -- We did engage the GAC as planned during ICANN67 -- the revised Work Plan didn’t change that. -- Maybe there’s a way that we can have some issues still be open since there was specific discussion from the GAC that they weren’t commenting at ICANN67 and were waiting for ICANN68. -- But ICANN68 is not going to be a face-to-face meeting. -- WG Leadership will discuss the letter and how to respond.

1 0

FW: GAC Chair letter to Subpro PDP WG Co-Chairs: GAC Leadership Input on Subpro PDP WG Timeline
by Jeff Neuman April 9, 2020

April 9, 2020

FYI Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> From: Benedetta Rossi <benedetta.rossi(a)icann.org> Sent: Thursday, April 9, 2020 11:33 AM To: Cheryl Langdon-Orr <langdonorr(a)gmail.com>; Jeff Neuman <jeff.neuman(a)comlaude.com> Cc: gac-leadership(a)icann.org; Steve Chan <steve.chan(a)icann.org>; Emily Barabas <emily.barabas(a)icann.org>; Julie Hedlund <julie.hedlund(a)icann.org> Subject: GAC Chair letter to Subpro PDP WG Co-Chairs: GAC Leadership Input on Subpro PDP WG Timeline Dear Cheryl and Jeff, I hope this email finds you well. Please find attached the letter from the GAC Chair, Manal Ismail, to you both as Subsequent Procedures for new gTLDs Co-Chairs, relative to GAC leadership input on the timeline of the PDP WG. The letter can also be found on the GAC website correspondence page<https://gac.icann.org/contentMigrated/gac-leadership-concerns-regarding-cha…>. Thank you. Kind regards, Benedetta -- Benedetta Rossi | GAC Advice and Policy Support Manager benedetta.rossi(a)icann.org<mailto:benedetta.rossi@icann.org> | +32.491.90.42.50 ICANN | Internet Corporation for Assigned Names and Numbers ________________________________ 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>

1 0

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

April 8, 2020

Dear all, Please find below the proposed agenda for the call on Thursday, 09 April 2020 at 20:00 UTC for 90 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.1 Objections [All Sub-Sections Except GAC Early Warning and GAC Advice - Not Yet Completed], continue discussion on page 73 * 2.10.1 Base Registry Agreement, page 74 * 2.4 Application Change Requests, TBD 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

Post Call / New gTLD Subsequent Procedures Working Group call on Monday, 06 April 2020 at 15:00 UTC
by Michelle DeSmyter April 6, 2020

April 6, 2020

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

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 April 1500 UTC
by Julie Hedlund April 6, 2020

April 6, 2020

Dear Working Group members, Please see below the notes from the meeting on 06 April at 1500 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-06+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: Affirmation xx (rationale 1): ACTION ITEM: Clarify that it was part of the compromise in Work Track 5 to recognize that some GAC procedures were available even if specific objections were not established. ACTION ITEM: Change the last sentence to, “The Working Group further affirms that the IO should continue to be given the opportunityin a position to file Community and/or Limited Public Interest objections when doing so serves the best interests of the public who use the global Internet, as was the case in the 2012 round. Recommendation xx (rationale 2): ACTION ITEM: Change to “This process will [must] serve as a supplement to the existing Code of Conduct Guidelines for Panelists and Conflict of Interest Guidelines for Panelists. ACTION ITEM: Make a note that when we discuss appeals we should consider what we may want to recommend if the IO has a conflict of interest. ACTION ITEM: Draft an overarching section on conflicts of interest. ACTION ITEM: Add links to COI policies of IO and evaluators. Implementation Guidance xx (rationale 4): ACTION ITEM: Change “must” to “should” here and in the other IGs, and consider alternative language in brackets: Information about fees and refunds for the dispute resolution processes must be readily available [prior to the end of the application submission period.] [prior to the commencement/opening of the application submission period.] [at the time of publication of the Applicant Guidebook.] Recommendation xx (rationale 6): ACTION ITEM: Consider adding reference to public comment as part of the Application Change Request -- see comments on Global Public Interest. ACTION ITEM: Add a footnote about standing in general categories. ACTION ITEM: Add text in brackets “All [these] amendments and RVCs submitted after the application submission date shall be considered Application Changes and be subject to the recommendations set forth in Section xx Application Changes Requests.” Implementation Guidance xx (rationale 7): Re: “The same panel would review all documentation associated with the objection. Each response would be reviewed on its own merits to determine whether the relevant applied-for gTLD was confusingly similar.” ACTION ITEM: Delete “to determine whether the relevant applied-for gTLD was confusingly similar.” Re: The panel would issue a single determination that identified which applications would be in contention. Any outcome that resulted in indirect contention would be explained as part of the DRSP’s determination. ACTION ITEM: Add a footnote defining direct and indirect contention. RE: Possible additional Recommendations/Implementation Guidance: Reduce costs associated with filing [community objections] [all objections]. ACTION ITEM: Find out if ICANN gathered information from the ICC on the nature of their charges. c. New issues raised in deliberations since publication of the Initial Report, if applicable. String Confusion Objection: ACTION ITEM: Add bracketed text in “Proposal that there should be grounds for a String Confusion Objection if an applied-for string is [an] exact translation of an existing string that is in a highly regulated sector, and the applied-for string would not employ the same safeguards as the existing string[, subject to the applicant’s governing law].” 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.1 Objections [All Sub-Sections Except GAC Early Warning and GAC Advice - Not Yet Completed], continue discussion on page 68, Affirmation xx with modification (rationale 1) Affirmation xx (rationale 1): The Working Group affirms that the role of the Independent Objector (IO) should exist in subsequent procedures as it did in the 2012 round, subject to the changes introduced from other recommendations, and the Implementation Guidance below. The Working Group further affirms that the IO should continue to be in a position to file Community and/or Limited Public Interest objections when doing so serves the best interests of the public who use the global Internet, as was the case in the 2012 round. ACTION ITEM: Clarify that it was part of the compromise in Work Track 5 to recognize that some GAC procedures were available even if specific objections were not established. ACTION ITEM: Change the last sentence to, “The Working Group further affirms that the IO should continue to be given the opportunityin a position to file Community and/or Limited Public Interest objections when doing so serves the best interests of the public who use the global Internet, as was the case in the 2012 round. Recommendation xx (rationale 2): ICANN must develop a transparent process to ensure that Dispute Resolution Service Provider panelists, Independent Objectors, and third-party providers evaluating applications are free from conflicts of interest. This process will serve as a supplement to the existing Code of Conduct Guidelines for Panelists and Conflict of Interest Guidelines for Panelists. Discussion: -- Re: Suggestion to include the recommendation in all sections where it may apply. Think about the sections to which this is relevant. Need to look at all possible sections and see if they make sense -- repeating in 5 or more sections. Alternatively, have an overarching issue about conflict of interest across the program, and include with other overarching recommendations. -- What do we mean by “This process will serve”? Change to “must”. -- As to IO, there should be an appeal on the conflict of interest issue prior to that Objection proceeding. Who should hear the appeal? Maybe whoever will be enforcing the decision, such as the ICANN Board. -- There also is the question of who enforces the conflict of interest with an IO. -- Need to make sure all of the players in the process are known. So extend the concept of conflict of interest to additional categories. -- Legal conflicts of interest do not refer to financial interests or nepotism. Those are Board of Director conflict principles. -- The point was that the same language may not apply to every section on this question of appealing a conflict of interest decision. Nevertheless we could draft one overarching section if we make sure we distinguish the proceeding types in this regard. ACTION ITEM: Change to “This process will [must] serve as a supplement to the existing Code of Conduct Guidelines for Panelists and Conflict of Interest Guidelines for Panelists. ACTION ITEM: Make a note that when we discuss appeals we should consider what we may want to recommend if the IO has a conflict of interest. ACTION ITEM: Draft an overarching section on conflicts of interest. ACTION ITEM: Add links to COI policies of IO and evaluators. Implementation Guidance xx (rationale 4):. Information about fees and refunds for the dispute resolution processes must be readily available prior to the end of the application submission period. Discussion: -- Talking about the fees to file a dispute. -- In filing an application the biggest question is how much are the fees. -- This is not the first time dispute providers are being enlisted. we are not starting from scratch here so why added delays in establishing fees. -- This is part of a larger conversation. Think more about that -- about all the things we are requiring to be out at the time of the launch. -- Given the cost “variability” that many suffered in the 2012 round I believe it is prudent to make best efforts here to be as transparent as possible - if nothing more than to rein in the cost inflation that was allowed to happen in the 2012 round. -- We should strive for an early stage - and state that finalization be delayed. -- Lawyers will definitely be asked what are the chances of drawing an Objection and what would it cost. Will be very awkward to say "I don't know what it will cost." From an applicant's point of view, ICANN has had 8 years to nail down this detail. -- Publication with Guidebook gives the most predictability. ACTION ITEM: Change “must” to “should” and consider alternative language in brackets: “Information about fees and refunds for the dispute resolution processes must be readily available [prior to the end of the application submission period.] [prior to the commencement/opening of the application submission period.] [at the time of publication of the Applicant Guidebook.]” Implementation Guidance xx (rationale 4):. [Prior to the launch of the application submission period], to the extent that dispute resolution panelists provide other guidance, processes and/or sources of information to assist them with processing and making decisions, such information must be made publicly available and easily found, either on their respective websites or preferably, in a central location. Discussion: -- Question: Is this meaningful? Answer: This was meant to be a catchall -- all under the heading of transparency. Anything else that could be used to make a decision needs to be known. -- Question: The word “processes” is problematic. What processes are we talking about? Could we delete the word “processes”? Recommendation xx (rationale 6): Applicants must have the opportunity to amend an application or add Registry Voluntary Commitments in response to concerns raised in an objection. All amendments and RVCs submitted after the application submission date shall be considered Application Changes and be subject to the recommendations set forth in Section xx Application Changes Requests. Implementation Guidance xx (rationale 6). To the extent that RVCs are used to resolve an objection either (a) as a settlement between the objector(s) and the applicant(s) or (b) as a remedy ordered by an applicable dispute panelist, those RVCs must be included in the applicable Applicant(s) Registry Agreement(s) as binding contractual commitments enforceable by ICANN through the PICDRP. Discussion: -- Staff note: Note that the following recommendation is currently included under Global Public Interest: "ICANN must allow applicants to submit Registry Voluntary Commitments (RVCs)(previously called voluntary PICs) in subsequent rounds in their applications and/or to respond to public comments, objections, GAC Early Warnings, and/or GAC Consensus Advice. Applicants must be able to submit RVCs at any time prior to the execution of a Registry Agreement; provided, however, that all RVCs submitted after the application submission date shall be considered Application Changes and be subject to the recommendations set forth in Section xx Application Changes Requests." Do we want to keep both? Also, should we specify how an application may be amended? -- That we added the text “including but not limited to public comments” after “Application Changes”. This was included in a different section. Or we can add a footnote that explains what are Application Changes. That was in Global Public Interest. ACTION ITEM: Consider adding reference to public comment as part of the Application Change Request -- see comments on Global Public Interest. ACTION ITEM: Add a footnote about standing in general categories. ACTION ITEM: Add text in brackets “All [these] amendments and RVCs submitted after the application submission date shall be considered Application Changes and be subject to the recommendations set forth in Section xx Application Changes Requests.” Implementation Guidance xx (rationale 7): Re: “The same panel would review all documentation associated with the objection. Each response would be reviewed on its own merits to determine whether the relevant applied-for gTLD was confusingly similar.” ACTION ITEM: Delete “to determine whether the relevant applied-for gTLD was confusingly similar.” Re: “The panel would issue a single determination that identified which applications would be in contention. Any outcome that resulted in indirect contention would be explained as part of the DRSP’s determination.” ACTION ITEM: Add a footnote defining direct and indirect contention. Possible additional Recommendations/Implementation Guidance: * Reduce costs associated with filing [community objections] [all objections]. * Reduce barriers to filing objections: time, expertise required, and awareness of the opportunity to file. Discussion: -- People could be asked to work pro bono. -- Question: Do we have any information that was shared by the ICC on their process? -- Agree we need competitive quotes. No on the issue of "caps" - will limit providers and competition among providers. -- We need to qualify more than one provider in each category of Objection. That way there are choices for Objectors based on the fees established by the provider. ACTION ITEM: Find out if ICANN gathered information from the ICC on the nature of their charges. c. New issues raised in deliberations since publication of the Initial Report, if applicable. String Confusion Objection: Re: “Proposal that there should be grounds for a String Confusion Objection if an applied-for string is an exact translation of an existing string that is in a highly regulated sector, and the applied-for string would not employ the same safeguards as the existing string.” Discussion: -- Example is translation of .pharmacy translation into Russian. -- What are we trying to get to? We should add something that the same safeguards subject to the applicant’s governing law. We are not trying to create universal law. We just want to make sure that users don’t think one is regulated and one isn’t. -- Questions: Why limited to “highly regulated sector”? And what do we mean by “exact translation”? Do we mean linguistic translation? Answer: In the example .pharmacy would be .pharmacia in an exact translation. We are saying this doesn’t necessarily apply to all strings. -- Is it a translation from English into Russian/Cyrillic? -- Need to think about how the translated string will be used. -- Keep this bracketed and keep the connection to GAC Category 1 Strings. ACTION ITEM: Add bracketed text in “Proposal that there should be grounds for a String Confusion Objection if an applied-for string is [an] exact translation of an existing string that is in a highly regulated sector, and the applied-for string would not employ the same safeguards as the existing string[, subject to the applicant’s governing law].” String Confusion Objection: “Discussion about the potential for extending the String Confusion Objection in other ways -- for example, synonyms for verified TLDs, homonyms -- potential tie in to CCT-RT recommendation 35 is mentioned in the CCT-RT rec summary spreadsheet: https://docs.google.com/spreadsheets/d/1PGV5_nMafLWtSHyCGdr-b8eqoJj9B8YKBSh… Discussion: -- CCT-RT -- was Recommendation 35 something for the WG to consider? Yes, “The Subsequent Procedures PDP should consider adopting new policies to avoid the potential for inconsistent results in string confusion objections. In particular, the PDP should consider the following possibilities…” -- It does make sense to include synonyms and potentially homonyms as standing for a String Confusion Objection. -- We will connect this to GAC Category 1 Strings -- if both were required to have Category 1 restriction would that make there less need for an objection?

1 0