Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt

[Michael Thomas <[e-mail]>]

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