[Gnso-newgtld-wg] Notes and Action Items - New gTLD Subsequent Procedures PDP WG - 12 June 2017

[Julie Hedlund]

Dear Working Group members,

 

Please find below the action items and discussion notes from today’s meeting.  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 chat room or the recording. The meeting recording and transcripts will soon be available at: https://community.icann.org/x/CtTRAw.

 

Kind regards,

Julie

Julie Hedlund, Policy Director

 

 

1. Work Track Updates

 

Work Track 1:  Christa Taylor 

-- Call on 13 June at 0300 UTC. 

-- Topic Review and Progress (Systems, Communications, Application Fees)

-- CC2 Application Fees

 

Work Track 2: Michael Flemming

-- Meeting this week 15 June 2100 UTC.  Last meeting before Johannesburg.

-- Go back to vertical integration.  Asked ICANN for data to distinguish what type of complaints have been report.  Analyze those data as a group.

 

Work Track 3: Karen Day

-- Next meeting 19 June 1500 UTC.

-- Continuing discussion on accountability mechanisms: PICDRP; also selection of subject matter for Johannesburg for 27 June.

-- Why is Work Track 3 discussing accountability mechanisms?  Answer: It was called out in the charter.  The RPM PDP is looking at the policy around the accountability mechanism.  We are tasked with looking at processes for accountability mechanisms.

-- The only way to challenge the decisions made in the new gTLD process was via the accountability mechanism -- looking at whether those are sufficient or whether we need additional appeals mechanisms.

 

Work Track 4: Cheryl Langdon-Orr

-- Continuing discussions on 20 June at 0300 UTC.

-- Will continue more on name collision work.

-- Look at where we have come so far on our topics.

 

2. Community Comment 2

 

-- Staff is wrapping up the summary and analysis document that must be published with the public comment proceeding.  High-level analysis since the more detailed analysis will be done by the PDP WG.

-- Organized comments and sorted them so that they are referenced to the appropriate category and sub-category.

-- Full comments on the public comment page are authoritative.

-- Take the Work Track work to see if the comments help to make a recommendation.

-- All of the work tracks will be going through the comments.

 

3. ICANN59 Planning

 

-- Two Geonames sessions at ICANN59 -- Geographic names at the top level: 27 for 90 minutes and 29 June for 2 90-minute sessions. 

 

* Monday 26 June 2017* 09:00 – 09:30: Update to the GNSO, in Committee 4

* Tuesday 27 June 2017* 08:30 – 12:00: Working Group F2F meeting, in Committee 4*; 17:00 – 18:30: Cross Community Discussion – Geographic Names at the Top-Level Session I in Bill Gallagher room

* Thursday 29 June 2017* 15:15 – 18:30: Cross Community Discussion – Geographic Names at the Top-Level Session II in Ballroom 1

 

Full WG meeting on Tuesday, 27 June -- 0830-1200 Local.

-- There are conflicts such as with the Registry and Registrar WG joint sessions.

-- Format: Each work track leader has been tasked with introducing several topics on which they would like feedback outside of the WG members.  Example: Work Track 1 -- difficult to get a wide range of thoughts on applicant support.  Perhaps putting it out to the larger group might be beneficial.

 

Geographic Names Sessions:

-- Caveat that we are still negotiating a contract with CBI; group that specializes in facilitating discussions between civil society, governments, businesses, such as United Nations.

-- Skilled at dealing with facilitating controversial topics.

-- Planning to studying materials and talking to others on geonames.

-- Avri and Jeff have reviewed proposals and developing a matrix.  Preparing some background documents.  Drill down on some of the proposals and doing a "straw bunny".  Just a discussion starter.

-- Go over that during the full WG meeting on Tuesday, 27 June.

-- WG members can take those proposals back to their various groups.

 

4. Drafting Team Update -- Applications Assessed in Rounds

 

See: https://docs.google.com/document/d/1u3UzvZIXzjnxtklgPmqArqff6dyckUbyuzWyLz7dKOw/edit?usp=sharing

-- Had hoped to have a smaller discussion group, but can make more progress with the full WG discussion.

 

Problem Statement:

-- There is concern that introducing new gTLDs through a series of application rounds, separated by a series of reviews and revisions to policies and implementation, have a number of negative impacts, such as impacting demand and decision-making, introducing substantial delays if reviews between rounds are needed, and causing latency to market.

 

Requirements Considered:

