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

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 19 September 2019
by Julie Hedlund Sept. 19, 2019

Sept. 19, 2019

Dear Working Group members, Please see below the notes from the meeting on 19 September 2019. 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/2019-09-19+New+gTLD+Subsequent+Pr…. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: Actions: Objections: Possible new high-level agreement: -- "All panelist for providers will be free from conflicts of interests and there will be an appeal mechanism should a party believe that a panelist or a provider has an unresolved conflict of interest." Then, the AGB can just implement that.  Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review of summary documents: a. Objections -- See: https://docs.google.com/document/d/1BkRn9nYeBNjyx2mTw-3nIDn22jTumWd4w1PZR-K…, page 2 Outstanding Items - New Ideas/Concerns/Divergence: Ensuring that panelists, evaluators, and Independent Objectors are free from conflicts of interest -- Need to separate out CPE. -- Not sure about publishing all of the panelists. In the CPE there was an opportunity to object to a panelist. -- So long as the parties have a chance to review potential conflicts of individual panelists that should satisfy the conflict of interest provision. Not sure that the community outside of the parties need to have this information. -- Could be for community objection, but not for CPE. -- Question: Who determines the conflict issue once a party objects? Is there an appeal from that determination?  Answer: there was an IRP proceeding related to a panelist having a perceived conflict of interest - https://www.icann.org/resources/pages/dot-sport-v-icann-2015-03-27-en -- There is a process already where a panelist has to declare that there are no conflicts to the provider themselves, and the list of the panelists goes to the parties. -- The providers already have mechanisms for appeal. -- That should be part of the criteria by which ICANN assesses / appoints service providers --- ie provision for dealing with COI. -- So the Policy would be "All panelist for providers will be free from conflicts of interests and there will be an appeal mechanism should a party believe that a panelist or a provider has an unresolved conflict of interest." Then, the AGB can just implement that.  -- Could be whatever appeal mechanism we determine in relation to other possible appeals. -- It may be worth looking at section 2.4.3 of the AGB again, which talks about Code of Conduct Guidelines for Panelists, to if there is truly a delta to be resolved . High Level Agreement: For all types of objections, the parties to a proceeding should be given the opportunity to agree upon a single panelist or a three-person panel - bearing the costs accordingly. Choice of single panelist or a three-person panel (see High-Level Agreement B above). -- Re: ALAC comment -- in danger of reinventing the wheel. -- Need to look at the cost distribution of the party that doesn’t want a second or third panel. -- Do all service providers follow that UDRP policy on costs being picked up by party asking for 3 panelists highlighted by Susan?  -- All parties should agree to moving to 3 panelists. -- Question: Seems like this high-level agreement is to allow all objections to choose 1 or 3 panelists. Would that then be a change to the Limited Public Interest Objection, which always was 3. Would it now be limited to 1? Answer: The comments were meant for all types of objections. Limited Public Interest then could have the option of a single panelist. Publish, for each type of objection, all supplemental rules as well as all criteria to be used by panelists (see High-Level Agreement C above). -- Re: ICANN Org comment: These supplemental rules were published well after the reveal and without guidance on what they could or could not do in the supplemental rules. -- There should be greater transparency in the selection and appointment of service providers, AND all rules which are to apply to any objection process should be available upfront. -- Supplemental rules aren’t supposed to cover the policy, but are administrative. -- But supplemental rules and documents extended beyond that - specifically for CPE - and without addressing it here it may happen for objections going forward. Non-substantiative is one thing, but reinterpretation of the AGB is another. -- Keep CPE out of the discussions as it is not an objection, but can talk about community objections. High-Level Agreement: Extension of the “quick look” mechanism, which currently applies to only the Limited Public Interest Objection, to all objection types. The “quick look” is designed to identify and eliminate frivolous and/or abusive objections. (High-Level Agreement D)  Extension of the quick look mechanism to all objection types (see High-Level Agreement D above). -- Comments have suggestions for improving quick look. -- Re: RySG comment -- CANN should develop clearer criteria to assist the DRSP in accurately identifying abuse and develop additional appropriate sanctions, including financial penalties and the loss of the ability to make additional objections.

1 0

