Thanks Jim for the clarification. Kind regards, Julie From: Jim Prendergast <jim@GALWAYSG.COM> Date: Monday, February 10, 2020 at 3:48 PM To: Julie Hedlund <julie.hedlund@icann.org>, "gnso-newgtld-wg@icann.org" <gnso-newgtld-wg@icann.org> Subject: [Ext] RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC Hi Julie – one addition on the Actions from 2.2.6 RSP Pre-Approval Its buried in the notes but the action item should be to come up with a term that describes the program but replaces the term “Approval” because of the implications that may convey in light of the recent EBERO/SLAM data we received. Concerns are further described in my email to the list from Jan 30 - https://mm.icann.org/pipermail/gnso-newgtld-wg/2020-January/002400.html and supported by Rubes on list and a few others on the call earlier today. Jim Prendergast The Galway Strategy Group +1 202-285-3699 From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Julie Hedlund Sent: Monday, February 10, 2020 11:51 AM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 10 February 1500 UTC Dear Working Group members, Please see below the notes from the meeting on 10 February 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-02-10+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: 2.2.3 Applications Assessed in Rounds: Implementation Guidance xx (see rationale 2): ACTION ITEM: Take the contents of Jeff Neuman’s email into Implementation Guidance (amended for clarity as necessary). ACTION ITEM: WG members will be invited to present a minority view. Proposal from Alexander Schubert: “If a string has been evaluated and is not approved by ICANN – the application will be withdrawn BY ICANN once all appeals and accountability mechanisms are exhausted (no input by the applicant required; prevents “blocking of a string forever”).” ACTION ITEM: Take the discussion of Alexander Schubert’s proposal to the email list. 2.2.6 RSP Pre-Approval: Recommendation xx (Rationale 1): ACTION ITEM: Add after first sentence: “may receive pre-approval by ICANN if they pass the required technical evaluation and testing conducted by ICANN, or their selected third party provider.” Implementation Guidance xx (rationale 7): ACTION ITEM: Re-write to clarify. Recommendation xx (rationale 5): ACTION ITEM: Add some language in a note about the comment from Donna Austen about whether we can get details concerning the costs. Recommendation xx (rationale 6): ACTION ITEM: Change the first sentence to read “The list of pre-approved RSPs must be published…” Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52... [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_documen...> a. 2.2.3 Applications Assessed in Rounds (brief continued discussion – page 4) -- Spent a lot of time on how we perceived a subsequent round if there are still applications in process. -- Current language: Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application round [PROVIDED THE APPLICANT(S) for that same string FROM THE PRIOR ROUND HAVE AGREED IN WRITING TO FOLLOW ALL UPDATED POLICY provisions prior TO THE OPENING OF THE NEXT ROUND. DING ADOPTED BY NEW POLICIES]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round, unless and/or until the applications from the previous round that match those strings have had their final disposition. Email from Jeff Neuman: See http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-February/002434.html Discussion: -- Question: What does “on hold” mean? Answer: Subject of GAC advice or challenge from right of first refusal; didn’t apply to many. Means the application is still being processed. Subject of an appeal or accountability mechanism. .IDN is still in an accountability mechanism. -- Question: What does Application Support mean as a category? Answer: That the application is being evaluated for application support. -- Seems like most of the edge cases will have been addressed by the Board. -- The principle suggested by Anne Aikman-Scalese that there could be backup applications would not be allowed on the current suggested policy where there are policy issues involved (on hold, brand issue, appeal/accountability mechanisms). -- Allowing backup applications would add lots of complications and unintended consequences. Simpler to have a rule to say if it is in any of these statuses you can’t apply for it. -- There should be pressure on prior applicants to meet new policy. -- But that assumes that there is new policy, and not sure we can assume that. -- Question: How long do you let an application "hang out" without any pending mechanisms on it? Answer: There are timelines for accountability mechanisms in the Bylaws and we’ll be setting implementation guidance when we discuss appeals. -- Why assume that people will want to apply for the problematic strings (those that had name collisions) and assume that those problems will be resolved? -- Anne Aikman-Scalese: I am not talking about 6.c "Not approved" only. I am talking about most of your detailed categories - many of which prohibit back-up offers that will lock applicants out until another window opens up - perhaps much later, e.g. in the case of appeals and accountability mechanisms. ACTION ITEM: Take the contents of Jeff’s email into Implementation Guidance (amended for clarity as necessary). ACTION ITEM: WG members will be invited to present a minority view. Proposal from Alexander Schubert: “If a string has been evaluated and is not approved by ICANN – the application will be withdrawn BY ICANN once all appeals and accountability mechanisms are exhausted (no input by the applicant required; prevents “blocking of a string forever”).” See: http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-February/002431.html Question: Currently there is no mechanism to force the withdrawal of an application for a string. Should we create one? Discussion: -- Does this trigger the necessity to exhaust all remedies? -- Support Alexander’s proposal to include a provision to force withdrawals in the case where the Board says the application shouldn’t proceed and there should be a refund. -- What happens if the Board says the application won’t proceed for now -- “not approved” is not the same as “rejected”? We could always say that the Board needs to be explicit. -- Strings that were rejected due to objection - and can't move forward (e.g. a city or a religious community). Should be withdrawn to allow others to apply for it in the future.
 ACTION ITEM: Take the discussion of Alexander Schubert’s proposal to the email list. b. 2.2.6 RSP Pre-Approval (page 20) -- Email from Jim Predergast: Could we call this two phases of testing, rather than “pre-approval”. Have two phases -- second phase would be everything in schedule A, that is unique to each TLD. Avoid the implication of “pre-approval”. So, call it “passed Phase 1 testing”. -- Assumption is that there will be a phase 2 of testing. -- We are trying to signify RSPs that have passed an initial evaluation. Is there a way of indicating that without using the word “approval”? -- We went to “pre-approval” to avoid the terminology of “certification”. -- Hard not to get bogged down in trying to find a word that is acceptable to all. -- We could add explanatory language as to what “pre-approval” means. -- New data from ICANN reinforces that there continue to be problems with registry back-end operators. -- Explanatory language would only work for insiders -- outsiders would see that as approval. -- Continue this discussion on the list. -- The testing part would apply to both, the only difference is the timing. -- Other terminology for Recommendation xx (Rationale 1): “... may receive pre-approval if they pass the required technical evaluation and testing conducted by ICANN, or their selected third party provider.” -- Or call it “Pre-testing Program” or “ Pre-qualification”. ACTION ITEM: Amend Recommendation xx (Rationale 1): add after first sentence: “may receive pre-approval by ICANN if they pass the required technical evaluation and testing conducted by ICANN, or their selected third party provider.” Implementation Guidance xx (rationale 7): With respect to each subsequent round, ICANN org may establish a separate more streamlined process for reassessments in terms of evaluation and testing than those entities seeking RSP pre-approval for the first time. Discussion: -- We don’t know how this will go in the next round. -- Probably easier to say that we stay the same as what we had before, but if there is an opportunity for ICANN to streamline the process they should be allowed to do so. -- We are saying that there could be a much more extensive pre-approval process, but for reassessment it might be less extensive. -- Need to clarify the wording. -- Should defer to the SSAC as technical experts and ICANN staff. -- Saying that RSPs do not have technical expertise might be wrong
