On 10/22/2012 09:30 AM, Kerry Lynn wrote:
On Mon, Oct 22, 2012 at 12:15 PM, Michael Thomas <[email protected] <mailto:[email protected]>> wrote:On 10/22/2012 07:22 AM, Tim Chown wrote: And I don't think this possibility is excluded at all by the current arch text either. It talks of an authoritative name service running on the CER, with a dynamic registration service (e.g. dyndns). I have added 'as far as possible' to the unmanaged text. It's been hard for me to gauge what is and isn't in scope on the naming front. For the most part, this wg looks like it's only interested in putting some band-aides on mdns/dns-sd. That's a mistake, IMO, because there's nothing inevitable about a zeroconf driven design. We should consider littleconf solutions especially for naming because there is no way that mikes-toothbrush.mtcc.com <http://mikes-toothbrush.mtcc.com> got named that way coming from the factory. Not sure how you can draw that conclusion; there seem to be lovers and haters of mDNS. To the extent that it's unsuited for multi-link topologies, a BoF has been approved to discuss problems and requirements. I hope that folks interested in a DNS-based solution to service discovery and naming will join the mdnsext mailing list.
As I mentioned, what I'm thinking about doesn't need multicast at all. So it would be pretty bizarre to discuss getting rid of the need for multicast dns on a mailing list that is bent on extending it.
I have nothing wrong with littleconf per se, but there seems to me a chicken and egg problem: how does one engage a device (presumably running a web-based UI) initially in order to administer it? Is that by address or by name? If by name, then how does it work?
The device just announces itself to a repository, and the repository serves up its name. No need to multicast each time you need to resolve a name, it just unicasts it or maybe anycasts it at boot time, perhaps on a renewal timer. If the rfc's that Brian's note references are applicable, so much the better. Mike _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
