[Gnso-newgtld-wg] Actions/Discussion Notes: New gTLD Subsequent Procedures PDP WG 12 February 2018

[Julie Hedlund]

Dear WG Members,

 

Please see below the action items and discussion notes captured by staff from the meeting on 12 February 2018. These high-level notes are designed to help PDP WG members navigate through the content of the call and are not meant as a substitute for the transcript or recording.  The MP3, transcript, and chat room notes will be provided separately.

 

For reference see the following link to the Applications Submission Periods: https://docs.google.com/document/d/1u3UzvZIXzjnxtklgPmqArqff6dyckUbyuzWyLz7dKOw/edit?usp=sharing. 

 

Best regards,

Julie

 

Julie Hedlund, Policy Director

 

 

Actions/Discussion Notes

 

Action Item:

 

Application Submission Period: WG members should contribute suggestions for potential criteria to put into our initial report that we could use to say we are ready to go on to the next round and to answer who will make that determination.  See: https://docs.google.com/document/d/1u3UzvZIXzjnxtklgPmqArqff6dyckUbyuzWyLz7dKOw/edit?usp=sharing.

 

Notes:

 

1.  SOI Updates: No updates

2.  Work Track Updates:

Work Track 3:

-- Next meeting 13 February at 1500 UTC.  Discussing Applicant Freedom of Expression, Accountability, String similarity.

Work Track 4:

-- Met on 12 February at 1500 UTC.  Topic was Financial Evaluation.  Converging on a possible model.  Next call is 01 March at 2000 UTC.

Work Track 1:

-- Next call is 20 February on 2000 UTC.

-- Still working on topics.  Expect that it will be RSP Program and another topic.

Work Track 2: Next call is 22 February at 1500 UTC.

 

Work Track 5:

-- Next call is 21 February at 2000 UTC.  Continuing from the last call on the different geographic terms in the AGB; looking at each individually to assess the positive and negative attributes.

3. Overarching Issue: Applications Submission Periods

See: https://docs.google.com/document/d/1u3UzvZIXzjnxtklgPmqArqff6dyckUbyuzWyLz7dKOw/edit

 

General Discussion:

-- Some have said it should be first come, first served, and some have suggested rounds.  We don't have consensus.  The next application window is likely to be a round format.

-- If we can come to a decision that we will always do rounds that would be fine, but don't think we have to put in our recommendations the definitive ongoing process.

-- Both models work but we need to figure out what is best before moving forward.  Someone applies for .jeff, but the application window would still be open and then others could apply and then go to a contention set.  Open application process. 

-- Agree that we need to consider the open model as opposed to the "black box plus reveal" model from the first round.  Open process might create more contention sets but avoid some who might not have applied.

-- If we do have something without rounds we have to think about how all the objections, permissions, and rights protections would work.  Current procedures assume a pool that is being reviewed.

-- The idea of an open model where others could apply could address some concerns, but raises significant concerns about the process being used to blackmail someone into paying them off.

-- Issues with window open to everyone simultaneously (as in 2012); too many applications all at once.  Consider mini-rounds, which are pre-defined by grouping the criteria and objectives of certain numbers of well-identified groups of TLS, such as brands, geographicals, etc.  Evaluation process would be quite different for such groups.

-- Anyone disagree with the notion that the next opportunity for applications can be submitted that it should be a round?

>From the chat:

avri doria: Alan, I thought there was a desire to prevent a  future stall point, wouldn't another process risk becoming a future stall point?

Alan Greenberg: Sorry, didn't mean to steal your thunder. I did wantto establish that MAYBE, we do not need full clarity for the long term in our recommendations.

Maxim Alzoba (FAITID): if an application blocks other applications with the same string - then it will lead to private auction where the first auctions off the seat

Alan Greenberg: @Avri, yes, perhaps, but we are living in a different world that we were in in 2007 when this process was first (at a policy level) started. We are seeing relatively stagnant domain sales, and that has to ultimately enter into our consideration.

Phil Buckingham:  i think it is very  important that ICANN does some kind of outreach to try  establish the level of demand / interest for a R2 .- say in 2020 ,  - particalarly amongst global .brands 

Kristina Rosette (Amazon Registry): Rubens, are you advocating for one model over another because of the secrecy consideration or were you just flagging the secrecy consideration as a factor to be taken into account?

Alan Greenberg: Id it is known that .jeff is applied for and others could do so as well, that could get REALLY ugly - someone with deep pocketes sees an opportunity that no one had thought of and out-bids them.

Rubens Kuhl: Kristina, I don't have a preference in either model, so far. I think we need to establish which one we move forward and tune the process to that definition. 

Kristina Rosette (Amazon Registry): @Rubens:  Thanks for clarifying.

Christopher Niemi: @Phil +1