SSAC and ICANN does not necessarily have understanding of all aspects of the inner work of Registries backends.
 ACTION ITEM: Re-write to clarify. Recommendation xx (rationale 5): The RSP pre-approval program must be funded by those seeking pre-approval on a cost-recovery basis. Costs of the program should be established during the implementation phase by the Implementation Review Team and/or ICANN org. Discussion: -- Really would like to understand what those costs are. -- Important, if possible, to get some indicative costs. If the costs are prohibitive then we won’t get anyone using the pre-approval program. Flag to come back to this. -- Not sure that we’ll have information on the costs during the PDP. Should have a better understanding during implementation. ACTION ITEM: Add some language in a note about the comment from Donna Austen about whether we can get details concerning the costs. Recommendation xx (rationale 6): Results of an RSP Pre-Approval Program must be published on ICANN’s website with all of the other new gTLD materials and must be available to be used by potential applicants with an adequate amount of time to determine if they wish to apply for a gTLD using a Pre-Approved RSP. Discussion: -- Could we narrow this so that there could be security purposes to not publish? -- Say that “the list of pre-approved RSPs will be published”. ACTION ITEM: Change the first sentence to read “The list of pre-approved RSPs must be published…” 3. Work Plan -- See email from Jim Prendergast on the Work Plan: http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-February/002442.html. -- Topics for the next meeting at 0300 UTC on 13 February are: Universal Acceptance and Registry System Testing. 4. Topics for ICANN67 -- Working with the GAC to identify topics. -- Will provide briefing documents to help guide discussions. -- GAC members will be able to attend the SubPro PDP WG meetings because they will not have conflicts for those sessions.