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