Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices
"Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com> Fri, 21 November 2014 12:55 UTC
Return-Path: <jaehoon.paul@gmail.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486AB1A0363 for <dnssd@ietfa.amsl.com>; Fri, 21 Nov 2014 04:55:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPTvMShhQ9zq for <dnssd@ietfa.amsl.com>; Fri, 21 Nov 2014 04:55:39 -0800 (PST)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF881A0164 for <dnssd@ietf.org>; Fri, 21 Nov 2014 04:55:39 -0800 (PST)
Received: by mail-ie0-f178.google.com with SMTP id tp5so4680821ieb.23 for <dnssd@ietf.org>; Fri, 21 Nov 2014 04:55:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qpjh//vQJfs2uEJ9Cnyzwsajl6bKifeXuomJrzS0NFI=; b=OFknLoo7N02N+ORGIipz3O/q2AAEhNsStFdqB9x0ydZCeWrR0KMXqBcIi4qNW8ZvyP zIWMbBvoAEAI88j4niuwaNoc1bxas6Pe6E3Yu5w8N1g/8S1CEFJjTQUch48LjGoaa6m7 zhgMhuoJlqpk+oUCgNQlIcaa1XrB+4k+OqvEFrUqXCuCWFxxE40SaE9eh0l0X6z/Xtu/ FV6ZGKtFF2YCfzkbFfJMnzKtEZYZUkGDEm+9yjBl5TsmyfHhtN3q6PK9RU4WT5P8FEsz RUzrsDzvU+V1xAoyI3t8mPHxLpyxJyUngJro2XT98+oRd05O2MNk6T8LLMvnDbDQnzgB y7Hw==
MIME-Version: 1.0
X-Received: by 10.107.156.131 with SMTP id f125mr3768915ioe.15.1416574538348; Fri, 21 Nov 2014 04:55:38 -0800 (PST)
Received: by 10.64.57.12 with HTTP; Fri, 21 Nov 2014 04:55:38 -0800 (PST)
In-Reply-To: <12750388-E313-4364-8D42-9DF75C91D91C@istumbler.net>
References: <CAPK2DeyuABqSbH5dtdtScYWnE-vkmGO642xFb6FZehu-5MTaAA@mail.gmail.com> <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <CAPK2Deys6VU83R0hfv_8svNKuaSBEfu_dGqnGkoN_pQ9zE_6HQ@mail.gmail.com> <F61ADDF8-6BC1-4C9E-B80A-32F3EF186E3D@istumbler.net> <CAPK2DeyCToF6MwQOpnbW=tY+uU_iEsgOS0WSe1NYpxGq6kC+3Q@mail.gmail.com> <F158B437-8DAB-469E-B957-745CDBB3AB41@istumbler.net> <CAPK2DexC=YH_pjMnHw2ubsKe-4LqWm+BM10JwR_AxRm2k9Tudg@mail.gmail.com> <12750388-E313-4364-8D42-9DF75C91D91C@istumbler.net>
Date: Fri, 21 Nov 2014 21:55:38 +0900
Message-ID: <CAPK2DewfxsfEh1fJCfGbWjeU92Bu8VH1W7Os+wwyJ0U+86gxdQ@mail.gmail.com>
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
To: Alf Watt <alf@istumbler.net>
Content-Type: multipart/alternative; boundary="001a1140c8d828336605085df612"
Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/BKLand0k-wKsksj5ATscnwSZ1o8
Cc: Brian Haberman <brian@innovationslab.net>, Myung-Ki Shin <mkshin@etri.re.kr>, "dnssd@ietf.org" <dnssd@ietf.org>, Jung-Soo Park <pjs@etri.re.kr>, Ted Lemon <Ted.Lemon@nominum.com>, Sejun Lee <prosejun14@gmail.com>
Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Nov 2014 12:55:47 -0000
Alf, It seems like you didn't attend the last DNSSD WG session in Hawaii. Though my draft lacks explanation for DNS name registration into a DNS server, I did explain the presentation at the last DNSSD WG session with the following slides, especially slide 5: http://www.ietf.org/proceedings/91/slides/slides-91-dnssd-6.pdf >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 > Though there exists a similarity for the DNS name generation, the difference is that my scheme uses the device category and device model for the DNS name to let an IoT device be identified for its functionality without an explicit service discovery procedure. > - 5.2.3 the ‘collector’ is effectively an mDNS/DNS-SD browser which is limited to name records > Well, not exactly the same. The collector is either a router or host that uses Node Information protocol rather than mDNS. > - 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. > The method to find out the micro-location is out of scope in this scope. It is assumed that the micro-location information (e.g., refrigerator) for the macro-location information (e.g., kitchen) is available. The localization of the micro-location and macro-location is the current feasible research subject under the development of my research lab. We have a preliminary result based on simulation in an apartment. > - 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 Like the above answer, the micro or macro location can be autoconfigured by the smartphone in indoor environments, such as an apartment. Take a look at the slide 9 among the slides that were presented at Homenet WG in the last IETF meeting: http://www.ietf.org/proceedings/91/slides/slides-91-homenet-4.pdf > > - 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. > My draft does not prevent end-users from manually configuring DNS name for their IoT devices. As you know, an IPv6 interface of the IoT device can have more than a DNS name for the given, same IPv6 address. >- 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 > In my scheme, the device category and device type including vendor are included into a DNS name, these can be used to let users identify the available services when a database having the mapping the service information for the device category and device type (such as unicast-based DNS server at home) is available to the users. In my approach, a unicast-based DNS server is required with the mapping information of DNS names and IPv6 addresses of IoT devices rather than running individual mDNS per IoT device. >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: > In my approach, IoT devices need a generic IPv6 stack with handling additional ICMPv6 options, such as DAD for DNS name and Node Information Protocol rather than mDNS as application. We need to consider which approach is easy for the implementers. Paul >"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). > =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Fri, Nov 21, 2014 at 4:02 AM, Alf Watt <alf@istumbler.net> wrote: > 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 < > jaehoon.paul@gmail.com> 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: +82-31-299-4957 > > Mobile: +82-10-4758-1765 > > Fax: +82-31-290-5119 > > Email: pauljeong@skku.edu, jaehoon.paul@gmail.com > > 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 <alf@istumbler.net> 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 < > jaehoon.paul@gmail.com> 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: +82-31-299-4957 > >> Mobile: +82-10-4758-1765 > >> Fax: +82-31-290-5119 > >> Email: pauljeong@skku.edu, jaehoon.paul@gmail.com > >> 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 <alf@istumbler.net> 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 < > jaehoon.paul@gmail.com> 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. > >>> > >> > >> > > > > > >
- [dnssd] DNS Name Autoconfiguration for Home Netwo… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Ted Lemon
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Dave Thaler
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Alf Watt
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Ted Lemon
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Daniel Park
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Simpson, Robby (GE Energy Management)
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Tom Pusateri
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Alf Watt
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Stuart Cheshire
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Simpson, Robby (GE Energy Management)
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Simpson, Robby (GE Energy Management)
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Alf Watt
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Ted Lemon
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Guangqing Deng
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Simpson, Robby (GE Energy Management)
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Ted Lemon
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Mr. Jaehoon Paul Jeong
- Re: [dnssd] DNS Name Autoconfiguration for Home N… Ted Lemon