IESG and others, Unfortunately and due to some other priorities, I have not been able to do a comprehensive review of this document. The following is based on reading through and trying to get an understanding of this rather long document and its many definitions, some of which are, as the document itself points out, somewhat controversial.
First, as far as the definitions are concerned and as far as I can tell, where a term appeared in RFC 7719 and the definition has been changed, almost every change is for the better. The authors and WG are to be commended for that. I do have some concerns that may be important. First and recognizing that some of what I'm concerned about now comes directly out of 7719, unless a definition is completely uncontroversial (i.e. the term is used the way the document says it is and has never been used, accepted, or interpreted in any other way in the community), treating a definition as normative or claiming consensus for it (without documented evidence) seems to me to put us on a difficult path: much as we might wish it, many people are unlikely to change their normal/historical usage just because we say so. If they don't, and this document appears to say "these are the definitions and all others are now wrong" (as it appears to do in many cases), we are likely to add to confusion rather than reducing it. Some of the language also appears to overreach a bit. To a first order approximation, I think the definition of a naming system is correct, but that is, in part, because I understand some of the terms used in that definition differently than others might understand them. Similarly, if a domain name is "An ordered list of one or more labels" and that definition is "independent of the DNS RFCs, and the definition here also applies to systems other than the DNS", then, absent a definition of "label" that is similarly broad and independent (and more specific than "An ordered list of zero or more octets", some things we are normally fairly sure are not domain names, e.g., the string 128.0.0.1, is a domain name. Probably don't want to go there -- it is certainly true in some cases, but one of this document's objectives, at least IMO, should be to never increase confusion. And so on. That leads me to a conclusion that might be painful. These same definitions were acceptable in 7719 because it made fairly clear that it was Informational and guidance, not normative. By promoting the document to BCP, I think we create new problems and/or an obligation to be far more clear about what is normative and what is not and what alternative uses of the terminology might exist. The document does very well about the latter for some terms but not for others and so, from that point of view, either needs more work or publication as Informational. The relationship to 2308 also seems problematic. That document is a Proposed Standard. This draft mostly references it for definitions and usage, which is fine. However, in the few places where it actually changes 2308, it appears to me that we run into the problem that, historically, we have never allowed a document that is not strictly standards-track (maturity levels and all) to update a standards-track document, with no exception for BCPs. So, if it is necessary to modify ("update") 2308, it would seem to me to be far preferable to create a standards-track document that does that, rather than putting a few words into this document (whether it is then published as Informational or as BCP). Doing otherwise risks creating significant confusion as to what the standard actually is or is not. In that same context, while I note that Appendix A and B describe changes from 7719, there is no explicit list of changes made to 2308, something the IESG normally requires in such updates. thanks for your consideration, john --On Monday, July 30, 2018 14:00 -0700 The IESG <iesg-secret...@ietf.org> 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-terminology-bis-11.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 i...@ietf.org mailing lists by > 2018-08-13. Exceptionally, comments may be sent to > i...@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop