ICANN ICANN Email List Archives

[gnso-idng]


<<< Chronological Index >>>    <<< Thread Index >>>

RE: [gnso-idng] rethinking IDN gTLDs

  • To: "Eric Brunner-Williams" <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Subject: RE: [gnso-idng] rethinking IDN gTLDs
  • From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
  • Date: Mon, 30 Nov 2009 19:55:35 -0500

Agree Eric.

Chuck 

> -----Original Message-----
> From: Eric Brunner-Williams [mailto:ebw@xxxxxxxxxxxxxxxxxxxx] 
> Sent: Monday, November 30, 2009 7:37 PM
> To: Gomes, Chuck
> Cc: Avri Doria; gnso-idng@xxxxxxxxx
> Subject: Re: [gnso-idng] rethinking IDN gTLDs
> 
> Gomes, Chuck wrote:
> > Eric,
> > 
> > As I know you understand, even if there are no direct costs to 
> > applicants for the failure you cite, the bottom line is that the 
> > application fees could be lower if the evaluation process was less 
> > expensive.
> > 
> > Chuck
> 
> 
> Each application portfolio manager is, in effect, conducting 
> a kind of 
> involuntary resource denial attack on ICANN, and all applicants (its 
> own included), by making the cost of application preparation scale.
> 
> CORE's .cat has kittens. We have contract management, and document 
> management, and ICANN application response management costs, but we 
> have only one and a bunch of fractional costs of actual application 
> preparation, and that's the biggie.
> 
> We'd like to signal to ICANN that "these e-reams of paper crudely 
> nailed together" are one application needing the standard 
> duty of care 
> by the evaluator, and a bunch of edits off of that single application 
> each of which has very limited scope, and for which no standard duty 
> of care by the evaluator is warranted outside of these very limited 
> scopes.
> 
> We like to signal that the consumption of standard complete duty of 
> care units by the evaluator, a limited resources, by the N-1, can be 
> released back to the general resource pool, to be expended on other 
> applications, reducing the cost of the evaluation process.
> 
> Unfortunately, thus far in the DAGvX process, it is ICANN's volition 
> that its evaluation (defense) cost doesn't scale proportional to my 
> application (attack) cost. I can't tell you how frustrating its been 
> explaining that "independent evaluation" of identical applications is 
> only useful, as a question of method, in observing the 
> behavior of the 
> evaluator, that is, as a perversely wasteful form of quality control.
> 
> Which evaluators "pass" .cat's clone? Which "fail" the same 
> application? What is the process utility in that?
> 
> This is why I followed up on the Edmon/Avri exchange. Useful 
> information that would lead to lower evaluation cost if used early, 
> exists in the case of every application brought by an existing 
> registry operator, and more generally, by any multi-application 
> author, where past applications as well as contemporanious 
> applications matter, even applications brought by some, though not 
> all, ccTLD registry operators ({.de, .se} yes, {.ir, .eg} no, as a 
> completely arbitrary example where I know the details), and in 
> particular, applications brought by an ASCII operator for a non-Latin 
> label, or more generally, for any set of applications which meet some 
> "contention" test based upon the assumption that the "contending" 
> applications are independent, not correlated.
> 
> This list's discussion mentioned in passing an area where 
> cost savings 
> are significant, on the order of $1m, perhaps as much as $2m. 
> It isn't 
> unique to IDN application, it just happens to be possible with these 
> applications as with other applications with some characteristics.
> 
> Writing this note has made me aware that some of the ccNSO members 
> have a material interest in the issues before this GNSO centric list. 
> I didn't realize that before this evening, beyond the IDN technical 
> consistency set of issues.
> 
> Eric
> 




<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy