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

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

Closed generics proposal
by Dorrain, Kristine Feb. 28, 2020

Feb. 28, 2020

All, As promised on last week's call, I offer a proposal for what we're calling "closed generics." I wanted to turn the attention away from the binary question of "closed generics" or "no closed generics" and think about why some ROs may have applied for closed generics. If we can solve for these problems (e.g. create processes that solve for folks' concerns AND allow applicants to innovate), my guess is, the fight will fade. The examples are not based on real stories but are illustrative; other use cases could be imagined if we move away from only thinking of domain names as the end product/commodity. We should encourage next round applicants to innovate and explore ideas - we didn't get the Tesla by forcing everyone to build a Model T, the Model T was a starting point to improve upon. 1. Applicant offers a product or service for which unique URLs are part of the product. Controlling the namespace is part of the critical safety and infrastructure. * Example: .heart * Use: applicant develops a new pacemaker that stays in contact with the doctor, the pacemaker, an app on the patient's phone, and an online dashboard page that certain necessary folks have access to. * Why should this TLD be single-user? i. The RO has to undergo extensive security and privacy testing - by controlling the entire space (including being its own Registrar), the applicant can guard against phishing, malware, hijacking, etc. ii. The domain name is not sold to the end-user. It's the way the devices and dashboards communicate. It does not need a retail chain or any Rr markup or fees for the applicant to create the names it needs to run its product. The domain is just an easy handle for mobile and desktop access to the dashboard. It performs a function and is not a consumer product or service itself. Some of you will argue that ALL medical device manufacturers should then have access to .heart, but that's unrealistic since the medical device company that controls .heart will own all of the security and no other medical device company would be willing to trust their competitors with their data and security. Some of you will ask: a. "Why not just make it a .brand"? For a registry that is working on a standard for communication and security in this space, they will want it to be more "open" versus branded. That doesn't mean just anyone can obtain. The registry may need flexibility to monitor across a number of entities. Also, startups may not have a brand yet, or part of the new product/service may be creating a new brand. b. "But why not a community? Because some startups may be trying to disrupt an entrenched industry and you may not be able to get the large industry trade associations to back you and instead try to prevent change or innovation, as we saw in the last round. We want to encourage innovation and new models. We don't want to be ourselves an entrenched industry that is unwilling to embrace change. 1. Applicant startup is considering a new service that, when combined with a domain name, offers a new and unique benefit to the customer (a private sandbox, a unique dashboard, a control center for a device, whatever). It's possible that when this idea comes to fruition, the end user will need/want to own or control the domain name, but since the end user is not using the domain name to put up a site, but instead to interact with the service, this is unlikely. Having to own and manage a domain name will be clutter in the customer's life-they want the service. * Example: .dashboard * Assume there is no need/desire for the customer to deal with "owning" the domain name. The current ban on closed generics means that we're forcing the customer to register and manage a domain name that they don't want in order to obtain the service or device. i. Suggestion: create an option for an RO to decide domains in its TLD will be part of a bigger product or service and so long as the domain is bundled, the TLD can be owned and operated by the RO. * Assume the applicant may want to transfer ownership to the end user later. RO needs to alpha- and beta-test this idea before it launches - it really doesn't even know what the final registration policies will be because it hasn't decided its model yet. It needs customers and feedback. RO only has 100 "free" domains to work with and once you use them they're gone. This is not enough for a good beta test. i. Suggestion: make it easier for an Approved Launch Program or a new (TBD) Beta Program to include a multi-year beta. ii. Suggestion: include some guardrails or "PIC" language to ensure that when the idea is launched to customers, Spec 9 will apply at that point. 1. Applicant has cool ideas but needs time to test (similar to 2(c), above, but in a more traditional model). It wants to eventually offer names to customers for sale but needs to be able to break things and try things - pre-RSEP, pre-full registrant access. How can a registry experiment and figure out what works for their customers - the registrant - if the rules say they have to just open up. What happens if, upon opening, they realize the TLD rules need to be modified? Allowing models to be "closed" and test for some time will lead to more experimentation and new models in the long-run. * Suggestion: One set of guardrails could be a set number of test names that don't count against the RO 100, or a specific "test phase." As we can see, there is little point in assuming why ROs applied for closed generics - there were very likely business cases and innovative ideas behind the last round applications. These scenarios demonstrate that it is not difficult to imagine business cases that could benefit from innovation - nor is it difficult to fashion solutions to address concerns that some may have about using TLDs in this way. Instead of being stuck in the binary yes/no deliberations of 8 years ago and failing to meet the Board's expectation that we will come back to them with a sensible policy recommendation, let's instead build the guardrails that will allow innovation to proceed. Thanks, Kristine Dorrain

7 9

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

Feb. 27, 2020

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

1 0

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

Feb. 27, 2020

Dear Working Group members, Please see below the notes from the meeting on 27 February 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-02-27+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: Affirmation xx (with modification) (rationale 3): ACTION ITEM: Replace “use a pre-evaluated RSP” to "use an RSP who has successfully completed the Pre-Evaluation Program. (Pre-evaluated RSP)". Implementation Guidance xx (rationale 5): ACTION ITEM: Consider integrating the Module 2 elements from Q30b. Implementation Guidance xx (rationale 6): ACTION ITEM: Re: “may only need to be performed once as opposed to being evaluated for each individual application” -- Explanatory text or clarifying text might be needed here. Implementation Guidance xx (rationale 10): Re: “iii. If the applicant is an Affiliate (as defined in the current Registry Agreement) of a current Registry Operator that is not in default on any of its financial obligations under its applicable Registry Agreements, and has not previously triggered the utilization of its Continued Operations Instrument.” ACTION ITEM: Add the Registry Operator (RO) itself: It intended all options:  RO, Affiliate of an RO, parent company etc. Rationale for Recommendation xx-xx (rationale 2): ACTION ITEM: Revise the last sentence to, “Accordingly, there is support for a thorough examination [during the implementation of these policy recommendations] of why there were so many CQs in 2012 and how they can be significantly reduced in future rounds[, prior to the finalization of the Applicant Guidebook].” (new text in brackets) Notes: 1. Review Agenda/Statements of Interest: 2. Working Method: From Jeff’s email at http://mm.icann.org/pipermail/gnso-newgtld-wg/2020-February/002553.html: * We are currently using the following Working Document to support initial review and discussion of draft recommendations: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…<https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…>. This will continue to be the document where you will find newly drafted recommendations that have not yet been discussed on a call. You are encouraged before each call to review the sections on the upcoming agenda and insert comments into the document and/or raise questions/concerns on the mailing list. Staff will continue to note preliminary suggested edits in the Working Document during the call as items are discussed. * Once a section has been discussed on a call (or multiple calls), the leadership team will work on revisions in redline in the Working Document. * When a set of revised sections are ready for review by the WG, the leadership team will add a “clean” version of those sections to a new document, what we are tentatively calling the “Production” document, which will be read-only. These sections will be released in logical clusters, for example all sections related to Pre-Launch Activities. The leadership team will send an email to the group with date by which any comments on those sections should be provided. A redline of the revisions will be available in the Working Document for reference, but once the revision is sent out, members should not add new comments or suggestions in the Working Document. Instead, they should follow the process below. * The Working Group will use the method used successfully by the EPDP Team in the finalization of their Initial Report. Specifically, WG members will be asked to limit comments to items in the revised section that they absolutely “cannot live with.” If there is text that they cannot accept, they will fill out a form like the one attached and send it to the WG by email. The form asks for the specified text that the WG member cannot accept, a suggested revision, and the rationale for the revision. * Any issues identified will be addressed and resolved on the mailing list, or if necessary, scheduled for discussion on a subsequent call. Discussion: -- This is what the EPDP used. -- Question: Is this just to get us to agree on the document to go out for public comment, right? Answer: Yes. You also can file comments in the public comment period. -- After we get the public comment in we may use this method to produce the Final Report. -- Re: the Work Plan -- We have added meetings the week before and after ICANN67 so we’ve revised the Work Plan to with the possibility of publishing the report sooner. 3. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkR…: 2.7.7 Applicant Reviews: Technical/Operational, Financial and Registry Services (page 43) -- First section is the general notion of applicant reviews. -- First affirmation is affirming several principles from 2007. Overall Evaluation: Recommendation xx (rationale 1): Evaluation scores on all questions should be limited to a pass/fail scale (0-1 points only). Discussion: -- Comment from Jim Prendergast: “as I recall there were some questions worth more than 1 point in the 2012 round because of their importance. As an example, are we suggesting that description of purpose is on par with efforts to address DNS abuse if we limit point values to 1?” -- This evaluation is performed for everyone RSP if they don’t participate in the pre-evaluation or if they didn’t pass. -- ICANN’s PIRR recommended eliminating the 2-point questions. Technical and Operational Evaluation Affirmation xx (with modification) (rationale 3): The Working Group affirms recommendation 7 from the 2007 policy with the following proposed additional text in italics: “Applicants must be able to demonstrate their technical and operational capability to run a registry operation for the purpose that the applicant sets out, either by submitting it to evaluation at application time or agreeing to use a pre-evaluated RSP. Discussion: -- Comment from Jim Prendergast: “suggest alternative language. "use an RSP who has successfully completed the Pre-Evaluation Program. (Pre-evaluated RSP)" Then link back to the section of the recommendations for reference.” ACTION ITEM: Replace “use a pre-evaluated RSP” to "use an RSP who has successfully completed the Pre-Evaluation Program. (Pre-evaluated RSP)". Implementation Guidance xx (rationale 5): A mechanism(s) should be established to meet the spirit of the goals embodied within Q30b - Security Policy without requiring applicants to provide their full security policy. Discussion: -- Comment from Jim Prendergast: “We need to ensure that the AGB clearly defines what the "spirit of the goals embodied within Q30b" actually are. Otherwise that it may be open to interpretation by applicants new and old.” ACTION ITEM: Consider integrating the Module 2 elements from Q30b. Implementation Guidance xx (rationale 6): ICANN org or its designee should aggregate and/or consolidate the technical and operational evaluation across applications to the extent feasible where the applications, for all intents and purposes, share identical responses to the relevant questions, particularly as it relates to the proposed registry services. This is intended to apply even when an applicant indicates that it will not use a pre-evaluated RSP. For example, if an applicant submits multiple applications or multiple applications are submitted from different applicants that share a common technical infrastructure, the technical and operational evaluation may only need to be performed once as opposed to being evaluated for each individual application. Discussion: -- Is this consistent with recommendations on how applications get prioritized? -- What this is saying is the first time you evaluate an RSP whether during pre-evaluation or after, the results of the first evaluation will carry over to every time that RSP is used in an application. -- Don’t think there is an impact of the RSP technical evaluation in the queuing of applications. -- Priority is process-wide, so when it comes to technical evaluation, it ends up being publish priority, in order to gain from cost-savings at evaluation. -- There may be circumstances when the same technical infrastructure may be evaluated again, which is only where this applies. -- Only evaluate the new elements of the application. ACTION ITEM: Re: “may only need to be performed once as opposed to being evaluated for each individual application” -- Explanatory text or clarifying text might be needed here. Financial Evaluation: Implementation Guidance xx (rationale 10): Re: “iii. If the applicant is an Affiliate (as defined in the current Registry Agreement) of a current Registry Operator that is not in default on any of its financial obligations under its applicable Registry Agreements, and has not previously triggered the utilization of its Continued Operations Instrument.” ACTION ITEM: Add the Registry Operator (RO) itself: It intended all options:  RO, Affiliate of an RO, parent company etc. Rationale for Recommendation xx-xx (rationale 2): The Working Group believes that in service of transparency, the Clarifying Questions (CQs) and responses to those CQs should be published for all publicly posted application questions. However, the Working Group recognizes that CQs and their responses for publicly posted application questions may inadvertently share private information. Respecting the privacy and confidentiality of responses is important. The Working Group believes that the number of CQs in the 2012 round were excessive, indicating a lack of clarity in the way that the application questions were phrased and/or presented. Accordingly, there is support for a thorough examination of why there were so many CQs in 2012 and how they can be significantly reduced in future rounds. Discussion: -- Comment from Jim Prendergast: “Is there a deadline for when this must be done?” ACTION ITEM: Revise the last sentence to, “Accordingly, there is support for a thorough examination [during the implementation of these policy recommendations] of why there were so many CQs in 2012 and how they can be significantly reduced in future rounds[, prior to the finalization of the Applicant Guidebook].” (new text in brackets)

1 0

General Path Forward / Working Methods
by Jeff Neuman Feb. 27, 2020

Feb. 27, 2020

Dear Working Group members, The Co-Chairs would like to add an item to the agenda for the call later today. As discussed on our 13 February Working Group call, the WG leadership team has been considering the best way to manage the WG's process for reviewing and revising draft recommendations to include in the draft Final Report. The WG has now discussed a number of draft report sections on calls, and would like to propose the following next steps: * We are currently using the following Working Document to support initial review and discussion of draft recommendations: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…<https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…>. This will continue to be the document where you will find newly drafted recommendations that have not yet been discussed on a call. You are encouraged before each call to review the sections on the upcoming agenda and insert comments into the document and/or raise questions/concerns on the mailing list. Staff will continue to note preliminary suggested edits in the Working Document during the call as items are discussed. * Once a section has been discussed on a call (or multiple calls), the leadership team will work on revisions in redline in the Working Document. * When a set of revised sections are ready for review by the WG, the leadership team will add a "clean" version of those sections to a new document, what we are tentatively calling the "Production" document, which will be read-only. These sections will be released in logical clusters, for example all sections related to Pre-Launch Activities. The leadership team will send an email to the group with date by which any comments on those sections should be provided. A redline of the revisions will be available in the Working Document for reference, but once the revision is sent out, members should not add new comments or suggestions in the Working Document. Instead, they should follow the process below. * The Working Group will use the method used successfully by the EPDP Team in the finalization of their Initial Report. Specifically, WG members will be asked to limit comments to items in the revised section that they absolutely "cannot live with." If there is text that they cannot accept, they will fill out a form like the one attached and send it to the WG by email. The form asks for the specified text that the WG member cannot accept, a suggested revision, and the rationale for the revision. * Any issues identified will be addressed and resolved on the mailing list, or if necessary, scheduled for discussion on a subsequent call. We realize that this process is new and WG members may have questions about it, which is why we are starting this discussion about the process on the upcoming call. Given the large amount of material we have to cover in the coming months and the importance of staying on schedule with the revised work plan, the leadership team is confident that the proposed path forward will keep the group moving forward. We look forward to continuing the discussion as we finalize the next steps. Jeff Neuman & Cheryl Langdon-Orr Subsequent Procedures PDP Co-Chairs ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com>

5 4

Re: [Gnso-newgtld-wg] Proposal re Closed Generics
by Alan Greenberg Feb. 26, 2020

Feb. 26, 2020

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

9 12

Proposed text on Application Comment
by Rubens Kuhl Feb. 26, 2020

Feb. 26, 2020

Replace "As was the case in the 2012 round, applicants should continue to be given the opportunity through Clarifying Questions to respond to comments that might impact scoring." With "As was the case in the 2012 round, when an application comment would make an evaluator reduces scoring, applicants must have the opportunity through Clarifying Questions to respond." Rewording just changes it to "should"; when rewriting, the use of must occurred to me as a better option, but it's a bit of a substantive change. Rubens

4 3

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

Feb. 25, 2020

Dear all, Please find below the proposed agenda for the call on Thursday, 27 February 2020 at 20:00 UTC for 90 minutes: 1. Review Agenda/Statements of Interest 2. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5…: 2.7.7 Applicant Reviews: Technical/Operational, Financial and Registry Services (page 42) 3. AOB Please prepare for the following topics for future meetings: Monday, 02 March at 15:00 UTC: Continued discussion of 2.7.7 Applicant Reviews: Technical/Operational, Financial and Registry Services 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