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

Post Call | New gTLD Subsequent Procedures Working Group call / Thursday, 30 January 2020
by Julie Bisland Jan. 31, 2020

Jan. 31, 2020

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

Re: [Gnso-newgtld-wg] EBERO / SLAM Data Status and next steps
by Steve Chan Jan. 31, 2020

Jan. 31, 2020

Dear All, There did not appear to be any comments, questions, or objections to how the EBERO/SLAM data topic was characterized by Jeff, including what will be sought from ICANN Org’s GDD team. The information below will be sent to GDD for their review and resolution. Best, Steve From: Gnso-newgtld-wg <gnso-newgtld-wg-bounces(a)icann.org> on behalf of Jeff Neuman <jeff.neuman(a)comlaude.com> Date: Wednesday, October 2, 2019 at 8:14 AM To: "gnso-newgtld-wg(a)icann.org" <gnso-newgtld-wg(a)icann.org> Subject: [Gnso-newgtld-wg] EBERO / SLAM Data Status and next steps All, On 23 August 2019, high-level statistics were shared from ICANN org’s SLA Monitoring program (attached). These statistics provided the monthly number of 1) DNS failures 2) RDDS failures and 3) DNS and RDDS failures that reached the EBERO threshold. On 26 August 2019, Donna Austin shared a RySG document which included data previously shared by ICANN org at the Madrid DNS Symposium / GDD Summit (attached). This data provided more detail on group 3 above in particular, including elements like: The cause for why the EBERO threshold was reached (i.e., DNS/DNSSEC or RDDS) A further, more specific breakdown within each of the two categories that indicate why the EBERO threshold was reached (e.g., IPv6 transport error, broken chain of trust in DNSSEC, etc.) Within our Working Group there has been some discussion about what impact this data may have. For example, we discussed whether past failures should have any impact on future application evaluations or RSP pre-approval for future rounds? The Working Group, however, is trending towards agreeing that evaluation and thus RSP pre-approval (which is likely to leverage the same or substantially the same evaluation criteria) should be forward looking and not be impacted by past performance. The Working Group is also trending towards requiring the pre-approval prior to each evaluation round and that the approval will be good for the duration of the then-current round. A second area in which this data could have an impact is whether or not existing Registry Service Providers should be grandfathered into any future pre-approval processes? Based on the Working Group’s deliberations and public comment received, the answer appears to be no. Most of the comments seem to point to requiring all RSPs (whether new or existing) to go through the same processes in future rounds. Therefore, based on where the Working Group is heading, the Co-Chairs do no believe that we are in need of additional historical data for purposes of finalizing its work on the RSP Pre-approval program. We recognize that registry service provider performance has been a topic of discussion for matters other than the pre-approval program. We understand that there has been discussion about whether the relatively high number of registry services failures indicates that RSP might need to improve how they operate to ensure the security and stability of the DNS. While this WG is forward looking and not intending to impose new commitments for existing RSPs, lessons may be learned to improve the evaluation process for future applicants/RSPs. Based on the above, the WG believes it does need more context from GDD to understand the data it has been provided, since not all SLA failures are equally harmful. Therefore in looking at the failures, for example, the WG needs clarity on whether they refer to service availability or Round Trip Time (RTT). The WG also wants to try and examine if there was any harm caused by the downtime, which is benefitted in part by understanding the timing of the failure (e.g., prior to Sunrise, during Sunrise, before General Availability, after GA). For the failures that did NOT reach the EBERO threshold, the WG would like summary data of which of the SLRs was missed. For the failures that DID reach the EBERO threshold, a detailed breakdown (e.g., similar specificity that was shared at the Madrid DNS Symposium / GDD Summit), which includes the timing of the failure. This information may help identify weaknesses in the evaluation criteria, registry system testing, and/or contractual requirements captured in the Registry Agreement. The leadership intends to send the request for additional context next week, but we would like to know if there are any comments from the Working Group. Thanks for your attention to this matter. Best regards, Jeff Neuman and Cheryl Langdon-Orr SubPro 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

