GNSO IDN Working Group Outcomes Report

[zfreud]

"This is the final version of the GNSO IDN Working Group Outcomes Report. This report provides a written summary of areas of broad agreement, support and discussions of the GNSO IDN-WG on issues for consideration of the GNSO Council regarding further GNSO policy development activities on IDN issues for the generic top level domain (gTLD) space."

http://www.gnso.icann.org/mailing-li...YENXyvv5x7.doc

Let the fireworks begin...

[domainguru]

If anyone here is able to analyze that document and *correctly* interpret what it means for DNAME .... that would be amazing

All I can find so far is:

------
4.1.8. Suggested Approach towards Aliasing:
Agreement to address aliasing as a policy issue, rather than in terms of any specific technical mode for implementation of such a feature.
------

------
4.2.19
Support for the view that aliasing provides protection of and reduce confusion for existing domain name holders, while recognizing that there may also be disadvantages.
Support for the view that aliasing does not alleviate confusion and should be struck from a list of potential solutions.
Note: The same result for domain name holders as aliasing provides could be achieved by normal DNS means. Aliasing per se is not an IDN specific feature, even if aliasing has raised much interest in the IDN context.
------

So 4.1.8 says there is Agreement that aliasing is a policy issue, not a technical one. But 4.2.19 says there is support both for and against aliasing as policy.

So basically, no agreement at all on aliasing. Shall we all meet up again in another few years?

Is there anything else in the document of note? Where does this document go? Taken to the next ICANN meeting so they can fail to agree there as well?

[jacksonm]

You need to read 4.3.3 to get the real meat.

Yes, they are going to proceed with dname. Each application will be subject to IPR claims on the proposed string. But other than that, it looks good.

.

[domainguru]

Originally Posted by jacksonm

You need to read 4.3.3 to get the real meat.

Yes, they are going to proceed with dname. Each application will be subject to IPR claims on the proposed string. But other than that, it looks good.

.

4.3.3 is a summary table.

Why do you say they are going to proceed with DNAME? 4.2.19 clearly states there is support both for and against it.

[zfreud]

My take:

"4.1.7a Agreement that priority rights for new strings on the top-level do not derive from existing strings"

4.1.7a is a loss for .com AKA Verisign.

4.1.8 is a win for Verisign. DNAME will not be voted out on technical grounds.

The policy side, however, seems a pretty tough road ahead. Overall, I think it is becoming more and more obvious that high demand cTLDs (china, japan, etc) will be inserted into the root as NS IDN TLDs and that DNAME, if it arrives at all, is years away.

Also of note for that debate:

"4.2.14
Support for treating existing gTLD registries equally in cases when they apply for IDN gTLD strings.
Alternative view; to consider preferential rules for existing sponsored gTLD registries in the above context. "

[jacksonm]

Originally Posted by domainguru

4.3.3 is a summary table.

Why do you say they are going to proceed with DNAME? 4.2.19 clearly states there is support both for and against it.

That document is some convoluted thing, for sure.

I guess I was wrong.

-
Agreement that priority rights for new strings on the top-level do not derive from existing strings. 4.1.7a
-

I interpret this as saying that e.g. .com can not simply demand any strings which they think mean .com in other languages, but they will have to apply for them the same as any other gTLD.

However, after e.g. .com applies for and receives aliases, they could be inserted into the root as DNAME records. Technically nothing prevents that, it's only a matter of policy if they use a DNAME record or a simple DNS alias record... For the end user, the result would be the same.

IMO, I think DNAME per se as compared to simple aliasing is probably a bad idea. The reason is that the most popular DNS server software "Buggy Internet Name Daemon", or BIND, typically has a hell of a time implementing new record types. As well, the DNS response packet size would increase and cause problems for clients. For all intents and purposes, simple aliases in the root are functionally equivalent and won't cause technical problems.


.

[zfreud]

Just to be clear on one thing. The GNSO is clearly advocating for the respect IP rights when it comes to gTLDs. No surprise there. To interpret that as support for DNAME is a bit of a stretch. Everything in this document points to the fact that any application for an IDN gTLD will have to go throught the standard application process (time consuming and costly).

Verisign will likely fight any attempted application for an IDN gTLD that in any way leans on the english ".com".

That said, if they want to manage IDN gTLDs that reference .com they will have to make applications and get approval for each and every one of them...DNAME or not.

I think Verisign will take the easier route of branding .com as what it already is: a global brand that cuts across language barriers.

[Rubber Duck]

Well it seems to me that this is merely the results of a consultation process whose outcomes are so nebulous either by accident or design that the ICANN Board is effectively left free to implement whichever solution it sees fit.

On balance probably good news. One more stage completed so forward to the next beaurocratic hurdle. In the meantime, the technical teams will be progress with scant regard for any of this.

[domainguru]

Originally Posted by zfreud

I think Verisign will take the easier route of branding .com as what it already is: a global brand that cuts across language barriers.

I understand that view, but I think that would be a huge and costly mistake if VeriSign just settled for ASCII ".com". In 10 years time, Asians will be using IDN.IDN for websites, not ASCII.ASCII or even IDN.ASCII. If VeriSign want their slice of that huge pie, they will have to find a way to be the ".com" registry in Asian languages.

[Rubber Duck]

Originally Posted by domainguru

I understand that view, but I think that would be a huge and costly mistake if VeriSign just settled for ASCII ".com". In 10 years time, Asians will be using IDN.IDN for websites, not ASCII.ASCII or even IDN.ASCII. If VeriSign want their slice of that huge pie, they will have to find a way to be the ".com" registry in Asian languages.

Let me think now. Wasn't DNAME Verisign's idea in the first place? Doesn't that kind of indicate that they feel they might have a vested interested in getting the IDN.IDN aliased into each and every language? Am I missing something here?

[domainguru]

Originally Posted by Rubber Duck

Let me think now. Wasn't DNAME Verisign's idea in the first place? Doesn't that kind of indicate that they feel they might have a vested interested in getting the IDN.IDN aliased into each and every language? Am I missing something here?

Not disagreeing with you. Just replying to a post

[Alphamale]

so, just to cut to the chase...

is this another one of those threads about dname, where we actually havent got a clue what it means and are all just guessing ?

[domainguru]

Originally Posted by Alphamale

so, just to cut to the chase...

is this another one of those threads about dname, where we actually havent got a clue what it means and are all just guessing ?

that's the best analysis yet

[IDNCowboy]

Support for the view that aliasing provides protection of and reduce confusion for existing domain name holders, while recognizing that there may also be disadvantages.

uh oh

[domainguru]

Originally Posted by IDNCowboy

Support for the view that aliasing provides protection of and reduce confusion for existing domain name holders, while recognizing that there may also be disadvantages.

uh oh

We've already pointed out there is both support for aliasing in that paragraph, and support for not aliasing in the next paragraph. i.e. no agreement.

[Drewbert]

Congratualtions to the "open to all" "bottom-up" ICANN for relwasing documents in a non-public file format.

[blastfromthepast]

Originally Posted by zfreud

http://www.gnso.icann.org/mailing-li...YENXyvv5x7.doc

Let the fireworks begin...

Not Found

The requested URL /mailing-lists/archives/council/docYENXyvv5x7.doc was not found on this server.

Anyone care to repost it?

[Giant]

Originally Posted by blastfromthepast

Not Found

The requested URL /mailing-lists/archives/council/docYENXyvv5x7.doc was not found on this server.

Anyone care to repost it?

http://www.gnso.icann.org/mailing-li.../msg03330.html

Then click on the attachment link: GNSO IDN WG Final Outcomes Report.doc