[Gnso-newgtld-wg-wt1] Actions/Discussion Notes: New gTLD Subsequent Procedures PDP WG Meeting - Sub Team 1 - 28 February 2017

Emily Barabas emily.barabas at icann.org
Wed Mar 1 12:00:35 UTC 2017


Dear All,

Please see below the action items and discussion notes captured by staff from the Sub Team 1 meeting on 28 February 2017. These high-level notes are designed to help Working Group members navigate through the content of the call and are not a substitute for the recording. The recording is available at https://community.icann.org/x/l7PDAw.

Kind regards,
Emily



Agenda:
1.     Welcome & Agenda Overview
2.     SOIs
3.     Communications & Systems
a.  From the New gTLD Program Implementation Review provided several recommendations that the group may want to consider in developing implementation guidance on Systems and Communications. https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf
   i.  Systems (see page 174)
  ii.  Communications (see page 198)
4.     Application Guidebook,https://community.icann.org/display/NGSPP/4.2.5+Applicant+Guidebook?preview=/58735907/58737106/Section%204.2.5.pdf
5.     CC2 Questions, https://docs.google.com/document/d/1iZBCVEAJPBYEDg7jLsMHKkNczR_b6-jH2Wl5eVH-WWM/edit#<https://docs.google.com/document/d/1iZBCVEAJPBYEDg7jLsMHKkNczR_b6-jH2Wl5eVH-WWM/edit>
6.    AOB

Action Items:

ACTION ITEM: WT1 leads will circulate request for input on CC2 questions by email.

Notes:

2.     SOIs
- No updates.

4.     Application Guidebook
- Introduction:
- Background: The AGB is different from some of the other subjects the group is considering in that it is not the result of consensus policy.
- The AGB was the vehicle for implementation of the policy. There were 9 versions of the AGB over 4 years. Used as a guide for staff in the implementation.
- Questions & Concerns: Some DG members suggested dividing the AGB into sections by audience or making it a procedural guide with background separated out in a different section. Some suggested that the AGB was not the right vehicle although no alternative was proposed.
- Rationale for policy development - the DG did not anticipate policy development, but the WG may want to make suggestions for changing the AGB structure or approach. The WG could also recommend an alternate vehicle to the AGB.
- Discussion:
- Is the AGB the right methodology?
- The AGB is as good as any other potential vehicle, we don't need to completely revamp it. There is a lot of rationale and background, legalese.
- There is an opportunity to do an "idiot's guide" or a stripped down version with the things applicants need to know (rationale in a different section or document).
- How can the current AGB be improved? By type of application? Can it be made more readable?
- Not necessarily by type of application. As things currently stand, the information would be similar for different application types.
- It may be helpful to break out certain information, for example information for technical providers and registry operators if there is a RSP program.
- Should it be step-based depending on the type of application?
- No additional comments.

From the chat:
Ashley Roberts: I'm happy with the AGB as the correct methodology. There may be a case for small changes based on individual implementation changes, but in general the AGB does the job.
Vanda Scartezini: agree with jeff. not by the kind of application.

3.     Communications & Systems

a. Systems:
- Review of recommendations from the Implementation Review on Systems (8.1.a and 8.1.b).
- Discussion and findings to date indicate a need for: 1. Improvements to security and stability 2. Ability to use non-ASCII 3. Systems should be capable of sending automated invoices.
- Applicants and registries don't "own" correspondence because it is held in ICANN's portals. Security concerns - risk of data loss. There is also a risk associated with ownership of the correspondence if there is a dispute or legal action.
- Clarification regarding invoices - the requirement would be for making invoices available, not about the specific system.

From the chat:
Jeff Neuman: Part of the problem was that ICANN believed it had to develop cusomized systems at the beignning as opposed to looking at what was out there.  Rather than cusomizations, ICANN should look now at what is out there and not wait until the next round starts
Jeff Neuman: On beta testing, this is something that we did propose for the last round, but ICANN was afraid that giving some of us access for beta testing purposes would be some kind of advantage in the application process
Jeff Neuman: I didnt agree, but that was their view
Trang Nguyen: Is the requirement for the system to be able to generate invoices, or to just send? invoices might need to be generated in a different system than the application system.
Christa Taylor: Trang - idea is to be able to generate and send an invoice if they need it for their own internal purposes for payment systems
Jon Nevett: I am sure that we discussed this before, but systems need to be secure -- the data breach -- where highly confidential information was accessed -- was very problematic for many applicants
Ashley Roberts: A possible solution to the issue I raised could be to have the systems automatically email a copy of any new added correspondence to applicants so that they have an email copy as well as in the portal.
Alan Greenberg: Issue is not, I presume, whether invoice is delivered through portal, but that it can be requested.

