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

"Simpson, Robby (GE Energy Management)" <> Thu, 20 November 2014 15:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2B0131A0A6A for <>; Thu, 20 Nov 2014 07:51:46 -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 dKrLzqx_NmeA for <>; Thu, 20 Nov 2014 07:51:42 -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 8E9381A1A77 for <>; Thu, 20 Nov 2014 07:51:42 -0800 (PST)
Received: from pps.filterd ( []) by (8.14.7/8.14.7) with SMTP id sAKFjQSS004998 for <>; Thu, 20 Nov 2014 10:51:42 -0500
Received: from ([]) by with ESMTP id 1qsju6r0sc-11 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <>; Thu, 20 Nov 2014 10:51:42 -0500
Received: from unknown (HELO ([]) by with ESMTP/TLS/AES256-SHA; 20 Nov 2014 10:50:07 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 20 Nov 2014 10:51:26 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 20 Nov 2014 10:51:26 -0500
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Thu, 20 Nov 2014 10:51:25 -0500
From: "Simpson, Robby (GE Energy Management)" <>
To: Tom Pusateri <>
Thread-Topic: [dnssd] DNS Name Autoconfiguration for Home Network Devices
Date: Thu, 20 Nov 2014 15:51:24 +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="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
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-20_07:2014-11-20,2014-11-20,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-1411200126
Cc: Brian Haberman <>, Myung-Ki Shin <>, "" <>, Dave Thaler <>, Jung-Soo Park <>, Ted Lemon <>, Sejun Lee <>, "Mr. Jaehoon Paul Jeong" <>
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: Thu, 20 Nov 2014 15:51:46 -0000

On 11/17/14, 6:09 PM, "Tom Pusateri" <> wrote:

>So would this be a good use for the device-info Pseudo Service Type TXT
>I haven't been able to find much on "device-info" except for it's
>definition and a short email about it.
>But it seems like a TXT record with key/value pairs would be more
>suitable for this type of information.
>If device-info isn't right, then maybe a new service type can be defined
>for this purpose.

I myself am unfamiliar with device-info as well.  In general, I would be
concerned about putting too much of this information in TXT records as
that could be quite a lot of information being sent, particularly in mDNS
environments and also particularly if the target is IoT (where battery
power is at a premium, packet sizes are especially limited, etc.).

If you go down the route of not putting all of this information into TXT
records, you then need to decide on format (e.g., JSON, XML) and query
style, thus you end up with specific service types for "your world."
Which I think is OK as many of us are concentrated on different use cases.

To illustrate, once again I'll show what we did with SEP 2.0 (IEEE 2030.5):
We defined a service type "smartenergy".  All devices that would respond
to the "smartenergy" service type would then return a "dcap" TXT record.
That "dcap" was a URI that would lead an interested party to a
"DeviceCapabilities" resource, which spelled out where everything was
located on that device.  One of those was the "DeviceInformation"
resource, which contained various items such as manufacturer ID, model,
serial number, etc.  We also defined subtypes of the "smartenergy" service
type that would allow finer grained discovery by functionality, such as
locating devices that offered smart metering information.  Contact me
off-list if you want more details of this specific use, my point here is
just trying to illustrate how mDNS and DNS-SD have been used in the wild
to support this kind of information.