IETF Logo Mail Archive

[DNSOP] Re: draft-ietf-dnsop-delext and non-useful parent-side types

Ralf Weber <dns@fl1ger.de> Thu, 23 July 2026 13:24 UTC

Return-Path: <dns@fl1ger.de>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id C78BB11D6D3CB for <dnsop@mail2.ietf.org>; Thu, 23 Jul 2026 06:24:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1784813097; bh=jAmaEGw7F8f6xCTUmSSFo205fk2eBTUodFHGoAjDJPo=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=mnMGsniOFbS7oLCnF3fiZ9VHtvwjPBNdoSZXMYeK8KMaG2ST9FcVsbt+bNVfyaZSe Srq2HrKPaj9LLu7Tu6V7Uub2pSj9VFluXblyqVCFwdAIIcHOniIFh4U1fI9PYGCrp5 RVlpfgB4n6RWWVCKJWOt/R3CiX0++KCTygx5ydM8=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=unavailable autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4C59lKsJEMf for <dnsop@mail2.ietf.org>; Thu, 23 Jul 2026 06:24:55 -0700 (PDT)
Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:c014:beec::465:25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 2DEAA11D6C0F3 for <dnsop@ietf.org>; Thu, 23 Jul 2026 06:23:41 -0700 (PDT)
Received: from [100.64.0.1] (rtr-guestwired.meeting.ietf.org [31.133.144.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by nox.guxx.net (Postfix) with ESMTPSA id 6BF783E71D; Thu, 23 Jul 2026 13:23:35 +0000 (UTC)
From: Ralf Weber <dns@fl1ger.de>
To: Peter Thomassen <peter=40desec.io@dmarc.ietf.org>
Date: Thu, 23 Jul 2026 15:23:34 +0200
X-Mailer: MailMate (2.0r6292)
Message-ID: <C2316DFD-96AA-497C-8FCA-AA10133432CD@fl1ger.de>
In-Reply-To: <81674e48-033e-4257-97d5-4c3a251b33c9@desec.io>
References: <97BE2BD7-DE21-4684-B150-F0588D1D6365@verisign.com> <81674e48-033e-4257-97d5-4c3a251b33c9@desec.io>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: OWYQCEQAIRU6A3JKXGJVWZZWTOZSRJIC
X-Message-ID-Hash: OWYQCEQAIRU6A3JKXGJVWZZWTOZSRJIC
X-MailFrom: dns@fl1ger.de
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: "Blacka, David" <davidb=40verisign.com@dmarc.ietf.org>, dnsop@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [DNSOP] Re: draft-ietf-dnsop-delext and non-useful parent-side types
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/PXO_DbfInVRtkIG9VGAeQ1zZ5Do>
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>

Moin!

On 22 Jul 2026, at 20:00, Peter Thomassen wrote:

> Hi David,
>
> On 7/22/26 19:53, Blacka, David wrote:
>> So, the question is: do we want delext to make it possible to define
>> new parent-side types that work with NS? or are we ok that all new
>> delegation types either need to be DELEG successors or be served
>> with DELEG?
>
> I'd strongly prefer the former: it will be almost no work to take this into account now, in comparison to when we don't but need it later.

This was discussed early on in DELEG, and the consensus then was because every NS can be represented by a DELEG record that we did not need it. We then had a discussion if this should synthesised automatically and if this should be part of the spec and we said that this is implementation dependant and we should not describe it.

So long
-Ralf
———
Ralf Weber

v2.46.0 | Report a Bug | By Email | System Status