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

[Jonathan Hui <[e-mail]>]

On Fri, Aug 13, 2021 at 4:19 AM Ted Lemon <[e-mail]> wrote:

> On August 12, 2021 at 11:08:44 PM, Simon Lin (
> simonlin=[e-mail]) wrote:
>
> 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.
>
> I don't think dnssd-zone-discover helps with this. I think the client
> needs to either unregister itself with SRP before migrating, or follow the
> same protocol I mentioned earlier with respect to its service
> advertisement: advertise without asserting uniqueness.
>
On Wi-Fi, the device needs to discover the SRP server. Why can't
dnssd-zone-discover help with that? If there is a single SRP server in the
network and it is servicing both Wi-Fi and Thread networks, we don't need
to deal with conflicts. If there are multiple SRP servers, then I hope SRP
replication will address the vast majority of cases.

> > 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.
>
> This is a good point—SRP replication also increases complexity, but it
> constrains it nicely to the more capable nodes on the network—the ones that
> are acting as ad-hoc infrastructure and not as end nodes.
>
I hope SRP replication will eliminate the need for end devices to handle
conflicts directly. Hopefully we can get some operational experience as to
whether other mitigations are necessary.

--
Jonathan Hui