The call for the Applicant Support GGP team will take place on Monday, 22 May 2023 at 20:00 UTC for 60 minutes.

For other places see: https://tinyurl.com/fwad3eae

PROPOSED AGENDA


  1. Welcome
  2. Work Plan & ICANN77
  3. Continue Discussion of Task 6 – see Draft Working Document at:https://docs.google.com/document/d/1uoXS6_6VFlg-tOslZFryVVMu7DES9XdubmRcjHa6-X4/edit?usp=sharing [docs.google.com]  – note that when making edits choose “Suggesting” to avoid overwriting other text.
  4. AOB

BACKGROUND DOCUMENTS



PARTICIPATION


Attendance

Apologies: Satish Babu (Alternate)

RECORDINGS


Audio Recording

Zoom Recording (including audio, visual, rough transcript and chat)

GNSO transcripts are located on the GNSO Calendar

Notes/ Action Items


ACTION ITEMS/HOMEWORK:

  1. Staff to revise the Task 6 Working Document to capture suggested Recommendation Guidance, assumptions, and deliberations.
  2. WG members to add suggestions to the Task 6 Working Document once complete.
  3. Staff to prepare a slide presentation for the meeting on 05 June of the Task 6 recommendation guidance, rationale, and assumptions.

Notes: 

Draft Agenda

GGP WG-Applicant Support Meeting #14

Monday, 22 May 2023 at 2000 UTC


  1. Welcome
  2. Work Plan & ICANN77 – see attached slides.
  • Where we are now: April-June 2023, including ICANN77 (Tuesday, 13 June at 1530-1700 EDT) – Finalize Task 6, begin Draft Report development.
  • It may seem like we have a lot of time, but we need to finalize the development of the draft Recommendations Guidance Report in June so that we can put it out for public comment in July, per the schedule.  That period is for 40 days and then it will take several meeting to review and analyze the public comments, followed by development of the Final Report, including indicating how the WG took into consideration the public comments.
  • The Final Report is due to be delivered to the Council by December of this year at the latest.

      3.Continue Discussion of Task 6 – see attached slides and Draft Working Document at:https://docs.google.com/document/d/1uoXS6_6VFlg-tOslZFryVVMu7DES9XdubmRcjHa6-X4/edit?usp=sharing [docs.google.com] – note that when making edits choose “Suggesting” to avoid overwriting other text


Discussion:

  • First option in exceeding the funding is to seek additional funding (as in the ODA).
  • Second option is (from the slides): Fairness/equality of funding, while not hindering the efficiency of the process; or prioritization of some sort, or other?
  • Question: Considering ODA prescribed that only applicant fees would fund applicant support, what they suggested in the provision of additional funding ? Asking applicants for fee increase ? Answer: Could be a number of sources.  Funds in the program – part of the application fee for unpredictable costs.
  • Mike: Personal opinion is that fairness will be the best approach; prioritization creates complexities and puts ICANN in a difficult  position.
  • Fairness/equality: spread equally across applicants is one possibility.  Could have lower fee reductions (such as 70% rather than 75%-80%).
  • If it is prioritization then ICANN org has to create criteria and allocate the fees accordingly.  It would be complex and could generate complaints.
  • Fairness is simplistic but straightforward and most efficient.
  • If you say not to divide equally (look at the opposite) then what’s the basis to give one applicant more support?  Rationale is that the equitable solution avoids concerns about how to determine who gets what funds.  Efficiency and simplicity of process would be the goal.
  • Assumptions: to have as many qualified applicants to be able to provide support to.
  • We aren’t giving them money – fee reductions of 75%-85%.  Program is supposed to be run as close as possible to a cost basis.  It is real money, just not a check to an applicant.
  • It’s money that is increasing costs to unsupported applicants.  Need to keep that in mind.
  • Do we have agreement that equality of treatment is the way to go? 4-5 supporters.  This should be considered rough consensus.
  • Two issues: what happens if equality leads to such a dilution that support would be useless? Put into guidance that this is a risk and org should look at mitigating the risk.
  • Second issue: How to deal with the issue of making everyone wait.  Perhaps suggest some principles that allow flexibility.  Could we say that ICANN org could determine minimum coverage.  Create a flexible program that allows applicants to know as much as possible about their range of support allocation as early as possible.
  • Applicant support should not be diluted to the point of being meaningless – could provide guidance that ICANN org should be tasked with identifying a floor – a point whereby support should not drop below.
  • Evaluations should be published and transparent.

     4.AOB


  • No labels