Note
Notes/ Action Items ACTION ITEMS/HOMEWORK: 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. [COMPLETED] Notes: 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.

Note

Notes/ Action Items

ACTION ITEMS/HOMEWORK:

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. [COMPLETED]

Notes:

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.

Content

Space Tools

Versions Compared

Old Version 4

New Version Current

Key