On 09/27/2016 02:37 AM, Warren Kumari wrote: > > My opinion really doesn't matter, but I happen to think that, at this > point, we should evaluate the requested P2P names according to RFC > 6761 -- you followed the process in effect *at the time*, and jumped > through many hoops. The process is far from perfect (see > draft-tldr-sutld-ps) but that *was* the process at that point, and so > your drafts should (IMO) be evaluated against that. If the IETF had > been able to quickly and clearly come to consensus that the process > was broken, and what to do to fix it, I might feel differently, but > changing the rules retroactively feels unfair. >
Thank you for your clarification. Indeed the discussion was long ago and details slipped from memory. > Interestingly enough, just above that mail, Stephane also objected to > "pseudo-TLD", but we asked the WG for a better term and (IIRC), didn't > get any better suggestions: > "Can you suggest a better term (noting that this term is used in both > RFC6761 and draft-grothoff-iesg-special-use-p2p-names-04)? > They are things that look like TLDs when leaking into the DNS context, > but are not actually TLDs. > I remember introducing the term 'pseudo-TLD' in the P2P Names draft and doing a similar research as the one I cut from your message for brevity. At the time I thought the Canada Dry effect would work: it looks like DNS, it tastes like DNS, but it's not DNS, hence 'pseudo'. But indeed that can as well bring confusion. I have no alternate suggestion at this point, but I have one to avoid talking about "squatting" names: "using names without ICANN sanction". It may be longer, but it's more accurate, and doesn't conflate a legitimate but often criminalized practice with a fact of usage that can stem from many reasons, one of them being the need of humans to name things. Using names without ICANN sanction also speaks to people who don't know why it's a problem, and places it in the correct context where the problem can then be solved. Except, of course, if that particular name represents a technical issue ;o) == hk _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
