From ggm@algebras.org Wed Mar 20 00:17:26 2024 Return-Path: X-Original-To: dd@ietfa.amsl.com Delivered-To: dd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48B4FC1E7236 for ; Wed, 20 Mar 2024 00:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.905 X-Spam-Level: X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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=algebras-org.20230601.gappssmtp.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 l7to6v8TroK0 for ; Wed, 20 Mar 2024 00:17:22 -0700 (PDT) Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 6507BC1DA1C6 for ; Wed, 20 Mar 2024 00:17:21 -0700 (PDT) Received: by mail-oo1-xc29.google.com with SMTP id 006d021491bc7-5a4a2d99598so1755406eaf.2 for ; Wed, 20 Mar 2024 00:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20230601.gappssmtp.com; s=20230601; t=1710919041; x=1711523841; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SDjZhB/wvbY02Le4WrHLxpewCbrEE7FAHDgLNQ4QUrM=; b=fn+qlF91OdIXzlLXg5kcF16nZMbNU8j3ZccCSjpa04uiePRpe7GI+YFAWgfI8eKoUi FZOJ403TUZuKDxcDfhJEsDUJVuFW2Tg6ej6ADSIH1lulWh3NtPe4smejNwugVIcJxAFM CwfVWlA3T6UgP8r2NQX/dT9qA1UcmPWIUg5wACq/u54xsscmDJQFcyBWZ8biDToHodxe ho6Q+2IviuBapBJkTNvlLebrKw4P79Vp6gpbZGPYyYGGduKDN2kOcQ4SDSJvLF8Klb9t Gm6A/i83DW6f2NVb1aOy1rlN6u94kT2nYaxEqneCLbZglwnFN/Dacn8vQVUNSxvNv3Ld JjJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710919041; x=1711523841; 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=SDjZhB/wvbY02Le4WrHLxpewCbrEE7FAHDgLNQ4QUrM=; b=sy9FWmyC/iuSkosuXHsFBYXxBZxGOjVThM8AADMDu69sTcpFHCQAYShllB4v2uZg/A iYZhYB8gqTK3zJLrzcubLE87mtQ26jsd6f0m18qV1+dueIA09m1DOXSxx3+MnQ2Ct/Bl lL5XUR/uWYtZjyaTQYErITgewL8ZHGAZfYH9oRInXmPTbmyh+TO71X/VE4XVwUhEMVMJ E33TzaZwiHekcMGqjl3JDGkZyuBciMZCDw11CaPZxyYWUEqtifOkPfPrlaauFr32P7KH RGjiQEfs6s9ssy6JPtULCcAxBPSOBqgtfhvYmBcd7ZnC0FqhpbMCKcq60QnLu2xhBkdX k1LA== X-Gm-Message-State: AOJu0Ywalwg7/7WtNg2+nWKA3q0r93p/ZcH/2aQ+6mDhh1+wKsLWxt+B yYgorxije24SkI0XPs4/VlJaTbCLM9ycvpLUxd9YqFj8H7nkh42W5u06KEz2NUSbsKfys7NW5Rp rMnkU67Np0CBiUOdaHXa/EmZil8TTowXgHdOp1Q== X-Google-Smtp-Source: AGHT+IE73Q1ojjsCBTfTPnwT8L2CMay+YtntVN1HY+uCSLqy/VNJVuoAC46bnjC8eQqjWhH98NR9JjfVXIkecdL8/ww= X-Received: by 2002:a05:6820:2d43:b0:5a1:dd31:a38d with SMTP id dz3-20020a0568202d4300b005a1dd31a38dmr1397476oob.6.1710919040702; Wed, 20 Mar 2024 00:17:20 -0700 (PDT) MIME-Version: 1.0 References: <20240319.192031.779472543197418519.he@uninett.no> <26106.33066.79339.949428@gro.dd.org> In-Reply-To: <26106.33066.79339.949428@gro.dd.org> From: George Michaelson Date: Wed, 20 Mar 2024 17:17:10 +1000 Message-ID: To: Dave Lawrence Cc: dd@ietf.org Content-Type: multipart/alternative; boundary="000000000000a9398106141261d7" Archived-At: Subject: Re: [dd] [Ext] starting charter text for the DELEG BOF discussion X-BeenThere: dd@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: DNS Delegation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2024 07:17:26 -0000 --000000000000a9398106141261d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable A DELEG record shared over EPP or a functional equivalent should be capable of expressing the information in an NS record, obviating the need to say the same thing twice to your parent through a registrar. On the wire, some might argue for on the fly synthesis. But concrete instantiation simply shouldn't conflict. G On Wed, 20 Mar 2024, 4:24=E2=80=AFpm Dave Lawrence, wrote: > Havard Eidnes writes: > > > DELEG is a replacement mechanism for delegating the name space. > > > > That ("replacement mechanism") may be the intended goal, and might > > have been feasible to acheive if it was invented in the early days > > of the DNS. > > For what it's worth, I haven't heard any of the advocates of changing > the delegation mechanism even hint at believing that it would > completely supplant NS records. I won't be so bold as to claim no one > has never made that remark, but it is not the common belief. > > Yet the "replacement mechanism" language is still apt. A resolver > that follows DELEG instead of NS has, in all practical senses, > replaced NS during that part of its process. > > > However, we are quite far from that situation, and I have not seen > > any discussion about "deployment considerations" for DELEG in the > > current environment. > > That you haven't seen it does not mean it has not been happening. The > conversation has been present among software developers, operators, > registrars, and registries. More of it can be happening on the list, > yes, and will be happening in the working group, but rest assured that > deployment considerations have not been ignored. > > > Or is the plan to exert pressure on folks who don't upgrade their > > resolvers to versions supporting DELEG? How? > > As with my earlier observation, in none of my discussions have I > encountered anyone who has suggested that there be a plan to exert > explicit pressure on any part of the ecosystem, be that to resolvers > or authorities or registries or registries. > > > Or is that going to happen "automatically" because of the built-in > > benefits of DELEG? > > Yes, that's my own view, that features that can be enabled through an > improved delegation mechanism would lead market forces to gravitate to > it. (I wouldn't use "automatically" to describe it though.) > > -- > dd mailing list > dd@ietf.org > https://www.ietf.org/mailman/listinfo/dd > --000000000000a9398106141261d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A DELEG record shared over EPP or a functional equivalent= should be capable of expressing the information in an NS record, obviating= the need to say the same thing twice to your parent through a registrar.
On the wire, some might argue f= or on the fly synthesis. But concrete instantiation simply shouldn't co= nflict.

