> On 14 Dec 2022, at 16:28, Eliot Lear <l...@lear.ch> wrote: > > We're off in the woods again. Let's keep these two principles in mind: > > • The DNS resolution mechanisms are not expected to resolve, let alone > secure names ending in .ALT. > • How other resolution mechanisms secure names is their affair.
If these principles apply, why is the IETF bothering with .alt at all? This pseudo-TLD won’t be part of the One True DNS Name Space that uses the One True DNS Resolution Mechanism. I fail to understand why it continues to get airtime in dnsop. Please make it stop. Anyways to get back on topic, I do not support this ID. IMO it’s out of scope for dnsop or the IETF more generally. If the ID goes ahead, it will open up far too many layer-9+ issues and encourage others to abuse IETF processes to get around ICANN’s rules for gTLD sales. The IETF and dnsop would be wise to steer well away from that. Although I realise that train has kind of left the station already because of .onion, I think the WG and the IETF has to minimise the risk of getting embroiled in further collateral damage and layer-9+ food fights over TLDs. I still don’t see why a special TLD has to be set aside or needed for these alternate name spaces. What can be done with .alt that couldn’t be equally done in (say) alt.arpa? The ID says nothing on that issue. Or why alternate name spaces that aren’t part of the DNS need to be somehow anchored in the DNS. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
