--On Tuesday, July 28, 2015 07:07 -0700 The IESG <iesg-secretary@xxxxxxxx> wrote: > The IESG has received a request from the Domain Name System > Operations WG (dnsop) to consider the following document: > - 'DNS Terminology' > <draft-ietf-dnsop-dns-terminology-03.txt> as Best Current > Practice > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send > substantive comments to the ietf@xxxxxxxx mailing lists by > 2015-08-11. >... Hi. This is a long review, for which I apologize, but draft-ietf-dnsop-dns-terminology-03 is a rather long document in which I found a lot of difficulties. IMO, there are an unusually large number of problems for a document in IETF Last Call. The first four major (numbered) sections below are addressed to the document and associated issues generally. The remaining one is about 75% of the review's length and addresses issues associated with specific terms. (1) _Status observation_: The fourth paragraph of the Introduction says: "During the development of this document, it became clear that some DNS-related terms are interpreted quite differently by different DNS experts. Further, some terms that are defined in early DNS RFCs now have definitions that are generally agreed to that are different from the original definitions. Therefore, the authors intend to follow this document with a substantial revision in the not-distant future. That revision will probably have more in-depth discussion of some terms as well as new terms; it will also update some of the RFCs with new definitions." To me, that is a statement that the document in unfinished or at least that it does not represent "Best Current Practice". If the authors and WG are convinced that a "substantial revision" is needed very soon but that this version should be published as a placeholder or for other reasons, then it should be Informational, with only that follow-on document assigned to the BCP category. Otherwise, the WG should withdraw this draft and finish the job. If the intent is that this document describe the terminology used by DNS experts to discuss the DNS (as one might infer from the 3rd paragraph of the Introduction) and that the follow-on document will be intended for more general community use, that could justify publication of this document (plus or minus suggestions such as those below) as BCP now, but then the Title, Abstract, and Introduction need work to make the audience clear. Also as a status issue, some of the comments about a few of the definitions appear to be normative statements about the use and application of the DNS specs and not statements about terminology at all. Most or all of these reconfirm changes or clarifications from earlier specifications, but still read oddly --more like normative statements about protocols or tutorials-- in a terminology document. For example, read through the "TTL" portion of Section 4 to see how much of it defines what a TTL is (actual terminology) and how much of it is a description of how TTLs are applied and used. Alternately, if this document really is intended to clarify, update, and revise terminology that has been used in the past, it should be published as a Proposed Standard that updates the relevant documents. Some of the comments are certainly consistent with what we normally consider "updating", but the document fails to either identify what is being updated or to discuss that, both of which the IESG ostensibly requires. Several of the remarks about particular terms below comment further on inconsistencies with a "best current practice" document. (2) _Usability: Finding terms_ Because this document is long and organized by categories that might not be obvious to the reader, it would benefit significantly from an alphabetical index of terms defined and either numbering those terms (with the term number in the index) or at least using the index to localize terms to the sections in which they appear. Without such an index or similar organizational mechanism, I fear the document will be nearly useless as a reference and that few people will read it from beginning to end to determine which terms to use and remember all of the definitions. Documents like this are, at least IMO, much more often used to find out what a term means or determine whether it is being used appropriately; either of those uses would strongly benefit from an index. (3) _Procedural Observation_ For the terminology itself, I have not been following the progress of this document in DNSOP so, if specific issues raised below have been thoroughly discussed there and I don't raise new issues about them, I'm happy to see things go ahead on the basis of the WG's decisions. However, note that, if any assertion of prior discussions defies belief, I may ask for a pointer to specific discussions in mailing list archives or meeting minutes. Many of the remarks below are quibbles but, IMO, terminology documents are one of the places where we really should quibble enough to get things right, lest they add to the confusion, rather than reducing it. Because some of the uses of these terms have been, as the document points out, quite different historically or in other contexts, I don't believe this document is adequate and should be published unless it calls out the popular ones and identifies them as inappropriate in IETF-DNS contacts at least. That is done for several terms but not others, so the document is also inconsistent. Parts of this note (part 5 below) point out other important examples. (4) _The dot-foo problem (and a missing definition for "dotless")_ Meta-definition: Despite the popularity of its usage, I believe this document should not encourage the use of ".foo" to refer to the "foo" TLD (as the document points out, if "foo" is an FQDN, it is more properly written "foo."). If we encourage "dot-foo" (or ".foo"), at least without a lot more explanation, we are only a step from "dot-label1.label2" (or to be precise and difficult ".label1.label2." where "label1.label2." is the name of any node that contains either delegation records or non-delegated subdomains). While its focus was somewhat different and it never got any attention in DNSOP or elsewhere, the expired https://datatracker.ietf.org/doc/draft-klensin-dotless-terminology-harmful/ discusses another aspect of this problem. One of its implications for the present I-D is that, if organizations like the IAB are going to use the term "dotless domain" as if it meant something, "dotless" or "dotless domain" should appear in the present I-D, even if to denounce its use. (5) _Specific terms_ _Section 2_ "Host Name" and "Domain Name": It is probably worth noting that not only is "host name" sometimes used to denote the first label in an FQDN (as the document indicates) but that many vendors have established a practice of setting up, e.g., configuration tables or options that distinguish between "host name" with that definition and "domain" as the rest of the FQDN with that label excluded. Guilty parties include Windows (at least through version 8.1), FreeBSD, Cisco (at least some products), a few ICANN-accredited registrars, and probably many more, so this cannot be dismissed as a fringe issue. "Label": Binding "label" to "node" is a fine plan, but leaves the fairly frequent practice of using a string with a dot embedded in it as the owner of a node. That is a practice that makes the first substring of the label indistinguishable lexically from a [delegated] subdomain (see below) of the second substring. This obviously interacts with the meaning of the term "subdomain". That term is used a few times in the document but not defined. At least because of this issue with labels and the related question of whether a "subdomain" exists only with a zone break, it seems imperative to me to define and discuss it... or to discourage its use and otherwise get it out of the document. "Host Name" (again): Another popular definition of this term associates it only with domain names that actually identify hosts, i.e., it is the owner of a node that contains address records and not only, e.g., delegation records, service indicator records (MX, SRV, NAPTR, URI, etc.) or aliases (CNAME or DNAME records). It would be consistent with the rest of the I-D to mention that usage, even if only to discourage it. "IDN": I think it would be wise to be careful about two things in this definition. Because of them, it is probably not right. First, while IDNA2008 is quite specific about referring to labels, "IDN" has been popularly used in at least three other (and inconsistent) ways: (i) to describe FQDNs with at least one label that requires IDNA handling; (ii) for FQDNs and/or labels containing non-ASCII characters (including domain names that use UTF-8 or ISO 8859-x (typically 8859-1) directly in the DNS; (iii) and only those FQDNs all of whose labels (other than the root indicator) contain representations of non-ASCII characters. Note that RFC 6055 claims to be about "Internationalized Domain Names" and, among other things, discusses the second case. I recommend the document explore those alternate meanings and then deprecate the use of "IDNs" in protocol-like discussions of the DNS (or elsewhere where precision is required) and focus on, e.g., "IDNA labels" or "IDNA2008 labels". Second, there is the matter of whether a putative label that contains characters that must be processed into an A-label or U-label for use with the DNS is reasonably referred to as an "IDN" or "IDN label" (a subject on which UTR 46 and various web-oriented documents contribute to the confusion). I believe this document needs to identify and discuss those distinctions, not just treat "IDN" as s synonym for something IDNA-ish. While it is not (at least IMO) a sufficient solution for any of those issues, it would be reasonable to include an informative reference to RFC 6365 in that definition for additional information. "Alias": See the discussion of "subdomain" under "label" above. Partially as a result, I don't know what this definition means. I also suggest that ordinary and common usage of the term "alias" means that the (fully-qualified) owner of a DNAME record is an alias as well, and that "subdomains of the owner" may additionally be aliases. "Canonical name": the first sentence of this definition is circular and "canonical name" is not actually defined. I've heard uses of "canonical name" to refer to fully-qualified targets of fully-qualified owners of DNAMEs as well. If the WG doesn't like that usage, it would be appropriate to say something. I've never liked it, and RFC 5321 deliberately avoids it, but I've also heard "canonical name" used to describe the domain that appears in the RDATA of MX RRs. "Canonical form", and sometimes "canonical name" have also been popular in some communities to refer to the A-label or U-label form of an IDN label (sic) after alias/ mapping processive via RFC 5895, UTR 46, or other specifications. It may be that we should start moving away from the term in the context defined in the I-D and start using "alias target" or something to that effect. "Public suffix": the discussion of the "UK." (and, by the way, "US.") zone would be clearer and the source of controversy more obvious if the I-D explicitly pointed out that policy changes have resulted in _both_, e.g., "ac.uk." and "uk." (and "NH.US". and "US.") meeting the criteria for public suffixes at the same time. _Section 3_ Nit about apparently-missing definite articles: in the first sentence, s/is first 12/is the first 12/ (or rewrite to use a word like "comprise"). Similarly, the first sentence of the next paragraph. See also "...fields in the RDATA an SOA resource..." later in the document, where the omission actually makes the sentence hard to understand. "Referrals": "zone cut" is used here in a way that is critical to the explanation but defined only in Section 6. A cross-reference or forward pointer would be in order. _Section 4_ "RRset": This definition is consistent with the usage in DNNSEC, i.e, that resources records with the same owner and class but different types are not part of the same RRset. That is fine, but I've seen it used to encompass all of the records that might be returned in response to a query for a particular owner node with QTYPE=ANY, so, consistent with other sections of the I-D, that other case should probably be mentioned (and, obviously, deprecated). Is there an approved term for the collection of resource records with the same owner and, if so, where is it in this document? This definition would be much stronger if it could say "This is an RRset; those other categories of things that are its supersets are called X and Y." "Owner" and "SOA Field Names": One reason why "Owner name" (see "Owner" paragraph) is often used is that the RNAME has been referred to as "Owner" in dozens of documents and probably uncountable numbers of comments in zone files. "Responsible party" is also used, e.g., in RFC 1034. It might be useful to explicitly note that the I-D prefers the names given to pieces of field formats in RFC 1035, just it elsewhere appears to prefer names used in association with query responses rather than those that describe the fields themselves (see comments early in this review about status and audience). "TTL": Errata, even "IESG approved" errata, don't change standards-track documents at least unless the errors are glaringly evident typographical errors (but still confusing enough to justify errata). Section 8 of RFC 2181 is extremely clear about this and does update 1035, so it would be more appropriate to replace "it is fixed in an erratum" with something like "this is clarified in RFC 2181" or, "consistent with an erratum, this is clarified in RFC 2181". Given that change and for editorial reasons, it would be better to consolidate the two consecutive parenthetical remarks or to incorporate the second one into the text. See also comments above about the tutorial, rather that terminology, nature of much of this subsection, especially the next-to-last paragraph ("The reason that..."). "Class independent": While this definition seems ok to me, at least given my limited knowledge, recent discussions on the IETF list and elsewhere have been very negative about the actual usability of CLASSes, at least on the public Internet. There seem to multiple issues, of which one example is associated with what a zone (or at least a master file) that contains records from more than one CLASS means and how it is accessed and another is associated with CLASS independence - a rather sweeping claim for any RRTYPE that is not associated with the structure of the DNS itself because it seriously constrains later behavior and decisions. Given those issues and especially given some of the tutorial material elsewhere in this document, it seems strange and possibly inappropriate to define Class independence this way and to do so without any further explanation. See the discussion of "Priming" and other terms below for additional examples of the dimensions of this rat hole. Recommendation: unless the authors and WG have the energy to discuss CLASSes in detail, drop this definition and put a sentence or two into the introductory material that indicates that CLASS use and terminology raise additional issues and are deferred to other documents. That gets them out of the immediate critical path and, should the WG decide to deprecate them, saves a lot of energy getting the terminology right. _Section 5_ "Full resolver": if the intent is to deprecate the use of this term because no one knows what it means and other, adequate, terminology exists, that should be explicit. Otherwise, this section should either define what the term means or drop it: the history of the term is, by itself, really not helpful or consistent with the apparent scope of the document or "BCP" assertions. "Priming": Does the I-D want/need to mention CLASS here? If a resolver "performs queries for a name, type, and class" (see "Resolver" definition), then this description of priming, especially its relationship to _the_ (emphasis added) DNS root zone, is not adequate. Also see note on "Root zone" below. "Secondary server" and "Primary server": Consistent with the general documentation approach in this I-D, it may be worth mentioning that "primary", "secondary", and "master" all appear in RFC 1034. For better or worse, "slave" does not. I was surprised to not see "lame delegation" or "split horizon" in this section, the latter possibly as part of "View". _Section 6_ "Zone": See the comments about CLASS above. As a terminology document, this should be clear about whether "Zone with records associated with different CLASSes" is even meaningful and, if so, what it means. Note that the old issue of the meaning of QCLASS=ANY interacts with that question. A different way to state the issue is as a question: If a master file for a zone (a term used, with small variations, several times in RFC 1034 but not mentioned in this I-D) contains records that include several different CLASSes, are those records all part of the same zone or do they define different zones (noting that different comments in RFC 1034/1035 can be read to give different answers)? If the I-D is going to touch CLASSes, I don't see how to avoid these issues. "Child" and "Parent": With all respect to RFC 7344, the sentence quoted under "Child" is unlikely to be comprehensible to anyone who doesn't already know what the term means. The one in "Parent" isn't much better and is almost circular. Note that "parent zone" and "children zones" (sic) are described and used in RFC 1034 and the usage there seems more clear than these definitions. Also note that 1034 uses "subzone" which is also used in this document but, like, "subdomain" is not defined in the I-D. Because, as hinted above, the question of whether "subdomain" is actually a synonym of "subzone" can be important, defining the terms and making any important distinctions also seems important. Also see "Empty non-terminals" below. "Origin" and elsewhere, particularly "Apex": The document needs to clarify that terms like "top" and "apex" are related to the hierarchical structure of the DNS, not other ways in which DNS information can be organized (e.g., master files or DNSSEC canonizalization). If the document is to be used normatively, i.e., describes Best Current Practice, it isn't acceptable to say 'These days, this sense of "origin" and "apex" (defined below) are often used interchangeably' without making a recommendation as to whether that is a good idea. "Apex": If "top" is really a synonym, that should be said here. If not, "top" should be deprecated or identified as historical, informal, and/or non-preferred terminology. Note that the definition of "Authoritative data" uses "top node" (from 1034). "Glue": The last sentence of this subsection strongly implies that the terminology introduced in RFC 2181 is not preferred for general use. If that is the intent, please be explicit about it; otherwise this document specifies two inconsistent definitions for the same term. I believe that latter is inconsistent with publication as a BCP. "In-bailiwick": I have to admit this term (and its opposite) are new to me. I haven't figured out from the definition why adding it adds clarity rather than more confusion. See the comments above about two, inconsistent, definitions and publication as a BCP, unless the "best" current practice is inconsistent usage. "Authoritative data": If this is as ambiguous as the definition / statement suggests, is the Best Current Practice to not use the term? If so, say so. If not, say why and where its use should be considered acceptable. "Empty non-terminals": this definition strongly suggests that "subdomain" is a property of owner name structure and not of zone relationships. If that is the intent, it is _really_ important to define and clarify "subdomain". "Occluded name": I don't think "in a limbo" is helpful as part of this definition. The nodes are just hidden and inaccessible for resolution (i.e., inaccessible except as part of zone transfers or to the authoritative servers themselves) until and unless the occluding RRs are removed. Perhaps "in purgatory" (a state that might be easier to escape if enough virtuous acts occur with respect to the zone), but I really can't recommend going there. "Fast flux DNS": Is "domain is bound in DNS" really intended here or was that a typographical error for "... is found...". If it was intentional, as I realize it was, it is confusing and a definition of "bound in DNS" is required. Hmm. I just read the relevant section of RFC 6561 and now know what was intended. This is still a horrible sentence that I'm astonished got by the RFC Editor. Perhaps it would be a lot more clear if the I-D said something like "This occurs when a domain is bound to multiple address records (and hence multiple IP addresses), each of which has a very short Time-to-Live (TTL) value associated with it". It could, however, be simplified even further, and made more consistent with the terminology used elsewhere in this I-D, if it talked about owners and RRsets, noting that "one RRset, one TTL value" rule implies that the TTLs cannot be different very short values as the sentence of 6561 implies. IMO, the I-D doesn't need to quote 6561 when it is clearly confusing (and as the last sentence indicates, fairly clearly too limiting); it should be entirely reasonable to paraphrase it in a way that is obviously consistent but more clear. (That sentence of 6561 probably deserves an erratum suggesting a clarified form. I hope someone will file it.) _Section 7_ "Registry": This definition treats the Registry as both the operational entity and the related policy entity. As one goes further down the tree, that is often the case, but, nearer the apex of the DNS tree, the policy entity ("whoever decides what data goes into a zone") may be very separate from the entity who is often described as the "Registry operator" (a term that probably belongs in this section or may, at the risk of more confusion, be a synonym for "DNS Operator" (see below)). There may also be policy entities separate from the Registry who may impose significant constraints on the names that can be placed in the zone (including, btw, the IETF, especially if we continue on the Special Names path). One can avoid making those distinctions by indicating that the definitions in the document are written from a DNS point of view, but then a definition of "Registrar" (or EPP, etc.) are probably not needed. Note that the document's definition of "DNS operator" interacts with this distinction and reinforces the need for it. It could even say that, for some zones, the registry function actually consists of a DNS operator and one or more relevant policy authorities who decide what names the DNS operator may add, maintain, etc. See also below. "WHOIS": The I-D might take the description a step further and explicitly say that the term "Whois data" or "Whois database" is used as a synonym for "registry database" or "registrant database" (regardless or whether accessed via the Whois protocol or not), but that usage should be discouraged because it causes confusion now and will cause more if, as the IETF hopes, Whois is eventually replaced for Registry Data and similar applications. Also note that, while the original application of Whois has largely fallen out of use, the protocol is commonly used to access address registry databases, databases that are not usually considered DNS databases (the contents of the reverse-mapping zones subsidiary to ARPA. not withstanding). "DNS Operator": This definition is a little convoluted. A Registry Operator is almost certainly associated with a Registry ahd hence operates (or contracts out the operation of) servers that are authoritative for at least one zone. But a DNS Operator may be operating recursive servers and not operate any servers that are authoritative for anything. I think the readers should understand that before getting to the end of this definition and don't believe they will, especially because "registry operator" is not defined and this definition starts out by talking about authoritative servers. _Section 8 and 9_ I hope that the number of issues identified in this review will stimulate someone much more expert on DNSSEC than I am to carefully review these sections; I have not attempted to do so. However, I note that, in line with some of the comments above, this section appears to contain several normative, updating, clarifications of the various specifications which may not be appropriate for a BCP terminology document. Section 9 presents two sets of definitions that it says "differ a bit", but makes no recommendations. This would be entirely reasonable in an Informational document whose purpose was to warn readers that either definition might be in use and they needed to exercise care. It would be equally appropriate as an informational explanation intended to lay the foundation for a WG to clean up the mess by identifying one definition from each pair as authoritative. It is less reasonable in a BCP, at least without a careful explanation about how inconsistent definitions can both be "best practice". In any of those cases, it would be more useful if the definitions were formatted to allow the reader to efficiently discover the differences: side by side, one term and both definitions before the next term, or something else that does not put the two sets of definitions on separate pages (or worse as we move to alternate RFC presentation forms). Despite my sense that this draft still needs a lot of work, a serious effort to get DNS terminology clarified and under control is long overdue and I thank the authors and WG for taking it on. john