Discontinuation of third level domain registrations for the .name TLD [pdf](itp.cdn.icann.org) |
Discontinuation of third level domain registrations for the .name TLD [pdf](itp.cdn.icann.org) |
I don't see how this is any different, other than the second-level domain owner delegates their registrar job to the first-level domain owner.
There is something weird though if you control smith.name, that you don't control john.smith.name. The DNS system does convey some indirect concept of responsibility.
ICANN is involved because Verisign is the registry operator for .name, and the contract between ICANN and Verisign gives ICANN some oversight power over Verisign's registry services. This includes some fairly limited oversight power over what they call "voluntary services", which are services that the registry provides that are not required to be provided by the contract. Apparently the registration of 3rd level domains and the email forwarding service are voluntary services, not services that Verisign is obligated to offer by the contract.
contrary, this is one TLD _ceasing_ its idiosyncratic mode of operation.
I've managed multiple third-level domains for decades, and didn't realize this distinction between registry-managed domains and having the registry delegate third-level domains to the authoritative servers...the latter I'm quite used to, but this change is about the former.
I've never used .name, and while I was initially skeptical, it seems like this is a pretty reasonable move.
(via https://www.icann.org/resources/pages/reconsideration-26-2-s...)
In the RSEP it states:
> "Have you communicated with any of the entities whose products or services might be affected by the introduction of your proposed service? If so, please describe the communications."
> "No. Not applicable."
As thankful as I am to OP for bringing this to my attention; I am equally disappointed that my registrar (Fasthosts) has not made any attempt to warn me about this, and that Verisign consider me "Not applicable" to a change that will be extremely onerous.
90 days to transition is an extremely short period of time to transition literally every account I have, including email addresses I use for government and medical services.
i've been a third level domain customer since 2006 not amused at all
Now, years later, they are undoing it and they're even breaking existing domains. ("existing third level domain names will be terminated") This kind of breaking change shouldn't be allowed.
That was the starting point - we started as a webmail provider letting people share lastname.sometld domains
Without that, it's just another name.
If I had to guess, they're wanting to auction off the second level domains which will likely bring in more money than the rather unpopular third level registrations.
None. There will not be any effect on the life cycle of domain names."
Well, aside from deleting all of them. But no other effect on the life cycle.
"3.6. Have you communicated with any of the entities whose products or services might be affected by the introduction of your proposed service? If so, please describe the communications. No. Not applicable."
I guess communication is not applicable when you just cease a service.
Sounds like a win to me if you play your cards right.
They want to discontinue this because it's not especially popular or profitable. I take this to mean that they can't get enough money to support the administrative and developmental overhead.
Now, it's true that there's only ~100k people using first.last.name type domains, and managing those and their special rules is a time and testing suck for developers and administrators. And likewise the business of getting things done requires offices and other resources. On the other hand, domain name registration is, when you get down to it, a matter of administering a database and keeping things like the DNS in sync with it. It's technically inelegant and annoying, and no doubt a potential source of security problems (isn't everything?), but it's not actually a difficult or dangerous job, and the financial overhead seems like a negligible fraction of their revenue.
I get that this is an administrative headache. But administrative problems often do not require administrative solutions, in the sense that the administrative 'solution' is to generate some paperwork declaring the the problems outweigh the benefits and the impact on others doesn't matter and can be ignored. There's a sense throughout the document of people who took on a responsibility just wanting to wash their hands of it without any consideration for those who will be impacted. This is an ongoing cultural antipattern in Silicon Valley and the tech industry in general. There's an air of dishonesty to Verisign's claims 'we talked to a few people verbally and everyone's cool with it, therefore you should approve it because there's no opposition that matters.'
istm the best way to resolve this is via Coasean bargaining, that is Verisign pays people to go along with the shutdown, using some sort of objective formula and getting buy-in from a supermajority of registrants. For example they could offer 5 years of free firstname-lastname.com (or .name) hosting and guaranteeing domain forwarding for 2 years, or let people handle it themselves in return for $1000 or whatever. To be sure, some people might argue that their loss is much greater because they've built a big brand around their .name domain, but I think it's probably better to get broad acceptance for a blanket solution rather than turn it into a fight for the most $ that will inevitable end up in protracted arbitration or litigation, costing tens or hundreds of times more than buying people out.
Basically, .name came out of us starting out as a webmail provider offering people to pick from ca. 60k domain names covering most common last names, because one of my co-founders and I both had firstname@lastname.tld email addresses.
When ICANN opened up for new TLDs we decided to try to offer the same more broadly.
So it wasn't just the registration, but initially also email forwarding..
None of the first batch of TLDs did as well as projected, and demand for .name was well below what we'd hoped, sadly.
For .name, it was a match of less demand than we thought and people not getting the third level thing, which led to eventually abandoning it as the main offering (after I'd moved on).
We ended up selling to Verisign a few years later.
do you think there's any point in contacting ICANN or Verisign? i'd be sad to lose mine!
it's wild how long some third level domains are still pre-registered for and how little an email forward must cost to run (at the sub-registrar level?)
bonus: You set precedent for other people to sue and beat Verisign down cut by cut.
It's an odd concept. I have to say I hadn't really thought of it before reading this.
I know this sounds absolutely absurd and your mind must be screaming "so just get arbitrary.fixed and assign yourself whatever.aribtrary.fixed?" at you... but stick with me and I can say with, dare I say, 61% confidence what .name was doing will make you think "uh - ok, yeah... I... guess. People did that?" :).
If you own smith.uk then great - you can be john.smith.uk. What about Jim Smith in the UK? Is he supposed to just reach out to John Smith and ask for jim.smith.uk to be delegated to him? What about the thousands of other (anything but John) Smiths, are they just supposed to pester John and ask if he'll delegate the name? What if Jane Doe doesn't want to delegate to other Does? What if Bob Johnson does and then dies - lapsing the renewal? It's all a big mess because one person is assigned arbitrary.tld.
That's where arbitrary.arbitrary.tld comes in - arbitrary.tld is managed by the same ones running tld. Now thousands of different people can get their john.smith.tld and jim.smith.tld without having to worry about who controls smith.tld any more. Now sure, there is more than one John Smith... but the chance an individual is able to register their name goes from 1/last to 1/(first*last) and the even when your name is taken it'll take fewer extra characters/nicname variations to find an open one close to it (like jim2.smith.name or jimmy.smith.name).
That's what .name was and why tlds like .uk or third level zones under them like .co.uk aren't really the same thing. The 2nd level isn't both arbitrary AND controlled by the tld operator at the same time. The closest you could get in a normal .tld is to start a service which tries to buy up every lastname.tld, but it's not really practical to try to do so and you'll always end up with someone who doesn't want to sell or some name you didn't think to buy.
Summary (if you quote anything in response please try to do it from the details section as it's more accurate):
Many of the fields you may have missed explicitly say such entries will be deleted and when. None of the other fields, when interpreted in the way ICANN uses them in this process rather than personal interpretations, state there will be no impact to such registrations. The exact quantity is not really relevant nor does ICANN need that in the request form to know. The links above are about ICANN reviewing and confirming there was no error, lack of information, or false reporting in the process.
.
Details:
Changes to the life-cycles of domains is a question meant to ask if this seeks to modify the life cycle policy, which is a separate type of change from termination of the service as a whole. I.e. this does not seek to change the life cycle policy, it seeks to terminate the service offering completely - making the life cycle policy irrelevant. It'd be like saying "on the form to scrap the car they said they aren't planning to change the paint. That's fraud because after it's scrapped the paint won't be the same!" - it sounds correct if you feed it through a set of boolean gates but falls apart when you realize the request is one about getting rid of the entire car rather than about requesting to change the paint color.
The links greyface- provided are from a request to ICANN to review this particular concern. The Ombudsman looked at the same material you have seen (and more) to find:
> On the basis of the following substantive evaluation, it is evident that ICANN followed the relevant policies and underlying process thoroughly, had sufficient information, and did not rely on false or inaccurate information in taking action on the relevant RSEP Requests.
Importantly, they further say on this particular subject:
> Approximately, 22,000 domain names may seem material, and it may or may not be—in either case, it was disclosed to ICANN by the Registry Operator as part of the collaborative process before submitting its RSEP Requests.
With the further detail for the fields you're referencing:
> Finally, I consider whether ICANN relied on false and/or inaccurate information: None was relied on the subject matter expert told me, nor does it appear that any such information was provided to ICANN relating to these RSEP Requests and their preceding collaborative processes. While the Requestor is of the view that statements provided by the Registry Operator in the RSEP Requests (“no effect on the lifecycle of domains” “no effect on competition” and “no effect on the domain market”) may be false or inaccurate in light of the discontinuation and termination of the approximately 22,000 registrations,28 as discussed in the preceding sections, the approximately 22,000 registrations are not relevant to ICANN’s determination at hand, and further, as also noted above, this information was disclosed to ICANN in the collaboration phase.
There were also several other issues raised in the reconsideration request, all were similarly found to be rooted in invalid understandings of this form or process.
Significant effort is spent detailing the relevant parts the RSEP process, confirming and detailing exactly how it was followed correctly. This specifically included whether certain matters were considered for referral (or should have been referred) to RSTEP for review. It's a tragedy to disagree with the well written reconsideration request document without responding to where you feel its analysis was incorrect & why, particularly content from sections:
- 4.2.1, designated to contain inquiries related to the RSEP process and if it was accurately followed, including:
- 4.2.1.3 referencing the parts of the RSTEP process defining when RSTEP should be engaged
- 4.2.2.1 highlighting how voluntary advanced collaboration prior to starting the RSEP process has made the dedicated referral processes referenced in 4.2.1.3 rarely relevant
- 4.2.2.2 containing a confirmation by the Ombuds that the preliminary portion of the process was done correctly and with the required info (including the list of 22k domains shared voluntarily before the preliminary phase began, without need to formally refer to RSTEP)
- & 4.3 concretely explaining in more plain terms why the Ombuds is sympathetic to the user but believes ICANN correctly followed the RSEP process in not engaging RSTEP for the concerns raised and re-raised
About the only thing I think could have been pre-emptively added was a reference to the definitions of Security and Stability concerns, which helps explain why it would have made no sense for RSEP to declare Security or Stability issues in need of referral during preliminary review, let alone "significant" and even ignoring the voluntary early engagement activity:
> 1.2 Security - An effect on security by the proposed Registry Service shall mean (A) the unauthorized disclosure, alteration, insertion or destruction of Registry Data, or (B) the unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with all applicable standards.
> 1.3 Stability - An effect on stability shall mean that the proposed Registry Service (A) is not compliant with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs sponsored by the IETF or (B) creates a condition that adversely affects the throughput, response time, consistency or coherence of responses to Internet servers or end systems, operating in accordance with applicable relevant standards that are authoritative and published by a well-established, recognized and authoritative standards body, such as relevant Standards-Track or Best Current Practice RFCs and relying on Registry Operator's delegation information or provisioning services.
Requesting authorization to terminate a given service & related registrations is clearly neither an unauthorized action/disclosure on registry data as well as clearly not against an IETF RFC. Notably, "Stability" is not defined as "has impact to users" - as well stated towards the end of the reconsideration request:
> Second, on the consideration of material information – the loss of approximately 22,000 is important to the individuals–however, this is not relevant to the strictly defined, community-developed policy
One can find the source for the material quoted in the reconsideration request response as well as the definitions I I added in above at https://www.icann.org/rsep-en/