Re: [DNSOP] Current status of draft-ietf-dnsop-dnssec-validator-requirements

Florian Obser <> Wed, 07 June 2023 17:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F539C1516FF; Wed, 7 Jun 2023 10:38:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IcwrfCRLu734; Wed, 7 Jun 2023 10:38:09 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA512) (No client certificate requested) by (Postfix) with ESMTPS id 63E3CC14CE5F; Wed, 7 Jun 2023 10:38:07 -0700 (PDT)
Received: from pinkunicorn ( [2001:1c00:270d:e800:ddfa:1155:30ee:5532]) by (OpenSMTPD) with ESMTPSA id da90654e (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 7 Jun 2023 19:38:03 +0200 (CEST)
From: Florian Obser <>
To: Tim Wicinski <>
Cc: dnsop <>, dnsop-chairs <>
References: <> <>
Date: Wed, 07 Jun 2023 19:38:02 +0200
In-Reply-To: <> (Tim Wicinski's message of "Wed, 7 Jun 2023 13:08:14 -0400")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (darwin)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [DNSOP] Current status of draft-ietf-dnsop-dnssec-validator-requirements
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Jun 2023 17:38:13 -0000

On 2023-06-07 13:08 -04, Tim Wicinski <> wrote:
> Just a reminder we're looking for any feedback on continuing work on this
> document.  The Chairs/OverLord Warren feel significant work on this
> document is needed, but that may not be relevant.

The document seems to have a rather pessimistic view on running a
validator. It has this huge list of things that an operator has to do
and does not assign any importance to them - everything seems to be
equally important.

If I were to read this as the person responsible for running the
recursive resolver at an enterprise or at an ISP I'd think: That sounds
like effort and incredibly fragile, it's probably best to not enable

It would be nice to have an informational RFC on the topic, but I'm not
convinced this is it. Maybe Andrew's suggestion to split this up is the
way forward. Maybe have one document with minimum requirements (correct
time, stuff like that) and take it from there.

> We're wrapping this feedback up this Sunday 11 June.
> (and Thanks Andrew for your comments)
> tim

In my defence, I have been left unsupervised.