DNS Terminology
RFC 7719

Note: This ballot was opened for revision 03 and is now closed.

(Ben Campbell) Yes

Comment (2015-09-16 for -04)
No email
send info
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.

(Spencer Dawkins) Yes

Comment (2015-09-16 for -04)
No email
send info
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?

(Stephen Farrell) Yes

Comment (2015-09-15 for -04)
No email
send info
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.

(Joel Jaeggli) Yes

Barry Leiba Yes

(Kathleen Moriarty) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Comment (2015-09-16 for -04)
No email
send info
Thanks for this document.

- Reading first the write-up, I started to wonder about the rationale to produce a terminology document as BCP?
I re-read RFC 2026, and concluded that BCPs should document standardize practive.
Then I realized the diff between version 3 and 4 :-) 

- From the shepherd writeup: 
"One issue raised by the Working Group was that such a list of definitions would be best served with some sort of Index. 
The authors and the Document Shepherd agree, but feel it would be better served being handled during the editing process."
What/when is the editing process? AUTH48? Why wait?

- "Most of the definitions here are believed to be the consensus
definition of the DNS community - both protocol developers and
operators."
I hope we can write: "Most of the definitions here are the consensus
definition of the DNS community - both protocol developers and
operators.", leaving no doubts about the process.

- "Further, some terms that
   are defined in early DNS RFCs now have definitions that are generally
   agreed to, but 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."

You lost me here. Do you want a new revision of this document, or revisions of early DNS RFCs, or both?
And why do you say "That revision will probably have more in-depth discussion of some terms".
Does it mean that THIS document is not final? This is the way I read it.

(Brian Haberman) No Objection

(Terry Manderson) No Objection

Comment (2015-09-16 for -04)
No email
send info
No-objection from me regarding the existence of this document, I do think it's helpful, however along with others (Ben, Benoit, Alvaro) I feel the work is incomplete if a revision is required so soon. 

I would feel much more comfortable if the document was taken back to the WG and completed before being published.

Alvaro Retana No Objection

Comment (2015-09-16 for -04)
No email
send info
This is a very nice, and needed reference.

However, I don’t understand why it is being published.  As others have pointed out, the Introduction reads:

   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.

If a revision is coming soon, why not wait?  What does an RFC number give the authors/WG that the ongoing maintenance of an ID doesn’t?  The statement above just reads as if the work is not complete.

This point has been made by others, so I won’t stand in the way of publication.