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

Re: [Gnso-newgtld-wg] Current Thinking on Closed Generics
by Alexander Schubert July 27, 2020

July 27, 2020

Hi,I agree. But since we can't even find concensus WITHIN this WG on the issue whether the allocation of closed generics (because of standing GAC advice and/or the bylaws) should follow a public interest goal - and how far reaching this should be in the realm of this new gTLD program:Shouldn't we first lay the groundwork on which we then later can build on? We are soon to publish a draft to the public and garner their input. And I fully agree that at this point of time we are in no position to advance concrete policy recommendation proposals. But we could sample two general proposals for the community to elaborate on that would establish a base as to how the actual "picket fence" of "public interest" should look like. Not policy but guidelines for what the basis of our policies should be.E.g.:1) "Generally generic keyword based gTLDs should be available for registration of domains to a wider public. The benefit of operation as restricted or single registrant registry would have to outweigh the unavailability of domains to all or part of the community. The registry operator will have to convince the community that his operating model justifies making domains unavailable to some within or even all the community."2) "There is an endless amount of strings available - and as any single registrant use is potentially fostering innovation just the prospect of innovation in and of itself justifies single registrant registries."Btw: Picket Fence 1) is the basis for community gTLDs and restricted TLDs like .bank: 99.9999% of entities are denied to register a .bank domain: because it is indeed in the public interest that you end up on a bank's website if you visit a .bank domain. Yes that denies companies who produce or sell banks (seating, power banks, etc) to use .bank domains - but overall the benefits that the restriction generates outweighs the unavailability.Let's the community decide to what degree the new gTLD program should be bound to the public interest. Right now would be an awesome moment in time to garner input on this topic from the community. We are acting ON BEHALF of the community - so why second guessing what the community wishes - just ask.In case the community choses 2): we are done. Any string can be applied for as closed generic. If the community choses 1): we have finally very clear guidelines. Even when we still can't agree on a concrete policy we can put that portion into the applicant guidebook - and warn folks:"In 2012 closed generics were barred from advancing. This program follows a clear public interest goal. If you restrict registrations just to yourself and affiliates then there shouldn't be a general expectation that your application will be approved."We owe it to new entrants that they are warned. In 2012 we had mostly ICANN insiders applying (consulting). In the next round this will dramatically change.See you later in the call.AlexanderSent from my Samsung device -------- Original message -------- From: "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Date: 7/27/20 07:01 (GMT+02:00) To: "mail(a)christopherwilkinson.eu CW" <mail(a)christopherwilkinson.eu>, Jeff Neuman <jeff(a)jjnsolutions.com>, gnso-newgtld-wg(a)icann.org Subject: Re: [Gnso-newgtld-wg] Current Thinking on Closed Generics As I understand it, Jeff does not see an opportunity for consensus without obtaining further public comment on the issue of Closed Generics. I believe that by definition, a Closed Generic is one where only the applicant and its strictly defined affiliates may occupy the domains. The WG has recently been to GNSO Council with a request for a new timeline, which was approved. That is where Jeff is getting his deadline. I tend to agree with Jeff that: (a) further discussion by the WG at this time will not achieve consensus (b) additional public comment on the various proposals (and anything new that comes in during the next week) will better inform further attempts of the WG to achieve consensus. Regarding the discussion on the public interest, I don’t think every gTLD is required to serve the public interest. There is a general assumption (which may be questioned of course) that competition is fostered by the program generally and that this will inure to the benefit of consumers. The topic of Closed Generics serving a public interest is a separate one entirely, due to standing GAC Consensus Advice. Personally, and certainly not speaking on behalf of the IPC, I don’t think a long discussion about why the Board should override GAC Advice is a good use of our time. Nor do I think the proposal from the small group led by George is actually a proposal for a Closed Generic. It appears to me to be more of a proposal that is community and/or eligibility based. For the above reasons and subject to Monday’s discussion, I support Jeff’s proposed approach to the issue for purposes of the draft Final Report. Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of mail(a)christopherwilkinson.eu CW Sent: Sunday, July 26, 2020 12:13 PM To: Jeff Neuman <jeff(a)jjnsolutions.com>; gnso-newgtld-wg(a)icann.org Subject: Re: [Gnso-newgtld-wg] Current Thinking on Closed Generics [EXTERNAL] Dear Jeff: Allow me just a quick response. 1. The proposals that we have received merit a full discussion by the PDP. I think that time should be made available. 2. Your latest communication seems to me to ignore the current and prospective economic situation arising from the global pandemic. > … we could get much further behind and ultimately not meet our end of year date. On the contrary, there should now be no urgency. If the objective is to successfully launch another large opening of the DNS, then that should be done in the context of substantial international economic expansion. Which is apparently not currently on the cards. I assume that Staff and Co-Chairs have investigated the relationships between the macro economic situation and the relative success of introducing large numbers of new TLDs.- 3. Although I may have missed something, I do not know where the 'end of year date' comes from. Nor the current twice a week PDP schedule. Indeed, that has not brought matters forward, rather just made more time for discussion. Just a few thoughts Best regards CW … we could get much further behind and ultimately not meet our end of year date.de julio de 2020 a las 18:30 Jeff Neuman <jeff(a)jjnsolutions.com> escribió: All, I wanted to throw something out for consideration by the group in the interests of getting to the draft final report. We are already a week or two behind and I am worried that we could get much further behind and ultimately not meet our end of year date. So, I am laying this out on the line as a proposal. This is not a definitive plan, but something to think about. For the Draft final report, we state that there is No Agreement on the issue of Closed Generics and keep the paragraph in the draft the way it is today. In addition to the text that is already in there, we now have two proposals, one from George et al., and one from Kurt, et al. What if we give everyone an additional week to come up with any proposals on Closed generics they would like to float out for public comment. We publish those proposals for public comment being very specific that they are individual proposals and do not have any level of support within the working group. We may even not want to attach names to the proposal so as to try not and bias the comments we get in. We can of course discuss this last point. We solicit comments on all of the proposals. While the public comment period is going on, we continue to discuss the proposals as a Working Group to see if we can reach any sort of consensus on this issue. We make it very clear in our report that absent reaching consensus within the Working Group on any of these proposals, taking into consideration public comments of course, that in the final report, we will go with the language that is in the Draft Final Report (without any of the individual proposals); namely, No Agreement. Why do this? We need to be realistic with ourselves as well as the community that to date there is no agreement on how to move forward. We also need to give the community a chance to look at the various options people in the working group have proposed so that they can think about these as well (regardless of whether one group of people like it or not). At the end of the day, we will need to demonstrate to the GNSO Council and the Board that we attempted every possible way to reach consensus on a compromise. And finally there are 40+ other topics that we have come to some sort of final resolution on and there is no reason to delay everything even more for these last few issues. What does this mean for us? i) On the call on Monday, we will discuss this path of moving forward. ii) This means that we do not need to use up time on the call discussing the two existing proposals for which I am sure we could spend hours going back and forth and likely end up on Monday exactly where we are now. iii) It also means that others have a week to submit their own proposals. I personally have some ideas that I may put into a proposal that I may submit (not as a co-chair, but personally speaking). This may give us another reason to not attach names to the proposals so that if I submitted a proposal it wouldn’t be associated with the “co-chair”. iv) We work on finalizing the draft report sections on Predictability and Mechanisms of Last Resort this week as well as the Preamble and “Cant Live With” Package 7. v) This would enable us to stay only a week or to behind. Thoughts? Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff(a)jjnsolutions.com http://jjnsolutions.com _______________________________________________ Gnso-newgtld-wg mailing list Gnso-newgtld-wg(a)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.

