> On 01/09/2015 01:06, Mark Andrews wrote:
>>
>> Why is topology being forced into the naming? DNS is independent
>> of topology. We have *a* home. I really don't care what link my
>> printer is connected too. It is not something I want to see in its
>> name unless I put it there.
>
> No-hat:
>
> I'm very much with MarkA on this one.
>
> I want my devices to have a persistent name identifier, regardless of
> which part of the topology they happen to be plugged into at the time.
>
> I wouldn't mind if the "canonical" identifier happens to be topology
> dependent, so long as there's some mechanism (e.g. CNAME) to
> automatically map the persistent identifier to the topology-dependent one.
Please consider the following thoughts in no particular:
* In each "zone" collisions need to be handled gracefully.
** Also: there can be legitimate reasons for having devices with the same
(per-link) name in different parts of your network and if you
do service-discovery it can even be useful to know where the
device you found is located / what it is connected to (e.g.
printer.ethernet.office.home vs. printer.wifi.children.home)
* We currently have 2 sources of names from devices: MDNS and DHCP(v6),
it is complicated to extend them from their natural per-link to a multi-
link scope.
** MDNS does conflict resolution per link, extending it to multiple ones
is problematic (c.f.
draft-ietf-homenet-hybrid-proxy-zeroconf-00#appendix-C)
** Implementing multi-link hostname conflict resolution in DHCP(v6) servers
sounds
very painful (besides there are enough people already that don't even
want
to have stateful DHCPv6 by default).
* Having full-blown DNS-servers supporting zone transfers etc., on each and
every
router puts a huge additional burden on implementers, personally I don't
see having a bind9 or similar on every router as very realistic or
desirable.
For some schemes a single one per network might but enough, but that
would put
the burden on the user to know, care and buy / install the "one".
* As noted by someone else in this thread, (most) users don't know about or
actively
use hostnames, so indiscriminately publishing all of them in a
top-level zone
and syncing them across the network might not be worth it.
** Many auto-generated hostnames are very opaque (e.g. foobar-a18cb3) and
without
additional service discovery information are relatively useless to a
user,
in presence of service discovery information though the names become
less
relevant.
** All that said, HNCP is already suitable to publish top-level hostnames under
.home,
for a selected set of devices.
Resolutions for some or all of these issues are of course welcome.
Cheers,
Steven
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
