[dnssd] Re: DNSSD: DNS-SD discovery for BRSKI and variations

[Chris Box <[e-mail]>]

Toerless,

The chairs agreed that we would only grant agenda time to this topic if we
heard there was interest from working group members. As of this point,
we've not seen any, so the current position is that it won't be on
Thursday's agenda.

If any list members want to amend that position, e.g. after seeing your
slides, please let us know: [e-mail]

Thanks
Chris

On Tue, 5 Nov 2024 at 12:34, Toerless Eckert <[e-mail]> wrote:

> I've proposed slides for the topic to datatracker.
>
> These are the same slides as i'll use for ANIMA:
>
> https://datatracker.ietf.org/meeting/121/materials/slides-121-anima-04-brski-discovery-00
>
> except that i would of course concentrate @dnssd on the DNS-SD relevant
> background,
> details and questions, whereas the ANIMA presentation is focussing  on the
> diffs over IETF120
> draft state.  (yes, sorry, slide deck reuse is not ideal...).
>
> Cheers
>     Toerless
>
> On Wed, Oct 23, 2024 at 12:41:04AM +0200, Toerless Eckert wrote:
> > Dear DNS-SD WG
> >
> > I was wondering if i could bother you folks in taking a look @ and
> providing
> > feedback suggestions 4 our ANIMA-WG draft:
> >
> > https://www.ietf.org/archive/id/draft-ietf-anima-brski-discovery-05.html
> >
> > This should have a couple of aspects of general interest to DNS-SD
> enthusiasts, but
> > also some new concepts.
> >
> > If there is interest, i would be happy to present about it at the
> IETF121 DNS-SD WG meeting.
> >
> > BRSKI is the IETF ANIMA secure onboarding protocol for devices, where
> > for resilience and automation its highly beneficial to discover
> onboarding
> > servers (registrars), and in the absence of full routing also proxies
> for them.
> >
> > If this sounds boring, consider that unfortunately several industry
> groups have diffeent
> > opinions about protocol details, so we have ended up in a set of
> variations of the
> > protocol where not necessarily all servers are compatible with all
> clients. So this
> > draft introduces an extensible method to indicate supported variations
> so clients
> > can pick the right server. More importantly, proxies can discover all
> possible
> > variations even future ones and create appropriate proxy announcements.
> >
> > Of course, we want discovery to be fast and resilient, so there is also
> text about the
> > details how to select the best server based on prio & weight and time
> out in case it's
> > not responding. And how to optimize this in the face of having to do
> this as a proxy
> >
> > If that's not annoying enough, then there is also no consensus on what
> discovery protocol
> > is the best, so we have to support DNS-SD, GRASP and CORE-LF... today,
> tomorrow may be
> > more, and i really don't want to see specs over specs written for a full
> matrix, so the
> > draft also attempts to reduce this problem into a cross-discovery
> mechanism IANA registry,
> > so that we hopefully can easily define extensions mostly only through
> additional registrations
> > in that registry. Which might also be a concept for other protocols with
> similar interop issues.
> >
> > If thats' not enough, we also needed to discover client devices (which
> we call pledges)
> > via DNS-SD by their serial number, so we had to define a scheme by which
> we do
> > that, which is also described.
> >
> > So, if any of this sounds like an interesting application use of DNS-SD
> that you'd
> > like to check out as DNS-SD folks, please do so!
> >
> > Cheers
> >     Toerless
> >
>
> --
> ---
> [e-mail]
>