>> I believe that the registry we have currently defined doesn't do a great job >> of capturing the actual needs here.
Agreed. It seems to me that there are two somewhat separate things going on here. One is the .ONION issue. It's a domain name string that has a coordinated use that is implemented outside the RFC 1034/1035 DNS. The other is the .BELKIN and .CORP issue. They're domain name strings that have no coordinated use, but there's enough uncoordinated use that there'd be a stability risk if a live TLD started answering queries. In both cases, one question is when we reserve the name, and the other equally important question is when we un-reserve the name. For all three, I think there's adequate evidence to reserve them now. The un-reserve criteria is different, and I expect would be different for any other name we reserved. For .onion, it's not out of the question that five or ten years from now we check in with the ToR project and they say oh, the whole reserved name thing was such a hassle that we switched to onion:// names and we don't use domain names at all. For .BELKIN, the problem was a lot of home routers shipped a decade ago. Eventually most of them will die and the problem will go away. Or if the Belkin company wanted a vanity domain, they presumably know what the routers did and could come up with a TLD that avoided sending unfortunate responses to the old queries. For .CORP, I gather the main usage was for intranet TLS certificates, but the public CAs have stopped signing them so they will probably mostly go away, too. The point of these examples is not that we need to solve any of those issues now, but that a useful reserved name registry needs to deal with the reality that most reservations need not be forever. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
