This should not be allowed. It means (a) one TLD does not operate at the most fundamental level like the others; (b) all of the individuals who are using third-level .name domains are left high and dry

▲

kristjansson a day ago | parent | next [-]

> one TLD does not operate at the most fundamental level like the others;

contrary, this is one TLD _ceasing_ its idiosyncratic mode of operation.

▲

altairprime 2 days ago | parent | prev | next [-]

Which TLDs allow users to registry arbitrary.arbitrary.tld other than .name?

▲

rpdillon a day ago | parent | next [-]

I read the PDF, and thought I understood, but you're asking a good question. I did some research, and it turns out that when .name launched in 2001 (under Global Name Registry), it used this really weird shared-SLD architecture where the registry retained the second-level domain (e.g., rpdillon.name) and sold independent third-level domains (e.g. bob.rpdillon.name and jane.rpdillon.name) to completely unrelated individuals through ICANN registrars.

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.

▲

vidarh a day ago | parent [-]

I cofounded Nameplanet, which morphed into GNR, and my name is in the ICANN docs for .name...

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.

▲

slartibardfast0 18 hours ago | parent [-]

thanks for trying, fwiw it made a beautiful domain for java source code back in the day. i hope you can do a long form retrospective on the .name story someday

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

▲

vidarh 10 hours ago | parent [-]

It can't hurt to try to contact someone, but I doubt Verisign would listen. Already back then (we contracted them to run the registry backend, over my objections) they were stuffed full of bureaucrats. Maybe ICANN.

I left back in 2003, so can really only talk about the origin. By 2003 we cut staff massively, and after completing a reference registrar platform and laying off most of my team there wasn't really much left for me to do, so I left too...

The guy I originally got the shared domain idea with stuck around with a few of the early developers. Our other co-founders were out at that point.

Most of the fun was the initial mail platform and the registrar platform, both of which leaned heavily on qmail - the latter as a queuing system to decouple everything. Email as a messaging bus works very well...

But the .name process was like pulling teeth. One interesting thing is to look at our original ICANN contract and appendices compared to .biz and .info. We had to supply somewhere around 200 pages extra technical detail for "reasons" that seemed to boil down to us not knowing the right people.

Meanwhile dot-biz got away with maybe 30 pages including things like copy-pasting BNF that had no real relevance.

We ended up working round the clock to provide technical details the others weren't even asked for.

Not sure if someone wanted us to fail, or what the motivation was exactly, but the process was clearly not fair.

	▲	slartibardfast0 8 hours ago \| parent [-]
		ah that's wild that top-level owned the MX records and mail relay server infra! thanks very much for sharing. i'm going to send a few old fashioned letters. my registrar said only, we can't give legal advice, ICANN going to ICANN ;)

▲

cpburns2009 a day ago | parent | prev [-]

Don't many ccTLDs do something like that with the ".co.xx" second-level domain? (e.g., ".co.uk")

▲

zamadatix 21 hours ago | parent [-]

Kinda, it's a slight variation of that from what I can tell. E.g. you can't go and register john.smith.uk because it's arbitrary.fixed.fixed rather than arbitrary.arbitrary.fixed. You can do something like john.smith.co.uk, but only if you have registered smith.co.uk or they delegate to you.

It's an odd concept. I have to say I hadn't really thought of it before reading this.

▲

Natfan 20 hours ago | parent [-]

i'm 60% sure that anyone can get a .uk domain. police.uk and nhs.uk are the only ones i can think of off the top of my head, but those might be 3TLDs hosts tbf

	▲	zamadatix 18 hours ago \| parent [-]
		That's arbitrary.fixed, which is something also slightly different. 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.

▲

ButlerianJihad 2 days ago | parent | prev [-]

Are there registrants in the third-level today? It doesn't appear so. The application filled in every single blank with "no problem lol" making it appear that zero customers or registrants will be affected, like at all. So, was anyone taking advantage of this service? They will immediately be terminating the service and so, if anyone was renting space thusly, will have a very narrow window to transition service. But yes, registering "N.N.name" without directly registering "N.name" seemed like a bonkers way to run things.

▲

greyface- 2 days ago | parent [-]

There are 22,000 third-level registrants currently. https://www.icann.org/en/system/files/files/reconsideration-...

(via https://www.icann.org/resources/pages/reconsideration-26-2-s...)

▲

ButlerianJihad 2 days ago | parent [-]

OMG. That is appalling! So the document that Spiridonov submitted clearly shows how Verisign blatantly and repeatedly lied to ICANN on their application. That is absurd. I mean, they are Verisign. To just outright lie like that, about the "life-cycles of domains" and say that there is zero effect, when there are 22,000 customers affected. By Verisign. How can anyone trust them if they blatantly and verifiably lie, in writing, to ICANN? That seems like fraud to me. By Verisign, of all people.

▲

220hertz a day ago | parent | next [-]

By Verisign, you say?

▲

zamadatix 21 hours ago | parent | prev [-]

It's genuinely hard for me to to tell which parts of your comment are supposed to be a sarcastic reaction and which parts are supposed to be serious, which could well be a failure of mine rather than yours, but, taking it all in good faith:

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.

▲

cxr 20 hours ago | parent [-]

That's not accurate. A valid understanding of the form/process should result in an expectation of a referral to RSTEP to evaluate the impact on security and stability. But that didn't happen.

	▲	zamadatix 18 hours ago \| parent [-]
		Today I feel like some guy who spent 6 years studying the curvature of iguana toes (or something equally random) and finally sees questions about them for the first time in his life :D. 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/