Dear Jeff et al, I ended up being in the air with no Internet access during the scheduled call time, but have now listened to the recording: I have three comments on the discussion: 1. Adoption of the term “Affirmation”. We will ultimately need to distinguish between an Affirmation that is representative of Consensus or Rough Consensus and an Affirmation (or other category) that results in a “fallback” position to the 2012 AGB or practice due to a failure of the WG to reach Consensus. So the addition of an “Affirmation” category is still a bit unclear in this regard. Is the word “Affirmation” an equivalent to the designation “Consensus”? Will there be more than one category of “Affirmation”? Do we have a clear definition of “Affirmation” for the document that will be published? 2. Applicants “checking the box” re use of Pre-approved RSP. With respect to the RSP “Pre-approval”, it was mentioned on the call that an applicant might “check the box” stating that it would be using a pre-approved RSP. I think we need to consider that applicants might be tempted to prepare an application, not actually having concluded an agreement with a “pre-approved” RSP, and simply have “checked the box” to avoid further costs until the applicant sees whether or not its application can move forward, whether there are other applicants for the same string (string contention), whether there might be Objections, and whether or not it succeeds in the financial evaluation. So what degree of “proof” might be required to verify that the applicant’s RSP services are actually in place? Or do we care whether or not the agreement with the pre-approved RSP is in place at the time of application? If the RSP agreement that is claimed in “check the box” is not in fact in place, does that mean that ICANN could be wasting time in applying other eavaluation processes to the application? 3. Use of Excess application fees. Regarding the change of the “Implementation Guidance” status on the use of excess application fees to a “WG Recommendation”, that seems fine (personal opinion subject to IPC further input), but is there a possible need to cross-reference the Auction Proceeds program that will ultimately be adopted by ICANN? The reason I ask is that the specific purposes listed appear to track the CCWG Auction Proceeds work to some degree. The Board itself may be concerned that it may not be workable on a practical level to implement one solution for Excess Application Fees and another solution for Auction Proceeds. (PERHAPS THE NOTE HERE IS THAT THE RECOMMENDATION SHOULD LIST AUCTION PROCEEDS AS AN “EXTERNAL EFFORT” OR “DEPENDENCY” RELATED TO THIS RECOMMENDATION.) Thank you, Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces@icann.org> On Behalf Of Julie Hedlund Sent: Thursday, January 30, 2020 2:43 PM To: gnso-newgtld-wg@icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 January 2000 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 30 January 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-01-30+New+gTLD+Subsequent+Pro.... Kind regards, Julie Notes and Action Items: Actions: Affirmation xx (rationale 1): ACTION ITEM 1: Leadership to consider if there is another category beyond recommendations and implementation guidance, such as things for ICANN Org to consider. Affirmation xx (rationale 2): ACTION ITEM 2: Do some research as to whether we are affirming the second sentence: “Application fees may differ for applicants.” ACTION ITEM 3: Add recommendation or affirmation with modification: Historical costs should not be part of the cost structure. Implementation Guidance xx (rationale 3): ACTION ITEM 4: Add two recommendations: 1) in the AGB section -- add “including all fees” as must be published at that time; 2) in this section -- the reassessment of cost recovery must happen prior to each round. ACTION ITEM 5: Add to deliberations: Example of cost floor. Recommendation xx (rationale 4): ACTION ITEM 6: Change to “must have a plan in place” and then also “must be communicated in advance”. Should also say, “the implementation guidance below describes in more detail how this should be accomplished.” Implementation Guidance xx (rationale 4): ACTION ITEM 7: Clarify/re-write: If a floor is not used then excess fees go to applicants; if a floor is used then excess fees go to the programs identified. Implementation Guidance xx (rationale 4): In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories… ACTION ITEM 8: Change to “excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories…” and change it in brackets to a recommendation, changing “should” to “must”. 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.... The goal of this exercise is intended to accomplish at least a couple of things, 1) Ensure that the format and level of detail, which emphasizes the recommendations/implementation guidance/affirmations and rationale rather than comprehensive deliberations (and which follows the model established by Work Track 5), is supported by the WG, and 2) Give the WG the opportunity to make substantive progress on finalizing topics. 2.5.1 Application Fees & 2.5.2 Variable Fees -- General comment: Make it clear what is implementation guidance and what is a recommendation. -- This is not implementation versus policy -- this is “must” versus “should”. Affirmation xx (rationale 1): -- Note from ICANN Org: “Note that there was a request from ICANN org to clarify if the suggestion that “all applications should incur the same base application fee amount” extends to scenarios beyond “type of application or number of applications.” For example, would an applicant proposing to use a pre-approved RSP pay the same application fee as one who proposes to operate its own back-end registry functions and thus requiring technical evaluation? The WG may want to improve the language to make this clear.” -- With the should class, will there also be an example or type of a case that shows why it isn't a must?
 If it’s a “must” in certain types of cases then it’s helpful to have an example -- reasons for not doing it. -- Should put the technical evaluation as a separate fee if they haven’t gone through the pre-approval process. -- Raises an interesting question about the cost-recovery model. -- Added a comment: “Technical evaluation should be a separate fee if not part of pre-approval program (also, technical evaluation fee would be the same whether as part of pre-approval or not).” -- Are we saying that there could be a base fee and the possible deductions and increases? -- Question: If there is an applicant that applies for 20 strings and they don’t go through the pre-approval would they go through the technical evaluation once or 20 times? Answer: You would only go through the technical evaluation once, which would be consistent with the RSP pre-approval program. But might make more sense for them to do a pre-approval. -- Question: Would the same apply to background checks? Answer: There are some differences from a technical review. Might be some minor cost efficiencies. -- Create a third category: Must/should/might. ICANN “might" want to grant price breaks for multiple applicants for the financial and background checks. -- The more that you put into a pre-approval the more the base fee in theory could go down if there are multiple applications. -- The timing of when various evaluations are conducted also matter. As a side point, there was a suggestion that evaluation (background screening?) be conducted twice - once during application and second, prior to contracting. ACTION ITEM: Leadership to consider if there is another category beyond recommendations and implementation guidance, such as things for ICANN Org to consider. Affirmation xx (rationale 2): -- Do some research as to whether we are affirming the second sentence: “Application fees may differ for applicants.” -- Comments: “The Working Group may want to consider whether it wants to affirm the overall structure of the fee (i.e., historical costs, processing, and contingency).” and “I think the opposite is the case at least with respect to historical costs. I believe the group was against doing that, but we will check.” -- WG agrees with the second comment -- that it doesn’t include historical costs, but we should clarify it as an affirmation. ACTION ITEM: Do some research as to whether we are affirming the second sentence: “Application fees may differ for applicants.” ACTION ITEM: Add recommendation or affirmation with modification: Historical costs should not be part of the cost structure. Affirmation xx (rationale 3): -- Why is the word “generally” there? It is because the fee floor is not part of cost recovery, but we could remove the word “generally”. It does not mean that most WG members agreed but not all. Best to remove it. Implementation Guidance xx (rationale 3): -- Should this be a recommendation? We didn’t make it one because we don’t have all the information on what the costs should be. -- Question: What does this mean? When would the price change happen? Answer: When ICANN figures out what the costs will be for the program then it will determine what will be the revenue-neutral fee. They will also have developed a predetermined threshold. We should make it clear that this would take place before applications are submitted. It would be assessed on a per round basis. (Added as a comment.) -- Reference the fact that this needs to be established as part of the AGB prior to each application round. ACTION ITEM: Add two recommendations: 1) in the AGB section -- add “including all fees” as must be published at that time; 2) in this section -- the reassessment of cost recovery must happen prior to each round. Recommendation xx (rationale 4): -- Add the notion of determining the fees for each subsequent round (“reassessment of cost recovery must happen prior to each round.” -- Question: Is this plan intended to be the administrative arrangements for where ICANN keeps the money? It says that ICANN has to have a plan in place for managing the excess fees, but don’t know what we mean by a plan. Does ICANN have to have a separate bank account until it determines what is excess and what is not? Answer: In cases where there was implementation guidance that was tied together we tried to create a what that goes with a how. There are guidance about what ICANN should do to deal with excess fees and shortfalls. It is less about administration, but that there needs to be some sort of communicated in advance plan as to what will happen if there are excess fees or shortfalls. ACTION ITEM: Change to “must have a plan in place” and then also “must be communicated in advance”. Should also say, “the implementation guidance below describes in more detail how this should be accomplished.” Implementation Guidance xx (rationale 4): -- I thought that in the event that a 'fee floor' is used, any excess fees collected above the floor would be returned to the applicants; and if there were any excess fees that remained from the fee floor this excess would go to things like universal awareness etc. -- Explain what "Universal Awareness" means. ACTION ITEM: Clarify/re-write: If a floor is not used then excess fees go to applicants; if a floor is used then excess fees go to the programs identified. Implementation Guidance xx (rationale 4): In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories… -- Comment: “Recommend this language be changed to: a global communication and awareness campaign about the introduction and availability of new gTLDs.” Should be differentiated from Universal Acceptance. -- Do we need to be more specific? Preference would be to be more specific. -- Change to a recommendation -- “must”? ACTION ITEM: Change to “excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories…” and change it in brackets to a recommendation, changing “should” to “must”. Implementation Guidance xx (rationale 4): To help alleviate the potential burden of an overall budget shortfall, a separate segregated fund should be set up that can be used to absorb any shortfalls and topped-up in a later round. The amount of the contingency should be a predetermined value that is reviewed periodically to ensure its adequacy. -- I would like to think that the segregated fund is off limits to "loans to ICANN". New issues raised in deliberations since publication of the Initial Report, if applicable: -- Comment: “Is it possible to nominate a % of the overall application fee that is intended to be the fee floor? Absent tangible guidance, implementation will be extremely difficult. Further study in the implementation phase will not be helpful if the variables remain unknown.” -- The one variable that will remain unknown is the number of applications. -- One of the things that we did discuss was the recognition that you are running a piece of Internet infrastructure and there is a benefit to doing that. Can we come up with any idea of what we think the value of that is? That may be impossible. That could be added as one of the variables. Whoever is going to determine the floor should take it into consideration. -- Not sure why we are including this paragraph if there is no recommendation coming out of it. It is intended to acknowledge new issues that were raised after the last public comment, but noting that there was no agreement on a recommendation. ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.