Re: [dd] [Ext] starting charter text for the DELEG BOF discussion

Paul Hoffman <paul.hoffman@icann.org> Tue, 05 March 2024 20:06 UTC

Return-Path: <paul.hoffman@icann.org>
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 8E967C14CF1F; Tue, 5 Mar 2024 12:06:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level:
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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
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 afoh37jfb5SP; Tue, 5 Mar 2024 12:06:20 -0800 (PST)
Received: from ppa4.dc.icann.org (ppa4.dc.icann.org [192.0.46.77]) (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 4C303C15107F; Tue, 5 Mar 2024 12:06:19 -0800 (PST)
Received: from MBX112-W2-CO-1.pexch112.icann.org (out.mail.icann.org [64.78.33.5]) by ppa4.dc.icann.org (8.17.1.24/8.17.1.24) with ESMTPS id 425K6AGS031659 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 Mar 2024 12:06:10 -0800
Received: from MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) by MBX112-W2-CO-1.pexch112.icann.org (10.226.41.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Tue, 5 Mar 2024 12:06:14 -0800
Received: from MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) by MBX112-W2-CO-1.pexch112.icann.org ([169.254.44.235]) with mapi id 15.02.1258.028; Tue, 5 Mar 2024 12:06:14 -0800
From: Paul Hoffman <paul.hoffman@icann.org>
To: Ben Schwartz <bemasc=40meta.com@dmarc.ietf.org>
CC: "dd@ietf.org" <dd@ietf.org>
Thread-Topic: [Ext] [dd] starting charter text for the DELEG BOF discussion
Thread-Index: AQHabzbMCudPsp4sSEGJ8GX4tx3BmbEqGNOA
Date: Tue, 05 Mar 2024 20:06:14 +0000
Message-ID: <CD3A8291-EE91-49AB-BBEE-9120AB4A24FC@icann.org>
References: <yblbk7wl65k.fsf@wx.hardakers.net> <SA1PR15MB4370F1D275E94CD1AE2C8A89B3222@SA1PR15MB4370.namprd15.prod.outlook.com>
In-Reply-To: <SA1PR15MB4370F1D275E94CD1AE2C8A89B3222@SA1PR15MB4370.namprd15.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.0.32.234]
x-source-routing-agent: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <139255345EEB5545BBA3A239B991692A@pexch112.icann.org>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-03-05_17,2024-03-05_01,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/5lYP3CBCAKPF_hWTAlrhaS2XiUE>
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 <dd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dd>, <mailto:dd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dd/>
List-Post: <mailto:dd@ietf.org>
List-Help: <mailto:dd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dd>, <mailto:dd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Mar 2024 20:06:22 -0000

On Mar 5, 2024, at 11:52, Ben Schwartz <bemasc=40meta.com@dmarc.ietf.org> wrote:
> 
> This charter text doesn't mention encryption, TLS, or QUIC.

Correct. It doesn't mention anything from <https://mailarchive.ietf.org/arch/msg/dd/H2p3Mzgc02ineG9-ccIHuNKbS3w> other than aliaasing.

> It seems to me that enabling encrypted transport upgrade is a key motivating factor that drives many aspects of the DELEG design.

It was a key motivating factor, but then was not developed to the extent that aliasing was.

>   Encryption should at least be mentioned in the charter, and the group's intention should be spelled out here to avoid confusion about the division of responsibility between DELEG and DPRIVE.

If there's a lot of interest on this list for that use case, it could certainly be added to this proposed charter. Please propose text.

According to the DPRIVE chairs, DPRIVE is going dormant, so it seems unlikely to recharter to take on a new work item that could be covered in a different working group. Having said that, if the working group that comes out of this BoF does cover identifying encrypted transports during delegation, the chairs of that WG should certainly reach out to the DPRIVE mailing list even if the WG has shut down.

--Paul Hoffman