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

[Martin Turon <[e-mail]>]

Hi All,


I'm writing to offer my support for adopting
draft-sctl-advertising-proxy-02
<https://datatracker.ietf.org/doc/html/draft-sctl-advertising-proxy-02>
by the workgroup.  I have read and reviewed the document and view it
as ready to publish.


The advertising proxy provides an important optimization for a
foundational IoT use case -- bridging legacy multicast DNS clients on
WiFi with unicast SRP clients on a stub network such as Thread, and
allowing seamless service discovery across both scopes.  As mentioned
by others, the Matter <https://buildwithmatter.com/> standard is
planning to leverage this work heavily, and an open source
implementation <https://github.com/project-chip/connectedhomeip> of
the work based on this draft is underway now in that forum.


A few minor comments to note from this final review:


1) *Editorial*: "provide with" is awkward phrasing. Remove "with" or
possibly add a word/object.


In order to address this problem, it may be advisable to *provide with*

   a way for the advertising proxy to inform the mDNS service that it

   should continue to advertise the name that is in conflict, rather

   than ceasing to do so when the conflict is detected.


2)  *Editorial*: as Nathan mentioned, "may made" should be "may make"
in the Security Considerations section:


   An Advertising Proxy *may made* data visible to eavesdroppers on the
   configured multicast-capable link(s).


3) *Question:* Regarding "2.1.1
<https://datatracker.ietf.org/doc/html/draft-sctl-advertising-proxy-02#section-2.1.1>.
Name Conflicts in Managed Namespaces"


Is the case of a device conflicting with itself handled? 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.  When
the device tries to re-register its services to direct to its new,
renumbered IP addresses, could its own stale records on the proxy possibly
lock it out?


Thank you for the good work here, Stuart and Ted!


Regards,

Martin

_____________________________
Martin Turon  |  Google