Re: [DNSOP] Request for Comments on I-D about IoT DNS Name Autoconf

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

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

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

> On 4 Nov 2015, at 23:14, Mr. Jaehoon Paul Jeong <[e-mail]>
> 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.
> See Samsung's refrigerators:
> http://www.samsung.com/us/support/appliances/refrigerators
>
>
> 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.
>

   >> 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



>
> Stuart Cheshire
>
>
>