Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Info

PROPOSED AGENDA


  1. Agenda review/SOIs
  2. Discussion of Public Comments
    1. Continued: 2.2.2.2: Clarity of Application Process (starting with 2.2.2.2.e.1)
    2. 2.2.3: Applications Assessed in Rounds
  3. AOB

 BACKGROUND DOCUMENTS


For agenda item 2, please find the relevant public comment review document: https://docs.google.com/spreadsheets/d/15zDdzlBwLCz5m2sNXui6N6pporbUq-lDFEwfh4rKi4A/edit?usp=sharing

Info
titleRECORDINGS

Mp3

Adobe Connect Recording

GNSO transcripts are located on the GNSO Calendar

Tip
titlePARTICIPATION

Attendance & AC chat

Apologies: Katrin Ohlmer

Note

Notes/ Action Items


Actions:


ACTION ITEM: Noted confusion about how the predictability framework and standing panel are represented and understood. Develop a graphic to clarify.  Also consider using a different term, such as "Standing Panel".


2.2.2.e.1:

ACTION ITEM: Line 20, #6 Brand Registry Group -- Add to 2.2.4 (obligations and rights for different categories).

ACTION ITEM: Line 21, #7 RySG -- Change to Agreement.


2.2.3: General Comments:

ACTION ITEM: Line 4, #1 ALAC -- Change to showing the first part (applications as rounds) as agreement; ask ALAC to clarify the second part.  Copy #1 to preliminary recommendation 1 (2.2.3.c.1).

ACTION ITEM: Line 5, #2 ALAC -- Put the bullet points into the sections where they apply.

ACTION ITEM: Line 6, #4 ICANN Org -- Ask for clarification on which part of the CCT-RT to which they are referring.


2.2.3.c.1: ACTION ITEM: Line 13, #6 ICANN Org -- Move ICANN Org comment ahead of BRG comment; start with BRG at the next call.


Notes:


1. Updates to Statements of Interest:  Michael Casadevall -- member of the WT5 subteam for NCSG drafting for public comments.


2. Discussion of Public Comments


-- Should let the Sub Groups know if we are changing the informal guideline on the quorum level.  (Quorum is not an official procedure for WG in the GNSO Operating Procedures.)


See: https://docs.google.com/spreadsheets/d/15zDdzlBwLCz5m2sNXui6N6pporbUq-lDFEwfh4rKi4A/edit?usp=sharing


a. Continued: 2.2.2.2: Clarity of Application Process (starting with 2.2.2.2.e.1)


Line 16, #2 ICANN Org -- Agreement (support for the idea that ICANN Org can scale) Concerns (notes the importance of providing adequate time between finalization of the AGB and opening of the application window); refer concerns to full WG.


Line 17, #3 BC -- The BC questions whether ICANN can scale to process, say, 10,000 applications; refer concerns to full WG.


Line 18, #4 RrSG -- Concerns (doubt about ICANN's ability to scale): "At present, it doesn't appear that ICANN is properly structured to efficiently handle a new application round with a larger scale of TLDs."  New Idea (suggestion for ensuring scalability): "Careful design of subsequent program along with a restructuring of ICANN staff appear to be necessary. Ideally, once restructured, the program would remain open all the time."  Refer to full WG.

-- Consider how to convey the concern to ICANN Org as a question.

-- ICANN Org has said that they need a closer to final set of recommendations before they can provide a realistic estimate on their ability to scale.


Line 19, #5 ALAC -- New idea: ICANN Org needs to conduct a study regarding its scalability; refer to full WG.


Line 20, #6 Brand Registry Group -- New Idea (more accurately, feedback on how to ensure scalability); refer to full WG.

--- Really talking about creating a catagory, so applies in 2.2.4 (obligations and rights for different categories).


Line 21, #7 RySG -- New Idea (feedback on ways to improve scalability); refer to full WG.

-- Not really a new idea; if we take some of the changes already recommended by the Intial Report and some of the recommendations in the comment, these would all help with scalability.

-- ACTION: Change to Agreement.

-- This is a short-hand comment and is related to other similar comments on improvements.


Discussion:

-- Comments could be broken down into two things (look at NCSG and BC) -- agreement for the idea but the IRT might not be the correct way to handle it.

-- Should be clear (NCSG comment) that the IRT should not operate outside of the guidelines of the PDP WG.

-- Two types of IRT: 1) GNSO mandated IRT, not related to these comments and is out of scope; 2) IRT that is normally formed as part of the GNSO Operating Procedures -- believe the comments from the NCSG is about the addition of a standing IRT after the launch of the program.

-- If there are overall concerns about IRTs in general (relating to the GNSO Operating Procedures) that is out of scope here.

-- The Initial Report tries to define a moment in time when a new standing panel would be formed.

-- Noted confusion about how the predictability framework and standing panel are represented and understood.  ACTION: Develop a graphic to clarify.

-- What is the relevance to scalability?  Some representatives may not have the manpower available so the sub group constituencies would not be able to keep up on the standing panel.

-- Call it something different: such as "New gTLD Review Standing Panel".

-- Confusion on who constitutes it.


Other Comments:

Line 23, #1 Council of Europe -- Concerns New Idea (suggesting to improve clarity, predictability, and transparency of the application process)

-- Not sure if these are really new.

Line 24, #2 Christopher Wilkinson -- Concerns: There is an underlying assumption in this part of the draft that all applications would be subject to the same guidelines and evaluation processes irrespective of the nature of the proposed TLD. That is very unlikely to be the case because different categories of applications will manifest quite different characteristics.


b. 2.2.3: Applications Assessed in Rounds


General Comments:


Line 4, #1 ALAC -- Concerns: all applications must continue to be batched for assessment; ALAC strongly advocates against the immediate commencement of a permanent FCFS

-- Seems to be agreeing, at least in part, on FCFS.

-- Seems to be a concern about FCFS in rounds.

-- Ask ALAC to clarify.


Line 5, #2 ALAC -- Concerns: The ALAC believes that all applications must continue to be batched for assessment; other concerns.

-- ACTION: Put the bullet points into the sections where they apply.


Line 6, #4 ICANN Org -- Concerns (request for clarification on options presented in part d.)

-- ACTION: Ask for clarification on which part of the CCT-RT to which they are referring.


2.2.3.c.1:

Line 11, #4 RySG -- Agreement: The RySG supports the notion of setting out either a date certain or a set of definitive criteria to determine when the next new gTLD Round commences.; New Idea (suggestion that criteria may need to be volume-based): This may need to be volume based.


Line 13, #6 ICANN Org -- Concerns (feedback on options a and b presented in the recommendation).

-- Not sure that this is a concern.  But assessment tool doesn't always fit the purpose.  Isn't really a concern, but is a proposal/options.

-- ACTION: Move ICANN Org comment ahead of BRG comment; start with BRG at the next call.