4 3

Proposed Agenda - New gTLD Subsequent Procedures PDP WG - Monday, 27 July at 15:00 UTC for 90 Minutes
by Julie Hedlund July 27, 2020

July 27, 2020

Dear WG Members, Please find below the proposed agenda for the WG meeting on Monday, 27 July 2020 at 15:00 UTC for 90 minutes. Proposed Agenda: 1. Review Agenda/Updates to Statements of Interest 2. Complete Review of the updated Predictability Framework, see: https://docs.google.com/document/d/1vBckhFQCCQ-zyvfGGcDB3NWQhodVsffdqbyb6kT…. Also attached, please find the updated concerns/mitigation document and process flow. 3. Review Private Resolutions – Model 5 at: https://docs.google.com/document/d/1X8F8zHkgMzQg2WqGHpuoEP78rhpDkFOjD2qKrZZ… and Auctions: Mechanisms of Last Resort at: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… 4. Closed Generics – Discussion of proposal from George Sadowsky/Small Group (George with Greg Shatan, Alan Greenberg, and Kathy Kleiman) – See attached document. 5. 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>. Best, Julie Julie Hedlund, Policy Director

4 3

Additional thoughts on Proposal 5
by Jim Prendergast July 27, 2020

July 27, 2020

Apologies in advance. I will not be able to join the call later today as I am cohosting a workshop at RightsCon at the same time. I will review the notes and recording and respond on list as necessary. As Jeff noted during the last call, this is complicated because we are now allowing the resolution of contention sets in ways that were not allowed in the 2012 round. A very simple, clean way to settle contention sets without these measures is to have them all go to an ICANN auction of last resort or a random draw. But some people insist that losers should get paid so those are off the table. I also believe that we have to address BOTH Board concerns - Board Concern #1 - applications submitted for the sole purpose of receiving a payout for losing private auctions We have made good progress in addressing #1 and I think we can get there with some tweaks. Transparency requirements are good but they should not be rolled back for the creation of JVs. Not suggesting trade secrets be divulged but we should know who the operator of the JV is and we should also know the circumstances around what caused members of the contention set who are not part of the JV to drop out. I also believe that the Bona Fide proffers should be reviewed and enforced by ICANN, not just the outside evaluators. Rationale is that at some point, the evaluators will disappear. They are temporary help. ICANN has the ultimate responsibility to administer this program so they should be the ones reviewing theses Bona Fide requirements. And along these lines - ICANN should oversee all auctions, not just the Auction of Last resort. As currently constructed in Paul's edit - there are too many steps for revealing the results of private auctions. With ICANN overseeing this, it's a much cleaner process. ICANN involvement also adds a level of assurance that these auctions are being conducted in an aboveboard manner. As far as penalties for violations of the Bona Fide requirements - loss of registry has to be there. That is a major deterrent and should not be cast aside. Board Concern #2 - gaming for the purposes of financing other applications. The base Proposal 5 does nothing to address Concern #2. Donna stated that she's "not convinced that means we have to address it." I couldn't disagree more. If we fail to address this now, there is a strong likely hood that the Board will either 1) come back to us and ask us to develop a plan (slowing things down again) or 2) develop a solution themselves. Neither is an ideal outcome so we have to do something to stop the gaming for purposes of financing other applications. I and others believe that the Bona Fide requirements do not go far enough here. Others believe my sealed bid requirement goes too far. So what are alternative solutions that are enforceable and prevent this type of activity? Auction proceeds held in escrow? All auction conducted at once? Timing on when these auctions happen is the key to stop this gaming and that is why I proposed the submission of all bids upfront. With bids upfront, auctions could be conducted whenever but there is a constraint on the ability to roll funds over and over. ICANN's right to refer to competition authority. We never got around to discussing why Paul felt the need to delete this section completely and since the call there was a brief discussion on list about whether ICANN has this as an inherent right or whether it should be spelled out. My proposal was based upon the RSEP process which is already in force of all registry operators and will be required for all future operators. It specifically calls out competition authority referral if ICANN makes a determination such referral is necessary. I was surprised how representatives of contracted parties reacted so negatively to that since it is in existing registry agreements. My rationale for including this provision and calling it out specifically is simple - if a JV or other form of private resolution raises competition concerns for ICANN, they should have the right to refer it to relevant competition authorities to ensure they are ok with it. This protects ICANN the institution from charges that it is fostering anticompetitive behavior. Jim Prendergast The Galway Strategy Group +1 202-285-3699

5 5

Brief Paper - Closed Generic Viewpoint
by Kurt Pritz July 26, 2020

July 26, 2020

Hi Everyone: Marc Trachtenberg, Mike Rodenbaugh and I have combined to develop the attached paper describing our position on the delegation of closed-generic TLDs. While Paul McGrady generally agrees with the document, he is travelling and couldn’t dedicate sufficient attention to the document to formally sign on to it. This is not meant as a response to the paper recently offered, “A Proposal for Public Interest Closed Generic gTLDs,” but was developed in parallel and meant to be considered on its own. As always, this is not as complete, succinct, and clear as we would like it to be and would be pleased to discuss the thinking behind it in any forum. We hope you find it meaningful. Thanks in advance for any time devoted to reading it. Sincerely, Kurt, Marc, Mike

3 2

Comments re new public Interest closed generic TLDs
by George Sadowsky July 25, 2020

July 25, 2020

