September 2017 - Gnso-newgtld-wg-wt4

Ongoing name collision incident
by Rubens Kuhl Oct. 5, 2017

Oct. 5, 2017

Nothing like real life experience to base policy discussions: there is an ongoing name collision incident in a legacy gTLD. D-Link routers have a default parameter given to local networks the suffix domain.name ; so, names without a full domain name get appended domain.name for its queries. Microsoft operating systems query for the string "wpad" to determine local proxy servers of an organisation. .name is a registry where a domain is required to be first.last.name , with two labels. So... someone registered wpad.domain.name and is now taking over browsing traffic for the affected users, which can be in the order of millions but are least in the thousands. For live view of the redirection process: https://gwhois.org/wpad.domain.name+dns <https://gwhois.org/wpad.domain.name+dns> http://wpad.domain.name/wpad.dat <http://wpad.domain.name/wpad.dat> will return the list of proxy servers under attacker control. (It currently returns this: function FindProxyForURL(url, host) { return 'PROXY 185.82.212.95:8080; DIRECT'; } ) Policy question for the item "name collisions in legacy gTLDs" is whether contracted parties should be obliged to act in a certain way under similar circumstances. Rubens

3 2

- Data Request Response: Name Collision Reports Information
by Steve Chan Oct. 4, 2017

Oct. 4, 2017

