[GNSO-GGP-WG] FOR REVIEW: Action Items #1 & #3 | GGP WG-Applicant Support Mtg #15 on 05 June at 1500 UTC
Mike Silber
silber.mike at gmail.com
Fri Jun 9 06:06:15 UTC 2023
Thanks Maureen
I think that is a positive change and support it!
On Thu, 08 Jun 2023 at 18:25, Maureen Hilyard <maureen.hilyard at gmail.com>
wrote:
> Hi Julie and GGP team
>
> I like Rafik's proposed merging of the two recommendations into one
> cohesive recommendation, and if I may, I would like to make some tiny
> wordsmithing changes.
>
> "ICANN Org should develop a flexible and responsive Applicant Support
> Program that will in order to communicate the results of the evaluation
> process and allow inform applicants to know about their range of support
> allocations, as early as possible and in a transparent manner."
>
> *Clean version*
>
> "ICANN Org should develop a flexible and responsive Applicant Support
> Program that will communicate the results of the evaluation process and
> inform applicants about their range of support allocations, as early as
> possible and in a transparent manner."
>
> Maureen
>
>
> On Fri, Jun 9, 2023 at 3:52 AM 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.
>>
> _______________________________________________
> 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/20230609/2812eade/attachment-0001.html>
More information about the GNSO-GGP-WG
mailing list