Tina Dam answers: Are existing gTLDs going to be aliased to IDN extensions or not? [Archive] - IDN Forums

bwhhisc

21st February 2008, 11:20 PM

Comment by Alias
2008-02-21 11:36:34
Hi, What can you say about aliasing? Are existing gTLDs going to be aliased to IDN extensions or not?

2008-02-21 15:33:13 by Tina Dam:
Hello Alias, this is difficult to answer and might end up being different for the various TLDs. Let me try and see if this explanation helps.

In the policy work related to IDN gTLds it was determined by the community that just because a company is the registry operator for a gTLD today is not the same as saying that it will have pre-rights to all or any translated or transliterated versions of that TLD. However, as part of the process for introduction of new gTLds there is also an objection based process. As such if someone applies for a certain string others can object to it on ground of for example “confusability” with the existing string. So one can imagine a situation where a .tld is tranlated into another language, represented by a corresponding script and applied for in the process. If it is not the same operator then the current operator of .tld could possible make an objection.

Now that said, of course current gTLD operators can also decide right away to apply for a translated string and to operate that as an aliasing to the exisiting one.

So in other words untill we see applications i cant tell what it will be.

Tina

**she typed offcourse, but I think she meant "of course" so I changed it to those words just before the bold words.

sunsei21

21st February 2008, 11:30 PM

hmm so the ball is in verisigns court?

rhys

21st February 2008, 11:50 PM

No comment on the ccTLD policy?

bwhhisc

22nd February 2008, 12:40 AM

No comment on the ccTLD policy?

Rhys, you can ask her that question directly on this thread:

http://blog.icann.org/?p=276#comments

zfreud

22nd February 2008, 01:51 AM

touchring

22nd February 2008, 02:17 AM

Touchring: "Yeah, what's First Grade about?"

bwhhisc

22nd February 2008, 07:28 AM

"Hello this is Verisign"

"Hi, this is IDNForums Aliasing expert, Blastfromthepast. I'd really like you to alias .com and .net"

Verisign: "Well Blast, this was of course the entire point to our sponsoring the DNAME proposal. And as we're sure you are aware, it isn't our decision whether we are allowed to alias .com and .net"

Blast: "Right. But you don't understand. I really know what I am talking about. And I want you to alias .com and .net. So do my fellow IDN Forum members."

Verisign: "Blast, you need to go to Google and search for the following: "DNAME" "gTLD" "ccTLD" "First Grade"

Blast: "First Grade? What's that? Can you alias that too?!"

Where did Blast's post go??
How do you make posts entirely disappear?

************************************
************************************
Back to ICANN Blog...
Next question up on the block...waiting for answer from Tina Dam

Comment by sean
2008-02-21 18:18:23
Tina,

Can you clarify what you mean buy a current gTLD operating a new string as “an aliasing to the existing one”?

Do you mean:

1: The given registry will somehow “alias” the new IDN gTLD to an existing latin TLD so that typing one domain name + gTLD automatically directs to the same location as the other gTLD? My understanding is this solution (whether DNAME or equivalent) would require further ICANN testing, approval, etc.

2: The registry will effectively grant registrants in one gTLD the same domain in the IDN gTLD. In this scenario it would be the registrant who decides whether the domains “alias” or not as they would decide if they should point to the same location. This scenario would not need the approval of anyone.

Comment by sean
2008-02-21 18:25:26
In rereading my comment i realize it might be confusing.

To avoid confusion, and purely as an example:.

let’s say that Verisign applies for and is granted a hanzi equivalent of .com. For arguments sake we’ll call this “.公司”

Are you saying Verisign can then somehow choose to alias these domains so that

existingdomain.com

points to the exact same location as

existingdomain..公司

without any intervening technology? (i.e. DNAME)

or, are you saying Verisign can choose to grant the stakeholder in “exsitingname.com” the domain “existingdomain.公司”. This would effectively alias the domain (assuming the registrant pointed them to the same location) without any new technology, ICANN approval, etc. END QUOTE

Jay

22nd February 2008, 08:53 AM

All credit to Alias and Sean (whoever they are) for moving this discussion on. Tina's response to Alias' question was very vague, so hopefully she'll clarify some more about this.

jacksonm

22nd February 2008, 08:57 AM

All credit to Alias and Sean (whoever they are) for moving this discussion on. Tina's response to Alias' question was very vague, so hopefully she'll clarify some more about this.

Alias raises hand.

.

touchring

22nd February 2008, 09:05 AM

jacksonm

22nd February 2008, 09:21 AM

touchring

22nd February 2008, 09:55 AM

This is exactly what I said a week or so ago and was insinuated to be an idiot!!!

.

Come on. What do you expect sellers to say? ;)

Everything is within our expectations. No free lunch.

yanni

22nd February 2008, 10:00 AM

What's the ICANN fee? 60 cents?

ala101

22nd February 2008, 10:05 AM

What's the ICANN fee? 60 cents?
ICANN fee is 20 cents per domain name year.

yanni

22nd February 2008, 10:24 AM

ICANN fee is 20 cents per domain name year.

We're safe, then :)

555

22nd February 2008, 10:41 AM

"current gTLD operators can also decide right away to apply for a translated string and to operate that as an aliasing to the existing one."

What are the possible oppositions to that?
Since it is verisign's proposal for dname, now that the above was said, what is holding verisign to do just that?

Rubber Duck

22nd February 2008, 10:58 AM

Tina's response is already very clear, there will be no aliasing from ICANN. If verisign wants to alias, and give free domains to .com holders, it's their own biz. But mind you, ICANN fee still has to be paid!!

Bottomline -> no free aliasing.

Where has this been said?

Are you just making this up as you go along?

This is exactly what I said a week or so ago and was insinuated to be an idiot!!!

.

And you still are an idiot because you are just basing your assumptions on Touchrings ramblings.

Aliasing within the root cannot be done a case by case basis. That would have to be done within the backend at the Registry.

If it is done this way then sometimes aliases would work and sometimes they wouldn't. This would effectively break the root in a bigger way than anything that IDN might have been conjectured to do so far, even by its most unhinged critics! The big difference of course would have to be that this particular piece of DNS vandalism would have to be sanctioned by the ICANN Board.

Frankly, I would get more sense out of Homer Simpson!

jacksonm

22nd February 2008, 11:32 AM

Sorry, I just ate a huge pizza for lunch. I can't take any of your bait :-)

.

zfreud

22nd February 2008, 01:43 PM

Rubber Duck

22nd February 2008, 01:49 PM

Come on. If we are going to attempt to discuss this we need to get a few facts straight and tighten up on our terminology.

First.

Verisign cannot and won't allocate TLDs to anyone. Only ICANN can do that.

The other thing that occurs to me is that whilst the C Name protocol obviously exists in the Registry Servers, whether or not they have the authority to use it in this way must be covered by their Registry Agreement with ICANN. I think this would have to go through the ICANN swamp, and as yet they have not even got their boots wet.

Also if this was their master plan, why bother putting forward the DNAME proposal. Just doesn't make sense!

Explorer

22nd February 2008, 02:01 PM

RE: "If verisign wants to alias, and give free domains to .com holders"

yes, but this is NOT aliasing by registry. This is simply granting new TLDs to existing verisign clients who can then choose, or not, to point their domains to the same location. Meaning this would allow for client side aliasing, or CNAME. Which is obviously already an established protocol.

True aliasing, whether via DNAME or some other method, requires support in a zone’s authoritative server. Any solution like that will need to march through the ICANN swamp.

This is why I keep saying: new space idn TLDs are a foregone conclusion at this stage.

Which leaves a pretty messy IP landscape ahead. I think it is also open to debate whether Verisign opts to grant existing IDN.com stakeholders the equivalent domain in whatever foreign script. There are arguments from a profit perspective for and against doing that. And we all know that when it comes to Verisign, profit will be what drives the decision making process.

But if they do give exsiting IDN.com stakeholders access to the equivalent IDN.IDNcom what do you think the odds are that Verisign would give those new TLDs away for free? If you say zero, you're getting warm.

