On 03/13/2013 11:20 AM, Tim Chown wrote:
I don't understand what mDNS has to do with service announcement to a
repository. mDNS is a way to find names in lieu of a repository (that is, each
device is it's own authoritative name service). Sending naming/service
announcements
to a repository is an adjunct of the repository protocols and has nothing to do
with mDNS that I can figure out.
Well, a device in a homenet today will commonly use both unicast and multicast
DNS, the former for internal devices, the latter for external.
I'm responding in particular to:
" For a service such as mDNS to coexist with an Internet name service, where the
homenet is preferably using a global domain name, it is desirable that the zeroconf
devices have a way to add their names to the global name space in use. One solution could
be for zeroconf protocols to be used to indicate global FQDNs, e.g. an mDNS service could
return a FQDN in a SRV record."
This just doesn't make any sense to me. mDNS is typically used to do an
A/AAAA lookup. And mDNS isn't global, so it wouldn't do me much good if
I were in Brazil. So I don't think this is a solution at all, and it definitely
doesn't seem to have anything to do with mDNS. To my mind, what would
be useful is for the device to populate a repository (zeroconf or not) via
an existing or tweaked DNS protocols (ixfr?).
Mike
More speculation about mDNS vs. SRV records without any motivation of what
is trying to be accomplished and why... it just sort of appears out of thin air
here.
So the important aspect is that devices can register themselves with a name
service that would typically be hosted on the CER (and secondaried elsewhere).
I think more thought needs to be given to adding names automatically to a
repository. It mentions that a user may choose to do so, but what if there's
no meaningful "user" such as my IP-speakers with no UI? Should it try or not?
(I think it ought, but that's me). More to the point: what are the implications
of things that don't have meaningful UI's.
To be defined. But noted.
There should be some more discussion of the differences between a locally
significant domain name, and a globally significant one. What happens
when people camp on names they don't own? How might that interact with
mobility?
Not sure what you mean here.
More speculation about dnydns without any motivation for why it's interesting
and/or significant.
There seems to be no mention of the relationship between local/home resolvers
if the local resolver isn't the authoritative resolver. In particular, it's not
an
unusual situation to have a "cloud" (read: high bandwidth, well connected...)
authoritative dns be a slave to a local master. Or if you don't like that, some
other way to achieve similar goals of not wanting my home network have to
know how to deal with ddos's on nameservers, as one for-instance.
I think that's not precluded. The key bit is the homenet must be able to
operate if disconnected.
3.7.5 Independent Operation
I'm generally skeptical that anything these days works well when you pull
the plug on the Internet. There are so many hidden assumptions about
connectivity that I don't think we should try to do anything heroic here.
Sure. It's a fair goal though.
3.7.6 Considerations for LLN's
First I'll say that it's not just LLN's that have problems with chatty networks:
it's anything with a battery. This should be rewritten from that perspective and
stay away from speculation about whether proxies are needed for a particular
technology that doesn't necessarily have consensus.
More to the point: this architecture should have considerations throughout about
battery driven devices and their considerations, and not just whether mdns will
cause daily trips to the store to buy new batteries.
One for Anders to comment on, perhaps...
3.7.7 DNS resolver discovery
I don't understand this section: is there anything we need to do beyond what
SLAAC and/or DHCP do now? If there is, it might be nice to enumerate what
the problem is.
This came up from Jari's own experiments. It implies stateless DHCP is
available, or that the resolver address(es) are propagated by some other means.
---
Overall, section 3.7 leaves me more confused than enlightened. It reads more
like a stream of consciousness than an architecture.
For the reason Ted has observed. I agree it needs to be tighter, preferably.
tim
Mike
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
