RE: [gnso-idng] rethinking IDN gTLDs
Stephane, Please note my responses below. Chuck > -----Original Message----- > From: owner-gnso-idng@xxxxxxxxx > [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of Stéphane Van Gelder > Sent: Tuesday, December 01, 2009 6:45 AM > To: gnso-idng@xxxxxxxxx > Subject: Re: [gnso-idng] rethinking IDN gTLDs > > I would rather request that staff commit to DAGv4 being the > final "draft" and that a definitive applicant guidebook come > out in Q1 2010. Chuck: In my opinion, the timing of a final AG is a separate topic. Certainly any changes recommended between now and a final AG could impact timing but I don't see the issue discussed in the chain of emails below as one that would cause delays. To be realistic though, considering the work remaining on the overarching issues and vertical integration, the soonest I think we will see DAG4 is a few weeks before the Nairobi meeting in March. I also would hope that that is the final DAG but for that to be the case, ICANN Staff and the community has a huge amount of work to do between now and then. Disappointly, DAG3 still had too many huge holes. For DAG4 to be the final DAG, it will have to be fairly close to complete with only minor changes remaining. Assuming DAG4 is the last DAG, then it seems to me the soonest a final AG could be approved by the Board would be in the July timeframe. > > If there are any recommendations to be made, that seems to me > to be the most crucial. > > Of course, we can also continue to debate the finer points of > whether the current DAG is perfect or not, but as it will > never be, I am growing more and more frustrated with detached > philosophical debates the kind of which I have been a witness > to on this thread for the last couple of days. Don't get me > wrong, I have deep respect for the undeniable intelligence > and expertise being displayed in these discussions. It's just > that at this stage, these kind of discussions could result in > suggestions that additions be made to the DAG leading to yet > another can of worms being opened and more delays. Chuck: How to handle confusingly similar strings is not a philosophical issue in my opinion. It relates specifically to the evaluation criteria for one of the 19 GNSO recommendations. > > Stéphane > > Le 30 nov. 2009 à 20:02, Gomes, Chuck a écrit : > > > > > 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 > >> > >> > >> > > > > Attachment:
smime.p7s
|