draft-klensin-dns-function-considerations is an interesting document so I take the liberty to copy dnsop, which may be interested.
A few remarks about the -01 version: It does not seem to mention other naming systems, except a short reference to "blockchains" (there are many of naming systems, each with different strengthes and weaknesses than the DNS). I do not suggest to enumerate them all, rather to note they exist, and The Solution may not be a replacement of the DNS but a coexistence of the DNS with other naming systems (I have trouble believing that one day, we will have One Perfect Naming System). > 3.1. Multiple address types In this section, and in some others, I think that you mix problem description and solutions. For this problem (getting both A and AAAA records with a single query), there is the solution you mention (QTYPE=ADDR) but there is also having several questions in the Question section. Same issue in "3.13.2. Extensions and Deployment Pressures -- The TXT RRTYPE" where you mention a solution (new RR types) and not another one (TXT records below the apex). > perceived discrimination against some languages Scripts, not languages. And "perceived" is offensive: it _is_ a discrimination (although we agree there is no obvious solution). > it does not appear that any of them are as satisfactory as a system > with query privacy designed in might be. Both QNAME minimization (RFC 7816) and DNS encryption (RFC 7858) have seen very little deployment today, so I don't think we can already conclude they are not satisfactory. > The DNS model of master and slave servers, with the latter > initiating updates based on TTL values, The slaves don't use the TTL values, don't they? > a subject that is intensely controversial with regard to who should > control those servers [the root name servers], how they should be > distributed and where they should be located. The problem is only partly technical. For instance, with today's DNS, it is already possible to have more root name servers (not thousands, OK, because of the size of the priming response, but dozens, certainly). This would partially address the problem. > A key design element of the original network object naming systems > for the ARPANET, largely inherited by the DNS, was that the names > were identifiers and their being highly distinguishable and not > prone to ambiguity was important. If the main (and may be only) goal were to have unambiguous identifiers, digits would have been sufficient (a SHA-256 hash is an unambigous identifier, see RFC 6920). Unlike what you say, from the beginning, domain names have been expressing "thoughts and concepts". With a few exceptions, nobody registers "opaque" domain names. Editorial: > including a model for negotiating extended functionality [RFC2671] It is now RFC 6891. > and hard to illustrate in ASCII-only Internet-Drafts and RFCs We now have RFC 7997 :-) > Whether that would be desirable on not Or not? _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
