[Gnso-newgtld-wg] Actions/Discussion Notes: New gTLD Subsequent Procedures PDP WG 19 December

Julie Hedlund julie.hedlund at icann.org
Mon Dec 19 22:56:36 UTC 2016


Dear WG Members,

 

Please see below the action items and discussion notes captured by staff from the meeting on 19 December.  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 are provided separately and are posted on the wiki at: https://community.icann.org/display/NGSPP/1.+WG+Meetings.

 

Best regards,

Julie

 

Julie Hedlund, Policy Director

 

Actions/Discussion Notes: New gTLD Subsequent Procedures PDP WG Meeting, 19 December

 

1. Work Track Brief Updates

 

Work Track 1 – Sara Bockey and Christa Taylor: Met on 12 December.  Discussed applicant support, application process and cost, and application submission period and queuing. No further meetings through the end of December.

Work Track 2 -- Phil Buckingham: We are considering changing the time of the call in the New Year - still every other Thursday . 2   Our first call in the new year willl be on the COI / LOC issues .  Any applicant with prior experiences/ problems re: Round 1  on this Q50  - feedback would be much appreciated  - 3  WT2 received a really excellent email from Kurt Pritz re categories / registry agreement . Your feedback / responses on this would be much appreciated 

Work Track 3 -- Karen Day and Robin Gross: Meeting tomorrow.  Ensure that WT members review the materials for tomorrow's discussion on Legal Rights Objections is on the wiki at : https://community.icann.org/display/NGSPP/4.4.3+Objections

Work Track 4 -- Ruben's Kuhl: Discussions from Hyderabad.  (Work Track) Consensus all ongoing on doing technical capability after the process.  Also discussing financial.  We have a Work Track call on 22 December, but facing competition from Christmas and Santa Claus, so any objection to canceling?  [No objections were received and the call cancellation notice was send out.]

 

2. CC1 Review, cont. (Please see attached as XLS and PDF; iterative versions always captured here - https://community.icann.org/x/3B6OAw.)

 

Actions:  Come back with principles related to the responses to CC1.

 

Discussion Notes:

 

Subject 4: Predictability should be maintained or enhanced without sacrificing flexibility.  In the event changes must be introduced into the new gTLD Application process, the disruptive effect to all parties should be minimized.

 

4.a. Was the round of 2012 sufficiently predictable given external factors, while balancing the need to be flexible?  [Reading from the tool, responses 4aR1-3.]

 

·         There were changes introduced only after we saw what the applications were like.  Will still have some corrections to make along the way.

·         Should have learned a lot, but there are a couple of things we can flag.  GAC advice was a big factor in slowing down two thirds of the applications.

·         A lot of these issues will have been sorted out since we are working on them.  The comment on GAC advice is interesting and we'll need to talk about it in Work Track 3 -- how to deal with GAC advice after the round has started?

·         We need to look at patterns of the kind of advice we got in the processes we build so that (GAC advice) doesn't come out of the blue.  The advice forced us to look at how the TLDs would be used and the semantics.

·         To think about: Let's say in Work Track 2 we finalize the geographic names issue and then the process starts, but someone submits an application and a government (GAC or anyone else) has a problem with that?  Do we have to let it go?  Is there a policy against opening up issues?  What should be the response from ICANN?

·         I don't see how in the Bylaws we can say that GAC can't give advice.

·         A conversation in the RySG group, such as two characters at the second level, if there is GAC advice it should be based in international law.

·         What is the international law?  This is a good question and one that Work Track 2 will need to look at.  To bring it up a level -- what factors should the ICANN community look at as to whether it merits changing a process midway through.

·         The GAC seems to always find a loop hole to object later.  Isn't the Accountability Work Stream 2 working on the role of governments in providing advice? No, Accountability is not addressing this.

·         The GAC is working with us, so presumably we will try to cover these issues, but I don't think there is anything we can do if a government wants to raise an objection.

·         But would ICANN be justified in saying that you originally said it was okay, we can apply this to the next window?

·         Seems natural that in the first round that there were a lot of issues that couldn't be predicted.  There had been GAC principles on new gTLDs back as far as 2007.  This is a process that should be ongoing.

·         GAC is much more active.

·         Think about it in terms of SSAC bringing an objection.  Based on the implications (same with the GAC) it will be a judgment call.

 

4.c. What are the impacts on applicants, users, and related parties from a process that lacks predictability? [Reading from the tool, responses 4cR1-3.]

 
Asking for agreement on: Kurt Pritz: Combining two of my earlier comments: (1) a risk to DNS stability or clear violation of some public interest; (2) a change based on information that was unknowable when the process was developed.
This could be a starting basis for a framework.  Ask for volunteers for a drafting team, or the Chairs or staff?  Get the points down.
 

4.b. Do the changes implemented as a result of the establishment of CCWGs and the adoption of the principles and processes from the Policy and Implementation Working Group suffice to maintain predictability of the application process while at the same time provide for the needed flexibilty to address changes of circumstances. [Reading from the tool, responses 4b.R1-3.]

4.d. Any other issues related to this overarching subject?   [Reading from the tool, responses 4dR1-3.]

 

If this group got to the point later had a consensus on how an implementation review team could work we could do that later.

 

>From the chat:

Rubens Kuhl: A truism: a longer process will be less predictable than a shorter process. So if we make it shorter, it gets more predictable. 

Klaus Stoll: We did learning by doing the first time round and should learn valuable lessons and implement them. Maybe we should create a list of lessons learned.

Kurt Pritz: I think the question for this group might be, "Is there consensus that the application / evaluation  / delegation procedure should be more predictable than the last round and aspire to be predictable and consistent with the Guidebook?"

Jorge Cancio (GAC Switzerland): GAC Advice was (from our point of viwe, of course) something that was also due to the fact that we were engaging in the very first exercise of this kind. And some of the issues raised by the GAC after the start of the round had already been reaised before, but perhaps there had been not a full agreement on how to factor it in.

Kurt Pritz: @ Rubens: The policy could say that there is a pretty high bar for amending the process after launch, i.e., a risk to DNS stability or clear violation of some public interest

Robin Gross: What is ICANN required to do with the GAC advice, especially if it comes late?

Rubens Kuhl: Kurt, I would like to see the same thresholds existing today in the RA... like the board can issue emergency security policies, so they could intervene in the application process in case of risk to DNS stability. But for public interest issues, there would be either (a) something community-wide as a consensus policy or (b) full voted agreement between applicants and ICANN consenst. 

Donna Austin, Neustar: @Robin - i think that's an important question - what does late mean and what's the consequence.

Robin Gross: Especially when GAC was involved in the working groups that created the GNSO policy, and subsequently wants to provide possibly different advice?

Donna Austin, Neustar: @Kavouss - i was using it as an example and providing views of an SG other than the GAC.

Christa Taylor: Depends on the substance of the change..

Kurt Pritz: Two thoughts that are not thought through: (1) If the GAC provides advice, the Board should be required to deal with it on a timely basis, with the timing to be spelt out in the procedure. (2) Maybe post-launch comments can only be based on new information that was not available before the launch  

Klaus Stoll: We should not lose the lessons learned and make a list of Changes and issues,and lessons learned.

Cheryl Langdon-Orr (CLO): the merit is probably The question and the Test 

Robin Gross: We should look at what ICANN's bylaws require for GNSO policy development.  And specifically the process by which the board is to resolve differences between GNSO developed policy and GAC advice.

Annebeth Lange, ccNSO: I think it is in place to remind of the GAC Principles on new gTLDs: ICANN should  avoid  country,  territory  or  place  names,  and  country,  territory  or  regional  language  or  people  descriptions,  unless  in  agreement  with  the  relevant  governments or public authorities.  

Mathieu Weill: No, Accountability WS2 is not addressing this

Donna Austin, Neustar: @Annebeth, those principles existed prior to the 2012 round and were taken into account at that time. On what basis do you propose that agreements made for the 2012 round be re-opened?

Tom Dale (ACIG GAC Secretariat): WS2 sub-group on transparency is looking at ICANN-government relations, but not the role of the GAC.

Annebeth Lange, ccNSO: What I mean, Donna, is that in 2012 round country & territory names based on ISO 3166 were taken out - for this round. If they are taken in again in the next round, these principles should be taken into account, so that a support/non-objection should be necessary to make it a gTLD

Rubens Kuhl: I think the question is whether advice that amounts to the deferrence required to deal with GAC Consensus Advice can occur after date X. GAC can always issue advice, governments can issue them, I can issue advice by writing a letter to the board... 

Annebeth Lange, ccNSO: In my view it does not make sense that a capitol needs support/non-objection, but a country/territory should not need it. This includes 3-letter codes on the ISO-3166 list representing countries. 

Cheryl Langdon-Orr (CLO): we should also recognise that the GAC now is, more proactivly engaged now 

Donna Austin, Neustar: thanks Annebeth

Martin Sutton: It appears all are in agreement that there was lack of predictability in the last round.  Based on this, should we simply list the specific issues that have been raised, check where there has been a change since, and whether the changes have improved predictability? Where no change has occurred against a specific issue, review and consider if a change is needed.  As we channel specifics through the WTs, we should also use this as a checkpoint to see if we have sufficiently improved predictability.

Cheryl Langdon-Orr (CLO): the merits are again the issue yes as Alan said. 

Mathieu Weill: Agree with Alan, ICANN Bylaws are clear on the importance of security, stability and public interest, predictability will never prevail over these factors

Annebeth Lange, ccNSO: And public interest also includes politics.  On the other hand, the more uncertainties we can get rid of before launching, the better. That will, in my view, give us a faster next round than last time.

Steve Coates: To Jeff's point, this is why launch times need to be more predictable.  

Christa Taylor: perhaps categories 

Kurt Pritz: Combining two of my earlier comments: (1) a risk to DNS stability or clear violation of some public interest; (2) a change based on information that was unknowable when the process was developed

Donna Austin, Neustar: Agree with Kurt, particularly on 2). 

Cheryl Langdon-Orr (CLO): yup

Martin Sutton: @Kurt - we could test your formula on the changes that were made during the last application phase.

avri doria: all of the contentful comments seem to end up in the notes.

Kavouss Arasteh 2: Cheryl, what is the meaning of yup in standard communication standard?

Vanda Scartezini: Agree with Kurt too

Christa Taylor: +1

Jorge Cancio (GAC Switzerland): We have to be aware that the role of GAC early warning and GAC consensus advice was part of the AGB of 2012 and therefore part of the rules of the game

Vanda Scartezini: we can put our green to give you a better view

Cheryl Langdon-Orr (CLO): I agree with KuRT

Phil Buckingham: +1 to Kurt 's comment 

Kristina Rosette (Amazon Registry): @Kurt: Is there a reason you didn't include security in #1 or was it presumed?  @Kurt:  To be clear, the "security" in "security and stability"?

Jorge Cancio (GAC Switzerland): what is being asked?

Kurt Pritz: @ Kristine: DNS security, stability, resiliency

Cheryl Langdon-Orr (CLO): I assumed presumed

Jorge Cancio (GAC Switzerland): Politics, and policy are difficult to be reduced to a formula

Phil Buckingham: + 1 CLO  presumed and overriding 

Jorge Cancio (GAC Switzerland): + 1 Mathieu on staff/Board changes

Annebeth Lange, ccNSO: +1

Jorge Cancio (GAC Switzerland): I feel the GAC answer on 4 b) also answers some points made before on the GAC role

Mathieu Weill: Would this test apply to changes introduced by staff into the process? It is my impression that there is an area for larger improvements in predictability 

 

Subject 5: Community engagement in new gTLD application processes

 

5.a Are there circumstances in which the application window should be frozen while unforeseen policy issues are considered and resolved?  If so, should there be a threshold or standard that must be reach before considering freezing an application window?  [Reading from the tool, responses 5aR1-3.]