b. Review of recommendations in the Program Implementation Review regarding Communications (8.4.a and 8.4.b)
- Discussions and findings to date indicate need for: 1. the knowledge base to be made more timely and searchable 2. better communication of applicant advisories. consolidation of program information into a single site 3. Leverage GSE team to promote awareness about the new gTLD program 4. metrics to understand level of success.
- There was lots of discussion of the communication plan in the Implementation Review, but little discussion of timing of communications period, budget of communications period, languages, etc.
- This topic is connected to customer service, and we should probably spend some time on that. There was a phone line before the application period started, but that was eliminated during the application period. Email was much slower.
- Recommend real-time customer support. if phone is not possible, maybe a chat function could be implemented.
- ICANN doesn't send you communication, it sends you a note that there is an update in the portal. It would be helpful if you could get messages through email rather than having to log into the portal to get messages.
- The policy process was still going on for some topics (for example RPMs) while the New gTLD Program was being implemented. There was a strict prohibition on ICANN staff talking to applicants, but they could talk to other community members in policy discussions, which seems unfair.

From the chat:
Phil Buckingham: should not invoicing be done through ICANN's accounting system .., which  should  be  totally separate from the application  syatem ,.   The overriding requirement  must be  to absolutely elliminate any attempt (s)  of a breach  of the application  portal  , this time .
Trang Nguyen: For background and context, phone support was provided during the application window for technical issues related to accessing TAS. To ensure equal access to information, ICANN developed knowledge articles when a question is received, and then point to it to respond.
Jeff Neuman: Fear of communicating with applicants led to ICANN not being clear with applicants...this led to I believe an increase in having to issue Clarifying questions
Jeff Neuman: @Trang, but it was impossible to really search the knowledge database and get the answers
Jeff Neuman: On the TAS system, I am not sure why the submission of applications had to only be in ASCII, no links, no diagrams, etc.
Trang Nguyen: Yes, the search capability of the knowledge base had room for improvement.
Jeff Neuman: Lots of complaints about that
Ashley Roberts: Tagging onto Jeff's point, any applicant information should be easy to locate and preferably stored in one place. In the first round information was stored in various locations - the AGB, the knowledge base, FAQs, etc, making it hard to fiind what you were looking for.
Phil Buckingham: + 1  Ashley
Jeff Neuman: And if you had a question,customer support took days to answer because all answers needed to be approved by legal
Jeff Neuman: and other parties
Trang Nguyen: @Jeff, to ensure equal access to information, we had to generalize questions received, draft responses, run the draft responses by subject matter experts to ensure accuracy, post and then answer the question, pointing the applicant to the knowledge article. This takes time and did impact response time. But, if the same question is asked again, response time is within 24 hours for those where existing content exists.
Jeff Neuman: @Trang, the issue is that the questions are never asked the same way....so getting a quick response was rare.  I believe the equal access argument was overplayed.  Equal access would only apply to any NEW information.  Not answering questions about existing systems, processes, etc.
Trang Nguyen: customer service stats: http://archive.icann.org/en/meetings/costarica2012/bitcache/New%20gTLD%20Program%20Update-vid=33377&disposition=attachment&op=download.pdf.[archive.icann.org]<https://urldefense.proofpoint.com/v2/url?u=http-3A__archive.icann.org_en_meetings_costarica2012_bitcache_New-2520gTLD-2520Program-2520Update-2Dvid-3D33377-26disposition-3Dattachment-26op-3Ddownload.pdf.&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=mBQzlSaM6eYCHFBU-v48zs-QSrjHB0aWmHuE4X4drzI&m=qhkZom_I27KWIM9MoDbMQzCuiS65Et0RPdUYGemFIdI&s=qPxYB8zevT_hyAf_CPu8foQIS9k1m_yVeXpzYZ7ZcTA&e=>  Average resolution tme is 1.6 days. 80% responded within 24 hours.

5.     CC2 Questions
Revisions to CC2 questions:
- Cost recovery - the real word should be "break even," the point where total revenue and total expenses are equal.
- Language has been revised on cost floor and ceiling.
- Question on the use of shortage or surplus of funds. On the last call, the group agreed to keep it "out of the weeds" and make recommendations at a high policy level. Request for the group to review the language.
- 1.4.3 - asks about how floor and ceiling amounts should be set.
- 1.4.2 – question for the group - is this question still valid?
- Questions about language related to use of excess funds.
- New language added to 1.4.3 regarding use of surplus for underserved regions.
- 1.5.3 - Is there something specific that we want to address regarding the volume of applications?
- 1.1.11 - regarding funding of an RSP program - do edits properly represent discussion on 14 Feb call?

ACTION ITEM: WT1 leads will circulate request for input on CC2 questions by email.

From the chat:
Jeff Neuman: I think the use of excess funds needs further exploration.  From a policy level, we should just state that the AG should set forth the use of excess funds if any
From the chat:
Jeff Neuman: I believe that IF there is an RSP Program it should be self funded
Jeff Neuman: meaninig that it should be paid for by those participating

6.    AOB
- none.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt1/attachments/20170301/74e268e0/attachment-0001.html>


More information about the Gnso-newgtld-wg-wt1 mailing list