[dd] likely charter issues

[Geoff Huston <[e-mail]>]

> On 21 Mar 2024, at 5:57 PM, Paul Hoffman <[e-mail]> wrote:
> 
> Greetings again. Based on the comments during the DELEG BoF this week, Wes made many changes to the proposed charter that was shown in the BoF. The current version is here:
>   https://github.com/paulehoffman/dns-delegation/blob/main/charter.md
> 
> Please see if the new wording works for you. If so, please say so. If not, please start a new thread with a descriptive subject of what you would like to see changed.

no it does not.

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"?

2. The Objectives mention "DNS authoritative signaling mechanisms" and appears to indirectly refer to the first sentence that its the role of the parent to respond with this additional delegation information. So it appears that the charter want to work on _authoritative_ information provided by the parent. I mentioned in the BOF that I thought that the scope should include a study of the nature of authority models that would permit the parnet to provide authoritative information, but I cannot see this in the new wording.

3. The objective talks about new signalling methods, yet makes no mention of the nature of this introduction of such new mechanisms. It sould be reasonable to either say explicitly "fully backward compatible", or at a minimum note that the scope of the work should include consideration of deployment models that permit existing and new signalling models to coexist across various deployment scenarios.

thanks

  Geoff