January 2020 - Gnso-newgtld-wg

Re: [Gnso-newgtld-wg] What behaviors would we consider undesirable?
by Pruis, Elaine 03 Feb '20

03 Feb '20

All, I have deep reservations about removing the phrase “collusion” from the subpro goals, and potentially, final recommendations. Jeff stated “I am not sure we can say for a fact that collusion occurred “in order to deceive or cheat someone”” but there is plenty of public information suggesting that is exactly what occurred in the last round, both in private contention resolution as well as objection proceedings. From Circle ID 2016:<http://www.circleid.com/posts/20161107_afilias_cynical_attempt_to_secure_a_…> “Afilias' motivation could not be more transparent: in a private auction, either tens of millions of dollars will be paid to it for losing the auction or, if NDC is disqualified, Afilias stands to secure the .web new gTLD at a much lower non-competitive price. Indeed, it was just such maneuvering that caused Afilias to commit, in writing, a demonstrable violation of the Blackout Period as it sought agreement among the contention set to substitute a private for a public auction a few days before the public auction took place. Pursuant to the express terms of the Guidebook, this violation in and of itself could disqualify Afilias.” From Domain Incite, 2018<http://domainincite.com/23758-verisign-says-afilias-tried-to-rig-web-auction>: “Afilias and other bidders proposed that a private auction be performed pursuant to collusive and potentially illegal terms about who could win and who would lose the auction, including guarantees of auction proceeds to certain losers of the auction.” The solution to this problem is to not suggest support for, or even allow for, private auctions. ICANN IRP filings<https://www.icann.org/en/system/files/correspondence/omahoney-et-al-to-klit…> “To make matters worse, it appears that Donuts is acting in collusion with another similarly-situated “group registry” applicant to magnify the adverse impact of these tactics on the Sport Communities. The timing of Donuts’ actions before the Ombudsman and this present IRP filing shows that Donuts and Famous Four Media (“FFM”, the second group registry applicant in the .sport/.sports and .rugby contention sets) collude in their strategy of procedural harassment. Donuts waited for the multiple frivolous proceedings submitted by FFM to be dismissed and then took over. These two portfolio applicants thus managed to maximize the delays suffered by the Sport Communities. IRB Letter at 2-3. As both are funded by venture capital and both are engaged in private and ICANN auctions for many TLDs they have applied for, they have an interest in perpetuating uncertainty as to the status of TLDs that target communities. In this way, they maintain artificial financial valuation for the applications in their portfolio which target communities and were prevailed upon by way of ICANN’s Community-based objections or ICANN’s Community Priority Evaluation.“ Famous Four Media Limited and Donuts Inc. Abusive, Baseless and Harmful Actions Concerning the .Rugby gTLD<applewebdata://ED9A75A6-5E60-4EB2-9E61-0BDFC75BDB27/Famous%20Four%20Media%20Limited%20and%20Donuts%20Inc.%20Abusive,%20Baseless%20and%20Harmful%20Actions%20Concerning%20the%20.Rugby%20gTLD> “The secret, ex parte nature of the actions of Famous Four and Donuts exacerbates their pernicious impact on the IRB.” And, “Now, in a repeat of their earlier strategy, Famous Four has followed the apparent dismissal of the CEP complaint of Donuts with perfectly coordinated timing.” In fact, the classic Vickrey model with bids at application would eliminate contention sets altogether, which could further minimize the tactical use of objection proceedings. For the preservation of ICANN’s reputation and the longevity of the MSM, we as a community need to do everything we can to remove any opportunities for, or even the perception of, misconduct or inappropriate behavior. With the recent .org transaction now widely covered in the mainstream media, there is a lot of focus and attention on ICANN. And many detractors are looking for any excuse to delegitimize the organization. Let’s not give them any more ammunition. Jeff asked, “Are Private Auctions (whether done legitimately or not) undesirable for resolving contention sets? Does it harm the reputation of ICANN or the program?“ YES (see above) Elaine From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Date: Tuesday, January 21, 2020 at 11:21 AM To: Jeff Neuman <jeff.neuman(a)comlaude.com>, "lists(a)christopherwilkinson.eu" <lists(a)christopherwilkinson.eu>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [EXTERNAL] Re: [Gnso-newgtld-wg] What behaviors would we consider undesirable? I have suggested replacing the word “collusion” in the Google doc – see suggested language there. Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Jeff Neuman Sent: Monday, January 20, 2020 3:13 PM To: lists(a)christopherwilkinson.eu; gnso-newgtld-wg(a)icann.org Subject: Re: [Gnso-newgtld-wg] What behaviors would we consider undesirable? [EXTERNAL] ________________________________ Thanks Christopher. Collusion is defined<https://dictionary.cambridge.org/us/dictionary/english/collusion> as “agreement between people to act together secretly or illegally in order to deceive or cheat someone.” I am not sure we can say for a FACT that collusion occurred “in order to deceive or cheat someone.” Yes, parties did work in secret and came up with “agreements”, but the second element or deceit or cheat is just as important. In the last round the Applicant Guidebook not only allowed working in private to resolve contention sets, but it encouraged it. The mere act of having private auctions does not equate to there being collusion. That said, we still may want to list collusion as an “undesirable activity”; but collusion would include the “in order to deceive or cheat someone.” The second question, however, is do we believe that private auctions, in and of themselves, for the New gTLD Program, should be considered “undesirable activity.” Although not “collusion”, we could still attempt to disallow them. That is what we are trying to get a sense of from the group. Are Private Auctions (whether done legitimately or not) undesirable for resolving contention sets? Does it harm the reputation of ICANN or the program? Please note, as one of the Co-Chairs, I am not taking a position on this, other than to note that many of the comments (including from the GAC, ICANN Board, NCSG, some registries, BC, Gov’t of India, etc.) stated in their comments that private auctions where funds are distributed back to the losing applicants, may not be desirable. Other groups, including some registries, the RrSG, the IPC, Neustar, BRG, etc. however, did support private auctions where are applicants agree to participate. Thanks. Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of lists(a)christopherwilkinson.eu<mailto:lists@christopherwilkinson.eu> Sent: Monday, January 20, 2020 3:44 PM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] What behaviors would we consider undesirable? Good evening: I strongly 'suggest' that we do not want to replace the word 'Collusion' in this context. 1. Collusion took place in the last round, otherwise there could not have been any private auctions. 2. The fact that we are discussing this at all strongly suggests - to the outside world - that we would prefer to dissimulate that fact. 3. ICANN is the regulator of the conditions of competition in this sector; if we cannot deal with this matter, it severely undermines the original rationale for having ICANN at all. Regards CW On 17 Jan 2020, at 17:30, Aikman-Scalese, Anne <AAikman(a)lrrc.com<mailto:AAikman@lrrc.com>> wrote: I put some suggested language in the Google doc to replace the word “Collusion”: https://docs.google.com/document/d/16qDoiK6vydQp6a0v9tMvU2l5fcypJY24hCzTIVT… Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Rubens Kuhl Sent: Friday, January 17, 2020 2:58 AM To: Dorrain, Kristine <dorraink(a)amazon.com<mailto:dorraink@amazon.com>> Cc: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] What behaviors would we consider undesirable? Kristine, This is a not a reasonable business adjustment. If the contention set seems "unbeatable", one could withdraw or simply wait the appropriate refund. A similar way to see #2 is a participant in a race that starts extorting other racers when it realises it won't win the race. It doesn't matter that the original intent had good faith; if someone switches to a bad behaviour on the fly, then it's now up for a new assessment of its attitude. Rubens On 16 Jan 2020, at 20:57, Dorrain, Kristine <dorraink(a)amazon.com<mailto:dorraink@amazon.com>> wrote: Hi Rubens, with respect to #2, you admit good faith intent at the time of application. At what point would an applicant’s reasonable business adjustment reacting to the unforeseen business impact of third party applications and business decisions switch the first applicant’s good faith to bad faith? It seems like the community would get to use the benefit of hindsight to judge the reactionary business decisions made by other applications in their business strategy. Kristine From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Rubens Kuhl Sent: Thursday, January 16, 2020 1:14 PM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] What behaviors would we consider undesirable? <Leadership Hat Off> I will start with two different although similar bad behaviours: - Apply with no intention to actually run the TLDs, just to get into private auctions and profit from losing them. - Apply with intent to run the TLDs, but after contention sets are revealed, change strategy to profit from losing some TLDs instead of fighting to get them. Rubens On 16 Jan 2020, at 17:17, Jeff Neuman <jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com>> wrote: All, On the call early this morning (for some of us), while we were discussing the goals/objectives to consider when selecting a mechanism of last resort to resolve string contention, a very important question was asked by a participant on the call. The question demonstrated that what one person believes is “Bad Faith” other people may not believe is “bad faith” with respect to mechanisms to resolve contention sets. So, with the e-mail chain, I would like for members of the Working Group to discuss what behaviors they would consider to be of the type that we would like to preclude? And by the same token, what are the types of activities that we know we would like to allow. For example, we believe from most of the comments that have come in as well as in our discussions, that some forms of private resolution have been deemed acceptable. This includes the creation of joint ventures between applicants (assuming public comment, etc.), potentially revising applications to address concerns (eg., trademark owner agrees to withdraw its application if other applicant agrees to mitigate trademark abuse), 2 trademark owners agree to modify strings to enable both to have their own TLDs (eg., .deltafaucets or .deltaair)), etc. We have also heard from the ICANN Board that they may believe that participating in private auctions with the sole purpose of losing and using those to fund other auctions may not be as desirable. Though the next call with not be on this topic, we did want to put this issue out on e-mail. Please discuss. Thanks. Jeff Neuman Senior Vice President Com Laude | Valideus 1751 Pinnacle Drive Suite 600, McLean VA 22102, USA M: +1.202.549.5079 D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> www.comlaude.com<http://www.comlaude.com/> <image003.jpg> ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com/> _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg(a)icann.org<mailto:Gnso-newgtld-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-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. ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521. _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg(a)icann.org<mailto:Gnso-newgtld-wg@icann.org> https://mm.icann.org/mailman/listinfo/gnso-newgtld-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. ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com> ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.

