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

[Adrian Kinderis <adrian@xxxxxxxxxxxxxxxxxx>]

My view is somewhat simple Eric. As are most of my thoughts...

No new gTLD (IDN or otherwise) should be launched until they can all go 
together. I see no reason why they should.

Therefore, in my view, IDN ccTLD's can continue on their merry way, fast track 
or otherwise.

This is not simply a negative bit of rhetoric it is my view and I certainly do 
not support any situation that would allow an existing gTLD any further rights 
over anything than what they have now (an oligopoly??)... now you want another 
leg up? Please! . 

I don't get your 'just kidding' stuff but it must be my lack of intellect as I 
often seem to miss the point on your postings. Perhaps if you 'dumbed it down' 
a little I may understand where you are coming from....

Thanks.

Adrian Kinderis
Chief Executive Officer
AusRegistry Pty Ltd
Level 8, 10 Queens Road
Melbourne. Victoria Australia. 3004
Ph: +61 3 9866 3710
Fax: +61 3 9866 1970
Email: adrian@xxxxxxxxxxxxxxxxxx 
Web: www.ausregistry.com.au

The information contained in this communication is intended for the named 
recipients only. It is subject to copyright and may contain legally privileged 
and confidential information and if you are not an intended recipient you must 
not use, copy, distribute or take any action in reliance on it. If you have 
received this communication in error, please delete all copies from your system 
and notify us immediately.


-----Original Message-----
From: Eric Brunner-Williams [mailto:ebw@xxxxxxxxxxxxxxxxxxxx] 
Sent: Wednesday, 3 February 2010 10:36 AM
To: Adrian Kinderis
Cc: gnso-idng@xxxxxxxxx
Subject: Re: [gnso-idng] Picking up where we left off ...

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