Stephane, Thanks for reading the draft and for your comments. I will study them and see what I can do and will get back to you if I have questions. One general observation: I've tried, when mentioning possible alternate approaches, to provide a partial existence proof that alternatives are possible that could do the job or improve things, not to propose solutions or to be comprehensive able possibilities. Fro example, the blockchain example was mentioned because it is one way -- a way that has gotten a lot of attention lately -- to have an authoritative structured name system without having a hierarchical system and centrally-managed root. I didn't mean to suggest that it was the only such option (it isn't) or the best one (I suspect it is not).
As to whether DNSOP wants to get involved, while there are operational issues in the summary I'm trying to make, I see most of them as being consequences of protocol choices that were either poor to start with (like the underspecification of CLASS), poor (more historically than at present) implementations, or that just have not held up (i.e., failed 30-odd years ago to adequately predict the present). So, while I'm sure there are people on the DNSOP list who are, or should be, very interested in the question of whether we are pushing the DNS past its practical limits, I don't see that as specifically an operational problem. Instead, I see it as an issue that affects much of the IETF. That is especially true if, as one person who commented believes, a transition to a DNSng could be more difficult and take longer than the IPv4-> IPv6 transition. In addition, while I would welcome help or even a contributor or co-author or two, I think there are a number of reasons why the contents of this I-D are more appropriately an Independent Submission than any sort of IETF stream document (even an Informational one) that would require a consensus determination. best, john --On Tuesday, June 6, 2017 22:04 +0200 Stephane Bortzmeyer <bortzme...@nic.fr> wrote: > 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
