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

From: John C Klensin <[email-masked]>
Date: Mon, 03 Aug 2015 17:08:09 -0400

--On Tuesday, July 28, 2015 07:07 -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-dns-terminology-03.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
> 2015-08-11.
>...

Hi.  This is a long review, for which I apologize, but
draft-ietf-dnsop-dns-terminology-03 is a rather long document in
which I found a lot of difficulties. IMO, there are an unusually
large number of problems for a document in IETF Last Call.

The first four major (numbered) sections below are addressed to
the document and associated issues generally.  The remaining one
is about 75% of the review's length and addresses issues
associated with specific terms.

(1) _Status observation_: 

The fourth paragraph of the Introduction says:

   "During the development of this document, it became clear
   that some DNS-related terms are interpreted quite
   differently by different DNS experts.  Further, some terms
   that are defined in early DNS RFCs now have definitions
   that are generally agreed to that are different from the
   original definitions.  Therefore, the authors intend to
   follow this document with a substantial revision in the
   not-distant future.  That revision will probably have more
   in-depth discussion of some terms as well as new terms; it
   will also update some of the RFCs with new definitions."

To me, that is a statement that the document in unfinished or
at least that it does not represent "Best Current Practice".
If the authors and WG are convinced that a "substantial
revision" is needed very soon but that this version should be
published as a placeholder or for other reasons, then it should
be Informational, with only that follow-on document assigned to
the BCP category.  Otherwise, the WG should withdraw this draft
and finish the job.

If the intent is that this document describe the terminology
used by DNS experts to discuss the DNS (as one might infer from
the 3rd paragraph of the Introduction) and that the follow-on
document will be intended for more general community use, that
could justify publication of this document (plus or minus
suggestions such as those below) as BCP now, but then the
Title, Abstract, and Introduction need work to make the
audience clear.

Also as a status issue, some of the comments about a few of the
definitions appear to be normative statements about the use and
application of the DNS specs and not statements about
terminology at all.  Most or all of these reconfirm changes or
clarifications from earlier specifications, but still read
oddly --more like normative statements about protocols or
tutorials-- in a terminology document.  For example, read
through the "TTL" portion of Section 4 to see how much of it
defines what a TTL is (actual terminology) and how much of it
is a description of how TTLs are applied and used.

Alternately, if this document really is intended to clarify,
update, and revise terminology that has been used in the past,
it should be published as a Proposed Standard that updates the
relevant documents.  Some of the comments are certainly
consistent with what we normally consider "updating", but the
document fails to either identify what is being updated or to
discuss that, both of which the IESG ostensibly requires.

Several of the remarks about particular terms below comment
further on inconsistencies with a "best current practice"
document.

(2) _Usability: Finding terms_

Because this document is long and organized by categories that
might not be obvious to the reader, it would benefit
significantly from an alphabetical index of terms defined and
either numbering those terms (with the term number in the
index) or at least using the index to localize terms to the
sections in which they appear.  Without such an index or
similar organizational mechanism, I fear the document will be
nearly useless as a reference and that few people will read it
from beginning to end to determine which terms to use and
remember all of the definitions.  Documents like this are, at
least IMO, much more often used to find out what a term means
or determine whether it is being used appropriately; either of
those uses would strongly benefit from an index.

(3) _Procedural Observation_

For the terminology itself, I have not been following the
progress of this document in DNSOP so, if specific issues raised
below have been thoroughly discussed there and I don't raise new
issues about them, I'm happy to see things go ahead on the basis
of the WG's decisions.  However, note that, if any assertion of
prior discussions defies belief, I may ask for a pointer to
specific discussions in mailing list archives or meeting
minutes.  Many of the remarks below are quibbles but, IMO,
terminology documents are one of the places where we really
should quibble enough to get things right, lest they add to the
confusion, rather than reducing it.

Because some of the uses of these terms have been, as the
document points out, quite different historically or in other
contexts, I don't believe this document is adequate and should
be published unless it calls out the popular ones and identifies
them as inappropriate in IETF-DNS contacts at least. That is
done for several terms but not others, so the document is also
inconsistent.  Parts of this note (part 5 below) point out other
important examples.

