On Jun 15, 2020, at 21:21, Tony Finch <d...@dotat.at> wrote: > Yes, that's why I pointed it out. The intro fairly explicitly says it's a > replacement for .lan (etc.), but that raises questions about how this > draft relates to other efforts to fix the .lan problem.
I think your reading of the text just indicates that it could be tightened up to be clearer, since I read it differently (it's a replacement choice, is my understanding). I think the presence of ambiguity is an indication that a working group could improve thiss document. >> 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 > > Can't we continue to point out that they are wrong and there are better > ways of solving their problems? I have wondered that myself, but I suppose there will always be people for whom registering a domain and keeping it registered is a worse answer than simply configuring something. I also don't find the technical arguments that apparently make a fake TLD a better choice than a registered domain very compelling. I have wondered aloud whether there is data to support the asssertion that people are squatting on TLDs because of a need, or by accident or for some other reason; whether or not using a non-delegated TLD is in fact more common than using a registered domain at an anchor today; whether use of non-delegated TLDs is growing along axes that strongly indicates that this is a widespread problem and not something isolated to a handful of vendors; whether that growth still looks like growth when it's normalised against other variables that are trending up and to the right, etc, etc, etc. However, given that this document only points out an option that already exist and doesn't actually recommend using a TLD versus any other anchor, I don't think any of that matters. I think it's up to another document to provide that kind of advice. It's hard to see any advantage in shoe-horning that advice into this one -- and the chances of such a document converging any time soon, regardless of venue. seem slim > I also appreciate that this draft is very clever, but speaking as an IOCCC > winner, very clever things can also be things you should never do in > production. I think the most clever thing about it is that it describes what is already there and doesn't ask any difficult questions or require any difficult decisions to be made. (Maybe your C code does that too, but if it does I presume that's not why you wouldn't run it in production :-) Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