Dear Jeff, We would like to respond to your email suggesting that this proposal is essentially an open restricted gTLD. We suggest that differences are substantial. We are recommending a “public interest goals” framework as sought by the GAC and the Board ("For strings representing generic terms, exclusive registry access should serve a public interest goal.” - Beijing GAC Advice). Differences between our Public Interest Closed Generic TLD and an open restricted TLD: 1. There is only a single registrant, the Registry Operator. The Registry Operator will have a governance structure that ensures that the entity meets its stated goals, which is an essential feature of any entity. The governance concepts we suggest are ones well suited to meet the specific public interest goals of this type of TLD. 2. A restricted gTLD may certainly impose strict entry requirements on its registrants, as..bank and ,pharmacy do. However such gTLDs say nothing about limiting any behavior on the registry, including behavior that would be commonly regarded as not in the public interest. For example, when one of us was on the Board and leaving, there was a significant dispute between .pharmacy and the Canadian pharmacies. The entry requirements had been set in a discriminatory fashion so that the Canadian pharmacies could not comply and were therefore excluded. This clearly was done for U.S. industry purposes to restrict knowledge of alternatives and competitive possibilities between the two groups. That may be in the interests of U.S. pharmacies but it is not in the global public interest. Similarly, using the .disaster example and permitting it to be delegated to the Red Cross risks not serving the public interest. There are a number of prominent organizations besides the Red Cross that work in the area of disaster mitigation. The exclusion of all other major organizations from participation in the TLD would both bias the content of the TLD toward only the Red Cross affiliates and branches as well as limit its usefulness to global internet users. Our model would not allow this to happen, since acceptance of the TLD as being in the public interest would rely upon the support of a sufficient number of organizations, providing in the aggregate sufficient coverage of this disaster space. Only by insisting upon such a process can the required level of trust be achieved to consider the closed generic TLD to be truly in the public interest. Note: We are *not* requiring that all eligible registrants be allowed into the public interest closed generic TLD; that choice will be made by the registry and its governance group. The registry and its governance group are fully empowered to decide on the structure of the TLD and all second level domain names (and by extension third level and beyond are owned by the registry). Our rules ensure that the public interest closed generic TLD benefits the public interest and not just the registry. In our proposal, there are a number of requirements to ensure that such a situation will occur, including a "sufficient representation" issue as one criterion for approval, a governing body for those who include themselves in the application, fair entry and exit criteria for the life of the TLD, and an inability to repurpose the TLD in a way that modifies its original and mandated purpose. In addition, our proposal allows the domain space at the second and further levels to be shaped somewhat arbitrarily -- and potentially uniquely -- by the registry in the service of the public interest rather than being only a list of second level "registrants." Our proposal has no registrants other than the applicant, but it does include a collection of like minded not-for- profit organizations. This provides a possibility of some quite innovative use of the closed generic domain structure. A public interest closed generic TLD, we submit, permits a new form of TLD structure with different objectives, applications, review, and delegation processes. 3. Our closed generic public interest TLD proposal focuses solely upon TLDs that are reviewed and accepted to be in the public interest, which we would argue as being the essence of what the GAC and the Board were trying to accomplish. Accordingly, Specification 11 does not apply. Overall, our framework features exclusive registry access to a generic string -- with express provisions designed to protect the public interest. We very much look forward to hearing the reactions and opinions of others in the working group, and especially our discussion regarding the proposal at our next working group meeting. Regards, George, Alan, Kathy and Greg

2 2

Re: [Gnso-newgtld-wg] Brief Paper - Closed Generic Viewpoint
by Alexander Schubert July 25, 2020

July 25, 2020

Hi Kurt,The submitted document is a good summary of the "no strings attached" fraction here in the WG. If I may condense:The original PDP & AGB included no constraints or regulations on closed generics.The only reason why closed generics were rejected in 2012 (and are subsequently now subject to debate) is GAC advice. If a certain generic term based .com (e.g. "book.com") is taken then there is an infinite amount of other strings available that could serve as SLD under .com; the same must be true for a top-level identifyer; e.g. (working off of therausus) instead of ".book" registrants could choose domains in the gTLDs:.publication .text.title.writingAny applicant could also do like Amazon and simply use ".nile" or ".mekong" instead ".book"; because AMAZON sells books via amazon.com!A "public interest" test is impossible to implement and introduces cost, complication and uncertainty.Closed generic term based gTLDs have the greatest potential for innovation - but even if no innovation happens: no harm done.I guess we are past the stage of "shooting holes" into policy suggestions. I would just like to mention:Yes!Thanks GAC!Naming choice & rules in SLDs under the monopolistic .com gTLD are completely incomparable to the naming choice of gTLD strings. It's comparing apples and ducks. Two different universes with incomparable dynamics. I say that as someone who was a domainer since 23 years (not anymore; I changed camp) and is actively creating new gTLDs since 15 years. Conflation of "Brand" vs. generic gTLD. This is comparing apples and solar solstices. An opinion. This is the main issue: there is an expectation that (driven by consultants) corporations claim their category keyword gTLDs - just to own them. Then they might or might not think about innovation. But as I said: we are probably past the "discussion stage": we exchanged these same bullet points forth and back for years.We as GNSO WG need to sample policy suggestions; then let the Internet Community decide between the choices as this WG will not come up with consensus on any of the single suggested versions. So far it seems we have three policy suggestion camps ("clouds"):An unfiltered approach to closed TLDs; were anybody can apply for any string as closed gTLD:Generic keywords (".book")Brands (Spec 13 would be eliminated in that model, right?)Geo terms (e.g. ".shanghai")An approach where the public benefit that is suggested in the gTLD operation plan is outweighing the fact that the public can't register domains.I am not singling out any concrete policy version. Implementation will have to be worked on.None of the above is satisfactory - therefore until an appropriate policy advice is being created closed gTLDs remain confined to SPEC 13 brand TLDs.A word to Spec13 Brand TLDs:If any string could be operated as closed gTLD: wouldn't then the entire class (and the related policies) of SPEC13 Brand gTLD be superfluous? If we do not lift all restrictions around closed generic gTLDs (hence keep SPEC13):How to prevent that closed generics are being introduced as SPEC13 registry? I register a TM "BOOK" (or buy a used one; there are two live TMs "BOOK" at USPTO right now; and there are many more globally) apply for .book as SPEC13 Brand gTLD - then do my "innovative thing"? E.g. give "accounts" (not domains) to clients - and route accountname.book to their presence that is hosted on my servers (similar to a FB page presence; or ebay store)? I don't give them the domain or access to nameservers - they apply for an account name - get an online service of whatever kind (store, social media account, heart tracker app account) - and I as registry route accountname.closedTLD to their account presence on my servers!Alexander Sent from my Samsung device -------- Original message -------- From: Kurt Pritz <kurt(a)kjpritz.com> Date: 7/25/20 00:13 (GMT+02:00) To: gnso-newgtld-wg(a)icann.org Subject: [Gnso-newgtld-wg] Brief Paper - Closed Generic Viewpoint Hi Everyone: Marc Trachtenberg, Mike Rodenbaugh and I have combined to develop the attached paper describing our position on the delegation of closed-generic TLDs. While Paul McGrady generally agrees with the document, he is travelling and couldn’t dedicate sufficient attention to the document to formally sign on to it.This is not meant as a response to the paper recently offered, “A Proposal for Public Interest Closed Generic gTLDs,” but was developed in parallel and meant to be considered on its own. As always, this is not as complete, succinct, and clear as we would like it to be and would be pleased to discuss the thinking behind it in any forum. We hope you find it meaningful. Thanks in advance for any time devoted to reading it. Sincerely,Kurt, Marc, Mike_______________________________________________Gnso-newgtld-wg mailing listGnso-newgtld-wg@icann.orghttps://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.

1 0

Re: [Gnso-newgtld-wg] Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 23 July 2020 at 03:00 UTC
by McGrady, Paul D. July 24, 2020

July 24, 2020

Sending again, this time copying the list. Looking forward to Staff instructions on this. I have never in all my years of WG work seen all suggestions rejected by Staff before so I am really befuddled about how this process now works. Thanks. Thanks Steve. Unless I hear otherwise, I will take your email as overriding the Co-chair’s instructions to make changes into the Google document. I’m not exactly sure why we are taking a different approach on this issue than for every other issue this WG has encountered so far where the document was Jackson Pollock’s White, Red and Black. But, perhaps that will become clear to me as time goes on. As for your suggestion that “WG members try and reach alignment on the principle components of a proposal rather than preparing competing redlines” – how should we do that? Trying to do that exclusively over email will be quite a feat to track when there is no unified Google document anymore. I’m concerned that I will miss something. Will Staff gather the substantive portions of those comments and circulate them prior to our next call? If so, what is the cut-off deadline for making those comments? How will the various changes that I proposed and we walked through as a group be captured and brought forward for refinement? Sorry to ask so many questions, but when the rules change this significantly this late in the game over one issue only, I am just trying to figure out how to pivot so that I can do my best to follow the new rules. Best, Paul Sent from my iPhone To receive regular COVID-19 updates from Taft, subscribe here<https://www.taftlaw.com/general/subscribe>. For additional resources, visit Taft's COVID-19 Resource Toolkit<https://www.taftlaw.com/general/coronavirus-covid-19-resource-toolkit>. This message may contain information that is attorney-client privileged, attorney work product or otherwise confidential. If you are not an intended recipient, use and disclosure of this message are prohibited. If you received this transmission in error, please notify the sender by reply e-mail and delete the message and any attachments. On Jul 23, 2020, at 6:48 PM, McGrady, Paul D. <PMcGrady(a)taftlaw.com> wrote: Thanks Steve. Unless I hear otherwise, I will take your email as overriding the Co-chair’s instructions to make changes into the Google document. I’m not exactly sure why we are taking a different approach on this issue than for every other issue this WG has encountered so far where the document was Jackson Pollock’s White, Red and Black. But, perhaps that will become clear to me as time goes on. As for your suggestion that “WG members try and reach alignment on the principle components of a proposal rather than preparing competing redlines” – how should we do that? Trying to do that exclusively over email will be quite a feat to track when there is no unified Google document anymore. I’m concerned that I will miss something. Will Staff gather the substantive portions of those comments and circulate them prior to our next call? If so, what is the cut-off deadline for making those comments? How will the various changes that I proposed and we walked through as a group be captured and brought forward for refinement? Sorry to ask so many questions, but when the rules change this significantly this late in the game over one issue only, I am just trying to figure out how to pivot so that I can do my best to follow the new rules. Best, Paul From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Pruis, Elaine via Gnso-newgtld-wg Sent: Thursday, July 23, 2020 1:09 PM To: steve.chan(a)icann.org; jim(a)GALWAYSG.COM; julie.bisland(a)icann.org; gnso-newgtld-wg(a)icann.org Cc: gnso-secs(a)icann.org Subject: Re: [Gnso-newgtld-wg] Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 23 July 2020 at 03:00 UTC Thanks Steve, I agree, staff or chairs should “hold the pen” and incorporate agreed upon language and changes. Otherwise our document will turn into Jackson Pollock’s White, Red and Black. Elaine Pruis Senior Director Naming Operations and Policy epruis(a)verisign.com<mailto:epruis@verisign.com> 703.948.4672 <image002.png> From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> on behalf of Steve Chan <steve.chan(a)icann.org<mailto:steve.chan@icann.org>> Date: Thursday, July 23, 2020 at 1:16 PM To: Jim Prendergast <jim(a)GALWAYSG.COM<mailto:jim@GALWAYSG.COM>>, Julie Bisland <julie.bisland(a)icann.org<mailto:julie.bisland@icann.org>>, "gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>" <gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>> Cc: "gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>" <gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>> Subject: [EXTERNAL] Re: [Gnso-newgtld-wg] Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 23 July 2020 at 03:00 UTC Hi Jim, all, Staff has created a separate version that retains Paul’s redlines (here: https://docs.google.com/document/d/10-4Ihe76XexR_4WcodSnxBlEiJAS3tMw6_i0wY9…) and in turn, rejected the suggestions that Paul made in the main document (here: https://docs.google.com/document/d/1X8F8zHkgMzQg2WqGHpuoEP78rhpDkFOjD2qKrZZ…) for ease of review. From the staff perspective, we think it may be more productive if WG members try and reach alignment on the principle components of a proposal rather than preparing competing redlines. Best, Steve From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> on behalf of Jim Prendergast <jim(a)GALWAYSG.COM<mailto:jim@GALWAYSG.COM>> Date: Thursday, July 23, 2020 at 9:34 AM To: Julie Bisland <julie.bisland(a)icann.org<mailto:julie.bisland@icann.org>>, "gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>" <gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org>> Cc: "gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>" <gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>> Subject: Re: [Gnso-newgtld-wg] Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 23 July 2020 at 03:00 UTC I believe Anne also asked for this on the call but could we get a copy of Proposal 5 before Paul made edits to the document. Or a clean copy with Paul’s edits below it? Would be easier for some of us to compare the changes and suggest our own without making changes to the master version. If I make any suggestions or changes, I’ll create my own version and circulate via email for all to see. thanks Jim Prendergast The Galway Strategy Group +1 202-285-3699 From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Julie Bisland Sent: Thursday, July 23, 2020 12:55 AM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Cc: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> Subject: [Gnso-newgtld-wg] Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 23 July 2020 at 03:00 UTC Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 23 July 2020 at 03:00 UTC can be found on the agenda wiki page <https://secure-web.cisco.com/1FuMyD8UifwhaMbQu28ThQ9OhpvuasiaCNQsZK5Injpt2n…> (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://secure-web.cisco.com/1FgEdOUxEmTeEz4vh3STcbpbeyP5uy_FGYI5E5tt_QDq76g…> and the main wiki page<https://secure-web.cisco.com/1zBgzBUZOEJFGT0akFQFv-P0bTuhoVpLUfmjoxrtksXSyG…>. Thank you. Kind regards Julie

3 5

Re: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6
by Kathy Kleiman July 24, 2020

July 24, 2020

Hi Jeff and Cheryl,Reverting back to an older topic, I would like to ask when the Packet 7 issue is being scheduled for discussion in the WG? I'll certainly arrange to be on that call to talk this through with you. It is a topic worthy of discussion together. Quick background: This is a major change - and one appropriate for the give and take of our Packet discussions, per our well-established procedure. Further, if we can spent an hour together newly-presented changes to auctions proposals, I'm sure we spend a few minutes together vetting a change to RVCs which potentially reverses months of discussion and agreement. :-) Best and tx, Kathy On 7/16/2020 1:41 PM, Jeff Neuman wrote: Anne, I never said delete the second sentence of that paragraph…so the whole paragraph would state: ICANN must allow applicants to submit Registry Voluntary Commitments (RVCs)(previously called voluntary PICs) in subsequent rounds in their applications and/or to respond to public comments, objections, GAC Early Warnings, GAC Consensus Advice, or for any other reason the applicant desires to make additional commitments. Applicants must be able to submit RVCs at any time prior to the execution of a Registry Agreement; PROVIDED, HOWEVER, THAT ALL RVCS SUBMITTED AFTER THE APPLICATION SUBMISSION DATE SHALL BE CONSIDERED APPLICATION CHANGES AND BE SUBJECT TO THE RECOMMENDATION SET FORTH IN SECTION XX APPLICATION CHANGES REQUESTS, INCLUDING, BUT NOT LIMITED TO, PUBLIC COMMENT IN ACCORDANCE WITH ICANN’S STANDARD PROCEDURES AND TIMEFRAMES So how is that not clear…I have bolded it and added emphasis. Jeffrey J Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff(a)jjnsolutions.com [1] http://jjnsolutions.com FROM: Aikman-Scalese, Anne SENT: Thursday, July 16, 2020 1:31 PM TO: Jeff Neuman ; Jamie Baxter ; Rubens Kuhl ; gnso-newgtld-wg(a)icann.org SUBJECT: RE: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 Jeff, The Application Change Request section does NOT say that all RVCs are subject to public comment. You would have to add your language below to that section – but only IF the WG agrees that private negotiation of RVCs is ok. (I can’t remember but Kathy has a different recollection of this.) Anne FROM: Jeff Neuman SENT: Thursday, July 16, 2020 9:32 AM TO: Aikman-Scalese, Anne ; Jamie Baxter ; Rubens Kuhl ; gnso-newgtld-wg(a)icann.org [6] SUBJECT: RE: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 [EXTERNAL] ------------------------- I am trying to distill all of these emails from the last 24 hours and here are my thoughts. * The text in the existing Applicant Guidebook states: “A formal objection can be filed only on four enumerated grounds, as described in this module. A formal objection initiates a dispute resolution proceeding.” Thus using the term “formal” does make sense in Section 2.3.2 Recommendation XX (Rationale 4). It does not make sense to include the word “informal” there because it creates a category of objections that does not exist. * Why don’t we just state something like: “ICANN must allow applicants to submit Registry Voluntary Commitments (RVCs)(previously called voluntary PICs) in subsequent rounds in their applications and/or to respond to public comments, objections, GAC Early Warnings, GAC Consensus Advice, or for any other reason the applicant desires to make additional commitments. The point of that language was to use as an example, but it was not intended to be a limited list. Plus, when combined with the language Steve quoted, there is no doubt that all RVCs are subject to public comment (whether they are in the initial application) or submitted as an Application Change. Jeffrey J. Neuman Founder & CEO JJN Solutions, LLC p: +1.202.549.5079 E: jeff(a)jjnsolutions.com [7] http://jjnsolutions.com [8] FROM: Gnso-newgtld-wg ON BEHALF OF Aikman-Scalese, Anne SENT: Thursday, July 16, 2020 10:26 AM TO: Jamie Baxter ; Rubens Kuhl ; gnso-newgtld-wg(a)icann.org [12] SUBJECT: Re: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 No – that’s the issue I am raising. All the changes to “formal objection” in the Objections section raise questions about the various references to “objections” in both the RVC section and the Application Change Request section. Those sections talk about “objections”. I did not see a prohibition on adopting RVCs in response to private negotiations with a party that is threatening to file an Objection. If we are permitting an RVC to be adopted during a private negotiation process, the RVC should be subject to public comment. If we are prohibiting adoption of an RVC to resolve a dispute before it gets to the formal Objection phase, then I am also fine with that. I am not fine with RVCs being adopted in private negotiations with that potentially not being subject to public comment. This is not at all clear in the document. We make reference to “formal objections” in the Objections section and just use the word “objections” in the RVC and Application Change Request section. We do not make any references to an RVC adopted pursuant to private negotiation before an Objection is filed. If we are going to allow those, it needs to be clear and it also needs to be clear that they are subject to public comment. If we are not going to allow that kind of private resolution, that has to be clear from the document. Anne FROM: Jamie Baxter SENT: Thursday, July 16, 2020 7:16 AM TO: Aikman-Scalese, Anne ; Rubens Kuhl ; gnso-newgtld-wg(a)icann.org [16] SUBJECT: Re: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 [EXTERNAL] ------------------------- Hey Anne And I don’t disagree with your concerns, however I thought Steve had pointed to where in the language your concern was covered. No? Jamie FROM: "Aikman-Scalese, Anne" DATE: Thursday, July 16, 2020 at 10:04 AM TO: Jamie Baxter , Rubens Kuhl , "gnso-newgtld-wg(a)icann.org [20]" SUBJECT: RE: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 Jamie, I don’t disagree with any of what you have said below. I am only saying that the document now creates the possibility that someone can argue that an RVC adopted in response to private negotiations (as opposed to the currently listed mechanisms) would not be viewed as an application change request requiring public comment. It is certainly not my purpose to “create” an informal objection. My purpose is to clarify that any RVC adopted to resolve a potential dispute (not just formal objection) should trigger an application change request process that requires public comment. Perhaps I have used the wrong language to try to accomplish that but it seems to me that once we say that Application Change Request with public comment only applies where there is a “formal objection”, then you have created a big loophole to transparency. Not intending to create a new category, just recognizing that private parties may approach each other and negotiate and the outcome could be a “settlement” that results in an RVC and that should always be subject to public comment. Anne FROM: Jamie Baxter SENT: Thursday, July 16, 2020 6:56 AM TO: Aikman-Scalese, Anne ; Rubens Kuhl ; gnso-newgtld-wg(a)icann.org [25] SUBJECT: Re: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 [EXTERNAL] ------------------------- Hey Anne I think my point may have been missed so I’ll try again. Currently there are public comments and there are objections (formal objections). These are two clearly defined periods for comment and opposition to be expressed by those reviewing applications (minus any GAC processes). Each of these have clearly defined procedures and timelines associated with them as noted in the 2012 AGB, creating transparency and predictability for all. If someone is interested in expressing comment or opposition about an application they are required to do so within those confines (minus GAC). This makes it a fair playing field for all applicants, including community applicants. In the 2012 round, people expressed comment and opposition outside of those confines and ICANN took no steps to enforce the AGB rules or prevent that comment or opposition from impacting the application and evaluation process. This diminished any transparency and predictability that was promised to applicants, and it was in contradiction to what the AGB provided for comment and oppostion. For standard applicants, any comment or opposition expressed after initial evaluation and “formal” objections were completed had no further impact, however for community applicants, ICANN’s miscarriage of the AGB rules had a direct impact on CPE scoring because of gaming. There is no such thing as informal objection in the AGB (as Steve Chan has confirmed), and I do not believe we should be creating such a thing. There are clearly defined times to submit public comment (for free) and there are clearly defined times to challenge applications via the objection process (at a cost). We should not be striping the transparency and predictability out of the process for applicants by allowing an undefined new category of “informal objection” that has no time limit or constraint. As I have pointed out on multiple occasion, all applicants should be treated equally in the process, but community applicants were not in the 2012 round, leaving them subject to an ICANN imposed additional period for people to game them in CPE by going after criteria 4 scoring. Hopefully that clarifies. Jamie FROM: "Aikman-Scalese, Anne" DATE: Wednesday, July 15, 2020 at 8:08 PM TO: Jamie Baxter , Rubens Kuhl , "gnso-newgtld-wg(a)icann.org [29]" SUBJECT: RE: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 Hi Jamie – I think transparency is the issue. If the new language says that RVCs that are adopted in response to a “formal” objection require public comment, then that language, in and of itself, creates a category of objection that is “not formal”. That could easily be a call or a letter from some party that says, “If you don’t adopt the following RVC, we are going to file an objection.” In that case, the RVC that is adopted should also be subject to an Application Change Request and public comment. A private “threat” like that would not be a matter of public comment. Anne FROM: Jamie Baxter SENT: Wednesday, July 15, 2020 4:01 PM TO: Aikman-Scalese, Anne ; Rubens Kuhl ; gnso-newgtld-wg(a)icann.org [34] SUBJECT: Re: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 [EXTERNAL] ------------------------- Hey Anne I would venture to argue that informal objection is technically “public comment.” I do not support creating an undefined category of application input/intervention called “informal objection” that has no specific rules or timeline for submission. This does not add transparency to the process or predictability for applicants. Public comment and formal objections already have clearly defined rules and timelines. I continue to believe it was a miscarriage of the AGB to allow “letters of opposition” (a.k.a informal objection) to be accepted years after the public comment period was closed and the formal objection period was complete. There was certainly no reference in the AGB that this would be allowed or acceptable. It was ultimately a successful gaming tactic used against community applicants. Community applicants deserve the same level of predictability as all other applicants. Jamie FROM: Gnso-newgtld-wg on behalf of "Aikman-Scalese, Anne" DATE: Wednesday, July 15, 2020 at 6:21 PM TO: Rubens Kuhl , "gnso-newgtld-wg(a)icann.org [38]" SUBJECT: Re: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 Section 2.3.2 on RVCs and PICs says in Recommendation xx (Rationale 4) that ICANN MUST allow RVCs to be added after the application submission date in order to respond to public comments, objection, GAC Early Warnings, and/or GAC Consensus Advice. So obviously RVCs can be adopted in a context other than “formal objection”. That section then refers us to the Application Change Request section. Thus, in Section 2.4 Application Change Requests, it appears we may have to amend the following language in a. Recommendation xx (rationale 2): ICANN org must document the types of changes which are required to be posted for public comment and which are not required to be posted for public comment. The following is a non-exhaustive list of changes that must require public comment: * The addition of Registry Voluntary Commitments in response to public comments, objections (whether formal or informal), GAC Consensus Advice, or GAC Early Warnings * Changes to Registry Voluntary Commitments in response to public comments, objections, GAC Consensus Advice, or GAC Early Warnings * Changes associated with the formation of joint ventures (see Recommendation xx below) FROM: Aikman-Scalese, Anne SENT: Wednesday, July 15, 2020 2:53 PM TO: 'Rubens Kuhl' ; gnso-newgtld-wg(a)icann.org [41] SUBJECT: RE: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 Right Rubens – just looking for the language that confirms that because the section on Objections now says in d. that this applies where RVCs are adopted in response to concerns raised in a FORMAL objection. FROM: Gnso-newgtld-wg ON BEHALF OF Rubens Kuhl SENT: Wednesday, July 15, 2020 2:49 PM TO: gnso-newgtld-wg(a)icann.org [43] SUBJECT: Re: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 My take is that unless the RVC is already filed in the application, when it will be subject by comments as all applications, will trigger application change request which includes public comments. Why would that not be so ? Rubens On 15 Jul 2020, at 18:38, Aikman-Scalese, Anne wrote: Thanks Jamie. I’m looking for the language in the draft Final Report that confirms your understanding. As mentioned below, Subsection d. has some added language stating that RVCs adopted in response to “concerns raised in a formal objection” will be considered application changes. Maybe Jeff or staff can advise where we would find that RVCs adopted in response to concerns expressed by a party that has not yet filed such “formal objection” would also be subject to application change request and public comment. (It may be in the section on Registry Voluntary Commitments”, but I am just looking for confirmation that all RVCs, regardless of the stage in which they are proposed to address concerns, trigger application change request procedures and public comment on the RVCs. Anne FROM: Jamie Baxter SENT: Wednesday, July 15, 2020 2:34 PM TO: Aikman-Scalese, Anne ; Emily Barabas ; gnso-newgtld-wg(a)icann.org [48] SUBJECT: Re: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 [EXTERNAL] ------------------------- Hey Anne I do not believe that all informal objection is weighted equally (or at the level of formal objection) – at least that was our experience in the 2012 round – therefore not all informal objection necessarily invokes an application change request. That said, I do see opportunities where informal objection may invoke an application change request, such as in CPE to address a “letter of objection” targeting points in criteria 4. It has been my understanding that any application change request that extends beyond administrative adjustments to an application goes out for public comment – which I believe is the catch net to address your concerns below. I have never assumed that change requests stemming from informal objection are exempt from public comment. Do I understand that correctly? Jamie FROM: "Aikman-Scalese, Anne" DATE: Wednesday, July 15, 2020 at 5:07 PM TO: Jamie Baxter , Emily Barabas , "gnso-newgtld-wg(a)icann.org [52]" SUBJECT: RE: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 Yes – Jamie – that would be my understanding. The question posed relates to the fact that the later paragraph says that RVCs developed in response to a “formal objection” invoke an application change request and require public comment. I hope we have not inadvertently created an exception to this requirement in relation to RVCs adopted in response to an “informal” objection. Anne FROM: Jamie Baxter SENT: Wednesday, July 15, 2020 1:29 PM TO: Aikman-Scalese, Anne ; Emily Barabas ; gnso-newgtld-wg(a)icann.org [57] SUBJECT: Re: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 [EXTERNAL] ------------------------- Hey Anne My interpretation of “formal objection” would be those that are paid for via a dispute resolution provider, not to be confused with any other objection expressed in public comment or other format, including the ICANN correspondence page. Jamie FROM: Gnso-newgtld-wg on behalf of "Aikman-Scalese, Anne" DATE: Wednesday, July 15, 2020 at 4:19 PM TO: Emily Barabas , "gnso-newgtld-wg(a)icann.org [61]" SUBJECT: Re: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 ON PACKAGE 6, PLEASE SEE BELOW: 1. RE 2.6.1 RE “APPLICATION QUEUING”, the language shown below should be modified because the previous section is drafted as “more than 125” and the section below is drafted as “less than 125”. Language should be revised does not cover what happens if you get exactly 125 IDN applications: * * If there are (delete “less than”) 125 or fewer applications for IDN strings that elect to participate in the prioritization draw, then all such applications shall be assigned priority numbersprocessed in the first batch prior to any non-IDN application. 2. SECTION 2.8.1 – OBJECTIONS I don’t understand why we would remove affirmations of Recommendation 2 and Recommendation 3 from this section. The fact that these Affirmations are affirmed elsewhere in the report does not change their relevance in relation to the subject of Objections. Please clarify whether these Affirmations are “in” or “out.” They don’t appear to be deleted but there are comments on the side saying they should be. Recommendation xx (rationale 3) Throughout this rationale, the word, “formal” has been inserted in front of the word, “objection”. What is the meaning/need for the insertion of “formal” before “objection”? Is there a thought that there are “informal” objection processes? This language also appears in Rationale 6 and there are NUMEROUS insertions of this reference in the Section on Deliberations. Is there some intended effect here with respect to Subsection d. which specifies that a change in Registry Voluntary Commitments that is made in response to a “formal objection” invokes an application change process? Is the idea that if there are RVCs that are agreed OUTSIDE the “formal objection” process (i.e. via an “informal” objection), those RVCs are somehow NOT subject to an application change process and related public comment? I thought we had established that all new RVCs need to be subject to an application change process and public comment. 3. SECTION 2.9.1 COMMUNITY APPLICATIONS – SUBSECTION C. “New issues raised in deliberations since publication of the Initial Report, if applicable.” Thanks for deleting the reference to the conclusion that the IRT should be the body that determines any needed changes to the CPE Guidelines. However, what was discussed when the “can’t live with” comments were reviewed is that there is a need to specify that the WG is seeking public comment on the CPE Guidelines. We should be specifying at this point in the text that we are seeking that comment and we should provide the link at this same point in the text so that we call attention to the request for public comment on the CPE Guidelines (but not the scoring.) Thank you, Anne FROM: Gnso-newgtld-wg ON BEHALF OF Emily Barabas SENT: Friday, July 10, 2020 10:44 AM TO: gnso-newgtld-wg(a)icann.org [64] SUBJECT: [Gnso-newgtld-wg] Deadline Wed 15 July - "Can't Live With" Review of Package 7 and Final Check on Revised Package 6 [EXTERNAL] ------------------------- Dear all, The following are now available for your review in the production document [65]. The DEADLINE for comments is WEDNESDAY 15 JULY AT 23:59 UTC. * PACKAGE 7 sections of the Report are now ready for “CAN’T LIVE WITH” review (beginning on page 148 [66]): * Please limit comments to items in the revised sections that you absolutely “cannot live with.” If there is text that you cannot accept, please fill out the attached form and send it to the WG by email. Please do not provide your input in any other format. * Package 7 includes two report sections: * 2.5.4 Applicant Support (last discussed on 11 June [67]) - For this section, PLEASE LIMIT “CAN’T LIVE WITH” COMMENTS TO THE NEW TEXT IN THE SECTION, which is displayed in black. The text in grey has already gone through “Can’t Live With” review as part of an earlier package. * 2.3.2 Registry Voluntary Commitments (RVCs) / Public Interest Commitments (PICs) (last discussed on 18 June [68]) * Comments will be tracked here [69]. * PACKAGE 6 revisions of the report, now ready for a FINAL CHECK (beginning on page 118 [70]): * Please limit feedback to errors in the edits, for example a revision that you believe does not accurately reflect the outcome of discussions about a “Can’t Live With” item. * Please send this type of feedback to the mailing list. Typo corrections can be sent directly to staff. * For package 6 sections, please do not raise new issues, introduce new “Can’t Live With” items, or re-open deliberations. * A high-level summary of the “Can’t Live With” input received is available here [71]. And a detailed log with the outcomes from the WG’s consideration of that input is available here [72]. Kind regards, Emily Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org [73] 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. 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. ------------------------- 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 [74] https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg [75] _______________________________________________ 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 [76]) and the website Terms of Service (https://www.icannorg/privacy/tos [77]). 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. 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. 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. 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. 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 [78] https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg [79] _______________________________________________ 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 [80]) and the website Terms of Service (https://www.icann.org/privacy/tos [81]). 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), an Links: ------ [1] mailto:jeff@jjnsolutions.com [2] mailto:jeff@jjnsolutions.com [3] mailto:AAikman@lrrc.com [4] mailto:jbaxter@spimarketing.com [5] mailto:rubensk@nic.br [6] mailto:gnso-newgtld-wg@icann.org [7] mailto:jeff@jjnsolutions.com [8] http://jjnsolutions.com [9] mailto:gnso-newgtld-wg-bounces@icann.org [10] mailto:jbaxter@spimarketing.com [11] mailto:rubensk@nic.br [12] mailto:gnso-newgtld-wg@icann.org [13] mailto:jbaxter@spimarketing.com [14] mailto:AAikman@lrrc.com [15] mailto:rubensk@nic.br [16] mailto:gnso-newgtld-wg@icann.org [17] mailto:AAikman@lrrc.com [18] mailto:jbaxter@spimarketing.com [19] mailto:rubensk@nic.br [20] mailto:gnso-newgtld-wg@icann.org [21] mailto:gnso-newgtld-wg@icann.org [22] mailto:jbaxter@spimarketing.com [23] mailto:AAikman@lrrc.com [24] mailto:rubensk@nic.br [25] mailto:gnso-newgtld-wg@icann.org [26] mailto:AAikman@lrrc.com [27] mailto:jbaxter@spimarketing.com [28] mailto:rubensk@nic.br [29] mailto:gnso-newgtld-wg@icann.org [30] mailto:gnso-newgtld-wg@icann.org [31] mailto:jbaxter@spimarketing.com [32] mailto:AAikman@lrrc.com [33] mailto:rubensk@nic.br [34] mailto:gnso-newgtld-wg@icann.org [35] mailto:gnso-newgtld-wg-bounces@icann.org [36] mailto:AAikman@lrrc.com [37] mailto:rubensk@nic.br [38] mailto:gnso-newgtld-wg@icann.org [39] mailto:gnso-newgtld-wg@icann.org [40] mailto:rubensk@nic.br [41] mailto:gnso-newgtld-wg@icann.org [42] mailto:gnso-newgtld-wg-bounces@icann.org [43] mailto:gnso-newgtld-wg@icann.org [44] mailto:AAikman@lrrc.com [45] mailto:jbaxter@spimarketing.com [46] mailto:AAikman@lrrc.com [47] mailto:emily.barabas@icann.org [48] mailto:gnso-newgtld-wg@icann.org [49] mailto:AAikman@lrrc.com [50] mailto:jbaxter@spimarketing.com [51] mailto:emily.barabas@icann.org [52] mailto:gnso-newgtld-wg@icann.org [53] mailto:gnso-newgtld-wg@icann.org [54] mailto:jbaxter@spimarketing.com [55] mailto:AAikman@lrrc.com [56] mailto:emily.barabas@icann.org [57] mailto:gnso-newgtld-wg@icann.org [58] mailto:gnso-newgtld-wg-bounces@icann.org [59] mailto:AAikman@lrrc.com [60] mailto:emily.barabas@icann.org [61] mailto:gnso-newgtld-wg@icann.org [62] mailto:gnso-newgtld-wg@icann.org [63] mailto:gnso-newgtld-wg-bounces@icann.org [64] mailto:gnso-newgtld-wg@icann.org [65] https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… [66] https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… [67] https://community.icann.org/display/NGSPP/2020-06-11+New+gTLD+Subsequent+Pr… [68] https://community.icann.org/display/NGSPP/2020-06-18+New+gTLD+Subsequent+Pr… [69] https://community.icann.org/x/JDKJBw [70] https://docs.google.com/document/d/1Hh8Wj3IwXvi91Am1k4Zoooct2zmPOmVe1pLmjQL… [71] https://community.icann.org/display/NGSPP/g.+Draft+Final+Report [72] https://docs.google.com/spreadsheets/d/1blgQjzh_vR7WQ1utsqBnHDb8_b2DD7IDQu-… [73] http://www.icann.org/ [74] mailto:Gnso-newgtld-wg@icann.org [75] https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg [76] https://www.icann.org/privacy/policy [77] https://www.icann.org/privacy/tos [78] mailto:Gnso-newgtld-wg@icann.org [79] https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg [80] https://www.icann.org/privacy/policy [81] https://www.icann.org/privacy/tos