(4) _The dot-foo problem (and a missing definition for
"dotless")_

Meta-definition: Despite the popularity of its usage, I believe
this document should not encourage the use of ".foo" to refer
to the "foo" TLD (as the document points out, if "foo" is an
FQDN, it is more properly written "foo.").  If we encourage
"dot-foo" (or ".foo"), at least without a lot more explanation,
we are only a step from "dot-label1.label2" (or to be precise
and difficult ".label1.label2." where "label1.label2." is the
name of any node that contains either delegation records or
non-delegated subdomains).  While its focus was somewhat
different and it never got any attention in DNSOP or elsewhere,
the expired
https://datatracker.ietf.org/doc/draft-klensin-dotless-terminology-harmful/
discusses another aspect of this problem.  One of its
implications for the present I-D is that, if organizations like
the IAB are going to use the term "dotless domain" as if it
meant something, "dotless" or "dotless domain" should appear in
the present I-D, even if to denounce its use.

(5) _Specific terms_

_Section 2_

"Host Name" and "Domain Name": It is probably worth noting that
not only is "host name" sometimes used to denote the first
label in an FQDN (as the document indicates) but that many
vendors have established a practice of setting up, e.g.,
configuration tables or options that distinguish between "host
name" with that definition and "domain" as the rest of the FQDN
with that label excluded.  Guilty parties include Windows (at
least through version 8.1), FreeBSD, Cisco (at least some
products), a few ICANN-accredited registrars, and probably many
more, so this cannot be dismissed as a fringe issue.

"Label": Binding "label" to "node" is a fine plan, but leaves
the fairly frequent practice of using a string with a dot
embedded in it as the owner of a node.  That is a practice that
makes the first substring of the label indistinguishable
lexically from a [delegated] subdomain (see below) of the
second substring.  This obviously interacts with the meaning of
the term "subdomain".  That term is used a few times in the
document but not defined.  At least because of this issue with
labels and the related question of whether a "subdomain" exists
only with a zone break, it seems imperative to me to define and
discuss it... or to discourage its use and otherwise get it out
of the document.

"Host Name" (again): Another popular definition of this term
associates it only with domain names that actually identify
hosts, i.e., it is the owner of a node that contains address
records and not only, e.g., delegation records, service
indicator records (MX, SRV, NAPTR, URI, etc.) or aliases (CNAME
or DNAME records).   It would be consistent with the rest of the
I-D to mention that usage, even if only to discourage it.

