The call for the New gTLD Subsequent Procedures Sub Group C will take place on Thursday, 08 November 2018 at 15:00 UTC for 60 minutes.

07:00 PST, 10:00 EST, 16:00 Paris CET, 20:00 Karachi PKT,  (Friday)00:00 Tokyo JST, (Friday) 02:00 Melbourne AEDT

For other times: https://tinyurl.com/ybssjnb3

PROPOSED AGENDA


As this is the first formal meeting for us, we will go over briefly the procedures to review feedback for the Initial Report. The Sub Group C will follow a working schedule to facilitate the review and analysis of comments. This week we will start with the Registry Agreement comments available at the below link. 

https://docs.google.com/spreadsheets/d/1MQmo1B6zBqGXYFRF2pKZXPhGmz0JfZhIaMxKIdVsT1g/edit#gid=1627799531 [docs.google.com] 

It is expected that each member has reviewed the comments in full before the meeting so that we can quickly move through our analysis. We kindly ask for your cooperation in this. 


 BACKGROUND DOCUMENTS




Mp3

Adobe Connect Recording

GNSO transcripts are located on the GNSO Calendar


Attendance & AC chat

Apologies: Susan Payne, Justine Chew

Notes/ Action Items


Notes: 

1. Welcome and SOIs (2min)

- No SOI Updates

2. Process for review (3min)

- comments are organized into a series of spreadsheets in Google Docs

- leadership team has done preparatory work to assist with analyzing the comments

- the SG will go through the comments to identify areas where there is agreement, divergence, concerns, and new ideas, as well as identifying any comments that need to be clarified

- the SG will do a first pass of review and may do a second pass if certain comments need additional consideration

- basic structure of the doc -- first tab is a work plan for the Sub Group. Work plan suggests addressing the topics in order that they are contained in the spreadsheet. Today is an exception. We are starting with a topic that the leaders felt would be a good starting point because the Sub Group began discussing this topic in Barcelona.

- On each sheet, the comments are organized under each recommendation, option, or question. 

- The text at the beginning of each comment, staff has tried to capture the essence of the comment in bold.

- The WG response column follows the template in the GNSO Working Group Guidelines. 

- The leadership team did a preliminary assessment to see which of the following apply to each comment: agreement, divergence, concerns, new idea.

From the chat:

Jim Prendergast: uestion was on WG response is that something we do on a track by track basis or at the plenary level?

Cheryl Langdon-Orr (CLO - PDP Co-Chair): We bring our assessment(s) of the PC's reveived with any recommendations or changes that have been proposed back to Planary @Jim

- The goal is that everyone reviews the comments before the call  so that they do not need to be read aloud on the call.

3. Review of Registry Agreement Comments (45min)

- 2.10.1.c.1 - comments received from BRG, ICANN Org, XYZ, and Neustar.

- BRG comment supports the recommendation, provides new idea regarding use of the expedited PDP

From the chat:

- Katrin Ohlmer: I think the idea (in blue) does not relate to the question, so i would suggest to move this part to the section "Additional Comments".

- Question - why might the BRG suggest that the RA is part of consensus policy. The RA is an agreement between ICANN and the Registry. Not sure if it's accurate that an amendment to the RA would be for policy development to address. Is there an opportunity to ask clarifying questions to BRG on this.

From the chat:

Cheryl Langdon-Orr (CLO - PDP Co-Chair): Clarifying questions  is why we asked for liaisons from groups, but that said, like spices in cooking should be used sparingly ;-0)

- We are not limited from asking clarifying questions in the exercise. 

- Point of clarification - the blue text is a different color because it is a new idea raised in the context of the comment. 

- The comment is prefaced with a qualifier that explains when there may be a PDP. Agreement that only when those conditions are met should this be subject to policy development.

- Process question - if the group has a question for the liaisons or the commenters, what is the process for getting clarification on questions?

- These will be sent to the liaisons through the leadership team, or if there is no liaison applicable, through other appropriate channels.

ACTION ITEM: leadership team will share comment/clarifying question with Martin Sutton from BRG.

- Comment from ICANN Org raises concerns about proposed recommendation (see caveats below in discussion)

From the chat:

Cheryl Langdon-Orr (CLO - PDP Co-Chair): This  ICANN.org one is an example of where a contributor raises some 'concern'   as oppossed to Agreement or Agreement with a refinement or new idea proposed as is seen in the other comments received) by example

Jim Prendergast: ICANN also warned applicants that if they had any changes to the base registry agreement, it wold take a long time ad they would go to the back of the line

Jim Prendergast: are we aware of any examples of where an applicant successfully negotiated changes to the base registry ageement?

- Comment about the overall context of the responses - ICANN is talking about process for making changes to the RA. The BRG is talking about what happens if a whole class of applicants need a change that might result in a new specification. We might want to think about the different perspectives that the respondents are coming in with. This should be taken into consider when we indentify convergence, divergence, etc.

From the chat:

Jeff Neuman: I think Kristine is right.  ICANN's comments are not necessarily concerns on the high level changes, but rather only on the individual type changes

- It might be helpful to make the recommendation more specific and clear regarding the scope of the recommendation. 

- comment from XYZ states that the RA must be available at the beginning of the application process. 

- this is not really a new idea, it was discussed under the topic of predictability. This could be a recommendation if it gets traction. 

- This is actually part of the original GNSO policy (base RA must be available at the beginning of the application process. 

- This should be categorized as off topic and possibly be considered elsewhere

From the chat: 

Jeff Neuman: Recommendation 10 from 2007 GNSO FInal Report adopted by the Board in 2008:  https://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07 [gnso.icann.org]

Jeff Neuman:  There must be a base contract provided to applicants at the beginning of the application process.

- Comment from Neustar in support of the recommendation.

- Comment from RySG in support of this recommendation.  Supports greater flexibility for ROs wishing to seek an exemption. Do not believe that section 2.9 should apply to Spec 9 exempt TLDs.

- Comment from MarkMonitor supports single RA, with exceptions (e.g. PICs) for certain types (e.g. communities, .brand)

From the chat:

Michael Flemming: We have not had any divergence from the comments that we related to this

- Question 2.10.1.e.1: responses from RrSG and Neustar.

- RrSG states that at a minimum, all SLA metrics should be equal

- Neustar raised concerns in response to this question - would require an applicant to know the underlying policy justifications for any part of the RA. 

- If this ends up rising to the level of a recommendation, it might be useful to reach out the Neustar for further clarifiication. It seems like the Neustar comment might better fit under 2.10.1.e.1.1, a subquestion under 2.10.1.e.1.

ACTION ITEM: Follow up with Neustar for clarification on response to question 2.10.1.e.1

- Question 2.10.1.e.1.1 - response from RrSG

- RrSG supports as long as review of the request takes place, believes erring on the side of registrants and channel continues to make sense.

4. AOB and Objective Next Meeting (4min)

- Next call will pick up with the topic Registry Agreement

- Next call is 15 November 2018 at 20:00 UTC for 60 minutes