FW: GNSO Council Letter to ICANN Board on NCAP-SubPro Dependencies
by Aikman-Scalese, Anne Sept. 19, 2019

Sept. 19, 2019

The list rejected the JAS Final Report as requiring moderator approval because the file is so big. I am forwarding this message with a modified file showing the JAS summary recommendations (not the full report). Anne From: Aikman-Scalese, Anne Sent: Wednesday, September 18, 2019 4:37 PM To: 'Jeff Neuman' <jeff.neuman(a)comlaude.com>; 'gnso-newgtld-wg(a)icann.org' <gnso-newgtld-wg(a)icann.org> Subject: GNSO Council Letter to ICANN Board on NCAP-SubPro Dependencies Hi Jeff and Cheryl, Regarding Monday's call on name collisions, I have the following comments. 1. There seemed to be a lot of discussion about JAS having asserted that the system they recommended "worked". In this regard, the WG has not actually had a substantive discussion on the harm associated with name collisions. The only reporting requirement from the 2012 round was to report to ICANN any instances that involved a threat to human life. As we know, that is not the only risk posed by name collisions. The risks include the following as detailed in the attached ICANN advice to IT Professionals (see pages 6-7 of the attachment): Para 2.1 - Direction to Unexpected Websites - and interception by malicious actors (which security certificates may not be adequate to prevent), allowing access to sensitive information and/or allowing the malicious actor to install dangerous code on the user's computer. Para 2.2 - Direction of Email to the Wrong Recipients Para 2.3 - Security Reductions In the attached JAS Final Report that Jeff and Rubens referenced, Recommendation 14 states as follows: [cid:image001.png@01D56E3F.2B39F030] Assessing these dangers is a critical part of NCAP Study 1 - to define the harm - and that has to happen in order to have an intelligent discussion of the topic. The NCAP has a half day meeting in Montreal on Friday afternoon November 1. I am sure Sub Pro WG members are welcome. And I know Jeff assured the NCAP Discussion Group that he joined the Discussion Group for the purpose of coordinating policy with them. 2. Re the IPC position, just to clarify, the IPC consensus was to defer to NCAP if NCAP recommendations are ready in time for launch. Given that we project a couple of years before the framework for launch can be in place, it seems reasonable to expect that we could at least develop some sort of testing mechanism for DO NOT APPLY and the Work Track 4 risk categories prior to launch, either via NCAP or an independent advisor. Jeff and Cheryl's additions to the GNSO Council letter to the Board should be helpful in this regard. Anne From: Aikman-Scalese, Anne Sent: Tuesday, September 10, 2019 9:34 PM To: Jeff Neuman <jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com>>; gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: RE: FOR REVIEW: Draft GNSO Council Letter to ICANN Board on NCAP-SubPro Dependencies Hi Jeff and Cheryl, Thanks for sending. Two quick comments: (1) the word "including" in b) seems to be missing a letter (2) In this draft, can we please ask about the pending discussion in relation to the development of a "DO NOT APPLY" list? (The sooner the NCAP develops a methodology for that, the better off we all are.) I have not seen a specific reference to a method for testing as to "DO NOT APPLY" or very high risk strings in Study 1 and so the timing there is a bit concerning. ALAC points out we could take a bunch of applications and then not delegate until that work is done. I have always thought and always commented that there should be a way for an applicant to test a string for name collision issues without having to pay the whole application fee and put all the effort into an application and business plan only to find it's a "no go". We need to be asking about a gating mechanism on this issue to save people a lot of time and trouble. If that gating mechanism were developed during the time the AGB is being written, then that might prove a way forward to coordinate the timing. Many thanks for putting this together. I believe the Board commented that there was an "opportunity for collaboration" with NCAP and an ability to work out the scheduling so that maybe their reply (in line with the public comment filed by the Board). But it never hurts to clarify. Anne From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org<mailto:gnso-newgtld-wg-bounces@icann.org>> On Behalf Of Jeff Neuman Sent: Tuesday, September 10, 2019 7:47 PM To: gnso-newgtld-wg(a)icann.org<mailto:gnso-newgtld-wg@icann.org> Subject: [Gnso-newgtld-wg] FW: FOR REVIEW: Draft GNSO Council Letter to ICANN Board on NCAP-SubPro Dependencies [EXTERNAL] ________________________________ All, We just wanted to forward this note to the SubPro PDP Full Working Group. Cheryl and I were asked by the GNSO Council Leadership to give our thoughts to them about the attached draft letter from the Council to the ICANN Board. We provided this feedback and as you can see we made it clear that the redlines are from Cheryl and I and not the Working Group. Please let us know if you have any questions. Jeff Neuman and Cheryl Langdon-Orr From: Jeff Neuman <jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com>> Sent: Tuesday, September 10, 2019 10:44 PM To: Drazek, Keith <kdrazek(a)verisign.com<mailto:kdrazek@verisign.com>>; Cheryl Langdon-Orr (langdonorr(a)gmail.com<mailto:langdonorr@gmail.com>) (langdonorr(a)gmail.com<mailto:langdonorr@gmail.com>) <langdonorr(a)gmail.com<mailto:langdonorr@gmail.com>>; Pam Little <pam.little(a)alibaba-inc.com<mailto:pam.little@alibaba-inc.com>>; rafik.dammak(a)gmail.com<mailto:rafik.dammak@gmail.com> Cc: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>; gnso-chairs(a)icann.org<mailto:gnso-chairs@icann.org>; Steve Chan <steve.chan(a)icann.org<mailto:steve.chan@icann.org>>; Emily Barabas <emily.barabas(a)icann.org<mailto:emily.barabas@icann.org>>; Julie Hedlund <julie.hedlund(a)icann.org<mailto:julie.hedlund@icann.org>>; Jeff Neuman <jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com>> Subject: RE: FOR REVIEW: Draft GNSO Council Letter to ICANN Board on NCAP-SubPro Dependencies Dear Keith, Pam and Rafik, Please find enclosed Cheryl and my redlines to the draft letter. We do not believe the substance of the letter has been changed at all, but rather just added some more specificity. This letter contains only the comments of Cheryl and I and not the Subsequent Procedures Working Group. There are so many people making so many arguments and even if the Board says that there are "dependencies", I think they need to be specific as to which exact step is the completion of the NCAP work dependent on. What is the exact point where we cannot move forward. Some people say the Board cannot accept the final policy without this work being done. Some say the policy can be completed, but implementation work cannot be completed prior to the NCAP finishing. Some say that can complete but we cannot complete the AGB. Some say we can complete that but we cannot announce the new round. Some say we can announce but cannot accept applications. Some say we can do it all but not delegate. And finally some say we can delegate and use existing name collision model until NCAP states otherwise. We hope this makes sense and please forward to the GNSO Council for its consideration. Thanks again for reaching out to us. We are going to forward this correspondence chain to the Full Working Group as well. Best regards, Jeff Neuman and Cheryl Langdon-Orr Subsequent Procedures Co-Chairs Jeff Neuman Senior Vice President Com Laude | Valideus D: +1.703.635.7514 E: jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com> From: Drazek, Keith <kdrazek(a)verisign.com<mailto:kdrazek@verisign.com>> Sent: Monday, September 9, 2019 6:48 PM To: Jeff Neuman <jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com>>; Cheryl Langdon-Orr (langdonorr(a)gmail.com<mailto:langdonorr@gmail.com>) (langdonorr(a)gmail.com<mailto:langdonorr@gmail.com>) <langdonorr(a)gmail.com<mailto:langdonorr@gmail.com>> Cc: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>; gnso-chairs(a)icann.org<mailto:gnso-chairs@icann.org> Subject: FW: FOR REVIEW: Draft GNSO Council Letter to ICANN Board on NCAP-SubPro Dependencies Jeff/Cheryl, FYI, attached is the draft Council letter to the Board on NCAP and SubPro. This has been sent to the Council list for consideration and comment. Best, Keith From: council <council-bounces(a)gnso.icann.org<mailto:council-bounces@gnso.icann.org>> On Behalf Of Drazek, Keith via council Sent: Monday, September 09, 2019 3:47 PM To: council(a)gnso.icann.org<mailto:council@gnso.icann.org> Cc: gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> Subject: [EXTERNAL] [council] FOR REVIEW: Draft GNSO Council Letter to ICANN Board on NCAP-SubPro Dependencies Hi all, Attached for your review is a draft letter from the GNSO Council to the ICANN Board concerning dependencies between the NCAP and Subsequent Procedures PDP. Please review and advise if you have any comments or questions. We can discuss on the list and this will be included on the agenda for our 19 September GNSO Council meeting. Thanks, Keith ________________________________ The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see www.comlaude.com<https://comlaude.com> ________________________________ This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. ?2510-2521.