3 4

Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 30 January 2000 UTC
by Julie Hedlund Jan. 30, 2020

Jan. 30, 2020

Dear Working Group members, Please see below the notes from the meeting on 30 January 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-01-30+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: Affirmation xx (rationale 1): ACTION ITEM 1: Leadership to consider if there is another category beyond recommendations and implementation guidance, such as things for ICANN Org to consider. Affirmation xx (rationale 2): ACTION ITEM 2: Do some research as to whether we are affirming the second sentence: “Application fees may differ for applicants.” ACTION ITEM 3: Add recommendation or affirmation with modification: Historical costs should not be part of the cost structure. Implementation Guidance xx (rationale 3): ACTION ITEM 4: Add two recommendations: 1) in the AGB section -- add “including all fees” as must be published at that time; 2) in this section -- the reassessment of cost recovery must happen prior to each round. ACTION ITEM 5: Add to deliberations: Example of cost floor. Recommendation xx (rationale 4): ACTION ITEM 6: Change to “must have a plan in place” and then also “must be communicated in advance”. Should also say, “the implementation guidance below describes in more detail how this should be accomplished.” Implementation Guidance xx (rationale 4): ACTION ITEM 7: Clarify/re-write: If a floor is not used then excess fees go to applicants; if a floor is used then excess fees go to the programs identified. Implementation Guidance xx (rationale 4): In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories… ACTION ITEM 8: Change to “excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories…” and change it in brackets to a recommendation, changing “should” to “must”. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkR…. The goal of this exercise is intended to accomplish at least a couple of things, 1) Ensure that the format and level of detail, which emphasizes the recommendations/implementation guidance/affirmations and rationale rather than comprehensive deliberations (and which follows the model established by Work Track 5), is supported by the WG, and 2) Give the WG the opportunity to make substantive progress on finalizing topics. 2.5.1 Application Fees & 2.5.2 Variable Fees -- General comment: Make it clear what is implementation guidance and what is a recommendation. -- This is not implementation versus policy -- this is “must” versus “should”. Affirmation xx (rationale 1): -- Note from ICANN Org: “Note that there was a request from ICANN org to clarify if the suggestion that “all applications should incur the same base application fee amount” extends to scenarios beyond “type of application or number of applications.” For example, would an applicant proposing to use a pre-approved RSP pay the same application fee as one who proposes to operate its own back-end registry functions and thus requiring technical evaluation? The WG may want to improve the language to make this clear.” -- With the should class, will there also be an example or type of a case that shows why it isn't a must?  If it’s a “must” in certain types of cases then it’s helpful to have an example -- reasons for not doing it. -- Should put the technical evaluation as a separate fee if they haven’t gone through the pre-approval process. -- Raises an interesting question about the cost-recovery model. -- Added a comment: “Technical evaluation should be a separate fee if not part of pre-approval program (also, technical evaluation fee would be the same whether as part of pre-approval or not).” -- Are we saying that there could be a base fee and the possible deductions and increases? -- Question: If there is an applicant that applies for 20 strings and they don’t go through the pre-approval would they go through the technical evaluation once or 20 times? Answer: You would only go through the technical evaluation once, which would be consistent with the RSP pre-approval program. But might make more sense for them to do a pre-approval. -- Question: Would the same apply to background checks? Answer: There are some differences from a technical review. Might be some minor cost efficiencies. -- Create a third category: Must/should/might. ICANN “might" want to grant price breaks for multiple applicants for the financial and background checks. -- The more that you put into a pre-approval the more the base fee in theory could go down if there are multiple applications. -- The timing of when various evaluations are conducted also matter. As a side point, there was a suggestion that evaluation (background screening?) be conducted twice - once during application and second, prior to contracting. ACTION ITEM: Leadership to consider if there is another category beyond recommendations and implementation guidance, such as things for ICANN Org to consider. Affirmation xx (rationale 2): -- Do some research as to whether we are affirming the second sentence: “Application fees may differ for applicants.” -- Comments: “The Working Group may want to consider whether it wants to affirm the overall structure of the fee (i.e., historical costs, processing, and contingency).” and “I think the opposite is the case at least with respect to historical costs. I believe the group was against doing that, but we will check.” -- WG agrees with the second comment -- that it doesn’t include historical costs, but we should clarify it as an affirmation. ACTION ITEM: Do some research as to whether we are affirming the second sentence: “Application fees may differ for applicants.” ACTION ITEM: Add recommendation or affirmation with modification: Historical costs should not be part of the cost structure. Affirmation xx (rationale 3): -- Why is the word “generally” there? It is because the fee floor is not part of cost recovery, but we could remove the word “generally”. It does not mean that most WG members agreed but not all. Best to remove it. Implementation Guidance xx (rationale 3): -- Should this be a recommendation? We didn’t make it one because we don’t have all the information on what the costs should be. -- Question: What does this mean? When would the price change happen? Answer: When ICANN figures out what the costs will be for the program then it will determine what will be the revenue-neutral fee. They will also have developed a predetermined threshold. We should make it clear that this would take place before applications are submitted. It would be assessed on a per round basis. (Added as a comment.) -- Reference the fact that this needs to be established as part of the AGB prior to each application round. ACTION ITEM: Add two recommendations: 1) in the AGB section -- add “including all fees” as must be published at that time; 2) in this section -- the reassessment of cost recovery must happen prior to each round. Recommendation xx (rationale 4): -- Add the notion of determining the fees for each subsequent round (“reassessment of cost recovery must happen prior to each round.” -- Question: Is this plan intended to be the administrative arrangements for where ICANN keeps the money? It says that ICANN has to have a plan in place for managing the excess fees, but don’t know what we mean by a plan. Does ICANN have to have a separate bank account until it determines what is excess and what is not? Answer: In cases where there was implementation guidance that was tied together we tried to create a what that goes with a how. There are guidance about what ICANN should do to deal with excess fees and shortfalls. It is less about administration, but that there needs to be some sort of communicated in advance plan as to what will happen if there are excess fees or shortfalls. ACTION ITEM: Change to “must have a plan in place” and then also “must be communicated in advance”. Should also say, “the implementation guidance below describes in more detail how this should be accomplished.” Implementation Guidance xx (rationale 4): -- I thought that in the event that a 'fee floor' is used, any excess fees collected above the floor would be returned to the applicants; and if there were any excess fees that remained from the fee floor this excess would go to things like universal awareness etc. -- Explain what "Universal Awareness" means. ACTION ITEM: Clarify/re-write: If a floor is not used then excess fees go to applicants; if a floor is used then excess fees go to the programs identified. Implementation Guidance xx (rationale 4): In the event that an application fee floor is used to determine the application fee, excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories… -- Comment: “Recommend this language be changed to: a global communication and awareness campaign about the introduction and availability of new gTLDs.” Should be differentiated from Universal Acceptance. -- Do we need to be more specific? Preference would be to be more specific. -- Change to a recommendation -- “must”? ACTION ITEM: Change to “excess fees received by ICANN should be used to benefit [the new gTLD programs in] one or more of the following categories…” and change it in brackets to a recommendation, changing “should” to “must”. Implementation Guidance xx (rationale 4): To help alleviate the potential burden of an overall budget shortfall, a separate segregated fund should be set up that can be used to absorb any shortfalls and topped-up in a later round. The amount of the contingency should be a predetermined value that is reviewed periodically to ensure its adequacy. -- I would like to think that the segregated fund is off limits to "loans to ICANN". New issues raised in deliberations since publication of the Initial Report, if applicable: -- Comment: “Is it possible to nominate a % of the overall application fee that is intended to be the fee floor? Absent tangible guidance, implementation will be extremely difficult. Further study in the implementation phase will not be helpful if the variables remain unknown.” -- The one variable that will remain unknown is the number of applications. -- One of the things that we did discuss was the recognition that you are running a piece of Internet infrastructure and there is a benefit to doing that. Can we come up with any idea of what we think the value of that is? That may be impossible. That could be added as one of the variables. Whoever is going to determine the floor should take it into consideration. -- Not sure why we are including this paragraph if there is no recommendation coming out of it. It is intended to acknowledge new issues that were raised after the last public comment, but noting that there was no agreement on a recommendation.

