[GNSO-GGP-WG] Actions & Notes | GGP WG-Applicant Support Mtg #14 on 22 May at 2000 UTC

[Julie Hedlund]

Dear Working Group members,

Please see below the action items and brief notes for the GGP WG meeting on 22 May.  These also are posted on the wiki at:  https://community.icann.org/display/GGPGIRFAS/2023+Meetings.  Please note that these are not a substitute for the recordings also posted to the wiki.

The next meeting will be in two weeks on Monday, 05 June at 1500 UTC.

Kind regards,
Steve and Julie

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]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1uoXS6_6VFlg-tOslZFryVVMu7DES9XdubmRcjHa6-X4/edit?usp=sharing__;!!PtGJab4!8uu0chT9xv-UxgqEYzm964xF5FrJXFCENBR0rngI5RBXIvHzgQWJbSKdmNDrP_73PkCHkfTv_UNV_tkiuJYmsrtW3mzNdCwytA$>  – 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-ggp-wg/attachments/20230522/8beda979/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GGP Applicant Support Work Plan & Timeline for Council 22 May 2023.pdf
Type: application/pdf
Size: 1338775 bytes
Desc: GGP Applicant Support Work Plan & Timeline for Council 22 May 2023.pdf
URL: <https://mm.icann.org/pipermail/gnso-ggp-wg/attachments/20230522/8beda979/GGPApplicantSupportWorkPlanTimelineforCouncil22May2023-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: GGP Task 6 Discussion Framework 22 May 2023.pdf
Type: application/pdf
Size: 463650 bytes
Desc: GGP Task 6 Discussion Framework 22 May 2023.pdf
URL: <https://mm.icann.org/pipermail/gnso-ggp-wg/attachments/20230522/8beda979/GGPTask6DiscussionFramework22May2023-0001.pdf>