Re: [DNSOP] Another attempt at consensus on the bailiwick discussion

"Wessels, Duane" <dwessels@verisign.com> Wed, 15 December 2021 23:56 UTC

Return-Path: <dwessels@verisign.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 67A5B3A0C23 for <dnsop@ietfa.amsl.com>; Wed, 15 Dec 2021 15:56:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 (2048-bit key) header.d=verisign.com
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 Nn04Z5NxgKmr for <dnsop@ietfa.amsl.com>; Wed, 15 Dec 2021 15:56:17 -0800 (PST)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E99A3A0BE3 for <dnsop@ietf.org>; Wed, 15 Dec 2021 15:56:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3002; q=dns/txt; s=VRSN; t=1639612578; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=kKA/YmN+CSs4kwfuTN0QsO37MqJOcuMApfP2SP9N5Ao=; b=DkYqRqvzyRW8JTNyiAoK6J2bui0tp0i1hscgR8SmdwXfVGmdfsHm6/9z H2B48XMfCp1/MhNRpQ8psyUka3ItDICbAejq6K9pM44JOeCV3hVUuI/H1 S4J8fl7RLnps3AkjwAEVWhHfUZzZ7B6HjZKq8YVw56xlI5xqHqWNqHGiE 5tQV6r5NS80BJ1wcPhwEQxcmLZDRbzgY3oWF8asImVlImN+MJ5zFpz3l2 myCfKYc5mPl7xpot7G60ont7aNXrgjl+9ZnVnvaF2DB7LV501ZUnLhJU8 odG2TgTcialsWQKeRiKKoOJ6wU3EBlZYwkWdzHu9bG3BAnvqs5seDHePR w==;
IronPort-Data: A9a23:yQ+GxanoQd+2kFmP8bYiplfo5gzGJ0RdPkR7XQ2eYbSJt1+Wr1Gzt xJJWziFaP/bamr0etFxa9nloB9Qu8WEnNJgQAtppChkEy4T+ZvOCOrCIxarNUt+DCFjoGGLT ik6QoOdRCzhZiaE/n9BClVlxJVF/fngqoDUUYYoAQgsA180IMsdoUg7wbdg2Nc12YPR7z6l4 rseneWOYDdJ5BYpagr424rbwP+4lK2v0N+wlgVWicFj5DcypVFMZH4sDfjZw0/Df2VhNrXSq 9AvbF2O1jixEx8FUrtJm56lKhFaGua60QKm0hK6UID66vROS7BbPg/W+5PwZG8O4whlkeydx /0Vs9vtYjg5F5TgmdoWfxkGIQhROZdZreqvzXiX6aR/zmXsSV21/NNDPBlse5MT/fxvR2hCs +ICMzZLZReG7w606OvjDLAz3YJ6cZKtYNJ3VnJIlFk1Cd4qXp3YWKjO/vdG0S0xncFBG7DVY M9xhT9HNU2aP0QeYgx/5JQWs8GIiif9ajNj9XXOv+ka42OP6Slwz+24WDbSUpnQLSlPpW6Sq 2fP5G+sXkkVM9uQzTfD+XWpruPKlDnwHoMfCLP+8eRl6HWfwHcUEDUXWEe15/6jhSaDt8l3I VYSozUooLhqrgmwUMO7Whyj5XSD+BQGXYMWDfch7keGza+8DxulO1XohwVpMLQO3PLajxRzv rNVt7sF3QBSjYA=
IronPort-HdrOrdr: A9a23:JiTWX6kcHtZaBJdo/2x/VIo2hV/pDfLx3DAbv31ZSRFFG/Fw8P re+cjztCWE6gr5N0tBpTntAse9qBDnmqKdiLN5VYtKNzOW21dAQrsC0aLShxPtHCHk/vNQ2O NKY8FFZOHYPBxfgdzh6Ae1V/Qt0LC8mpyAtKP7w212RQ9nL5t86Rx0Yzz3LmRtSBJYCYECGJ 2Q28pCq1ObEkgqUg==
X-IronPort-AV: E=Sophos;i="5.88,209,1635206400"; d="scan'208";a="11241903"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.7; Wed, 15 Dec 2021 18:56:15 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2375.007; Wed, 15 Dec 2021 18:56:15 -0500
From: "Wessels, Duane" <dwessels@verisign.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [EXTERNAL] [DNSOP] Another attempt at consensus on the bailiwick discussion
Thread-Index: AQHX8g9YjGqmIcbjA0SEmCxyPTZbwQ==
Date: Wed, 15 Dec 2021 23:56:15 +0000
Message-ID: <315888CA-4429-4038-AB6F-0D38B95A2FA2@verisign.com>
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>
In-Reply-To: <CAHbrMsDpW=Z7R69Zn9Oqxfjo7SnhfuNpj_uL+VN6FS_5oXuA5g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3654.120.0.1.13)
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <A198411E5156874E812787D5D5BC1A45@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Z9Ubn4vsoNr9Bp4VS-Ar0_7Am7U>
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: Wed, 15 Dec 2021 23:56:23 -0000

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.

DW


> On Dec 15, 2021, at 3:18 PM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org> wrote:
> 
> 
> 
> I like this definition.  However, I think it would be clearer to say "useful" instead of "necessary".
> 
> On Wed, Dec 15, 2021 at 1:18 PM Wessels, Duane <dwessels=40verisign.com@dmarc.ietf.org> wrote:
> Despite what the subject line says, I’d like to follow up on the discussion about glue from today’s interim meeting.
> 
> First, I think the definition of glue given in RFC 2181 is problematic in a number of ways.  It is overly broad (e.g., "any record ... that is not properly part of that zone” and "any other stray data that might appear”).  It essentially says that all non-authoritative data is glue, including NS, which is wrong IMO.
> 
> If we can ignore what 2181 says, then the question is whether or not glue is limited only to addresses.  Historically it has only meant addresses, since those address RRs were required for zones with in-domain name servers.  There are some new proposals in DPRIVE to publish more record types in parent zones and have them considered as glue.  This has obvious implications server behavior given the glue-is-not-optional draft.
> 
> On one hand I think it would be a lot simpler to just say that only address records can be glue.  But I’m not sure that is defendable given the directions things are going.  Here’s a definition of glue that I came up with:
> 
> Glue is non-authoritative data in a zone that is transmitted in the additional section of a referral response on the basis that the data might be necessary for resolution to proceed at the referred name servers.
> 
> I also feel like we might be heading in a direction where there would need to be a registry or some standardization of which RR types can be treated as glue.
> 
> DW
> 
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop