[GNSO-GGP-WG] FOR REVIEW: Action Items #1 & #3 | GGP WG-Applicant Support Mtg #15 on 05 June at 1500 UTC

Thu Jun 8 16:03:02 UTC 2023

Thanks Julie

I like the proposal!

On Thu, 08 Jun 2023 at 17:52, Julie Hedlund <julie.hedlund at icann.org> wrote:

> Dear Working Group members,
>
>
>
> Per Action Item #1 below, Rafik has provided a suggested revision of Task
> 6 Recommendation Guidance 3 & 4 as follows and in the Working Document at:
> https://docs.google.com/document/d/1MkFbMitHIwtQyGBVdhfU4BQzfh6rhwGq3UTwBot6UHk/edit?usp=sharing
> :
>
>
>
> "ICANN Org should develop a flexible and responsive Applicant Support
> Program  in order to communicate the results of evaluation process and
> allow applicants to know about their range of support allocations as early
> as possible in transparent manner."
>
>
>
> Per Action Item #3 below, WG members are requested to review the suggested
> text from Rafik and the redlines based on Monday’s discussion and provide
> comments if any in the Working Document at the link above.
>
>
>
> Kind regards,
>
> Julie
>
>
>
> *From: *GNSO-GGP-WG <gnso-ggp-wg-bounces at icann.org> on behalf of Julie
> Hedlund <julie.hedlund at icann.org>
> *Date: *Monday, June 5, 2023 at 3:58 PM
> *To: *"gnso-ggp-wg at icann.org" <gnso-ggp-wg at icann.org>
> *Subject: *[GNSO-GGP-WG] Actions & Notes | GGP WG-Applicant Support Mtg
> #15 on 05 June at 1500 UTC
>
>
>
> Dear Working Group members,
>
>
>
> Please see below the action items and brief notes for the GGP WG meeting on
> 05 June at 1500 UTC.  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 *during ICANN77 on Tuesday, 13 June at 1530-1700
> EDT (local time), 1930-2200 UTC.*  See the ICANN77 Schedule at: https://icann77.sched.com/event/1NMtv/gnso-guidance-process-for-applicant-support-working-group?iframe=yes&w=&sidebar=yes&bg=no
> [icann77.sched.com]
> <https://urldefense.com/v3/__https:/icann77.sched.com/event/1NMtv/gnso-guidance-process-for-applicant-support-working-group?iframe=yes&w=&sidebar=yes&bg=no__;!!PtGJab4!6l5Maz8iy6KaOiEWhXEXzKHAW2lenfbLDtwbQ-LImCzwD_awNpJLM1X5AjtPFv7AYx8-cJ8_s12mwQk7_vBGZWJxxEq51N0uTg$>.
>
>
>
>
> Kind regards,
>
> Steve and Julie
>
>
>
> *ACTION ITEMS/HOMEWORK:*
>
>    1. *Rafik to combine Recommendation Guidance 3 and 4 for WG
>    consideration.*
>    2. *Staff to revise the Task 6 Working Document based on the
>    discussion and submit it for final review to the WG.*
>    3. *WG members to review the final revised version of the Task 6
>    Working Document.*
>    4. *Staff to prepare the Task 3-5 Working Document to include
>    rationale and deliberations, along with a slide deck, to guide the
>    discussion at the ICANN77 meeting.*
>
> *Notes:*
>
>
>
> *Draft Agenda*
>
> *GGP WG-Applicant Support Meeting #15*
>
> *Monday, 05 June 2023 at 1500 UTC*
>
>
>
> 1. Welcome
>
>
>
> 2. Work Plan & ICANN77 – see attached slides, #4.
>
>    - Reminder that the WG is on schedule to post the preliminary
>    Recommendations Guidance Report for public comment in July per the work
>    plan and timeline.
>    - The WG is expected to finalize the Task 6 recommendations during
>    today’s meeting and the Task 3-5 recommendations during the ICANN77 meeting
>    (noting that the Task 3-5 recommendations have already been discussed, so
>    WG members will be considering only the rationale and deliberations).
>    - Staff will insert the text into the Recommendations Guidance Report
>    format as agreed in the task working documents after ICANN77 for discussion
>    at the meeting on Monday, 26 June at 2000 UTC.  (19 June is a holiday for
>    the ICANN US offices and also generally meetings aren’t held the week
>    following an ICANN meeting due to travel.)
>    - Per the concern that some members of the WG may not be able to
>    attend the ICANN77 meeting remotely due to time-zone issues, staff
>    emphasized that nothing would be finalized at that meeting – further
>    discussion would continue on the list at during the meeting on 26 June.
>    Staff noted also that WG members will be able to review the text in its
>    final form in the Recommendations Guidance Report before it is posted for
>    public comment.
>    - Mike Silber, Chair, noted that in order to ensure that the Report is
>    posted for public comment as envisioned by the work plan timeline, the WG
>    can take no more than two, and preferably one, meeting to finalize the text
>    of the recommendations, rationalization, and deliberations for all the
>    tasks.
>
> 3. Continue Discussion of Task 6 – see Draft Working Document at: https://docs.google.com/document/d/1m_C4abtrloC21hzbTayllfTwBcgIJ5sB5PGHHzgn9kg/edit?usp=sharing
> [docs.google.com]
> <https://urldefense.com/v3/__https:/docs.google.com/document/d/1m_C4abtrloC21hzbTayllfTwBcgIJ5sB5PGHHzgn9kg/edit?usp=sharing__;!!PtGJab4!4ooPtnYSboxrBdRylUWD1LE1mSTeqjgKdMRIaFzlSKiMDv5WC78m2wYrrevXLLlOsdD-hkduXs3ievrKTslJjynznc4yGMM0cg$> and
> attached slides, starting on slide 6.
>
>
>
> *ODA:*
>
>
>
> *Comment from Maureen*: “additional resources such as the portal,
> showcase events, brochures, banners. etc are all these included in the
> costings that may or may not be ASP-specific but still ASP-related?”
>
>
>
> Discussion:
>
>    - As part of the recommendations – Mike suggested adding a footnote to
>    Recommendation Guidance 1 “that program costs should be dealt with
>    separately.”  More specifically: “sufficient funds for applicant support
>    doesn't include the funds required for actually running the program, which
>    should be dealt with separately.
>
> *Recommendation Guidance 1:*
>
>
>
> *Comment from Maureen*: “refresh my memory, but can an ASP applicant use
> ASP "funds" to purchase post-pro-bono-services? And, apart from a fee
> reduction (which would come out of the applicant's share), what else could
> an ASP applicant's possible equal allocation be used for?”
>
> *Comment from Julie, Staff*: Thanks Maureen, as the funding is in the
> form of a fee reduction, there would be no "funds" that the applicant could
> use to purchase anything.  I think what the WG envisioned is that the equal
> allocation of funding would only be in the form of an equal fee reduction.
> The WG did not discuss how the applicant could "use" the fee reduction.
>
>
>
> Discussion:
>
>    - The assumption is that the funding would bein the form of fee
>    reduction. So there aren’t any funds being provided to an applicant. Then
>    there's no way to purchase anything, because there's no funds, but also the
>    pro bono services are free.   Not sure what language we need to add to
>    clarify.
>    - What if there are additional services that they want to purchase?
>    How do they get support for that?
>    - We can make it clearer in the recommendation that the funding is
>    limited to a fee reduction – add in brackets “[by way of fee reduction]”.
>    On pro bono services that is clear – we don’t have to say more.
>    - There is recommendation 17.2, which isn’t in scope for this WG,
>    which the Board has concerns about: “The Working Group recommends expanding
>    the scope of financial support provided to Applicant Support Program
>    beneficiaries beyond the application fee to also cover costs such as
>    application writing fees and attorney fees related to the application
>    process.” We don’t have to reference that because it’s not within scope and
>    is being dealt with separately.
>    - Mike made some suggested edits in the document to respond to a
>    question from Gabriella concerning Option 2, to note that that is the
>    “equitable solution”.
>
> *Recommendation Guidance 2:*
>
>
>
> *Comment from Maureen*: “should that not be "allocated" or any other term
> that does not imply that the applicant will "receive" any funding?”
>
>    - Good point – suggest change in brackets “[be allocated]” instead of
>    “receive” as in: “In particular, the Working Group agreed that ICANN org
>    could determine the minimum level (or floor) of funding each qualified
>    applicant should receive [be allocated].”
>    - One WG member asked whether the recommendation provided sufficient
>    guidance with respect to setting a funding “floor”.  ICANN Org GDS staff
>    agreed that the recommendation guidance as currently written was helpful
>    guidance because it's establishing that there's a purpose and a goal behind
>    the allocation of support.
>
> *Recommendations 3 and 4:*
>
>
>
> *Comment from Maureen*: “We need to start the process of getting
> information out to ALL potential gtld applicants very soon, so that we can
> identify who the ASP applicants might be, and to start on the ASP as the
> next step! The timing of this whole process is critical. In the interest of
> fairness and equity, we cannot rush the ASP but at the same time, we can't
> drag it out for other applicants.”
>
>
>
> Discussion:
>
>    - This is very specifically in terms of communicating the results of
>    the evaluation and the likely support that applicants are going to get
>    after they've already so applied. Not people.
>    - It is important to highlight transparency and clarity on how much is
>    the benefit and how many beneficiaries from the very beginning
>
>
>    - The timeline needs to give potential applicants time to make an
>    application or to make a decision about any other direction they may decide
>    on.
>    - Wondering if using term “flexible” is appropriate.
>    - We aren’t going to set a limit but we are going to recommend an
>    equitable process with a minimum threshold.  We rejected Option 3 in our
>    previous discussion (and as noted in the rationale), which was
>    prioritization.
>    - And as a reminder of the process that we're looking at now is that
>    the working group has discussed these recommendations and has agree to the
>    terminology. We're really looking at the rationale and deliberations to
>    make sure that those are clear.
>    - I think what we're trying to tell stuff is that they must design a
>    program which allows for timely and transparent communication
>    - and then give them some flexibility. We're not trying to tell them
>    what to do here.
>    - Note that the more prescriptive we are, the more likely the Board
>    will flag it, the more likely it will go back to Council. It may have to be
>    the subject of a clarification process, or some sort of other supplemental
>    recommendation. In other words, it could really get hung up for months and
>    months. and so to the extent that you guys have an opportunity to say it
>    must be sufficient. It must be timely. Those are the kinds of things that
>    will make it easier to get past Council and past the Board, and then
>    ultimately, those things go to the IRT who decide what's sufficient and
>    timely.
>    - Some WG members agreed that it was optimal for the recommendation to
>    not be overly prescriptive, and in that regard the word “flexible” is
>    sufficiently clear.
>    - At least one WG member emphasized that the recommendation was too
>    vague with respect to the term “flexible.”
>    - Nonetheless, the Working Group also agreed that it would be helpful
>    for Rafik to combine Recommendation Guidance 3 and 4 in some fashion
>    (perhaps as two parts of one recommendation); staff captured this as an
>    action item.
>
>
>
> *ACTION ITEM: Rafik has agreed to combine Recommendation Guidance 3 and 4
> for WG consideration.*
>
>
> _______________________________________________
> GNSO-GGP-WG mailing list
> GNSO-GGP-WG at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-ggp-wg
>
> _______________________________________________
> By submitting your personal data, you consent to the processing of your
> personal data for purposes of subscribing to this mailing list accordance
> with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). You can
> visit the Mailman link above to change your membership status or
> configuration, including unsubscribing, setting digest-style delivery or
> disabling delivery altogether (e.g., for a vacation), and so on.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-ggp-wg/attachments/20230608/7052363d/attachment-0001.html>