Re: [dd] starting charter text for the DELEG BOF discussion

[Manu Bretelle <[e-mail]>]

On Tue, Mar 5, 2024 at 7:59 AM Ralf Weber <[e-mail]> wrote:

> Moin!
>
> On 2 Mar 2024, at 21:39, Wes Hardaker wrote:
>
> [..]
> > # 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 DNS delegation information to resolvers.
>
> Given that there is current work on actual protocol ideas that would stall
> that. I’m ok with a requirements document and changing the spec, but I
> don’t want to stall that work, so maybe delete “first” from that sentence.
>
>
> > The working group will also list the other types of information not
> available today that might be be provided over a designed signaling
> mechanism.
> >
> > The working group will then define the semantics of a new signaling
> mechanism, taking future extensibility into account.
> >
> > The first use case for this DNS delegation signalling mechanism is
> expected to be delegation aliasing, where the parent returns a pointer to
> service provider that will then return the needed delegation information.
> > This use case has been discussed for many years in the DNSOP and other
> Working Groups.
>
> While this is one use case it might no be the first that finishes, so IMHO
> we should maybe use that as an example and having a generic additional use
> cases for the delegation mechanism in the charter.
>
>
Agreed, we should make sure that AliasMode and ServiceMode DELEG are being
designed alongside so we don't end up cornering ourself with conflicting
modes.
While delegation aliasing is an important use case, I think transport
upgrade is also an important one that has had us running circles for a
while and treating this as a first class citizen use-case is important IMO.

Manu