I might be wrong, but I think the majority of IDN holders will gladly pay what Verisign asks (shouldn't be more than a reg fee, no?) to get the equivalents of their IDN .coms. Would you pay $8 to get realestate.ком if you had realestate.com in Russian? You bet. So, if this is the case, then the whole discussion about “will we get it for free or will we have to pay” is pretty meaningless, in my opinion.

At this stage of the game, in my view, the ball is in Verisign’s court. So, interested parties should be commenting/lobbying/trying to get more color out of/inviting to discuss/blogging about/ Verisign.

zfreud

22nd February 2008, 02:08 PM

RE: "Verisign cannot and won't allocate TLDs to anyone. Only ICANN can do that."

Duck, you misunderstood me. Obviously Verisign would need to apply to ICANN for any IDN gTLD for and be granted said IDN gTLD. After that, however, of course Verisign may choose to allocate this new gTLD to their existing clients if they felt it made business sense. For example, if they apply for and are granted multiple foreign script 'equivalents' of .com. Will they then leave the existing IDN.com holders holding the bag (foreign script .com is a different space entirely) or will they grant (or give first crack at) those existing IDN.com holders the foreignscript .com?

RE "The other thing that occurs to me is that whilst the C Name protocol obviously exists in the Registry Servers, whether or not they have the authority to use it in this way must be covered by their Registry Agreement with ICANN."

Again, no one will need the authority here? Verisign doesn't have to do anything. They can leave it up to the domain name holder. If you want to point IDN.com and IDN.IDNCOM to different places, that will be your choice.

RE: "Also if this was their master plan, why bother putting forward the DNAME proposal. Just doesn't make sense!"

This wasn't their master plan. Battlefields change all the time. DNAME was clearly a solution that favored Verisign and as such they pushed. I think they've lost that battle and are now putting their efforts into securing new space .com equivalents in foreign script that aren't disadvantaged by fast track ccTLDs. I think they're going to lose that battle as well, but that's another story.

And Explorer, I agree with you whether one has to pay the additonal fee is meaningless. What is meaningful however is whether Verisign chooses to treat their inevitable new IDN gTLDs as brand new, or as equivalent to existing idn.com registrations. meaning, there isn't much stopping them from saying that idn.com is different from idn.idncom

As for the ball being in Verisigns court....I see the ball being in CNNICs court.

Rubber Duck

22nd February 2008, 02:10 PM

Yes, and of course for Cyrillic you are only going to get .ком and if the ASCII dot Com isn't getting little or no traffic, you would just dump it. So would they actually gain very much? What would be the point, except to greatly devalue their major brand.?

I might be wrong, but I think the majority of IDN holders will gladly pay what Verisign asks (shouldn't be more than a reg fee, no?) to get the equivalents of their IDN .coms. Would you pay $8 to get realestate.ком if you had realestate.com in Russian? You bet. So, if this is the case, then the whole discussion about “will we get it for free or will we have to pay” is pretty meaningless, in my opinion.

At this stage of the game, in my view, the ball is in Verisign’s court. So, interested parties should be commenting/lobbying/trying to get more color out of/inviting to discuss/blogging about/ Verisign.

Jay

22nd February 2008, 03:21 PM

Just to ward off another argument over aliasing based merely on speculation, can I point out that Tina Dam was only presenting the notion of operators doing their own aliasing as one possibility already available. It's hard to tell from her comments if ICANN have discussed this and agree to it in principle, or if it's just an idea that she is passing along out of interest and that ICANN might consider this if an operator applies to do it. This is what I mean by her comments being vague.

As for aliasing using DNAME, she has definitively stated in her blog (http://blog.icann.org/?p=261) that ICANN have not yet made a decision about this. What I'm hoping is that she gives some sort of indication of where that decision-making process is at. Has it been put on the backburner, is it a few weeks away, have they given up? Hopefully we can get some sensible discussion about this on the blog and find out where ICANN are at.

Fka200

22nd February 2008, 03:51 PM

This is OLD NEWS. I mentioned this before!

Jay

22nd February 2008, 05:52 PM

This is OLD NEWS. I mentioned this before!

I know, but I fear people have forgotten. By the way, here's the latest from Tina Dam in response to "Sean":

"I am saying that it could be either one. It is important to talk about alaising and what functionality is really meant behind it. This is what the policy development bodies are doing today. Then once the policy is decided and the term defined then we can talk about what technical solution can provide that function. DNAME has been reviewed a few times as a potential solution to aliaising, but as you point out with your examples, it depends on how one defines aliasing."

In other words, nothing is decided, and she doesn't know what will be proposed (as she's not involved in the policy area). Oh well, it was worth asking.

Rubber Duck

22nd February 2008, 05:57 PM

DNAME is still live. Latest draft 5 Feb 2008, as I have repeatedly posted. But clearly most people on here either can't or just don't read.

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-09.txt

Tina has NOT stated that Registries may do back-end Aliasing. These are merely totally unsubstantiated assertion mostly from Touchring and Michael Jackson. Her comments are vague and frankly are much more likely to refer to Aliasing within the Root Zone which has previously been discussed at IDN workshops.

In the meantime, if you have no fact to report, can we just avoid trying imagine scenarios and then peddling them as done deals?

Just to ward off another argument over aliasing based merely on speculation, can I point out that Tina Dam was only presenting the notion of operators doing their own aliasing as one possibility already available. It's hard to tell from her comments if ICANN have discussed this and agree to it in principle, or if it's just an idea that she is passing along out of interest and that ICANN might consider this if an operator applies to do it. This is what I mean by her comments being vague.

As for aliasing using DNAME, she has definitively stated in her blog (http://blog.icann.org/?p=261) that ICANN have not yet made a decision about this. What I'm hoping is that she gives some sort of indication of where that decision-making process is at. Has it been put on the backburner, is it a few weeks away, have they given up? Hopefully we can get some sensible discussion about this on the blog and find out where ICANN are at.

zfreud

22nd February 2008, 06:36 PM

Could someone please explain to me how a registry could do back end aliasing? Without inserting code into the root servers, no registry can on their own alias anything. As Duck would say, let's stop talking rubbish.

Nothing is going into the root without ICANN approval, whether it be new space IDN TLDs or the code necessary to make DNAME aliasing work. And while DNAME is still being worked on as a technical standard, and may indeed one day see the light of day, it will be long after ccTLDs have been inserted as new space records.

That, obviously is conjecture based on a cool look at the landscape at present and where we all seem to be going... But then so is my belief in IDN.com.

Rubber Duck

22nd February 2008, 06:42 PM

Well Verisign almost certainly have the capability to do aliasing at the back-end if they were permitted to do it, and assuming they held all the respective TLDs. But if they were permitted to do it at the back-end, who is to say they would not deliver DNAMES?

Could someone please explain to me how a registry could do back end aliasing? Without inserting code into the root servers, no registry can on their own alias anything. As Duck would say, let's stop talking rubbish.

Nothing is going into the root without ICANN approval, whether it be new space IDN TLDs or the code necessary to make DNAME aliasing work. And while DNAME is still being worked on as a technical standard, and may indeed one day see the light of day, it will be long after ccTLDs have been inserted as new space records.

That, obviously is conjecture based on a cool look at the landscape at present and where we all seem to be going... But then so is my belief in IDN.com.

zfreud

22nd February 2008, 06:47 PM

where exactly does one find this mythical backend? it's not as if we all stop by the Verisign office everytime we type .com.

If Verisign is "permitted" to do aliasing, then they will be using a standard like DNAME or some other agreed upon method. A standard which would need to be approved as all the root servers would need updating. Verisign can't magically turn on DNAME like turning on lights in their office.

Rubber Duck

22nd February 2008, 07:09 PM

A DNS is basically a system that turns Names into IPs and back again.

This is a layman's perspective:

The ICANN Root Servers effective direct the traffic to the Registries which hold the IP Directories. If it is a dot Com the query gets sent to the Verisign Servers, if it is a dot Info, it gets sent to Affilias. The Registry servers effectively just deliver an IP address back to the Root so the traffic can be directed to where it needs to go. It is almost like playing trains.

If Verisign controls more than one registry but only one has registrants, then it can link across to the one holding the master directory by making a query in much the same way that the query comes from ICANN in the first place. If you had a .kom registry and it were linked to .com then the query would go from the Root to the .kom servers, which instead of sending back an IP from their own records would forward the query to the .com registry, who would send the IP to the .kom registry that would then send it back to ICANN. It is a lot more complicated than that because there is two way verification going on at each stage.

Now you have the situation of C- Name and D-Name aliasing which are just two protocols. Under C-Names, the .kom servers would check their own database to see which records needed to be forwarded to the .com servers and which one would simply return an IP directly. Under D-Names everything would be referred directly to the dot com master directory. In many ways, as complicated as D-Names is, if it works it is going to be a hell of lot easier to administer than C-Name aliasing.

Of course from ICANN's perspective, it may actually prefer to let Verisign run it this way as a Test-Bed before being tempted to try to introduce the technology itself. For all we know, Verisign might already be running mock-ups of DNAMES.

where exactly does one find this mythical backend? it's not as if we all stop by the Verisign office everytime we type .com.

If Verisign is "permitted" to do aliasing, then they will be using a standard like DNAME or some other agreed upon method. A standard which would need to be approved as all the root servers would need updating. Verisign can't magically turn on DNAME like turning on lights in their office.

Drewbert

22nd February 2008, 08:22 PM

Could someone please explain to me how a registry could do back end aliasing? Without inserting code into the root servers, no registry can on their own alias anything. As Duck would say, let's stop talking rubbish.

Nothing is going into the root without ICANN approval, whether it be new space IDN

I guess you'd better complain to the USPTO regarding their awarding Snapnames a patent for "parallel registry technology" then, since you think aliasing can't be done via the registry databases.

jacksonm

22nd February 2008, 08:36 PM

I guess you'd better complain to the USPTO regarding their awarding Snapnames a patent for "parallel registry technology" then, since you think aliasing can't be done via the registry databases.

Right.

ZFreud, RD, etc - I explained it once already and it was a very simple explanation - completely out of ICANN's hands. If you all can't understand what I said, it's not my fault.

.

zfreud

22nd February 2008, 08:39 PM

Rubber Duck

22nd February 2008, 09:27 PM

jacksonm

22nd February 2008, 09:35 PM

blastfromthepast

22nd February 2008, 09:40 PM

At this stage of the game, in my view, the ball is in Verisign’s court. So, interested parties should be commenting/lobbying/trying to get more color out of/inviting to discuss/blogging about/ Verisign.

Right on, an effort should me made to get some assurances from Verisign and to lobby them.

And now for zfreud:

Join Date: Sep 2005
Posts: 83
Rep Power: 0

Drewbert and Duck, I stand corrected. I was new spacing my thoughts

Once again there, you come out of the woodwork... go back to sleep.

Blast: "First Grade? What's that? Can you alias that too?!"

Now, speaking of the first grade, my elementary school's first grade tuition cost more than the two years you most likely spent at community college.

zfreud

22nd February 2008, 10:14 PM

"my elementary school's first grade tuition"

Now there was some money well spent.

jacksonm

22nd February 2008, 11:38 PM

Yes, perhaps we do need to get up to speed on the terminology because the explanations so far have been way off base.

DNS is the only thing which we deal with that is a protocol. The DNS protocol is a standardized communications interface to a database full of standardized record types. You communicate with the DNS service in a standardized manner, and you can query standardized record types. DNS does not use TCP/IP as an underlying transport protocol - it uses UDP. Very simple.

The DNS protocol provides transparent access to a geographically distributed, hierarchical database. The top of the database is called ".". The "." zone is managed by ICANN and replicated to "root" servers around the world. Under ".", you have entries like ".com" and ".jp". Under those entries, you have domain names like "foo.com" and "ne.jp".

A DNS server may contain many types of records:

A (Address) - this record type maps a hostname to an IP address. You query a DNS server for an A record of "www.foo.com" and you get back the IP address "216.234.246.150". The hostname in this example is "www". An A record is the standard entry to give a hostname to an IP address.

PTR (Pointer Record) - this record type allows you to do reverse DNS lookups (query an IP and get back a hostname). This is called reverse mapping. You create a PTR record for "216.234.246.150" and give it a value of "www.foo.com". Not all people who manage DNS servers actually create reverse records for the hostnames in the database, although they really should. PTR records point to A records.

CNAME (Canonical Name) - this record type lets you create aliases for an existing A record. With this record, you can alias additional hostnames to a single IP address which already has an A record. For example, you can alias the names "ftp" and "mail" to "216.234.246.150". Now you have one IP address which answers for three names: www, ftp, and mail in the foo.com domain.

DNAME - this record type lets you map an entire subtree of the DNS name space to another domain. If you map foo.com to bar.com then you have renamed foo.com to become bar.com, while leaving the foo.com names answering (good for transitions, etc). You can query www.foo.com, and the request for the hostname "www" is automatically queried from the "bar.com" zone. In the event of DNAME adoption, all DNAME records would go inside of the "." zone (in the root servers).

NOTE that a single DNS server can handle an arbitrarily large number of different domains. For example, the "." server has all ccTLD and all gTLD domains, as well as .gov, .edu, etc.

Stay tuned for lesson 2, where we will study delegation and recursive resolving.

.

Wot

22nd February 2008, 11:43 PM

"my elementary school's first grade tuition"

Now there was some money well spent.

i orsa wena skule wen i wuz a chilen.

blastfromthepast

23rd February 2008, 03:26 AM

Stay tuned for lesson 2, where we will study delegation and recursive resolving.

Jacksonnm has better technical skills than most, and it behoves everyone in this discussion to learn from him.

touchring

23rd February 2008, 04:03 AM

Drewbert and Duck, I stand corrected. I was new spacing my thoughts when I should have been aliasing...

grrrr....

jacksonm, i suspect it's not completely out of ICANN's hands. For the same reason Verisign had to pull back on wild carding .com, I don't think they will be allowed to alias without ICANN authorization.

Unlike Jackson, I'm no techy but i think from the business point of view.

Businesses are guided by profits and ethics (no ip infringement, no cheating, no illegal).

There's no rule that says you can't alias 2 domains you own.

If you own .com and .kom (k is the russian k), the registrar can give you the option of aliasing, can't they?? They may even charge for the service!!

Verign wins - they make another $6. ICANN wins - they make 20 cents.

We LOSE!!

Question to Jose - the .es launch, existing ASCII .es owners with similar names are given the priority, aren't they?? Like Espanya.es is given priority for the IDN version? I think i saw something like that at their whois service while searching for names.

Remember that ICANN likes to say that aliasing is not just an IDN issue? hACK! We've got domains for like 20 years, ICANN aliasing has never been implemented since. So at this point, i only see 3 possibilities:

1). Verisign takes idn.kom and then offer it to idn.com owners. If we don't take the name (at a fee of course), it will be up for all to register.

2). Verisign sits on it, it doesn't take .kom and no one else does. No aliasing, no dname, nothing happens (good chance for this next 2 years).

3). Someone else takes .kom, Verisign does not object - we're cooked! Now less to URDP to enforce our rights (if it is still possible!).

