[DNSOP] Genart last call review of draft-ietf-dnsop-kskroll-sentinel-15

Jari Arkko <jari.arkko@piuha.net> Thu, 30 August 2018 05:46 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 52C8C130EF4; Wed, 29 Aug 2018 22:46:36 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Jari Arkko <jari.arkko@piuha.net>
To: <gen-art@ietf.org>
Cc: dnsop@ietf.org, draft-ietf-dnsop-kskroll-sentinel.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.83.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153560799626.14640.11971224364548163931@ietfa.amsl.com>
Date: Wed, 29 Aug 2018 22:46:36 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nx9HtJK_iMAKhFPCT5YLCjowDa0>
Subject: [DNSOP] Genart last call review of draft-ietf-dnsop-kskroll-sentinel-15
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2018 05:46:37 -0000

Reviewer: Jari Arkko
Review result: Ready with Issues

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.