Re: [DNSOP] Another attempt at consensus on the bailiwick discussion
Paul Vixie <paul@redbarn.org> Thu, 16 December 2021 18:55 UTC
Return-Path: <paul@redbarn.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 DDD3D3A0E42 for <dnsop@ietfa.amsl.com>; Thu, 16 Dec 2021 10:55:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Level:
X-Spam-Status: No, score=-3.951 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, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redbarn.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DPMVmTpdORGh for <dnsop@ietfa.amsl.com>; Thu, 16 Dec 2021 10:55:31 -0800 (PST)
Received: from util.redbarn.org (util.redbarn.org [24.104.150.212]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0C553A0E36 for <dnsop@ietf.org>; Thu, 16 Dec 2021 10:55:29 -0800 (PST)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by util.redbarn.org (Postfix) with ESMTPS id 67E6818EA05; Thu, 16 Dec 2021 18:55:28 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=redbarn.org; s=util; t=1639680928; bh=g7j+PeQ7cYxJA37gJa1T0mpcm4/q4Ij/jZOmKnNoK8k=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=VdQDd8RRZz+dGGE/8sqI2OiIki+8KzT6CK1beVTxKb2eH+58dVQcxe8zPP8WweQBR Zu608ZElz4JmUKHBXSnvOsRbkxD9QTtJkAWpHUMe+i0yfLjZAOgPGwXOh5Y/yGx2/t 4KOzHiKy+SoyArtrneYi1YDxCRWkydixfLYtDLRA=
Received: from [IPv6:2001:559:8000:c9:f065:c89a:99f4:2ace] (unknown [IPv6:2001:559:8000:c9:f065:c89a:99f4:2ace]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 41D357597E; Thu, 16 Dec 2021 18:55:28 +0000 (UTC)
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
Cc: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
References: <B08E9361-B97B-4862-861C-4EF628C85E50@icann.org> <bb61304c-6ef9-7850-3dbb-19b624bc07b@nohats.ca> <60a11d97-8be4-91e-4880-999c1a57a75b@dotat.at> <FC138247-7BA2-4CCA-8E6C-A06423236A81@icann.org> <2009A9A9-4CF3-4AB6-8D6B-3474B15F0328@verisign.com> <CAHbrMsDpW=Z7R69Zn9Oqxfjo7SnhfuNpj_uL+VN6FS_5oXuA5g@mail.gmail.com> <315888CA-4429-4038-AB6F-0D38B95A2FA2@verisign.com> <CAHbrMsBj1F9rtFywZh-68JjCTUVOzAej_GLc15KGNOALQf28yg@mail.gmail.com>
From: Paul Vixie <paul@redbarn.org>
Message-ID: <7bd5b32b-7070-cae8-8629-ee6c47674f38@redbarn.org>
Date: Thu, 16 Dec 2021 10:55:26 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 PostboxApp/7.0.53
MIME-Version: 1.0
In-Reply-To: <CAHbrMsBj1F9rtFywZh-68JjCTUVOzAej_GLc15KGNOALQf28yg@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/TFyoLtX2h_VAV8W1UjWP-JWrBYM>
Subject: Re: [DNSOP] Another attempt at consensus on the bailiwick discussion
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 16 Dec 2021 18:55:37 -0000
Ben Schwartz wrote on 2021-12-16 10:45: > On Wed, Dec 15, 2021 at 3:56 PM Wessels, Duane > <dwessels=40verisign.com@dmarc.ietf.org > <mailto:40verisign.com@dmarc.ietf.org>> wrote: > > For me “necessary” is an important distinction and “might be useful” > is too broad or ambiguous. I have a hard time reconciling the idea > that glue is not optional with the idea that it might be useful. > > > My view is less like "might be useful for reaching the nameserver", and > more like "intended for use in connecting to the nameserver". A record > is "glue" if it is provided for the purpose of helping the > resolver connect to the nameserver indicated in the NS record. the AAAA or A RRsets which are beneath delegation points will never be answered authoritatively by the zone's servers. they will either come as referral glue when asking for other names at/below that delegation point, or they will come as referral glue when asking for them by name. so they do seem "necessary" since there is no other way to get them from the zone's servers except by asking a question which inspires the server to add them to the additional data section of a referral response. of course, they may be held as glue higher up the hierarchy. for example we might get ns-ext.vix.com's AAAA/A RR from the root or COM servers when forwarding a question for www.vix.com to one of those servers. but if it doesn't come from there, it had better come from vix.com's servers, but since it's below a delegation point, it can only be sent by the vix.com zone servers as additional data in a referral response. perhaps the nomenclature should be "referral glue" to drive home the point about where it will appear, and disambiguate from whatever DPRIVE is thinking about, and avoid the use of the words "necessary" or "useful". > "Necessary" doesn't work, in my view. Whenever there are multiple A or > AAAA glue RRs, each RR is not individually "necessary". Any glue AAAA > RRSet is basically never "necessary". i think that's a corner case, unworthy of the complexity of describing it. if there is only one name server for a zone, and it has only one kind of IP connectivity, then that one AAAA (or A) RRset will be "neccessary". this highlights the benefit of not using words like "necessary" or "glue" since they drag in unnecessary outer concepts. vixie
- [DNSOP] Bailiwick discussion for draft-ietf-dnsop… Paul Hoffman
- Re: [DNSOP] Bailiwick discussion for draft-ietf-d… Tim Wicinski
- Re: [DNSOP] Bailiwick discussion for draft-ietf-d… Paul Wouters
- Re: [DNSOP] Bailiwick discussion for draft-ietf-d… Brian Dickson
- Re: [DNSOP] Bailiwick discussion for draft-ietf-d… John Levine
- Re: [DNSOP] Bailiwick discussion for draft-ietf-d… Tony Finch
- [DNSOP] Another attempt at consensus on the baili… Paul Hoffman
- Re: [DNSOP] Bailiwick discussion for draft-ietf-d… Vladimír Čunát
- Re: [DNSOP] Another attempt at consensus on the b… Wessels, Duane
- Re: [DNSOP] Another attempt at consensus on the b… Paul Vixie
- Re: [DNSOP] Another attempt at consensus on the b… Brian Dickson
- Re: [DNSOP] Another attempt at consensus on the b… Joe Abley
- Re: [DNSOP] Another attempt at consensus on the b… Ben Schwartz
- Re: [DNSOP] Another attempt at consensus on the b… Wessels, Duane
- Re: [DNSOP] Another attempt at consensus on the b… Tim Wicinski
- Re: [DNSOP] Another attempt at consensus on the b… George Michaelson
- Re: [DNSOP] Another attempt at consensus on the b… Paul Wouters
- Re: [DNSOP] Another attempt at consensus on the b… Mukund Sivaraman
- Re: [DNSOP] Another attempt at consensus on the b… Ben Schwartz
- Re: [DNSOP] Another attempt at consensus on the b… Wessels, Duane
- Re: [DNSOP] Another attempt at consensus on the b… Paul Vixie