Skip to main content

Last Call Review of draft-ietf-dnsop-kskroll-sentinel-15
review-ietf-dnsop-kskroll-sentinel-15-genart-lc-arkko-2018-08-29-00

Request Review of draft-ietf-dnsop-kskroll-sentinel
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-09-06
Requested 2018-08-23
Authors Geoff Huston , Joao da Silva Damas , Warren "Ace" Kumari
Draft last updated 2018-08-29
Completed reviews Genart Last Call review of -15 by Jari Arkko (diff)
Assignment Reviewer Jari Arkko
State Completed Snapshot
Review review-ietf-dnsop-kskroll-sentinel-15-genart-lc-arkko-2018-08-29
Reviewed revision 15 (document currently at 17)
Result Ready with Issues
Completed 2018-08-29
review-ietf-dnsop-kskroll-sentinel-15-genart-lc-arkko-2018-08-29-00
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-kskroll-sentinel-??
Reviewer: Jari Arkko
Review Date: 2018-08-29
IETF LC End Date: 2018-09-06
IESG Telechat date: Not scheduled for a telechat

Summary:

This document was easy to read, and I had no issues to raise. I believe the
test that it describes is useful and important for the DNSSEC operational
processes in the Internet.

I did, however, have one question and one minor issue discussed below, and
several editorial observations.

Major issues:

Minor issues:

The document says:

   If the validating resolver has a forwarding configuration, and uses
   the CD bit on all forwarded queries, then this resolver is acting in
   a manner that is identical to a standalone resolver.

What does "using the CD bit" mean? Do you expect the bit to be set or not set?
Please clarify the language.

The document says:

   nonV:  A non-security-aware DNS resolver will respond with an A or
      AAAA record response for "root-key-sentinel-is-ta", an A record
      response for "root-key-sentinel-not-ta" and an A or AAAA RRset
      response for the name that returns "bogus" validation status.

I do not understand why an old, non-DNSSEC aware resolver would respond in
different ways to the -is-ta and -not-ta queries. But here you say an A record
response is returned for -not-ta but A or AAAA RRset response is returned for
-is-ta. What am I missing?

Nits/editorial comments:

Section 3 table lists "A" as responses, while the text talks about "A or RRset
response". Perhaps this could be aligned to avoid confusion.

Section 4 title is "Sentinel Tests from Hosts with More than One Configured
Resolve". Shouldn't that be "... Resolvers"?

The document did not clearly specify whether the names queried (including the
-is-ta and not-ta label) need to exist in the used domain, or if it is enough
for the domain itself to exist. Perhaps this could be clarified.