March 2020 - Gnso-newgtld-wg

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 05 March 2000 UTC
by Julie Hedlund March 5, 2020

March 5, 2020

Dear Working Group members, Please see below the notes from the meeting on 05 March 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-03-05+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: 1. Updates to Statements of Interest: -- Jamie Baxter updated his Statement of Interest: https://community.icann.org/display/gnsosoi/Jamie+Baxter+SOI 2. Review draft final recommendations – see the Working Document here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…: a. 2.12.1 TLD Rollout (page 54) Recommendation xx (rationale 2): ICANN org should establish metrics and service level requirements for each phase of the application process including each during the review, evaluation, contracting and transition to delegation stages. ICANN should report on a monthly basis on its performance with respect to these key performance indicators. -- Staff comment: This recommendation is reaching beyond this section, since it talks about the reviews and evaluation. It might be worth considering if this recommendation should be narrowed to the Transition to Delegation or if this recommendation belongs elsewhere, as an overarching goal of the Program. -- Included in the deliberations section is the discussion of the proposal from Alexander Schubert on blocking. But no agreement by the WG to include the proposal as a recommendation. Rationale for Affirmations xx-xx (rationale 1): Although some members of the Working Group were in favor of trying to further define what it means to “use” a TLD, The Working Group ultimately affirms the existing definition for “use” of a gTLD (namely, delegation into the root and meeting all other contractual commitments with respect to required content. It believes that as was the case in the 2012 round, there should be a specified timeframe in which the gTLD should be used. Further the Working Group believes that the timeframes for gTLD rollout from the 2012 round continue to be appropriate in subsequent rounds. The Working Group acknowledges that the provision of extensions to applicants can result in programmatic delays and additional costs and that the lack of a time limit for launch of a gTLD also carries operational costs. The Working Group nonetheless believes that maintaining the existing rules strikes the right balance between establishing appropriate requirements while providing applicants with flexibility when extra time is needed to roll out a gTLD. Discussion: -- Question: In terms of priorities could we have a provision that priority should be given to new entrants that are not already representatives of registries from the initial round? Answer: We discussed the suggestion of priorities in applications assessed in rounds and did not agree to such a recommendation. -- Question: Can we document a concern with the lack of a recommendation on prioritizing new entrants? Answer: That is already documented in the discussion on application queuing. b. 2.12.3 Contractual Compliance (page 56) Recommendation xx: ICANN’s Contractual Compliance Department should publish more detailed data on the activities of the department and the nature of the complaints handled; provided however, that ICANN should not publish specific information about any compliance action against a Registry Operator unless the alleged violation amounts to a clear breach of contract. To date, ICANN compliance provides summary statistics on the number of cases opened, generalized type of case, and whether and how long it takes to close. More information must be published on the context of the compliance action and whether it was closed due to action taken by the Registry Operator, or whether it was closed due to a finding that the Registry Operator was in compliance from the beginning. And “The Working Group believes that by providing additional data about the activities of ICANN’s Contractual Compliance department and the nature of complaints handled, ICANN can better support the community in evaluating the functioning of the New gTLD Program and developing policy on this topic in the future.” Discussion: -- Staff comment: In reviewing the current Compliance reporting, it has a fair amount of detail (e.g., complaint type) and also indicates whether the registry (or registrar) was able to demonstrate compliance. Further clarity may still be needed? - https://features.icann.org/compliance/dashboard/2020/0120/report -- Staff comment: Update to be more specific based on any adjustments to the recommendation above regarding data. -- Concerned when we say that Compliance should publish more detailed data we should provide more information about what detailed data we want. We should be explicit about what data we want published. -- Hard to be specific depending on what the Compliance activity might be. -- Suggest taking out “more” in “should publish more detailed data”. -- There are a lot of statistics in the Compliance dashboard, but you don’t see the context about the complaint, why it was filed, and what was done about it. -- There were ICANN self-generated cases and lack of grounds. -- So we need to identify what it is that we want to be included in the compliance reports - whether or not already there. Because probably there is more data now than when the WT looked at this, but we also don't want to lose data later that is currently shared because we don't specify it as being a requirement. -- Asking for insights to be provided based on the data. b. Deliberations and rationale for recommendations and/or implementation guidelines -- Suggestion to include for additional context: "..believes that by providing additional information and insights gathered from the data on the activities..." c. New issues raised in deliberations since publication of the Initial Report, if applicable. Discussion: -- Talking about an abusive targeted price by a registrar -- a pattern of abusive behavior -- we aren’t trying to regulate pricing, but activity. -- We did ask for evidence of the pattern in the Initial Report and from INTA in its survey, but we didn’t get evidence of the pattern of discriminatory pricing. -- Thought we had anecdotal evidence.