-- Clarify and predictability about how and when applications can be applied for in the future.

-- There must not be undefined gaps between the acceptance of applications.

The application submission mechanism(s) must address the potential impact on other areas of the program (e.g., objections, string contention, etc.)

-- The application submission mechanism(s) should not negatively impacts the stability and quality of the program.

-- The application submission mechanism(s) should not substantially impact operational effectiveness and the fiscal feasibility of the program.

 

Solutions Being Considered:

-- Hybrid: A fixed set of rounds or a single additional round (or perhaps defined by certain criteria to determine the 'scale of demand') followed by some form of steady state.

-- Pros and Cons: Trying to get some thinking on the solutions.

 

Discussion:

-- There have been statements in the Community Comment 2 that we will need a application window to take the pressure off.  Concerned with "must" and "should" -- are their conflicts with these requirements?  They cannot all coincide.

-- If you get a huge number of applications would that affect the defined time periods?  Do we put in caveats if it is above a certain number?

-- Perhaps have an assumption section in the document.  What should be some of those assumption?

-- If there is a flood of applications it would be hard to predict the work load for ICANN staff.  If they are not string contention sets could you process them by date and time received?  That would give incentive to file early.  Not a safe assumption that there are no more high-risk strings so put in a process to test for string contention/collision.

-- Continue conversation on name collision in Work Track 4.

-- Other assumptions?  Consider them and update the Google Doc.

-- We will need to put assumptions.  Need to look at contingencies based on what happens, or be less specific.

-- Can we accept applications but not process them until you have the capacity?  You would add uncertainty as to when there will be a process.

-- Needs to be a service expection when one puts in an application.

-- On the idea of starting a round and then going into first-come, first served that could be gameable.

-- Assume that there must be predictability in the process for applications.

-- It would help to get more information from ICANN based on a small number of assumptions as to what they would expect.

-- Also interesting if anyone has done market analysis as to the predicted demand.

-- In terms of ICANN trying to determine its capacity: This WG is debating what changes it wants to make to the program.  A requirement for an inquiry on workload would be a set of assumptions -- different contract, categories of applications, etc. that could change the answer substantially.  There probably is a point where simply staffing up doesn't meet the volume.

-- There are a lot of contingencies in play before we could ask ICANN.

-- With regard to capacity: The biggest constraint is the SSAC requirement to only process 1000 applications a year.  Urge us to ask ICANN to do a real technical analysis can the root zone safely accommodate in a year.

-- When we could have an open ongoing window: Could only happen the day after a day after an application window closes.  The question for the WG: If we are ready at the end of this next round to open one the next day we should do that, or wait until the following window.

-- So instead of a function of time, it would be a function of time and capacity?

-- Demand could be driven by the cost of the application.

-- What about the possibility of creating windows where application fees get lower if you wait.

-- Assuming the steady state was a completely open and continuous process and not doing application windows.

-- Once you deal with the pent-up demand you move to open and continuous.

 

>From the chat:

Alan Greenberg: We would not need 100,000 to swamp us....

Phil Buckingham: Yes, we set limits 

Hadia Elminiawi: how do you determine the number of applications above which there would be a problem?

Anne Aikman-Scalese (IPC): In order of submission by date and time EXCEPT where there are string contention sets - BUT  ONLY AFTER TESTING TO MAKE SURE STRING IS NOT HIGH RISK FOR NAME COLLISION.

Alan Greenberg: If we assume less than or equal to 1,000, would not apply if much greater.

Greg Shatan: 100,000 applications would net $18.5 billion in application fees.  That could solve a lot of problems.  But I can't imagine any market analysis that reasonably foresees anything like that.

vanda scartezini: yes , good suggestion Donna. 

Donna Austin, Neustar: @Greg, I expect that amount of money would likely create many more problems than it solves.

Rubens Kuhl: Applications could receive objections, GAC advice... name collision high risk is just one of the possibilities. 

Alan Greenberg: Not ordering within window was, at the time, a feature and not a bug.

vanda scartezini: yes. flood of application is not positive 

Christa Taylor: Why can't we determine our capacity limits ahead of time?  (ballpark)

Donna Austin, Neustar: @Christa, because then you get into the first come first serve debate. 

Christa Taylor: Ask of ICANN

Anne Aikman-Scalese (IPC): @Rubens - no reason to even obtain GAC advice if string is HIGH RISK for name collision - it should be a screening mechanism as to eligibility to operate as gTLD - see SSAC comments on CC2