1 0

Correction: Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 30 January 2020 at 20:00 UTC
by Julie Hedlund Jan. 29, 2020

Jan. 29, 2020

Dear all, Please find below the proposed agenda for the call on Thursday, 30 January 2020 at 20:00 UTC for 90 minutes (note correction from 60 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…. The goal of this exercise is intended to accomplish at least a couple of things, 1) Ensure that the format and level of detail, which emphasizes the recommendations/implementation guidance/affirmations and rationale rather than comprehensive deliberations (and which follows the model established by Work Track 5), is supported by the WG, and 2) Give the WG the opportunity to make substantive progress on finalizing topics. * 2.5.1 Application Fees & 2.5.2 Variable Fees 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

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Thursday, 30 January 2020 at 20:00 UTC
by Julie Hedlund Jan. 29, 2020

Jan. 29, 2020

Dear all, Please find below the proposed agenda for the call on Thursday, 30 January 2020 at 20:00 UTC for 60 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…. The goal of this exercise is intended to accomplish at least a couple of things, 1) Ensure that the format and level of detail, which emphasizes the recommendations/implementation guidance/affirmations and rationale rather than comprehensive deliberations (and which follows the model established by Work Track 5), is supported by the WG, and 2) Give the WG the opportunity to make substantive progress on finalizing topics. * 2.5.1 Application Fees & 2.5.2 Variable Fees 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

