February 2018 - Gnso-newgtld-wg-wt4

Re: [Gnso-newgtld-wg-wt4] Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 February 2018
by Steve Chan April 17, 2018

April 17, 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%20Res… 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(a)icann.org> on behalf of Julie Hedlund <julie.hedlund(a)icann.org> Date: Monday, February 5, 2018 at 1:08 PM To: "gnso-newgtld-wg-wt4(a)icann.org" <gnso-newgtld-wg-wt4(a)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.… 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)

1 2

WT4 Call #25
by Rubens Kuhl March 1, 2018

March 1, 2018

Dear WT4 members, The next call for the New gTLD Subsequent Procedures Sub Team – Track 4 - IDNs/Technical & Operations will take place for 60 minutes on Thursday, 01 March 2018 at 20:00 UTC, 21:00 Brussels, 20:00 London, 12:00 Los Angeles, 15:00 Washington DC; Friday 02 March, 04:00 Singapore, 05:00 Tokyo, 07:00 Sydney. The proposed agenda, as previously mentioned during the last WT4 call, is as follows: 1. Welcome, SOI updates 2. WG Co-chairs guidance on Initial Report 3. Registry System Testing 4. AOB Since RST (Registry System Testing) was described in AGB as PDT (Pre-Delegation Testing), reading section 5.2 is recommended: https://newgtlds.icann.org/en/applicants/agb/transition-delegation-04jun12-… More documents are available at ICANN's RST website, https://www.icann.org/resources/registry-system-testing <https://www.icann.org/resources/registry-system-testing> , of which this chart - https://www.icann.org/sites/default/files/assets/rst-1280x720-31jul17-en.jpg <https://www.icann.org/sites/default/files/assets/rst-1280x720-31jul17-en.jpg> - is an useful high-level summary. For WG members, please use the instructions in the calendar invite for connecting to AC and phone bridge, with phone bridge recommended for those willing to speak. Best, CLO & Rubens

3 6

Recordings, attendance & AC chat from New gTLD Subsequent Procedures Sub Team Track 4 IDNs/Technical & Operations call on Monday, 12 February 2018 15:00 UTC
by Michelle DeSmyter Feb. 12, 2018

Feb. 12, 2018

Dear All, Please find the attendance, AC Chat and recording of the call attached to this email. The Adobe Connect recording is below for the New gTLD Subsequent Procedures Sub Team - Track 4 - IDNs/Technical & Operations call held on Monday, 12 February 2018 at 15:00 UTC. Adobe Connect recording: https://participate.icann.org/p5n41ccfzwc/ The recordings of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4 Agenda Wiki page: https://community.icann.org/x/LAWfB Thank you. Kind regards, Michelle

1 0

Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 12 February 2018
by Julie Hedlund Feb. 12, 2018

