Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition

Wes Hardaker <wjhns1@hardakers.net> Tue, 02 May 2023 14:41 UTC

Return-Path: <wjhns1@hardakers.net>
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 7CE8FC1524AA for <dnsop@ietfa.amsl.com>; Tue, 2 May 2023 07:41:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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] 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 BkN8UNat55zp for <dnsop@ietfa.amsl.com>; Tue, 2 May 2023 07:41:57 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [107.220.113.177]) (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 07BDEC15152F for <dnsop@ietf.org>; Tue, 2 May 2023 07:41:56 -0700 (PDT)
Received: from localhost (unknown [10.0.0.9]) (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 mail.hardakers.net (Postfix) with ESMTPSA id 85954207BD; Tue, 2 May 2023 07:41:56 -0700 (PDT)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Paul Vixie <paul@redbarn.org>
Cc: Wes Hardaker <wjhns1@hardakers.net>, Paul Vixie <paul=40redbarn.org@dmarc.ietf.org>, Joe Abley <jabley@hopcount.ca>, m9p@india.emu.st, dnsop@ietf.org
References: <f5757414-dd3b-8a09-f945-d73cecf556a3@NLnetLabs.nl> <40C193AF-938C-418F-924E-94F4DD358164@icann.org> <20230501115805.5b4e5115@dataplane.org> <0.2.0-final-1682972681.287-0xd4930e@qmda.emu.st> <ovdbVoNO3SETnssmcX_ys9g7p1j9CEsl1VUMNYZgwHj1W-hTDQZPTaSfswmU_LmnYB5Yq0F_oHVjwfJB6z8fcNdg6Zp-YiVEQrZyneEp9Pg=@hopcount.ca> <c5cf66ab-716f-6a9f-1572-444e88a12a6c@redbarn.org> <yblzg6nu33h.fsf@wx.hardakers.net> <7a7534b1-3015-f7a4-1552-ef532f40876a@redbarn.org>
Date: Tue, 02 May 2023 07:41:56 -0700
In-Reply-To: <7a7534b1-3015-f7a4-1552-ef532f40876a@redbarn.org> (Paul Vixie's message of "Mon, 1 May 2023 19:53:09 -0700")
Message-ID: <yblv8hau763.fsf@wd.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/EwfYfZUPB0FCPLIgayeAEo5xi9g>
Subject: Re: [DNSOP] [Ext] WGLC rfc8499bis one week extension for lame delegation definition
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: Tue, 02 May 2023 14:41:58 -0000

Paul Vixie <paul@redbarn.org> writes:

> > There I fixed it for you:
> 
> that's a meme, right?

Yes, it was a joke.  Apologies if it offended you in any way.

My point was to indicate that:

1. There are multiple (mis)understandings of what a lame delegation is
(regardless of whether or not the original terminology was more precise
and drift has happened)

2. There are in fact multiple underlying issues that could be better
documented in error messages to better explain to operators exactly what
problems are being seen.  This may require multiple terms to achieve a
better set of explanations.  Similar to how EDE has extended the reasons
why a SERVFAIL (or other error codes) may have been encountered.

> if you want to fix it

I've mentioned before that I think it would be better to have multiple
terms that defined more precise errors of exactly what was going wrong
from the point of view of the error-generator.  I typically don't rehash
my past statements unless I have something to add [and I don't - my
original statements still stand].  The consensus seemed to be at the
time "it's not broken, so we shouldn't fix it".

-- 
Wes Hardaker
USC/ISI