4 3

New gTLD Subsequent Procedures PDP WG - 30 January 2000 UTC Call - TWO COMMENTS ON THE DISCUSSION
by Aikman-Scalese, Anne 31 Jan '20

31 Jan '20

Dear Jeff et al, I ended up being in the air with no Internet access during the scheduled call time, but have now listened to the recording: I have three comments on the discussion: 1. Adoption of the term “Affirmation”. We will ultimately need to distinguish between an Affirmation that is representative of Consensus or Rough Consensus and an Affirmation (or other category) that results in a “fallback” position to the 2012 AGB or practice due to a failure of the WG to reach Consensus. So the addition of an “Affirmation” category is still a bit unclear in this regard. Is the word “Affirmation” an equivalent to the designation “Consensus”? Will there be more than one category of “Affirmation”? Do we have a clear definition of “Affirmation” for the document that will be published? 2. Applicants “checking the box” re use of Pre-approved RSP. With respect to the RSP “Pre-approval”, it was mentioned on the call that an applicant might “check the box” stating that it would be using a pre-approved RSP. I think we need to consider that applicants might be tempted to prepare an application, not actually having concluded an agreement with a “pre-approved” RSP, and simply have “checked the box” to avoid further costs until the applicant sees whether or not its application can move forward, whether there are other applicants for the same string (string contention), whether there might be Objections, and whether or not it succeeds in the financial evaluation. So what degree of “proof” might be required to verify that the applicant’s RSP services are actually in place? Or do we care whether or not the agreement with the pre-approved RSP is in place at the time of application? If the RSP agreement that is claimed in “check the box” is not in fact in place, does that mean that ICANN could be wasting time in applying other eavaluation processes to the application? 3. Use of Excess application fees. Regarding the change of the “Implementation Guidance” status on the use of excess application fees to a “WG Recommendation”, that seems fine (personal opinion subject to IPC further input), but is there a possible need to cross-reference the Auction Proceeds program that will ultimately be adopted by ICANN? The reason I ask is that the specific purposes listed appear to track the CCWG Auction Proceeds work to some degree. The Board itself may be concerned that it may not be workable on a practical level to implement one solution for Excess Application Fees and another solution for Auction Proceeds. (PERHAPS THE NOTE HERE IS THAT THE RECOMMENDATION SHOULD LIST AUCTION PROCEEDS AS AN “EXTERNAL EFFORT” OR “DEPENDENCY” RELATED TO THIS RECOMMENDATION.) Thank you, Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Julie Hedlund Sent: Thursday, January 30, 2020 2:43 PM To: gnso-newgtld-wg(a)icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 January 2000 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 30 January at 2000 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-01-30+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: Affirmation xx (rationale 1): ACTION ITEM 1: Leadership to consider if there is another category beyond recommendations and implementation guidance, such as things for ICANN Org to consider. Affirmation xx (rationale 2): ACTION ITEM 2: Do some research as to whether we are affirming the second sentence: “Application fees may differ for applicants.” ACTION ITEM 3: Add recommendation or affirmation with modification: Historical costs should not be part of the cost structure. Implementation Guidance xx (rationale 3): ACTION ITEM 4: Add two recommendations: 1) in the AGB section -- add “including all fees” as must be published at that time; 2) in this section -- the reassessment of cost recovery must happen prior to each round. ACTION ITEM 5: Add to deliberations: Example of cost floor. Recommendation xx (rationale 4): ACTION ITEM 6: Change to “must have a plan in place” and then also “must be communicated in advance”. Should also say, “the implementation guidance below describes in more detail how this should be accomplished.” Implementation Guidance xx (rationale 4): ACTION ITEM 7: Clarify/re-write: If a floor is not used then excess fees go to applicants; if a floor is used then excess fees go to the programs identified. Implementation Guidance xx (rationale 4): In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories… ACTION ITEM 8: Change to “excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories…” and change it in brackets to a recommendation, changing “should” to “must”. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkR…. The goal of this exercise is intended to accomplish at least a couple of things, 1) Ensure that the format and level of detail, which emphasizes the recommendations/implementation guidance/affirmations and rationale rather than comprehensive deliberations (and which follows the model established by Work Track 5), is supported by the WG, and 2) Give the WG the opportunity to make substantive progress on finalizing topics. 2.5.1 Application Fees & 2.5.2 Variable Fees -- General comment: Make it clear what is implementation guidance and what is a recommendation. -- This is not implementation versus policy -- this is “must” versus “should”. Affirmation xx (rationale 1): -- Note from ICANN Org: “Note that there was a request from ICANN org to clarify if the suggestion that “all applications should incur the same base application fee amount” extends to scenarios beyond “type of application or number of applications.” For example, would an applicant proposing to use a pre-approved RSP pay the same application fee as one who proposes to operate its own back-end registry functions and thus requiring technical evaluation? The WG may want to improve the language to make this clear.” -- With the should class, will there also be an example or type of a case that shows why it isn't a must?  If it’s a “must” in certain types of cases then it’s helpful to have an example -- reasons for not doing it. -- Should put the technical evaluation as a separate fee if they haven’t gone through the pre-approval process. -- Raises an interesting question about the cost-recovery model. -- Added a comment: “Technical evaluation should be a separate fee if not part of pre-approval program (also, technical evaluation fee would be the same whether as part of pre-approval or not).” -- Are we saying that there could be a base fee and the possible deductions and increases? -- Question: If there is an applicant that applies for 20 strings and they don’t go through the pre-approval would they go through the technical evaluation once or 20 times? Answer: You would only go through the technical evaluation once, which would be consistent with the RSP pre-approval program. But might make more sense for them to do a pre-approval. -- Question: Would the same apply to background checks? Answer: There are some differences from a technical review. Might be some minor cost efficiencies. -- Create a third category: Must/should/might. ICANN “might" want to grant price breaks for multiple applicants for the financial and background checks. -- The more that you put into a pre-approval the more the base fee in theory could go down if there are multiple applications. -- The timing of when various evaluations are conducted also matter. As a side point, there was a suggestion that evaluation (background screening?) be conducted twice - once during application and second, prior to contracting. ACTION ITEM: Leadership to consider if there is another category beyond recommendations and implementation guidance, such as things for ICANN Org to consider. Affirmation xx (rationale 2): -- Do some research as to whether we are affirming the second sentence: “Application fees may differ for applicants.” -- Comments: “The Working Group may want to consider whether it wants to affirm the overall structure of the fee (i.e., historical costs, processing, and contingency).” and “I think the opposite is the case at least with respect to historical costs. I believe the group was against doing that, but we will check.” -- WG agrees with the second comment -- that it doesn’t include historical costs, but we should clarify it as an affirmation. ACTION ITEM: Do some research as to whether we are affirming the second sentence: “Application fees may differ for applicants.” ACTION ITEM: Add recommendation or affirmation with modification: Historical costs should not be part of the cost structure. Affirmation xx (rationale 3): -- Why is the word “generally” there? It is because the fee floor is not part of cost recovery, but we could remove the word “generally”. It does not mean that most WG members agreed but not all. Best to remove it. Implementation Guidance xx (rationale 3): -- Should this be a recommendation? We didn’t make it one because we don’t have all the information on what the costs should be. -- Question: What does this mean? When would the price change happen? Answer: When ICANN figures out what the costs will be for the program then it will determine what will be the revenue-neutral fee. They will also have developed a predetermined threshold. We should make it clear that this would take place before applications are submitted. It would be assessed on a per round basis. (Added as a comment.) -- Reference the fact that this needs to be established as part of the AGB prior to each application round. ACTION ITEM: Add two recommendations: 1) in the AGB section -- add “including all fees” as must be published at that time; 2) in this section -- the reassessment of cost recovery must happen prior to each round. Recommendation xx (rationale 4): -- Add the notion of determining the fees for each subsequent round (“reassessment of cost recovery must happen prior to each round.” -- Question: Is this plan intended to be the administrative arrangements for where ICANN keeps the money? It says that ICANN has to have a plan in place for managing the excess fees, but don’t know what we mean by a plan. Does ICANN have to have a separate bank account until it determines what is excess and what is not? Answer: In cases where there was implementation guidance that was tied together we tried to create a what that goes with a how. There are guidance about what ICANN should do to deal with excess fees and shortfalls. It is less about administration, but that there needs to be some sort of communicated in advance plan as to what will happen if there are excess fees or shortfalls. ACTION ITEM: Change to “must have a plan in place” and then also “must be communicated in advance”. Should also say, “the implementation guidance below describes in more detail how this should be accomplished.” Implementation Guidance xx (rationale 4): -- I thought that in the event that a 'fee floor' is used, any excess fees collected above the floor would be returned to the applicants; and if there were any excess fees that remained from the fee floor this excess would go to things like universal awareness etc. -- Explain what "Universal Awareness" means. ACTION ITEM: Clarify/re-write: If a floor is not used then excess fees go to applicants; if a floor is used then excess fees go to the programs identified. Implementation Guidance xx (rationale 4): In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories… -- Comment: “Recommend this language be changed to: a global communication and awareness campaign about the introduction and availability of new gTLDs.” Should be differentiated from Universal Acceptance. -- Do we need to be more specific? Preference would be to be more specific. -- Change to a recommendation -- “must”? ACTION ITEM: Change to “excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories…” and change it in brackets to a recommendation, changing “should” to “must”. Implementation Guidance xx (rationale 4): To help alleviate the potential burden of an overall budget shortfall, a separate segregated fund should be set up that can be used to absorb any shortfalls and topped-up in a later round. The amount of the contingency should be a predetermined value that is reviewed periodically to ensure its adequacy. -- I would like to think that the segregated fund is off limits to "loans to ICANN". New issues raised in deliberations since publication of the Initial Report, if applicable: -- Comment: “Is it possible to nominate a % of the overall application fee that is intended to be the fee floor? Absent tangible guidance, implementation will be extremely difficult. Further study in the implementation phase will not be helpful if the variables remain unknown.” -- The one variable that will remain unknown is the number of applications. -- One of the things that we did discuss was the recognition that you are running a piece of Internet infrastructure and there is a benefit to doing that. Can we come up with any idea of what we think the value of that is? That may be impossible. That could be added as one of the variables. Whoever is going to determine the floor should take it into consideration. -- Not sure why we are including this paragraph if there is no recommendation coming out of it. It is intended to acknowledge new issues that were raised after the last public comment, but noting that there was no agreement on a recommendation. ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521.

2 1

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Monday, 03 February 2020 at 15:00 UTC
by Julie Hedlund 31 Jan '20

31 Jan '20

Dear all, Please find below the proposed agenda for the call on Monday, 03 February 2020 at 15:00 UTC for 90 minutes: 1. Review Agenda/Statements of Interest 2. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…. The goal of this exercise is intended to accomplish at least a couple of things, 1) Ensure that the format and level of detail, which emphasizes the recommendations/implementation guidance/affirmations and rationale rather than comprehensive deliberations (and which follows the model established by Work Track 5), is supported by the WG, and 2) Give the WG the opportunity to make substantive progress on finalizing topics. * 2.5.3 Application Submission Period * 2.5.5 Terms and Conditions If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Kind regards, Julie Julie Hedlund, Policy Director

1 0

Post Call | New gTLD Subsequent Procedures Working Group call / Thursday, 30 January 2020
by Julie Bisland 30 Jan '20

30 Jan '20

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 30 January 2020 at 20:00 UTC can be found on the agenda wiki page<https://community.icann.org/x/EgVxBw> (attendance included) and the GNSO Master calendar <https://urldefense.proofpoint.com/v2/url?u=http-3A__gnso.icann.org_en_group…> . These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members can join the call, observers can listen to the recordings and read the transcript afterwards. Please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> if you would like to change your status from observer to member. For additional information, you may consult the mailing list archives <http://mm.icann.org/pipermail/gnso-newgtld-wg/> and the main wiki page<https://community.icann.org/x/RgV1Aw>. Thank you. Kind regards, Julie

