DNS Terminology
draft-ietf-dnsop-dns-terminology-05

I'm balloting "yes" because I think a document like this should exist. But I share the question others have raised about why publish this version if a newer version is coming soon.

A few other minor comments:

This is listed as informational, but it was last called as a BCP. I'm not sure if that matters, since a BCP would have been held to as high or higher a standard than an informational RFC.

The shepherd's answer to question 7 does not address the question about whether authors have confirmed that they have complied with the IPR rules.

SoA gets mentioned a few times, but If there is a definition, I failed to find it.

This is a really great resource. Thank you for putting it together.

I had a few points where I wasn't understanding the text as well as I'd hoped. I offer them, in case you see better ways to explain things, but no response is needed if the answer is "Spencer just needs to pay attention".

If this 

      For example, at the time this document is published, the "au" TLD
      is not considered a public suffix, but the "com.au" domain is.
      (Note that this example might change in the future.)
      
is intended to say that a subdomain may be a public suffix when its domain is not, that could be stated more clearly. If it's intended to say something else, I don't know what that is (and "For example" didn't help!)

In this text

      Some servers do not honor the TTL on an
      RRset from the authoritative servers, such as when the
      authoritative data has a very short TTL.
      
I wasn't sure what "do not honor" meant - discarding the RRset before the TTL has expired, hanging onto the RRset after the TTL has expired, or flipping a coin?

In this text

   DNSSEC-aware and DNSSEC-unaware:  Section 2 of [RFC4033] defines many
      types of resolvers and validators, including "non-validating
      security-aware stub resolver", "non-validating stub resolver",
      "security-aware name server", "security-aware recursive name
      server", "security-aware resolver", "security-aware stub
      resolver", and "security-oblivious 'anything'".  However, "DNSSEC-
      aware" and "DNSSEC-unaware" are used in later RFCs, but never
      formally defined.  (Note that the term "validating resolver",
      which is used in some places in those documents, is nevertheless
      not defined in that section.)
      
so, there's no formal definition anywhere? Maybe that could be the first thing that this list item says? It's somewhat buried under all the terms that ARE defined, which seems backwards.

I'm also slightly confused about why "validating resolver" is mentioned in this list item, instead of appearing in a separate list item. Is the common element that it's not defined anywhere else, either?

Thanks for this. 

Is a domain a sub-domain of itself? Do we care? The definition
of Alias might imply that we do. Not sure.