Dear WT4 Members, If you’ll recall, WT4 requested additional information for reports of name collisions. Below, please see the requested data elements. Date of report to ICANN Type of TLD where the collision occurred (Single-registrant, Brand, Geo, IDN, Open/Generic, Open/Niche) When and how reporting person detected the collision Affected system (Corporate network, Mobile Application, Web Application, Other-Specify) Registry response (If available) Outcome (to the best of ICANN's knowledge) Attached, please find ICANN Org’s response (and available near the bottom of the Wiki page here: https://community.icann.org/x/Yz2AAw) Best, Steve Steven Chan  Policy Director, GNSO Support ICANN 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094-2536  steve.chan(a)icann.org mobile: +1.310.339.4410 office tel: +1.310.301.5800 office fax: +1.310.823.8649 Find out more about the GNSO by taking our interactive courses and visiting the GNSO Newcomer pages. Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO Follow the GNSO on Facebook: https://www.facebook.com/icanngnso/ http://gnso.icann.org/en/

2 4

Fwd: ICANN Compliance x Name Collisions
by Rubens Kuhl Sept. 21, 2017

Sept. 21, 2017

Steve, Emily, Julie; (sent via WT4 list) Can we ask compliance to drill down the 45 TLDs where they found controlled interruption wildcards still in place per registry service provider ? Not mentioning names of RSPs or ROs, just something like RSP 1 - 32 TLDs RSP 2 - 10 TLDs RSP 3 - 3 TLDs Thanks, Rubens > >> Início da mensagem encaminhada: >> >> De: Rubens Kuhl <rubensk(a)nic.br> >> Assunto: [Gnso-newgtld-wg-wt4] ICANN Compliance x Name Collisions >> Data: 12 de setembro de 2017 21:07:21 BRT >> Para: gnso-newgtld-wg-wt4(a)icann.org >> >> >> https://www.icann.org/en/system/files/files/compliance-update-jun17-en.pdf >> >> At the end of page 3: >> "This quarter, the ICANN Contractual Compliance team also processed referrals from ICANN Technical Services regarding controlled interruption wildcard record violations. Approximately 45 TLDs were found to have activated names (other than nic.tld) in the DNS, while controlled interruption wildcard records continued to exist in their zone file." >> >> It seems a high number of TLDs are still having issues with the 2012-round Name Collision Framework, long after delegation. This specific data point suggests that one of the suggested modifications, having ICANN or an ICANN contractor run the process before the TLD is delegated to the approved applicant, would not only address the time-to-market problem seen by registries but also improve compliance with the framework as designed. >> >> We should note though that this report doesn't mention distribution by registry service provider; all 45 TLDs could share a single back-end for all we know. >> >> >> Rubens >> >> >> >> _______________________________________________ >> Gnso-newgtld-wg-wt4 mailing list >> Gnso-newgtld-wg-wt4(a)icann.org >> https://mm.icann.org/mailman/listinfo/gnso-newgtld-wg-wt4 >

3 3

Attendance, Recording, AC recording, & AC Chat from New gTLD Subsequent Procedures Sub Team Track 4 IDNs/Technical & Operations call on Thursday, 14 September 2017
by Julie Bisland Sept. 14, 2017

Sept. 14, 2017

Dear All, Please find the attendance and recording of the call attached to this email. The Adobe Connect recording and AC Chat are below for the New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations held on Thursday, 14 September 2017 at 20:00 UTC. Adobe Connect recording: https://participate.icann.org/p93vvmmwizf/<https://participate.icann.org/p93vvmmwizf/?OWASP_CSRFTOKEN=00c812ada3468bdb…> 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/ERohB Thank you. Kind regards, Julie ------------------------------- Adobe Connect chat transcript for 14 September 2017 Julie Bisland:Welcome to the New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations on Thursday, 14 September 2017 at 20:00 UTC. Julie Bisland:Agenda wiki page: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Cheryl Langdon-Orr (CLO):of course 40kg+ "puppies have to play wrestle *at* your feet Jon Nevett:Quick question -- why is the IDNs/Technical & Operations WG looking at financial issues? Cheryl Langdon-Orr (CLO):As an Evluation Question it falls to us and WT2 Jon Nevett:ok -- thanks Steve Chan:@Jon, I think the name for the WT could probably be a bit more broad. Here is the Wiki page for this subject: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_x_… Steve Chan:@Trang, I have the PIRR extract if you have any desire to share. Jeff Neuman:Work Track 4 looks at all of the questions in the application Cheryl Langdon-Orr (CLO):Which would mean perhaps an even L O N G E R name for this WT ;-) Alan Greenberg:What slide are we on? Cheryl Langdon-Orr (CLO):bless you Rubens Kuhl:5 Cheryl Langdon-Orr (CLO):slide 5 Steve Chan:If anyone is interested in reviewing the Program Implementation Review Report, Financial Capability Evaluation section, there is an extract here on the Wiki: https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_do… Cheryl Langdon-Orr (CLO):perfect timing STeve ;-) Cheryl Langdon-Orr (CLO):Thank You Trang Cheryl Langdon-Orr (CLO):slide 6 Jeff Neuman:what is it about the financial statements that caused failures? Jeff Neuman:Is it just related to proposed business cases? Jeff Neuman:yes Phil Buckingham:jeff - there was no due diligence . It was ticking boxes according to a " balancing templated model " The template didnt balance . It was standardised for ALL applicants Phil Buckingham:how did they ( evaluators ) deteremine when the application ( rather than the applicant ) was a (not) a going concern Cheryl Langdon-Orr (CLO):it is not a viability or "health" check... Phil Buckingham:exactly Jeff . No applicant could project revenues 5 years out in a brand new market place back in 2012 ! Jeff Neuman:yes Jeff Neuman:thanks Jeff Neuman:So we have to go back to the original 2007 policy which states: Applicants must be able to demonstrate their financial and organisational operational capability. Cheryl Langdon-Orr (CLO):In applicant support situations , support may even be required to present in appropriate language and form , business planning and financials etc. Phil Buckingham:so if there is no financial evaluation then the overall mission statement ( q18) needs to be points scored in terms of financial , technical , operationally capability . This would need to be points scored on an annual basis to check if there are any material changes . Trang Nguyen:or obtaining a certified statement from an auditor... Cheryl Langdon-Orr (CLO):there is a risk of being too US or EU centric on all this though Jeff Cheryl Langdon-Orr (CLO):we always base things on our own experience set of course Phil Buckingham:any certified statement would need to in complaince with US GAAP , since ICANN is a US corporation . This could prove to be very problematic to (say) an African NGO applicant Jeff Neuman:But what is the remification of not passing any of these checks? Jeff Neuman:Of course "passing the checks" has to be defined Jeff Neuman:So you can be awarded the TLD, but not sign a contract? Cheryl Langdon-Orr (CLO):it was a hypothetical small island state of course ;-) Rubens Kuhl:Credit scores are very jurisdiction-dependent... Cheryl Langdon-Orr (CLO):"credit score of [....] or ratifyable alternate" perhaps Jeff Cheryl Langdon-Orr (CLO):ergh typos sorry Cheryl Langdon-Orr (CLO):time check Jeff Neuman:But personally agree that the existing questions and answers did not really assess what it was meant to assess/ Rubens Kuhl:Thanks Trang for joining us today! avri doria:bye. very informative, thanks Julie Bisland:The next New gTLD Subsequent Procedures Sub Team – Track 4 – IDNs/Technical & Operations will take place on Thursday, 28 September 2017 at 20:00 UTC for 60 minutes. Phil Buckingham:+1 Rubens it might work in 1 st world countries . I cant see how this would work in 3 rd world ( potentially more riskier / corrupt ) countries Cheryl Langdon-Orr (CLO):corruption can be a stable financial system Cheryl Langdon-Orr (CLO):Bye all

1 0

Notes and Action Items: New gTLD Subsequent Procedures PDP WG - Track 4 - 14 September 2017
by Emily Barabas Sept. 14, 2017

Sept. 14, 2017

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. Kind regards, Emily ---------------------------------------------------------------------------------------- Notes: 2. SOIs -- No updates 3. Financial Evaluation -- Program Review feedback: -- "Consider whether an alternative approach to the Financial Capability evaluation would be worthwhile." -- CC2 comments are in agreement with this feedback - "Review Financial Capability CQs and responses to determine whether improvements to the application questions can be made." -- From the slides -- if the approach to financial evaluation changes, 2012 questions won't be of much use -- Feedback from ICANN org: -- Financial evaluation from 2012 - -- Criteria didn't recognize different business models, one set of questions for all -- No differences in criteria for TLDs that were cost centers vs. revenue generating TLDs -- Something for the WT to consider - what is the purpose of financial evaluations? -- Set of criteria to see if the applicant understood what evaluators would check financially based on the technical approach proposed. -- Significant number of CQs in the 2012 round that followed up on financial questions -- Did the applicants really understand the financial questions? From the chat: Steve Chan: If anyone is interested in reviewing the Program Implementation Review Report, Financial Capability Evaluation section, there is an extract here on the Wiki: https://community.icann.org/download/attachments/58735969/PIRR_2.7%20Financ…<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_do…> - Threats being addressed: insolvent registry, lack of market performance, parent company extinction or business fine closure, unwillingness to provide financial stantements to contract due diligence, applying for more TLDs than a company can handle - In what other ways can we address those threats: current financials, stock exchange listed companies (but some companies are not profitable, what about startups?) - Another group of applicants that struggled with meeting financial criteria: large orgs that are not publicly traded. They were not comfortable providing financial statements. ICANN had to have a lot of discussions to help them understand the requirements. - All applications passed financial evaluation, but 25 failed the initial evaluation: 2 failed multiple financial and technical questions, 18 failed question 45 (financial statements), 2 open TLDs and 1 brand TLD failed question 50 (contingency planning), 1 geoTLD failed question 48 (funding and revenue). From the chat: Jeff Neuman: what is it about the financial statements that caused failures? Jeff Neuman: Is it just related to proposed business cases? - There are a number of those 25 applicants that failed due to question 45, and eventually decided they did not want to share confidential information in evaluation and felt more comfortable going to extended eval (primarily large companies that are not publicly traded) - Some didn't provide financial statements for the correct period. - Some did not take into acount methodology for evaluating applications, but this is a small number - What did ICANN actually do with those financial statements? Was it a box checking exercise, or did they evaluate the financial health of the applicant? - Q45 criteria - asked for audited financial statement, if no financial history, gave options for other info to provide. Evaluators checked that the criteria for question 45 were met (provision of cash flow, balance sheet, etc for the correct period). - What if the company provided the requested information, they follow correct accounting practices, but it showed poor financial health. Would this be evaluated? - If there is a concern that was flagged by the auditor, this would trigger a clarifying question. - Audited financials do reflect if the company could take on the additional business. There was not evaluation to see if the company was stable enough to handle a new gTLD. Is that accurate? Yes. There was not financial due diligence. Financial evaluation does not evaluate business models. From the chat: Phil Buckingham: jeff - there was no due diligence . It was ticking boxes according to a " balancing templated model " The template didnt balance . It was standardised for ALL applicants Phil Buckingham: how did they ( evaluators ) deteremine when the application ( rather than the applicant ) was a (not) a going concern - There was no evaluation of projections in Q46, and whether those align with the business model. - Funding and cost questions looked at projections template to see if there was adequate projected funding to align with proposed technical infrastructure provided. - Question 46 - What guide did evaluators use to evaluate whether applicant can cover costs? Is it just based on the information the applicant provides? - In the technical section of the application, the applicant provided information about the infrastructure they planned to use. Evaluation checked that there is alignment betweeen financial calculations and infrastructure proposed. - Evaluators were taking the projections on registrations the applicant expected to generate and made sure that it aligned with other information provided in the application on costs and funding. - Straw person proposal: "No need to do any financial evaluation as part of the application process. ICANN Org would be allowed to evaluate any financial information deemed appropriate as required by usual corporate governance before contract signing (like OFAC regulations and credit reports). Applicants will be provided in AGB a non-exhausive list of likely documents to be required as part of the contracting process, if they succeed in their applications." From the chat: Jeff Neuman: So we have to go back to the original 2007 policy which states: Applicants must be able to demonstrate their financial and organisational operational capability. - The straw person would be a change to the 2007 policy. - By not evaluating financials, we don't deliver on a mentioned goal of potentially blocking speculation through financial analysis, but was it possible to implement this in the first place? - But we do streamline the process and provide fairness among applications. - There is a precedent for self-assessment in other industries. - Could this decision suggest an application fee floor or applicant support design when WT1 and WT4 proposals are combined? From the chat: Cheryl Langdon-Orr (CLO): In applicant support situations , support may even be required to present in appropriate language and form , business planning and financials etc. Phil Buckingham: so if there is no financial evaluation then the overall mission statement ( q18) needs to be points scored in terms of financial , technical , operationally capability . This would need to be points scored on an annual basis to check if there are any material changes . - Eliminating financial evaluation may not be accepted by some members of the community. Are there alternatives that we could propose? Ususally there are ways to ensure that the group you are doing business with is financially stable –such as credit reports, financial/credit evaluation firms, and other measures. To what extent are these tools the same/different in different countries. The idea of eliminating financial evaluation completely is difficult to swallow. Getting rid of the 2007 policy completely will likely not be acceptable to many. From the chat: Trang Nguyen: or obtaining a certified statement from an auditor... Cheryl Langdon-Orr (CLO): there is a risk of being too US or EU centric on all this though Jeff Cheryl Langdon-Orr (CLO): we always base things on our own experience set of course - Straw person does not prevent ICANN from asking for information, such as credit checks, but this would not be part of the application and evaluation process. From the chat: Phil Buckingham: any certified statement would need to in complaince with US GAAP , since ICANN is a US corporation . This could prove to be very problematic to (say) an African NGO applicant Jeff Neuman: But what is the remification of not passing any of these checks? -Ramification would be not getting a contract. From the chat: Jeff Neuman: Of course "passing the checks" has to be defined Jeff Neuman: So you can be awarded the TLD, but not sign a contract? - We need to look at something allows appropriate flexibility and meaningful results while supporting stability. - ICANN regional hubs may be able to provide information about local norms. It would be good to allow greater flexibility in terms of the information provided to accomodate different norms. - If ICANN is going to look at credit reports, they should state it up front in the AGB along with the standard it is going to apply to make its determination. Not convinced that ICANN shouldn't ask for this info in the evaluation process if this is going to be part of the process, even if it is just a box-checking exercise. From the chat: Rubens Kuhl: Credit scores are very jurisdiction-dependent... Cheryl Langdon-Orr (CLO): "credit score of [....] or ratifyable alternate" perhaps Jeff Jeff Neuman: But personally agree that the existing questions and answers did not really assess what it was meant to assess Phil Buckingham: +1 Rubens it might work in 1 st world countries . I cant see how this would work in 3 rd world ( potentially more riskier / corrupt ) countries 5. AOB -- None

1 0

Registry Services straw-person
by Rubens Kuhl Sept. 14, 2017

Sept. 14, 2017

Hi all. Based on our call today, this is a new straw-person to base our discussion on Q23 (Registry Services): "Applicants will be allowed but not required to specify additional registry services. List of previously approved registry services (IDN Languages, GPML, BTPPA) to be included by reference in AGB and contract. If applicant informs additional registry services, applicant will specify whether it wants it evaluated thru RSEP at evaluation time, contracting time or after contract signing, acknowledging that exception processing in evaluation or contracting could incur additional application fees. If applicant has not informed additional registry services, RSEP will only be available after contract signing. " Rubens

7 33

Apologies
by Martin Sutton Sept. 14, 2017

Sept. 14, 2017

Unfortunately, Thursday’s clash with my evening college course, so I will be unable to join today’s call. Please accept my apologies. Kind regards, Martin Martin Sutton Executive Director Brand Registry Group martin(a)brandregistrygroup.org<mailto:martin@brandregistrygroup.org>

2 1

ICANN Compliance x Name Collisions
by Rubens Kuhl Sept. 14, 2017

Sept. 14, 2017

https://www.icann.org/en/system/files/files/compliance-update-jun17-en.pdf <https://www.icann.org/en/system/files/files/compliance-update-jun17-en.pdf> At the end of page 3: "This quarter, the ICANN Contractual Compliance team also processed referrals from ICANN Technical Services regarding controlled interruption wildcard record violations. Approximately 45 TLDs were found to have activated names (other than nic.tld) in the DNS, while controlled interruption wildcard records continued to exist in their zone file." It seems a high number of TLDs are still having issues with the 2012-round Name Collision Framework, long after delegation. This specific data point suggests that one of the suggested modifications, having ICANN or an ICANN contractor run the process before the TLD is delegated to the approved applicant, would not only address the time-to-market problem seen by registries but also improve compliance with the framework as designed. We should note though that this report doesn't mention distribution by registry service provider; all 45 TLDs could share a single back-end for all we know. Rubens

3 4

Financial evaluation failures
by Rubens Kuhl Sept. 1, 2017

Sept. 1, 2017

25 applications failed financial evaluation criteria; of those 25, 3 also failed technical evaluation. Of those 3, 2 were multiple questions failures (3 questions in one application, 5 questions in another). Even removing those 2 that are more like generalized issues, there were: - 18 applications that failed Q45 (Financial statements) - 3, 2 being open TLDs from the same applicant and 1 brand TLD, applications that failed Q50 (Contingency planning) - 1 GeoTLD application that failed Q48 (Funding and revenue) Comments on those: Q45: Clearly the worst offender of financial evaluation. Something to be discussed in more detail in our next call. Q48: Possibly just an applicant that refrained from providing wild guesses on financials. That GeoTLD currently has 14k registrations with no history of giving domains for free/cheap, so it's probably better than a good number of other TLDs that are still losing money. Q50: The Brand TLD that is already a cost center instead of a revenue line probably failed it in a way similar to Q45 (lack of declaration from officers committing X amount of money). The Open TLD applicant is a curious issue; I'll try asking that applicant if he is willing to provide the full text of the answer. Rubens

1 0

Re: [Gnso-newgtld-wg-wt4] Registry Services panel evaluation failures
by Rubens Kuhl Sept. 1, 2017

Sept. 1, 2017

> Em 1 de set de 2017, à(s) 16:36:000, John R. Levine <johnl(a)iecc.com> escreveu: > >> Comment: this is was an overreach from the panel. Such stability measures that prevent domain registrants from changing to configurations that will make their domains inaccessible are in use in a bunch of TLDs, including TLDs with millions of registrations like .cz and .br. The full text that led to failure is from a non-public response on DNSSEC, and many other applications from the same back-end passed evaluation. This both indicates the panel looking in duplicity questions that were evaluated by the technical panel, and lack of consistent evaluation. > > Remember what I said about cut and paste errors? Fair enough about my last sentence. Consistency failures could come from applicants not doing ctrl+c ctrl+v correctly and from evaluation. But the reason for the failure is still pretty clear as an overreach, and also goes to disenfranchising innovation: since most TLDs don't care about registrant DNS configurations, the ones that do are bullied into not doing it. > >> 1-1155-50524 >> >> "The Registry Services Evaluation Panel was not able to determine whether your proposal to offer Internationalized Domain Name (IDN) registrations would raise significant Security and Stability issues as described in Section 2.2.3.1 of the Applicant Guidebook (AGB). Yourapplication (including Clarifying Question and Outreach responses) did not provide sufficient information concerning IDN registration policies, variant management policies, and resourcing plans in accordance with the criteria of Question 44 in the AGB. Yourapplication is eligible foran Extended Evaluation as described in Section 2.3.3 of the AGB." >> >> Comment: IDN question was an optional question, and by answering to it, the panel failed an application for a question that was not required. Considering we already made good progress in IDN evaluation, by incorporating LGRs (Label Generation Rules), whether this could occur or not again is yet to be seen. > > There were a lot of screwed up IDN profiles. I don't remember the details. That's why ICANN required all IDN info again at contract signing... but this one was curious that an optional feature made it fail. If an optional feature is not adequately implemented, just that feature should be removed... the only case where I see IDN services as mandatory are in IDN TLDs. We could add that to the IDN proposed language. Anyway, since IDN evaluation will be totally different, perhaps one future program review could look into whether the planned change was successful or not. Rubens

1 0

Technical evaluation failures
by Rubens Kuhl Sept. 1, 2017

Sept. 1, 2017

Of the 8 applications that failed initial evaluation in technical section, 4 failed due to multiple technical evaluation questions, and 3 of those 4 also failed financial evaluation. In these 4 multiple-questions failure there are some brand TLDs who didn't grasp the concept of operating a registry instead of operating DNS services for a domain and one applicant that just didn't respond to CQs in time. Of the 4 that failed due to a single question, there were: Q28 (Abuse prevention and mitigation): Applicant submitted a change request, but Q28 was not updated in line with that change request. Q31 (Technical overview of the registry): Not disclosed in the report what was the failure Q35 (DNS service): Not disclosed in the report what was the failure Q40 (Registry Transition): Insufficient information in response to CQs Questions 31, 35 and 40 and the applications that failed multiple questions are likely addressed by RSP program; the only question that from the IE reports could deserve some attention is about abuse prevention and mitigation. At the time AGB was create there were no PICs; abuse measurement were after the fact included as Spec 11 3b. We have two paths we can go here: 1) Considering Spec 11 3b and Spec 6 item 4 (Abuse Mitigation) as superseding what was meant to be obtained by Q28 2) Considering that Q28 is still relevant Preferences between those two ? Note that even outsourced registries do not have to outsource abuse mitigation to the same provider; that could be a different provider. Rubens