Meeting Invitation Webinar | EPDP - Phase 2 Proposed Recommendations on a Standardized System for Access and Disclosure | Thursday, 13 February 2020 at 14:00 UTC
by Terri Agnew Jan. 29, 2020

Jan. 29, 2020

Dear all, Please find the details below for the EPDP - Phase 2 Proposed Recommendations on a Standardized System for Access and Disclosure Webinar. This webinar will provide an overview of the EPDP’s Phase 2 proposed recommendations for a Standardized System for Access and Disclosure (SSAD). This effort builds upon the EPDP’s Phase 1 work on enhancing Registration Data Services where, under certain circumstances, personal contact information is now redacted. The Phase 2 effort for developing the SSAD will allow for disclosure of this redacted contact information based on third-party legitimate interests, administration proceedings, and law enforcement needs, subject to applicable law and the rights of the data subject. The webinar will highlight each of the EPDP Team’s recommendations and will provide an opportunity for participants to ask questions and provide feedback on the Initial Report, which is currently out for public comment. The report can be found on the public comment proceedings section on https://www.icann.org/public-comments [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_public-2…>, and the webinar materials will be posted on the EPDP’s wiki page<https://community.icann.org/x/6g6JBw> following the webinar. Thursday, 13 February 2020 at 14:00 UTC for 60 minutes For other times: https://tinyurl.com/wsm7h3y [tinyurl.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__tinyurl.com_wsm7h3y&d=…> Join Zoom Meeting: https://icann.zoom.us/s/331729252 [icann.zoom.us]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.zoom.us_s_331729…> Meeting ID: 331 729 252 Password: 586730 One tap mobile +16699006833,,331729252# US (San Jose) +19294362866,,331729252# US (New York) Find your local number: https://icann.zoom.us/u/abQBVd1jHM [icann.zoom.us]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.zoom.us_u_abQBVd…> Slides to assist you with Zoom: Welcome to Zoom: https://icann.box.com/shared/static/1sal3l5qf4csdukt0pk2c75ey3bte22z.pdf [icann.box.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.box.com_shared_s…> Zoom FAQ: https://icann.box.com/shared/static/d5rap0g6xphevhkdd3mhu2hy753l2m3s.pdf [icann.box.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__icann.box.com_shared_s…> If Zoom disappears, see instructions:https://gnso.icann.org/sites/default/files/policy/2019/present…<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_sites_d…> A calendar invitation has equally been attachment for you to download to your calendar. Thank you in advance for reserving this time in your schedule. Kind Regards, Terri

1 0

Nomination Opens for ICANN Community Excellence Award
by Nathalie Peregrine Jan. 29, 2020

Jan. 29, 2020

https://www.icann.org/news/announcement-2-2020-01-27-en [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_news_ann…> ICANN Launches Dr. Tarek Kamel Award and Opens Nomination for ICANN Community Excellence Award LOS ANGELES - 27 January 2020 – Today, the Internet Corporation for Assigned Names and Numbers (ICANN) announced a new award, the Dr. Tarek Kamel Award for Capacity Building. This award recognizes ICANN community members for significant efforts in developing capacity in areas related to ICANN's mission. Dr. Tarek Kamel Award for Capacity Building The award is established in honor of the late Dr. Tarek Kamel, an Internet pioneer known for his contributions to global Internet governance. At the time of his passing, Kamel was ICANN's Senior Advisor to the President and Senior Vice President for Government and Intergovernmental Organization Engagement. This annual award will be presented to one individual during ICANN's Annual General Meeting, held in the fourth quarter each year. The ideal recipient will have: · Contributed significantly to national, regional, or global capacity-development programs related to ICANN's mission. · Developed capacity-building programs that positively influenced the multistakeholder and diversified participation at ICANN. Details about the award selection process will be available in May 2020. Nomination Opens for ICANN Community Excellence Award The Multistakeholder Ethos Award has been renamed the ICANN Community Excellence Award. ICANN is accepting nominations for this year's award, which will be presented at ICANN68 Kuala Lumpur in June 2020. The ICANN Community Excellence Award recognizes community members who have significantly invested in consensus-based solutions and have contributed substantively to the ICANN multistakeholder model. The ideal recipient(s) will have: · Participated in the ICANN community for a minimum of five years. · Served in multiple ICANN working groups or committees. · Collaborated significantly with more than one Supporting Organization (SO) or Advisory Committee (AC). Candidates will be evaluated by a panel of ICANN community members appointed by the SO/AC chairs using a merit-based point system, using three criteria: 1. Demonstrates an ability to work across community lines with both familiar and unfamiliar ICANN stakeholders with the aim of building consensus. 2. Facilitates dialogue and open discussion in a fair and collegial manner through the spirit of collaboration, showing empathy and demonstrating a sincere desire to engage with people from other backgrounds, cultures, and interests. 3. Demonstrates additional support for the ICANN multistakeholder model and its overall effectiveness through volunteer service via working groups or committees. Please submit nominations via this nomination form [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_forms_…>. Include detailed information outlining why the nominee meets the award criteria. Any additional information in support of nominations and questions about the award process may be submitted to excellenceaward2020(a)icann.org<mailto:excellenceaward2020@icann.org>. For more information, please consult the ICANN Community Wiki.<https://community.icann.org/x/YyOAAw>

1 0

Proposed agenda - New gTLD Subsequent Procedures PDP WG - Tuesday, 28 January 2020 at 03:00 UTC
by Julie Hedlund Jan. 25, 2020

Jan. 25, 2020

Dear all, Please find below the proposed agenda for the call on Tuesday, 28 January 2020 at 03:00 UTC for 60 minutes: 1. Review Agenda/Statements of Interest 2. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkR…. The goal of this exercise is intended to accomplish at least a couple of things, 1) Ensure that the format and level of detail, which emphasizes the recommendations/implementation guidance/affirmations and rationale rather than comprehensive deliberations (and which follows the model established by Work Track 5), is supported by the WG, and 2) Give the WG the opportunity to make substantive progress on finalizing topics. * 2.5.1 Application Fees & 2.5.2 Variable Fees 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 Thursday, 23 January 2020
by Andrea Glandon Jan. 23, 2020

Jan. 23, 2020

