[DNSOP] Artart last call review of draft-ietf-dnsop-zoneversion-07

John Levine via Datatracker <noreply@ietf.org> Sun, 09 June 2024 14:13 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 B0AB6C14CF09; Sun, 9 Jun 2024 07:13:38 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: John Levine via Datatracker <noreply@ietf.org>
To: art@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.15.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171794241870.3247.17055653550600432692@ietfa.amsl.com>
Date: Sun, 09 Jun 2024 07:13:38 -0700
Message-ID-Hash: PS2JU7GZ6VKAXWE3AA5P5EBFLU5HBPR7
X-Message-ID-Hash: PS2JU7GZ6VKAXWE3AA5P5EBFLU5HBPR7
X-MailFrom: noreply@ietf.org
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: dnsop@ietf.org, draft-ietf-dnsop-zoneversion.all@ietf.org, last-call@ietf.org
X-Mailman-Version: 3.3.9rc4
Reply-To: John Levine <johnl@taugh.com>
Subject: [DNSOP] Artart last call review of draft-ietf-dnsop-zoneversion-07
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RiS-F_NGxyRekLgz_dplbMdX9tk>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

Reviewer: John Levine
Review result: Ready with Nits

This draft is ready to go.  The recent revisions to the label count are
adequately clear and the rest seems straightforward.

I wonder about the paragraph "A name server MUST ignore any non-empty
ZONEVERSION payload data that might be present in the query message."  It's not
wrong, but why call out this one particular error and not others like multiple
ZONEVERSION options?  I'd take it out and leave the response to ill-formed
queries undefined, or else be more general and say a server MUST ignore invalid
ZONEVERSION options.