"IDN": I think it would be wise to be careful about two things
in this definition.  Because of them, it is probably not right.

   First, while IDNA2008 is quite specific about referring to
   labels, "IDN" has been popularly used in at least three
   other (and inconsistent) ways: (i) to describe FQDNs with at
   least one label that requires IDNA handling; (ii) for FQDNs
   and/or labels containing non-ASCII characters (including
   domain names that use UTF-8 or ISO 8859-x (typically 8859-1)
   directly in the DNS; (iii) and only those FQDNs all of whose
   labels (other than the root indicator) contain
   representations of non-ASCII characters.  Note that RFC 6055
   claims to be about "Internationalized Domain Names" and,
   among other things, discusses the second case.  I recommend
   the document explore those alternate meanings and then
   deprecate the use of "IDNs" in protocol-like discussions of
   the DNS (or elsewhere where precision is required) and
   focus on, e.g., "IDNA labels" or "IDNA2008 labels".  

   Second, there is the matter of whether a putative label that
   contains characters that must be processed into an A-label 
   or U-label for use with the DNS is reasonably referred to as
   an "IDN" or "IDN label" (a subject on which UTR 46 and
   various web-oriented documents contribute to the confusion).
   I believe this document needs to identify and discuss those
   distinctions, not just treat "IDN" as s synonym for
   something IDNA-ish.  While it is not (at least IMO) a
   sufficient solution for any of those issues, it would be
   reasonable to include an informative reference to RFC 6365
   in that definition for additional information.

"Alias": See the discussion of "subdomain" under "label" above.
Partially as a result, I don't know what this definition means.
I also suggest that ordinary and common usage of the term
"alias" means that the (fully-qualified) owner of a DNAME
record is an alias as well, and that "subdomains of the owner"
may additionally be aliases.

"Canonical name": the first sentence of this definition is
circular and "canonical name" is not actually defined.  I've
heard uses of "canonical name" to refer to fully-qualified
targets of fully-qualified owners of DNAMEs as well.  If the WG
doesn't like that usage, it would be appropriate to say
something.  I've never liked it, and RFC 5321 deliberately
avoids it, but I've also heard "canonical name" used to describe
the domain that appears in the RDATA of MX RRs. "Canonical
form", and sometimes "canonical name" have also been popular in
some communities to refer to the A-label or U-label form of an
IDN label (sic) after alias/ mapping processive via RFC 5895,
UTR 46, or other specifications.  It may be that we should start
moving away from the term in the context defined in the I-D and
start using "alias target" or something to that effect.

"Public suffix": the discussion of the "UK." (and, by the way,
"US.") zone would be clearer and the source of controversy more
obvious if the I-D explicitly pointed out that policy changes
have resulted in _both_, e.g., "ac.uk." and "uk." (and
"NH.US".  and "US.")  meeting the criteria for public
suffixes at the same time.

_Section 3_

Nit about apparently-missing definite articles: in the first
sentence, s/is first 12/is the first 12/ (or rewrite to use a
word like "comprise").  Similarly, the first sentence of the
next paragraph.  See also "...fields in the RDATA an SOA
resource..." later in the document, where the omission actually
makes the sentence hard to understand.  

"Referrals": "zone cut" is used here in a way that is critical
to the explanation but defined only in Section 6.  A
cross-reference or forward pointer would be in order.

_Section 4_

"RRset": This definition is consistent with the usage in
DNNSEC, i.e, that resources records with the same owner and
class but different types are not part of the same RRset.  That
is fine, but I've seen it used to encompass all of the records
that might be returned in response to a query for a particular
owner node with QTYPE=ANY, so, consistent with other sections
of the I-D, that other case should probably be mentioned (and,
obviously, deprecated).  Is there an approved term for the
collection of resource records with the same owner and, if so,
where is it in this document?  This definition would be much
stronger if it could say "This is an RRset; those other
categories of things that are its supersets are called X and
Y."

"Owner" and "SOA Field Names": One reason why "Owner name" (see
"Owner" paragraph) is often used is that the RNAME has been
referred to as "Owner" in dozens of documents and probably
uncountable numbers of  comments in zone files.  "Responsible
party" is also used, e.g., in RFC 1034.  It might be useful to
explicitly note that the I-D prefers the names given to pieces
of field formats in RFC 1035, just it elsewhere appears to
prefer names used in association with query responses rather
than those that describe the fields themselves (see comments
early in this review about status and audience).

"TTL": Errata, even "IESG approved" errata, don't change
standards-track documents at least unless the errors are
glaringly evident typographical errors (but still confusing
enough to justify errata).  Section 8 of RFC 2181 is extremely
clear about this and does update 1035, so it would be more
appropriate to replace "it is fixed in an erratum" with
something like "this is clarified in RFC 2181" or, "consistent
with an erratum, this is clarified in RFC 2181".  Given that
change and for editorial reasons, it would be better to
consolidate the two consecutive parenthetical remarks or to
incorporate the second one into the text.  See also comments
above about the tutorial, rather that terminology, nature of
much of this subsection, especially the next-to-last paragraph
("The reason that...").

"Class independent": While this definition seems ok to me, at
least given my limited knowledge, recent discussions on the IETF
list and elsewhere have been very negative about the actual
usability of CLASSes, at least on the public Internet. There
seem to multiple issues, of which one example is associated with
what a zone (or at least a master file) that contains records
from more than one CLASS means and how it is accessed and
another is associated with CLASS independence - a rather
sweeping claim for any RRTYPE that is not associated with the
structure of the DNS itself because it seriously constrains
later behavior and decisions.  Given those issues and especially
given some of the tutorial material elsewhere in this document,
it seems strange and possibly inappropriate to define Class
independence this way and to do so without any further
explanation.   See the discussion of "Priming" and other terms
below for additional examples of the dimensions of this rat
hole. Recommendation: unless the authors and WG have the energy
to discuss CLASSes in detail, drop this definition and put a
sentence or two into the introductory material that indicates
that CLASS use and terminology raise additional issues and are
deferred to other documents.  That gets them out of the
immediate critical path and, should the WG decide to deprecate
them, saves a lot of energy getting the terminology right.

_Section 5_

"Full resolver": if the intent is to deprecate the use of this
term because no one knows what it means and other, adequate,
terminology exists, that should be explicit.  Otherwise, this
section should either define what the term means or drop it:
the history of the term is, by itself, really not helpful or
consistent with the apparent scope of the document or "BCP"
assertions.

"Priming": Does the I-D want/need to mention CLASS here?  If a
resolver "performs queries for a name, type, and class" (see
"Resolver" definition), then this description of priming,
especially its relationship to _the_ (emphasis added) DNS root
zone, is not adequate.  Also see note on "Root zone" below.

"Secondary server" and "Primary server": Consistent with the
general documentation approach in this I-D, it may be worth
mentioning that "primary", "secondary", and "master" all appear
in RFC 1034.  For better or worse, "slave" does not.

I was surprised to not see "lame delegation" or "split horizon"
in this section, the latter possibly as part of "View".

_Section 6_

"Zone": See the comments about CLASS above.  As a terminology
document, this should be clear about whether "Zone with records
associated with different CLASSes" is even meaningful and, if
so, what it means.  Note that the old issue of the meaning of
QCLASS=ANY interacts with that question.  A different way to
state the issue is as a question: If a master file for a zone (a
term used, with small variations, several times in RFC 1034 but
not mentioned in this I-D) contains records that include several
different CLASSes, are those records all part of the same zone
or do they define different zones (noting that different
comments in RFC 1034/1035 can be read to give different
answers)?  If the I-D is going to touch CLASSes, I don't see how
to avoid these issues.

"Child" and "Parent": With all respect to RFC 7344, the
sentence quoted under "Child" is unlikely to be comprehensible
to anyone who doesn't already know what the term means.  The
one in "Parent" isn't much better and is almost circular.  Note
that "parent zone" and "children zones" (sic) are described and
used in RFC 1034 and the usage there seems more clear than
these definitions.  Also note that 1034 uses "subzone" which is
also used in this document but, like, "subdomain" is not
defined in the I-D.  Because, as hinted above, the question of
whether "subdomain" is actually a synonym of "subzone" can be
important, defining the terms and making any important
distinctions also seems important.  Also see "Empty
non-terminals" below.

"Origin" and elsewhere, particularly "Apex": The document needs
to clarify that terms like "top" and "apex" are related to the
hierarchical structure of the DNS, not other ways in which DNS
information can be organized (e.g., master files or DNSSEC
canonizalization).  If the document is to be used normatively,
i.e., describes Best Current Practice, it isn't acceptable to
say 'These days, this sense of "origin" and "apex" (defined
below) are often used interchangeably' without making a
recommendation as to whether that is a good idea. 

