Re: [dnssd] WGLC on draft-ietf-dnssd-hybrid-03

[Markus Stenberg <[e-mail]>]

I was on vacation during WGLC (good timing - I was leaving home when it started, lost my laptop charger early on the trip and by the time I got home official WGLC window was done). Disclaimer: This is a beer-powered remotely participating hobbyist commentary based on reading my own earlier comments + draft deltas, and does not consititute a full review. Sorry.

Anyway..

Section 1 - isn’t this scheme essentially aiming at causing more multicast duplication too? (e.g. given ‘home’ DNS-SD browse domain, if we send unicast for each sublink.home, we wind up with N multicasts per single logical request).

Section 4.5.1 - I wonder about positive TTL limiting. Because if device ‘moves’, it most likely will either
a) have two different names (foo.link1.home, foo.link2.home), or
b) one name with two addresses (foo.link1.home A 192.168.1.1, foo.link1.home A 192.168.1.2).

Happy Eyeballs-ish should take care of either in practise, so I am against positive TTL limiting. Negative TTL limiting makes sense except in some DoS scenarios which can be circumvented to some degree by e.g. limiting total # of multicasts send by hybrid proxy over time interval per link or something.

Overall, I find the text bit too prescriptive (‘do it this way’), as it forbids you from having a service that e.g. only supports printer and apple TV services, and proactively queries for them rarely => no need for extra traffic by whatever occurs on wire, and the content could be even pushed to e.g. normal DNS-SD using DNS Update or equivalent ( draft-lemon-homenet-naming-architecture-00.txt has strawman proposal about this, and I thought about it years ago too but never got around to implementing or specifying it ). Another scheme would be completely passive node that did clever things with e.g. L2 availability to detect when stuff drops off link ‘fast enough’.

Second major missing piece from my point of view is the section 6.4 paragraph 2 - stitching together of zones. As it is, the single logical request => N multicasts propagation sounds somewhat undesirable to me.

While not having reread the whole thing again (see sorry above), my earlier nits are mostly addressed, I cannot find anything particularly broken (see disclaimer about beer), and I think it is ‘ready’ for some  definition of ready. I would not personally want it as a choice for any large network though, due to it forcing exactly one operating model for the mdns->dnssd translation which I am no longer convinced is actually optimal. For home network purposes this works, but I would be leery of saying this is ’the way to do it’ without some simulation results in e.g. enterprise or university deployment scenarios.

Cheers,

-Markus