[Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 February 2018
Steve Chan
steve.chan at icann.org
Tue Apr 17 23:41:59 UTC 2018
Dear WT4 Members,
Please see a subsequent response from ICANN org in support of the WT4 request below.
“As a follow-on to the March 20th, 2018 message, the Supplemental Notes materials referenced in that message are now located at https://community.icann.org/x/gggFBQ. In addition, we are providing WT4 with FAQs, Knowledge Articles, and Reference Materials previously published in the SugarCRM knowledge base. These materials are historical information that ICANN org is providing to WT4 to inform PDP deliberations.”
Once you navigate to the link above, you will see that there are separate Wiki page for FAQs, Knowledge Articles, Reference Materials, and Supplemental Notes. If you have any questions or comments, please let me know.
Best,
Steve
From: Gnso-newgtld-wg-wt4 <gnso-newgtld-wg-wt4-bounces at icann.org> on behalf of Steve Chan <steve.chan at icann.org>
Date: Tuesday, March 20, 2018 at 4:05 PM
To: "gnso-newgtld-wg-wt4 at icann.org" <gnso-newgtld-wg-wt4 at icann.org>
Subject: Re: [Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 February 2018
Dear WT4 Members,
Per the WT’s request to ICANN Org in the email below, please find their response directly below and information/resources compiled to date attached. The information/resources can also be found on the topic specific Wiki page here: https://community.icann.org/x/YT2AAw
Best,
Steve
**
As per your request sent via Steve Chan on 9 February 2018, attached is a compilation of existing and published information and resources regarding application questions and clarifying questions. Please note that the Supplemental Notes information referenced in the document is not yet available. This information was hosted in our old CRM system, which has been decommissioned. It is taking longer than we thought to bring this system back up online, but we continue to work with our IT team on this. We will provide you with the links to the Supplemental Notes for all application questions once the system is back up online. In the meantime, we are sending you all other information and resources relevant to this request.
From: Gnso-newgtld-wg-wt4 <gnso-newgtld-wg-wt4-bounces at icann.org> on behalf of Steve Chan <steve.chan at icann.org>
Date: Wednesday, February 7, 2018 at 4:41 PM
To: Julie Hedlund <julie.hedlund at icann.org>, "gnso-newgtld-wg-wt4 at icann.org" <gnso-newgtld-wg-wt4 at icann.org>
Subject: Re: [Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 February 2018
Dear WT4 Members,
For those that may have missed the last call, as noted below in the action items, it was decided that in relation to WT4’s request for data related to clarifying questions, it would be pursuing option 1, “Compile and share existing information and resources regarding application questions and clarifications.” Please see a fuller description here: https://community.icann.org/download/attachments/58735969/ICANN%20Org%20Response%20to%20WT4%20CQ%20Data%20Request.pdf?version=1&modificationDate=1517425699000&api=v2
Note, this does not preclude WT4 from seeking additional clarifying question information it deems necessary, which could include options in the letter referenced above and/or other options.
Best,
Steve
From: Gnso-newgtld-wg-wt4 <gnso-newgtld-wg-wt4-bounces at icann.org> on behalf of Julie Hedlund <julie.hedlund at icann.org>
Date: Monday, February 5, 2018 at 1:08 PM
To: "gnso-newgtld-wg-wt4 at icann.org" <gnso-newgtld-wg-wt4 at icann.org>
Subject: [Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 February 2018
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.pdf?version=1&modificationDate=1517582919000&api=v2
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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20180417/e47907af/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2018 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4/attachments/20180417/e47907af/smime-0001.p7s>
More information about the Gnso-newgtld-wg-wt4
mailing list