Subject: Request for Comments on I-D about IoT DNS Name Autoconf

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 3 Nov 2015 18:51:56 +0900

Hi 6man, 6lo and dnsop folks,

There will be a talk about IoT DNS Name Autoconfiguration
in 6man WG's morning session tomorrow, 11/4/2015.

Title: DNS Name Autoconfiguration for Internet of Things Devices
https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00

I hope we discuss how to configure the DNS names of IoT devices in
networks,
such as home network, enterprise network, road network, and factory network
with the minimum configuration effort.

Imagining that you have hundreds of IoT devices in your network,
will you configure their DNS names manually one by one?

To prepare for the new wave of IoT networks based on IPv6,
we need to think of the DNS naming and auto-registration into DNS for IoT
devices.

We (SKKU and Jubix) implemented a prototype for a smart grid with electric
meters
Korea Electric Power Corporation (KEPCO) that is the main power delivery
company in South Korea.
Our meters are running on IPv6/6lo/Wi-SUN (IEEE 802.15.4g).

Since I have 5 minutes for the presentation tomorrow, I will shortly
introduce the motivation,
the DNS name format based on the ITU-T/ISO object identifier, and our
protocol.

Please read my draft and slides in the 6man agenda link:
https://datatracker.ietf.org/meeting/94/agenda.html

The slides has the backup slides (as Appendix slides) that explain
the implementation and demonstration, and also the comparison with mDNS.

Thanks for reading this email.

Best Regards,
Paul
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Email: [email-masked], [email-masked]
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php

---

From: Stuart Cheshire <[email-masked]>
Date: Wed, 04 Nov 2015 21:51:13 -0800

> https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00

This was not actually discussed in 6man, 6lo, or dnsop, so I’ll make some comments here.

It’s hard to know where to start.

Your document confuses device discovery with service discovery. What a device *is* tells you virtually nothing about what it *does*. The “device category” of my computer being “laptop” or “tablet” tells you *nothing* about what services it offers.

Your document assumes that every search domain your tablet encounters (starbucks.com, narita-airport.co.jp, meeting.ietf.org, comcast.com) will allow your tablet to create global records in that domain. Clearly this is nonsense.

Having put global address records into starbucks.com, your document assumes then assumes that starbucks.com will then allow you do to a zone transfer to fetch the entire zone to discover the names of all the other address records in starbucks.com. Clearly this is nonsense too.

Your document proposes global address records with names with this form:

unique_id.device_model.device_category.mic_loc.mac_loc.domain_name.

For example:

jkadjkhdsafhjlsadfjklkljdgajknsadf.Sungkyunkwan-1234.cleaning-robot.right-upper-corner.living-room.comcast.com.

The host name of the cleaning robot keeps changing as it moves around the room, requiring continual updates and continual zone transfers to keep track of the name as it changes. Clearly this is infeasible.

I would, however, love to get one of these new flying cleaning robots, which can be located (as it was in your example), “in the right-upper corner of a living room.”

Stuart Cheshire

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 5 Nov 2015 16:02:58 +0900

Dear Stuart,
Thanks for your constructive comments below.

I answer your comments in lines.

On Thu, Nov 5, 2015 at 2:51 PM, Stuart Cheshire <[email-masked]> wrote:

> Your document confuses device discovery with service discovery. What a
> device *is* tells you virtually nothing about what it *does*. The “device
> category” of my computer being “laptop” or “tablet” tells you *nothing*
> about what services it offers.
>
   >> Device model (denoted as device_model) in my proposed DNS name format
can let an IoT device refer to
        the specification of another device's functions, assuming that such
the device model's specification is available
        publicly. Of course, we can use service discovery for device
functions, such as dnssd.
        This is the next step in my draft.
        For example, for a given Samsung's refrigerator model, such as
RF4287HARS
        (28 cu. ft. French Door Refrigerator Stainless Steel), we can know
the functions with the specification.
        See Samsung's refrigerators:
http://www.samsung.com/us/support/appliances/refrigerators

>
> Your document assumes that every search domain your tablet encounters (
> starbucks.com, narita-airport.co.jp, meeting.ietf.org, comcast.com) will
> allow your tablet to create global records in that domain. Clearly this is
> nonsense.
>
   >> In Section 7 (DNS Name Management for Mobile IoT Devices),

https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00#section-7,
        I discuss the mobility issue of an IoT device to receive multiple
search domains.
        Whenever the IoT device recognizes the movement into another
subnet, it can delete its DNS names
        by DNS dynamic update.
        In reality, in public areas (e.g., starbucks and narita airport),