1 0

Re: [Gnso-newgtld-wg] EBERO / SLAM Data Status and next steps
by Steve Chan 30 Jan '20

30 Jan '20

Dear All, There did not appear to be any comments, questions, or objections to how the EBERO/SLAM data topic was characterized by Jeff, including what will be sought from ICANN Org’s GDD team. The information below will be sent to GDD for their review and resolution. Best, Steve From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Jeff Neuman <jeff.neuman(a)comlaude.com> Date: Wednesday, October 2, 2019 at 8:14 AM To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] EBERO / SLAM Data Status and next steps All, On 23 August 2019, high-level statistics were shared from ICANN org’s SLA Monitoring program (attached). These statistics provided the monthly number of 1) DNS failures 2) RDDS failures and 3) DNS and RDDS failures that reached the EBERO threshold. On 26 August 2019, Donna Austin shared a RySG document which included data previously shared by ICANN org at the Madrid DNS Symposium / GDD Summit (attached). This data provided more detail on group 3 above in particular, including elements like: The cause for why the EBERO threshold was reached (i.e., DNS/DNSSEC or RDDS) A further, more specific breakdown within each of the two categories that indicate why the EBERO threshold was reached (e.g., IPv6 transport error, broken chain of trust in DNSSEC, etc.) Within our Working Group there has been some discussion about what impact this data may have. For example, we discussed whether past failures should have any impact on future application evaluations or RSP pre-approval for future rounds? The Working Group, however, is trending towards agreeing that evaluation and thus RSP pre-approval (which is likely to leverage the same or substantially the same evaluation criteria) should be forward looking and not be impacted by past performance. The Working Group is also trending towards requiring the pre-approval prior to each evaluation round and that the approval will be good for the duration of the then-current round. A second area in which this data could have an impact is whether or not existing Registry Service Providers should be grandfathered into any future pre-approval processes? Based on the Working Group’s deliberations and public comment received, the answer appears to be no. Most of the comments seem to point to requiring all RSPs (whether new or existing) to go through the same processes in future rounds. Therefore, based on where the Working Group is heading, the Co-Chairs do no believe that we are in need of additional historical data for purposes of finalizing its work on the RSP Pre-approval program. We recognize that registry service provider performance has been a topic of discussion for matters other than the pre-approval program. We understand that there has been discussion about whether the relatively high number of registry services failures indicates that RSP might need to improve how they operate to ensure the security and stability of the DNS. While this WG is forward looking and not intending to impose new commitments for existing RSPs, lessons may be learned to improve the evaluation process for future applicants/RSPs. Based on the above, the WG believes it does need more context from GDD to understand the data it has been provided, since not all SLA failures are equally harmful. Therefore in looking at the failures, for example, the WG needs clarity on whether they refer to service availability or Round Trip Time (RTT). The WG also wants to try and examine if there was any harm caused by the downtime, which is benefitted in part by understanding the timing of the failure (e.g., prior to Sunrise, during Sunrise, before General Availability, after GA). For the failures that did NOT reach the EBERO threshold, the WG would like summary data of which of the SLRs was missed. For the failures that DID reach the EBERO threshold, a detailed breakdown (e.g., similar specificity that was shared at the Madrid DNS Symposium / GDD Summit), which includes the timing of the failure. This information may help identify weaknesses in the evaluation criteria, registry system testing, and/or contractual requirements captured in the Registry Agreement. The leadership intends to send the request for additional context next week, but we would like to know if there are any comments from the Working Group. Thanks for your attention to this matter. Best regards, Jeff Neuman and Cheryl Langdon-Orr SubPro PDP Co-Chairs The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com

3 4

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 January 2000 UTC
by Julie Hedlund 30 Jan '20

30 Jan '20

Dear Working Group members, Please see below the notes from the meeting on 30 January at 2000 UTC. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording, transcript, or the chat, which will be posted at: https://community.icann.org/display/NGSPP/2020-01-30+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: Affirmation xx (rationale 1): ACTION ITEM 1: Leadership to consider if there is another category beyond recommendations and implementation guidance, such as things for ICANN Org to consider. Affirmation xx (rationale 2): ACTION ITEM 2: Do some research as to whether we are affirming the second sentence: “Application fees may differ for applicants.” ACTION ITEM 3: Add recommendation or affirmation with modification: Historical costs should not be part of the cost structure. Implementation Guidance xx (rationale 3): ACTION ITEM 4: Add two recommendations: 1) in the AGB section -- add “including all fees” as must be published at that time; 2) in this section -- the reassessment of cost recovery must happen prior to each round. ACTION ITEM 5: Add to deliberations: Example of cost floor. Recommendation xx (rationale 4): ACTION ITEM 6: Change to “must have a plan in place” and then also “must be communicated in advance”. Should also say, “the implementation guidance below describes in more detail how this should be accomplished.” Implementation Guidance xx (rationale 4): ACTION ITEM 7: Clarify/re-write: If a floor is not used then excess fees go to applicants; if a floor is used then excess fees go to the programs identified. Implementation Guidance xx (rationale 4): In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories… ACTION ITEM 8: Change to “excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories…” and change it in brackets to a recommendation, changing “should” to “must”. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkR…. The goal of this exercise is intended to accomplish at least a couple of things, 1) Ensure that the format and level of detail, which emphasizes the recommendations/implementation guidance/affirmations and rationale rather than comprehensive deliberations (and which follows the model established by Work Track 5), is supported by the WG, and 2) Give the WG the opportunity to make substantive progress on finalizing topics. 2.5.1 Application Fees & 2.5.2 Variable Fees -- General comment: Make it clear what is implementation guidance and what is a recommendation. -- This is not implementation versus policy -- this is “must” versus “should”. Affirmation xx (rationale 1): -- Note from ICANN Org: “Note that there was a request from ICANN org to clarify if the suggestion that “all applications should incur the same base application fee amount” extends to scenarios beyond “type of application or number of applications.” For example, would an applicant proposing to use a pre-approved RSP pay the same application fee as one who proposes to operate its own back-end registry functions and thus requiring technical evaluation? The WG may want to improve the language to make this clear.” -- With the should class, will there also be an example or type of a case that shows why it isn't a must?  If it’s a “must” in certain types of cases then it’s helpful to have an example -- reasons for not doing it. -- Should put the technical evaluation as a separate fee if they haven’t gone through the pre-approval process. -- Raises an interesting question about the cost-recovery model. -- Added a comment: “Technical evaluation should be a separate fee if not part of pre-approval program (also, technical evaluation fee would be the same whether as part of pre-approval or not).” -- Are we saying that there could be a base fee and the possible deductions and increases? -- Question: If there is an applicant that applies for 20 strings and they don’t go through the pre-approval would they go through the technical evaluation once or 20 times? Answer: You would only go through the technical evaluation once, which would be consistent with the RSP pre-approval program. But might make more sense for them to do a pre-approval. -- Question: Would the same apply to background checks? Answer: There are some differences from a technical review. Might be some minor cost efficiencies. -- Create a third category: Must/should/might. ICANN “might" want to grant price breaks for multiple applicants for the financial and background checks. -- The more that you put into a pre-approval the more the base fee in theory could go down if there are multiple applications. -- The timing of when various evaluations are conducted also matter. As a side point, there was a suggestion that evaluation (background screening?) be conducted twice - once during application and second, prior to contracting. ACTION ITEM: Leadership to consider if there is another category beyond recommendations and implementation guidance, such as things for ICANN Org to consider. Affirmation xx (rationale 2): -- Do some research as to whether we are affirming the second sentence: “Application fees may differ for applicants.” -- Comments: “The Working Group may want to consider whether it wants to affirm the overall structure of the fee (i.e., historical costs, processing, and contingency).” and “I think the opposite is the case at least with respect to historical costs. I believe the group was against doing that, but we will check.” -- WG agrees with the second comment -- that it doesn’t include historical costs, but we should clarify it as an affirmation. ACTION ITEM: Do some research as to whether we are affirming the second sentence: “Application fees may differ for applicants.” ACTION ITEM: Add recommendation or affirmation with modification: Historical costs should not be part of the cost structure. Affirmation xx (rationale 3): -- Why is the word “generally” there? It is because the fee floor is not part of cost recovery, but we could remove the word “generally”. It does not mean that most WG members agreed but not all. Best to remove it. Implementation Guidance xx (rationale 3): -- Should this be a recommendation? We didn’t make it one because we don’t have all the information on what the costs should be. -- Question: What does this mean? When would the price change happen? Answer: When ICANN figures out what the costs will be for the program then it will determine what will be the revenue-neutral fee. They will also have developed a predetermined threshold. We should make it clear that this would take place before applications are submitted. It would be assessed on a per round basis. (Added as a comment.) -- Reference the fact that this needs to be established as part of the AGB prior to each application round. ACTION ITEM: Add two recommendations: 1) in the AGB section -- add “including all fees” as must be published at that time; 2) in this section -- the reassessment of cost recovery must happen prior to each round. Recommendation xx (rationale 4): -- Add the notion of determining the fees for each subsequent round (“reassessment of cost recovery must happen prior to each round.” -- Question: Is this plan intended to be the administrative arrangements for where ICANN keeps the money? It says that ICANN has to have a plan in place for managing the excess fees, but don’t know what we mean by a plan. Does ICANN have to have a separate bank account until it determines what is excess and what is not? Answer: In cases where there was implementation guidance that was tied together we tried to create a what that goes with a how. There are guidance about what ICANN should do to deal with excess fees and shortfalls. It is less about administration, but that there needs to be some sort of communicated in advance plan as to what will happen if there are excess fees or shortfalls. ACTION ITEM: Change to “must have a plan in place” and then also “must be communicated in advance”. Should also say, “the implementation guidance below describes in more detail how this should be accomplished.” Implementation Guidance xx (rationale 4): -- I thought that in the event that a 'fee floor' is used, any excess fees collected above the floor would be returned to the applicants; and if there were any excess fees that remained from the fee floor this excess would go to things like universal awareness etc. -- Explain what "Universal Awareness" means. ACTION ITEM: Clarify/re-write: If a floor is not used then excess fees go to applicants; if a floor is used then excess fees go to the programs identified. Implementation Guidance xx (rationale 4): In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories… -- Comment: “Recommend this language be changed to: a global communication and awareness campaign about the introduction and availability of new gTLDs.” Should be differentiated from Universal Acceptance. -- Do we need to be more specific? Preference would be to be more specific. -- Change to a recommendation -- “must”? ACTION ITEM: Change to “excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories…” and change it in brackets to a recommendation, changing “should” to “must”. Implementation Guidance xx (rationale 4): To help alleviate the potential burden of an overall budget shortfall, a separate segregated fund should be set up that can be used to absorb any shortfalls and topped-up in a later round. The amount of the contingency should be a predetermined value that is reviewed periodically to ensure its adequacy. -- I would like to think that the segregated fund is off limits to "loans to ICANN". New issues raised in deliberations since publication of the Initial Report, if applicable: -- Comment: “Is it possible to nominate a % of the overall application fee that is intended to be the fee floor? Absent tangible guidance, implementation will be extremely difficult. Further study in the implementation phase will not be helpful if the variables remain unknown.” -- The one variable that will remain unknown is the number of applications. -- One of the things that we did discuss was the recognition that you are running a piece of Internet infrastructure and there is a benefit to doing that. Can we come up with any idea of what we think the value of that is? That may be impossible. That could be added as one of the variables. Whoever is going to determine the floor should take it into consideration. -- Not sure why we are including this paragraph if there is no recommendation coming out of it. It is intended to acknowledge new issues that were raised after the last public comment, but noting that there was no agreement on a recommendation.

