Re: Process forward [RE: [gnso-idng] restarting discussions on IDN gTLD]

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

Mike Rodenbaugh wrote:
> Thanks Eric.  I do not want to get into defining 'single-registrant TLD' or
> estimating market demand. I am just pointing out that, if there is some
> consensus that various tracks might be desirable, there is certain to be a
> huge debate about prioritization.  I recall this was recognized long ago,
> when I first got formally involved in the new TLD PDP (a 'Task Force'
> meeting in MDR), and ultimately was embodied in the GNSO's policy
> recommendations which did not include any sort of silos or other
> prioritization scheme.  

Mike, I'm surprised today to find 5 figures worth of registrations 
within a "single-registrant" RFP, so I'm sure that defining what a 
"single-registrant" application is, is something reasonable people 
could differ on.
On the volume of applications however I think you've a duty to dot the 
last eye and cross the last tee. If, as a queuing problem, which I'm 
sure exist in business logic, not just computer science scheduler 
problems, there are two queues, and one queue may be unbounded, and 
the other queue is bounded, than a queue service routing that serves 
the unbounded queue before the bounded queue will never serve the 
bounded queue.
So in ordering the single-registrant, for which we can't be certain is 
bounded below whatever number Thomas Narten's conjectured volume of 
root zone change events in a year, or ICANN application window, before 
community-based applications, for which CORE's knowledge suggests is 
for the bounded below that limit, you've potentially created an 
ordering that will never serve a known, finite set of applications, 
but will serve an unknown, significantly larger, set of applications.
Now if you think "it can't happen", that's OK. At some point, and I've 
no idea how many meetings hence, the numbers of applications visiting 
each decision point in the evaluation process will be public 
knowledge. Perhaps it will have happened, perhaps it won't.


> The later Council resolutions were dealing with differing tracks between
> gTLDs and ccTLDs, not differing tracks within gTLDs.  The Council was
> addressing a situation it could not control, with ccTLDs, rather than any
> situation purportedly within GNSO's policy ambit.

I appreciate that the Council was addressing a situation it could not 
control -- as otherwise I suspect that there would be no "ccTLD IDN 
FT" at all, or a "ccTLD IDN PDP" that Edmond and I suppose I hope to 
coordinate in a cc+g context so that consistency, and synchronous 
availability goals can be met as well as circumstances allow -- but 
what does the 31 July '08 language mean if it means anything at all?
Thanks for you time Mike,
Eric