You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

 

The next call for the New gTLD Subsequent Procedures Working Group is scheduled to take place on Monday, 25 April 2016 at 16:00 UTC for 90 minutes.

 

09:00 PDT, 12:00 EDT, 17:00 London, 18:00 CEST

for other places see:http://tinyurl.com/hzcb6zb

 

Agenda:

 Below, please find the proposed agenda for the New gTLD Subsequent Procedures WG meeting scheduled for Monday 25 April 2016 at 16:00 UTC.

  1. Review agenda
  2. Roll call/SoIs
  3. Update on CCT-RT/PDP WG Leadership Coordination Call (discussion document under consideration by the CCT-RT attached)
  4. The path forward to Constituency Comment 1
  5. Subject discussion: 4.2.7 Applications Assessed in Rounds (Final Issue Report excerpt attached and available on Wiki here: https://community.icann.org/x/Jz2AAw)
  6. Subject discussion: 4.2.2 Predictability (Time Permitting. Final Issue Report excerpt attached and available on Wiki here: https://community.icann.org/x/HT2AAw)
  7. AOB

Those signed up as Members to this PDP WG should have received meeting information from the GNSO Secretariat. If you did not receive these participation details, please contact the GNSO Secretariat for assistance (gnso-secs@icann.org).


Mp3

Transcript

AC Chat

Attendance 

Apologies: Craig Schwartz, Rudi Vansnick, Susan Payne, Christopher Momanyi, Liz Williams (Will be late), Corinne Cath, Richard Padilla, Paul Mcgrady,

On audio only:


Proposed Next Meeting:

Monday, 2 May 2016 at 2200 UTC

 

Notes/Action Items:

 

1. Update on CCT-RT/PDP WG Leadership Coordination Call (discussion document under consideration by the CCT-RT attached)

 

Action Item: Staff will establish regular coordination meetings between the leadership of the two groups.

 

2. The path forward to Constituency Comment 1

 

Action Item: Start a Drafting Team to frame the questions.  Seeking volunteers.  Volunteers thus far: Christa Taylor, Tom Dale, Katrin Ohlmer, Gangesh Varma, Jay Westerdal, Cecilia Smith, Iliya Bazlyankov, Grace Mutung'u.

 

3. Subject discussion: Should the subsequent procedures be rounds?  Pros and Cons

 

4. . Subject discussion: 4.2.2 Predictability: Pros and Cons

 

5.  Action Item List on Wiki: PDP WG members should review the actions and comment as desired.  Do a quick review and status update at the beginning of each meeting.

 

6.  Timing of calls: Continue to look at the times.


How can we ensure that predictability while balancing changes in the process?

 

Pros

1. predictability offers the chance to improve the communication of the introduction process of new gtlds.

2. Legal and application processes are still being worked out and argued. So it is nice to have predictability by having those issued worked out ahead of time.

3. Develop adaptations to policy based on a cross-community effort from the start. We have learned a lot since the last AGB, and work in silos is slowly being superseded by cross-community work.

4. Another reason for unpredictability was GAC advice and the NGPC response.

5. There were a lot of entities that applied that lost a lot of money due to unpredictability.

6. Publish "perfect applications" for new applicants to read and give better guidelines for each answer/requirement.

7. Lack of predictability causes applicants to loose faith+trust in process

 

Cons

1.  Too much predictability may affect flexibility.

 

Standards to be expected of predictabilty

 

Pros

1. (Include here or under predictability?)Develop adaptations to policy based on a cross-community effort from the start. We have learned a lot since the last AGB, and work in silos is slowly being superseded by cross-community work.

2. A definitive list of names banned should be shown to applicates ahead of applying. Such as .home, .corp, etc.

3.  Predictability on deadlines both from applicant and ICANN such as response times for application review, negotiation process, etc

 

Degree to which guidebook is final and should be stuck to

 

Mitigating Factors

 

Pros

1. I suggest ICANN Board analyses and makes decisions on GACs input to final AGB principles AND agree with GAC not to change rules for applicants AFTER applications have been submitted - in this way we would not experience such things as "sensitive strings" , "closed generics" Two letter release applications etc etc....

2. As mitigation, we might have approval - with the same mechanism already in place in registyr agreements - for changes to the process that are not security/stability-related.

 



  • No labels