Feb. 12, 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 – 12 February 2018 1. SOI Updates: No updates. 2. Continued discussion of financial evaluation models Slide 6: -- Discussed 4 financial evaluation models: 1) No financial evaluation 2) No business model or financial fitness evaluation, only financial wherewithall. 3) Some level of self or 3rd-party certification, still without business model evaluation. 4) Comprehensive evaluation of business model and finances. Slide 7: -- Let's start from scratch, using what we got from WT members so far: -- Little support for models 1 and 4. -- Model 2 with some simplifications and some additions looked more capable of achieving consensus. -- The output isn't consensus-grade yet, let's test it. Slide 8: -- 5 criteria (see details on the slide) Slide 9: -- Implementation mock-up of the evaluation questions (see details on the slide) Slide 10: Financial Evaluation in Initial Report -- Include both "middle-earth" and "straw-cookie monster" models mentioning agreement (or lack thereof) level, and in the case of "middel-earth", mention to possible simplifications. -- Include, if provided, mock-up questions for each model. Since Financial Evaluation is getting a full re-write, providng questions simplify and clarifty implementation, although not required and not immutable. Discussion: -- COI piece -- given this mock up the COI element that could be taken as a payment by ICANN could be deferred to the signing of the payment and delegation (rather than at application submission). Or it could be spread across the regular payments made to ICANN. (Note that WT2 has spent a lot of time on this.) -- Like the proposed financials and taking an overall view of how many applications submitted. Still have to consider what would happen if they would win 50% or 90% and what percent could go to private option. Otherwise pooling is great. -- Two types of review: finanical review and an audit. The downfall is that the applicant might say that they don't expect a launch for two years. The process that a company has to do it in line with this process -- working with an auditor to understand what the business is going to do, the volume, to showing that they have given enough thought. -- Side note: Need to be sure that the applicant can demonstrate their ability to contract companies for bandwidth, hardware, etc. Too hard to have everything contracted in advance. >From the chat: Maxim Alzoba(FAITID): audited financial statement of a new company gives almost no info beyond officers and address and starting balance Maxim Alzoba(FAITID): it was violation of FATF recommendations to governments Maxim Alzoba(FAITID): Financial Action Task Force (FATF) Martin Sutton: Could the COI amount you referred to be part of a payment once agreement is signed? I know this is not directly related to this wt.. Maxim Alzoba(FAITID): I am not saying starting audit is not required, that is a measure to prevent purely (from financial of judicial points of view)bad companies from participation Phil Buckingham: 70% 80% of CQ s issued were related to Q50 re the LOC / COI not Q46 on lack of / submission of financial statements Maxim Alzoba(FAITID): +1 Martin, it would simplify COI obtaining from banks Jon Nevett: Good point Martin -- making applicants pay a COI doesn't make much sense at all Phil Buckingham: yes agreed . Maxim Alzoba(FAITID): COI is required only for 6 years, and payment is one way thing Maxim Alzoba(FAITID): to support new Registries with EBERO (paid via COI if smth goes wrong) Christa Taylor: An audit/review will evaluate the business model as it would have implications on the financial viability of the corporation Trang Nguyen: Perhaps stating the obvious, but there’s a tie between COI and the RSP discussion. I believe one of the approaches under discussion there is to have the RSP take-over in cases of financial failure. If that is adopted, there would be no need for a COI.

1 0

WT4 Call #24
by Rubens Kuhl Feb. 11, 2018

Feb. 11, 2018

Dear WT4 members, The next call for the New gTLD Subsequent Procedures Sub Team – Track 4 - IDNs/Technical & Operations will take place for 60 minutes on Monday, 12 February 2018 at 15:00 UTC, 16:00 Brussels, 15:00 London, 07:00 Los Angeles, 10:00 Washington DC, 23:00 Singapore; Tuesday, 13 February 2018 00:00 Tokyo, 02:00 Sydney. The proposed agenda, as previously mentioned during the full WG call last Monday, is as follows: 1. Welcome, SOI updates 2. Continued discussion of financial evaluation models 3. AOB All of the models reviews will include assessment of WG agreement or disagreement, and can lead to tentative consensus calls. Prior reading of the models and meeting #22 slides (https://community.icann.org/display/NGSPP/2018-01-11+New+gTLD+Subsequent+Pr… <https://community.icann.org/display/NGSPP/2018-01-11+New+gTLD+Subsequent+Pr…>) is strongly recommended. For WG members, please use the instructions in the calendar invite for connecting to AC and phone bridge, with phone bridge recommended for those willing to speak. Best, CLO & Rubens

1 0

Recordings, attendance & AC chat from New gTLD Subsequent Procedures Sub Team Track 4 IDNs/Technical & Operations call on Monday, 05 February 2018
by Julie Bisland Feb. 5, 2018

Feb. 5, 2018

Dear All, Please find the attendance, AC Chat and recording of the call attached to this email. The Adobe Connect recording is below for the New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations call held on Monday, 05 February 2018 at 20:00 UTC. Adobe Connect recording: https://participate.icann.org/p2nph1syd1m/<https://participate.icann.org/p2nph1syd1m/?OWASP_CSRFTOKEN=965d4db171c7a81f…> The recordings of the calls are posted on the GNSO Master Calendar page: http://gnso.icann.org/en/group-activities/calendar ** Please let me know if your name has been left off the list ** Mailing list archives: http://mm.icann.org/pipermail/gnso-newgtld-wg-wt4 Agenda Wiki page: https://community.icann.org/x/KgWfB Thank you. Kind regards, Julie

1 0

Re: [Gnso-newgtld-wg-wt4] [Gnso-newgtld-wg] Fwd: New gTLD Subsequent Procedures PDP WG: Request for Input
by lists＠christopherwilkinson.eu Feb. 5, 2018

Feb. 5, 2018

