Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices

[Alf Watt <[e-mail]>]

Paul,

Thank you for responding. I took the time to read through your proposal and have the following suggestions:

- carefully consider the extent to which your proposal duplicates existing work, in particular:

	- 5.2.1. and 5.2.2. very closely resemble the current behavior of mDNS nodes choosing names

	- 5.2.3 the ‘collector’ is effectively an mDNS/DNS-SD browser which is limited to name records

	- Note well that mDNS/DNS-SD specifications carefully describe the desirable caching behavior
		for multiple ‘collectors’ on a multicast link, which significantly improves performance

- carefully consider the existing uses for the DNS name label for an internet host:

	- 6 - 6.2 while the concept of nested location for IoT devices is interesting, overloading the existing
		name parameter to convey this information does not seem like an appropriate tradeoff.

	- 6 - 6.2 it is also unclear how a device would be able to locate itself in a particular micro or macro location
		and therefore generate an appropriate name for itself, without user configuration

	- the ‘name’ of any object, networked or not, is generally the choice of the owner. In some cultures ‘naming’
		is synonymous with taking ownership. Taking away the end-users ability to name their IoT objects may
		result in poor usability, and potentially cause confusion with existing applications or network devices 
		which do not implement the proposed naming scheme.

- while naming is important, a device only needs to be discoverable and visible to users if some service is to be accessed:
	- your proposal covers only half of the solution currently provided by mDNS/DNS-SD: local naming AND service discovery
	- applications connect to services, not hosts; if a host offers no services then it does not need to be visible in a browser
	- most network users have little interest in discovery for the sake of discovery, they are interested in services

I suspect, that if you took the time to implement your proposal, you would quickly realize that the existing mDNS and DNS-SD standards aren't so much ‘overkill’ as the minimum set of features and optimizations which are required to efficiently implement the user experience your document calls for:

"This DNS name lets home residents easily identify each device for monitoring and remote-controlling it in a home network.”

Re-reading your proposal, no feature in it is not already possible using mDNS/DNS-SD, perhaps paired with new record types (ULOC, MLOC, or e.g. to represent the micro and macro location parameters, distinct from the existing LOC record), or existing ones (make, model and etc. could for e.g. be added to TXT records).
	


> On Nov 18, 2014, at 6:49 PM, Mr. Jaehoon Paul Jeong <[e-mail]> wrote:
> 
> Alf,
> Thanks for your kind survey information.
> 
> It seems that the devices mentioned above will be able to run mDNS.
> My point is to allow IoT device vendors to have an alternative way for a simple DNS naming 
> that is based on IPv6 stateless autoconfiguration.
> 
> For the case where only the mapping between an IoT device's DNS name and its IPv6 is required,
> mDNS seems like an overkill.
> 
> Paul
> 
> 
> ===========================
> Mr. Jaehoon (Paul) Jeong, Ph.D.
> Assistant Professor
> Department of Software /
> Department of Computer Engineering
> Sungkyunkwan University
> Office: [phone]
> Mobile: [phone]
> Fax: [phone]
> Email: [e-mail], [e-mail]
> CPS Lab Website: http://cpslab.skku.edu
> Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php
> 
> On Wed, Nov 19, 2014 at 3:46 AM, Alf Watt <[e-mail]> wrote:
> The proposal may have merit for other reasons but in terms of resource usage for IoT devices it’s very instructive to look at existing products.
> 
> The Phillips Hue lights are built around a 32 ARM core [1] with limited RAM (128kb). The Nest Protect smoke detector is also built around a similar 32bit ARM core from Freescale, the K60[2].
> 
> Both of these are attached to a Zigbee radio, which provides sufficient bandwidth for DNS-SD over mDNS, as per our charter[3].
> 
> Devices which need service discovery on batteries will very likely be using layer-2 discovery mechanisms for power consumption reasons (i.e. BT-LE). 
> 
> I have a hard time imagining that a device with much less capabilities than above will be a useful internet node. If it can't afford to run a simple discovery service then what is it doing on the network?
> 
> Best,
> Alf
> 
> [1] http://www.digchip.com/datasheets/parts/datasheet/456/STM32F217VET6.php
> "ARM-based 32-bit MCU, MB Flash/128+4KB RAM, crypto, USB OTG HS/FS, Ethernet, 17 TIMs, 3 ADCs, 15 	comm. interfaces & camera"
> [2] http://cache.freescale.com/files/32bit/doc/data_sheet/K60P100M100SF2V2.pdf?fpsp=1&WT_TYPE=Data%20Sheets&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation
> [3] http://datatracker.ietf.org/wg/dnssd/charter/
> 
>> On Nov 14, 2014, at 10:34 PM, Mr. Jaehoon Paul Jeong <[e-mail]> wrote:
>> 
>> Alf,
>> For embedded such as printers, cameras that have power and capacity equivalent to smartphone,
>> you are right.
>> 
>> For low-power low-capacity devices, such as light bulb and smoke detecting sensor,
>> I think that running server(s) seems not viable 
>> even though I have no exact number of target memory and cpu size 
>> for such low-power low-capacity IoT devices.
>> 
>> Is there anyone else to comment on the hardware specification of such IoT devices?
>> 
>> Thanks.
>> 
>> Paul  
>> 
>> ===========================
>> Mr. Jaehoon (Paul) Jeong, Ph.D.
>> Assistant Professor
>> Department of Software /
>> Department of Computer Engineering
>> Sungkyunkwan University
>> Office: [phone]
>> Mobile: [phone]
>> Fax: [phone]
>> Email: [e-mail], [e-mail]
>> CPS Lab Website: http://cpslab.skku.edu
>> Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php
>> 
>> On Fri, Nov 14, 2014 at 12:02 PM, Alf Watt <[e-mail]> wrote:
>> I’m confused, the mDNSResponder code is very lightweight and already runs on embedded devices such as printers, cameras and may other low-memory and low-cpu devices.
>> 
>> What is your target memory and cpu size for an IoT device? Given that we’ve been using mDNS for more than a decade, the steady pace of improvement in semiconductors means that even the smallest device will have more than sufficient resources for mMDS.
>> 
>> Best,
>> Alf
>> 
>>> On Nov 14, 2014, at 1:34 PM, Mr. Jaehoon Paul Jeong <[e-mail]> wrote:
>>> 
>>> The solution in RFC 6762 (Multicast DNS) section 9 is viable for regular computers, 
>>> such as laptop, desktop, and smartphone that can afford to run mDNS responder.
>>> For IoT devices, such as light bulb and fire detecting sensor, that have limited memory and storage,
>>> mDNS seems not viable for the DNS naming for them.
>>> 
>> 
>> 
> 
>