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

Michael Thomas <> Wed, 16 July 2014 00:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C8F7E1B27B5 for <>; Tue, 15 Jul 2014 17:48:28 -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 ppiFYEgzy3Ya for <>; Tue, 15 Jul 2014 17:48:23 -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 7244E1B27AA for <>; Tue, 15 Jul 2014 17:48:16 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.14.7/8.14.7) with ESMTP id s6G0kZgt000990; Tue, 15 Jul 2014 17:46:48 -0700
Message-ID: <>
Date: Tue, 15 Jul 2014 17:46:35 -0700
From: Michael Thomas <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Ted Lemon <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <53C58350.3020006@mt> <> <> <> < > <> <53C59926.9020704> <>
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: Wed, 16 Jul 2014 00:48:28 -0000

On 07/15/2014 04:42 PM, Ted Lemon wrote:
> On Jul 15, 2014, at 5:12 PM, Michael Thomas <>; wrote:
>> 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.
> That's not the point.   If you look at most of the consumer-grade IoT devices that have been announced recently, they all keep the data on their portal and do not allow you to use the device without sending them your data, so chances are the device is going to just talk to their portal using a proprietary scheme and ignore what we want.   Which is fine; my point is not that they are evil, but just that the use case for this may not be quite as broad as we imagine.   I still think it's worth doing, and I hope that over time this stuff moves in the direction of more flexibility.   What we do in homenet can easily either make that easy or make it hard, so we should try to make it easy.

Oh, ok. But this entire area is going to be pretty darn tricksey to get 
right, and we can have some hope
that after enough proprietary we-need-to-get-something-done from 
vendors, they'll be somewhat relieved
to have exactly One something that's standardized to support. I've seen 
this many times at $routervendor,
even when they have their own business model in mind. So we shouldn't be 
too fatalistic... the game is still
young on this account.