Re: [dd] Havard's thread Re: [Ext] starting charter text for the DELEG BOF discussion
Edward Lewis <edward.lewis@icann.org> Wed, 20 March 2024 12:27 UTC
Return-Path: <edward.lewis@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 C5764C14F6F1 for <dd@ietfa.amsl.com>; Wed, 20 Mar 2024 05:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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
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 V_YLnsBr7cqZ for <dd@ietfa.amsl.com>; Wed, 20 Mar 2024 05:27:05 -0700 (PDT)
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 8ED89C14F6E8 for <dd@ietf.org>; Wed, 20 Mar 2024 05:27:05 -0700 (PDT)
Received: from MBX112-E2-VA-1.pexch112.icann.org (out.mail.icann.org [64.78.48.205]) by ppa4.dc.icann.org (8.17.1.24/8.17.1.24) with ESMTPS id 42KCQecE004028 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 Mar 2024 05:26:40 -0700
Received: from MBX112-E2-VA-1.pexch112.icann.org (10.217.41.128) by MBX112-E2-VA-2.pexch112.icann.org (10.217.41.130) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1258.28; Wed, 20 Mar 2024 08:27:03 -0400
Received: from MBX112-E2-VA-1.pexch112.icann.org ([10.217.41.128]) by MBX112-E2-VA-1.pexch112.icann.org ([10.217.41.128]) with mapi id 15.02.1258.028; Wed, 20 Mar 2024 08:27:03 -0400
From: Edward Lewis <edward.lewis@icann.org>
To: Dave Lawrence <tale@dd.org>, "dd@ietf.org" <dd@ietf.org>
Thread-Topic: [dd] Havard's thread Re: [Ext] starting charter text for the DELEG BOF discussion
Thread-Index: AQHaeoV/w269d3deWEeHSeroTRuJUbFAgCuAgABNHgD//8F+AA==
Date: Wed, 20 Mar 2024 12:27:03 +0000
Message-ID: <4DA817D9-54D8-4B7B-938F-156774D92ACC@icann.org>
References: <D52147D7-C779-46C4-8B27-C27502D541D0@icann.org> <26106.28843.737951.303072@gro.dd.org> <F74E2C0A-BCCC-42F5-B8AB-5255FAB08C94@icann.org> <26106.53830.98971.446723@gro.dd.org>
In-Reply-To: <26106.53830.98971.446723@gro.dd.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.65.22091101
x-originating-ip: [192.0.47.234]
x-source-routing-agent: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <DBC5D81A46886746A7C3E6642908341D@pexch112.icann.org>
Content-Transfer-Encoding: base64
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-20_08,2024-03-18_03,2023-05-22_02
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/s4ek_Hz5HGIxUpWNu7HfvrSJn2I>
Subject: Re: [dd] Havard's thread Re: [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: Wed, 20 Mar 2024 12:27:11 -0000
On 3/20/24, 08:11, "dd on behalf of Dave Lawrence" <dd-bounces@ietf.org on behalf of tale@dd.org> wrote: >it ...doesn't really add clarity or meaning to discussions about what to do about DNS protocol development. I think of the term "the camel" as a reminder that continuing to make the DNS protocol more complex, the rate of deployment of the changes diminishes. When we modify the protocol, the result is that the protocol must be simpler, simpler to operate (to be specific). Raising the camel in this context is a reminder that DELEG needs to consider its transition path. DELEG is only an enabling technology; it is not an end goal. DELEG won't win over friends in operations alone, it will as a path to a DNS that is less costly to operate. Because I'm using terms loosely - "less costly" includes lower risk of operational mishaps due to rolling out DELEG. The fear that change will cause outages is one topic to be addressed in deployment considerations. Lowering cost is one reason operators will deploy something, the other is raising revenue (functionality, depending on how you want to say it). DELEG isn't, on its own raising anything but it enables modifications that could, so I'm focusing on lower cost to deploy as the selling point.
- [dd] Havard's thread Re: [Ext] starting charter t… Edward Lewis
- [dd] Havard's thread Re: [Ext] starting charter t… Dave Lawrence
- [dd] DELEG and the DNS camel Jim Reid
- Re: [dd] Havard's thread Re: [Ext] starting chart… Edward Lewis
- Re: [dd] Havard's thread Re: [Ext] starting chart… Dave Lawrence
- Re: [dd] Havard's thread Re: [Ext] starting chart… Edward Lewis