2 1

Re: [Gnso-newgtld-wg] Proposal for introducing new public interest generic gTLDs
by Alexander Schubert July 24, 2020

July 24, 2020

Another huge risk of closed gTLDs:Currently we have 3 types of gTLDs:Open gTLDs like .bike or .onlineRestricted gTLDs like .bankClosed Spec13 gTLDs like .bmwIn 1.) and 2.) registrants enjoy many protections:The registry can't take away their domain - e.g. to give it to someone who offers a lot of money.The registry can't suddenly 50-fold the price for a registration (or "lease"); just because a business generates Millions via that domain.The registry can't easily change their policies: they can't suddenly deny certain content for example.I guess there are many other protections that I am not aware of.In 3.) there are no registrants - so if someone was allowed by the brand to run a domain: they would not enjoy ANY rights or protections.So what if someone applies for ".vlog" as closed gTLD - offering vloggers (video bloggers) free domains and free hosting as long as the "registry" (the company that leases 2nd level domains) may display ads in a headbanner? Super innovative. Very beneficial as it is free. But now the vloggers who claim fame and have tons of users become vulnerable - as "their domain" isn't theirs - and the registry could change pricing and policies at any time specifically on a per domain basis. "Oh: fashion.vlog makes US $5Million a year? Let's charge them US $100,000 annual lease." (Of course it started out as free offering).I just don't yet see where anyone needs a closed gTLD that is still safe for the users - outside of brands. SNAP or TWITTER assigning account names to .snap or .twitter to create vanity social media domains: yes! But those are brands.What would be an example of a closed TLD which couldn't be realized as Spec13 or restricted gTLDs?AlexanderSent from my Samsung device -------- Original message -------- From: "Aikman-Scalese, Anne" <AAikman(a)lrrc.com> Date: 7/22/20 20:16 (GMT+02:00) To: Jeff Neuman <jeff(a)jjnsolutions.com>, Alan Greenberg <alan.greenberg(a)mcgill.ca>, George Sadowsky <george.sadowsky(a)gmail.com>, gnso-newgtld-wg(a)icann.org Subject: Re: [Gnso-newgtld-wg] Proposal for introducing new public interest generic gTLDs  Jeff, If I understand what you are saying, the proposal put together by this group is not currently restricted because it is, in fact, an eligibility issue (and probably a GAC safeguard issue) and is not, in fact a Closed Generic and is not prohibited by the current rules or the Board’s Resolution on Closed Generics. Is that right? Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Jeff Neuman Sent: Wednesday, July 22, 2020 6:19 AM To: Alan Greenberg <alan.greenberg(a)mcgill.ca>; George Sadowsky <george.sadowsky(a)gmail.com>; gnso-newgtld-wg(a)icann.org Subject: Re: [Gnso-newgtld-wg] Proposal for introducing new public interest generic gTLDs [EXTERNAL] A lot to respond to here, but let me try: Why is this not a Closed TLD Proposal The Proposal at the very beginning states that it will allocate domain space to initial and subsequent partners and other relevant entities. The closest definition we have to a non-brand closed TLD is in Specification 11: Registry Operator of a “Generic String” TLD may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 2.9(c) of the Registry Agreement). “Affiliates” are defined in the corporate sense, not in the general sense of affiliation. Section 2.9(c): “For the purposes of this Agreement: (i) “Affiliate” means a person or entity that, directly or indirectly, through one or more intermediaries, or in combination with one or more other persons or entities, controls, is controlled by, or is under common control with, the person or entity specified, and (ii) “control” (including the terms “controlled by” and “under common control with”) means the possession, directly or indirectly, of the power to direct or cause the direction of the management or policies of a person or entity, whether through the ownership of securities, as trustee or executor, by serving as an employee or a member of a board of directors or equivalent governing body, by contract, by credit arrangement or otherwise." This proposal does not meet the definition of closed. It is more akin to a Community TLD or Open Restricted. The proposal also provides for the expansion of the name space to include a larger group of organizations.The Operation of the TLD section talks about revenue from fees charged for registrations. I know of no “closed” TLD that charges for registrations (because again the Registry Operator is the Registrant for all names and wouldn’t charge itself).The earthquake example is a good one to show that one would rather apply for an “open restricted” .earthquake TLD as opposed to a PICGTLD. If I am the US Geological Survey, I can apply as an open restricted TLD and propose all of the same rules with respect to second level registrations and not have any of the strict requirements in the proposal (Council, restriction on transfer, ICANN Board approval, etc.). Because this proposal provides no benefit (eg., priority in contention), there is NO reason to elect being a PICGTLD. Response to Alan: a) In the above example where the US geological Survey applies for .earthquake and proposed restrictions to only those organizations that are equivalent to what you list in 5.2 of the proposal, there is no existing objection that would survive. b) Yes there are at least 2 TLDs (.bank and .pharmacy) that have VERY strict requirements. So strict that some organizations have complained because although they are accredited to be a bank of pharmacy in their home country, they still may not be eligible because of not being up to the standards of the TLD. .pharmacy for example requires extensive checks of regulatory licenses, physical inspection of franchisees, etc. One could argue that these TLDs are actually more restrictive than the proposed PICGTLDs. c) You state: “But as I started with, if there is no value to what we are proposing, then perhaps the best path is to simply forbid such closed TLDs." a. That is essentially what the proposal does. I

