Original text:
name (i.e. the name that was in the RDATA of the CNAME RR) as also being the QNAME. <del> This creates a kind of confusion, however, because the answer to a query that results in CNAME processing contains in the echoed </del>  Question Section one QNAME (the name in the original query), and a second QNAME that is in the data field of the last CNAME.  The confusion comes from the iterative/recursive mode of resolution, A program "that extract[s] information from name servers in response to client requests."  (Quoted from RFC1034, Section 2.4) A resolver performs queries for a name, type, and class, and <del> receives answers.  The logical function is called "resolution". </del>  In practice, the term is usually referring to some specific type of resolver (some of which are defined below), and understanding the use of the term depends on understanding the context. A related term is "resolve", which is not formally defined in RFC1034 or RFC1035.  An imputed definition might be "asking a question that consists of a domain name, class, and type, and <del> receiving some sort of answer".  Similarly, an imputed definition of "resolution" might be "the answer received from resolving". </del>  A resolver that cannot perform all resolution itself.  Stub resolvers generally depend on a recursive resolver to undertake specific to be generally useful. A configuration for a DNS server that allows it to provide <del> different answers depending on attributes of the query, such as </del>  for "split DNS".  Typically, views differ by the source IP address of a query, but can also be based on the destination IP address, the type of query (such as AXFR), whether it is recursive, and so

Reviewer comments:
Thanks the authors for their work in making this draft. I'm going through and I noticed that the term "answer" (45 occurrences) and "response" (47 occurrences) are used interchangeably in the text. I am OK with that, but they should be explicitly defined IMHO, to avoid confusion. E.g.: if I: ` Is the response the entire DNS-layer packet(s), with all the RRs in it? (including flags,etc) Is an answer each line in both ANSWER and AUTHORITY section? Maybe this is clear to many ppl, but it would be nice to write it down. thanks
I do not believe that we have used these terms "interchangeably", since they're not. Some responses are answers and all answers are responses. Some answers contain an Answer Section and some (negative answers, for instance) do not. If that isn't clear, we perhaps ought to add text similar to that, though I thought we had some discussion of this. I didn't see it while looking on my phone just now, however. A
I have opened PR to fix the places where I think we are really talking about responses, not answers.
I think given how late this is in the draft, I'd like to suggest just adding a new bit of text rather than changing the terms, because the WG has been over this ground some. I think it'll be easier to get WG agreement on some text describing the differences without trying to pick each case. Dunno where to put it -- probably intro or something like that -- but here's a suggestion: This document is sometimes unclear on the terms "response" and "answer". The lack of clarity is partly because the DNS specifications themselves use the terms ambiguously. In general, a response is any DNS message with the QR bit set (see [forward reference here]). An answer is any response that attempts actually to answer the question posed in the corresponding query message. Not all answers are authoritative (see [forward reference here]). Some answers contain an Answer Section (see [xref?]), but not all do (such as a negative answer, [forward reference]). Some other responses are not an answer at all, such as an error response. Sorry not to submit this in the usual and proper githubby way, but I'm on vacation and jamming this in.
Closed with , but might be reopened during IESG review if needed.

Revised text:
name (i.e. the name that was in the RDATA of the CNAME RR) as also being the QNAME.  <ins> This creates a kind of confusion, however, because the response to a query that results in CNAME processing contains in the echoed </ins> Question Section one QNAME (the name in the original query), and a second QNAME that is in the data field of the last CNAME.  The confusion comes from the iterative/recursive mode of resolution, A program "that extract[s] information from name servers in response to client requests."  (Quoted from RFC1034, Section 2.4) A resolver performs queries for a name, type, and class, and  <ins> receives responses.  The logical function is called "resolution". </ins> In practice, the term is usually referring to some specific type of resolver (some of which are defined below), and understanding the use of the term depends on understanding the context. A related term is "resolve", which is not formally defined in RFC1034 or RFC1035.  An imputed definition might be "asking a question that consists of a domain name, class, and type, and  <ins> receiving some sort of response".  Similarly, an imputed definition of "resolution" might be "the response received from resolving". </ins> A resolver that cannot perform all resolution itself.  Stub resolvers generally depend on a recursive resolver to undertake specific to be generally useful. A configuration for a DNS server that allows it to provide  <ins> different responses depending on attributes of the query, such as </ins> for "split DNS".  Typically, views differ by the source IP address of a query, but can also be based on the destination IP address, the type of query (such as AXFR), whether it is recursive, and so