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

"Mr. Jaehoon Paul Jeong" <> Wed, 11 November 2015 01:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DE1F91B4522; Tue, 10 Nov 2015 17:14:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nHqnuasqVMwd; Tue, 10 Nov 2015 17:14:54 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D66D81B4520; Tue, 10 Nov 2015 17:14:53 -0800 (PST)
Received: by ykdv3 with SMTP id v3so26444163ykd.0; Tue, 10 Nov 2015 17:14:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=m3Ww7tAbb6DrANVxvnHeA0dYfNxWAkIxvPmbEUOxp8s=; b=xKDpE9HbVcyaBXHFxuo4b8YkR8wfXU/BGmEYdq4xX75BCIy/PqXO0BUIGJVNgv2JJy iLxicniu66EPCmJfytsvSd9jUspY8JQRzawNqKFOrTn7EVbSPReGjKVNNaOOF6SzqLnC 2BzaNJ1iiJkkaFcGJqDnuv6Cew2ZE47rn4AHHyNHkpNvb31pcpDG4xsMZKTh0PAZ9gER nTtDFs5IfgxUk1lm/EYJCRhUv6x8YPjgJN4fWixN+FhvS9QzdTGfLdUc6ym4WlsV+h1j E4buCRj1m6bGVAvfdlAxT36jnsJzrm8Oe9ddvEWObZ6n985V1gwh92G63hWG816GmBNu EKyw==
X-Received: by with SMTP id l184mr6162409ywf.342.1447204492938; Tue, 10 Nov 2015 17:14:52 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 10 Nov 2015 17:14:23 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: "Mr. Jaehoon Paul Jeong" <>
Date: Wed, 11 Nov 2015 10:14:23 +0900
Message-ID: <>
To: Stuart Cheshire <>
Content-Type: multipart/mixed; boundary="94eb2c07e590b885c70524398d5b"
Archived-At: <>
Cc: Brian Haberman <>, IETF IPv6 Mailing List <>, Hyunjong Jeon <>, Myung-Ki Shin <>,, Jung-Soo Park <>, Kyemyung Jung <>,, Sejun Lee <>
Subject: Re: [DNSOP] Request for Comments on I-D about IoT DNS Name Autoconf
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Nov 2015 01:14:58 -0000

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

On Tue, Nov 10, 2015 at 5:24 AM, Stuart Cheshire <> wrote:

> On 4 Nov 2015, at 23:14, Mr. Jaehoon Paul Jeong <>
> 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:
> 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

        For the location privacy for IoT devices (e.g., medical devices and
        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

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

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

        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