Re: [dnssd] Adoption call for draft-sctl-advertising-proxy

[Simon Lin <[e-mail]>]

> Specifically,
> imagine a dual-radio device (WiFi and Thread) which for some reason
> migrates from being an SRP client to an mDNS client or vice versa.

What's the solution to resolve the case where an SRP client migrates
to be an mDNS client. When the mDNS client tries to advertise its DNS
service, it will conflict with the SRP server of the original SRP
client. I don't think SRP replication can solve this problem.

As Jonathan said, always using SRP regardless of whether the device is
connected via Thread or WiFi can solve this problem. Also maybe the
device can unregister itself from SRP when it has migrated to WiFi,
which requires the device to remember the IP address of the SRP
server, or to use draft-tljd-dnssd-zone-discover.

> The way I'm currently proposing to address this is by requiring SRP
> replication when there is more than one SRP server, and by not renaming,
> but rather waiting for the conflict to resolve.

Agree that SRP replication is the most user-friendly way of addressing
this problem.

> An additional mitigation strategy is to not actually detect conflicts. If
> we have two conflicting registrations, and SRP replication doesn't resolve
> them, then they just coexist until one goes away.

Does this strategy violate mDNS protocol? Moreover, if two different
devices register their service on different SRP servers using the same
name, it's not a good idea to not resolve the conflict since the
conflict will last for a long time.

> The only other alternative is to rename. I think this is too heavy of a
> solution, but I'm open to debate.

It increases the complexity on every device that needs to browse for
mDNS services. I would prefer SRP replication to renaming.

--
Simon  Lin