[dnssd] Review of draft-sctl-advertising-proxy-00

[Jonathan Hui <[e-mail]>]

I have reviewed this document.

I believe this document addresses a real pain point for constrained
networks - namely how legacy clients can discover services offered by
constrained devices using a service registry. As mentioned in my review of
draft-ietf-dnssd-srp-02, this is of great interest to the Thread Group and
Project CHIP efforts, both of which are based on IPv6.

Overall, this document looks like a great start.

Are there considerations for having multiple Advertising Proxies and SRP
servers active on the same link? Is that within scope of this document?

More targeted comments:

2.4.  No Address Suppression


I see this addresses one of my questions in my review
of draft-ietf-dnssd-srp-02.

disconnecting and then reconnecting to the network.  The service
> registry has no reliable automatic way to determine whether a device
> that registered records has failed or disconnected from the network.
>

Would we permit implementations that do have visibility into whether a
device has disconnected from the network? I realize this is a layer
violation and technology specific.

their records in a unicast DNS namespace, there is a presumption they
> they will only register addresses with sufficient scope to be usable


Typo: "they they"

3.  Security Considerations
>

I know draft-ietf-dnssd-srp-02 describes cryptographic mechanisms to
enforce first-come, first-serve naming. I presume with the introduction of
Advertising Proxy, the same guarantees do not extend to legacy devices
publishing via mDNS. Should we mention that here?

An Advertising Proxy may made data visible to eavesdroppers on the


Typo: "may made data" -> "may make data"

Thanks.

--
Jonathan Hui