"Apex": If "top" is really a synonym, that should be said here.
If not, "top" should be deprecated or identified as historical,
informal, and/or non-preferred terminology.  Note that the
definition of "Authoritative data" uses "top node" (from
1034).

"Glue": The last sentence of this subsection strongly implies
that the terminology introduced in RFC 2181 is not preferred
for general use.  If that is the intent, please be explicit
about it; otherwise this document specifies two inconsistent
definitions for the same term.  I believe that latter is
inconsistent with publication as a BCP.

 "In-bailiwick": I have to admit this term (and its opposite)
are new to me.  I haven't figured out from the definition why
adding it adds clarity rather than more confusion.  See the
comments above about two, inconsistent, definitions and
publication as a BCP, unless the "best" current practice is
inconsistent usage.

"Authoritative data": If this is as ambiguous as the definition
/ statement suggests, is the Best Current Practice to not use
the term?  If so, say so.  If not, say why and where its use
should be considered acceptable.

"Empty non-terminals": this definition strongly suggests that
"subdomain" is a property of owner name structure and not of
zone relationships.  If that is the intent, it is _really_
important to define and clarify "subdomain".

"Occluded name": I don't think "in a limbo" is helpful as part
of this definition.  The nodes are just hidden and inaccessible
for resolution (i.e., inaccessible except as part of zone
transfers or to the authoritative servers themselves) until and
unless the occluding RRs are removed.  Perhaps "in purgatory" (a
state that might be easier to escape if enough virtuous acts
occur with respect to the zone), but I really can't recommend
going there.