2 1

Re: [Gnso-newgtld-wg] Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 23 July 2020 at 03:00 UTC
by Pruis, Elaine July 23, 2020

July 23, 2020

Thanks Steve, I agree, staff or chairs should “hold the pen” and incorporate agreed upon language and changes. Otherwise our document will turn into Jackson Pollock’s White, Red and Black. Elaine Pruis Senior Director Naming Operations and Policy epruis(a)verisign.com<mailto:epruis@verisign.com> 703.948.4672 [signature_510382353] From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Steve Chan <steve.chan(a)icann.org> Date: Thursday, July 23, 2020 at 1:16 PM To: Jim Prendergast <jim(a)GALWAYSG.COM>, Julie Bisland <julie.bisland(a)icann.org>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Cc: "gnso-secs(a)icann.org" <gnso-secs(a)icann.org> Subject: [EXTERNAL] Re: [Gnso-newgtld-wg] Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 23 July 2020 at 03:00 UTC Hi Jim, all, Staff has created a separate version that retains Paul’s redlines (here: https://docs.google.com/document/d/10-4Ihe76XexR_4WcodSnxBlEiJAS3tMw6_i0wY9…) and in turn, rejected the suggestions that Paul made in the main document (here: https://docs.google.com/document/d/1X8F8zHkgMzQg2WqGHpuoEP78rhpDkFOjD2qKrZZ…) for ease of review. From the staff perspective, we think it may be more productive if WG members try and reach alignment on the principle components of a proposal rather than preparing competing redlines. Best, Steve From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Jim Prendergast <jim(a)GALWAYSG.COM> Date: Thursday, July 23, 2020 at 9:34 AM To: Julie Bisland <julie.bisland(a)icann.org>, "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Cc: "gnso-secs(a)icann.org" <gnso-secs(a)icann.org> Subject: Re: [Gnso-newgtld-wg] Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 23 July 2020 at 03:00 UTC I believe Anne also asked for this on the call but could we get a copy of Proposal 5 before Paul made edits to the document. Or a clean copy with Paul’s edits below it? Would be easier for some of us to compare the changes and suggest our own without making changes to the master version. If I make any suggestions or changes, I’ll create my own version and circulate via email for all to see. thanks Jim Prendergast The Galway Strategy Group +1 202-285-3699 From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> On Behalf Of Julie Bisland Sent: Thursday, July 23, 2020 12:55 AM To: gnso-newgtld-wg(a)icann.org Cc: gnso-secs(a)icann.org Subject: [Gnso-newgtld-wg] Post Call | New gTLD Subsequent Procedures Working Group | Thursday, 23 July 2020 at 03:00 UTC Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 23 July 2020 at 03:00 UTC can be found on the agenda wiki page <https://secure-web.cisco.com/1FuMyD8UifwhaMbQu28ThQ9OhpvuasiaCNQsZK5Injpt2n…> (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://secure-web.cisco.com/1FgEdOUxEmTeEz4vh3STcbpbeyP5uy_FGYI5E5tt_QDq76g…> and the main wiki page<https://secure-web.cisco.com/1zBgzBUZOEJFGT0akFQFv-P0bTuhoVpLUfmjoxrtksXSyG…>. Thank you. Kind regards Julie

1 0