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

[Toerless Eckert <[e-mail]>]

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]