1 0

Registry Services panel evaluation failures
by Rubens Kuhl Sept. 1, 2017

Sept. 1, 2017

Two applications failed initial evaluation due to registry services panel: 1-1155-50524 and 1-2090-26288. These are the evaluation results for them: 1-2090-26288 "Registry Services Eligible for Extended Evaluation Yourapplication (including Clarifying Question and Outreach responses) did not provide sufficient information concerning DNSSEC policies for the Registry Services Evaluation Panel to determine whether or not your proposal to disallow the prepublication of registrant DS records with no matching DNSKEY on the child would raise significant Security and Stability issues as described in Section 2.2.3.1 of the Applicant Guidebook (AGB). Yourapplication is eligible foran Extended Evaluation as described in Section 2.3.3 of the AGB." Comment: this is was an overreach from the panel. Such stability measures that prevent domain registrants from changing to configurations that will make their domains inaccessible are in use in a bunch of TLDs, including TLDs with millions of registrations like .cz and .br. The full text that led to failure is from a non-public response on DNSSEC, and many other applications from the same back-end passed evaluation. This both indicates the panel looking in duplicity questions that were evaluated by the technical panel, and lack of consistent evaluation. 1-1155-50524 "The Registry Services Evaluation Panel was not able to determine whether your proposal to offer Internationalized Domain Name (IDN) registrations would raise significant Security and Stability issues as described in Section 2.2.3.1 of the Applicant Guidebook (AGB). Yourapplication (including Clarifying Question and Outreach responses) did not provide sufficient information concerning IDN registration policies, variant management policies, and resourcing plans in accordance with the criteria of Question 44 in the AGB. Yourapplication is eligible foran Extended Evaluation as described in Section 2.3.3 of the AGB." Comment: IDN question was an optional question, and by answering to it, the panel failed an application for a question that was not required. Considering we already made good progress in IDN evaluation, by incorporating LGRs (Label Generation Rules), whether this could occur or not again is yet to be seen. What is clear to me that lack of a concrete line between the registry services panel and the technical evaluation panel is likely an issue. Registry services are the "what" and technical infrastructure is the "how", and mangling the two is something to be avoided. Rubens

1 0

Initial Evaluation Reports
by Rubens Kuhl Sept. 1, 2017

Sept. 1, 2017

Hi there. Policy staff provide a nice tool for us to understand what led to initial evaluation failure on the 35 applicants that did; the attached spreadsheet contains that information. Summary: - 2 failures due to registry services panel - 3 failures due to geographic names panel (and so it's not in our plate) - 8 failures in technical evaluation - 23 failures in financial evaluation I'll be dissecting each of the 3 in our scope (registry services, technical, financial) in later messages. Rubens

1 0