I'm just projecting based on what has been discussed on this forum - i may well be wrong. :o

Drewbert

23rd February 2008, 04:39 AM

>Verisign does not object

And monkeys might fly out of my butt.

blastfromthepast

23rd February 2008, 05:42 AM

3). Someone else takes .kom, Verisign does not object - we're cooked! Now less to URDP to enforce our rights (if it is still possible!).

According to the rules being cooked by ICANN, Verisign must get .ком. (No monkies for Drewbert, sorry.)

So,

Correction to 3) Verisign takes .ком. Verisign lets someone else register IDN.ком - we're cooking! Now turn to URDP to enforce IDN.com -> IDN.ком rights.

Drewbert

23rd February 2008, 06:16 AM

> Now turn to URDP to enforce IDN.com -> IDN.ком rights

Which supposedly requires a registered TM, but they let ones through in the past without them.

jacksonm

23rd February 2008, 07:22 AM

Unlike Jackson, I'm no techy but i think from the business point of view.

I don't know where you are going with that; are you another one of those that think that technical and business skills are mutually exclusive? I will tell you that I put together business cases for a large multinational technology corporation every day. And I'm better at it than many because I do have a technical background.

When I told you (collectively) a week ago how Verisign would most likely do this (exclusively sell domains in new namespaces to existing dot com holders), from a business perspective, I think it was right on the money. So did Drewbert, whom you invoked in the name of my supposed idiocy, and he also explained why it was a good idea and why it would it is already implicitly sanctioned by ICANN.

