Re: [dd] last call on proposed charter to send to the IESG

[Tim Wicinski <[e-mail]>]

I say ship it - The IESG will want to mark it all up themselves.  "Value
Add" and all that.

tim


On Thu, Apr 4, 2024 at 6:12 PM Wes Hardaker <[e-mail]> wrote:

>
> Greetings all,
>
> Paul and I have reviewed the various conversations and believe the
> charter included below reflects the best consensus of the community at
> this point.  We suggest that this is now sufficient to pass to the IESG
> and are requesting a "2 week last call" for needed changes for the
> charter before it gets sent to the IESG.
>
> ----
>
> # Background and Problem Space
>
> The DNS protocol has traditionally had limited ability to signal to
> recursive resolvers about the capabilities of authoritative servers they
> communicate with. In part, this stems from the inability of parents (often
> registries) to specify additional information about child delegations
> (often registrants) beyond NS, DS, and glue records. Further complicating
> matters is the inability of a registrant to signal that the operation of a
> delegation point is being outsourced to a different operator, leaving a
> challenge when operators need to update parental information that is only
> in the control of the child. 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. Data is often out of synchronization between parents and children
> which causes significant problems.
>
> # Objective and Scope
>
> To address these challenges, the working group will first develop the
> requirements for adding a new signaling mechanism that allows parents to
> return additional DNS delegation information about their children.
>
> The working group will also list the other types of information not
> available today that might be provided over a designed signaling mechanism.
>
> The potential first use cases for the working group will be new DNS
> authoritative signaling mechanisms for alternative DNS transports, and
> delegation aliasing (where the parent returns a pointer to the service
> provider that will then return the needed delegation information). The
> working group should also consider how well different solutions can be
> deployed, and should study possible negative consequences of deploying
> alternative delegation mechanisms.
>
> The working group will then define the semantics of a new signaling
> mechanism, taking future extensibility into account.
>
> The working group will specify extensions to the DNS, EPP, and other
> protocols that relate to delegation. The working group will coordinate with
> other working groups as appropriate.
>
> # Deliverables
>
> - A document listing the requirements for a new signaling mechanism
> allowing parents to return additional information when communicating about
> a delegated child. This is expected to be published as an informational RFC.
>
> - A specification defining the new delegation information distribution
> mechanism. The WG will carry out an operational impact assessment and
> include corresponding operational and deployment considerations sections in
> the specification. The specification will include a concept of operations
> that describes how both current and future systems will interact in an
> Internet-wide interoperable way. This is expected to be published as a
> standards-track RFC.
>
> - A specification for how to use the new delegation information to perform
> aliasing of delegation information. This is expected to be published as a
> standards-track RFC.
>
> - A specification for facilitating the use of additional transports for
> DNS. This is expected to be published as a standards-track RFC.
>
>
> --
> Wes Hardaker
> USC/ISI
>
> --
> dd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dd
>