[Gen-art] Genart last call review of draft-ietf-dnsop-rfc7816bis-09

[Suhas Nandakumar via Datatracker <[e-mail]>]

Reviewer: Suhas Nandakumar
Review result: Ready with Nits

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?"