1 0

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 05 March 2020 at 20:00 UTC
by Julie Hedlund March 3, 2020

March 3, 2020

Dear all, Please find below the proposed agenda for the call on Thursday, 05 March 2020 at 20:00 UTC for 90 minutes: 1. Review Agenda/Statements of Interest 2. Review draft final recommendations – see the Working Document here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…: * 2.12.1 TLD Rollout (page 54) * 2.12.3 Contractual Compliance (page 56) 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

Post Call / New gTLD Subsequent Procedures Working Group call on Monday, 02 March 2020 at 15:00 UTC
by Michelle DeSmyter March 2, 2020

March 2, 2020

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

ICANN67: GNSO Sessions - How to Get Organized and Remote Participation Details
by Julie Bisland March 2, 2020

March 2, 2020

Dear all, The one-stop wiki page for all your Remote Participation queries is now available. This wiki page covers remote participation details for all GNSO open viurtual meetings. In addition to this, ICANN Meetings’ Team has put together an updated ICANN meeting website which allows you to download all GNSO-related meetings to your inbox calendar in one go. 2 LINKS TO BOOKMARK NOW: ICANN67 Meeting Schedule<https://67.schedule.icann.org/> GNSO Remote Participation Wiki Page<https://community.icann.org/x/dACJBw> Step 1 – Create a profile and your personalized ICANN67 schedule Go to the Meeting Schedule webpage and create a profile and login. Every session on the full schedule can be selected and added to your individual schedule by clicking the Add box to the bottom right of each meeting, this adds it to your individual schedule which you can then add to your calendar. See next step. Step 2 - There are two ways to import your schedule into your calendar: once you’ve added all your chosen meetings to “My Schedule” go to Export. · Downloading creates a one-time snapshot of your schedule and copies it into your default calendar. If you subsequently make changes to your Pathable calendar, they will not be reflected in your calendar. · Subscribing creates a live feed of your schedule in your default calendar. Outlook checks for changes every few hours and updates your calendar appropriately. [cidimage001.png(a)01D5F081.CD7015E0] * Select either Download or Subscribe My Schedule * Meetings will download to your default calendar * For Microsoft Outlook, right click on the ics attachment, open with Microsoft Outlook Step 3 All remote participation sessions will use Zoom rooms. You can find the Zoom room links for public meetings on the ICANN67 Meeting Schedule<https://67.schedule.icann.org/> and on the <https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_…> GNSO Remote Participation Wiki Page<https://community.icann.org/display/gnsocouncilmeetings/ICANN67+GNSO+Remote…>. Zoom access details for closed meetings will be communicated separately. There are three options to connect your audio: 1) Via VoIP, choose Computer Audio 2) Getting a dial out from Zoom to your phone, choose Call Me 3) Phoning into the audio bridge (access numbers and Meeting ID are provided for that option), choose Telephone Audio If you cannot log into the Zoom room, but wish to connect via telephone only, to dial into the audio refer to the GNSO Remote Participation Wiki Page<https://community.icann.org/display/gnsocouncilmeetings/ICANN67+GNSO+Remote…> for access numbers and individual Meeting IDs. Step 4 Please download the mobile app by searching for “ICANN Meetings” in your app stores. For all GNSO meeting related queries (RP or others), please email us at: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> and we will be more than happy to assist! Kind regards, GNSO SO/AC Support team -- Julie Bisland GNSO SO/AC Support coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: 79613b691cb8a6c1 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 02 March 1500 UTC
by Julie Hedlund March 2, 2020

March 2, 2020