Only the super-dense cannot comprehend this, but I suspect by the time the light turns on inside these heads they will think that the idea was theirs.

I personally do not care if verisign wants me to pay for exclusive access to buy my domains in their new IDN extensions, and I will gladly pay them (not for latins, but you get the point). I don't consider that as losing, I consider it as winning.

.

alpha

23rd February 2008, 07:36 AM

as an observor on the sidelines, just a recap of progress made in clearing up confusion and learning anything new about how aliasing will play out:

around the 15th Feb

we knew shit about how this will all play out

then add...

# of threads 6
# posts 139
# views 1062 of posts
# ICANN people pissed off 3
numerous insultants, tantrums and general hair pulling

and today

and we still know shit about how this will play out

touchring

23rd February 2008, 07:39 AM

I don't know where you are going with that; are you another one of those that think that technical and business skills are mutually exclusive?

I personally do not care if verisign wants me to pay for exclusive access to buy my domains in their new IDN extensions, and I will gladly pay them (not for latins, but you get the point). I don't consider that as losing, I consider it as winning.

.

If you don't know, please don't assume you know where i am going with that.

I am no techy - this is a fact.

I did not say that technical and business skills are mutually exclusive. You think too much or you mistook me for someone else on this forum. ;)

Being a .com believer, i'm not particularly optimistic on the success of idn tld, so I consider any extra expense as a burden.

Profit = Revenue - Expense.

According to the rules being cooked by ICANN, Verisign must get .ком. (No monkies for Drewbert, sorry.)

So,

Correction to 3) Verisign takes .ком. Verisign lets someone else register IDN.ком - we're cooking! Now turn to URDP to enforce IDN.com -> IDN.ком rights.

Roger blast. This will be a nightmare scenario for us! :o

Also, possibility 4:

4) Verisign takes .ком. Verisign reserves our IDN.ком as premium! Oops, can we turn to URDP for this case?

jacksonm

23rd February 2008, 08:13 AM

Being a .com believer, i'm not particularly optimistic on the success of idn tld, so I consider any extra expense as a burden.

Well given the opportunity to gain exclusive (paid) access to my domains in an IDN TLD, I would take definitely advantage of this for Arabic and most likely for Russian. I would also strongly consider taking advantage of it for Chinese and Japanese. This is getting into pure opinion, though, on what we think is best. And that's not the point here.

Profit = Revenue - Expense.

Spending 6 or 7 USD to be able to sell Arabic domains for 6-7 figure sums is a no brainer for me :-)

.

Also, possibility 4:

4) Verisign takes .ком. Verisign reserves our IDN.ком as premium! Oops, can we turn to URDP for this case?

This is indeed a scary scenario. Probably the only thing that would help you is if you have a TM.

.

touchring

23rd February 2008, 08:41 AM

This is indeed a scary scenario. Probably the only thing that would help you is if you have a TM.

.

Ok, worst case scenario. Unlikely, but not impossible.

clipper

23rd February 2008, 08:52 AM

3). Someone else takes .kom, Verisign does not object - we're cooked! Now less to URDP to enforce our rights (if it is still possible!).

This is not possible, according to the ICANN "literature" I've read. And, as a publicly held company, Verisign would have to fight it.

as an observer on the sidelines, just a recap of progress made in clearing up confusion and learning anything new about how aliasing will play out:

around the 15th Feb

we knew shit about how this will all play out

then add...

# of threads 6
# posts 139
# views 1062 of posts
# ICANN people pissed off 3
numerous insultants, tantrums and general hair pulling

and today

and we still know shit about how this will play out

Thanks for summing it up. Looks like the whole market may have been devalued over the past week. Good news!

Rubber Duck

23rd February 2008, 09:15 AM

