> On 8 Aug 2022, at 11:16, Independent Submissions Editor (Eliot Lear) > <rfc-...@rfc-editor.org> wrote: > > I caution against those approaches that would set such a high bar that they > would require researchers to fork out hundreds of thousands of dollars on > application fees alone plus who knows how much else for, as someone else > wrote, an uncertain outcome. They'll simply go elsewhere. That in itself > would encourage squatting (or whatever you want to call it). The benefits of > avoiding squatting accrue not only to those researchers, but to those who use > their technology, and others as well.
These are valid points Eliot and I agree with them - at least in principle. However the opposite PoV is equally valid IMO. Those who can’t/won’t go to ICANN to get their new TLD shouldn’t come to the IETF to get around ICANN’s policies. [Not that I’m suggesting this is what the GNS draft’s authors are doing.] IMO it’s the start of a very slippery slope if the IETF accommodates ad-hoc requests for “special” TLDs that are probably for ICANN to decide. Resolving those mutually exclsuive positions is why you get the big bucks Eliot, isn’t it? :-) I suppose the question that needs to be asked is why on technical/engineering grounds MUST some new name space require a new TLD and why can’t that new name space be anchored elsewhere in the public DNS? OK, that’s two questions. Perhaps we’re over-thinking this. Putting these magic strings into the root is a problem for both IETF and ICANN policies. So let’s not do that. How about having an IANA registry of these experimental TLDs? Those strings don’t go in the root. And they don't get added to the IETF’s special use list and ICANN is still free to create these TLDs if/when they decide to create more. This hypothetical IANA registry would primarily be to avoid name collisions between those who are experimenting with new name spaces or running stuff inside them. For bonus points, entries in that registry have to be supported by (say) an Informational RFC. Those registry entries could also come with a health warning: if ICANN or the IETF one day creates your TLD for real, you’re out of luck. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