"Fast flux DNS": Is "domain is bound in DNS" really intended
here or was that a typographical error for "... is found...". If
it was intentional, as I realize it was, it is confusing and a
definition of "bound in DNS" is required.  Hmm. I just read the
relevant section of RFC 6561 and now know what was intended.
This is still a horrible sentence that I'm astonished got by the
RFC Editor.  Perhaps it would be a lot more clear if the I-D
said something like "This occurs when a domain is bound to
multiple address records (and hence multiple IP addresses), each
of which has a very short Time-to-Live (TTL) value associated
with it".  It could, however, be simplified even further, and
made more consistent with the terminology used elsewhere in this
I-D, if it talked about owners and RRsets, noting that "one
RRset, one TTL value" rule implies that the TTLs cannot be
different very short values as the sentence of 6561 implies.
IMO, the I-D doesn't need to quote 6561 when it is clearly
confusing (and as the last sentence indicates, fairly clearly
too limiting); it should be entirely reasonable to paraphrase it
in a way that is obviously consistent but more clear.
  
	(That sentence of 6561 probably deserves an erratum
	suggesting a clarified form.  I hope someone will file
	it.)

_Section 7_

"Registry": This definition treats the Registry as both the
operational entity and the related policy entity.  As one goes
further down the tree, that is often the case, but, nearer the
apex of the DNS tree, the policy entity ("whoever decides what
data goes into a zone") may be very separate from the entity who
is often described as the "Registry operator" (a term that
probably belongs in this section or may, at the risk of more
confusion, be a synonym for "DNS Operator" (see below)).  There
may also be policy entities separate from the Registry who may
impose significant constraints on the names that can be placed
in the zone (including, btw, the IETF, especially if we continue
on the Special Names path).  One can avoid making those
distinctions by indicating that the definitions in the document
are written from a DNS point of view, but then a definition of
"Registrar" (or EPP, etc.) are probably not needed.  Note that
the document's definition of "DNS operator" interacts with this
distinction and reinforces the need for it.  It could even say
that, for some zones, the registry function actually consists of
a DNS operator and one or more relevant policy authorities who
decide what names the DNS operator may add, maintain, etc. See
also below.

"WHOIS": The I-D might take the description a step further and
explicitly say that the term "Whois data" or "Whois database"
is used as a synonym for "registry database" or "registrant
database" (regardless or whether accessed via the Whois
protocol or not), but that usage should be discouraged because
it causes confusion now and will cause more if, as the IETF
hopes, Whois is eventually replaced for Registry Data and
similar applications.  Also note that, while the original
application of Whois has largely fallen out of use, the
protocol is commonly used to access address registry databases,
databases that are not usually considered DNS databases (the
contents of the reverse-mapping zones subsidiary to ARPA. not
withstanding).

"DNS Operator": This definition is a little convoluted.  A
Registry Operator is almost certainly associated with a
Registry ahd hence operates (or contracts out the operation of)
servers that are authoritative for at least one zone.  But a
DNS Operator may be operating recursive servers and not operate
any servers that are authoritative for anything.  I think the
readers should understand that before getting to the end of
this definition and don't believe they will, especially because
"registry operator" is not defined and this definition starts
out by talking about authoritative servers.