The model I explained before is simply selling names in a new extension to the owner of the label in another extension. It is nothing more than sales. Everybody gets their money.

The only difference in what I explained to normal sales is that these sales would be restricted to the label owner in another extension, e.g. dot com. It's blindingly simple.

.

Well if that is the case then we have absolutely nothing to worry about. Paying twice as and when it suits my purpose really would not unduly concern me with the portfolio we are holding. This is not one of the long tail operations were you have worry yourself sick about margins. If we have the rights to the domains that matter. we are minted PERIOD. Obviously, under these conditions any attempts to charge a premium would be seen for the extortion it is.

What people are missing here is, however, is the level of control that ICANN exerts. With all the chatter about split roots we need to understand that any and every Internet Service provider, Web Site etc, even in China and Russia runs on ICANN allocated IPs. To truly split the Internet, China would have to establish a totally independent Internet with its own IP allocations.

At the other end of the scale, ICANN has contractual control over not only Registries but Registrars. Registry Fly was not even a bloody Registrar, but a retailer. With this new Escrow service, it means that they will have a complete duplicate of all the Registrar Databases, so I am damned sure they could Clone the dot com registry if they had to. At the end of the day all this chatter about Verisign acting unilaterally without ICANN approval is just bunk. It is just not going to happen.

as an observor on the sidelines, just a recap of progress made in clearing up confusion and learning anything new about how aliasing will play out:

around the 15th Feb

we knew shit about how this will all play out

then add...

# of threads 6
# posts 139
# views 1062 of posts
# ICANN people pissed off 3
numerous insultants, tantrums and general hair pulling

and today

and we still know shit about how this will play out

Which is exactly what ICANN always tells you unless you can exert a little pressure!

jacksonm

23rd February 2008, 10:04 AM

Well if that is the case then we have absolutely nothing to worry about. Paying twice as and when it suits my purpose really would not unduly concern me with the portfolio we are holding. This is not one of the long tail operations were you have worry yourself sick about margins. If we have the rights to the domains that matter. we are minted PERIOD. Obviously, under these conditions any attempts to charge a premium would be seen for the extortion it is.

I also don't mind paying twice when it suits my purpose. If they go with this model, then I could see a possible scenario where they have a sunrise or pre-sunrise or whatever the hell they want to call it where dot com owners could assert their rights should they so desire. Or maybe they would do it so that nobody other than the dot com owner could ever buy the domain in the equivalent extensions. This is really just a business decision of the registry and has nothing to with ICANN. Of course how they behave could open them up for lawsuits from existing dot com owners, and this is what they would probably like to avoid.

What people are missing here is, however, is the level of control that ICANN exerts. With all the chatter about split roots we need to understand that any and every Internet Service provider, Web Site etc, even in China and Russia runs on ICANN allocated IPs. To truly split the Internet, China would have to establish a totally independent Internet with its own IP allocations.

No it wouldn't. IP allocations are completely independent of the ICANN DNS extensions. To prove this point, there are already operations today that are running alternate roots on top of ICANN allocated IP addresses. This has been going on for years.

At the other end of the scale, ICANN has contractual control over not only Registries but Registrars. Registry Fly was not even a bloody Registrar, but a retailer. With this new Escrow service, it means that they will have a complete duplicate of all the Registrar Databases, so I am damned sure they could Clone the dot com registry if they had to. At the end of the day all this chatter about Verisign acting unilaterally without ICANN approval is just bunk. It is just not going to happen.

If Verisign is granted an extension called ".xn--xyz", which is an equivalent to ".com", they can sell names individually, give them away for free, keep the namespace closed to the public, or whatever they like. Their only obligation to ICANN is to pay ICANN for each entry they make in this new namespace. Verisign does not need to get permission from ICANN for everything they do. If ICANN exerted the level of control over the DNS hierarchy that you imagine, then I'd need to get ICANN approval (or approval delegated to Verisign) to add new zones and aliases inside of my DNS server.

Keep your cool and I will continue to discuss with you.

.

Rubber Duck

23rd February 2008, 10:29 AM

Actually, they cannot, because the way names are allocated and charged for is a fundamentally integral part of their submission to be granted a registry or extension in the first place. They have to state all this up front before the allocation occurs and it is then contractually binding upon them. This goes way beyond what is technically feasible. And to some extent that is why it is important to get these things out in the open now, so they are unable to sneak something through a weakly worded draft of a contract, simply because nobody had clearly identified the issues.

I also don't mind paying twice when it suits my purpose. If they go with this model, then I could see a possible scenario where they have a sunrise or pre-sunrise or whatever the hell they want to call it where dot com owners could assert their rights should they so desire. Or maybe they would do it so that nobody other than the dot com owner could ever buy the domain in the equivalent extensions. This is really just a business decision of the registry and has nothing to with ICANN. Of course how they behave could open them up for lawsuits from existing dot com owners, and this is what they would probably like to avoid.

No it wouldn't. IP allocations are completely independent of the ICANN DNS extensions. To prove this point, there are already operations today that are running alternate roots on top of ICANN allocated IP addresses. This has been going on for years.

If Verisign is granted an extension called ".xn--xyz", which is an equivalent to ".com", they can sell names individually, give them away for free, keep the namespace closed to the public, or whatever they like. Their only obligation to ICANN is to pay ICANN for each entry they make in this new namespace. Verisign does not need to get permission from ICANN for everything they do. If ICANN exerted the level of control over the DNS hierarchy that you imagine, then I'd need to get ICANN approval (or approval delegated to Verisign) to add new zones and aliases inside of my DNS server.

Keep your cool and I will continue to discuss with you.

.

jacksonm

23rd February 2008, 10:35 AM

Rubber Duck

23rd February 2008, 10:51 AM

OK, do you think we can find an application or a contract to examine? At least the applications should be available with some searching. Post a link if you find one.

