The call for the New gTLD Subsequent Procedures Sub Team – Track 1 - Overall Process/Support/Outreach Issue will take place on Tuesday, 19 December 2017 at 20:00 UTC for 60 minutes.
12:00 PST, 15:00 EST, 20:00 London GMT, 21:00 Paris CET
For other times: https://tinyurl.com/ydcl9nbe
PROPOSED AGENDA
- Welcome & Agenda Overview
- SOIs
- Review of potential recommendations for Systems & Communications
- Review of potential recommendations for Application Queuing
- AOB
BACKGROUND DOCUMENTS
RECORDINGS
Mp3
AC Recording
AC Chat
PARTICIPATION
Attendees
Apologies: Alan Greenberg
Dial outs: Cheryl Langdon-Orr
Notes/ Action Items
1. SOIs: No updates.
2. Review of potential recommendations for Systems & Communications:
Slide 4: Systems:
-- Issue posed to the WG: How can the systems used to support the New gTLD Program, such as TAS, Centralized Zone Data Service, Portal, etc. be made more robst, user friendly, and better integrated?
Slide 5: Systems recommendations
Slide 6: System recommendations -- Consensus items to date
-- ICANN's Program Implementation Review Report has some relevant information on page 168: https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf
-- Can we show that some of the concerns from the first round are being addressed? Can add some language on the improvements that have already been addressed.
-- On the beta testing -- good recommendation -- there was a feeling that if we had done some beta testing ICANN might think that those who did the testing would have an unfair advantage. If we do recommend beta testing we should address that issue.
-- Add another note saying that the system shouldn't add new legal requirements, such as click-through agreements.
-- If there is a new system there will need to be new terms of use that may impose new legal requirements. We can express concern and reflect on what happened previously but it's unrealistic that a new system would not have any legal privileges and obligations.
-- Any legal conditions should be known up front in the AGB. Should be finalized before the process.
-- Shouldn't be the unilateral imposition of new legal terms and conditions -- should be a negotiated process.
From the chat:
Maxim Alzoba (FAITID): last time systems were not very secure - it is possible to add sowrding about separation of info recieved from different logins?
Maxim Alzoba (FAITID): wording
Maxim Alzoba (FAITID): it was large scale issue
Maxim Alzoba (FAITID): As I understand current Portal is going to accept info of Applicants, and not just Registies like now, and it is full of issues, and testing was a failure .. almost nothing was fixed after it
Maxim Alzoba (FAITID): so I am really pessemistic about the improvements done
Donna Austin, Neustar: Jeff, I understand that but there has been improvements/changes that might be positive.
Maxim Alzoba (FAITID): and we participated in the pilot
Maxim Alzoba (FAITID): the engagement without learning
Jeff Neuman: I do not believe the new portal can handle the receipt of application data
Maxim Alzoba (FAITID): was last time (autmn)
Maxim Alzoba (FAITID): even the import of data from the old GDD portal was not done properly
Maxim Alzoba (FAITID): that is why I recommended to add the wording about separation of data
Maxim Alzoba (FAITID): another important item: the system should not add new legal requirements on itself
Jeff Neuman: I agree 100% with Maxim. We are still dealing with this on the new portal where 50% of us have not used it because of the Terms of Use
Rubens Kuhl: "Homogenous terms and conditions between AGB and application system", perhaps ?
Maxim Alzoba (FAITID): legal requrements, which were not written in AGB or policies
Maxim Alzoba (FAITID): I meant these requirements needs to be driven from the multistakeholder process and needs to be set in advance
Maxim Alzoba (FAITID): or required changes to these terms - matter of IRT of something like it
Slide 8: Communications
-- Issue posed to the WG: Examine access to and content within knowledge base as well as communication methods between ICANN and the community.
-- The data in these slides comes from the Program Implementation Review Report as well: https://www.icann.org/en/system/files/files/program-review-29jan16-en.pdf You can see the relevant sections starting on page 199
Slide 9: Customer Service Center (CSC)
-- Around 2200 were on TLD application status.
Slide 10: CSC Annual Volume of Cases
Slide 11: CSC Number of Days to Last Response
Slide 12: CSC Number of Days to Case Closure
Slide 13: CSC Percentage of Cases Resolved by Tier 1
Slide 14: Communication Recommendations
Slide 15: Communications Recommendations -- Consensus Items to Date
Discussion:
-- Slide 15 -- "Program information should be contained within one website" -- Last time everything was spread around and not easy to find.
-- Prioritize the issues that have the biggest impact for most people.
-- Need for an escalation procedure.
-- This is another area where it may help to provide policy guidance on the ability of ICANN to answer questions without treating one applicant more favorably.
From the chat:
Maxim Alzoba (FAITID): prioritization of cases is required - like non-working application system - first grade e.t.c.
Maxim Alzoba (FAITID): in the future system
Maxim Alzoba (FAITID): there were no SLAs - they were created as a result of common interest working group of GDD and Registries/Applicants group
Maxim Alzoba (FAITID): *result of work
Jeff Neuman: I had that issue
Maxim Alzoba (FAITID): there should be an escalation process in place
Maxim Alzoba (FAITID): with clear rules and timelines
Maxim Alzoba (FAITID): notifications to applicants
Maxim Alzoba (FAITID): also when applicants know already open info - it saves time of support team
3. Review of potential recommendations for Application Queuing
Slide 17: Application Queuing
-- Issue posed to this WG: Review whether first come first served guidance remains relevant and if not, whether another mechanism is more appropriate.
Slide 18: Applicant Queuing Recommendations
-- If queuing need support draw/raffle, not Digital Archery.
-- Allow applicants which of their applications to prioritize.
-- No consensus on prioritization.
Slide 19: Applicant Queuing Recommendations -- Consensus Items to Date
-- Not sure asking what the goals were is very helpful. Not sure if the goal was to have IDNs go first.
-- Need to consider what we gain from prioritization of applications. Prioritizaton of IDNs made sense at the time but caused problems and delays.
From the chat:
Steve Chan: Ok, maybe we can formulate that into a fully formed request and then WT1 can help determine if it's something it needs to explore.
Rubens Kuhl: Perhaps WT1 could establish no opposition but no request to prioritze IDNs. That ICANN would have liberty to decide whether the political scenario at that time favors doing IDN prioritization or not.
Maxim Alzoba (FAITID): if some special priorities identified, we should use soemthing like "Weighted Fair Queueing"
Maxim Alzoba (FAITID): https://en.wikipedia.org/wiki/Weighted_fair_queueing
Maxim Alzoba (FAITID): so the prioritized group of application does not block others completely
Maxim Alzoba (FAITID): *applications
Donna Austin, Neustar: rather than IDNs should we give some preference to applications from the global south?
Maxim Alzoba (FAITID): @Donna, I meant something like this - but using the transparent process
Alexander Schubert: Global South will be gamed as tons of applicants use shell companies in tax havens anyways!
Maxim Alzoba (FAITID): maybe , last time lots of offshore companies were from "Europe"
Donna Austin, Neustar: quite possibly Alexander
Maxim Alzoba (FAITID): in terms of regions (for applications)
Rubens Kuhl: Not creating high barriers like high application fees and high recurring yearly fees is what would help Global South without being gamed.
Christa Taylor: Were IDN applicants who were given priority given a choice?
Christa Taylor: yes
Maxim Alzoba (FAITID): @ Rubens, it will be possible to rent out such registries after the process
Alexander Schubert: Low monetary entry barriers will create fun-applications by wannabe registries.
Christa Taylor: So are we against the priortization of applications?
Steve Chan: @Christa, I believe the order was 1) IDNs that opted in 2) standard TLDs that opted in 3) IDNs that did NOT opt in and 4) standard TLDs that did NOT opt in
Maxim Alzoba (FAITID): @Christa, we are not against it, it should be done in transparent manner, using different priorities for approved groups of applications (if any)
Jeff Neuman: No one has presented a compelling case for prioritizing any types of applications. We could ask for feedback on this in the Preliminary report.