On Jun 15, 2020, at 18:46, Tony Finch <d...@dotat.at> wrote: > The intro to this draft talks about things like x- which has been > deprecated since RFC 6648. It mentions some situationw where .test or > ..invalid would seem to be the right things to use, but it doesn't say why > not. It lists a bunch of TLDs that are being squatted by devices that > ought to move to home.arpa instead, but doesn't say why we have given up > on that idea after only a couple of years, or why we should expect them to > move to ISO 3166 reserved codes when they haven't moved to home.arpa.
I don't remember any text in the document that talked about people changing what they are doing. I thought the point of it was to provide some guidance for people who have decided (for whatever reason) that they have a use for a private namespace anchored by a TLD but who haven't decided what to use yet. Personally, I think the right advice for most people is that if you must use private namespace you should anchor it at a domain name in the global namespace that you control, so that your namespace is both private and unique. Someone should write that document. I'll help, if someone is interested. But draft-arends-pitchfork-pitchfork-burn-the-witch doesn't provide that kind of general advice; it provides specific advice for the case where people have decided that a TLD is definitely needed by pointing out that the 3166 people have already reserved a label for them to use and that current ICANN policy is that such label will never clash with a real (non-private) TLD. Note that without this document, the above will still be true. The two-character codes mentioned in this document will still be available for use for whatever purpose people can dream up, and will still not be delegated by ICANN. This document just writes it down so that people don't have to do the consderable homework to reach that conclusion themselves. I continue to think that using policy that already exists to solve a problem that apparently some poeple have without asking anybody to change anything at all is a thing of great and enduring beauty, and I'm quite surprised that so many people are trying to hard to turn it into something more difficult to agree with. Perhaps we've all been deprived of mic lines for long enough that we have some pent-up need to make things complicated. Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop