Re: [gnso-idng] Picking up where we left off ...

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

Adrian,

I'm aware of your point of view, however, apparently the Board won't 
halt the ccTLD IDN FT, and apparently the Board won't start the new 
applications.
One could view the GNSO Council position of record as a joke, or as 
something serious.
If it is something serious, then within the remaining constraints we 
should be able to find solutions.
I don't think "just kidding" is the better course, that other GNSO 
Council statements are "just kidding" or that when the Council meets 
and makes policy recommendations it is "just kidding".
So I am left with what could the FT and no present application date, 
and perhaps no application date for several years, mean?
Solutions I see are of the form I sketched.

I'm fine with none of them being right, but I suggest you have to do 
more than assert a negative, unless, in your view, the Council was 
just joking, or has been passed by events.
Eric


On 2/2/10 5:47 PM, Adrian Kinderis wrote:
> For what it is worth, I refute the claim that any existing operator 'get' 
> anything at all. They should apply just like anyone else.
>
> Adrian Kinderis
>
> -----Original Message-----
> From: owner-gnso-idng@xxxxxxxxx [mailto:owner-gnso-idng@xxxxxxxxx] On Behalf Of 
> Eric Brunner-Williams
> Sent: Wednesday, 3 February 2010 5:20 AM
> To: gnso-idng@xxxxxxxxx
> Subject: Re: [gnso-idng] Picking up where we left off ...
>
>
> All,
>
> It has been a week since I wrote "Picking up where we left off ...",
> and six weeks and five days since Stéphane's note, the last after
> Edmon cancelled the call scheduled the previous day , so the gnso-idng
> activity is ... not progressing.
>
> As you all should know, requests by Egypt, the Russian Federation, the
> United Arab Emirates, and Saudi Arabia have completed evaluation.
>
> The respective strings are:
>
> .sa xn--mgberp4a5d4ar (variants: xn--mgberp4a5d4a87g,
> xn--mgbqly7c0a67fbc, and xn--mgbqly7cvafr) for "al saudiah",
>
> .eg xn--wgbh1c, the familiar "misr",
>
> .ae xn--mgbaam7a8h, the familar "imarat",
>
> .ru xn--p1ai, the familiar "rf".
>
> Returning to the GNSOC rhetoric that roughly equal in time and sense
> means more than nothing ...
>
> One possibility is each of {VGRS, AF, NS, CORE} get an IDN of their
> choices.
>
> Another is that {VGRS, AF, NS, CORE} get an arabic or a cyrillic IDN.
>
> Another is that {VGRS, AF, NS, CORE} get an IDN sizeof(.sa or .eg or
> .ae), which is to say "small", or an IDN sizeof(.ru), which is to say
> bigger.
>
> Another is that {VGRS, AF, NS, CORE} get an IDN chit that they can't
> (or shouldn't) cash in yet, which they may either conceal until the
> entire ccTLD IDN FT activity discloses all ccTLD IDNs under the FT, or
> they must disclose in stages, e.g., the {SA, EG, AE, RU} set being one
> stage.
>
> These were some of my "what does `roughly equal' (my paraphrase) and
> the ccTLD IDN FT mean" thoughts.
>
> Of course, CORE's initial preference is a Hebrew Script IDN TLD for
> Yiddish, for the same reasons we did a Latin Script ASCII TLD for
> Catalan, to preserve an endangered language.
>
> There are alternate interpretations of the GNSO statements of position
> on IDNs. Avri has pointed out an equity claim for parties not
> currently contracted. Someone could offer a best use claim for the
> currently contracted parties with the largest market share. Someone
> else could offer a competition policy claim for the currently
> contracted parties with the smallest market share, and so on.
>
> CORE's position is that we're fine with the ccTLDs going first. We
> think steady IDN expansion, nor initial market share, is the better
> goal. We also know our view is not widely shared by the other
> contracted parties.
>
> What I've learned during the course of this list is that the
> Overarching Issues, at least the trademarks issue, isn't such a big
> deal for IDN strings are it is for ASCII strings, and with the
> exception of the homographic problem, the rest of the Overarching
> Issues are not as present.
>
> That could be a good thing, if the current DAGv3+ process was able to
> distinguish between IDN applications and ASCII applications, but for
> the present there is no differentiation, and so the relative absence
> of objection to IDN gTLDs is data without significance.
>
> Eric