Paul,
Thanks for the thorough response. A few additional comments
below; I consider all of these to fall into the "things that
should be considered as the document is evaluated" category, not
anything resembling showstoppers.
--On Monday, August 13, 2018 23:56 +0000 Paul Hoffman
<paul.hoff...@icann.org> wrote:
>...
>> 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".
Absolutely. And, of course, I'm familiar with 6365. IIR, we
were very sensitive about that problem when 6365 was being
assembled and tried very hard to make it clear, with the "As in
many fields...", sentence you quote above as part of that
effort. When I read the Introduction to
draft-ietf-dnsop-terminology-bis-12 (checked the current version
today), I don't get nearly that much clarity. Instead, I see
language about terminology having evolved (which is fine) and
consensus about the definitions, where the latter is, absent
qualifying language, usually IETF-speak for "standard" or "what
everyone else is doing and you should do too". Nothing in this
draft leaps out at me as a invocation of that principle from
6365 -- certainly its comment that 6365 contains terminology,
some of which is about the DSN, does not incorporate that
terminology model by reference. I assume that the WG does not
expect that model to be assumed from the observation that this
is a terminology document.
The document does mention "other organizations", specifically
the WHATWG spec and RSSAC lexicon, as additional sources of
definitions. If you, and the WG and community, believe that
does the job that the quoted sentence from 6365 does (or was
intended to do), I'm ok with that -- I may just be oversensitive
to the issue. If not, it would, IMO, be better to include a
very similar sentence here, perhaps at the beginning of that
"Other organizations" paragraph, than to leave it to the user to
infer that intent.
>...
>> 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?
Actually, I was relying somewhat on the definitions/ statement
in RFC 1123. Obviously, if one makes sufficient distinctions
between what you call the public DNS and others sorts of domain
names (non-public but derived from or assuming 1034/1035 or
using the even broader definition of "domain name" in Section
2), it can be one of those. But, referring partially to other
notes, as the IETF (and ICANN) have discussed several times in
the past, that odd-sounding "will not" language was chosen to
avoid having the IETF make (and standardize) an assertion that
was well out of its scope and authority (and well within that of
IANA at the time) rather than to imply that the statement was
any less normative. Sadly, Bob Braden isn't around to say
that again. From my point of view, although my note should
probably have said "could be a domain name in the public DNS"
rather than "is a domain name", the very fact that we are
discussing this again suggests well-established opportunities
for confusion.
In that regard, I find the document's definition of "split DNS"
a little bit frustrating, as I have seen (multiple times) a
distinction made between names (or a zone) that would clearly be
part of the public DNS except that they are hidden from view and
names that are part of a different hierarchical structure based
on a different root. That is a different case from names (even
fully-qualified ones) that different user can resolve but for
which they will get different results. It may also be different
from practices in CDNs to return different answers depending on
the presumed network location from which the question is being
asked, practices that presumably fall into your "view" category.
I can't make a case for holding up the document to try to sort
that out better, but it perhaps should be flagged as an
opportunity for future work.
>> 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.
See above. If this were as clear as BCP 166/ RFC 6365 about the
descriptive, rather than normative, character of the
definitions, I would have no problem. I don't think it is.
YMMD.
> 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.
>...
> Given the above definition of what a BCP is, a BCP certainly
> can update a standards-track document.
We obviously interpret that text differently, particularly
because I don't interpret the text starting with "define and
ratify..." as including "modifying a Standard" (or even a
Proposed Standard). Setting out current practices in, and
thinking about, terminology certainly falls within the BCP
range, especially when applied to principles and/or ways to
perform some operations, but, again, modifying a standard does
not appear to me to do so. I also note that even a "don't do
things that way" statement should, as I read 2026 and historical
practice, generally appear in an Applicability Statement with
"not recommended" language and not a BCP.
YMMD about this. If the IESG judges that there is consensus in
the community for a more relaxed definition in which BCPs can
change standards (and any maturity level), I hope that will be
documented in some clear, broadly-available, and archival way
because I'm sure it will sooner or later be cited as a precedent.
>...
>> 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.
Thanks. I appreciate the fix. I am a bit concerned that the
document got through WG review, several Area Review Team
reviews, presumably a shepherd's report, an AD decision to
initiate an IETF Last Call, etc., without that being spotted,
but that is presumably part of a broader problem.
Incidentally, I may be dreaming, but I thought an earlier
version of the I-D identified definitions that appeared in RFC
7719 and that are modified by this document. If that list
appears somewhere, I think it would be worth restoring. If it
does not, I'd prefer to let it go rather than making more work
or costing more time, but note that the IESG has periodically
insisted that, when one document updates or replaces
("obsoletes") another, the differences be explicitly identified.
best,
john
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