Dear Alexander: I think we shall not proceed to argue over a reductio ad absurdum. Let’s get real. CW > On 5 Feb 2018, at 20:56, Alexander Schubert <alexander(a)schubert.berlin> wrote: > > Dear Anne, > > So you suggest to lower the entry barrier (cost) to a VERY low amount (e.g. USD 10k) so that anyone who can afford today buying a used llll.com <http://llll.com/> can make their own gTLD in 2020? > > At 10k we will have 25,000 applications – and that’s a conservative estimate. At 1k processing speed per year we will gnaw at that for a decade. > > We need SOME kind of barrier for the next round! Money is a good one. If not money: what then? > > My humble opinion. > > Thanks, > > Alexander > > > > From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org <mailto:gnso-newgtld-wg-bounces@icann.org>] On Behalf Of Aikman-Scalese, Anne > Sent: Monday, February 05, 2018 8:48 PM > To: 'lists(a)christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu>' <lists(a)christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu>>; Jeff Neuman <jeff.neuman(a)comlaude.com <mailto:jeff.neuman@comlaude.com>> > Cc: gnso-newgtld-wg-wt4(a)icann.org <mailto:gnso-newgtld-wg-wt4@icann.org>; gnso-newgtld-wg(a)icann.org <mailto:gnso-newgtld-wg@icann.org> > Subject: Re: [Gnso-newgtld-wg] Fwd: New gTLD Subsequent Procedures PDP WG: Request for Input > > Excellent points which certainly merit discussion. I realize the original policy was always toward “unlimited” TLDs. But seriously the cost of entry is SO HIGH. > > It is tempting to draw some analogies here with (1) lack of Internet access and (2) lack of computer hardware and (3) lack of cell phone service > > Is there a “Great Divide” developing in the world of gTLDs? Will small business be left behind? > > Anne E. Aikman-Scalese > Of Counsel > 520.629.4428 office > 520.879.4725 fax > AAikman(a)lrrc.com <mailto:AAikman@lrrc.com> > _____________________________ > <image001.png> > Lewis Roca Rothgerber Christie LLP > One South Church Avenue, Suite 2000 > Tucson, Arizona 85701-1611 > lrrc.com <http://lrrc.com/> > > > From: lists(a)christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu> [mailto:lists@christopherwilkinson.eu <mailto:lists@christopherwilkinson.eu>] > Sent: Monday, February 05, 2018 11:41 AM > To: Jeff Neuman > Cc: Aikman-Scalese, Anne; gnso-newgtld-wg(a)icann.org <mailto:gnso-newgtld-wg@icann.org>; gnso-newgtld-wg-wt4(a)icann.org <mailto:gnso-newgtld-wg-wt4@icann.org> > Subject: Re: [Gnso-newgtld-wg] Fwd: New gTLD Subsequent Procedures PDP WG: Request for Input > > Good evening: > > Whatever domain names may have become, I think that the vast expansion - in the past and perhaps to come - has been mainly at the second level. > > At the top level, I still have serious misgivings: > > - The sudden, large expansion following the previous round has resulted in a significant proportion of Registries that are not financially viable, > at least on a stand-alone basis. (c.f. ‘vertical' integration) > > - we still lack market research by ICANN as to the business scope for introducing even more new TLDs. > Both in terms of the aggregate DNS market and in terms of the macro-economic context. > > - I am sensitive to warnings about how many and how quickly changes to the Root can be relied upon to maintain stability and security. I defer to RSSAC among others > > - I would love to live in a DNS world where a TLD would represent <significance or memorability to a small community, locality or even a family> > I would be on for that! But last time I looked, the costs and risks associated with creating a new TLD Registry are way beyond small communities’ resources. > ICANN oblige. > > Just a few thoughts > > CW > > (Speaking personally, of course.) > > > >> On 5 Feb 2018, at 17:20, Jeff Neuman <jeff.neuman(a)comlaude.com <mailto:jeff.neuman@comlaude.com>> wrote: >> >> Completely personal opinion here, but I think that comment from the RSSAC is a “red herring” meaning that it ignores the rationale for new TLDs. The RSSAC is looking at the notion of domain names as only being for the original purposes in which they were intended: Namely to create more memorable representations of network resources, because it was perceived to be too difficult to remember IP Addresses. >> >> What it ignores is that the use of domain names, whether at the top or the second level, has evolved into being used for many other purposes than purely that for which it was originally designed. As stated by John Klensin in IETF RFC 3467 (2003), >> >> “The DNS was designed to identify network resources. Although there was speculation about including, e.g., personal names and email addresses, it was not designed primarily to identify people, brands, etc. At the same time, the system was designed with the flexibility to accommodate new data types and structures, both through the addition of new record types to the initial "INternet" class, and, potentially, through the introduction of new classes.” >> >> Despite not being designed for these purposes, that is what has evolved. Domains are now used to identify computers, machines, organizations, people, places and things. Whether used for commercial or non-commercial purposes, they identify brands, people, geographic locations and things to their relevant user base. That user base may be global, national, local or even familial. A domain may be used for web traffic, machine-machine communication, e-mail or a host of other potential applications. It is up to the owner of the domain name (Or TLD) to make its intended user base aware of its existence. The significance of the domain is then ascertained and judged by the user base and not those outside of its intended user base. >> >> The RSSAC is asking an existential policy question of the GNSO community. One that has no right or wrong answer and one which has no clearly ascertainable answer. The answer to the question will differ to every person that attempts to answer it. There is no way to measure the global significance or memorability of any particular namespace. There is no purely scientific way to answer that question. And even if there was, why would it be limited to “library and cognitive science.” Why not look at it from an Anthropological, Economical, Educational, Historical, Linguistic, Philosophical, Political, Psychological, Sociological, Sustainability or other type of social science perspective? >> >> My personal view is that regardless of the global significance or memorability of a namespace, that namespace may have significance or memorability to a small community, locality or even a family. It may not even be used in the traditional sense and not intended to have any memorability by any persons or groups, but may only be significant to other machines. One of the things discussed at Namescon last week was a venture that Donuts has invested in which is working on using a TLD Namespace for a Geographical mapping tool to map the entire world down to the centimeter. If it does use the TLD namespace to do this, then there may or may not need to be any memorability of the namespace to any human so long as devices knew how to find the appropriate location. >> >> Sorry for the long e-mail and I will get off my soapbox, but I am not a huge fan of spending any more time on that question given that in my opinion it misses the point and relevance of what domains (and TLDs) have become. >> >> Jeffrey J. Neuman >> Senior Vice President |Valideus USA | Com Laude USA >> 1751 Pinnacle Drive, Suite 600 >> Mclean, VA 22102, United States >> E: jeff.neuman(a)valideus.com <mailto:jeff.neuman@valideus.com> or jeff.neuman(a)comlaude.com <mailto:jeff.neuman@comlaude.com> >> T: +1.703.635.7514 >> M: +1.202.549.5079 >> @Jintlaw >> >> From: Aikman-Scalese, Anne [mailto:AAikman@lrrc.com <mailto:AAikman@lrrc.com>] >> Sent: Friday, February 2, 2018 1:15 PM >> To: Jeff Neuman <jeff.neuman(a)comlaude.com <mailto:jeff.neuman@comlaude.com>>; gnso-newgtld-wg(a)icann.org <mailto:gnso-newgtld-wg@icann.org>; gnso-newgtld-wg-wt4(a)icann.org <mailto:gnso-newgtld-wg-wt4@icann.org> >> Subject: RE: [Gnso-newgtld-wg] Fwd: New gTLD Subsequent Procedures PDP WG: Request for Input >> >> I think the following point made by the RSSAC is very significant and certainly deserves further discussion. >> >> Using concepts from the disciplines of library and cognitive science, what number of TLDs results in their loss of memorability and significance? >> >> >> Hard to balance this with freedom of expression goal, but it should be given more consideration. In addition, the marketplace trend is toward apps – not more websites. >> >> Anne >> >> Anne E. Aikman-Scalese >> Of Counsel >> 520.629.4428 office >> 520.879.4725 fax >> AAikman(a)lrrc.com <mailto:AAikman@lrrc.com> >> _____________________________ >> <image001.png> >> Lewis Roca Rothgerber Christie LLP >> One South Church Avenue, Suite 2000 >> Tucson, Arizona 85701-1611 >> lrrc.com <http://lrrc.com/> >> >> >> From: Gnso-newgtld-wg [mailto:gnso-newgtld-wg-bounces@icann.org <mailto:gnso-newgtld-wg-bounces@icann.org>] On Behalf Of Jeff Neuman >> Sent: Friday, February 02, 2018 7:05 AM >> To: gnso-newgtld-wg(a)icann.org <mailto:gnso-newgtld-wg@icann.org>; gnso-newgtld-wg-wt4(a)icann.org <mailto:gnso-newgtld-wg-wt4@icann.org> >> Subject: [Gnso-newgtld-wg] Fwd: New gTLD Subsequent Procedures PDP WG: Request for Input >> >> Just in from the RSSAC. We will add the questions asked of us to the appropriate Work Tracks. Although some of the, may naturally fit in Work Track 4, others may be overall questions to the Working Group. >> >> If you have any thoughts on responses, please do not hesitate to weigh in and we will start keeping track on a Google Doc. >> >> >> Jeffrey J. Neuman >> Senior Vice President >> Com Laude USA / Valideus USA >> 1751 Pinnacle Dr., Suite 600 >> McLean, VA 22102 >> Jeff.Neuman(a)comlaude.com <mailto:Jeff.Neuman@comlaude.com> >> +1 (202) 549-5079 >> >> Begin forwarded message: >> >>> From: Steve Sheng <steve.sheng(a)icann.org <mailto:steve.sheng@icann.org>> >>> Date: February 2, 2018 at 8:49:36 AM EST >>> To: Jeff Neuman <jeff.neuman(a)comlaude.com <mailto:jeff.neuman@comlaude.com>>, avri doria <avri(a)apc.org <mailto:avri@apc.org>> >>> Cc: Rubens Kuhl <rubensk(a)nic.br <mailto:rubensk@nic.br>>, Cheryl Langdon-Orr <langdonorr(a)gmail.com <mailto:langdonorr@gmail.com>>, Emily Barabas <emily.barabas(a)icann.org <mailto:emily.barabas@icann.org>>, Steve Chan <steve.chan(a)icann.org <mailto:steve.chan@icann.org>>, Julie Hedlund <julie.hedlund(a)icann.org <mailto:julie.hedlund@icann.org>>, "rssac(a)icann.org <mailto:rssac@icann.org>" <rssac(a)icann.org <mailto:rssac@icann.org>> >>> Subject: Re: New gTLD Subsequent Procedures PDP WG: Request for Input >>> >>> Dear Jeff and Avri, >>> >>> Per your request on 14 September 2017, attached please find RSSAC’s response on root scaling. >>> >>> In addition to its formal advice, the RSSAC raises the following questions for the wider community (including GNSO) to consider. These questions go beyond the specifics of operations of DNS, the IANA functions, and the root server system, to broader issues of the costs and benefits of aggressive expansion of the root zone: >>> >>> Independent of expanding the commercial buoyancy of the DNS industry, how does the addition of many thousands of new gTLDs to the root zone make the Internet better for the people who use it, aside from the addition of IDNs for language and culture? >>> >>> Using concepts from the disciplines of library and cognitive science, what number of TLDs results in their loss of memorability and significance? >>> >>> Is adding a significantly large number of TLDs (e.g., more than 100,000) to the root zone, and presumably augmenting the business interests in the addressing system, a sustainable model for the DNS? At what point might this model fail. What next steps for naming system innovation are required, and when? >>> >>> >>> Best Regards >>> Steve Sheng on behalf of >>> >>> Tripti Sinha and Brad Verd >>> Co-Chairs, Root Server System Advisory Committee >>> >>> >> >> >> >> This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521. >> _______________________________________________ >> Gnso-newgtld-wg mailing list >> Gnso-newgtld-wg(a)icann.org <mailto:Gnso-newgtld-wg@icann.org> >> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg> > > > > This message and any attachments are intended only for the use of the individual or entity to which they are addressed. If the reader of this message or an attachment is not the intended recipient or the employee or agent responsible for delivering the message or attachment to the intended recipient you are hereby notified that any dissemination, distribution or copying of this message or any attachment is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the sender. The information transmitted in this message and any attachments may be privileged, is intended only for the personal and confidential use of the intended recipients, and is covered by the Electronic Communications Privacy Act, 18 U.S.C. §2510-2521. > _______________________________________________ > Gnso-newgtld-wg mailing list > Gnso-newgtld-wg(a)icann.org <mailto:Gnso-newgtld-wg@icann.org> > https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg <https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg>

1 0

Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 05 February 2018
by Julie Hedlund Feb. 5, 2018

Feb. 5, 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.… 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)

1 0

Fwd: New gTLD Subsequent Procedures PDP WG: Request for Input
by Jeff Neuman Feb. 5, 2018

Feb. 5, 2018

Just in from the RSSAC. We will add the questions asked of us to the appropriate Work Tracks. Although some of the, may naturally fit in Work Track 4, others may be overall questions to the Working Group. If you have any thoughts on responses, please do not hesitate to weigh in and we will start keeping track on a Google Doc. Jeffrey J. Neuman Senior Vice President Com Laude USA / Valideus USA 1751 Pinnacle Dr., Suite 600 McLean, VA 22102 Jeff.Neuman(a)comlaude.com<mailto:Jeff.Neuman@comlaude.com> +1 (202) 549-5079 Begin forwarded message: From: Steve Sheng <steve.sheng(a)icann.org<mailto:steve.sheng@icann.org>> Date: February 2, 2018 at 8:49:36 AM EST To: Jeff Neuman <jeff.neuman(a)comlaude.com<mailto:jeff.neuman@comlaude.com>>, avri doria <avri(a)apc.org<mailto:avri@apc.org>> Cc: Rubens Kuhl <rubensk(a)nic.br<mailto:rubensk@nic.br>>, Cheryl Langdon-Orr <langdonorr(a)gmail.com<mailto:langdonorr@gmail.com>>, Emily Barabas <emily.barabas(a)icann.org<mailto:emily.barabas@icann.org>>, Steve Chan <steve.chan(a)icann.org<mailto:steve.chan@icann.org>>, Julie Hedlund <julie.hedlund(a)icann.org<mailto:julie.hedlund@icann.org>>, "rssac(a)icann.org<mailto:rssac@icann.org>" <rssac(a)icann.org<mailto:rssac@icann.org>> Subject: Re: New gTLD Subsequent Procedures PDP WG: Request for Input Dear Jeff and Avri, Per your request on 14 September 2017, attached please find RSSAC’s response on root scaling. In addition to its formal advice, the RSSAC raises the following questions for the wider community (including GNSO) to consider. These questions go beyond the specifics of operations of DNS, the IANA functions, and the root server system, to broader issues of the costs and benefits of aggressive expansion of the root zone: * Independent of expanding the commercial buoyancy of the DNS industry, how does the addition of many thousands of new gTLDs to the root zone make the Internet better for the people who use it, aside from the addition of IDNs for language and culture? * Using concepts from the disciplines of library and cognitive science, what number of TLDs results in their loss of memorability and significance? * Is adding a significantly large number of TLDs (e.g., more than 100,000) to the root zone, and presumably augmenting the business interests in the addressing system, a sustainable model for the DNS? At what point might this model fail. What next steps for naming system innovation are required, and when? Best Regards Steve Sheng on behalf of Tripti Sinha and Brad Verd Co-Chairs, Root Server System Advisory Committee