Dear Working Group members, Please see below the notes from the meeting on 02 March at 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-03-02+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Action Items: 2.7.2 Registrant Protections: Recommendation xx (rationale 2): Provide TLDs with exemptions from the Code of Conduct (Specification 9) (including .Brand TLDs qualified for specification 13) with an exemption from COI requirements. ACTION ITEMS: -- Instead of “COI” say, “COI or its successor”. -- Double negative: something other than the second “exemption”. But exemption from the Code of Conduct also qualifies for an exemption from COI requirements. Reword to “and also an exemption from COI requirements”. c. New Issues Raised: ACTION ITEM: Add Implementation Guidance that a background check is done if there is a change to key personnel or officers, or to the entity itself, prior to contract signing. ACTION ITEM: Add to Role of Public Comments section: "ICANN must create a mechanism for the submission of information related to applicant background screening which may not be appropriate for public comment. At a minimum, ICANN must confirm receipt and that the information is being reviewed." ACTION ITEM: Ask ICANN Org: “Can a registry that is about to need an EBERO allowed to choose their EBERO provider? Matters from a data protection standpoint.” SSR2 Recommendation 26: Document, Improve, and Test the EBERO Processes See: https://www.icann.org/en/system/files/files/ssr2-review-24jan20-en.pdf; page 50: 26.5. ICANN org should publicly document the ERERO processes, including decision points, actions, and exceptions. ACTION ITEM: Include a reference to 26.5 and see how the rest of the recommendation evolves. Note that the WG is monitoring the work of the SSR2. 2.10.2 Registrar Non-Discrimination / Registry/Registrar Standardization: b. Deliberations and rationale for recommendations and/or implementation guidelines ACTION ITEM: Change last sentence to, “Certain exemptions to the Code of Conduct were subsequently approved by the ICANN Board of Directors, particularly with Brand TLD registries (in Specification 13) as well as with respect to entities that restricted their TLDs to only themselves and/or their affiliates [and trademark licensees].” New text in brackets. c. New issues raised: ACTION ITEM: Change “should” to “may” in the last sentence in the section: “Though the group believes this issue [may] be explored in the future, it is not making a recommendation on this area at this time.” 2.5 Registrar Support for New gTLDs Re: Granting a Code of Conduct exemption where a Registry Operator has made a good faith effort to recruit registrars to sell its TLD, but it has not been able to get registrars to do it . ACTION ITEM: Add this topic to the legal discussion. Notes: 1. Review Agenda/Statements of Interest: No updates provided. 2. Review draft final recommendations – see the Working Document here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…: a. 2.7.2 Registrant Protections -- Comment from Kathy Kleiman: Can we come up with a better term? "Registrant Protections" has always been confusing to me since the set of possible registrant protections is so much broader than anything we are talking about here. Perhaps "Technical Registrant Protections"? -- Comment from Jeff Neuman: Not all of them are technical, such as funding for the EBERO. Affirmation xx (rationale 1): The Working Group affirms existing technical registrant protections for registrants used in the 2012 round, including the EBERO and associated triggers for an EBERO event and critical registry functions. In addition, as described in section 2.7.7 Applicant Reviews: Technical/Operational, Financial and Registry Services, the substantive technical and operational evaluation is being maintained and therefore, protections against registry failure, including registry continuity, registry transition, and failover testing continue to be important registrant protections. The Working Group also supports the registrant protections contained in Specfication 6 of the Registry Agreement. Discussion: -- Not to reopen the debate, recognizing that this has been discussed… But EBERO has not proven effective in that the SLAM stats show there were several times a Registry should have been EBERO’d and was not. I think somewhere along the line the EBERO program needs to be reconsidered. Understood, and the outcome of the analysis saved my skin a few times :) I just think the concept needs to evolve. -- I would go a step further. The EBERO program is a crutch that keeps failing registries from going out of business. I don't know of any other industry where unsuccessful business are propped up like this. I might be wrong but .WED has been in EBERO since 2017. I think its still there. Recommendation xx (rationale 1): The Working Group supports recommendation 7.1.a. in the Program Implementation Review Report, which states: “Explore whether there are more effective and efficient ways to fund emergency back-end registry operator in the event of a TLD failure [other than requiring Continuing Operations Instruments].” Recommendation xx (rationale 2): Provide TLDs with exemptions from the Code of Conduct (Specification 9) (including .Brand TLDs qualified for specification 13) with an exemption from COI requirements. Discussion: ACTION ITEMS: -- Instead of “COI” say, “COI or its successor”. -- Double negative: something other than the second “exemption”. But exemption from the Code of Conduct also qualifies for an exemption from COI requirements. Reword to “and also an exemption from COI requirements”. c. New issues raised in deliberations since publication of the Initial Report, if applicable. The Working Group notes ICANN org’s comments on the Working Group’s Initial Report and a recommendation in the Program Implementation Review Report which suggest that additional consideration should be given to whether background screening should be performed during Initial Evaluation or at the time of contract execution (see PIRR recommendation 2.2.a). Because (i) there may be a significant amount of time that has passed between the initial evaluation and the contracting stage, and (ii) the changes that may be allowed to applications with respect to joint ventures or other allowable changes, many members of the Working Group were supportive of the Background checks occuring at time of contract execution. While the Working Group does not have any specific recommendations in this regard, it anticipates that the issue will be further considered in the implementation phase. Discussion: -- Staff comment: Is there anything further we want to say about the discussion regarding Pre-Approved RSPs serving as EBERO? This is discussed in some depth in the Initial Report. -- Staff comment: The Working Group may want to consider if there are any guiding principles to be considered during implementation. -- From Jeff Neuman: Most of the EBERO stuff has to do with finding other funding models to fund the EBERO than having a COI. We have a recommendation above that seeks more study of that. -- Consider a hybrid option as Implementation Guidance: if changes to key personnel, officers etc., or to the entity itself then the background check would have to be done before the contract signing. -- Great to have another check if there is a change or just before contracting. But, we cannot lose our gatekeeping check - it makes no sense to make folks go through an auction with another party that shouldn't even be there. -- Is there a mechanism for ICANN to acknowledge the comments and respond to them? But it shouldn’t be a public comment. -- Concerned that there is no easy recourse to ICANN Org making "a mistake" in completing a background check. ACTION ITEM: Add Implementation Guidance that a background check is done if there is a change to key personnel or officers, or to the entity itself, prior to contract signing. ACTION ITEM: Add to Role of Public Comments section: "ICANN must create a mechanism for the submission of information related to applicant background screening which may not be appropriate for public comment. At a minimum, ICANN must confirm receipt and that the information is being reviewed." SSR2 Recommendation 26: Document, Improve, and Test the EBERO Processes See: https://www.icann.org/en/system/files/files/ssr2-review-24jan20-en.pdf; page 50: 26.5. ICANN org should publicly document the ERERO processes, including decision points, actions, and exceptions. The document should describe the dependencies for every decision, action, and exception. 26.6. Where possible, ICANN org should automate these processes and test them annually. 26.7. ICANN org should publicly conduct EBERO smoke-testing at predetermined intervals using a test plan coordinated with the ICANN contracted parties in advance to ensure that all exception legs are exercised and publish the results. 26.8. ICANN org should improve the process by allowing the gTLD Data Escrow Agent to send the data escrow deposit directly to the EBERO provider. Discussion: -- Not sure what we can include from this recommendation. -- Can a registry that is about to need an EBERO allowed to choose their EBERO provider? Matters from a data protection standpoint. -- ICANN makes that decision and it's one of the reasons that the EBERO providers are geographical diverse, or at least they used to be. ACTION ITEM: Ask ICANN Org: “Can a registry that is about to need an EBERO allowed to choose their EBERO provider? Matters from a data protection standpoint.” ACTION ITEM: Include a reference to 26.5 and see how the rest of the recommendation evolves. Note that the WG is monitoring the work of the SSR2. b. 2.10.2 Registrar Non-Discrimination / Registry/Registrar Standardization (time permitting - page 52) b. Deliberations and rationale for recommendations and/or implementation guidelines ACTION ITEM: Change last sentence to, “Certain exemptions to the Code of Conduct were subsequently approved by the ICANN Board of Directors, particularly with Brand TLD registries (in Specification 13) as well as with respect to entities that restricted their TLDs to only themselves and/or their affiliates [and trademark licensees].” New text in brackets. c. New issues raised: ACTION ITEM: Change “should” to “may” in the last sentence in the section: “Though the group believes this issue [may] be explored in the future, it is not making a recommendation on this area at this time.” c. 2.5 Registrar Support for New gTLDs Affirmation xx: The Working Group affirms existing practice that it is up to a registrar to determine which gTLDs it carries. Discussion: -- Lack of recommendations is not satisfactory. Can we make exceptions for registry operators that have difficulty attracting ICANN accredited registrars so that they can become a registrar? -- It’s not that they can’t become registrars. Is the issue the exemption to the Code of Conduct? -- It sounds like we are talking about granting a Code of Conduct exemption where a Registry Operator has made a good faith effort to recruit registrars to sell its TLD, but it has not been able to get registrars to do it . -- There will be concerns about gaming and what is a “good faith effort”. -- Currently, you are always required to treat all registrars in a non-discriminatory manner, unless you also have Spec 13. So the Code of Conduct exemption just means that you don’t need to have separate books for your registrar services. ACTION ITEM: Add this topic to the legal discussion. 3. AOB: ICANN67 Topics: Applicant Support; Closed Generics; Community Applications; Global Public Interest; GAC Advice/Early Warning

