Re: [DNSOP] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt

Dave Lawrence <tale@dd.org> Mon, 18 March 2024 01:31 UTC

Return-Path: <tale@dd.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E16EC14F610 for <dnsop@ietfa.amsl.com>; Sun, 17 Mar 2024 18:31:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NpISR1MdDyw for <dnsop@ietfa.amsl.com>; Sun, 17 Mar 2024 18:31:23 -0700 (PDT)
Received: from fluff.twonth.com (fluff.twonth.com [45.79.143.238]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5C2C14F604 for <dnsop@ietf.org>; Sun, 17 Mar 2024 18:31:23 -0700 (PDT)
Received: from gro.dd.org (c-76-23-204-191.hsd1.vt.comcast.net [76.23.204.191]) by fluff.twonth.com (Postfix) with ESMTPS id 03AEC1FD1E for <dnsop@ietf.org>; Mon, 18 Mar 2024 01:31:23 +0000 (UTC)
Received: by gro.dd.org (Postfix, from userid 102) id 95DD3188BD3; Sun, 17 Mar 2024 21:31:22 -0400 (EDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <26103.39274.593925.814878@gro.dd.org>
Date: Sun, 17 Mar 2024 21:31:22 -0400
From: Dave Lawrence <tale@dd.org>
To: dnsop@ietf.org
In-Reply-To: <9dfb3b11-c5ea-42f0-8aa1-9b0d65066848@bellis.me.uk>
References: <57517c17-fa72-4180-a1ac-b74eac12ca88@NLnetLabs.nl> <9dfb3b11-c5ea-42f0-8aa1-9b0d65066848@bellis.me.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/mjRApKFqR88buNZcB1tO6U3y-SY>
Subject: Re: [DNSOP] Fwd: I-D Action: draft-toorop-dnsop-ranking-dns-data-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Mar 2024 01:31:24 -0000

Ray Bellis writes:
> I get the impression with DELEG on the horizon that there's a shift 
> towards the parent side data being considered more "authoritative" even 
> though in protocol terms it explicitly isn't.

Yes and no; there's a bit of nuance to ferret out here.  This is part
of the original sin of parent/child NS.  There is no child-side DELEG
for parent-side DELEG to be considered more authoritative about.  It
is just authoritative in the parent in the same way that DS is, which
incidentally is also more authoritative than if you put a DS in the apex.

Your general observation is, of course, correct that yes, this shift
takes a clearer parent-centric view of the perennial parent-centric /
child-centric debate.  In practical terms, operations have largely
been parent-centric anyway.