From ggm@algebras.org Tue Mar 19 16:42:14 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 84D1FC14F5FC for ; Tue, 19 Mar 2024 16:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 SI5dSef0X_2w for ; Tue, 19 Mar 2024 16:42:12 -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 CE4A9C14F5F2 for ; Tue, 19 Mar 2024 16:42:12 -0700 (PDT) Received: by mail-oo1-xc29.google.com with SMTP id 006d021491bc7-5a4b35ff84eso1802355eaf.2 for ; Tue, 19 Mar 2024 16:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20230601.gappssmtp.com; s=20230601; t=1710891731; x=1711496531; darn=ietf.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=nlqyMs7FLiSF01JkHrqNnpKYJVt742PEuYmQSBATrQg=; b=qg1MQbizAPiPg/U5HmUzN5yyoyQCEFlZNVCsMQbCMiCkRSeNppIL+mRm0gS5c7glew pqB4UM4USmusm8m/BzIkI4RaaRiLtojqhaZ2OHobw1cAM06nLqk2BJPnuuGpfv2ckd/B KLCn5S9sUhTHHf+U5PXdfMiCtZMetyNguBLum7qkedXYVuniyFeXT72wj9gBm+9Ue+QZ EIHX/UDBd8DHhMk/02VYiM7Fdz+rEOFa1Ktnwcx2bnjqL9/o59ibZNt5dMWVe1z/3x2G 1Br07+XMB5QPS+Cb765qGL6VSV+eJnPArWFdlA8G+lHJZ9XJoMiNHRfTt5TGVfUztXPD qo8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710891731; x=1711496531; h=content-transfer-encoding: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=nlqyMs7FLiSF01JkHrqNnpKYJVt742PEuYmQSBATrQg=; b=Yascp1gAC6pVy3mEwl1iPsVvax5UL4szftWal7InJboZaOvVQT/qpK6n3fooIMLl4k 0oKM4GEbSYBaZiicuU86q31EKZk2x7JtSIxH4MR9SQk5OkL2bIa8TukRErmiP7MNXLvn ilrC4dbq18uZSvf7Pe1ElZ9dnZUBffW1DwNMufSNwExFbd+uAAREqNcChafgIyAPngv3 qBagE6HSxIetIITEM7laWsUsyMxEMx8EKioLU6AaYLusHFqfjMC3MfqxWFvCLs/Cx9Sl GORrhJ0W1bg/pLidpPkUA84lpzwyQ2Hep1ktpCVitHseiAoBbVryFHG0lDfKGSh+TxOQ WUuw== X-Gm-Message-State: AOJu0Yzhbn0kSCQFr3S/Da9eadJ21l4AkOX5/um/Yl73ILmb4mMzic2s nmNLQ5nWFqUBJqgKoGrPLYh26SN9Pd9Vnnt0PDkUOu/n9oF9TfOjnUcPgmdF3Z6dp8l/+l+7ou8 4QSTwAAi+x1g4eHrxnawYZKmUG8yw3JEkGWZZWF87DNGP7lb7 X-Google-Smtp-Source: AGHT+IHoplcnazjHFtqqqdgSH8FuOHzzPIZlTeIA5Cvdng86J4WB+unw+HzlCLXfZbC46WJxj9T+HqcGp+833sp1bus= X-Received: by 2002:a05:6820:2018:b0:5a1:c5eb:18b4 with SMTP id by24-20020a056820201800b005a1c5eb18b4mr2396490oob.2.1710891730929; Tue, 19 Mar 2024 16:42:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: George Michaelson Date: Wed, 20 Mar 2024 09:41:59 +1000 Message-ID: To: "dd@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dd] DBOUND scope 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: Tue, 19 Mar 2024 23:42:14 -0000 Maybe a divide-and-conquer issue here is how to specify zone-cut and policy limits to zone cut(s) -because right now every mechanism I imagine comes with its own set of issues. I wouldn't preclude this being a future information type inside an extensible model of DELEG, but I would think there is a bit of work, problem-statement class before diving in. In that sense, a DELEG charted could be prepared to say something about future extensible models. And thus, NOT out-of-scope (in the future) -G On Wed, Mar 20, 2024 at 9:05=E2=80=AFAM Peter Thomassen wr= ote: > > > > On 3/19/24 12:53, Ben Schwartz wrote: > > I saw a few concerns in Zulip today about whether the DBOUND-like work = is addressable by /any/ technical solution. I think it is. Additionally, = I think: > > > > * We should use DELEG to solve it. > > ... at least for parent-side claims. > > I have little hope that there's a way to express child-asserted domain bo= undaries through delegations (because they are asserted by the parent). > > So, I think that any effort in this direction (be it now or in the future= ) should declare child-asserted domain boundaries *out of scope*. > > Peter