G
On Wed, 2= 0 Mar 2024, 4:24=E2=80=AFpm Dave Lawrence, <tale@dd.org> wrote:
Havar= d Eidnes writes:
> > DELEG is a replacement mechanism for delegating the name space. >
> That ("replacement mechanism") may be the intended goal, and= might
> have been feasible to acheive if it was invented in the early days
> of the DNS.

For what it's worth, I haven't heard any of the advocates of changi= ng
the delegation mechanism even hint at believing that it would
completely supplant NS records.=C2=A0 I won't be so bold as to claim no= one
has never made that remark, but it is not the common belief.

Yet the "replacement mechanism" language is still apt.=C2=A0 A re= solver
that follows DELEG instead of NS has, in all practical senses,
replaced NS during that part of its process.

> However, we are quite far from that situation, and I have not seen
> any discussion about "deployment considerations" for DELEG i= n the
> current environment.

That you haven't seen it does not mean it has not been happening.=C2=A0= The
conversation has been present among software developers, operators,
registrars, and registries.=C2=A0 More of it can be happening on the list,<= br> yes, and will be happening in the working group, but rest assured that
deployment considerations have not been ignored.

> Or is the plan to exert pressure on folks who don't upgrade their<= br> > resolvers to versions supporting DELEG?=C2=A0 How?

As with my earlier observation, in none of my discussions have I
encountered anyone who has suggested that there be a plan to exert
explicit pressure on any part of the ecosystem, be that to resolvers
or authorities or registries or registries.

> Or is that going to happen "automatically" because of the bu= ilt-in
> benefits of DELEG?

Yes, that's my own view, that features that can be enabled through an improved delegation mechanism would lead market forces to gravitate to
it.=C2=A0 (I wouldn't use "automatically" to describe it thou= gh.)=C2=A0

--
dd mailing list
dd@ietf= .org
https://www.ietf.org/mailman/listinfo/dd
--000000000000a9398106141261d7--