_Section 8 and 9_

I hope that the number of issues identified in this review will
stimulate someone much more expert on DNSSEC than I am to
carefully review these sections; I have not attempted to do so.
However, I note that, in line with some of the comments above,
this section appears to contain several normative, updating,
clarifications of the various specifications which may not be
appropriate for a BCP terminology document.

Section 9 presents two sets of definitions that it says "differ
a bit", but makes no recommendations.  This would be entirely
reasonable in an Informational document whose purpose was to
warn readers that either definition might be in use and they
needed to exercise care.  It would be equally appropriate as an
informational explanation intended to lay the foundation for a
WG to clean up the mess by identifying one definition from each
pair as authoritative.  It is less reasonable in a BCP, at least
without a careful explanation about how inconsistent definitions
can both be "best practice".  In any of those cases, it would be
more useful if the definitions were formatted to allow the
reader to efficiently discover the differences: side by side,
one term and both definitions before the next term, or something
else that does not put the two sets of definitions on separate
pages (or worse as we move to alternate RFC presentation forms).

Despite my sense that this draft still needs a lot of work, a
serious effort to get DNS terminology clarified and under
control is long overdue and I thank the authors and WG for
taking it on.

     john

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 05 Aug 2015 11:47:24 -0700

> (1) _Status observation_:

Sure, we can go to Informational for this document. Our intention for 
the -bis RFC is to actually update the RFCs with definitions that we are 
changing, so that should be a BCP. Off-list, the authors agreed with 
your logic, so the next draft will say "Informational".

> those uses would strongly benefit from an index.

What you say is true only for the few people reading printed-out copies 
of the RFC. These days, most people read RFCs on their computers. People 
who are looking for a particular term can quickly skim the left column 
or use the search function of their favorite text editor, web browser, 
or PDF reader. (For historical reference, John and I disagreed about 
this when he and I co-authored RFC 6365.) Once we have the new RFC 
format and HTML representations of RFCs, indexes will become much more 
useful.

> confusion, rather than reducing it.

The WG quibbled quite extensively on this document, and there are many 
places where there is not wide agreement.

> the present I-D, even if to denounce its use.

No one in the WG expressed any concern about using ".foo" to describe 
the "foo" TLD. The term "dotless" does not appear in this document, and 
no one has asked for it, so it would be impossible to predict if adding 
it would include a denunciation. You may be one of the very few people 
who associate the common use of ".foo" with the term "dotless domain".

> more, so this cannot be dismissed as a fringe issue.

Saying that "some vendors" do something like that does not seem valuable 
to this document since it does not further the definition already in the 
document. "Some vendors" do lots of good/bad/weird things. This document 
is meant as a terminology list, not a full description of the deployed 
DNS. (John will understand why I said that last bit; he and I were faced 
with the same issues when we were doing RFC 6365. If you think DNS 
deployment is inconsistent, wander over to i18n world sometime...)

> discuss it... or to discourage its use and otherwise get it out

I'm unclear on what you mean by "as the owner of a node".

Good catch on the lack of definition of "subdomain", which is used twice 
in quoting other RFCs and once bare. Proposal:

    Subdomain: a label or group of contiguous labels that are a child of 
given domain.
    For example, in the host name "nnn.mmm.example.com", both "mmm" and 
"nnn.mmm" are
    subdomains of "example.com".

> I-D to mention that usage, even if only to discourage it.

I'm not seeing that in any RFCs, but I could be missing it. If you can 
send one example of that usage, it could certainly be added as a 
now-discouraged practice.

> focus on, e.g., "IDNA labels" or "IDNA2008 labels".

Given that RFC 6055 did indeed mix those definitions together, it might 
be better to simply refer to it for more description and leave the 
current cleaner definition alone.

> something IDNA-ish.

I doubt that this document needs to talk about what is and is not a 
"putative label", given that this is not a term at all common. The 
documents that are referred to in this document do that.

> While it is not (at least IMO) a

Sure.

> may additionally be aliases.

