Thank you for your comments.
On Aug 13, 2018, at 3:26 PM, John C Klensin <john-ietf@xxxxxxx> wrote:
> 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.
Thanks! That's mostly due to the WG, not the authors.
> 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.
The IETF has a recent history of writing clarifying terminology documents whose intention is to say "here is the best way to define some terms" without saying "these are the definitions and all others are now wrong". For example, BCP 166 / RFC 6365, "Terminology Used in Internationalization in the IETF", tries to clarify some of the widely used words and phrases in internationalization. That BCP says:
As in many fields, there is disagreement in the internationalization
community on definitions for many words. The topic of language
brings up particularly passionate opinions for experts and non-
experts alike. This document attempts to define terms in a way that
will be most useful to the IETF audience.
That BCP also has conflicting definitions of common terms, such as for "glyph".
> 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.
As Viktor just pointed out, your example *can* be a domain name, even in the current DNS. The fact that is it typically not a domain name is irrelevant to the accuracy of the definition. Who do you believe would be more confused by such an accurate definition?
> 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.
1) Why is this different than BCP 166? As you certainly remember, it's not like the definitions for internationalization are that much more concrete than those for the DNS.
2) The DNOP WG decided that this draft updates RFC 2308, which is on standards track. As RFC 2026 says:
The BCP subseries of the RFC series is designed to be a way to
standardize practices and the results of community deliberations. A
BCP document is subject to the same basic set of procedures as
standards track documents and thus is a vehicle by which the IETF
community can define and ratify the community's best current thinking
on a statement of principle or on what is believed to be the best way
to perform some operations or IETF process function.
> 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).
Given the above definition of what a BCP is, a BCP certainly can update a standards-track document.
> Doing otherwise risks creating
> significant confusion as to what the standard actually is or is
> not.
Who do you feel will be confused? The IETF has a long history of standards track documents being updated by later standards track documents.
> 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.
Thank you for noticing this! (You can also read that as "Yipes!") Appendix A should absolutely have a bullet that says "QNAME in [RFC2308]". I have just done a careful review of every instance of "2308" in the document and believe that only QNAME and "forwarder" were updated from RFC2308.
--Paul Hoffman
