[DNSOP] RFC8499bis path forward after extended WGLC
Benno Overeinder <benno@NLnetLabs.nl> Fri, 19 May 2023 13:31 UTC
Return-Path: <benno@NLnetLabs.nl>
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 1FC1EC151065 for <dnsop@ietfa.amsl.com>; Fri, 19 May 2023 06:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl
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 AWlQoEYzaEqg for <dnsop@ietfa.amsl.com>; Fri, 19 May 2023 06:31:47 -0700 (PDT)
Received: from dane.soverin.net (dane.soverin.net [IPv6:2a10:de80:1:4092:b9e9:2295:0:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95B17C14F693 for <dnsop@ietf.org>; Fri, 19 May 2023 06:31:46 -0700 (PDT)
Received: from smtp.soverin.net (c04smtp-lb01.int.sover.in [10.10.4.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by dane.soverin.net (Postfix) with ESMTPS id 4QN76R3qjnz10F3; Fri, 19 May 2023 13:31:43 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [10.10.4.99]) by soverin.net (Postfix) with ESMTPSA id 4QN76R0rCWzP2; Fri, 19 May 2023 13:31:43 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1684503103; bh=ucLmgScSYRuLW7s8wOIf8tyTGo2QUchTqMPN9ihtqlM=; h=Date:To:From:Subject:From; b=dsLtxXmLFPmnKzgJAeDczrz5F5fxKKMb5ackWA/8KfJYqx8PxguwA5AIa3+psVKsV 4I5lyIfv8YBCkPd5HnTdbgQKw4Ng89lhAN9Oue6JU6uALWaRK5gM0Y39ivE7majumf J6DnlgEJpfY4vQYXL4KjnOPhLYQc8AYQWrgQIgX4sqfyIx7JS8RDcAtv7CHFo6R5yD jizG0sWrCacm/g6+HHaw/+jokV4bNuAoU5nvHEjR1by3BeE2x8LfIinQDTXi5g1pE2 CwJBzhLVuWAnpYXkm7uLlNc+KzON1aYybjKA6Rr8aMDiTQfWVf5NMfHGc6h7jL4u7c FjQZDEU2lqtRw==
Message-ID: <f8351dc3-a3b8-5ee1-4af0-27f0fcf4795a@NLnetLabs.nl>
Date: Fri, 19 May 2023 15:31:41 +0200
MIME-Version: 1.0
Content-Language: en-GB
To: DNSOP Working Group <dnsop@ietf.org>
X-Soverin-Authenticated: true
From: Benno Overeinder <benno@NLnetLabs.nl>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/vlMvFw6x9WNIFACFST3JWSIlako>
Subject: [DNSOP] RFC8499bis path forward after extended WGLC
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: Fri, 19 May 2023 13:31:52 -0000
Dear WG, The extended WGLC for rfc8499-bis did not conclude with rough consensus on either of the two proposed definitions of the term "lame delegation". There was some consensus in a subthread on one of the proposed definitions, earlier formulated on the mailing list, see the original thread https://mailarchive.ietf.org/arch/msg/dnsop/4E1AQKGivEHtJDB85gSNhofRuyM/. For readability, I will include the proposed definition again: "A lame delegation is said to exist when one or more authoritative servers designated by the delegating NS RRset or by the child's apex NS RRset answers non-authoritatively for a zone". In another subthread, new terms and definitions appeared because the definition above was not specific enough, but this thread didn't lead to a specific definition. There are now three paths forward: 1) Stick with the current text in the document – the original definition from RFC8499 plus a note that "These early definitions do not match the current use of the term "lame delegation", but there is no consensus on what a lame delegation is." A possible follow-up to this is for someone to start a WG consensus document on "lame", which can update 8499bis. 2) We still find a rough consensus on the definition proposed in the "Meaning of lame delegation" email thread, and the WG can agree that this is a definition useful to DNS engineers/operators. 3) Withdraw the document from WGLC so we can add definitions. Do not propose any new terms and definitions at this stage if we choose this option. The third option is the least desirable outcome since the document is already this far in the process and has seen many reviews and edits. In order for the WG to decide how to proceed, we plan to schedule an interim meeting in June and discuss the three options with the WG. Thank you, Suzanne, Tim and Benno
- [DNSOP] RFC8499bis path forward after extended WG… Benno Overeinder