Alan Greenberg: Again, we probably need assumptions. We may need a bifurcated plan with one path forward if there are <N applications and another if much more.  

Cheryl Langdon-Orr (CLO): agree Alan

Rubens Kuhl: @Anne, GAC Advice is coming for every string listed on reveal day, no matter it failing one evaluation criteria further down the road... 

Anne Aikman-Scalese (IPC): @Rubens - you don't have to waste the GAC's time if a string is really not eligible to operate as a TLD based on security and stability assessments.

Christa Taylor: +1 Alan

Phil Buckingham: Disagree Alan, we double / treble the number of evaluators ! 

Rubens Kuhl: @Anne, we can suggest GAC to wait, but they will do it or not based on their working process... and I believe they will go thru the list of strings no matter what. 

Karen Day (SAS): No predicibility for those that file in next batch

Alan Greenberg: If we have no predictability on processing, it becomes a lot easier!  ;-)

Sara Bockey: I will need to drop at the top of the hour.  many thanks to all for the good discussion

Donna Austin, Neustar: Agree with Avri

Alan Greenberg: Maybe you don't have to pay the bulk of the fee until your processing slot comes up.

Phil Buckingham: Agree Avri . Need an SLA , time processing limit 

Anne Aikman-Scalese (IPC): @Rubens - Assesssment for HIGH RISK strings that should not be eligible shoudl be first and fast.    CC2 comment by SSAC was SSAC 94.  See this recommendation: The SSAC recommends that ICANN consider the following in the context of the newgTLD program.• Prohibit the delegation of certain TLD strings. RFC 2606, “Reserved Top Level Domain Names,” currentlyprohibits a list of strings, including test, example, invalid, and localhost.4 ICANN should coordinate with thecommunity to identify a more complete set of principles than the amount of traffic observed at the root asinvalid queries as the basis for prohibiting the delegation of additional strings to those already identified inRFC 2606.• Alert the applicant during the string evaluation process about the pre-existence of invalid TLD queries to theapplicant’s string. ICANN should coordinate with the community to identify a threshold of traffic observed atthe root as the basis for such notification.

Greg Shatan: We might want to know what caused the most "friction" in the process the first time around, and whether solutions were found.

Donna Austin, Neustar: There is a lot of 'chicken'n'egg' in what we're doing.

Cheryl Langdon-Orr (CLO): indeed Donna 

Jeff Neuman: @Donna - Was thinking that same thing

Jeff Neuman: WT4 has asked the SSAC to reconsider their recommendations on the number of entries into the zone per year based on the study of the root that concluded no iseeus

avri doria: i appreicate Kurt's point on the only time therre isn't pent up demand and think we should give that timing aspect consideration in any solution.

Alexander Schubert: It doesn't make any sense to open the ongoing process after the next window: Say we get 4,000 applications - and ICANN can process 2,000 per year - then it will take anyways 2 years before ANY new application could be processed. During these 2 years of course there will be pent up demand!

Alexander Schubert: And pent up demand equals competition! And competition drives innovation and is benefitial for the industry!

Alexander Schubert: Why would we want to "avoid contention"? Competition doesn't happen without contention.

Kurt Pritz: @Alex. it isn't about avoiding contention. it is about when it is feasible to open a continuous application window. 

Donna Austin, Neustar: @Anne, I think its an idea worthy of consideration, but I'd start at a much higher threshold.

Kurt Pritz: the contention would be among the price brackets only

Alexander Schubert: Hi Kurt, "Alex" is fine. I am all for continuous process, but as long as processing time prevents new applications from being processed in the first place: Let's close the next window only once additional applications can be processed. Once we see no contention anymore we can go into continuios mode..

Kurt Pritz: the one lesson from the community round in 2003-4

Kurt Pritz: was that there shouldn't be a community only round

avri doria: let's continue the discussion on the list and in the doc https://docs.google.com/document/d/1u3UzvZIXzjnxtklgPmqArqff6dyckUbyuzWyLz7dKOw/edit#

Anne Aikman-Scalese (IPC): Well get ready to define what qualifies as Community because the GAC will advise priority round for community applications and things won't move forward until that issue is resolved.  We need to resolve it before the Board says "work out your differences please".

Jeff Neuman: Yes, Even if to just document the interdependencies, that is extremely helpful! 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20170612/e6db4c32/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4630 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20170612/e6db4c32/smime-0001.p7s>