.

The new contracts won't be available until after the policy is finalised, but we can look at the recent examples under the old system. Dot Mobi, and dot Asia have been able to Auction off domains at launch because that was part of the submission for which they were granted the extension. Other registries have not been able to do this. All registries are temporary custodians, with the possible exception of Dot Com where it would seem that Verisign more or less have squatters rights due to the fact that they have been around a hell of a lot longer and ICANN, had huge financial clout and have been skilful negotiators. Everything else, however, is stuck down pretty water tight as far as I can work out. If ICANN feels they have broken their obligations, then they can pretty much just be replaced.

Getting back to your previous point about IPs. Yes, organisation have been running separate Roots on ICANN IPs, although I personally do not regard that to be the case with the Chinese. In their case, it seems to be much more a local fudge. Perhaps they are running DNames to achieve their results, who knows? Whilst, it is a highly unlikely scenario and not one that I would give much thought to, in theory if CNNIC broke their contractual obligation to ICANN, there is a least a theoretical risk that ICANN would pull the plug on the entire Chinese Internet. Of course, the Chinese could implement some kind of back-up system, but if that were to occur, then the Internet would have been split in a real and meaningful way. At the moment, we have a situation where everything that works outside China, also works inside. OK, we have a few bolt on extras that work inside China that cannot work outside, but that is only really because they are waiting for our Luddites to catch up. This does not in any reasonable analysis represent a split of the Internet. On top of that we have had small independent networks working in the Middle East, and a couple of private sector wannabee. But frankly, these other initiatives have had precisely zero impact, and there is little to suggest that that situation might ever change.

jacksonm

23rd February 2008, 10:57 AM

Hey, here are the existing agreements:

http://www.icann.org/tlds/agreements/

They are really not that detailed or controlling.

.

Rubber Duck

23rd February 2008, 11:15 AM

Hey, here are the existing agreements:

http://www.icann.org/tlds/agreements/

They are really not that detailed or controlling.

.

I think you can assume this is pretty much a catch all!

(b) Statements made During Application Process. The factual statements contained in Registry Operator’s application for the TLD, or made by Registry Operator in negotiating this Agreement, were true and correct in all material respects at the time the application was submitted to ICANN and are true and correct in all material respects as of the date this Agreement is entered into set forth above.

http://www.icann.org/tlds/agreements/asia/asia-agreement-06dec06.htm

and what about this?

(i)At all times during the term of this Agreement and subject to the terms hereof, Registry Operator will fully comply with and implement all Consensus Policies, as the same may be applicable to Sponsored TLDs, found at http://www.icann.org/general/consensus-policies.htm, as of the Effective Date and as may in the future be developed and adopted in accordance with ICANN’s Bylaws and as set forth below.

and as a final FY:

Section 5.3 Limitation of Liability. ICANN's aggregate monetary liability for violations of this Agreement shall not exceed the amount of Registry Operator-Level Fees paid by Registry Operator to ICANN within the preceding twelve-month period pursuant to Section 7.2 of this Agreement. Registry Operator 's aggregate monetary liability to ICANN for violations of this Agreement shall be limited to fees and monetary sanctions due and owing to ICANN under this Agreement. In no event shall either party be liable for special, indirect, incidental, punitive, exemplary, or consequential damages arising out of or in connection with this Agreement or the performance or nonperformance of obligations undertaken in this Agreement, except as provided pursuant to Section 4.4 of this Agreement. EXCEPT AS OTHERWISE EXPRESSLY PROVIDED IN THIS AGREEMENT, REGISTRY OPERATOR DOES NOT MAKE ANY WARRANTY, EXPRESS OR IMPLIED, WITH RESPECT TO THE SERVICES RENDERED BY ITSELF, ITS SERVANTS, OR ITS AGENTS OR THE RESULTS OBTAINED FROM THEIR WORK, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE.

jacksonm

23rd February 2008, 12:42 PM

So basically what the agreement says is that once a proposal is accepted, the registry needs to operate accordingly. They also need to operate according to concensus policies, and there are only like 7 of them now. Essentially, the agreement can be renegotiated at any time by sending a new proposal.

(iv) Process for Consideration of Proposed Registry Services. Following written notification by Registry Operator to ICANN that Registry Operator may make a change in a Registry Service within the scope of the preceding paragraph:

(A) ICANN shall have 15 calendar days to make a “preliminary determination” whether a Registry Service requires further consideration by ICANN because it reasonably determines such Registry Service: (i) could raise significant Security or Stability issues or (ii) could raise significant competition issues.

Now, if Verisign proposed to restrict sales of labels under newly granted TLDs which are .com equivalents, do you think that this would be considered a "significant competition issue"? Maybe. Or maybe they would simply say "Don't bother us with this stuff, do what you want with your own namespaces". I don't think any of us can reasonably deduce how ICANN would respond to this sort of proposal. In the event they see a competition issue, they simply refer it to the appropriate governmental bodies (national governments, not ICANN), and they are done with the matter.

As Drewbert pointed out, some registries, e.g. .hk, already give away variant names "for free" within the same namespace. However, their price for a domain name is already so high that maybe they just absorb the per-domain fees to ICANN instead of passing them on directly to the customer. In addition, registries such as .com already block a lot of variants from registration. I wonder if .hk needed to get explicit permission to give away variants "for free"? I wonder if Verisign needs to get permission to do variant blocking, or does this fall under concensus policy?

Anyhow, from a business perspective, I simply can not see entire extension aliasing ever happening (regardless of the technology). I certainly can see that Verisign would do what I explained a week or so ago, and Drewbert pointed out the beauty of that as well. Indeed, Verisign has been a proposer and proponent of DNAME resource records, but we can not assume what they would intend to do with them - there are many different ways in which they could be used, even within Verisign's own DNS zone for .com.