1 0

Correction: Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 30 January 2020 at 20:00 UTC
by Julie Hedlund 29 Jan '20

29 Jan '20

Dear all, Please find below the proposed agenda for the call on Thursday, 30 January 2020 at 20:00 UTC for 90 minutes (note correction from 60 minutes): 1. Review Agenda/Statements of Interest 2. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…. The goal of this exercise is intended to accomplish at least a couple of things, 1) Ensure that the format and level of detail, which emphasizes the recommendations/implementation guidance/affirmations and rationale rather than comprehensive deliberations (and which follows the model established by Work Track 5), is supported by the WG, and 2) Give the WG the opportunity to make substantive progress on finalizing topics. * 2.5.1 Application Fees & 2.5.2 Variable Fees If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Kind regards, Julie Julie Hedlund, Policy Director

1 0

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 30 January 2020 at 20:00 UTC
by Julie Hedlund 29 Jan '20

29 Jan '20

Dear all, Please find below the proposed agenda for the call on Thursday, 30 January 2020 at 20:00 UTC for 60 minutes: 1. Review Agenda/Statements of Interest 2. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…. The goal of this exercise is intended to accomplish at least a couple of things, 1) Ensure that the format and level of detail, which emphasizes the recommendations/implementation guidance/affirmations and rationale rather than comprehensive deliberations (and which follows the model established by Work Track 5), is supported by the WG, and 2) Give the WG the opportunity to make substantive progress on finalizing topics. * 2.5.1 Application Fees & 2.5.2 Variable Fees If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Kind regards, Julie Julie Hedlund, Policy Director