we can disable the automatic DNS name registration
in routers
        because the registration in the public areas makes some privacy
issues.
        We can enable such automatic

>
> Having put global address records into starbucks.com, your document
> assumes then assumes that starbucks.com will then allow you do to a zone
> transfer to fetch the entire zone to discover the names of all the other
> address records in starbucks.com. Clearly this is nonsense too.
>
> The host name of the cleaning robot keeps changing as it moves around the
> room, requiring continual updates and continual zone transfers to keep
> track of the name as it changes. Clearly this is infeasible.
>
> I would, however, love to get one of these new flying cleaning robots,
> which can be located (as it was in your example), “in the right-upper
> corner of a living room.”
>
> Stuart Cheshire
>
>

--

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 5 Nov 2015 16:14:50 +0900

Stuart,
by mistake, my incomplete email was sent.
Here is the complete email.

On Thu, Nov 5, 2015 at 2:51 PM, Stuart Cheshire <[email-masked]> wrote:

>    >> Device model (denoted as device_model) in my proposed DNS name
format can let an IoT device refer to
        the specification of another device's functions, assuming that such
a device model's specification is available
        publicly. Of course, we can use service discovery for device
functions through dnssd.
        This service discovery is the next step in my draft.
        For example, for a given Samsung's refrigerator model, such as
RF4287HARS
        (28 cu. ft. French Door Refrigerator Stainless Steel), we can know
the functions with the specification.
        See Samsung's refrigerators:
http://www.samsung.com/us/support/appliances/refrigerators

Having put global address records into starbucks.com, your document assumes
> then assumes that starbucks.com will then allow you do to a zone transfer
> to fetch the entire zone to discover the names of all the other address
> records in starbucks.com. Clearly this is nonsense too.
>

https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00#section-7,
        I discuss the mobility issue of an IoT device to receive multiple
search domains.
        Whenever the IoT device recognizes the movement into another
subnet, it can delete its DNS names
        by DNS dynamic update.
        In reality, in public areas (e.g., starbucks and narita airport),
we can disable the automatic DNS name
        registration in routers because the registration in the public
areas makes some privacy issues.
        We can enable such automatic registration in our managed networks,
such as home network, office network,
        smart grid, and factory network.
        Thus, we can prevent your concern for global DNS names from
happening.

   >> To prevent the frequent update of a mobile IoT device's DNS name, the
IoT device can update its DNS name
        in a reasonable time interval. This is a further discussion issue.
        My point is that the physical location in the DNS name can help
users easily track the position of an IoT device.

   >> Me too :-)

    Thanks.

    Paul

---

From: Stuart Cheshire <[email-masked]>
Date: Mon, 09 Nov 2015 12:24:35 -0800

On 4 Nov 2015, at 23:14, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:

> Device model (denoted as device_model) in my proposed DNS
> name format can let an IoT device refer to the specification
> of another device's functions, assuming that such a
> device model's specification is available publicly.
> 
> For example, for a given Samsung's refrigerator model, such
> as RF4287HARS (28 cu. ft. French Door Refrigerator Stainless
> Steel), we can know the functions with the specification.

Mr Jeong,

Over the last year you have asked the IETF community for feedback on your document on several occasions. Various people have provided feedback, yet your document never changes. You just argue that all the feedback is wrong, and persist with your original proposal. I’m not sure what will be achieved by repeatedly asking for feedback on the same unwavering idea.

You suggest above that the software running on a constrained IoT device should visit the web page you gave, explore the web site to find some document specifying the network functionality provided by the refrigerator model, and the network protocol(s) used to access that functionality (I, as a human, was unable to find that document myself) and then (presumably via some artificial intelligence algorithms) the constrained IoT device would write itself a protocol implementation (and design itself a corresponding user interface) to control the refrigerator. I don’t believe that IoT devices with such artificial intelligence capabilities currently exist outside of Hollywood movies.

In your slides you focus on the example of interfacing to a smart meter over the network (pictured below). But products that do that have been available for a while. I already have one in my house, provided at no charge to me by my local electricity company. This is not some new experimental thing; it’s a mainstream, widely-used product:

<http://www.amazon.com/Rainforest-EAGLE-Ethernet-ZigBee-Gateway/dp/B00AII248U>

When a type of product is readily available for purchase, with a variety of different models from a variety of different vendors, it’s retail, not research.

I believe you could make a much larger contribution by doing something new which builds on the foundation provided by RFC 6762 and RFC 6763, rather than just doing the same thing a different way.

Stuart Cheshire

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 11 Nov 2015 10:14:23 +0900

