Dear Work Track members, Please see below the action items and notes from the meeting today. These high-level notes are designed to help WG members navigate through the content of the call and are not a substitute for the recording or transcript. See the chat transcript and recording at: https://community.icann.org/x/ERohB. Slides are attached for reference and some chat room excerpts are included below. Kind regards, Julie Julie Hedlund, Policy Director ---------------------------------------------------------------------------------------- Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 – 05 February 2018 Action Items: 1) CQ Options:  Agreement for Option 1: Compile existing info regarding questions and CQs (what was done for PIRR); but doesn't preclude other options; consider survey question for the survey of applicants in option 5. 2) RSSAC paper: Clarifying question -- Ask the RSSAC to provide clarify on what it meant re: 5%.  Notes: 1. SOI Updates: No updates. 2. Review of Technical Services suggestions for additional technical criteria (https://community.icann.org/pages/viewpage.action?pageId=58735969) Slide 5: Responses from Technical Services -- 8 recommendations regarding Registry System Testing and 3 regarding Application Evaluation. -- RST recommendations mostly linked to Registry Service Provider (RSP) program -- sync with WT1 and/or full WG. -- 1 Application Evaluation recommendation linked to RSP. -- 1 Application Evaluation recommendation about using RSEP for Registry Services Evaluation. -- Other Application Recommendation about 0-1 scoring instead of 0-1-2 from Program Implementation Review Report (PIRR) and accepted by WT4. 3. Review of Operations responses for request on CQs (also available at https://community.icann.org/pages/viewpage.action?pageId=58735969) Slides 6-7: Responses from Operations -- As for full text of CQs and answers for the questions with published answers and counts of CAs and answers for questions without published answers. Slide 8: Possible Ways Forward -- Insist on initial request but allow for redaction of content that mixes public and private responses. -- Pick either option 2 (staff review) or 3 (3rd party review). -- Other options? -- Continue working on known issues such as 0-1-2 scoring, Q30b (Security Policy) and Financial Evaluation. Discussion: -- Difficult to get additional funds in the budget, so precludes 2 and 4. -- Combine 1 with a survey of applicants. -- Change option 5 to survey of new registries. -- Possible option: Select options but in addition the bullet on slide 8 about requesting that during implementation other studies might be needed. -- What policy question are we trying to answer? Need to know which problems need policy decisions.

From the Chat:

Jeff Neuman: My recommendation was combining 1 and 5 Jeff Neuman: ok.  I thought a combo of 1 and 5 was the way to go which cost the least amount of money Maxim Alzoba (FAITID): 5. might not work - it was quite long ago (many applicants were consultants and have no contract since then) Cheryl Langdon-Orr (CLO): combination options can be discussed and proposed of course Rubens Kuhl: Any combination is fine, any new option is fine too. Maxim Alzoba (FAITID): so .5 might be changed to survey of new Registries Jeff Neuman: @maxim - true, but they still have email addresses on file.  If they dont work, then they dont work Jeff Neuman: I think we should try to reach out to the failed ones.  In some ways, their feedback would be more valuable. Jeff Neuman: There were not too many failed applications Kurt Pritz: You can ignore this if it will drag us backward; what policy question are we trying to answer by reading the CQs? The answer to that would govern which option is selected Maxim Alzoba (FAITID): @Jeff, if applicant is not equal to Registry  - most probably they might have no real life info from the current registry Jeff Neuman: Kurt -  Our mission, should we choose to accept it, is to make recommendations that will improve the questions asked in the previous round so as to make the questions more clear and to provide the information that was actually sought by the evaluators.  It is hoped that this would reduce the number of CQs the next time Cheryl Langdon-Orr (CLO): good point @Steve Jeff Neuman: For example, if the same CQ was asked to 80% of the applicants, chances are that the problem was in the question and not the answers Cheryl Langdon-Orr (CLO): exactly @Jeff Trang Nguyen: If the goal is to understand what the issues were with questions, Option 1 would provide the most direct answer. Org published advisories on the issues that were encountered most frequently by applicants. That together with statistics on the number of CQs could help to identify the issues. Jeff Neuman: @Trang - Agree that we need option 1 and I believe option 5 will also help. Maxim Alzoba (FAITID): COI related questions were good example of wrong ones (where all companies had to change their letters of credit few times) Cheryl Langdon-Orr (CLO): 1 as a priority and 5 as. following recommendation? Maxim Alzoba (FAITID): Could we update .5 with - ask the Registry - if it is Ok to ask Applicant or them ? Trang Nguyen: @Jeff, option 5 could be useful as well. It hadn't occurred to me before, but now thinking about it, doing 5 during implementation may be even more impactful. Any changes to the questions based on policy recs could be made, then published for public comment, during which we could ask whether any formulation of the questions need clarification. Martin Sutton: @Trang - agree that 1 is a sensible option, with option 5 to add more context to CQs they may have responded to. Cheryl Langdon-Orr (CLO): certainly could @Maxim Martin Sutton: @maxim - I recall COI triggering the most CQs, which was mainly as a result of inadequate instructions provided in the first place. 4. Review of responses for delegation rate and maximum number of TLDs (available at https://community.icann.org/display/NGSPP/4.6.1+Security+and+Stability) Slide 10: ICANN Org -- Mostly discussed application processing limits, not root zone scaling. -- Mentioned a relevant change: the increasing use of root zone replication to resolvers (RFC 7706) -- also applies to RFC 7816 (DNS query minimization) -- Says determining scaling capacity would require significant effort that might not be worthwhile since application processing limitations will likely be reached before any limitation becomes an issue. -- No response to root zone size question. Slide 11: SSAC -- ICANN should continue developing the monitoring and early warning capability with respect to root zone scaling. -- ICANN should focus on the rate of change for the root zone, rather than the total number of delegated strings for a given calendar year. -- ICANN should structure its obligations to new gTLD registries so that it can delay their addition to the root zone in case of DNS service instabilities. -- ICANN should investigate and catalog the long term obligations of maintaining a larger root zone. Slide 12: RSSAC -- Confirmed deployment of root zone system monitoring. -- Suggested adopting a monthly thinking instead of per annum. -- Recommended 5% per month growth rate (target, not ceiling). -- Strong recommendation on keeping allowed DNS records at root zone to a minimum (not related to TLS zone contents). -- Suggests possiblity of delaing or removing delegations. -- On zone size, is more concerned of possible TLDs becoming as popular ast .com/.net/.org than zone size, although unsure of effects for flattening DNS namespace. -- 3 non-technical questions referred to full WG and/or other WTs. Slide 13: Recommendations not incompatible with GNSO policy or each other -- Monitoring and early warning of the root zone system (RSSAC & SSAC). -- Delaying or removing delegations that cause instability (SSAC & RSSAC). -- More focus on change rate over smaller time periods than annually (SSAC and RSSAC). -- 5% monthly growth rate target (RSSAC). -- Maintain conservative approach to DNS records in the root zone (RSSAC). Slide 14: Recommendations incompatible with GNSO policy or each other -- Application processing limitations will already avoid issues (ICANN Org x SSAC and RSSAC). -- Investigate long term obligations of larger root zone prior to new delegations. Discussion: -- These are opinions not based on research; they are conservative.  From a risk management perspective that is not necessarily a bad thing. -- Discuss further the 5% monthly growth rate face-to-face with representatives with RSSAC and SSAC.

From the chat:

Maxim Alzoba (FAITID): what was the justification for 5%? any ? Maxim Alzoba (FAITID): @Martin, the requirements changes over the time - which is not good Maxim Alzoba (FAITID): *changed Maxim Alzoba (FAITID): why not 7% or 10%? Jeff Neuman: This may be a stupid question, but is gorwth rate strictly limited to adding new TLDs, or does it include adding new records (like DNSSEC records)?  If so, according to some rudimentary calculations on a spread sheet, it would take only  5 years to delegate 25,000 new TLDs at a growth rate of 5% per month Christa Taylor: +1 Jeff Christa Taylor: This would have some significant impacts to the delegation of new gTLDs Kurt Pritz: I did some rough calculations that are close but not exact: if the 5% requirement was imposed inthe 2012 round, some TLDs would have been delayed a year beyond the date when they were actually delegated and the backlog created (as compared to the actual delegations) would have taken 3 years to clear Maxim Alzoba (FAITID): and 5% gives 50 per month and 790 per year ... which is lower than 1000 , and thus it is not correct from perspective of 1000 per year is ok Maxim Alzoba (FAITID): *per first year Maxim Alzoba (FAITID): *ofr the first year :) Jeff Neuman: @maxim, the 5% is cumulative Jeff Neuman: If you start at 1200 and increase 5% per month, it would take 62 months to delegte 25,000 new gTLDs Maxim Alzoba (FAITID): @Jeff, my point that this number is not based on a research Maxim Alzoba (FAITID): it is just "we think 5% should be safe" - which is an opinion and not something calculated Maxim Alzoba (FAITID): Could we request from RSSAC the method they used to calculate this particular threshold? Jeff Neuman: at 6%, it would be take 53 months Maxim Alzoba (FAITID): 5% will detoriate the speed of delegation from 1000per year Maxim Alzoba (FAITID): and that 1000 was not properly justified too Jeff Neuman: at 7% per month, that would take 48 months for 25000 TLDs Maxim Alzoba (FAITID): @Jeff I am afraid that they meant  5%  of the starting amount (not cumulative)... Jeff Neuman: I interpreted it at 5% per month Cheryl Langdon-Orr (CLO): I read as a " from now on" point as well @Rubens Maxim Alzoba (FAITID): so it is not 1.05*1.05 but simply 1*1.05 Jeff Neuman: 5% from original amount is less than 1000 per ye Jeff Neuman: Look at the chart on page 7 Maxim Alzoba (FAITID): *risk Kurt Pritz: I am with Maxim about asking for the methodology to arrive at this number. If there is a methodology, then the number is a starting point for discussion, as Cheryl says. If it is an opinion without basis, then it is not a starting point Jeff Neuman: of the RSSAC paper Steve Chan: @Maxim, the RSSAC paper is available on the Wiki here: https://community.icann.org/download/attachments/58735967/RSSAC031%20FINAL.p... Kurt Pritz: In the 2012 round 35-40% was acceptable in the first month of delegations Rubens Kuhl: Do the resolution mentioned what would happen with the current work in progress at SSAC, asked by the board at November 2017 ? Rubens Kuhl: The graph on the appendix of the RSSAC suggestion makes clear which interpretation it is, which is (1+5%) to the power of number of months. Christa Taylor: Maxim +1 - s/b linear 5. AOB: Board decision on .corp, .home, and .mail -- not to be delegated in a next round and deposits will be refunded.  Staff will provide links to the resolution when available.

From the chat:

Rubens Kuhl: Do the resolution mentioned what would happen with the current work in progress at SSAC, asked by the board at November 2017 ? Rubens Kuhl: (on home/corp/mail)