Subject: Re: Last Call: <draft-ietf-dnsop-terminology-bis-11.txt> (DNS Terminology) to Best Current Practice

From: John C Klensin <[email-masked]>
Date: Mon, 13 Aug 2018 18:26:26 -0400

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 13 Aug 2018 19:03:32 -0400

> On Aug 13, 2018, at 6:26 PM, John C Klensin <[email-masked]> wrote:
> 
> the string 128.0.0.1, is a domain name

Yes, it is the presentation form of the domain name whose
list of labels is: "128", "0", "0", "1".  There is of course
no TLD named "1", so this domain is not registered, and it
would also not be a usable hostname, since many libraries
would treat it as a literal IP address instead.  And yet
it is still a domain name.

Indeed in a non-public network, I'm free to provision a
".1" TLD, and even create hosts as sub-domains of this name:

	example.128.0.0.1. IN A 192.0.2.1

perhaps making "128.0.0.1" an empty non-terminal.

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 13 Aug 2018 23:56:44 +0000

Thank you for your comments.

> authors and WG are to be commended for that.

Thanks! That's mostly due to the WG, not the authors.

> 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".

> to never increase confusion.

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?

> 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.

> 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
> 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

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

---

From: Tony Finch <[email-masked]>
Date: Tue, 14 Aug 2018 14:08:51 +0100

> ".1" TLD, and even create hosts as sub-domains of this name:

This would break a (non-normative) promise in RFC 1123

                                   However, a valid host name can never
           have the dotted-decimal form #.#.#.#, since at least the
           highest-level component label will be alphabetic.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
North Utsire, South Utsire: Variable, becoming southerly 3 or 4, occasionally
5 later. Smooth or slight. Rain later. Good, occasionally poor later.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 14 Aug 2018 13:31:06 +0000

Here we go with a thread on the set of Domain Names being a superset of host names again. ;)

On 8/14/18, 09:09, "DNSOP on behalf of Tony Finch" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Tony.
    -- 
    f.anthony.n.finch  <[email-masked]>  https://urldefense.proofpoint.com/v2/url?u=http-3A__dotat.at_&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=9G8-4P__AMgxNOQPiu7FkrImeieALKYtfGBE8UTuyg4&m=QjsPxg2u_w5HwqTk95P5eTu9RA87DRX8Va9nquK7g2I&s=NPniHZyF7bhbM8JRfkvKZTPrUgRkCZqoRFFeyAJKpe0&e=
    North Utsire, South Utsire: Variable, becoming southerly 3 or 4, occasionally
    5 later. Smooth or slight. Rain later. Good, occasionally poor later.
    
    _______________________________________________
    DNSOP mailing list
    [email-masked]
    https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=9G8-4P__AMgxNOQPiu7FkrImeieALKYtfGBE8UTuyg4&m=QjsPxg2u_w5HwqTk95P5eTu9RA87DRX8Va9nquK7g2I&s=l4QjBQfu1QpSZggF3IGNFfaWiORLQGuabec4DZAQEb8&e=

---

From: John C Klensin <[email-masked]>
Date: Wed, 15 Aug 2018 16:01:08 -0400

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
<[email-masked]> wrote:

>...
>> 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
>    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.

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
>> 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
>    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.
>...

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.

>...
>> 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

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 16 Aug 2018 08:11:51 +0200

On 15 Aug 2018, at 22:01, John C Klensin wrote:

> 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

Is it the case that various alternatives should be enumerated?

a. When a domain name is used for access to a service we might have:

a.1. The same DNS response regardless of who sends the query (this is the default for DNS)

a.2. Different responses depending on context (where query is sent from etc), but still same service (this is CDN)

b. When different services are accessed depending on context (enterprise setup)

b.1. A service is available or not depending on context, implemented via DNS response or not (version of a.1)

b.2. Different services are available depending on context, implemented via different DNS responses

c. The special case of (b) based on use of different root zone

:
:
:

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Thu, 16 Aug 2018 08:05:19 -0400

Patrik,

My personal view is that, if the same (or an extremely similar)
term is in use for the cases you enumerate, especially if most
of those who use it think they are saying something precise, we
are better off listing those cases and making the possible
confusion clear.  In particular, saying something that appears
to point to one particular case and ignoring the others is
likely to cause more problems than it solves.   For this case,
the current definition falls somewhere in between.  Partially, I
think, because it is a little vague it is not nearly as bad as
saying "this is the definitive definition and the term always
applies to this case" but not nearly as good as the sort of
enumeration you suggest.

best,
   john

--On Thursday, August 16, 2018 08:11 +0200 Patrik Fältström
<[email-masked]> wrote:

>> 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
>...

> a.2. Different responses depending on context (where query is
> sent from etc), but still same service (this is CDN)
> 
> b.1. A service is available or not depending on context,
> implemented via DNS response or not (version of a.1)
>