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

"Mr. Jaehoon Paul Jeong" <> Thu, 05 November 2015 07:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1867B1B3B40; Wed, 4 Nov 2015 23:14:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.499
X-Spam-Status: No, score=-1.499 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, URI_NOVOWEL=0.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yV93WYUCoidX; Wed, 4 Nov 2015 23:14:51 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 46AC01B3B39; Wed, 4 Nov 2015 23:14:51 -0800 (PST)
Received: by ykek133 with SMTP id k133so116569423yke.2; Wed, 04 Nov 2015 23:14:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kE8m8fxsEmUkmmY8aaKKY+QTbhDGMy84P/1wweoFIAI=; b=gi7WlXPZpOteYxJLUMR5A2B/azl5C+I4eu53ZFFiOvXEeAKIqFsiQWDtfTGrSKmlrx AGyy5uNVPRL0AWaFEXM4ZCfbm1aEkGZs11Dnvz9nN4Wi+p0HYHzt3qvcn5hBqBd8VyvJ VYQKc6ND4k1XmdoCGqJKnH8yF6QMiaAJZCKtJtFPQSMaYB0u9iwGwNJU1YBXKRcJNcow LGMuXOl6omesSSBHx7BvMHSdtRYJJVJzL0Knf2VpBdmFIk0ofd+Q5mmJmsfOjCYycWW9 fN5yZiYNDx0xw5html+4WSEl3mIOXof7kj1yFHuMbYl94YjDnSRZtJCI8a1EJv9YJ2NX Vxwg==
MIME-Version: 1.0
X-Received: by with SMTP id j4mr3459011ywf.129.1446707690606; Wed, 04 Nov 2015 23:14:50 -0800 (PST)
Received: by with HTTP; Wed, 4 Nov 2015 23:14:50 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Thu, 05 Nov 2015 16:14:50 +0900
Message-ID: <>
From: "Mr. Jaehoon Paul Jeong" <>
To: Stuart Cheshire <>
Content-Type: multipart/alternative; boundary="94eb2c0826e8fe18590523c5e164"
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: Thu, 05 Nov 2015 07:14:54 -0000

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

On Thu, Nov 5, 2015 at 2:51 PM, Stuart Cheshire <> wrote:

> On 3 Nov 2015, at 01:51, Mr. Jaehoon Paul Jeong <>
> wrote:
> > 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
> >
> 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 (
>,,, will
> allow your tablet to create global records in that domain. Clearly this is
> nonsense.
>    >> 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
        (28 cu. ft. French Door Refrigerator Stainless Steel), we can know
the functions with the specification.
        See Samsung's refrigerators:

Having put global address records into, your document assumes
> then assumes that 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 Clearly this is nonsense too.
   >> In Section 7 (DNS Name Management for Mobile IoT Devices),,
        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

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

> 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.”
   >> Me too :-)



> Stuart Cheshire

Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software
Sungkyunkwan University
Office: +82-31-299-4957
Personal Homepage: