Last Call Review of draft-ietf-dnsop-kskroll-sentinel-15

Request Review of draft-ietf-dnsop-kskroll-sentinel
Requested rev. 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 Damas, Warren 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
Review review-ietf-dnsop-kskroll-sentinel-15-genart-lc-arkko-2018-08-29
Reviewed rev. 15 (document currently at 17)
Review result Ready with Issues
Review completed: 2018-08-29


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


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


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.