- Gnso-newgtld-wg - lists.icann.org

Post Call | New gTLD Subsequent Procedures Working Group call on Thursday, 06 February 2020 at 20:00 UTC
by Andrea Glandon Feb. 7, 2020

Feb. 7, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 06 February 2020 at 20:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/GAVxBw> (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, Andrea

1 0

Re: [Gnso-newgtld-wg] [Ext] RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC
by Julie Hedlund Feb. 6, 2020

Feb. 6, 2020

Hi Anne, I did not capture that, but please note that as stated these are high-level notes, not verbatim. The definitive source is the recording and transcript. Also, if you would like this to be considered by the WG putting it on the list as you have done below is helpful. Kind regards, Julie From: "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Date: Thursday, February 6, 2020 at 5:42 PM To: Julie Hedlund <julie.hedlund(a)icann.org>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Ext] RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC Thanks Julie – Were you able to capture in the notes the views put forward to the effect that a proposal to ban new applications for strings not yet withdrawn is in fact “Policy” and not “Implementation Guidance”? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Julie Hedlund Sent: Thursday, February 6, 2020 3:02 PM To: gnso-newgtld-wg(a)icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 06 February 2000 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 06 February 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-02-06+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: Work Plan: ACTION ITEM: Staff will send a link to the revised work plan/timeline. 2.2.1 Continuing Subsequent Procedures ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. ACTION ITEM: Change text as follows: “Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application round [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Notes: 1. Updates to Statements of Interest: -- Avri Doria will be participating as one of the Board Liaisons to the WG. The other Board Liaison is Becky Burr. -- Question: What does that mean in terms of the role of the Board Liaison? Answer: Largely a constrained role; carrying things back and forth between the Board caucus that will be following it -- bringing questions and possibly answers. -- The goal is not for us to be participants in the PDP, but we want to avoid surprises, such as something that the Board wouldn’t be able to do. 2. Work Plan -- GNSO Council is trying to ensure realistic deadlines for the PDP WGs and to manage the policy development work. -- One of the PDP 3.0 recommendations that has been implemented is the need for Project Change Requests when the dates of deliverables cannot be met. As you may know the RPMs PDP WG submitted a Project Change Request for the GNSO Council meeting in January and is revising that request. -- The SubPro PDP WG Co-Chairs have been asked to submit a modified work plan along with the Project Change Request for the Council to consider at its meeting on 20 February. -- This is a worst case scenario to avoid having to do another request, but we expect to be able to shave some time off of this. -- New work plan shows the schedule of meetings to cover all of the topics. -- Unless the WG can work faster it would be delivering a Final Report by the end of 2020. -- This is just a preview; a link will be sent later. -- This is assuming a two meetings per week schedule. -- Some of these topics may not take two full meetings, but we’ve built that in as a buffer. -- Some things we could do to streamline this. One that we’ll suggest to the WG and GNSO Council is to have a couple of extended sessions in April and May -- in lieu of face-to-face meetings. Such as two 3-hour sessions in April and May we could save a month or more. -- New working method: Take after EPDP and ask the WG members to consider what they can live with, with an emphasis on suggesting solutions. -- Goal is to get the revised work plan and Project Change Request to the Council by early next week. -- Agree that we would need to schedule longer sessions well in advance, say two months. ACTION ITEM: Staff will send a link to the revised work plan/timeline. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…>. Structure: -- Affirmations are confirming the 2012 policy/AGB. -- Recommendations are things that must happen. -- Implementation Guidance are things that should happen. a. 2.2.1 Continuing Subsequent Procedures Affirmation xx (see rationale 1): The Working Group recommends that the existing policy contained in the 2012 Applicant Guidebook, that a “systematized manner of applying for gTLDs be developed in the long term,” be maintained. Affirmation xx (see rationale 2): The Working Group affirms Principle A and recommends that the New gTLD Program must continue to be administered “in an ongoing, orderly, timely and predictable manner.” Affirmation xx (see rationale 3): The Working Group affirms that the primary purposes of new gTLDs are to foster diversity, encourage competition, and enhance the utility of the DNS. Recommendation xx (see rationale 3). Accordingly, the Working Group recommends that meaningful metrics must be identified to understand the impact of the New gTLD Program. The metrics, broadly speaking, should focus on the areas of trust, competition, and choice. To review metrics, data must be collected at a logical time to create a basis against which future data can be compared. Discussion: -- On the recommendation: Should we cite section 5 of the CCT-RT Final Report for the types of data? There is still some uncertainty as to what will be adopted from that Final Report, so it would be preferable that this could be part of Implementation Guidance. Not trying to override ICANN Org’s plans. -- Re: metrics -- never seen any commitment from ICANN Org to collect and publish the metrics as recommended by the CCT Final Report. Don’t see how these can be collected. -- There was discussion in the SubPro Initial Report and in the CCT-RT Final Report; ICANN is aware of the discussions and has a schedule concerning the recommendations. -- Question from ICANN Org re: the recommendation: Is this some other framework that gets set up to measure the trust, competition, and choice goals over time. Answer: Some of it would be part of the implementation; we wanted a general recommendation about collecting data, but didn’t want to get into a debate on the details. We wanted to leave it to implementation as to what types of data would be collected and how. -- Question: Was this particular recommendation adopted by the Board or no? Should we refer to data gathering in accordance with whatever Board adopts in relation to the CCT recommendation? Answer: We will add this as Implementation Guidance. ACTION ITEM: Add Implementation Guidance that any data gathering would be in accordance with the Board adoption of the CCT-RT recommendation. Note also the sources of metrics in the footnote. b. 2.2.3 Applications Assessed in Rounds Affirmation xx (with modification) (see rationale 1): The Working Group affirms recommendation 13 from the 2007 policy, which states: “Applications must initially be assessed in rounds until the scale of demand is clear.” However, the Working Group believes that the words “initially” and “until the scale of demand is clear” be removed from the sentence and should just read “Applications must be assessed in rounds.” Recommendation xx (see rationale 2): Upon the commencement of the next Application Submission Period, there must be clarity around the timing and/or criteria for initiating subsequent procedures from that point forth. More specifically, prior to the commencement of the next Application Submission Period, ICANN shall publish either (a) the date in which the next subsequent introduction of new gTLDs will take place or (b) the specific set of criteria and/or events that must occur prior to the opening up of the next subsequent process. Implementation Guidance xx (see rationale 2): A new round may initiate even if steps related to application processing and delegation from previous application windows have not been completed. Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application opportunity. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application opportunity, unless and/or until the applications from the previous round that match those strings have had their final disposition. Discussion: -- Comment: May be worth seeing if the WG can narrow in on a preference here. Or perhaps this makes sense as an unless in a sense, so the date is the preference, unless there is non-exhaustive list of things that would prevent the timely launch? Question: Preference for ICANN Org to set a date, or instead to say what has to happen before a next round? -- In Implementation Guidance we suggested two options since comments were widely varied. -- The first option adds to predictability for applicants. Else applicants may be in limbo for an unknown period of time. -- The second option gets pretty complicated when you are trying to determine contention sets. Not sure how you would do it. -- This is not meant to allow someone to get into an already existing contention set. In both of these cases nothing is going to be processed in a subsequent round until every contention set is resolved and done from the previous round. -- Recommendation: preference is that ICANN publish a date.  -- Implementation Guidance: preference is that it should not be possible to apply for a string that is still being processed from a previous application opportunity. -- Disagree that strings from last round should be prohibited. Second option supports the notion of Applicant freedom of expression. -- From a process perspective the above comment would add complications that really aren't warranted. -- No evaluation of the new applicant would occur until the 2012 applications are resolved. The new applicants would have to accept that risk. -- Concerns about treating moribund applications made a decade ago as reservations for the next round. Are the strings that are withdrawn due to name collisions undergoing a process, or are they just on hold? -- What is the harm in keeping a particular string closed for new apps until all the previous applicants have fallen by the wayside. Then it opens up again for all. -- Because the window for application is closed at that point and we haven't said that a new window could open if they all fail. -- If there is agreement that rounds are the path forward, then if a string does not go through in one round it will become available in another round. -- That's one of our recommendations that there will be a series of windows. -- Is there any WG member that would die in a ditch over this option: “It should not be possible to apply for a string in a subsequent round that is still being processed from a previous application round.”? -- Favor the second option. -- Can't live with prohibiting applications for the same string. If "shall not proceed" means new applicants can still apply, I can live with that. -- What about applications that have not progressed on purpose? Or for technical reasons? -- From a pragmatic perspective if we allow for applicants to submit applications for a string that is already in process that adds layers of complexity to the process. If a string hasn’t gone forward to delegation and it becomes available again then it can be applied for. -- We don’t have a system in place that allows for continuing application periods, we have rounds. People should be waiting their turn but they can get in line -- violates applicants’ freedom of expression if they can’t apply. -- The point of the first recommendation is that ICANN Org will set a date certain or criteria that must occur. We are trying to get to a steady state process. -- If someone could apply for a string that is still in process, what we may be encouraging is applicants who might not be fully processed to apply in the next round if they think they are going to fail in the previous round. Need to define in implementation what “in process” means. -- If it would be possible to file applications for the same string in future rounds the door is open for gaming and unknown consequences: applicant(s) from the first round might consider future applicants in their behaviour and decisions. -- Surely, all delegated TLDs or those in process, are off limits. -- I think applicant freedom of expression means you can apply for any string you want, but I don't think that extends to TLDs already in existence or those that are in process in some way. -- Delegated TLDs are not under discussion. -- The point here are those that are not “in process”, so we need to define “in process”. -- Old applications that were denied for a policy reason should have to step up to new policy recommendations if they are going to prevail/ proceed and they should be encouraged to do so by knowing there may be applicants standing in line who are willing to do so. (No stonewalling on new policy recommendations - no blocking based on old policy positions.)  -- We already have many categories of Application Status (Active, Applicant Support, Delegated, etc.) -- Question: What about the status “Not Approved”? Answer: That only applies when an application has gone through all of the steps. There will be one or two edge cases. -- Let’s say that we are talking about the names collisions issues and strings that were not delegated -- if new policy is developed by NCAP and may come out of the Board. If there isn’t a new policy they shouldn’t be able to block new applicants. -- An applicant from a prior round who does not want to meet new policy recommendations can block a string forever by not withdrawing a Not Approved application. ACTION ITEM: Change Implementation Guidance to: “Implementation Guidance xx (see rationale 2): It should not be possible to apply for a string that is still being processed from a previous application round [delete “opportunity”]. OR Do not process applications further than the reveal stage for a string that is still being processed from a previous application round [delete “opportunity”], unless and/or until the applications from the previous round that match those strings have had their final disposition.” Recommendation xx (see rationale 2): Application procedures must take place at predictable, regularly occurring intervals without indeterminable periods of review unless the GNSO Council recommends pausing the program and such recommendation is approved by the Board. Unless and until other procedures are recommended by the GNSO Council and approved by the ICANN Board, ICANN must only use “rounds” as part of the New gTLD Program. Recommendation xx (see rationale 2): Absent extraordinary circumstances, future reviews and/or policy development processes, including the next CCT Review, should take place concurrently with subsequent application rounds. In other words, future reviews and/or policy development processes must not stop or delay subsequent new gTLD rounds. Recommendation xx (See rationale 2). If the outputs of any reviews and/or policy development processes has, or could reasonably have, a material impact on the manner in which application procedures are conducted, such changes must only apply to the opening of the application procedure subsequent to the adoption of the relevant recommendations by the ICANN Board. Discussion: -- Look at these recommendations together. -- If we are clear that applications need to follow all of the timelines before becoming “Not Approved” then they cannot block in future rounds. -- If you have a new policy in the next round that eliminated the problem that blocked a previous string then it should be able to be applied for in the next round. -- Let’s say that .home can move forward but only as a closed generic or .brand where there is a one registrant TLD. What if one of the applicants for .home has no interest in that? Their application needs to be dead. -- Those (.home, .corp, .mail) are not withdrawn even though "not approved". If the Board adopts new name collision policy, old applicants should be willing to step up to the new name collision policy and not be able to refuse to do so and block the string forever by not withdrawing the application. -- Rules should apply in each round to those applicants. -- If you can’t live with the language please suggest new language. -- Problem seems to be how to fix the “Not Approved” applications from the previous round. Board may have to decide how to deal with them. That is out of scope for this WG. ________________________________ 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

Re: [Gnso-newgtld-wg] What behaviors would we consider undesirable?
by Pruis, Elaine Feb. 4, 2020

Feb. 4, 2020

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

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 06 February 2020 at 20:00 UTC
by Julie Hedlund Feb. 4, 2020

Feb. 4, 2020

Dear all, Please find below the proposed agenda for the call on Thursday, 06 February 2020 at 20: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…. * 2.2.1 Continuing Subsequent Procedures * 2.2.3 Applications Assessed in Rounds 3. AOB 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

Re: [Gnso-newgtld-wg] [Ext] RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 03 February 1500 UTC
by Julie Hedlund Feb. 3, 2020

Feb. 3, 2020

Anne, Thank you for the helpful clarification. Kind regards, Julie From: "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Date: Monday, February 3, 2020 at 5:10 PM To: Julie Hedlund <julie.hedlund(a)icann.org>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Ext] RE: Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 03 February 1500 UTC Julie, There appears to be an error in ACTIN ITEM 2. The word “only” was not supposed to be deleted. The word “only” should remain in the text or it does not express what the WG was agreeing on the call. The meaning is to limit the grounds for rejection to the provisions of the AGB. The deletion is “be permitted to”. Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Julie Hedlund Sent: Monday, February 3, 2020 9:45 AM To: gnso-newgtld-wg(a)icann.org Subject: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 03 February 1500 UTC [EXTERNAL] ________________________________ Dear Working Group members, Please see below the notes from the meeting on 03 February 1500 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-02-03+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: 2.5.3 Application Submission Period: ACTION ITEM 1: Change the language of the recommendation in brackets as follows: “The Working Group recommends that for the next application window and subsequent application windows, [absent “extenuating or extraordinary” circumstances] the application submission period must be a fixed period of 13 weeks” Delete “three (3) months” [and should not begin or end on a weekend.] 2.5.5 Terms and Conditions: ACTION ITEM 2: First recommendation: Change “should” to “must” and delete “only be permitted to” from the first sentence: “Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN [must]should reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization [must]should cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.” Implementation Guidance xx: A framework for ICANN to make transparent changes to the Applicant Guidebook should be provided (see recommendations under Section Predictability). This framework should include available recourse for applicants, including the right to change an application or withdraw an application from ICANN’s consideration in exchange for a full refund, where applicable. This Implementation Guidance constitutes a revision to Section 14 of the Terms and Conditions from the 2012 round. Implementation Guidance xx: If the true risk of name collisions will be determined after the application is filed, ICANN should provide a full refund to applicants in cases where a new gTLD is applied for but later is disqualified because of risk of Name Collision. ACTION ITEM 3: Check the terminology -- Use consistent terminology - "not approved" or "will not proceed" and cross-reference the application change section. Re: The Working Group discussed the issue of confidentiality with respect to the Recommendation xx that ICANN should specify the reason that it has rejected an application. ACTION ITEM 4: Add Implementation Guidance language on confidentiality. ACTION ITEM 5: Add “Application Changes” to the list of dependencies. 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… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…>. Overview: -- Question: What was the relationship between “affirmations” and “consensus”? Answer: These are two different concepts. We will be taking consensus calls on everything -- whether it is an affirmation, recommendation, or implementation guideline. -- Question: Affirmation seems quite intertwined with the concept of consensus. How does that relate to people who don’t agree with that affirmation? Answer: We hope you would let us know prior to taking a consensus call -- perhaps by changing the language, or changing it to a different type, such as a recommendation. We’ll also have a preamble that will explain what are the different categories. -- Think of it as an affirmative recommendation. Default to the 2012 round will be stated differently -- noting that not everyone agreed. -- Question: If we have default where we don’t agree, what about things we didn’t discuss? a. 2.5.3 Application Submission Period Recommendation xx: The Working Group recommends that for the next application window and subsequent application windows, the application submission period must be a fixed period of three (3) months. -- We aren’t really affirming what happened last time (as we don’t agree), but making a recommendation. -- What we talked about and had agreement in the comments we said at least 3 months, but that leaves open a whole bunch of different possibilities. This recommendation says 3 months, but there was discussion about longer periods. Discussion: -- In this discussion there might be a dependency relating for time for translation of the AGB in all of the different languages -- it should be consistent. -- On the translations issue we had implementation guidance that the non-English version should come out at or the same time as the English version. -- It should be a fixed period of time and should be consistent. -- Not just due to circumstances — it should changeable based on policy considerations and objectives -- 90-120 day. -- If it's not a fixed time, then who decides and when? -- Agree not less than 90 nor more than 120. -- Hence 12 weeks works and applies a reasonable structure . -- The implementation guidelines could say that the period should not end over a weekend, or say that it ends on a Wednesday. Say that the week runs from a Wednesday to a Wednesday. ACTION ITEM: Change the language of the recommendation in brackets as follows: “The Working Group recommends that for the next application window and subsequent application windows, [absent “extenuating or extraordinary” circumstances] the application submission period must be a fixed period of 13 weeks” Delete “three (3) months” [and should not begin or end on a weekend.] b. 2.5.5 Terms and Conditions Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN must only be permitted to reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization must cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaw for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round. Discussion: -- Question: If we say “must” instead of “should” are we putting the Board in a position of not adopting a recommendation subject to GAC advice. Answer: The GAC advice led to unpredictability so this is a pretty strong recommendation from the comments that we got in on the Initial Report. -- Question: Are we able to accommodate name collisions, or things that we didn’t think about? Answer: That is in the first sentence. -- This should be viewed as a compromise position since ICANN shouldn’t be able to avoid having it’s decisions challenged in court. -- If ICANN acts inconsistently with the AGB or the Bylaws there are ways to challenge the decisions. This is all challengeable in some way and allows for accountability. -- Should we delete “be permitted” in the first sentence? ACTION ITEM: First recommendation: Change “should” to “must” and delete “only be permitted to” from the first sentence: “Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN [must]should reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization [must]should cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.” Implementation Guidance xx: A framework for ICANN to make transparent changes to the Applicant Guidebook should be provided (see recommendations under Section Predictability). This framework should include available recourse for applicants, including the right to change an application or withdraw an application from ICANN’s consideration in exchange for a full refund, where applicable. This Implementation Guidance constitutes a revision to Section 14 of the Terms and Conditions from the 2012 round. Discussion: -- What does the “where applicable” comes from - is it because of the difference between those who may not get a full refund. -- Putting in a full refund for any change to the AGB could be challenging. Not sure the WG could decide where a full refund should be made available. It is a qualifier that a full refund is not provided in all circumstances. -- Does the WG have a suggestion for the types of changes that would require a full refund? This doesn’t take into account that there are portions of the program that don’t get implemented until the end so there is a potential for changes. -- When we talk about application changes we provide more detail. Where and ICANN change materially changes the nature of an application, for example. ACTION ITEM: Check the terminology -- Use consistent terminology - "not approved" or "will not proceed" and cross-reference the application change section. c. New issues raised in deliberations since publication of the Initial Report, if applicable: The Working Group discussed the issue of confidentiality with respect to the Recommendation xx that ICANN should specify the reason that it has rejected an application. The Working Group considered feedback received through public comment regarding who should have access to this information provided by ICANN org. The Working Group reviewed one perspective that this information should be completely confidential and only available to the applicant, as well as the perspective that disclosure should be to the applicant exclusively if confidential information of the applicant might otherwise be revealed. The Working Group did not put forward a specific recommendation on this issue and notes that it may be considered further in the implementation phase. Discussion: -- This seems to make sense. This is a good inclusion. -- The reason for rejecting an application should be confidential, but binding on ICANN, not on the applicant. -- Question: Is that for any reason an application be rejected? Or just based on confidential information submitted by the applicant? Answer: It seems practically that the confidentiality would flow from the confidential disclosure. ACTION ITEM: Add Implementation Guidance language on confidentiality. -- Question: Should we link to the NCAP on name collisions as an “external effort”? Answer: Staff will determine the most efficient way to include links. ACTION ITEM 5: Add “Application Changes” to the list of dependencies. ________________________________ 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 5

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 03 February 1500 UTC
by Julie Hedlund Feb. 3, 2020

Feb. 3, 2020

Dear Working Group members, Please see below the notes from the meeting on 03 February 1500 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-02-03+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: 2.5.3 Application Submission Period: ACTION ITEM 1: Change the language of the recommendation in brackets as follows: “The Working Group recommends that for the next application window and subsequent application windows, [absent “extenuating or extraordinary” circumstances] the application submission period must be a fixed period of 13 weeks” Delete “three (3) months” [and should not begin or end on a weekend.] 2.5.5 Terms and Conditions: ACTION ITEM 2: First recommendation: Change “should” to “must” and delete “only be permitted to” from the first sentence: “Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN [must]should reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization [must]should cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.” Implementation Guidance xx: A framework for ICANN to make transparent changes to the Applicant Guidebook should be provided (see recommendations under Section Predictability). This framework should include available recourse for applicants, including the right to change an application or withdraw an application from ICANN’s consideration in exchange for a full refund, where applicable. This Implementation Guidance constitutes a revision to Section 14 of the Terms and Conditions from the 2012 round. Implementation Guidance xx: If the true risk of name collisions will be determined after the application is filed, ICANN should provide a full refund to applicants in cases where a new gTLD is applied for but later is disqualified because of risk of Name Collision. ACTION ITEM 3: Check the terminology -- Use consistent terminology - "not approved" or "will not proceed" and cross-reference the application change section. Re: The Working Group discussed the issue of confidentiality with respect to the Recommendation xx that ICANN should specify the reason that it has rejected an application. ACTION ITEM 4: Add Implementation Guidance language on confidentiality. ACTION ITEM 5: Add “Application Changes” to the list of dependencies. 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…. Overview: -- Question: What was the relationship between “affirmations” and “consensus”? Answer: These are two different concepts. We will be taking consensus calls on everything -- whether it is an affirmation, recommendation, or implementation guideline. -- Question: Affirmation seems quite intertwined with the concept of consensus. How does that relate to people who don’t agree with that affirmation? Answer: We hope you would let us know prior to taking a consensus call -- perhaps by changing the language, or changing it to a different type, such as a recommendation. We’ll also have a preamble that will explain what are the different categories. -- Think of it as an affirmative recommendation. Default to the 2012 round will be stated differently -- noting that not everyone agreed. -- Question: If we have default where we don’t agree, what about things we didn’t discuss? a. 2.5.3 Application Submission Period Recommendation xx: The Working Group recommends that for the next application window and subsequent application windows, the application submission period must be a fixed period of three (3) months. -- We aren’t really affirming what happened last time (as we don’t agree), but making a recommendation. -- What we talked about and had agreement in the comments we said at least 3 months, but that leaves open a whole bunch of different possibilities. This recommendation says 3 months, but there was discussion about longer periods. Discussion: -- In this discussion there might be a dependency relating for time for translation of the AGB in all of the different languages -- it should be consistent. -- On the translations issue we had implementation guidance that the non-English version should come out at or the same time as the English version. -- It should be a fixed period of time and should be consistent. -- Not just due to circumstances — it should changeable based on policy considerations and objectives -- 90-120 day. -- If it's not a fixed time, then who decides and when? -- Agree not less than 90 nor more than 120. -- Hence 12 weeks works and applies a reasonable structure . -- The implementation guidelines could say that the period should not end over a weekend, or say that it ends on a Wednesday. Say that the week runs from a Wednesday to a Wednesday. ACTION ITEM: Change the language of the recommendation in brackets as follows: “The Working Group recommends that for the next application window and subsequent application windows, [absent “extenuating or extraordinary” circumstances] the application submission period must be a fixed period of 13 weeks” Delete “three (3) months” [and should not begin or end on a weekend.] b. 2.5.5 Terms and Conditions Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN must only be permitted to reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization must cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaw for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round. Discussion: -- Question: If we say “must” instead of “should” are we putting the Board in a position of not adopting a recommendation subject to GAC advice. Answer: The GAC advice led to unpredictability so this is a pretty strong recommendation from the comments that we got in on the Initial Report. -- Question: Are we able to accommodate name collisions, or things that we didn’t think about? Answer: That is in the first sentence. -- This should be viewed as a compromise position since ICANN shouldn’t be able to avoid having it’s decisions challenged in court. -- If ICANN acts inconsistently with the AGB or the Bylaws there are ways to challenge the decisions. This is all challengeable in some way and allows for accountability. -- Should we delete “be permitted” in the first sentence? ACTION ITEM: First recommendation: Change “should” to “must” and delete “only be permitted to” from the first sentence: “Recommendation xx (rationale 1): Unless required under specific laws or the ICANN Bylaws, ICANN [must]should reject an application if done so in accordance with the provisions of the Applicant Guidebook. In the event an application is rejected, the ICANN organization [must]should cite with specificity the reason in accordance with the Applicant Guidebook, or if applicable, the specific law and/or ICANN Bylaws for not allowing an application to proceed. This recommendation constitutes a revision to Section 3 of the Terms and Conditions from the 2012 round.” Implementation Guidance xx: A framework for ICANN to make transparent changes to the Applicant Guidebook should be provided (see recommendations under Section Predictability). This framework should include available recourse for applicants, including the right to change an application or withdraw an application from ICANN’s consideration in exchange for a full refund, where applicable. This Implementation Guidance constitutes a revision to Section 14 of the Terms and Conditions from the 2012 round. Discussion: -- What does the “where applicable” comes from - is it because of the difference between those who may not get a full refund. -- Putting in a full refund for any change to the AGB could be challenging. Not sure the WG could decide where a full refund should be made available. It is a qualifier that a full refund is not provided in all circumstances. -- Does the WG have a suggestion for the types of changes that would require a full refund? This doesn’t take into account that there are portions of the program that don’t get implemented until the end so there is a potential for changes. -- When we talk about application changes we provide more detail. Where and ICANN change materially changes the nature of an application, for example. ACTION ITEM: Check the terminology -- Use consistent terminology - "not approved" or "will not proceed" and cross-reference the application change section. c. New issues raised in deliberations since publication of the Initial Report, if applicable: The Working Group discussed the issue of confidentiality with respect to the Recommendation xx that ICANN should specify the reason that it has rejected an application. The Working Group considered feedback received through public comment regarding who should have access to this information provided by ICANN org. The Working Group reviewed one perspective that this information should be completely confidential and only available to the applicant, as well as the perspective that disclosure should be to the applicant exclusively if confidential information of the applicant might otherwise be revealed. The Working Group did not put forward a specific recommendation on this issue and notes that it may be considered further in the implementation phase. Discussion: -- This seems to make sense. This is a good inclusion. -- The reason for rejecting an application should be confidential, but binding on ICANN, not on the applicant. -- Question: Is that for any reason an application be rejected? Or just based on confidential information submitted by the applicant? Answer: It seems practically that the confidentiality would flow from the confidential disclosure. ACTION ITEM: Add Implementation Guidance language on confidentiality. -- Question: Should we link to the NCAP on name collisions as an “external effort”? Answer: Staff will determine the most efficient way to include links. ACTION ITEM 5: Add “Application Changes” to the list of dependencies.

2 1

FW: New gTLD SubPro WG Liaison Announcement
by Jeff Neuman Feb. 3, 2020

Feb. 3, 2020

All, Welcome Avri and Becky as Liaisons from the Board to our Working Group. I believe this is a great development and will certainly help us as we move forward towards implementation. Please see the note below from the ICANN Board Chair on the role of the two Board Liaisons. As most of you are aware, Avri was one of the original Co-chairs of the group before moving onto the ICANN Board. Becky, as most of you know, has had many roles in the ICANN community, both from the Private Sector as well as from the US Government, and was at Neustar during the last round of New gTLDs. Both of them are well versed in the New gTLD process and we are glad to have them as liaisons. Best regards, Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> From: Wendy Profit <wendy.profit(a)icann.org> Sent: Monday, February 3, 2020 11:26 AM To: Jeff Neuman <jeff.neuman(a)comlaude.com>; langdonorr(a)gmail.com; gnso-secs(a)icann.org Cc: Maarten Botterman <maarten.botterman(a)board.icann.org>; Board Ops Team <board-ops-team(a)icann.org>; Secretary <secretary(a)icann.org> Subject: New gTLD SubPro WG Liaison Announcement SENT ON BEHALF OF MAARTEN BOTTERMAN Dear Cheryl and Jeff, I’m writing to notify you that two liaisons from the ICANN Board have been appointed to the New generic Top-Level Domain (gTLD) Subsequent Procedures Policy Development Process Working Group. They are Avri Doria and Becky Burr; and you may already be in communication with them in this regard. This email serves as official notification of their appointments. I also wish to confirm that the role of the two Board liaisons for the New gTLD Subsequent Procedures Working Group is consistent with the expectation of the GNSO Council, that Board Liaison(s) will share on a regular basis any input the Board may have that will inform the SubPro PDP team deliberations and ongoing work. Similarly, Board Liaison(s) are expected to keep the Board informed concerning the status of the SubPro PDP Team deliberations. The Board Liaison(s) are not expected to advocate for any position and/or participate in any SubPro Team consensus calls. Please inform the GNSO Council accordingly. Best regards, Maarten Wendy Profit ICANN Board Operations Senior Manager 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 ________________________________ 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>

2 1

Post Call / New gTLD Subsequent Procedures Working Group call on Monday, 03 February 2020 at 15:00 UTC
by Michelle DeSmyter Feb. 3, 2020

Feb. 3, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Monday, 03 February 2020 at 15:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/EwVxBw> (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, Michelle

1 0

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

Jan. 31, 2020

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 Jan. 31, 2020

Jan. 31, 2020

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