Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-01.txt

Peter Thomassen <> Wed, 22 June 2022 11:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B48D3C157B45 for <>; Wed, 22 Jun 2022 04:08:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.781
X-Spam-Status: No, score=-3.781 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.876, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J3yW-Uen8fAd for <>; Wed, 22 Jun 2022 04:08:31 -0700 (PDT)
Received: from ( [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A962C14CF06 for <>; Wed, 22 Jun 2022 04:08:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:Subject:From :References:To:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=DzIU4CRLAs1zcG/MRs5IV8dI+h/Q7XhjeQ/erJZ4qCw=; b=0C7JEZrXqXz2ZI7fWdVby4pRqj ChqEA8pWzF2N2HZl/HJ/J7OY1+HcD5vjqUsTsctVpGMZnHv94MQEMnocu+e5boNWC4gMRuKfaml9P nmoEPoH6hwAvd5XJPEvu5iFS/qrwgl3d/DsKU5fz28b9PwPbSNLUefV4q8t1YV1zaQjjlr9OkUlv4 3aY8zflJ97fq3WdKk34uZSov7VKMHt4P6efrV4Wy4hS4lIDoLKJACyuhcBTEpqV9buHU4rSCaDZAL e99o3WWDj6/A1vJXQwAXoC2G/rMnR7Vii+k0K0jwZU1xVgBid4QxmxqynfGatgvXNG7BaC8XaYHvD KMjc5aqQ==;
Received: from ([] helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1o3yDk-0002VK-0c for; Wed, 22 Jun 2022 13:08:28 +0200
Message-ID: <>
Date: Wed, 22 Jun 2022 13:08:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
References: <> <> <> <>
From: Peter Thomassen <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-01.txt
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, 22 Jun 2022 11:08:35 -0000

On 6/22/22 12:39, Peter Thomassen wrote:
> So I agree that strictly "replacing" Section 3 may be too much, but we should strongly discourage its use. Perhaps its enough to state that the draft "obsoletes" (or "deprecates"?) RFC 8078 Section 3?

I was thinking to write something like:

   This document updates [@!RFC8078] and replaces its Section 3 with (#bootstrapping) of this document.

   This document obsoletes Section 3 of [@!RFC8078] in favor of (#bootstrapping) of this document.

In doing so, I remember the Obsoletes: RFC header. Looking into it, it seems to apply to an RFC as a whole (not only to a Section, as is the case here).

I started considering what's the difference between obsoleting RFC 8078 Section 3, and the RFC as a whole. The differences would be:

- Besides Section 3 (which we want to obsolete), RFC 8078 has normative language in Section 4 (Disabling DNSSEC with Null CDS record), and in Section 5 (Security Considerations). I guess we don't want to obsolete Section 4. But if the whole RFC was obsoleted, the relevant aspects of Section 5 could be migrated to the new draft.

- RFC 8078 elevates RFC 7344 from Informational to Standards Track. Would that be "undone" by obsoleting RFC 8078? (I guess not?)

- Similarly, RFC 8078 registers the "Delete DS" algorithm. This continues to be needed. Would it collide with obsoleting the RFC?

I can imagine that having all bootstrapping-related stuff in one document (and obsoleting the former), that would make things easier to digest for readers. On the other hand, I don't know how the above situation would be best handled. Input from more experienced IETFers is appreciated.