[Gnso-newgtld-wg-wt4] Registry Services panel evaluation failures

[Rubens Kuhl]

> Em 1 de set de 2017, à(s) 16:36:000, John R. Levine <johnl at 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