RE: [gnso-idng] rethinking IDN gTLDs

["Gomes, Chuck" <cgomes@xxxxxxxxxxxx>]

Maybe we should suggest that the Staff implementation team add a
specific request in DAG4 that applicants identify portions of their
application that duplicate other applications submitted.

Chuck 

> -----Original Message-----
> From: owner-gnso-idng@xxxxxxxxx 
> [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Avri Doria
> Sent: Monday, November 30, 2009 1:50 PM
> To: gnso-idng@xxxxxxxxx
> Subject: Re: [gnso-idng] rethinking IDN gTLDs
> 
> 
> hi,
> 
> good points. 
> 
> A couple of questions:
> 
> 1- could not the writer of these 10 application include a 
> standard paragraph in all of them stating the similarity and 
> relationship you mention and other other advice you think 
> worth mentioning.  I have not checked, but is there, a 'any 
> other irrelevant Information' questions blank.  Any 
> application should have one of those.
> 
> 2- is there a necessary connection between applications using 
> a template and filled in by the same authors having the same 
> consideration and review aspects?
> 
> I do apologize for still looking at these issues from the 
> perspective of someone who is not working on an application - 
> in other words purely theoretically.  Out of curiosity, are 
> there others in this group who are similarly 'uninvolved'?
> 
> a.
> 
> 
> On 30 Nov 2009, at 12:29, Eric Brunner-Williams wrote:
> 
> > Avri Doria wrote:
> >> hi,
> >> Would/could  this not be dealt in the extended evaluation 
> stage where one requests an extended review of the rejection 
> on the basis of Confusing Similarity because there is no risk 
> of adverse effect?
> > 
> > 
> > At Sydney, ICANN's consultant on a portion of the 
> evaluation process had breakfast with Werner and I. We 
> explained that as the authors of several similar 
> applications, we thought it likely that evaluation of similar 
> applications with no knowledge available to the evaluators 
> that some applications had a common property -- like 10 lines 
> of total difference between all of the applications sharing a 
> common authoring property, that is, a scaling property 
> available to the author, would miss the scaling property 
> available to evaluators.
> > 
> > In a nutshell, I can write 10 applications for very little 
> more than the cost of 1 application, where the requirements 
> are equal. If the evaluator is unable to discover the 
> similarity of the applications, the cost of the evaluation 
> must be closer to 10 times the cost of evaluating one 
> application than to one times the cost of evaluating one application.
> > 
> > My point is that it matters where in the application 
> process information is available to the evaluator.
> > 
> > Concealing the similarity, or the process being so stupid 
> that the information is not used by the evaluator, of .foo 
> and .bar, leads to higher costs (cost includes time) to the 
> evaluation process.
> > 
> > So, to place the utility of the discovery that, say, VGRS 
> is applying for .mumble and .momble (invent your favorite IDN 
> to IDN or IDN to ASCII similarities here) in the 
> failure-extended-review-request sequence creates avoidable cost.
> > 
> >> Or do you think it should be a complicating factor in the 
> initial evaluation?  Do we need a stmt somewhere in the doc 
> allowing for this possiblity?
> > 
> > 
> > Please see the point Werner and I tried to get across to 
> the KPMG person. What you suggest is a "complicating factor" 
> seems to me to be major cost and complexity savings for the evaluator.
> > 
> > Seriously, I've a score of linguistic and cultural apps 
> that I expect to differ by a few pages over a significant 
> fraction of a ream each. What is the rational basis for 
> concealing the common case and a score of 10 page changes off 
> that common case, from the evaluator?
> > 
> > If no rational basis, other than the desire to spend more 
> applicant monies on repeated evaluation of the same 
> application, exists, than what rational basis is there, other 
> than the same caveat, from knowing ab initio, that some two 
> or more applications have a relationship with each other, and 
> that mutually ignorant evaluation is the least useful course 
> of action possible.
> > 
> > We shouldn't be designing the least efficient system imaginable.
> > 
> > Eric
> 
> 
>