I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dnsop-rfc7816bis-??
Reviewer: Suhas Nandakumar
Review Date: 2021-06-06
IETF LC End Date: 2021-06-07
IESG Telechat date: Not scheduled for a telechat

Summary:
I am no DNS expert. However reading this document and related RFCs provided sufficient context to understand the scope of the problem to be solved.

This document is Ready with nits.

Major issues:
None

Minor issues:
Section 2.1 "Using the QTYPE that occurs
   most in incoming queries will slightly reduce the number of queries,
   as there is no extra check needed for delegations on non-apex
   records"
Do we need to be explicit about performance impacts here ? 
Wonder if the phrase "slightly reduce" could be characterized to that extent? 


Section 2.1 last para might benefit with rewording/rephrasing. It is not clear from the context on the relationship between caching and happy eye balls query.

Section 2.3 
1. MAX_MINIMISE_COUNT and MINIMISE_ONE_LAB - are the values for these constants normatively defined or are they just recommendations ? Can the same be clarified in the 
document ?

2. What is the expected behavior in cases where the number of labels per iteration is still very high after division ? Do we need another constant MAX_MINIMIZE_COUNT_PER_ITERATION to ward against such attacks ?

 
Section 4. 
The section starts with query for "foo.bar.baz.example" and walk through refers to a.b.example.org  as query input.  Also no reference to ns1.nic.example seems to be appear in the detailed flows.
 Can this be updated it to match overall ?

Section 5
"QNAME minimisation may also improve lookup performance for TLD
   operators.  For a TLD that is delegation-only, a two-label QNAME
   query may be optimal for finding the delegation owner name, depending
   on the way domain matching is implemented."
This para doesn't clarify how the performance will be improved.  Can it
be extended with some context around the same.


Nits/editorial comments:

Section 2.2 " So, assuming
   that the resolver already knows the name servers of example, when it
   receives the query "What is the AAAA record of www.foo.bar.example?",
   it does not always know where the zone cut will be"
==> Can it be reworded as "So, it cannot be assumed that the resolver would be aware of zone cuts to know the name servers of example for the query "What is the AAAA record 
of www.foo.bar.example?"