Subject: [Last-Call] Genart last call review of draft-ietf-dnsop-rfc7816bis-09

From: Suhas Nandakumar via Datatracker <[email-masked]>
Date: Sun, 06 Jun 2021 23:13:23 -0700

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 7 Jun 2021 10:49:26 +0200

On Sun, Jun 06, 2021 at 11:13:23PM -0700,
 Suhas Nandakumar via Datatracker <[email-masked]> wrote 
 a message of 72 lines which said:

> I am the assigned Gen-ART reviewer for this draft

Thanks for the review.

> clarified in the document ?

The sentence "a good value is 10" seems to me indicating that it is
just a possible value. The important thing is to have a limit. Do we
think it should be rewritten with RFC 2119 words? MUST have a limit
and the RECOMMENDED value is 10?

>  Can this be updated it to match overall ?

Actually, there are *two* independant requests. One for
foo.bar.baz.example and one afterwards ("Here are more detailed
examples") for a.b.example.org. In the first one, ns1.nic.example is
indeed used.

Should we use the same QNAME for both?

> be extended with some context around the same.

With QNAME minimisation, an authoritative name server MAY use exact
matching ("do I know foobar.example?") while without it, it MUST use
tree matching ("do I know thing.stuff.foobar.example or an ancestor of
it?") and tree matching is typically slower.

---

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 7 Jun 2021 08:18:52 -0700

Hello Stephane

please see my responses inline. thanks

> and the RECOMMENDED value is 10?

[suhas] agree with the framing here and it makes it clearer about the
objectives

> Should we use the same QNAME for both?

[suhas] I will let you make a final call on this one. I was able to read
and understand but the intent wasn't
clear with 2 different Qnames on the first read.

> it?") and tree matching is typically slower.
[suhas] This helps thanks