1 0

Re: [Gnso-newgtld-wg] Proposal re Closed Generics
by Alan Greenberg March 2, 2020

March 2, 2020

Fine with me. But in my opinion, that means the exception for public interest TLDs will not fly and we revert to the 2012 implementation of no closed generics. Alan At 25/02/2020 04:32 PM, Mike Rodenbaugh wrote: i do not believe the Board should be allowed to make any decisions that are not "appealable" per the IRP. If Claimant has proper standing and a dispute within the scope of the Bylaws definition of Dispute, then they have a valid IRP claim. This is a very slippery slope to start to carve out Board decisions that have no chance of appeal, and why on Earth would we want to do that anyway? Mike Rodenbaugh RODENBAUGH LAW tel/fax: +1.415.738.8087 http://rodenbaugh.law On Mon, Feb 24, 2020 at 7:08 PM Alan Greenberg <alan.greenberg(a)mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote: I had this in my original proposal but based on individual discussions I have had I know that some people missed it. To have the Board make a decision that is not in any way appealable will require a Bylaw change, but it is a change for which there is another precedent that will go before the Board before out report reaches them. The Auction Proceeds CCWG also will require a similar Bylaw amendment. Alan At 24/02/2020 09:46 PM, Phil Buckingham wrote: Hi Justine , Alan , Anne, Justine , thatÃ¢€™s a great suggestion. The contrntractual compliance & monitoring needs to be much more rigorous in the next round . I very much support AlanÃ¢€™s suggestion of going aheadead with new ( 2020) policy recommendations for a special use case , New TLD application category . LetÃ¢€™s call it a Public Ic Interest TLD . I am working on a proposal ( for FridayÃ¢€™ deadline) .) . It will incorporate the evaluation and implementation issues too. Ultimately my thoughts are we need to make policy that is so demanding , incorporating AlexanderÃ¢€™s suggestion of a Ã¢â‚¢â‚¬œ health warning Ã¢€œ that applications will not pt pass the evaluation. ICANN will need to employ & train Ã¢â‚¬œ evaluation experts. There will be no come backs , no second evaluation , no appeals . Once passed the evaluation The Board would need to approve ( or reject) the application by Special resolution. Your thoughts ? Phil Phil Buckingham Sent from my iPhone On 25 Feb 2020, at 01:30, Justine Chew <justine.chew(a)gmail.com<mailto:justine.chew@gmail.com> > wrote: Perhaps this is something we could pick up under the Contractual Compliance topic. Justine ----- On Fri, 21 Feb 2020 at 01:39, Aikman-Scalese, Anne <AAikman(a)lrrc.com<mailto:AAikman@lrrc.com>> wrote: Thank you Justine. This is very constructive. We would then need to think about enforcement mechanisms. Private dispute resolution process? Filing a complaint with ICANN? Positive obligation by ICANN Compliance to monitor? Accomplish the goals below via PICs and eligibility requirements? Would appreciate your further thoughts. Just continuing the discussion so we can help create a complete proposal as this moves forward to formulate a WG recommendation. Anne From: Gnso-newgtld-wg < gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Justine Chew Sent: Thursday, February 20, 2020 12:28 AM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: Re: [Gnso-newgtld-wg] Proposal re Closed Generics [EXTERNAL] ________________________________ While I remain undecided on supporting either a full ban on closed generics or (what I call) a qualified ban per the special case conditions proposed by Alan, I strongly suggest that any consideration of Alan's proposal should also include the following: Insertion as material in the relevant RA for a closed generic TLD that is a generic word, such terms and conditions: (1) to be derived from the applicant's submission on the use of the closed generic TLD as being in the public interest; (2) which prohibit any action considered as anti-competitive (eg. discriminatory registration policies in favour of certain parties or against competitors in the applicable industry); (3) which govern any dealings on the disposal and/or future use of the closed TLDs - that (1) and (2) must be adhered to at all times and by any party which operates or acquires the rights under the RA; and (4) to stipulate that launching for SLD registration for the closed generic TLD by the (first) RO must take place within 2 years of signing the RA. the breach of one or more of which will constitute cause for termination of the RA. Justine ----- On Thu, 20 Feb 2020 at 13:48, Alan Greenberg <alan.greenberg(a)mcgill.ca<mailto:alan.greenberg@mcgill.ca> > wrote: While talking to a colleague today, I realized a problem with my proposal. I was thinking that there would (or could ) only be a small number of applications that could be deemed to be for closed TLDs that are generic words and in the public interest. That may indeed be true. However, there may well be MANY such applications twhere the applicant beleives their use will be in the public interest, and a large load of such cases going to the Board will not work. The change is to restrict applicants to not-for-profit entities only. This is in keeping with the nature of the one example that has been raised. Note that due to the unfortunate timing of the SubPro meeting being scheduled in conflict with the EPDP, I will likely not be on the SubPro call. To make my position clear, other than this special case I am proposing, I would NOT support the delegation of closed generics. Alan At 18/02/2020 07:43 PM, Alan Greenberg wrote: >The SubPro meeting today began discussing Closed Generics. > >One of my interventions was that although I was strongly opposed to >closed generics in the general case, I did support the concept that >a closed generic could be in the public interest, with the example >of .disaster operating by the International Red Cross as the example. > >I proposed that we allow closed generic applications, but the >decision on whether a particular application would move forward or >not would rest with the ICANN Board. > >The Board would have to agree, by an overwhelming majority (say at >least 90% of sitting, non-conflicted, Board members) that the TLD >would be in the public interest. > >The decision would be final and not appealable through the ICANN >Reconsideration or IRP processes. This latter condition would >require an amendment to the ICANN Bylaws to exempt such decision >from the accountability measures, but this is identical to an >amendment being recommended by the CCWG-Auction Proceeds, so there >is a current precedent. > >If, despite the fact that the decision would have to be near >unanimous, there is still distrust of the ICANN Board in this >matter, the approval of such TLDs could be subject to the Empowered >Community Approval or Rejection Actions (also requiring a Bylaw >change). However, in my mind, such caution would be overkill. > >This proposal would allow a closed generic when it is clearly (in >the view of the Board) in the Public Interest. > >Alan _______________________________________________ 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. _______________________________________________ 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. _______________________________________________ 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.

12 18

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Monday, 02 March 2020 at 15:00 UTC
by Julie Hedlund March 2, 2020

March 2, 2020

Dear all, Please find below the proposed agenda for the call on Monday, 02 March 2020 at 15:00 UTC for 90 minutes: 1. Review Agenda/Statements of Interest 2. Review draft final recommendations – see the Working Document here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…: * 2.7.2 Registrant Protections (page 50) * 2.10.2 Registrar Non-Discrimination / Registry/Registrar Standardization (time permitting - page 52) * 2.5 Registrar Support for New gTLDs (time permitting – page 53) 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] Meeting 02 March
by Julie Hedlund March 2, 2020

March 2, 2020

Hi Alan, There will be an agenda posted today. Kind regards, Julie On 3/1/20, 7:15 PM, "Gnso-newgtld-wg on behalf of Alan Greenberg" <gnso-newgtld-wg-bounces(a)icann.org on behalf of alan.greenberg(a)mcgill.ca> wrote: There is a meeting scheduled tomorrow (https://community.icann.org/x/PwVxBw) but there is no proposed agenda. Is the meeting on or cancelled? Alan _______________________________________________ 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.

1 0