ICANN ICANN Email List Archives

[gnso-idng]


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

RE: [gnso-idng] rethinking IDN gTLDs

  • To: <gnso-idng@xxxxxxxxx>
  • Subject: RE: [gnso-idng] rethinking IDN gTLDs
  • From: "Mike Rodenbaugh" <icann@xxxxxxxxxxxxxx>
  • Date: Mon, 30 Nov 2009 11:55:37 -0800

I like Chuck's idea, at least it might promote some efficiencies of scale.
Perhaps Staff also can provide an explanation of how the draft policy of 'no
discounts' squares with the GNSO Council recommendation, approved by the
Board, that application fees must be designed only to recover costs.  

Mike Rodenbaugh
RODENBAUGH LAW
548 Market Street
San Francisco, CA  94104
(415) 738-8087
http://rodenbaugh.com 

-----Original Message-----
From: owner-gnso-idng@xxxxxxxxx [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf
Of Gomes, Chuck
Sent: Monday, November 30, 2009 11:02 AM
To: Avri Doria; gnso-idng@xxxxxxxxx
Subject: RE: [gnso-idng] rethinking IDN gTLDs


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





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

Privacy Policy | Terms of Service | Cookies Policy