2 3

ICANN66 Prep Week Announcement
by Julie Hedlund Sept. 16, 2019

Sept. 16, 2019

Dear SubPro PDP WG members, The following announcement may be of interest. Best regards, Julie Julie Hedlund, Policy Director Register for ICANN66 Prep Week Webinars LOS ANGELES – 16 September 2019 – Today, the Internet Corporation for Assigned Names and Numbers (ICANN) released the schedule for ICANN66 Prep Week, which features a series of seven webinars to prepare the community ahead of its Annual General Meeting in November. To attend any of the below webinars, please register here<http://go.icann.org/prepweeksignup> by 11 October to receive joining instructions. You may also submit questions during the registration process. All registered attendees will receive participation details days before the webinar dates. ICANN66 Prep Week Webinars Schedule Monday, 14 October 2019 16:00 UTC | Global Stakeholder Engagement (GSE) Update: What to Expect at ICANN66 Tuesday, 15 October 2019 16:00 UTC | ICANN66 Plenary Session: DNS Abuse 23:00 UTC | Pre-ICANN66 Contractual Compliance Update Wednesday, 16 October 2019 16:00 UTC | ICANN66 Plenary Session: Evolution of ICANN's Multistakeholder Model 23:00 UTC | Multistakeholder Strategy and Strategic Initiatives (MSSI) Update Thursday, 17 October 2019 12:00 UTC | Generic Names Supporting Organization (GNSO) Policy Update 16:00 UTC | Pre-ICANN66 Policy Update All webinars be in English. Materials from the Pre-ICANN66 Policy Update will also be available in French. Recordings and materials will be posted here<https://meetings.icann.org/en/montreal66-prep-week>. Prep Week was established to help streamline the pre-meeting experience, as well as increase awareness of plenary topics, foster deeper conversations and enhance briefings and readout sessions.

1 0

Re: [Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 16 September 2019
by Jamie Baxter Sept. 16, 2019

Sept. 16, 2019

1 0

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 19 September 2019 at 20:00 UTC
by Julie Hedlund Sept. 16, 2019

Sept. 16, 2019

Dear all, Please find below the proposed agenda for the call on Thursday, 19 September 2019 at 20:00 UTC for 90 minutes: 1. Welcome and Updates to Statements of Interest 2. Review of summary documents: b. Objections -- See: https://docs.google.com/document/d/1BkRn9nYeBNjyx2mTw-3nIDn22jTumWd4w1PZR-K…, page 3 c. Accountability Mechanisms -- See: https://docs.google.com/document/d/1BkRn9nYeBNjyx2mTw-3nIDn22jTumWd4w1PZR-K…, page 15 3. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Kind regards, Julie Julie Hedlund, Policy Director

1 0

Post call / New gTLD Subsequent Procedures Working Group call on Monday, 16 September 2019 at 15:00 UTC
by Michelle DeSmyter Sept. 16, 2019

Sept. 16, 2019

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

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 16 September 2019
by Julie Hedlund Sept. 16, 2019

Sept. 16, 2019

Dear Working Group members, Please see below the notes from the meeting on 16 September 2019. 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/2019-09-16+New+gTLD+Subsequent+Pr…. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: 1. Updates to Statements of Interest: No updates provided. 2. Review of summary documents: a. Name Collisions -- See: https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrou…, page 55 Outstanding Items - New Ideas/Concerns/Divergence: -- GNSO Council letter to the Board asking about dependencies with the NCAP report with respect to the new gTLD subsequent procedures. -- More Unknowns than knowns at this stage from the NCAP work. So we need to draw some lines in the sand for our work re: dependencies. -- The lack of high-level agreements so far reflect divisions in the community and in the WG that will make us default to 2012 implementation in most of the topics. -- Some vendors have opted not to bid for the RFP for Study 1, but RFP is still open. -- In the comments, there is no consensus in deferring or not deferring to NCAP or SSAC. -- WG needs to plan for both circumstances: 1) NCAP is completed; 2) NCAP is not completed. -- Question: how many languages/scripts are involved? Answer: name collisions are about strings in ASCII characters. Name collisions only happen "in the wire", meaning that only in ASCII, even though that could be the IDNA representation of an IDN string. -- Question: Has any work been done on the RYSG ask for a look at the effectiveness of the previous mitigation measures? (sorry on mobile so slower reaction time)? Answer: Final report issued by the JAS advisors. Based on their data they do believe the previous mitigation measures have worked. -- Zero mishaps perhaps because we don’t know if controlled interruption actually worked effectively to alert us. -- From a evidence-driven PDP methodology, the only available data says 0. If NCAP work is not completed prior to the next application round, should the default be that the same name collision mitigation frameworks in place today be applied to those TLDs approved for the next round? -- Re: RySG comment, “No. ICANN should, at a minimum, release the studies its done on the names collision frameworks so that the community can judge if the same frameworks should be applied. If ICANN cannot do that, ICANN should conduct a prompt, formal study that quantifies and measures the efficacy of the previous controlled interruption framework should be conducted before modifying or replacing the system, without delaying the next round. Without these baseline measurements, assessing the risks of an alternative CI framework is not possible.” Question: Is there any evidence to the contrary since the JAS report? Answer: NCAP is looking to see if there was anything else. -- There is no evidence that controlled interruption worked as intended. -- Only by asking all Internet users if it worked or not could there be evidence of it having worked 100%. -- Hard to find evidence that may or may not be out there. -- An additional concern is that it wasn’t a vetted community driven design   -- But for all anybody knows, it worked. Despite some FUD on the other direction.   -- It is another unknown as it is a risk assessment ratio risk. -- In response to Rubens…. Rubens part of the scope of Study 1 of NCAP to review the papers and results to come to an assessment - we should not be trying to do that now, as a pdp WG - NCAP will make an independent assessment as per its scope. -- In order to prove it worked, ICANN would have to make some representative strings not go through controlled interruption, and see what happened in that control group compared to the full slate.  -- NCAP study 1 is just a collection of published material, with no conclusion to be made.  -- Suggestion to the final report: 2012 implementation (due to lack of consensus) + substantial refund + possibility of disabling CI on a per-string basis at ICANN Org request. -- Good for the WG to acknowledge the findings of SAC90 and potentially agree with them with respect to collaboration. b. Objections -- See: https://docs.google.com/document/d/1BkRn9nYeBNjyx2mTw-3nIDn22jTumWd4w1PZR-K…, page 2 High-Level Agreements: Re: ICANN must publish, for each type of objection, all supplemental rules as well as all criteria to be used by panelists for the filing of, response to, and evaluation of each objection. Such guidance for decision making by panelists must be more detailed than what was available prior to the 2012 round. (High-Level Agreement C) -- Could the WG include a recommendation this should be done prior to accepting any applications? For those who were part of the community applications, there were supplemental rules created after applications were submitted and after objections. If there are going to be supplemental rules they need to be published prior to applications being submitted. -- Seems like the first three bullets could be very costly, depending on how implemented. -- Don’t think the WG is asking for new rules, just for transparency in supplemental rules and in selecting panelists. -- So there does need to be a balance between transparency and flexibility. There will be some unknowns prior to the applications being submitted. -- Basically anything that is meant to apply to objection procedures must be made available upfront. -- Should we carve out community applications, versus community objections? -- Those that filed/responded to LPI and other objections would liekly agree with increased transparency. -- Community objections were also used by community applications to try resolving their contention sets, not only by standard applications against declared as community applications. -- Do we need to make a There appears to be a concern about the latter being developed on the fly. -- The point is not about CPE here, but rather about how supplemental documents for CPE were published years after ICANN accepted community applications. Unless we are clear in subsequent procedures about supplemental materials not being permitted for objections, then we don’t have any way of preventing them from doing so. -- Important to know costs ahead of time. -- Basically anything that is intended to apply to objection procedures must be made available upfront. -- Can we separate CPE into a separate category of objections? Community Objections are a different discussion. -- Perhaps providing a list of the changed elements would assist the group in understanding the issues you are presenting.  -- CPE is part of string contention resolution.

