February 2020 - Gnso-newgtld-wg

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

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

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

Feb. 25, 2020

Dear Working Group members, Please see below the notes from the meeting on 25 February 0300 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-25+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: a. 2.2.5 Applications Submission Limits ACTION ITEM: Edit the rationale. The goal is not to put the rationale into the recommendation or affirmation language. We think we can soften the language of the rationale a bit to keep in mind the summation of the three different positions. But, at the end of the day, the affirmation is still the affirmation that no limits should be placed on the applications. b. 2.3 Role of Application Comment ACTION ITEM: Re: Affirmation xx (rationale 1): Ruben Kuhl will suggested revised language to the WG on the email distribution list. ACTION ITEM: Add a second affirmation that says there will be an opportunity to comment on submitted applications via the public comment process. Also, expand rational #1 accordingly. Implementation Guidance xx (rationale 4): The [Implementation Review Team] community should develop guidelines about how public comments are to be utilized or taken into account by the relevant evaluators and panels, and these guidelines should be included in the AGB. The AGB should also be clear to what extent different types of comments will or will not impact scoring. ACTION ITEM: Change “community” to “Implementation Review Team” to be more specific. Notes: 1. Review Agenda/Statements of Interest: No updates provided. 2. ICANN67 Status Update – See the FAQs at: https://www.icann.org/resources/pages/icann67-faq-2020-02-24-en [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource…> -- SO and AC Chair met last week and also will meet today to discuss the schedule and are seeking feedback from the community. -- The PDP meetings will be held in the remote format. We are seeking 5.5 hours (as originally planned) of meetings. -- Encourage GAC participation to have fruitful community discussions and reduce impact of GAC advice on some of these topics. -- Need to be able to show in our Final Report that there has been full community dialogue on these issues. -- Helpful if your groups could put in a word of support for participation in these remote sessions. -- Virtual meeting hours are likely to be from 1400 to 2200 UTC. -- Since people will not be traveling we will put back on the schedule the WG meeting on 05 March as well as the meetings on 16 and 19 March. 3. Review draft final recommendations – see attached Working Document and here: https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om5… a. 2.2.5 Applications Submission Limits Affirmation xx: The Working Group believes that there should continue to be no limits placed on the overall number of applications or the number of applications a particular entity may submit. This affirms the existing implementation as no limits were placed on the number of applications in total or from any particular entity in the 2012 application round. Discussion: -- Comment from Kathy Kleiman: “This was the subject of huge discussion and disagreement; it seems entirely too simple a statement for our more complicated conclusion: some applicants want unlimited applications and other members of the Community are very concerned...pure invocation of the Neuman Rule??” -- So when we say that there's a recommendation or an affirmation. We're not saying that everybody in the community agrees that or that there's unanimity certainly we've heard some members of the community state that they thought that there should be some submission limits. But if you go back to Work track 1 that discussed this issue as well as the comments to the initial report there was a minority view that there should be submission limits. I think there was one proposal for a particular number, though there was no evidence provided as to why that was the number selected overall in total due to both the enforceability aspect as well as the overwhelming comments in support of no limits. This is why we believe the affirmation comes out here. -- What really belongs here was that there was severe disagreement on this and there was considerable discussion about how to put in some kind of reasonable limits of parents subsidiaries, etc. -- Put this back into the deliberations: “The working group could not come up with a consensus on application limits or non-limits.” -- Cannot support the text as it stands. T text as it stands, as well as the case in 2012 facilitates concentration and the registry registrar businesses. -- I think we are being inconsistent in how we are handling situations where we could not come to closure. This is an instance where the WG could not come to consensus. -- When we had the initial discussions we felt that there should be limits but there was no practical way to do it – too difficult to verify. That doesn’t get reflected here. -- If you look at the comments from Subgroup A this is not an area where there was strong disagreement. Christopher Wilkinson was opposed and so was the Public Interest Registry. It was not just the Registries that supported it, but also the Registrars and the Business Constituency, as well as the Brand Registry and the IPC. This is pretty strong support with a minority view. We haven’t had a consensus call so we are not using the word consent. -- Shouldn’t go back to just the comments as that doesn’t reflect the discussion in the WG. -- On the question of whether we need to reflect the minority opinions, those could be left to a minority report or minority statement. -- If we reworded this paragraph to be more like what we stated in the initial report, namely that although some members of the community supported the notion of putting limits into place the working group concludes, however, that there are no effective fair and or feasible mechanisms to enforce such limits therefore no limit should be imposed on either the number of applications in total, or the number of applications from any particular entity. -- Don’t want to replicate the deliberations from the Initial Report because we are trying not to have a 400-500-page report. -- Don’t agree to change the wording except perhaps to tack on a clause that there was a minority of people who disagreed. -- Seems like there are at least three schools of thought: 1) Those that favor having no limitations. 2) Those that might favor having limitations or would favor having limitations, but don't see a feasible equitable way to do it, and therefore, are unsatisfied with going with the status quo and then 3) those that oppose the status quo and believe that there are feasible equitable ways or at least a possibility and haven't gotten to the point where they want to give up on that idea and therefore, continue to support that. -- So if you add up the two first two schools of thought together, you end up with the conclusion. So perhaps what needs to be said is that there were a number who did not support limitations and others who could not find a way to implement limitations and therefore supported the status quo and others that objected, and that taking the two first two groups together the recommendation is that to keep the status quo. ACTION ITEM: Edit the rationale. The goal is not to put the rationale into the recommendation or affirmation language. We think we can soften the language of the rationale a bit to keep in mind the summation of the three different positions. But, at the end of the day, the affirmation is still the affirmation that no limits should be placed on the applications. b. 2.3 Role of Application Comment -- Comments from Kathy Kleiman: “Don’t we have need affirmation here: As was the case in the 2012 round, Community members will continue to be given the opportunity to comment on submitted applications via a Public Comment process where their comments are visible to other members of the Community, Applicants, and those processing the Applications (including ICANN and third parties) can review and consider the comments.” -- Let’s see if that comment is reflected in the recommendations and if not we’ll come back to that. -- But there's no affirmation that says that there will be an opportunity to comment on submitted applications via public comment process. ACTION ITEM: Add a second affirmation that says there will be an opportunity to comment on submitted applications via the public comment process. Also, expand rational #1 accordingly. Affirmation xx (rationale 1): 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 Discussion: ACTION ITEM: Re: Affirmation xx (rationale 1): Ruben Kuhl will suggested revised language to the WG on the email distribution list. Implementation Guidance xx (rationale 4): The [Implementation Review Team] community should develop guidelines about how public comments are to be utilized or taken into account by the relevant evaluators and panels, and these guidelines should be included in the AGB. The AGB should also be clear to what extent different types of comments will or will not impact scoring. Discussion: -- Comment from staff: “Does the WG want to provide any more specific guidance on what should those new rules and guidelines be? Also, suggest removing this sentence originally in the high-level agreement as it appears to repeat the second affirmation above: "In addition, to the extent that public comments are to be taken into account by the evaluators, panels, etc., applicants must have an opportunity to respond to those comments." If different from the affirmation above, we may want to rephrase to be more explicit.” ACTION ITEM: Change “community” to “Implementation Review Team” to be more specific. Recommendation xx (rationale 5): Applicants should have a clear, consistent, and fair opportunity to respond to the public comments on their application prior to the consideration of those comments in the evaluation process. Implementation Guidance xx (rationale 5): Applicants should be given a fixed amount of time to respond to the public comments on their application prior to the consideration of those comments in the evaluation process. Discussion: -- Comment from Kathy Kleiman: “Should applicants modify their applications in response to public comment, there should be a way to directly notify the Commenters of this change-to-the-application -- as they are all identified per earlier Recommendation. (Commenters may want to re-comments e.g., to support the change or to argue it does not fully address the concern.)” -- The applicant should have a clear, consistent fair opportunity to respond to the public comments on their application prior to the consideration of these comments in the evaluation process. -- Let's say the applicant modifies their application in response to the public comment. Then what what I'm suggesting is that there should be a way to directly notify the commenters of the change to the application. -- The recommendation is that should applicants modify their applications into response to public comment there should be a way to directly notify the commenters of the change to the application so that there's an opportunity to review it and further comment. -- Let's take that apart because there's a couple different components in there. So if an applicant changes their application the separate change process would kick in and that would automatically kick in the new comment period on the change. So I'm not sure we need to affirmatively state that the public comment period itself needs to have almost like a reply period but maybe an acknowledgement that if an applicant changes their application as a result of the public comments, then please see the change process section so we have a tie a tie in between the two. -- Question: Is this a proposal for a reply period, or that a change to the application would initiate the change process? Answer: The proposal is that initial commenters should know that there's been a change and that there's a new comment period that's open so that they know where to go. It’s not a reply, but it’s a notice. -- Perhaps that could be as an overall comment when we talk about the usable system and being searchable perhaps include something there about notifications about specific applications as kind of a implementation guidance. Rationale for Recommendation xx and Implementation Guidance xx (rationale 2): In the 2012 round, in order to submit a comment, a user first needed to create an account by providing name, email address, and optionally affiliation. The system sent an email to the email address provided and affirmative confirmation from the email address needed to be received by the system before an account was created. This functionality verified that there was a person attached to the email account. The Working Group raised concern, however, that this system did not verify that the person creating the account was who he or she claimed to be. The Working Group noted commenters could potentially misrepresent who they were or who they represented and “game” the system to disadvantage certain applicants. Recognizing that evaluation panelists perform due diligence in considering application comment, and the challenge of confirming the true identity of all contributors to public comment, the Working Group nevertheless encourages ICANN to seek opportunities to verify the identity of commenters in a meaningful way to reduce the risk of gaming and to require applicants to disclose any relationship with an applicant for the sake of transparency. Discussion: -- Comment from Kathy Kleiman: “Note: if the commenter cannot be identified, evaluation panelists can always take this into account. It's possible someone might not want their comments to a .POLICE or .KGB gTLD to be identified back to them :-)” -- Re: this recommendation on identifying commenters: There were concerns expressed that competitors and those that may not have the best of intentions may have been filing comments in order to harm other applications. So, requiring someone to state their affiliations was deemed an important part of the recommendations for members of the working group when we had those discussions. -- Concerns about the feasibility of identifying commenters, but that is why we have this as Implementation Guidance, so that ICANN Org can determine the best way to do it. We say that they should seek opportunities to verify. -- Don’t see any reason to change the direction on transparency. -- Nothing in hear prevents someone from submitting an anonymous comment. Next Steps: Review the Work Plan at: https://docs.google.com/spreadsheets/d/1SN8GX1nVER30p_VmX1fAEJUTRLByXhrI96k… -- We will try to move up some topics for next Thursday and for the meetings in the week following ICANN67. -- For this Thursday, 27 February and next Monday, 02 March we’ll cover Applicant Reviews.

1 0

ICANN67 FAQs
by Julie Hedlund Feb. 25, 2020

Feb. 25, 2020

Dear All, Please find the ICANN67 FAQs posted here: https://www.icann.org/resources/pages/icann67-faq-2020-02-24-en [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resource…> Kind regards, Julie Julie Hedlund, Policy Director

1 0