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

"Simpson, Robby (GE Energy Management)" <> Mon, 24 November 2014 16:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 078031A8710 for <>; Mon, 24 Nov 2014 08:33:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.266
X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AYKn-q06qwnL for <>; Mon, 24 Nov 2014 08:33:18 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 393BA1A711A for <>; Mon, 24 Nov 2014 08:33:04 -0800 (PST)
Received: from pps.filterd ( []) by (8.14.7/8.14.7) with SMTP id sAOG7MNB043884 for <>; Mon, 24 Nov 2014 11:33:03 -0500
Received: from ([]) by with ESMTP id 1qv6btg332-9 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <>; Mon, 24 Nov 2014 11:33:03 -0500
Received: from unknown (HELO ([]) by with ESMTP/TLS/AES128-SHA; 24 Nov 2014 11:24:41 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Mon, 24 Nov 2014 11:32:48 -0500
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 24 Nov 2014 11:32:48 -0500
From: "Simpson, Robby (GE Energy Management)" <>
To: Guangqing Deng <>, "Mr. Jaehoon Paul Jeong" <>
Thread-Topic: [dnssd] DNS Name Autoconfiguration for Home Network Devices
Date: Mon, 24 Nov 2014 16:32:47 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.28, 0.0.0000 definitions=2014-11-24_02:2014-11-24,2014-11-24,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411240132
Cc: "" <>
Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 24 Nov 2014 16:33:28 -0000

When discussing constrained devices (which I think is the intent here), I find the definitions from RFC 7228 ( convenient.

- Robby

From: Guangqing Deng <<>>
Date: Monday, November 24, 2014 at 11:26 AM
To: "Mr. Jaehoon Paul Jeong" <<>>
Cc: "<>" <<>>
Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices

The term of "IoT device" is mentioned many times here and in the draft, and it seems necessary to give a relatively formal defination to it instead of only presenting some instances of so called "IoT device". The domain name is usually used to uniquely and consistently identify objects and thus it is better to keep the domain name unchangeable. If many kinds of information of "IoT devices" (such as their locations and categories) are inserted into the domain name in some way, whether we should change the domain name or not if some kinds of information (like the location) changes?

Guangqing Deng

From: Mr. Jaehoon Paul Jeong<>
Date: 2014-11-19 12:00
To: Stuart Cheshire<>
CC:<>; Myung-Ki Shin<>; Brian Haberman<>; Jung-Soo Park<>
Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices
Thanks for your constructive comments.

As I answered Alf's email message just before,
I would like to allow IoT vendors to have an alternative way for DNS naming
with more compact implementation based on IPv6 stateless autoconfiguration.

For the question about how users find out the host names and which protocols are used
were presented with the following slides 4 and 5 during the last dnssd WG session in Hawaii:

To figure out what those devices do, we can use device category and device model
in the DNS name format.


Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software /
Department of Computer Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
CPS Lab Website:
Personal Homepage:

On Wed, Nov 19, 2014 at 7:46 AM, Stuart Cheshire <<>> wrote:
On 17 Nov, 2014, at 17:33, Mr. Jaehoon Paul Jeong <<>> wrote:

> Hi Tom,
> You are right for appliances with enough capacity to run mDNS.
> However, for low capacity IoT devices without mDNS, my proposal will be able to support an alternative way for DNS naming.

You assert that there are devices with insufficient resources to run DNS-SD/mDNS.

You assert that these devices would have sufficient resources to run your alternative.

I think you need data to substantiate these claims. Note that devices like the SitePlayer Telnet implement DNS-SD/mDNS in under one kilobyte (about 850 bytes of code, if I remember correctly): <>

So you need to demonstrate that:

1. That there are devices where 850 bytes of code is too much.

2. That these devices can implement your thing in under 850 bytes.

3. That your thing is useful. I’m still unclear on what your thing is useful for. Your proposal says how devices pick host names, but not how users find out what those host names are, or find out what those devices do, or what protocol to use to communicate with them, and how clients resolve those host names to addresses.

Stuart Cheshire

dnssd mailing list<>