> Apologies if I am being over simplistic about this but wouldn't the appropriate path have been to mirror all .tp over to .tl then after a period drop .tp? Running the two in parallel with different domains is just asking for trouble.
Yes, you are being simplistic !
I believe the plan is to open up the new registry, then get all the existing domains to move across. I assume (would hope) that all existing names would be reserved in the new registry - it would be a bit of a bummer to find your name taken when you come to move.
But that is just the easy bit. The really easy bit.
As the article points out, there is a lot of work involved. Just sit down and work out how many places you have given your email address to. Make out a list - and I'll pretty much guarantee that unless you either a) kept a list from the beginning, or b) have an eidetic memory, then you'll miss loads and loads and loads of places.
So a couple of years down the line, you come to log into something and can't recall your password. No problem - click the "forgotten password" link and put your email address in. FAIL. Because you forgot about it, you can no longer log in, AND you can't recover your password because your old email has stopped working.
That's just one example. I can think of a few services that I'm registered with and might not access more than once a year (or even less). In fact, only this week I accessed a system for work (software licence portal for a bit of software a customer uses) that we probably didn't log into for nearly 4 years - and no-one knew the password as the person (no longer working for us) who created the account didn't record it anywhere we know of.
If that service turns out to be for something critical then you could have problems - just think of all that manual work (alluded to in the article) for site operators changing domain for users !
And of course, think of all those services where your email is your account - I know a few where it's hard or impossible to change (bad design, but sh!t happens).
And then there's all those "forgotten systems" which keep churning away in the background and rely on email addresses embedded in config files and scripts. That little utility that "does something | mail -s "Here's your info" email@example.com - they all need finding, changing, and testing. Each one is not a problem - but when there's a lot of them, in systems people have forgotten they have, then it adds up.
For us, if a customer came along and said they were moving domains on their email, then depending on teh system it might not be too much work - but it would be manual work *moving* their existing accounts to the new domain and adding redirects from the old domain.
That's just email. Now lets look at other services.
For *every* web site the server config needs updating. It needs to know what to do when it gets a request for the new hostname. If it's a secure site, then it needs a new certificate - which now needs to be a multi-host certificate (== more costly) as it needs to be valid for both domains.
The fact that you're posting here suggests you're probably reasonably technically literate. For the rest of the population, multiply the problems 10 fold or 100 fold !
So yes, it *IS* a big deal. No it's *NOT* as simple as just mirroring the domains over.
You can't just add the new TLD. If you do that, then people will try to access stuff on it that isn't working or simply gives confusing results == confusion. So you need a phased approach so each domain owner can get the new stuff set up and *then* get the new domain created.
PS - don't get me started on the hassles of getting all the old email autocomplete entries purged !