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

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

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: [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 21, 2014 at 4:02 AM, Alf Watt <[e-mail]> 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 <
> [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.
> >>>
> >>
> >>
> >
> >
>
>