Suhas, thank you for your review. I have entered a No Objection ballot for this document. Lars On 2021-6-7, at 9:13, Suhas Nandakumar via Datatracker <noreply@xxxxxxxx> wrote: > > 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?" > > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