1 0

Meeting Invitation Webinar | EPDP - Phase 2 Proposed Recommendations on a Standardized System for Access and Disclosure | Thursday, 13 February 2020 at 14:00 UTC
by Terri Agnew 29 Jan '20

29 Jan '20

Dear all, Please find the details below for the EPDP - Phase 2 Proposed Recommendations on a Standardized System for Access and Disclosure Webinar. This webinar will provide an overview of the EPDP’s Phase 2 proposed recommendations for a Standardized System for Access and Disclosure (SSAD). This effort builds upon the EPDP’s Phase 1 work on enhancing Registration Data Services where, under certain circumstances, personal contact information is now redacted. The Phase 2 effort for developing the SSAD will allow for disclosure of this redacted contact information based on third-party legitimate interests, administration proceedings, and law enforcement needs, subject to applicable law and the rights of the data subject. The webinar will highlight each of the EPDP Team’s recommendations and will provide an opportunity for participants to ask questions and provide feedback on the Initial Report, which is currently out for public comment. The report can be found on the public comment proceedings section on https://www.icann.org/public-comments [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_public-2…>, and the webinar materials will be posted on the EPDP’s wiki page<https://community.icann.org/x/6g6JBw> following the webinar. Thursday, 13 February 2020 at 14:00 UTC for 60 minutes For other times: https://tinyurl.com/wsm7h3y [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_wsm7h3y&d=…> Join Zoom Meeting: https://icann.zoom.us/s/331729252 [icann.zoom.us]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.zoom.us_s_331729…> Meeting ID: 331 729 252 Password: 586730 One tap mobile +16699006833,,331729252# US (San Jose) +19294362866,,331729252# US (New York) Find your local number: https://icann.zoom.us/u/abQBVd1jHM [icann.zoom.us]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.zoom.us_u_abQBVd…> Slides to assist you with Zoom: Welcome to Zoom: https://icann.box.com/shared/static/1sal3l5qf4csdukt0pk2c75ey3bte22z.pdf [icann.box.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.box.com_shared_s…> Zoom FAQ: https://icann.box.com/shared/static/d5rap0g6xphevhkdd3mhu2hy753l2m3s.pdf [icann.box.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.box.com_shared_s…> If Zoom disappears, see instructions:https://gnso.icann.org/sites/default/files/policy/2019/present…<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_d…> A calendar invitation has equally been attachment for you to download to your calendar. Thank you in advance for reserving this time in your schedule. Kind Regards, Terri

