Original text:
order using HTTP's multi-streaming functionality (RFC7540 Section 5}). <del> The Answer section of a DNS response contains one or more RRsets. </del>  (RRsets are defined in RFC7719.)  According to RFC2181, each resource <del> record in an RRset is supposed to have the Time To Live (TTL) freshness information.  Different RRsets in the Answer section can have different TTLs, though it is only possible for the HTTP response to have a single freshness lifetime.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the Resource Record bearing the smallest TTL in the Answer section of the response.  Specifically, the HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS Records reach a 0 TTL.  The </del>  response freshness lifetime MUST NOT be greater than that indicated <del> by the DNS Record with the smallest TTL in the response. </del>  A DNS API client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic A DOH API client may utilize a hierarchy of caches that include both HTTP and DNS specific caches.  HTTP cache entries may be bypassed <del> with HTTP mechanisms such as the Cache-Control no-cache directive </del>  however DNS caches do not have a similar mechanism. A DOH response that was previously stored in an HTTP cache will

Reviewer comments:
feel free to merge if my language works for you
I just now see you gave me the go ahead to merge. I'll fix the conflict and do so.

Revised text:
order using HTTP's multi-streaming functionality (RFC7540 Section 5}).  <ins> The Answer section of a DNS response can contain zero or more RRsets. </ins> (RRsets are defined in RFC7719.)  According to RFC2181, each resource  <ins> record in an RRset has Time To Live (TTL) freshness information. Different RRsets in the Answer section can have different TTLs, although it is only possible for the HTTP response to have a single freshness lifetime.  The HTTP response freshness lifetime (RFC7234 Section 4.2) should be coordinated with the RRset with the smallest TTL in the Answer section of the response.  Specifically, the HTTP freshness lifetime SHOULD be set to expire at the same time any of the DNS resource records in the Answer section reach a 0 TTL.  The </ins> response freshness lifetime MUST NOT be greater than that indicated  <ins> by the DNS resoruce record with the smallest TTL in the response. If the DNS response has no records in the Answer section, and the DNS response has an SOA record in the Authority section, the response freshness lifetime MUST NOT be greater than the MINIMUM field from that SOA record.  Otherwise, the HTTP response MUST set a freshness lifetime (RFC7234 Section 4.2) of 0 by using a mechanism such as "Cache-Control: no-cache" (RFC7234 Section 5.2.1.4). </ins> A DNS API client that receives a response without an explicit freshness lifetime MUST NOT assign that response a heuristic A DOH API client may utilize a hierarchy of caches that include both HTTP and DNS specific caches.  HTTP cache entries may be bypassed  <ins> with HTTP mechanisms such as the "Cache-Control no-cache" directive; </ins> however DNS caches do not have a similar mechanism. A DOH response that was previously stored in an HTTP cache will