[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) (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 []) 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 
  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 

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