Anne Aikman-Scalese (IPC): COMMENT:  I don't think it's possible to deal effectively with contention sets unless there is a "window" of some sort.  We can't have a situation where the applicant who hits the submission button 2 minutes before the next applicant for the same string gets the string.   It will cause bedlam.  COMMENT

Maxim Alzoba (FAITID): what benefit brings to the community identification of the fastest applicants?

Annebeth Lange, co-lead WT5: As Greg said, it would be more difficult with permissions like support/non-objection and objections through  first come, first serve applications 

Rubens Kuhl: FCFS only works in absence of pent-up demand, so it wouldn't be a question of minutes between applications. 

Anne Aikman-Scalese (IPC): We are also going to have to deal with the high likelihood that the GAC will recommend a priority round for Community applications.   (Let's not stick our heads in the ground on this.)

Annebeth Lange, co-lead WT5: Anne +1

Phil Buckingham: + CW  I would envisage a round for .brands ( a closed model ) which could be run in parallel with  (say) a round for geos ( an open model) . Their application / evaluation criteria / points scoring would be totally different 

Rubens Kuhl: A community-only round will be rather unfortunate, since it will likely foster gaming that would hurt the image of community-based TLDs, which can exist for very good reasons, but would be used to get that TLDs. 

Cheryl Langdon-Orr (CLO - PDP Co-Chair): Next oportunity as a "round"  

Cheryl Langdon-Orr (CLO - PDP Co-Chair): let us know if you object to that assumption

Christopher Wilkinson: Shpould be Rounds

Maxim Alzoba (FAITID): +1 Rubens, in this round only reach/well supported communities communities won

Rubens Kuhl: BTW, 2004 was a community-only round, we called it sponsored TLDs at the time. 

Annebeth Lange, co-lead WT5: Should be rounds

Cheryl Langdon-Orr (CLO - PDP Co-Chair): No  of  "A Round"  not yet detailed in specs

Rubens Kuhl: There should be a *a* round, moving to FCFS in the long run. 

Anne Aikman-Scalese (IPC): FCFS does not work when there is pent-up demand.

Cheryl Langdon-Orr (CLO - PDP Co-Chair): That would be a "next step" discussion of course Rubens 

 

Requirements Considered (page 2 of the Google doc):

-- Agreed that the 2008 GNSO recommendation should remain in place -- that there should be an ongoing mechanism for the introduction of additional new gTLDs.

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

-- There must not be indefinite gaps between the processing of applications to the acceptance of additional new gTLD applications.

-- The choice of application submission methodology 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 impact the stability, security, resilience and quality of the new gTLD program.

-- The application submission mechanism(s) should not negatively impact operational effectiveness and the fiscal feasibility of ICANN or the new gTLD program.

Discussion:

-- Concern that an excessive rapidity of releasing new gTLD strings could be a security and stability issue.  The PDP WG has received responses from ICANN Org, RSSAC, and SSAC on the issue of the rate of delegation into the root.

ACTION: Second to last bullet -- rewrite it to include ICANN (as in the last bullet).  Not sure why ICANN was left out of the bullet. Change to "Of ICANN or the new gTLD program."

-- Not sure why bullet 1 is limited to the clarity and predictability of how and when applications can be applied for in the future -- why it doesn't include other aspects is because what we are considering is just the mechanism for accepting applications.  Need it around every aspect of the program, does that impact the mechanism for accepting applications?  Not sure that point fits into this part of the process.  Predictability and Clarity of the Application Process are actually their very own topics, fwiw.

-- To help address Kristina's point, could we add "evaluation" to the 3rd bullet, with objections?

>From the Chat:

Cheryl Langdon-Orr (CLO - PDP Co-Chair): That there must be clarity and predictability in the proposed path

Cheryl Langdon-Orr (CLO - PDP Co-Chair): The question of "Gaps"  not to be "indeffinate"  but defined ( asper predictability requiremtnt) 

Hadia Elminiawi: +1 cheryl 

Kristina Rosette (Amazon Registry): Clarifying question, Jeff:  Why does the last bullet refer to ICANN or the new gTLD program, but the second-to-last one only refers to the new gTLD program?  And, fwiw, how does one measure the stability, security and resilience of a program?

Emily Barabas: Top of page 3

Maxim Alzoba (FAITID): so far no scientific proof of the provided numbers was presented (5% growth and 1000 per year are both seems to be "looks safe")

avri doria: There may be an iconsideration with the creation of the impementation of the system as Org may not know whether they are building a use once round mechasism or  building something that will be used often the same way or are building something that can evolve into FCFS implementation.

Kristina Rosette (Amazon Registry): Agree that it doesn't relate to rounds vs. non-rounds.  Maybe drop a placeholder footnote to remind us that we need to do internal cross referencing later.  

Cheryl Langdon-Orr (CLO - PDP Co-Chair): Yes but the cosequences  will effect intervals  between any future offering of submission periods

avri doria: a consideration - sorry

Cheryl Langdon-Orr (CLO - PDP Co-Chair): Indeed Avri, good point

Martin Sutton: To help address Kristina's point, could we add "evaluation" to the 3rd bullet, with objections?

 

Solutions Considered (page 3 of the Google doc):

[See options in the Google doc]

Discussion:

-- Hold mini-rounds that are restricted to different types -- underserved regions, brands, geographicals, etc.  Could be covered in options 2 or 3 depending on the rules.

-- Predictable doesn't necessarily mean a set time period, but according to certain criteria -- such as 1 year after an identified dependency.

-- Need to capture the above-mentioned definition of predictability.

-- Define predictability in terms of either timing and/or occurrence of some sort of dependency or event.

-- Flag: thinking about the different mechanisms and what might serve as a trigger and the timing issue.

-- Could be a derivative of option 1 -- having staff decide the starting point for the next round?

-- If we say that ICANN has to not open a round for a certain amount of time that could be problematic, or forcing them to open a round when they aren't ready could cause problems.

-- Could that work with any of the options as long as there is some sort of an escape valve?

-- Is there another alternative, which would be some form of batching?

-- Not sure that anyone agreed that we could limit the number of applications overall.

-- Another issue is ICANN's capacity to process applications.  But can't make policy based on what ICANN can or cannot handle.

-- Instead of setting a defined time range, could set criteria that would have to be met before a round starts, but haven't come to consensus on any recommendation.

-- Criteria make more sense than a hard and fast timeframe.

-- Who decides that the criteria have been met?  It could be a combination of alternative criteria, but could be others.  Doesn't necessarily have to be a time limit or single criteria. 

-- Great to get a list of potential criteria to put into our initial report that we could use to say we are ready to go on to the next round and to answer who will make that determination.

>From the chat:

Paul McGrady: @Jeff, could we just leave it to Staff discretion as to when the next round starts?  Do we have to dictate it?

Paul McGrady: The next, next round, I mean.

Rubens Kuhl: Paul, I believe the main concern is the timing between procedures. The start of the next one is indeed something we can leave to discretion. 

Christa Taylor: Predictability is difficult as we have the yearly delegation rates and projected demand which would extend beyond years.  The number of applications will impact the time required which then impacts predictability.

Maxim Alzoba (FAITID): a round + typical cycle of life in ICANN period (at least a year)

Rubens Kuhl: Christa, the delegation rates are, for now, just artificial scarcity, until anything bad really happens, of which there is no sign that something would crash. 

Maxim Alzoba (FAITID): costant period available only in absence of issues (have we seen a round without issues so far?)

Cheryl Langdon-Orr (CLO - PDP Co-Chair): Or a next round leading to a perminant or endless batch opportunities to follow @Greg?

Greg Shatan: Semi-parallel processing?

Cheryl Langdon-Orr (CLO - PDP Co-Chair): If it can be properly resourced  - Why not?

Emily Barabas: @Jeff, confirmed -- none of the CC1 comments suggested specific limits (see Subject 6 in the CC2 summary document here https://community.icann.org/x/3B6OAw )

avri doria: who decides that the crteria have been met?

Cheryl Langdon-Orr (CLO - PDP Co-Chair): I am personally very confortable with the "criteria' approach @Paul

Maxim Alzoba (FAITID): 80%?

Trang Nguyen: If we look at the 2012 round, we released 100 IE results per week. There's probably potential to push that number higher. It's difficult to say without knowing what changes will be made to the next round.

Maxim Alzoba (FAITID): 80% of issues caused by 20% of applications (one of theories)

Maxim Alzoba (FAITID): and vice versa

Rubens Kuhl: Trang, was technical evaluation, registry services evaluation or financial evaluation the slower path in 2012 ? 

Martin Sutton: 50% passed evaluation or 35% contracts agreed or 25% are delegated

Paul McGrady: @Martin - yes!  Those are the sorts of fact based triggers we should be thinking about.

Susan Payne 2: % have signed contract; or completed PDT.  But a criterion tied to IE has the benefit that there would be a steady flow of work for evaluators

Phil Buckingham: @ Trang - if ICANN has twice the number  of  evaluators then they could  / should be able to push out 200 IE per week .?  

Trang Nguyen: They all occurred in parallel. No one of those 3 evaluations was more complicated or took longer than others.

Trang Nguyen: Not necessarily. The evaluation firms that we engaged had the ability to scale.

4.  Planning for ICANN61; Two sessions in ICANN61: 1) SubPro PDP WG on Saturday, 10 March for Work Tracks 1-4 at 12:15-15:00; 2) Work Track 5 on Wednesday 14 March at 8:30 to 10:15.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20180212/6cb0481e/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/20180212/6cb0481e/smime-0001.p7s>