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

Tim Wicinski <tjw.ietf@gmail.com> Thu, 16 December 2021 00:09 UTC

Return-Path: <tjw.ietf@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 740D73A0D25 for <dnsop@ietfa.amsl.com>; Wed, 15 Dec 2021 16:09:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 oSsIfjeR-i4d for <dnsop@ietfa.amsl.com>; Wed, 15 Dec 2021 16:08:56 -0800 (PST)
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D00A93A0D29 for <dnsop@ietf.org>; Wed, 15 Dec 2021 16:08:55 -0800 (PST)
Received: by mail-lf1-x12d.google.com with SMTP id u3so46294798lfl.2 for <dnsop@ietf.org>; Wed, 15 Dec 2021 16:08:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=al/hh1l6O4rS6zsAVp5KZHDIVeEBP4ZbqTR/EkFAY9U=; b=XX45mRzjLtX34trOjf39UNRLcxM1uUZLTe3Nly2BDkLLj3QVlITxJK+GmRTvtRIezS fcYsIAq4MKEXKTSqjfOVUnGYKdA3sEr9XEqwWHb8eodtdXjs4Dt91xf7DOlu6NCn0cJN eE+TIJT40FtVSx5vPo0oH1pbwhTB/HDqbyswSm2SF8ntepwAWQF7hryJS987tGHxl+Tr eqV+GzHgh4B846WhcaUeywC3OJr8NRi6E4rcLHhMkYAirJ4mquybOvBuG8j8B4HUmr1f Brd/gjP1qWWJdeWje9T+SrKt9k6xwVoYhbCf19LgaYsIFB8el4X1yS9ln6Z55LXjfVax 21Yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=al/hh1l6O4rS6zsAVp5KZHDIVeEBP4ZbqTR/EkFAY9U=; b=SNxC+2YO38nFYV/0TDqDvD4V6XtcEp3qyZhVQG7vrrQvWIn6pUgd+OxX8ruq973mU7 FAZv+9AHKumthDkx4nyP5dlBBlFcD9ynT8b8bCEv0LPE3Ttki17NMoRHAFAPPPzXokk9 kt+AulVdJrOUs2zGxin3USLNe7LVQ2pGBptwWF9uI17ISlw0UxiBLrQbshnCgaRwu3AP cow3mXNFtKq5Q/RVFGuWYC1/KcfAQf+CL6bLOt4Uhy8jQp0ZuQ5QP6t/tcadPOA5hRFz giC1IFTrSvw6xbo3xN3Jq5czBlaNSBvuf02jqLMQ5THhn1ZSfOwTU26UMVPTCCXTDNMS pXsQ==
X-Gm-Message-State: AOAM533wBS+kMGp6Wya8eT7B6IA2ke37/XLBdcxY7yUrL8aXp7GRkn8p rqHnqTR+Y4Z2Vxm7mkJ6ZtcdxwzZNoCkepPYt5k2NOXD
X-Google-Smtp-Source: ABdhPJwb8mqQpQpf4MAySqb6D46aoFKPTDyDpXa//nxpLCtye8xfZWcCX1E+my6DfcYW3vovgKlEvPmrjjT4ti3XXxI=
X-Received: by 2002:ac2:5df6:: with SMTP id z22mr11964032lfq.230.1639613332081; Wed, 15 Dec 2021 16:08:52 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <315888CA-4429-4038-AB6F-0D38B95A2FA2@verisign.com>
From: Tim Wicinski <tjw.ietf@gmail.com>
Date: Wed, 15 Dec 2021 19:08:41 -0500
Message-ID: <CADyWQ+Hpiuk1Ui7rjSaiUM4FFB20Qr4TRvnAjxO=OBGJ2j7N6A@mail.gmail.com>
To: "Wessels, Duane" <dwessels=40verisign.com@dmarc.ietf.org>
Cc: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003a50ad05d3383aa5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ShKsB1b66NajUNhtfHDuZC1VEso>
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 00:09:07 -0000

(no hats)

I feel that "might be useful" leaves the definition still ambiguous.

I like Paul V's additions on where the glue must reside, and noting that it
will be passed along with transfers.

tim




On Wed, Dec 15, 2021 at 6:56 PM Wessels, Duane <dwessels=
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.
>
> 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
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>