Dear all, All recordings for the New gTLD Subsequent Procedures Working Group call held on Thursday, 23 January 2020 at 20:00 UTC can be found on the agenda wiki page<https://community.icann.org/x/DgVxBw> (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 - 23 January 2000 UTC
by Julie Hedlund Jan. 23, 2020

Jan. 23, 2020

Dear Working Group members, Please see below the notes from the meeting on 23 January 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-01-23+New+gTLD+Subsequent+Pr…. Kind regards, Julie Notes and Action Items: Actions: 2.4.2 Communications: ACTION ITEM 1: Get a copy of the GAC advice re: notification of applications for certain strings. Noting that this issue was addressed in WT5 and did not rise to the level of a recommendation. ACTION ITEM 2: Add a link at the beginning of the document and note support for section of PIRR recommendation 8.5.a, which states "Consider customer service to be a critical function of the organization, and ensure that the Customer Service Center has the appropriate resources to support the ongoing and future activities of the New gTLD Program." 2.4.3 Systems: Re: Implementation Guidance xx: The Working Group suggests a number of feature enhancements to support an improved user experience. Specifically, the Working Group suggests the following capabilities for applicant-facing systems: ACTION ITEM 5: Add voluntary PICs to this list and 16 and 22 in brackets. For 23 - allow standard ones to autofill, no autofill for non-standard. Notes: 1. Updates to Statements of Interest: No updates provided. 2. Review draft final recommendations – see attached Working Document and here:https://docs.google.com/document/d/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkR…. The goal of this exercise is intended to accomplish at least a couple of things, 1) Ensure that the format and level of detail, which emphasizes the recommendations/implementation guidance/affirmations and rationale rather than comprehensive deliberations (and which follows the model established by Work Track 5), is supported by the WG, and 2) Give the WG the opportunity to make substantive progress on finalizing topics. a. 2.4.1 Applicant Guidebook: -- Took some notes from the WG conversation on 21 January. New text in Recommendation xx. Also changes to Implementation Guidance xx. b. 2.4.2 Communications, continue discussion from page 3: -- Edit in Affirmation xx - deleted Implementation Guideline E and added it below as a separate affirmation, noting suggested modification. Implementation Guidance xx.a: For timeliness, the Working Group believes that for the next subsequent round there should continue to be a minimum of four (4) months from the time when the final Applicant Guidebook is published and the application submission period begins. While this Implementation Guidance should serve as the minimum, additional time may be needed based on other factors such as the RSP pre-approval process, the level of substantive change to the program during implementation, etc. In addition, the Communications Period should begin at least six months prior to the window opening. Essentially, the communications plan should be commensurate with the time needed to perform elements like the non-exhaustive list below: * Outreach related to Applicant Support * Establishing and allowing interested parties to engage in the RSP pre-approval process -- Points out an overlap between the time the AGB is published and the communications period begins. The final AGB must be published at least 4 month before the application submission period opening. So you could have the communications period starting without the AGB being published. Implementation Guidance xx.b: Consistent with the recommendations in section 2.2.3 Applications Assessed in Rounds, the Working Group believes that a shorter communications period (i.e., less than the minimum 6 months stated above) may be needed for subsequent rounds if and when a steady state for application submission windows is established. -- Change “windows” to “periods”. -- Study state that is continually getting outreach so you don’t need to call out a separate 6-month period. Implementation Guidance xx.c: For broad outreach, the Working Group believes that consistent with recommendation 8.4.b from ICANN org’s Program Implementation Review Report, the program should “Leverage ICANN’s Global Stakeholder Engagement (GSE) team to promote awareness of the New gTLD Program within their regions/constituencies.” The Working Group believes that the GSE team could be leveraged to support the dissemination of program information and supporting education and overall outreach. The various Supporting Organizations and Advisory Committees are also important partners in sharing information. -- Question: When would third party service providers be selected? Answer: We aren’t specifying a time period. We do ask that all the rules are in place prior to the application submission period opening. ICANN would need to build that into their schedule. -- The first sentence says, “should leverage ICANN’s GSE team” but next sentence says, “could”. Shouldn’t it be “would”. ACTION: Change to “would”. Implementation Guidance xx.d: For accessibility, the Working Group stresses the need for a single, well-designed website dedicated to the New gTLD Program to support the sharing and accessibility of program information, which is consistent with recommendation 8.4.a from ICANN org’s Program Implementation Review Report. Once on the site, broadly speaking, users should be able to obtain information they are seeking in an effective manner. To that end, the Working Group has suggested specific elements for consideration: * Continue to maintain an online knowledge database, but ensure that it is robust, easy to search and navigate, is updated on a timely basis, and emphasizes issues with wide-ranging impact. In addition, to the extent possible, all items in the online knowledge database should reference applicable sections of the Applicant Guidebook to which the items relate. * Create an opt-in based notification system for applicants to receive program updates, updates to the online knowledge database, and application-specific updates. -- Noting where something already exists in implementation from the 2012 round -- such as the note relating to SLAs. If the WG disagrees then they will need to address this. “The WG suggested publishing SLAs, but these are already published by virtue of inquiries being centrally managed by ICANN's Global Support Center (GSC) group. Accordingly, staff has left this suggestion out.” ACTION ITEM: Get a copy of the GAC advice re: notification of applications for certain strings. Noting that this issue was addressed in WT5 and did not rise to the level of a recommendation. Implementation Guidance xx.e: For timeliness and accessibility as it relates to applicant communications, the Working Group believes that robust customer support is needed to address substantive and logistical questions as well as inquiries regarding use of applicant-facing systems. Real-time communication methods are preferred (e.g., telephone, online chat), but the Working Group recognizes that these forms of communication may beare costly. Further, the Working Group also recognizes that there may need to be different methods utilized. For instance, technical support for submitting an application may be different than responding to substantive inquiries about completing an application. Staff note: “For coherence, I'm going to suggest that we don't need separate recommendations about customer support for systems and should instead cover all aspects of customer support here (see 2.4.3.c.8 and 2.4.3.c.16, the original recs under systems). May also want to note the link to PIRR recommendation 8.5.a, which states "Consider customer service to be a critical function of the organization, and ensure that the Customer Service Center has the appropriate resources to support the ongoing and future activities of the New gTLD Program."” -- WG could decide whether to agree with that suggestion. Should at least include a citation to it. Wouldn’t be an affirmation (of something from 2012), but could include it as a guidance or something we agree with. ACTION ITEM 2: Add a link at the beginning of the document and note support for section of PIRR recommendation 8.5.a, which states "Consider customer service to be a critical function of the organization, and ensure that the Customer Service Center has the appropriate resources to support the ongoing and future activities of the New gTLD Program." Deliberations and rationale: Text added: “The Working Group also recognizes that during the 2012 round, ICANN Org was reluctant to provide real time support due to its equal access obligations and not wanting to appear to be giving some applicants information that was not necessarily provided to other applicants. The Working Group notes that although this is a legitimate concern, there should be ways to provide real-time support in a manner which does not run afoul of those equal access obligations.” c. 2.4.3 Systems Affirmation xx: The WG affirms Implementation Guideline O from the 2007 Final Report, which states: ““ICANN may put in place systems that could provide information about the gTLD process in major languages other than English, for example, in the six working languages of the United Nations.” -- Should we state the same Affirmation twice or have some other way to do this without re-affirming it twice? Or we could cite the previous. -- Just a consistency of language issue: is there a difference between the generally agreed and wide agreement? I think it would be helpful, if there is no difference, that we maintain consistent language.  -- Make a general edit to be consistent -- pick one. -- Streamline/edits at the end since we are going out of order. Implementation Guidance xx: In support of improved usability, the Working Group suggests that specific data entry fields in applicant-facing systems should accept both ASCII and non-ASCII characters. Although the Working Group recognizes that English is the authoritative language for the New gTLD Program, there are a number of fields including the Examples of appropriate fields include applied-for string, Applicant’s name, and contact information (including e-mail addresses) that should be collected and displayed in their native language / script. -- Did anyone ever identify a field where non-ASCII was needed, but was not supported? -- Don’t think it was allowed for addresses or people’s names. Implementation Guidance xx: The Working Group suggests a number of feature enhancements to support an improved user experience. Specifically, the Working Group suggests the following capabilities for applicant-facing systems: * provide applicants with automated confirmation emails. * provide applicants with automated invoices for application-related fees. * allow applicants to view historical changes that have been made to the application both during the application and evaluation phases. [changes made by whom? Need to clarify]. * allow applicants to upload application documents into the application system. * allow applicants to auto-fill information/documentation in multiple fields across applications. This functionality should only be enabled in a limited number of fields where it would be appropriate for responses to be identical. It should not be possible to auto-fill mission, purpose and non-standard services to be rendered. * allow applicants to specify additional contacts to receive communication about the application and/or access the application and specify different levels of access for these additional points of contact. -- Question re: first bullet: C10 - is it possible to be more specific about when we want to see confirmation emails? Answer: confirmation for any type of change/activity. Usually when you get an automated response, you get that every time something happens with that application, every change. -- Question re: third bullet: Changes from the applicant? Answer: Changes by a user. Anyone who has online access to their information. -- Note re: fourth bullet: “C13 - PIRR states that "For questions that allowed attachments, the application form provided the capability to attach files." Given that files could be uploaded, we need to be more specific in the recommendation. Perhaps the WG would like to affirm the recommendation in the PIRR (1.1.a) that states "explore a more structured way of capturing applicant responses," intended to address the issue of responses getting cut of in some open text fields. ..” -- Notes from Jeff re: fifth bullet: “We should be more specific by referencing specific questions in the original list of questions in the Applicant Guidebook. I would say 18(a), 18(b), 19, 20, 21, 23 (but only if additional services) would be the only ones potentially that would fit into the category of not allowing auto-fill.” -- Question: Could ask where PICs come in in the application system?  Answer: PICs were treated by the case-system, not by the application system.  -- Suggest non-auto fill for PICs. -- Non-auto-fill for Question 18 and Question 23 and agree with Justine - no autofill for voluntary PICs.  -- Question 23 is pretty broad -- only with respect to additional services beyond the base services. -- Question add question 22? Answer: Did not suggest adding it. Most had the same answers -- if you were going to ensure that all applicants are residents of the particular area and it will be for both TLDs don’t see an issue with allowing autofill. -- Question 16: The answers are all the same so no need not to allow autofill. -- If you don’t allow autofill you can’t prevent applicants from providing duplicate text. ACTION ITEM: Add voluntary PICs to this list. Put 16 and 22 in brackets. For 23 - allow standard ones to autofill, no autofill for non-standard. -- Note re: sixth bullet: “More information may be warranted for this guidance. For instance, which types of user need additional access or communications? Are the communications different or is it simply a cc?” -- Could just punt the specifics to the implementation team. Implementation Guidance xx.a: To ensure predictability and minimize obstacles and legal burdens for applicants, any Agreements or Terms of Use associated with systems access (including those required to be “clicked-through”) should be finalized in advance of the Applicant Guidebook’s publication and published with the AGB. See also Implementation Guidance xx in Section 2.4.1 (Applicant Guidebook). -- Staff note: “As noted in that section, need to be more specific about which agreements: RA, Applicant TOU, and/or Systems TOU?” -- This one was aimed at all of the other terms of use that were dropped on applicants at the last minute. This is referring to everything other than the RA and the TOU. New Issues Raised in Deliberations: -- Staff note: “Originally part of rec c4. Alternately, if the WG does not feel that the cited Guidelines are sufficient to address data breach in applicant-facing systems, it could provide specific guidance on how these situations should be treated differently. The WG could consider leveraging language from here regarding handling of security incidents: https://www.icann.org/en/system/files/files/nsp-terms-of-use-11may18-en.pdf. Note that any additional guidance would be specific to systems used for the New gTLD Program.” Next meeting: 28 January 2020 at 0300 UTC. Start with 2.5.1 Application Fees & 2.5.2 Variable Fees.

1 0