Re: [dd] Charter issue: synchronization between parents and children
Wes Hardaker <wjhns1@hardakers.net> Thu, 04 April 2024 21:24 UTC
Return-Path: <wjhns1@hardakers.net>
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 A3E2BC1519A4 for <dd@ietfa.amsl.com>; Thu, 4 Apr 2024 14:24:19 -0700 (PDT)
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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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 (1024-bit key) header.d=hardakers.net
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 oDgQRqAdVfPd for <dd@ietfa.amsl.com>; Thu, 4 Apr 2024 14:24:15 -0700 (PDT)
Received: from mail.hardakers.net (mail.hardakers.net [107.220.113.177]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 AB8D4C1C3D62 for <dd@ietf.org>; Thu, 4 Apr 2024 14:24:15 -0700 (PDT)
Received: from localhost (unknown [10.0.0.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hardakers.net (Postfix) with ESMTPSA id 52AD920628; Thu, 4 Apr 2024 14:24:08 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mail.hardakers.net 52AD920628
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hardakers.net; s=default; t=1712265848; bh=14Ys6geS4o1K4OZE/f9iXV+h2hZebuJGcXFYG9/EYDk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=sKDuBR9S8HQfsSD77IT75o56VccGpggjrGuhqjJVW/joUYoECXoi+13EyJE+LfDi0 0/DPLpPNvKO9KjNZn+O9ujeefz2qTQstjaq7W0mBA+Ql9GNWeftX6tBiloyGO/p4Oh CJNAai1cCL3RNLezQHZaGy4Y4TXVD/wJ6vk8N4s8=
From: Wes Hardaker <wjhns1@hardakers.net>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: "dd@ietf.org" <dd@ietf.org>
In-Reply-To: <AC35CB3A-B217-4F4B-80C6-4DB3DC04CEC0@icann.org> (Paul Hoffman's message of "Thu, 21 Mar 2024 08:25:36 +0000")
References: <49CC837E-4D8E-45CF-A0B5-7A28A82B1939@icann.org> <2CD3FF34-28B7-4A40-A68B-1E20EF4CB6C9@gmail.com> <AC35CB3A-B217-4F4B-80C6-4DB3DC04CEC0@icann.org>
Date: Thu, 04 Apr 2024 14:24:08 -0700
Message-ID: <yblmsq895zb.fsf@wd.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/dd/iGbltscPBSUwJSQNtkhD7aRumJs>
Subject: Re: [dd] Charter issue: synchronization between parents and children
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: Thu, 04 Apr 2024 21:24:19 -0000
Paul Hoffman <paul.hoffman@icann.org> writes: FYI, I'm back from a week of vacation and catching up. I'll respond to some of the threads based on my personal opinion. > > 1. Background and problems includes: ." A significant issue in > > today's deployed DNS that derives from these issues is data often > > being out of synchronization between parents and children. Said > > another way, children often have more up-to-date information about > > the nameservers and DNSSEC keying information than their parents due > > to slowness, or complete lack, of automated child-to-parent > > updates." > > > > But there is no mention of any objective or deliverable that > > specifically addresses this "significant issue". > > > > Is this topic in or out of scope? If its in scope then should there > > be a deliverable that references this? If its out of scope then why > > mention synchronisation at all, let alone as a "significant issue"? > > My no-hats interpretation is that it is definitely in-scope and would > need to be dealt with in the requirements document. It is, after all, > listed as a significant issue in the charter. I agree with Paul here. There is always a struggle with working groups crafting new protocols about how much to put in the charter vs what to list in requirements. George is right that when possible the charter should be explicit as possible. But in this case, I don't think requirements gathering is completed yet as not all corners of the industry have really signed off on a list of needs yet. Hence the first goal of the WG, IMHO, should be gathering requirements -- this does leave holes in the charter, however, but the requirements for requirements [sic] is the best mitigation for this. Any resulting proposed solution will need to ensure it conforms to the documented and WG accepted requirements. -- Wes Hardaker USC/ISI
- [dd] Back to the charter Paul Hoffman
- Re: [dd] Back to the charter George Michaelson
- [dd] likely charter issues Geoff Huston
- [dd] Charter issue: resource records Paul Hoffman
- [dd] Charter issue: synchronization between paren… Paul Hoffman
- [dd] Charter issue: authority models Paul Hoffman
- [dd] Charter issue: Introduction of new signaling Paul Hoffman
- Re: [dd] Back to the charter Wes Hardaker
- Re: [dd] Back to the charter George Michaelson
- Re: [dd] Charter issue: Introduction of new signa… Geoff Huston
- Re: [dd] Back to the charter Havard Eidnes
- Re: [dd] Charter issue: synchronization between p… Wes Hardaker
- Re: [dd] Back to the charter Wes Hardaker