4 6

WT4 Call #23
by Rubens Kuhl Feb. 4, 2018

Feb. 4, 2018

Dear WT4 members, The next call for the New gTLD Subsequent Procedures Sub Team – Track 4 - IDNs/Technical & Operations will take place for 60 minutes on Monday, 05 February 2018 at 20:00 UTC, 21:00 Brussels, 20:00 London, 12:00 Los Angeles, 15:00 Washington DC; Tuesday, 06 February 2018 04:00 Singapore, 05:00 Tokyo, 07:00 Sydney. The proposed agenda is as follows: 1. Welcome, SOI updates 2. Review of Technical Services suggestions for additional technical criteria (https://community.icann.org/pages/viewpage.action?pageId=58735969 <https://community.icann.org/pages/viewpage.action?pageId=58735969>) 3. Review of Operations responses for request on CQs (also available at https://community.icann.org/pages/viewpage.action?pageId=58735969 <https://community.icann.org/pages/viewpage.action?pageId=58735969>) 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 <https://community.icann.org/display/NGSPP/4.6.1+Security+and+Stability>) 5. AOB All of the response reviews will include assessment of WG agreement or disagreement, and can lead to tentative consensus calls. Prior reading of the responses is strongly recommended. Adobe Connect room: https://participate.icann.org/newgtldsubteams/ <https://participate.icann.org/newgtldsubteams/> You can connect your audio by following instructions in the pop up in the AC room, or use the Connect Me option that is sent in the calendar invitation. Best, CLO & Rubens

1 0