This is a definition quoted from a standards-track RFC. If it is wrong 
or misleading, it would be good fodder for the -bis of this document or 
as an update to that RFC.

> circular and "canonical name" is not actually defined.

And yet that is the definition directly from STD 13.

> I've

Because of that confusion, we have changed the example from ".uk" to 
".au" for the next draft.

> makes the sentence hard to understand.

Good catches. Will fix.

> cross-reference or forward pointer would be in order.

Yep.

> obviously, deprecated).

Can you point to an RFC or draft (even an antique one) that uses it in 
that sense? If not, we should probably leave it out, given that it is 
clearly wrong. If so, we should add it in the "deprecated usage" 
category.

> Is there an approved term for the

None that I know of, but others should chime in here if they do. If it 
exists, it would be a good term to include.

> early in this review about status and audience).

Yep, good addition.

> much of this subsection, especially the next-to-last paragraph

Sure. (Without agreeing with you about erratum never being able to 
change standards track documents; that discussion is for the IESG / IAB 
/ RFC Editor, not us.)

> explanation.

Why? The recent discussions on the IETF list would be less confusing if 
people read the definition in this draft.

> See the discussion of "Priming" and other terms

The fact that some people don't notice that some RTYPEs are not class 
independent does not lead to us not defining it.

> consistent with the apparent scope of the document or "BCP"

Disagree. It appears in an STD document without definition, and there 
was no later agreement on a definition. That fact is worth bringing up 
so no one thinks that they know what the STD means.

> zone, is not adequate.  Also see note on "Root zone" below.

The term "priming" applies to any class, so the current definition is 
fine as-is. There really isn't a good reason to bring up "but there 
might be other classes" in every definition that commonly is talking 
about IN.

> in RFC 1034.  For better or worse, "slave" does not.

Sure.

> in this section, the latter possibly as part of "View".

No one in the WG asked for them. If we are going to add them now, we 
would need to get WG consensus on the wording, which could be 
problematic in both cases.

> answers)?  If the I-D is going to touch CLASSes, I don't see how

I do. You are asking for definitions for things that have not been 
defined before. If the RFCs are not clear on whether or not a master 
file can have X, it is better to update those RFCs, not make up a new 
term with a definition that is clearer.

> distinctions also seems important.  Also see "Empty

The WG discussed these definitions and came to this. If you have 
specific better definitions, but all means suggest them and we can see 
if the WG likes them better.

> recommendation as to whether that is a good idea.

We agreed above that this doc is no longer BCP. When we do the -bis as 
BCP, it would be good to hear your guidelines for what a BCP definitions 
document must say for definitions like this. [tag1]

> definition of "Authoritative data" uses "top node" (from

"Top" is not a synonym for "apex", but "top node of the zone" is. That's 
what the draft says.

> inconsistent with publication as a BCP.

See [tag1] above.

> publication as a BCP, unless the "best" current practice is

See [tag1] above.

> should be considered acceptable.

See [tag1] above.

> important to define and clarify "subdomain".

Yep; see the proposed definition above.

> occur with respect to the zone), but I really can't recommend

We would prefer to quote standards track documents directly here.

> here or was that a typographical error for "... is found...".

"found". Will fix with a note that the quoted text has a typo.

> If

I'll do so.

> "Registrar" (or EPP, etc.) are probably not needed.

Agree that adding the "from a DNS point of view" for "registry". 
Disagree about "registrar" not being needed: it is a commonly-used term.

> Note that

Good addition.

> similar applications.

Good point.

> Also note that, while the original

Yep.

> out by talking about authoritative servers.

This was discussed in the WG (with me agreeing with your desire about 
recursive operators), but the rough consensus was with what is here now.

> appropriate for a BCP terminology document.

See [tag1] above. Also, discussions about DNSSEC are as prone to 
definition creep as discussions about DNS.

> pages (or worse as we move to alternate RFC presentation forms).

See [tag1] above.

> control is long overdue and I thank the authors and WG for

When Andrew and I started this, I hilariously, naïvely said that this 
would be easier than the i18n terminology document.

--Paul Hoffman