5.b. If the Board is faced with questions that cannot be addressed by the policy recommendations they were sent, must the Board bring the issue back to the GNSO and PDP process (e.g. the GNSO Expedited PDP or GNSO Guidance Process)? [Reading from the tool, responses 5b.R1-3.]

5.c. Should a standard be established to discriminate between issues that must be resolved during an open application window and those that can be postponed until a subsequent application window? [Reading from the tool, responses 5cR1-3.]

5d. Any other issues related to this overarching subject? [Reading from the tool, responses 5dR1-3.]

 

>From the chat:

Donna Austin, Neustar: Who would make the determination on what is 'severe'

avri doria: and the Board deciding it was so? without the EC objecting.

Donna Austin, Neustar: Some could say we experienced that in 2012 with Names Collision.

avri doria: True, Donna. Except no EC and no coming back to the community.

 

Subject 6. Limiting applications in total and/or per entity during an application window.

 

6a. Should a limit for the total number of applications for an application window and/or from a single entity be established?  If so, what should be the limiting factor (e.g. total applicaitons, total number of strings, etc.) and why? 

6b. If a limit for the total number of applications for an application window and/or from a single entity is established, how would the appropriate amount of applications be set to establish this limit? 

6.c: If a limit for the total number of applications for an application window and/or from a single entity is established, what mechanism(s) could be used to enforce limit(s)?

6.d: How would a limit on the total number of applications for an application window and/or from a single entity impact fees?

6.e: Would limits to the total number of applications for an application window and/or from a single entity be considered anti-competitive?  Please explain.

6.f: Do limits to the total number of applications for an application window and/or from a single entity favor “insiders?

6.g: Any other issues related to this overarching subject:

 

[Reading from the tool, responses to each question.]

 

Seems that people speaking and commenting in the chat are not in favor of limits, but to make sure the process is not dominated by insiders.

 

>From the chat:

Vanda Scartezini: i beleive limit is not realistic at all. I am for free competition and oepen opportunity to all who wants to apply

Annebeth Lange, ccNSO: But is it fair, Vanda, that those companies with a lot of money can affort to apply for many, but "newcomers" have problems doing that? Wasn't one of the reasons behind opening up that there should be fair competition?

Vanda Scartezini: this time, less money had a problem to apply more for lack of timely information than really lack of money at least in our region

Kurt Pritz: @ Annebeth: I think interfering with markets in a way to abet less financial applicants is not workable; I think your concern is best address by the Applicant Support question

Rubens Kuhl: I think the competitive angle is per-string, so those who apply for many are diluting their strength (low or high) among many strings and making it actually easier for the focused applicants. .club and .cloud registries are examples of that from the 2012-round. 

Jorge Cancio (GAC Switzerland): The key is again to have an effective outreach, that interested stakeholders have a fair say v-a-v strings that may interest them,  that community based applications work, and that the applicant support program really works

Annebeth Lange, ccNSO: I think this is especially important for new markets, like Africa

Cheryl Langdon-Orr (CLO): agree Jorge 

Annebeth Lange, ccNSO: Agree, Jorge

Cheryl Langdon-Orr (CLO): yes Annebeth 

Vanda Scartezini: agree with Rubens. 

 

3. Any other business: 

 

Look for a poll on the 0300 UTC Monday meeting falling on Sunday evening.  Substitute for 0300 UTC Tuesday (fall on Monday evening).

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20161219/bde3a8df/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CC1 Review Tool SubPro PDP WG 5 Dec 2016.pdf
Type: application/pdf
Size: 218853 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20161219/bde3a8df/CC1ReviewToolSubProPDPWG5Dec2016-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: CC1 Review Tool SubPro PDP WG 5 Dec 2016(1).xlsx
Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
Size: 91403 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg/attachments/20161219/bde3a8df/CC1ReviewToolSubProPDPWG5Dec20161-0001.xlsx>
-------------- 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/20161219/bde3a8df/smime-0001.p7s>


More information about the Gnso-newgtld-wg mailing list