[DNSOP] Secdir last call review of draft-ietf-dnsop-7706bis-07

Linda Dunbar via Datatracker <noreply@ietf.org> Mon, 24 February 2020 23:06 UTC

Return-Path: <noreply@ietf.org>
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 BF1CE3A1510; Mon, 24 Feb 2020 15:06:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Linda Dunbar via Datatracker <noreply@ietf.org>
To: secdir@ietf.org
Cc: last-call@ietf.org, draft-ietf-dnsop-7706bis.all@ietf.org, dnsop@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.118.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <158258558771.24222.13223272462077841258@ietfa.amsl.com>
Reply-To: Linda Dunbar <linda.dunbar@futurewei.com>
Date: Mon, 24 Feb 2020 15:06:27 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pp3TrABALgPGXYUZtqx2BnvCa_8>
Subject: [DNSOP] Secdir last call review of draft-ietf-dnsop-7706bis-07
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 24 Feb 2020 23:06:28 -0000

Reviewer: Linda Dunbar
Review result: Has Nits

Reviewer: Linda Dunbar
Review result: Ready with questions

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

The Abstract of  This document claims that this document shows how to start and
maintain  a copy of the root zone in the Recursive Resolvers so that the
Resolvers don't need to send query to  another node. Two questions: - What if
the node is not authorized to have the entire records? It would desirable for
the Resolvers to have all the records of the root zone. Is there any scenario
that the Resolvers simply cannot get all the records of the root zone?

-  How to detect if any records stored in the Resolver are STALE?

Page 3, last sentence of the 3rd paragraph:  is it a typo? or miss a verb?
"... it would all responses from a remote root server"

Cheers,

Linda Dunbar