Dear Mr. Cheshire,
Thanks for your frank thoughts and opinions.

On Tue, Nov 10, 2015 at 5:24 AM, Stuart Cheshire <[email-masked]> wrote:

> Over the last year you have asked the IETF community for feedback on your
> document on several occasions. Various people have provided feedback, yet
> your document never changes. You just argue that all the feedback is wrong,
> and persist with your original proposal. I’m not sure what will be achieved
> by repeatedly asking for feedback on the same unwavering idea.
>

   >> Generally speaking, I tried to address useful comments on the
revisions as long as I understand,
        such as location privacy for medical devices and a DNS name format.
        Refer to the recent draft
https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00.

        For the location privacy for IoT devices (e.g., medical devices and
smartphone),
        in Section 8, the location of smartphone can be encrypted by a
shared key or public/privacy keys.
        The device category or model can be encrypted based on my proposed
scheme.

        For the DNS name format, though this version does not have the new
format based on Object ID,
        this new name format is proposed in the slide 3 in my presentation
slides (https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00)
        is proposed. The slides is attached in this email.

        This new format is based on the standard format of ITU-T and
ISO/IEC for an object, such as IoT device.
        On the next version of my draft, I will reflect this change.

        In this version, the following are the new proposed ones:
        - The global DNS name autoconfiguration as well as the local DNS
name autoconfiguration
          (See Section 5.2.2. DNS Name Collection)

        - The DNS name management for the mobility of IoT devices
          (See Section 7. DNS Name Management for Mobile IoT Devices)

       I discussed with 6lo folks, IoT software engineers, and IoT experts
for my proposed schemes.
       They think that though my proposed one is a simple implementation
extension based on IPv6 ND and NI protocol,
       it is efficient in multi-link network in terms of DNS packet number
and energy consumption because my resolution is based on
       unicast rather than the multicast of mDNS.

       My team at SKKU and Jubix (a startup company in Korea) are working
for simulation and implementation to compare
       the overhead of mDNS and my proposed one (called DNSNA) in terms of
DNS packet number and energy consumption
       in wireless networks (e.g., 6lo networks).

       We have a plan to show the comparison in the next IETF 95 meeting.

> You suggest above that the software running on a constrained IoT device
> should visit the web page you gave, explore the web site
>
to find some document specifying the network functionality provided by the
> refrigerator model, and the network protocol(s) used to access
>
that functionality (I, as a human, was unable to find that document myself)
> and then (presumably via some artificial intelligence algorithms)
>
the constrained IoT device would write itself a protocol implementation
> (and design itself a corresponding user interface) to control the
> refrigerator.
>
I don’t believe that IoT devices with such artificial intelligence
> capabilities currently exist outside of Hollywood movies.
>

   >> The service discovery, which gets information (e.g., services and
functions) from other devices,  is out of scope in our current work.
        Our goal in this draft is to provide a simple DNS name generation
and registration without any intervention of administrators and users.

>
> In your slides you focus on the example of interfacing to a smart meter
> over the network (pictured below). But products that do that have been
>
available for a while. I already have one in my house, provided at no
> charge to me by my local electricity company.
>
This is not some new experimental thing; it’s a mainstream, widely-used
> product:

> <
> http://www.amazon.com/Rainforest-EAGLE-Ethernet-ZigBee-Gateway/dp/B00AII248U
> >
>
> When a type of product is readily available for purchase, with a variety
> of different models from a variety of different vendors, it’s retail, not
> research.
>
>    >> The smart grid for KEPCO (Korea Electric Power Corporation) is an
example for DNSNA.
        In addition to such a smart grid, other IoT devices including
wearable devices will be configured with their DNS names without running
mDNS.

        My folk in IoT industry said that their device can run only part of
IPv6 core specification because of the device's constrained capability.
        So he said that DNSNA is preferred over mDNS.
        mDNS is good enough for high capability devices (e.g., computers,
smartphones, and appliances) and high-bandwidth networks (e.g., WiFi),
        but for constrained IoT devices, which are reluctant to using
multicast, DNSNA may be a solution.

> I believe you could make a much larger contribution by doing something new
> which builds on the foundation provided by RFC 6762 and RFC 6763,
>
rather than just doing the same thing a different way.

   >> I don't say that my DNSNA is the only solution for IoT devices, but
would say that we IETF need to consider a light-weight DNS naming for
        IoT devices in order to deploy IPv6 in the IoT world.
        mDNS may be modified for the IoT world, so I will also consider how
to extend mDNS for this new world along with DNSNA.

        Thanks for your comments again.

        Best Regards,
        Mr. Jaehoon Paul Jeong