1 0

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Monday, 16 September 2019 at 15:00 UTC
by Julie Hedlund Sept. 13, 2019

Sept. 13, 2019

Dear all, Please find below the proposed agenda for the call on Monday, 16 September 2019 at 15:00 UTC for 90 minutes: 1. Welcome and Updates to Statements of Interest 2. Review of summary documents: a. Name Collisions -- See: https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrou…, page 55 b. Objections -- See: https://docs.google.com/document/d/1BkRn9nYeBNjyx2mTw-3nIDn22jTumWd4w1PZR-K…, page 2 c. Accountability Mechanisms -- See: https://docs.google.com/document/d/1BkRn9nYeBNjyx2mTw-3nIDn22jTumWd4w1PZR-K…, time permitting, page 15 3. AOB If you need a dial out or would like to submit an apology, please email gnso-secs(a)icann.org<mailto:gnso-secs@icann.org>. Kind regards, Julie Julie Hedlund, Policy Director

1 0

Post call | New gTLD Subsequent Procedures Working Group call | Thursday, 12 September 2019 at 20:00 UTC
by Julie Bisland Sept. 12, 2019

Sept. 12, 2019

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

1 0

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 12 September 2019
by Julie Hedlund Sept. 12, 2019

Sept. 12, 2019

Dear Working Group members, Please see below the notes from the meeting on 12 September 2019. 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/2019-09-12+New+gTLD+Subsequent+Pr…. Kind regards, Julie Julie Hedlund, Policy Director Notes and Action Items: 1. Updates to Statements of Interest: No updates provided. 2. Review of summary documents: a. Role of Application Comment -- See: https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrou…, page 51, Outstanding Items High-Level Agreements: -- Most were presented as implementation guidance. -- Also proposal for applicants to have a short time period to respond to public comments. Application Comment System Usability and Attachments: -- ICANN Org: Comment form does offer a number of the functions that the WG asked to have cover. Attachments are not searchable and sortable. Also could ask cost for review and evaluation Discussion: -- ICANN Org’s comments seem to be backward looking on the existing system. -- ICANN Org will try to use as much of the existing systems as possible. Will assess whether or not the tool is still fit for purpose and if not we will rebuild. -- Clarify that ICANN Org’s concern is not a technical concern for attachments, but that if we allow attachments that means that someone could attach a 300 page document to a comment and it would take the evaluation panel longer to review, with associated costs. -- Compromise is that the substance has to be in the comment itself and the attachment could only be used for reference or confirmation of what is in the comment. -- Still have an issue that anyone can set up an email and send in a comment but it doesn’t mean that they are a real person -- not validating that they are who they say they are. -- ICANN Org: Identify verification is very challenging to do particularly given the volume of applications and application comments. Right now we just make sure it is not a robot. -- Question: Why does the identify of the commenter matter at all? If the comment itself is valuable? Answer: There are two comments -- general comment period and comments that can impact scoring. The person making comments in a community priority evaluation should matter. Important to note that many of the same comments are posted to make it seem like there is widespread concern about an application, but that isn’t necessarily widespread. -- Key point here is that the verification process currently in place does not tackle the larger issue of gaming during public comment, although I realize that it helps reduce automated commenting. How Application Comments are taken into account and impact on scoring: -- ICANN Org -- what does the WG mean when ICANN should be more explicit in the AGB on how different types will or will not impact scoring -- helpful to be more clear about what we mean by “more explicit”. What should the new rules and guidelines be? -- WG is saying that it will still be left to the evaluators to consider those comments but the community should develop guidelines so that we don’t leave them so much discretion. -- Ensure that is a comment comes in that may impact the scoring then applicants should be able to address that directly. Discussion: -- Clarification on ICANN Org comments -- the evaluation panel has to look at those comments that were directed to them. It’s not a matter of whether or not they can choose, especially if that causes them to change a score, then they will have to seek clarification from the applicant. -- But the above isn’t documented in the AGB. -- Part of this is documenting what ICANN Org has already been doing in practice. -- Needs to be more transparency in how comments are considered. -- The WG is saying if the comment could have an impact on the scoring, before it is scored, then ICANN Org seeks clarification. -- For CPE in 2012 the evaluator had the opportunity to reach out at their discretion. -- Note that CPE is unique. One of the criteria for a community application was level of support and another was level of opposition. So there might need to be other issues to consider for Community Applications. Change in the length of time for application comment in relation to Community Priority Evaluation (CPE): -- Support for a longer comment period. -- Support for equal length comment period. -- “letters of opposition” should be considered a form of public comment and should adhere to the same submission deadlines. Concern about comments coming in years later for community applications. Should come in within a defined time period. Discussion: -- Timing of the last round should not be repeated. -- There needs to be an ending point. Need predictability. -- Need to have a beginning, middle, and end. -- 2012 AGB referenced public comment and community objection. No reference to “letters of Opposition”. They should be considered part of public comment. -- Most important to have predictability -- at least a beginning and end. Whether that beginning and end for CPE comment period is run at the exact same time as the general public comment period -- as long as it is predictable. -- If you look at 2012, was most of the substance came in during the public comment period. What came in later was people amplifying previous comments. Left the door open to gaming. -- Why should community applicants be subjected to longer comment periods just because ICANN org chose to put CPE at the end of the evaluation process. would standard applicants be open to longer comment periods if community priority is done at the beginning of subsequent procedures? Responding to comments that might impact scoring through Clarifying Questions; and Applicants given time to respond to the public comments prior to the consideration of those comments: -- NCSG: New Idea - The NCSG believes that if applicants are allowed to respond to comment, commenters should be allowed another round of comments (question 2.3.e.2) -- NCSG: New Idea - Last but not least, the broader community should be allowed to respond, critique and comment on the applicant’s response. It is very important to have this public response period, following applicant’s and something past experience shows it is critical for the future applicant guidebook to include. Discussion: -- Re: NCSG comment -- sounds like too much back and forth. -- Re: NCSG comment -- this is a traditional way of doing things. -- Two questions 1) does the comment affect scoring and the applicant doesn’t respond -- what is the consequence; 2) if the applicant does respond should the commenter be allowed to respond, and what are the consequences. -- Applicants have the option to respond or not to comments -- if the comment is positive, there is less reason TO respond, if the comment is negative, then evaluators may rely on that omission TO RESPOND as a presumption of some sort or not. -- Finish the loop -- make sure they did address the comment. -- Could support giving the commenter an opportunity to respond in a defined time and manner. -- Think about certain of number of days for comment, reply, comment. Only use for a limited purpose. b. Name Collisions -- See: https://docs.google.com/document/d/1Q6_DxsCvSA_3B7ArncO2U4tWNY3vH7Wi4nINrou…, page 55 -- No high-level agreements. -- Very technical issue being addressed in other areas of the community. -- Not enough from a policy perspective. -- We do know that there is an NCAP Phase 1 study that is starting -- RFP, but don’t know if a vendor has been selected. Don’t know if Phase 1 will lead to Phase 2. Don’t know what Phase 2 would be. -- The PDP WG Co-Chairs asked the Council to clarify with the Board what it is thinking in terms of dependencies. GNSO Council drafted a note to send to the Board, Co-Chairs commented asking for more specificity, forwarded draft to the WG, GNSO Council will send to the Board. 3. AOB: Update on SLAs -- Where are we on providing more details with the SLAs? Some information provided by GDD but not the same level of detail as was provided to the contracted parties. -- Staff spoke with GDD to convey the problems we are trying to solve and when might they deliver. It is a non-negligible amount of work to get that information. Could the WG further refine the problem it is trying to solve. Perhaps GDD could tailor that information. -- We have seen ICANN use that data in certain ways. -- If we can’t get the context of what is behind the data then we can’t make any assumptions. -- Jim Prendergast will follow up with more comments via email.

1 0