[GNSO-GGP-WG] Actions & Notes |GGP WG-Applicant Support Mtg #12 on 08 May at 2000 UTC
Maureen Hilyard
maureen.hilyard at gmail.com
Fri May 12 22:00:56 UTC 2023
Thank you Julie for these very comprehensive notes. It is an excellent
record for those who could not attend the meeting, to have such full notes
on the discussions that took place around the changes to the text, within
each of the recommendation sections.
Looking forward to the draft Recommendations Guidance report that staff is
putting together from the GGP discussions plus the draft Working document
for Task 6 at our next meeting.
See you then
Maureen
On Fri, May 12, 2023 at 11:34 AM Julie Hedlund <julie.hedlund at icann.org>
wrote:
> Dear Working Group members,
>
>
>
> Please see below the action items and brief notes for the GGP WG meeting
> on 08 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 on Monday, 15 May at 1500 UTC.
>
>
>
> Kind regards,
>
> Steve and Julie
>
>
>
> *ACTION ITEMS/HOMEWORK:*
>
> 1. *Staff will produce a draft Recommendations Guidance Report text
> incorporating the recommendation guidance for Tasks 3, 4, and 5 as
> discussed by the WG, filling in the rationale and deliberations from the
> discussions as well as some suggested assumptions for the WG to review. *
> 2. *Staff also will produce a draft Working Document for Task 6 for
> the WG to begin the discussion at the meeting on Monday, 15 May.
> [COMPLETED]*
>
> *Notes:*
>
>
>
> *Draft Agenda*
>
> *GGP WG-Applicant Support Meeting #12*
>
> *Monday, 08 May 2023 at 2000 UTC*
>
>
>
> 1. Welcome
>
>
>
> 2. Continued Discussion of Goals and Metrics Relating to Tasks 3, 4, 5 --
> Draft Suggested Revision (60 min) – start at section 5 -- see:
> https://docs.google.com/document/d/1bU_QTPqYKvwOp0l90sHLigCNmTE8Ykvrx59FlPelTjQ/edit?usp=sharing
>
>
>
> - Let's continue from Section 5, and let's see if we can wrap up 5 and
> 6, and then we can go back to some of the additional comments that have
> come in in the Interim.
>
>
>
> Section 5
>
>
>
> Comment from Leon, ICANN org: I would suggest changing to 0.5%. If we
> expect ~2000 applications to go through, then with 0.5% we expect 10
> supported applicants under the applicant support programme. If we say 5%,
> then this would mean 100 supported applicants. Perhaps this is what was
> meant and I'm wrong, but according to the previous conversations, the 10-15
> figure seemed more prevalent as a goal.
>
>
>
> Discussion:
>
> - We have Recommendation 5, that of all successfully delegated gTLD
> applicants the goal is that 5%, point 0.5 of them were supported applicants
> – indicators of success would be that 5% of all were successfully delegated.
> - The data metrics to measure success will be that 5% of successfully
> delegated were supported applications. Of supported applicants note that
> this percentage is in relation to the number brings apart strings applied
> for of the number of applicants.
> - See the above comment from Leon.
> - Mike:
> - I think Leon raises an interesting question, because we're not
> certain if we're going to have the resources to support given the numbers
> that Leon has suggested, which I think is a reasonable assumption at least
> to start working on. you know. I'm not sure ICANN has the ability to
> support 5% of all applications.
> - And then I suppose the question comes in, what do we deem as
> support? Because if we're talking about somebody who has at any stage gone
> through the applicant support program then that's going to be very
> difficult.
> - If we're talking about people who get specific financial support
> in the form of a fee reduction, either in terms of the application fee or
> ongoing fees, that’s going to start getting really expensive, and it
> impacts the financial modeling of the application costs.
> - So I think that's 0 point 5%, but I also know that we spoke last
> time about trying to shoot for something bigger than just a slight
> incremental increase on what we got last time.
> - So I I don't know what people think about it.
> - Thanks, Mike. Comments from others?
> - cause mothers are welcome.
> - Maureen: Maybe it's because we're not mathematicians. But I guess
> the original goal was 10-15, and whatever the 10-15 of 2,000 is in the
> mathematical formula is, really what we should be going for, and I thought
> I thought we had this.
> - Roz: I think 10% of 2,000 applications. 200 applications would be
> higher than the number of applicants that ICANN is likely to support.
> - Kristy: This is an interesting question. So I guess maybe a
> threshold question for this group is whether you want to see a proportion
> of total applications as being
> - supported applicants. So whether it's we get 2,000 applications or
> 10,000 applications, is it the aim to see some sort of percentage of those
> applications being supported, or within a range a sort of set number like
> 10 to 20, regardless of how many applications we get. So that would be kind
> of a threshold question for the group. Thanks.
> - Julie: I am glad you mentioned that, because I do think that was one
> of the things that previously the working group has discussed is, does it
> make more sense to just pick a number regardless of the number of
> applications? Because, frankly, and I think this is the other thing we
> mentioned, we don't know how many applications there will be. We do have a
> sense of how many applicants we might want.
> - Paul: Thanks. Yeah, thinking about supply and demand a certain
> number feels like it could be arbitrary. On the other hand, a percentage
> could also be arbitrary. There may be factors that are driving demand for
> non-applicant supported TLD applications, and we could have a bumper crop
> of applicant supported applications, but still not meet some
> - some number.
> - Mike: I think we should see if we can possibly shoot for both, where
> we want to see no less than say 10 supported applications with an objective
> of a suitable percentage. So is that 0 point 5% or 1%. So you know, we can
> debate that. But I think we can try and capture both items.
> - Julie: Thanks, Mike. Any comments on Mike's suggestion? You could
> say no fewer than 10 supported applicants and also capture the percentage.
> There are no objections to that then staff can make that change in the
> document.
>
>
>
> Section 6:
>
>
>
> Comment from Sarah: From ALAC: We are proposing that we adjust this period
> from two to three years. Please see comment below: "Three years after
> launch might be a better option as the second year is the Junk Dump for new
> TLDs when undeveloped/speculated domain names are dropped. By Y3, the
> patterns of a new TLD start to emerge."
>
>
>
> Discussion:
>
> - Julie: Any thoughts about Sarah's suggestion from ALAC?
> - Mike: I suppose it takes a little longer to get results, because
> we're tracking over 3 years. But you know, if it's going to give us better
> results, why not?
> - Julie: Thank you, Mike. Anyone had any. Have any objections to
> changing this to 3 years? [no objections noted] All right, then.
>
>
>
> Comment from Roz: “From Roz: Think there's something still about
> collecting data which needs to be captured.”
>
>
>
> Discussion:
>
> - Julie: The next comment was from Roz, and it was picked up from an
> earlier version of the document, which is why it Isn't labeled as Roz's
> comment, but I have picked it up as her comment from the previous document.
> - Julie: I'm not sure I quite understand the comment, Roz. Do you mind
> speaking to it?
> - Roz: Yeah, absolutely. So. We had a sentence originally, and it was
> captured in the old red-line document. I think about tracking data on how
> well things were going, as it developed in the first 2 to 3 years. And I
> noted that was taken out, and so I just wasn't really sure why? Because I
> thought part of what we agreed that we were going do is try to track
> different aspects to see if, for example, the successful applicant still
> felt supported, or to record any challenges they were having. In order to
> have a collection of data.
> - Thanks Roz. Kristy do you recall? Not to put you on the spot.
> - Kristy: Yeah, I think in general, on this one, I think we want to
> acknowledge that there is value in looking at the data long term of
> supported applicants, and whether and how they were successful, and if they
> weren't successful, why not? In looking at that data is that an indication
> of whether the applicant support program was successful? And If so, should
> that also, maybe entail looking at some of the other elements of support,
> because as it stands right now, the applicant support program is really
> just focused on a fee reduction program for the application process and
> cultivating some pro bono services. There is some research that ICANN org
> did on other globally recognized programs to see you what other programs
> do, and one of the things one of the findings from that research was that a
> lot of other global programs that would be sort of similar in nature to
> applicant support do provide some ongoing support for 3 to 3 to 4 years
> after the initial kind of decision or evaluation process. And that seems to
> be something that this recommendation and implementation guidance is sort
> of hinting at, but we haven't discussed explicitly, you know whether and
> how ICANN org can provide that kind of ongoing support. I guess that's
> another question for me that's tied to this recommendation, and the other
> outputs underneath it.
> - Julie: Thanks, Kristy. That's very helpful. Roz has also hopefully
> pulled out the previous language.
> - From Roz: “Following completion of a new gTLD round, ICANN org
> should collect data on the number of supported applications that resulted
> in a delegated TLD by region, and those that did not; track operations of
> those delegated TLDs for two years; and conduct of survey of the successful
> and unsuccessful supported applicants to determine which elements of the
> program they found useful or not.”
> - Julie: It may be that the concern was that there were a number of
> reasons that a delegated TLD was unsuccessful.
> - Roz: I just feel the language was a lot more specific about what
> could be done, and now I appreciate in the interest of summarizing it. It's
> been cut down, but I think it is important to note and I think it's fine to
> say, “should collect data” without over specifying what kinds of data. But
> I just think it's important to have specific deliverables in there would
> help to keep us accountable. You know, on how things go after the
> applicants are successful, and even those that are unsuccessful sort of
> like what happens afterward? Does anyone see harm in including that
> original language?
> - Steve: I'm going to entertain an attempt at trying to figure out why
> that language might have dropped. And I think it's possible, because
> there's a bit of a disconnect between
> - trying to get data about why the program is not successful. Because
> you know the way that this part of the document is actually drafted, it's
> looking at what represents that success. And then also the data that helps
> us indicate that the program is indeed successful. I think part of what was
> dropped from the language before is actually looking at the survey data to
> try to determine what doesn't work, but that doesn't make that data not
> valuable. It just might not fit in the structure that we have in front of
> us. So you know, maybe if we actually separated those two components, the
> elements that indicate success, and then this is sort of bonus data that we
> think should be collected in serving applicants that may not have been
> successful after the 2 years or 3 years. That might just be an in an
> important data point that is not directly correlated to the goal.
> - help that made. Sometimes. Thanks.
> - Julie: Thank you, Steve, and thank you for jogging my memory.
> Because I think that is indeed why we deleted that language because it
> didn't fit with what was indicating success and what was being measured for
> success. And yet it is, as Roz notes, useful information to have
> nonetheless. So I think there's a way we can include it, and noting also
> that we're putting this into implementation guidance. Yes, Steve notes in
> the chat. It's now a measure of not being successful. Correct? Exactly.
> Thank you. And thanks for that comment. Roz I appreciate it, and thanks for
> finding the original language as well. I don't think there are any more
> comments on that section.
> - No. So what I'd suggest is going back up to the top of the document,
> because I think there are some comments that were added since last Monday.
> and we can go ahead and go back to those
>
>
>
> Section 1:
>
>
>
> Comment from Gabriela: “The concept of "underrepresented" can be confusing
> as it is primarily used to describe a lack of political representation in
> multilateral contexts.
> However, when considering the concept of "underserved," it becomes more
> comprehensive, encompassing both physical and non-physical infrastructure
> in some regions. This broader understanding, in line with the perspective
> of the International Telecommunication Union (ITU), extends beyond solely
> addressing the needs of the least developed countries. Then, we would be
> encompassing a wider range of potential applicants while also contributing
> to SDG 9, which focuses on expanding internet infrastructure (including
> non-physical infrastructure).”
>
> From Roz: “Underserved is great! Agree that if that is kept,
> underrepresented can go.”
>
> From Kristy, ICANN org: “we may want to propose a clarification here that
> the targets are particular audience segments (e.g., nonprofit, social
> enterprises, community) with emphasis on under-* regions but not limited to
> those regions. The reference to the GAC definition of under-served is
> geographically based and the SubPro Final Report explicitly said they do
> not want to limit to geographic regions or national level economic
> classifications. So perhaps the rewrite is something like: "Target
> potential applicants from the not-for-profit sector, social enterprises
> and/or community organizations with emphasis on developing,
> under-represented and/or under-served regions." or something along those
> lines? The point being that we don't want to limit comms and outreach to
> particular regions for ASP but it's about finding potential applicants that
> would qualify from all regions, while emphasizing that more attention
> should be paid to under-* regions.”
>
>
>
> Discussion:
>
> - Mike: Yeah, I think that's correct. I had made one comment. I'm not
> sure if it's come through. But I I've got a concern about the reference to
> the under-served regions because that's a somewhat extensive and I think
> it's confusing, using that as a reference to what we define as underserved
> [in the GAC document in the footnote]. In particular, because the
> definition there of underserved also then refers to governments, which I
> don't think is what we're after. So my suggestion is that we just extract
> the specific definition in that document, which is an undeserved region, is
> one that does not have a well-developed DNS and or associated industry or
> economy.
> - Julie: Thank you Mike and Gabriela says in the chat: “Yes, we can
> include definition.” Thanks. Okay, very good. Great suggestion. Kristy
> Buckley, from ICANN org has a comment (see above).
> - Mike: Yes, I think Kristy spot on and I think that's what we're
> going with, but we may just need to refine the language.
> - Julie: Thanks, Mike.
> - Mike: So I think you you're just capturing what we kind of already
> agreed, and always appreciate it. So I think, if we change that language
> now that we've settled that we're not going to use “under-represented” that
> we're going to use “underserved” with a specific definition. Then I think
> we're good to go.
> - Julie: So we're not using “under-represented”. Let’s just take that
> out right now. And we're not using underdeveloped, either. Right? Let's
> take that out which leaves underserved and developing regions. Correct?
> Sarah has her hand up, Sarah. Please.
> - Mike: According to Gabriella, it should be “developing regions and
> countries”.
> - Sarah: Okay. I think I added a comment about, for example,
> indigenous communities and groups like that, because during the call last
> week we spent a bit of time discussing that. And I feel that if you remove
> under-represented, for example, then it removes lthat provision for
> communities like indigenous communities in developing countries.
> - Mike: Yeah, thank you. I take I take the point, but at the same
> time I think the concern that Gabriella has expressed outweighs the
> benefit. And I do think that, for example, indigenous communities would be
> catered for in the definition of “underserved”, which is, “does not have a
> well-developed DNS and or associated industry or economy.
> - Julie: Thank you, Mike.
> - Mike: Because it's not limited on a national level. And we're using
> the term “region” which could mean a group of countries or an area within
> national boundaries, or we could be looking at a region. But I think that
> the “underserved” definition is adequate, because if we start looking at
> “under-represented” that starts having political connotations which makes
> it very subjective.
> - Julie: Thank you, Mike. I see Kristy is noting in the chat:
> “Under-served being comprehensive and inclusive of Indigenous communities.
> It’s a broader term that is not limited to geographic area or economic
> status (e.g., developing)” And I and I was going to say something similar
> in that in the US I think it's more accurate to use underserved when trying
> to capture the indigenous communities, because they aren't necessarily
> regionally oriented. They're scattered throughout the United States and
> their defining features that they're underserved. [to Maureen] I think the
> idea is that the term “underserved” would be capturing the indigenous
> groups.
> - Mike: Yeah. So I had suggested that we simply take the definition
> from the GAC document. But if you feel that that's inadequate, and we want
> to expand of it I think the more clarity we get to definitions, the better.
> - Julie: So Mike, is the suggestion that you extract the definition
> from the document that we see there where I've highlighted and add to it?
> I'm not sure I understand.
> - Mike: For some reason my comment doesn't come through. So let me
> just up it into the chat. “Does not have a well-developed DNS and/or
> associated industry or economy.” Is the definition in the GAC document.
> - Julie: Thanks. And I see that Kristy is saying: “The SubPro Final
> Report called for ASP to focus on supporting “struggling regions” to get
> away from the geographic and socioeconomic development status. However, we
> were challenged to define what a struggling region was in the ODA, so we
> suggested that ASP not be limited to particular geographies but rather be
> based upon financial need and work in the public interest.”
> - Mike: Yeah. So I think we can use that. But I think the suggestion
> that's being made by Maureen and Sarah, is that we may want to just stretch
> that a little bit.
>
> Section 2:
>
>
>
> Comment from Maureen (on moderate): “I know that we are trying to keep
> things high level, but these indicators of success seem overly simplistic..
> is that it? (especially taking into account the range of expertise that is
> required to make a successful business case).”
>
>
>
> Discussion:
>
> - Julie: Anything you want to add to that, Maureen or other suggested
> language?
> - Maureen: So how do we ensure that the that they [pro bono services]
> are on a capacity level that will actually meet the business needs of our
> of people who are actually trying, you know, wanting to apply and just need
> additional information, how do we just assess the quality of information?
> - Mike: If ICANN starts assessing the quality of services being
> offered, then ICANN starts getting involved in accepting responsibility for
> that quality. Then ICANN seems to be putting its thumb on the scale in
> terms of what services are given to potential applicants, and that creates
> the potential for favoring supported applicants over non-supported
> applicants in certain circumstances. So it becomes really difficult. So I
> hear what you're saying, Maureen. How do we make sure that this is actually
> useful and usable? I think the information that ICANN makes available we
> can hold ICANN to a specific standard that they must provide useful, usable
> information. But in terms of the pro bono services if we don't get good
> quality then we need to go back and say the program wasn't useful to
> applicants and potential applicants. But I think that's all we can say.
> Then we need to go back and redesign the program. But what we are looking
> at here is one of the metrics to allow us to success rather than designing
> the program.
> - Maureen: Yeah, thank you. I just wanted to ask. At one stage, I saw
> that applicants would be advised about pro bono services, so who advises
> them as to who would be? How do they get assigned services?
> - Julie: Thanks, Maureen. I don't think actually we have that language
> in here anymore. I think we steered away from that language. But I see
> Kristy has her hand up. Kristy, please.
> - Kristy: Thanks, Julie. Yeah, I don't recall if that language was in
> there or not. But in general, I think that would pose risks to ICANN
> inserting itself between the pro bono service provider and those that are
> seeking for one of services, and I think the intent is to cultivate and
> recruit pro bono service providers, and we'll probably entail some sort of
> background screening and due diligence to ensure that those are legitimate
> products of pro bono service providers, but that then it would be up to
> those service providers and supported applicants to sort of find each other
> and determine, you know whether or how they're going to work together.
> Because ICANN providing that connection, or facilitating actively those
> relationships kind of puts ICANN in the middle of those relationships
> rather than creating space for those relationships to happen on their own.
> - Mike: Yeah, I think that you can add some wording that says that we
> will then communicate the availability of pro bono services and the
> parameters in which they are offered
> - to potential supported applicants.
> - Julie: Thanks, Mike. Where would you suggest? We add that to the
> recommendation?
> - Mike: So, ICANN has one cultivated program of services, as well as
> ICANN provides the information so that the ASP has communicated the
> availability of those provider services and the supported applicants report
> on those use.
> - Maureen: But as long as the details are there, and that they know
> that we where they can find that information and that they make those
> choices. That's that
> - Mike: Thanks, Maureen. If I recall correctly the idea of matching
> was raised and rejected. Because that puts ICANN in the middle of a
> relationship in a position which creates massive legal risk.
> - Julie: I will pull that language from the transcript when it's up
> and incorporate it into the document. And we're really talking about making
> sure that that information for pro bono services and other information and
> services is communicated to the potential supported applicants.
> - Kristy: Yeah, no concerns about adding the communication. We
> certainly want to do a good job at communicating that those services are
> there, and recruiting service providers, and doing everything we can to
> help people find each other in that space. But we just don't want to be in
> the middle. That's the that's the small technical piece that we want to
> avoid. Thanks.
> - Julie: Thanks. That's very helpful, Kristy and thanks for Maureen
> for the suggestion. And thank you, Mike, for the suggested language and
> Paul in chat notes recruiting pro bono service providers is going to be the
> hard part Indeed.
>
>
>
> Comment from Maureen re: “application”: “Are we setting criteria on
> volunteers of pro bono services so that we at least ensure a minimum degree
> of quality and usefulness of services?”
>
> - Kristy: So what we've done in the ODA for this question is we've
> estimated the number of hours needed for pro bono services based upon
> interviewing a couple of applicants from the previous round, and we put a
> table in the ODA that basically estimates the cost and the number program
> and service hours. I think it was 500 or so per applicant for like legal
> services, technical services, application, writing, consultants, etc. And
> so that is going to inform the recruitment strategy for services. But I
> don't know that we've set any like number that we're looking for in terms
> of number of providers or volunteers that answers your question, Maureen.
>
> Section 3:
>
>
>
> Comment from Maureen re: “usefulness” under Qualitative Measurements:
> “when would this survey be administered? I’m assuming they would only be
> able to gauge the usefulness of the ASP and its resources, at the end of
> the application process and whether their application has been successful
> or not?”
>
>
>
> Discussion:
>
> - Julie: I don't know that we need to specify when a survey would
> happen.
> - Mike: There are going to be inflection points where we want to check
> when somebody drops up and somebody hasn't logged into the applicant
> support portal for a month. One of the key inflection points is going to be
> once they've actually submit an application. But if somebody decides not to
> submit at some stage after a period of inactivity that should be noticed,
> and they should be sent to survey Link to say we notice you. Haven't logged
> in for a while. Can you tell us why? If I say because I'm no longer
> interested in it. That's an inflection pointed, which we say will tell us.
> Is it because you didn't feel supported if you didn't have the information
> you needed to make it the right decision, or because you did actually get
> the support and the information you needed. And you then made a decision
> which was an informed and supported decision that a new gTLD is not for you.
> - Julie: Thank you, Mike.
> - Maureen: I think that there needs to be ongoing assessments made as
> to how people are progressing, and to provide us with feedback in an
> ongoing way. Well, that will also mean that there will be ongoing
> assistance.
> - Julie: I’ll try to incorporate that language into this text.
> - Maureen: (from the chat) I agree there needs to be surveying taking
> place throughout the process, because every applicant is going to be able
> to make a decision about probably progressing at different stages. Thank
> you.
>
> Section 4:
>
>
>
> Comment from Maureen: “Has an ICANN Learn module (101) been produced
> already that details everything that an ASP applicant would need to know in
> order to make a successful application? especially if your indicator of
> success is "a STRONG understanding". Several modules may be required to
> cover the different areas of knowledge that an ASP applicant may need, in
> order to be successful.”
>
>
>
> Discussion:
>
> - Kristy: So we do not already have an ICANN Learn module on this, we
> have been in discussions with ICANN Learn account services on whether and
> how to do that. One of the things that we've talked about with them is sort
> of a one-on-one on what it takes to be a registry operator might be
> helpful, because then it's really clear. You know what someone is signing
> up for if they're applying for a TLD. But I think that if there are other
> aspects to your commentary that you would like to see as learning
> objectives it would be really helpful to the ICANN Learn team to understand
> what those learning objectives and learning outcomes are, so that they can
> be sure that ICANN Learn Kristy (in the chat): What would be most helpful
> to articulate are the learning objectives and learning outcomes. That will
> help Org determine what resources to deploy.
>
> Next Steps: Staff will produce a draft Recommendations Guidance Report
> text incorporating the recommendation guidance for Tasks 3, 4, and 5 as
> discussed by the WG, filling in the rationale and deliberations from the
> discussions as well as some suggested assumptions for the WG to review.
> Staff also will produce a draft Working Document for Task 6 for the WG to
> begin the discussion at the meeting on Monday, 15 May.
> _______________________________________________
> 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/20230512/662dead5/attachment-0001.html>
More information about the GNSO-GGP-WG
mailing list