This document explains a lot about registries implementing new services:

http://www.icann.org/registries/rsep/rsep.html

.

Rubber Duck

23rd February 2008, 01:16 PM

Yes, basically ICANN can change the rules to do what they please which is why Verisign now block variants that they didn't before. I think Verisign would like to charge existing domain holders for Variants and I think that is definitely an option. Indeed they could probably do it now, but probably don't see it as being commercially viable at present.

We need to remember that the ICANN fee is only about 20p per name and that is variable dependent on the specific agreement and most registrants would only be interested in one or two versions.

DNAME can only be used to alias an entire registry. It cannot be used to do them all on a case by case basis according to whether the registrant has stumped up or not. If it were done in the root, then all aliased extensions would be aliased for all registrants for each extension. There would be no scope to gather subscriptions except from a global increase in the registry fee. Perhaps that would happen, but the chances are that the ASCII mob would be asked to stump up as well!

So basically what the agreement says is that once a proposal is accepted, the registry needs to operate accordingly. They also need to operate according to concensus policies, and there are only like 7 of them now. Essentially, the agreement can be renegotiated at any time by sending a new proposal.

Now, if Verisign proposed to restrict sales of labels under newly granted TLDs which are .com equivalents, do you think that this would be considered a "significant competition issue"? Maybe. Or maybe they would simply say "Don't bother us with this stuff, do what you want with your own namespaces". I don't think any of us can reasonably deduce how ICANN would respond to this sort of proposal. In the event they see a competition issue, they simply refer it to the appropriate governmental bodies (national governments, not ICANN), and they are done with the matter.

As Drewbert pointed out, some registries, e.g. .hk, already give away variant names "for free" within the same namespace. However, their price for a domain name is already so high that maybe they just absorb the per-domain fees to ICANN instead of passing them on directly to the customer. In addition, registries such as .com already block a lot of variants from registration. I wonder if .hk needed to get explicit permission to give away variants "for free"? I wonder if Verisign needs to get permission to do variant blocking, or does this fall under concensus policy?

Anyhow, from a business perspective, I simply can not see entire extension aliasing ever happening (regardless of the technology). I certainly can see that Verisign would do what I explained a week or so ago, and Drewbert pointed out the beauty of that as well. Indeed, Verisign has been a proposer and proponent of DNAME resource records, but we can not assume what they would intend to do with them - there are many different ways in which they could be used, even within Verisign's own DNS zone for .com.

This document explains a lot about registries implementing new services:

http://www.icann.org/registries/rsep/rsep.html

.

Jay

23rd February 2008, 01:24 PM

A little more info from Tina Dam on where ICANN are up to on aliasing:

http://idntraders.com/index.php?topic=90.msg261#msg261

jacksonm

23rd February 2008, 01:35 PM

DNAME can only be used to alias an entire registry.

This is not really correct, remember that DNAME is only a resource record type and it can be used in many ways. It can be used to wholly redirect any branch of a namespace to any other domain. As a practical example, Verisign could do this in their own nameservers (if they had reserved idn.com for their own use):

.idn.com. DNAME .xn-xyz.

Now, all name lookups for the idn.com namespace would actually be referred to the .xn-xyz namespace for answers. So you see, they could alias a domain itself to a new extension. Not sure how useful this would be, but this does serve as a good practical example of what DNAME really does.

Now, here is an example of how you would use DNAME resource records to do extension aliasing (aliasing 5 IDN equivalents for dot com to .com itself):

.xn--xyza. DNAME .com.
.xn--xyzb. DNAME .com.
.xn--xyzc. DNAME .com.
.xn--xyzd. DNAME .com.
.xn--xyze. DNAME .com.

It cannot be used to do them all on a case by case basis according to whether the registrant has stumped up or not. If it were done in the root, then all aliased extensions would be aliased for all registrants for each extension. There would be no scope to gather subscriptions except from a global increase in the registry fee. Perhaps that would happen, but the chances are that the ASCII mob would be asked to stump up as well!

This is correct.

.

Rubber Duck

23rd February 2008, 01:44 PM

Yes, I went to great length at one time to try to point out Vint Cerf that DNAME could be used by the Chinese to great an unlimited number of TLDs under the dot CN so that it the dot CN did not have to be specifically used on second level names, such as .com.cn. Perhaps I shouldn't have said anything. :p

blastfromthepast

23rd February 2008, 07:45 PM

4) Verisign takes .ком.

So, all attention should be on Verisign.

So far, what we have going for Verisign, based on past performance:

1) Launched IDN.com TEST registrations in 2000.

2) Rolled over TEST registrations to real registrations when Punycode standard came out.
=> Early "test" registrants benefited, much to the annoyance of those who thought it was "just a test."

3) Produced aliasing proposal for ICANN shows support of aliasing idea for .com.

4) Have been keeping quiet.

NEXT STEP) Rolled over .com registrants to .ком, once approved for .ком, which they will be.
=> This is what we need to focus on.

bwhhisc

23rd February 2008, 10:55 PM

So, all attention should be on Verisign.

So far, what we have going for Verisign, based on past performance:
1) Launched IDN.com TEST registrations in 2000.
2) Rolled over TEST registrations to real registrations when Punycode standard came out.
=> Early "test" registrants benefited, much to the annoyance of those who thought it was "just a test."
3) Produced aliasing proposal for ICANN shows support of aliasing idea for .com.
4) Have been keeping quiet.
NEXT STEP) Rolled over .com registrants to .ком, once approved for .ком, which they will be.
=> This is what we need to focus on.
Worth the effort. Seems that from the ICANN blog conversation and comments by Tina Dam when Verisign is
ready they are free to make this request to ICANN when they wish.