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

Peter Thomassen <> Tue, 19 July 2022 08:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89495C14F612 for <>; Tue, 19 Jul 2022 01:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, 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_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 vGVERMOrrplJ for <>; Tue, 19 Jul 2022 01:17:32 -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 235CEC16ECED for <>; Tue, 19 Jul 2022 01:17: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:From: References:To:Subject: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=Z5cuGfkos8pD4hhDd8MN2hOAIY28w0pkk/xxtKLw7hQ=; b=wkh7HYuGoUN4APF928In0lkuE1 Ika7G5Sv5ozAK2k0DQQDO53zaSQTZtNMlOH3ao6YoekJakvWj+/gVVddAcLtyb2LfJBqmE5HrUEUA Ps5sCwRZgHeIAmmNW5Wn7BS5n+2ZfQfWx/Si0vlPrhf4fDRiXnwiNv7rWsSRVkQdikf4PABkyiKGA u2XEwD6+Oo5p+4sRxZujl1ujW6GvSe3Eg1Y7eoG7BxzsqdzaxWacUuOk01JusScAlyFFmhtEd8dTT UmKl7uP3MY3fwc3rnXa91wkb+6AUmLBGgGg6EtdEvmhfZH8KZEAJ/q3fZGa6cBEzjcLIfXOlloSuR mj84g5rw==;
Received: from [] (helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <>) id 1oDiQ1-0001vU-Bh for; Tue, 19 Jul 2022 10:17:26 +0200
Message-ID: <>
Date: Tue, 19 Jul 2022 10:17:24 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
References: <> <> <> <> <>
From: Peter Thomassen <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Tue, 19 Jul 2022 08:17:36 -0000

Dear WG,

I'm requesting help with the below issue. It would be great if somebody could advise how to proceed.



On 6/22/22 13:08, Peter Thomassen wrote:
> 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:
> OLD:
>    This document updates [@!RFC8078] and replaces its Section 3 with (#bootstrapping) of this document.
> NEW:
>    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.
> Best,
> Peter

Like our community service? 💛
Please consider donating at

deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin

Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525