<<<
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
>>>
|