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

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 05 May 2023 01:39 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 89D19C151B19 for <dnsop@ietfa.amsl.com>; Thu, 4 May 2023 18:39:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gmail.com
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 gz0bUUYxQTOW for <dnsop@ietfa.amsl.com>; Thu, 4 May 2023 18:39:45 -0700 (PDT)
Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 BB9C7C151553 for <dnsop@ietf.org>; Thu, 4 May 2023 18:39:45 -0700 (PDT)
Received: by mail-pj1-x1033.google.com with SMTP id 98e67ed59e1d1-24e14a24c9dso926069a91.0 for <dnsop@ietf.org>; Thu, 04 May 2023 18:39:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683250784; x=1685842784; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=nEB0ZcpgT+uePo2VvkSoN5Z8Op63ON1Nw7GOhrisYFs=; b=A7NcmIG8T4HuNfbBCXLCxmHtn4rG6StIb7hYnqt1QzyiFtUl2Zn+TVp550WoAqj50L CZjOC+oXJpateJwQA0RtanCba+UwVpfNIZameI2BJhQWi/LzpbWjT18JXfOTpKNQ6Dem gTlxiZ1qHe90TfU3qj2Buj4WvB5RKQwrBVCg+NREybzQy4QNKu4XMMz4A50YsZZ0xrmD 5iFxzVxNz9M4WNrB8B0htx+ga2PFYXTb8luSxdIiBfLVLzB4m+SPYMMGJbCjaCyTavZ5 pyM8OL7WhNK7WnN3rmxsT9rJHfKevYtd1bkytdxVwfiad45zIf2wbK1q7JNKAogr1CUg dyWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683250784; x=1685842784; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=nEB0ZcpgT+uePo2VvkSoN5Z8Op63ON1Nw7GOhrisYFs=; b=FO8bVnIbJ6c+6y4IMHnbTN6tGpFMMddoIfhABHrF0hp48SvUI6vXmwEF8vXJjPmQJB 8ANAIiJCm6tKzmZUoIBjRkRKWcOJFhZ6GYSNn4lQ+IBRZg5FtZCq78Fwl6vxtWDfvZki BFN47f6hVHU25btPClG9ZToBDaP163qxst4QDvOp5fiDjnrgj/sMJKDmlVX9Jm6HCzt4 tkO72DhuKXxyCxcx/88N8fYyBRaB4QRgR31Wim+2uMPbFfi58Q2CqlZgjsV7K8Fioutl BwcWN6oMtCooCHZOTWsz/1+Jko89ov9AwU13Y5o6G7vCJzyst4/vs+nx8qazpHJJhAJI ylJg==
X-Gm-Message-State: AC+VfDzLzESsYhUSXy8s5BA1FBsRCm7aQyePs3wZRYyrvnZ872W56Y24 XqiGRci/bi/9/KmPtQUziff0wYUCJZpIZu3wIYOZkO4Rhrw=
X-Google-Smtp-Source: ACHHUZ4AM0a1f0YRvW/lYtjBnLgQJzgWAy0rK419PZXrgigVa6TxTcR7rXPooupuCtNtwbwDUMcJ512+60f+sJBbP/Y=
X-Received: by 2002:a17:90b:1d82:b0:24d:fcd2:bdad with SMTP id pf2-20020a17090b1d8200b0024dfcd2bdadmr4087578pjb.35.1683250784377; Thu, 04 May 2023 18:39:44 -0700 (PDT)
MIME-Version: 1.0
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> <1C10367C-B890-426F-A4F8-2D68E903ED39@icann.org> <0.2.0-final-1683191254.797-0xa08e34@qmda.emu.st> <CAHw9_iLyz4dhjmXm=eeqiVqQWOjYOgs45NbCtRtvrYpTFQHz=w@mail.gmail.com> <0645EF4E-21C4-4D16-AFE7-D57054F7992C@isc.org> <CAKr6gn2SeEJgM1WWRRGmCK=mBXyCiqituibCZsq0TFyNBvqWfA@mail.gmail.com>
In-Reply-To: <CAKr6gn2SeEJgM1WWRRGmCK=mBXyCiqituibCZsq0TFyNBvqWfA@mail.gmail.com>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 04 May 2023 18:39:32 -0700
Message-ID: <CAH1iCip+7ANeFQf9a5kGKWLXT9XN91mugB2jLuE5U=6Ev-_zxw@mail.gmail.com>
To: George Michaelson <ggm@algebras.org>
Cc: DNSOP Working Group <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001220a405fae85d74"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zUdWNxkRWQl83ISfy7ygMN3g4uQ>
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: Fri, 05 May 2023 01:39:49 -0000

George is (of course) right.

I think the following set of definitions might be useful to consider.

Lame server: older language used to describe a "lame zone server".
Lame zone server: a server listed in the NS set for a zone, which is not
providing authoritative answers for said zone.
Partially lame domain (partially lame zone): a domain (zone) for which at
least one server is a lame zone server.
Completely lame domain (completely lame zone): a domain (zone) for which
all of the servers are lame zone servers.
Lame domain (or lame zone): a partially lame domain (partially lame zone)

(Feel free to augment or substitute as needed).

Brian
P.S. This might be a good time to suggest alternatives for "lame", at least
in this context. I.e. include "lame" but suggest the new term as a
substitute.


On Thu, May 4, 2023 at 5:34 PM George Michaelson <ggm@algebras.org> wrote:

> When people talk about "lame" they're in a sentence with a subject
> (the DNS), and an object(ive) -But there isn't a single parse. Sorry,
> but the declarative "this is what it means" seems to me to be failing,
> hard.
>
> The subject(s) are the zone(s) that are lame? thats one case. the
> other case, is the subject is the NS which is listed as authoritative
> but isn't serving. OK so you can qualify "lameness" to "the zone is
> lame" or "the zone has some lame NS" or "this NS is lame for the zone"
> -But they have different subjects and objects. what is "this" in each
> case? different.
>
> And not serving has (at least) two forms: you respond to 53 but reply
> incoherently if at all about the zone, and you aren't even responsive
> on 53. I can believe there are more.
>
> The objective is to fix it. You are either talking to the parent zone
> delegates to get something changed in the parent zone, or to the zone
> NS admin to get something changed at the NS, or to network technicians
> about why something along the path isn't working for you. So thats 3
> cases at least.
>
> Yet, we all seem to call this "lame" for some purposes. At least 2x
> who talked to, at least 2x forms, and at least 2x subjects but one
> Objective: -- fix it.
>
> I don't think we've cohered on a meaning. I respect Paul Vixies intent
> in giving clear origination of the term to Mark, but I do not agree
> the term means now what he said decades ago, its clear we don't (in
> this mail thread) really have a unitary meaning. If we did we wouldn't
> be here.
>
> I don't see how a single paragraph statement without OR ... alternates
> is going to cover what people patently have been saying "is lame" for
> some time, not aligning to a single meaning.
>
> I liked the proposed paragraph because it had the ".. or not at all"
> -And yet some people seem determined to say thats the "wrong" bit on
> the definition.
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>