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

Michael Thomas <> Tue, 15 July 2014 21:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BD8611B2920 for <>; Tue, 15 Jul 2014 14:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.753
X-Spam-Status: No, score=-1.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 81_3wi0AshWG for <>; Tue, 15 Jul 2014 14:12:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D3741A007C for <>; Tue, 15 Jul 2014 14:12:09 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.14.7/8.14.7) with ESMTP id s6FLC8p0017091 for <>; Tue, 15 Jul 2014 14:12:08 -0700
Message-ID: <>
Date: Tue, 15 Jul 2014 14:12:06 -0700
From: Michael Thomas <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <53C58350.3020006@mt> <> <> <> < > <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [homenet] New version draft-mglt-homenet-naming-architecture-dhc-options-02.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Jul 2014 21:12:09 -0000

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