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-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-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 ietf@xxxxxxxx mailing lists by
> 2018-08-13. Exceptionally, comments may be sent to
> iesg@xxxxxxxx instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
