Subject: [homenet] last call comments on section 3.7

From: Michael Thomas <[email-masked]>
Date: Thu, 28 Feb 2013 14:09:38 -0800

In general, I do not think this is ready to go. From what I can see, there is
a significant amount of disagreement about whether mdns and/or sd have a
place in the homenet architecture, and more than a little bit of groping
around as to what the problems are that need to be solved. This section is
both prescriptive in ways it ought not be, and speculative in ways that an
architecture document shouldn't be doing. I personally think that enumerating
requirements for what any solution ought to solve for is way more important,
but is sadly lacking in this section.

I think there is an unanswered question in this wg as to whether
naming should take a posture of how to integrate local naming into a wider
global scope, or figuring out how to adapt globally scoped naming into a
local context. In practical terms: whether we start with mdns and .local
and figure out how to hack it, or do we start with DNS and figure out how
to make it work against requirements. I will again say that the lack of
well agreed requirements for what we're doing hinders resolving this
question.

3.7.1 Service Discovery

This section starts out with telling us how it will be presented to the user (GUI)
without any reference to why a user or anything else needs service discovery.
As service discovery is not common on the internet today, I think this requires
a lot more motivation/requirements before jumping and telling us that out of
scope GUI's will come to the rescue -- it's not even clear that machine-machine
interfaces to find and configure, say, my IP speakers to my IP home entertainment
system won't be the norm.

Bottom line: remove the "how" and get immediately to the "why". Then we
can have a discussion.

3.7.2 Assigning Names

I think this can be easily rewritten to not need any informative references to yet
to be approved drafts that are not agreed upon.

3.7.3 Namespaces

It's not clear to me why a single namespace is "desirable". Do rebellious teenagers
really want to be part of their fuddy-duddy parent's namespace? Does it even
matter, architecturally? At least some motivation would be helpful. Part of my
uncomfort here is that there is a hidden assumption that a "home" is an indivisible
unit. Is that really true?

I'm not sure why ISP provided naming should be considered the default: we really
don't know what will be the case, and obviously ISP's have a big downside both
from changing ISP's, as well as the multiple-ISP's standpoint. I think that we can more
safely say that this service is just some "cloud" service provided somewhere on the
net since there isn't any locality requirement that I'm aware of.

This section dwells in solution space far more than I think it ought, and is highly
speculative (eg, .sitelocal, ulqdn, etc). Instead of speculating, it would be better
to say what characteristics we want, and what requirements we need to fulfill.

3.7.4 Homenet name service

Somewhere in this document we really need to make clear how mobility figures into
all of this. That is, what happens when things move around and what the implications
are for naming, both in my home, and on yours.

I don't think we should compare and contrast mdns as being "zeroconf" with
the implication that DNS is not. You can achieve "zeroconf" using service
announcement and not require multicast at all (at least not to announce the
service). In fact, until we have something resembling rough consensus, I don't
really think it's appropriate to favor one or the other in this document.

Again, ditch the references to ISP with something "cloud-like".

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.

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.

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.

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?

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.

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.

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.

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.
---
Overall, section 3.7 leaves me more confused than enlightened. It reads more
like a stream of consciousness than an architecture.

Mike