1 0

Nomination Opens for ICANN Community Excellence Award
by Nathalie Peregrine 29 Jan '20

29 Jan '20

https://www.icann.org/news/announcement-2-2020-01-27-en [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_ann…> ICANN Launches Dr. Tarek Kamel Award and Opens Nomination for ICANN Community Excellence Award LOS ANGELES - 27 January 2020 – Today, the Internet Corporation for Assigned Names and Numbers (ICANN) announced a new award, the Dr. Tarek Kamel Award for Capacity Building. This award recognizes ICANN community members for significant efforts in developing capacity in areas related to ICANN's mission. Dr. Tarek Kamel Award for Capacity Building The award is established in honor of the late Dr. Tarek Kamel, an Internet pioneer known for his contributions to global Internet governance. At the time of his passing, Kamel was ICANN's Senior Advisor to the President and Senior Vice President for Government and Intergovernmental Organization Engagement. This annual award will be presented to one individual during ICANN's Annual General Meeting, held in the fourth quarter each year. The ideal recipient will have: · Contributed significantly to national, regional, or global capacity-development programs related to ICANN's mission. · Developed capacity-building programs that positively influenced the multistakeholder and diversified participation at ICANN. Details about the award selection process will be available in May 2020. Nomination Opens for ICANN Community Excellence Award The Multistakeholder Ethos Award has been renamed the ICANN Community Excellence Award. ICANN is accepting nominations for this year's award, which will be presented at ICANN68 Kuala Lumpur in June 2020. The ICANN Community Excellence Award recognizes community members who have significantly invested in consensus-based solutions and have contributed substantively to the ICANN multistakeholder model. The ideal recipient(s) will have: · Participated in the ICANN community for a minimum of five years. · Served in multiple ICANN working groups or committees. · Collaborated significantly with more than one Supporting Organization (SO) or Advisory Committee (AC). Candidates will be evaluated by a panel of ICANN community members appointed by the SO/AC chairs using a merit-based point system, using three criteria: 1. Demonstrates an ability to work across community lines with both familiar and unfamiliar ICANN stakeholders with the aim of building consensus. 2. Facilitates dialogue and open discussion in a fair and collegial manner through the spirit of collaboration, showing empathy and demonstrating a sincere desire to engage with people from other backgrounds, cultures, and interests. 3. Demonstrates additional support for the ICANN multistakeholder model and its overall effectiveness through volunteer service via working groups or committees. Please submit nominations via this nomination form [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_forms_…>. Include detailed information outlining why the nominee meets the award criteria. Any additional information in support of nominations and questions about the award process may be submitted to excellenceaward2020(a)icann.org<mailto:excellenceaward2020@icann.org>. For more information, please consult the ICANN Community Wiki.<https://community.icann.org/x/YyOAAw>

1 0