On 7/15/14, 1:53 PM, Ted Lemon wrote:
We can safely assume that any device that is monetized through the cloud will
do everything in its power to prevent us from accessing it, so that's really
not the interesting test case. The interesting test case is whether a
Nest-like device that isn't operated through the manufacturer's captive portal
will use this set of standard protocols. (I don't know what the policies
behind Nest are specifically, but the phenomenon I'm talking about is more the
rule than the exception in citizen-grade IoT devices at the moment).
I believe we are at least in the fortunate situation that nobody's tried
hard to do a naming
provider land grab yet, so there may yet be time to do the right thing.
Can we make this a *requirement*? If not, why not?
We can't force anybody to do anything, that's why not. But we can document a mechanism
for doing it, and if implementation becomes widespread in home gateways, it's not
unreasonable to think that devices that _don't_ depend on a captive portal for
monetization will use these protocols rather than reinventing the wheel. But bear in
mind that this is a fairly big "if."
I mean a requirement for the homenet working group, of course. I'm not
entirely sure what
the appetite is for wheel reinvention in this space is, but I'm guessing
it's not that high if
this working group comes up with something that is workable, and gives
CPE vendors something
to shoot for rather than a bunch of ad hoc point solutions requiring
bilateral dev agreements.
We should be really clear that "CPE" !== "Router" too. If the Nest wants
to be my DNS name
repository that gets mirrored out in Google's intrastructure somehow,
that should OK too.
I think its main requirement is that it:
a) doesn't move around out of my homenet
b) is always on
Mike
_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
