[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 23 January 2000 UTC

[Julie Hedlund]

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+Procedures+PDP.

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/1kUlmZH8nxWTgfcRluA5FxLheMm4XhhOwkRt7om52aQU/edit?usp=sharing. 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20200123/7cce224c/attachment-0001.html>