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

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 13 Nov 2014 23:49:55 -1000

Hi dnssg WG folks,
This is Paul.

Today I presented a new draft for DNS Name Autoconfiguration for
Home Network Devices and IoT Devices at the end of dnssg WG session.
I would like to get your comments on whether this new topic is worthy of
work
in our dnssg WG.

My problem is how to make IoT devices have their unique DNS names
without the intervention or with a minimal intervention of home network
users.

The draft information is as follows:
Title: DNS Name Autoconfiguration for Home Network Devices

Draft:
http://datatracker.ietf.org/doc/draft-jeong-homenet-device-name-autoconf/

Abstract:
   This document specifies an autoconfiguration scheme for DNS names of
   home network devices.  By this scheme, the DNS name of a home network
   device can be autoconfigured with the device's category and model in
   a home network.  This DNS name lets home residents easily identify
   each device for monitoring and remote-controlling it in a home network.

The procedure of DNS name autoconfiguration is as follows:
- IoT devices autoconfigure their DNS names by using device information
  (e.g., device category, vendor name, and model) and a DNS suffix in DNS
search list
  that is advertised by RA or Stateless DHCPv6.

- A router then collects the DNS names and IPv6 addresses of IoT devices
  using Node Information Protocol.

- After this DNS name collection, the router registers the pairs of DNS
names and
  IPv6 addresses of the IoT devices into a DNS Server using DNS dynamic
update.

Once we agree on the usefulness of this draft, we can start to discuss the
DNS name format
and the autoconfiguration procedure based on this draft along with some
assumptions, such as
the trust model between a router and devices for DNS name registration.

Thanks for your comments in advance.

Paul
===========================
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
Email: [email-masked], [email-masked]
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Thu, 13 Nov 2014 23:52:24 -1000

Hi all,
There is a typo on dnssd :-)

Thanks.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Nov 2014 09:39:49 -1000

On Nov 13, 2014, at 11:49 PM, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> without the intervention or with a minimal intervention of home network users.

RFC 6762 section 9 explains how to do this without operator intervention.   I presume that you do not find the solution given in 6762 good enough for your specific use case.   Can you explain why it isn't good enough--why something better is needed?

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 14 Nov 2014 11:34:05 -1000

Ted,
The solution in RFC 6762 (Multicast DNS) section 9 is viable for regular
computers,
such as laptop, desktop, and smartphone that can afford to run mDNS
responder.
For IoT devices, such as light bulb and fire detecting sensor, that have
limited memory and storage,
mDNS seems not viable for the DNS naming for them.

For IoT devices, IETF is working for 6lo for the light interface with IPv6
layer.
In this context, my proposal is based on IPv6 neighbor discovery, so it
will be a viable option for
the DNS name service of IoT devices.

For the regeneration and verification of a unique DNS name under DNS name
conflict,
the solution in RFC 6762 recommends to use an incremental digit (such as 2,
3, 4, etc.) by trial and error.
In an IoT scenario where there will be many IoT devices of the same type,
such as light bulb in home or hotel here,
this incremental numbering approach will be costly and slow to let each IoT
device have a unique DNS name,
especially in a multi-subset network.

My proposal (not included in my current draft yet) is that the router will
join the "multicast addresses for IoT devices" as
a proxy for DNS name conflict detector in the home network whose DNS names
are registered in a DNS server
in the home network.

Thanks for your good feedback.

Paul

On Fri, Nov 14, 2014 at 9:39 AM, Ted Lemon <[email-masked]> wrote:

> RFC 6762 section 9 explains how to do this without operator intervention.
>  I presume that you do not find the solution given in 6762 good enough for
> your specific use case.   Can you explain why it isn't good enough--why
> something better is needed?
>
>
>

---

From: Dave Thaler <[email-masked]>
Date: Fri, 14 Nov 2014 21:59:44 +0000

Paul wrote:
> For the regeneration and verification of a unique DNS name under DNS name conflict,
> the solution in RFC 6762 recommends to use an incremental digit (such as 2, 3, 4, etc.)
> by trial and error. In an IoT scenario where there will be many IoT devices of the same
> type, such as light bulb in home or hotel here, this incremental numbering approach
> will be costly and slow to let each IoT device have a unique DNS name, ...

My reading is that RFC 6762 does not _require_ an incremental digit.  You can put in
a random ID or MAC-derived ID or something else highly unlikely to collide.
As such, it should not be "costly and slow".  Indeed RFC 6762 does not specify what
you have to do.   Would it be possible to recast your draft as
"how to choose a unique ID and use RFC 6762" ? 

-Dave

---

From: Alf Watt <[email-masked]>
Date: Fri, 14 Nov 2014 14:02:27 -0800

I’m confused, the mDNSResponder code is very lightweight and already runs on embedded devices such as printers, cameras and may other low-memory and low-cpu devices.

What is your target memory and cpu size for an IoT device? Given that we’ve been using mDNS for more than a decade, the steady pace of improvement in semiconductors means that even the smallest device will have more than sufficient resources for mMDS.

Best,
Alf

> On Nov 14, 2014, at 1:34 PM, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> 
> The solution in RFC 6762 (Multicast DNS) section 9 is viable for regular computers, 
> such as laptop, desktop, and smartphone that can afford to run mDNS responder.
> For IoT devices, such as light bulb and fire detecting sensor, that have limited memory and storage,

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Nov 2014 12:16:47 -1000

> I’m confused, the mDNSResponder code is very lightweight and already runs on embedded devices such as printers, cameras and may other low-memory and low-cpu devices.

The issue for lln devices is often battery capacity.

---

From: Daniel Park <[email-masked]>
Date: Sat, 15 Nov 2014 10:10:51 +0900

Before rushing this topic here, you should be clarifying why DNS-bases
discovery is necessary for IoT lite things. As of now, CoAP is mostly
popular in this world. It is well designed by IETF considering IoT resource
model and simplified message exchanges...

So, do you have any strong use case and requirement with DNS-based approach
in IoT?

Daniel.

Soohong Daniel Park, Ph.D.
Samsung Software R&D Center
2014. 11. 15. 오전 7:18에 "Ted Lemon" <[email-masked]>님이 작성:

> > I’m confused, the mDNSResponder code is very lightweight and already
> runs on embedded devices such as printers, cameras and may other low-memory
> and low-cpu devices.
>
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 14 Nov 2014 20:22:41 -1000

Dave,
Thanks for your clarification.

In Page 32 in RFC 6762, there is the recommended course of action after
probing and failing, but
there is no text about a random ID selection.
Anyway, we can perform a random ID selection for the uniqueness of a DNS
name, but
the readability for such a DNS name is not good for the users.

My original intention for DNS name generation is to include device category
(e.g., refrigerator),
device vendor (e.g., Samsung), device model (e.g., RH269LP).
This name itself delivers much information to users and mobile  smart
devices (e.g., smartphone or smart TV)
to represent the device icon visually.

I am not sure this is enough answer for your last question.
If you have more comments, please let me know.

Paul

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 14 Nov 2014 20:34:51 -1000

Alf,
For embedded such as printers, cameras that have power and capacity
equivalent to smartphone,
you are right.

For low-power low-capacity devices, such as light bulb and smoke detecting
sensor,
I think that running server(s) seems not viable
even though I have no exact number of target memory and cpu size
for such low-power low-capacity IoT devices.

Is there anyone else to comment on the hardware specification of such IoT
devices?

Thanks.

Paul

On Fri, Nov 14, 2014 at 12:02 PM, Alf Watt <[email-masked]> wrote:

> I’m confused, the mDNSResponder code is very lightweight and already runs
> on embedded devices such as printers, cameras and may other low-memory and
> low-cpu devices.
>
> What is your target memory and cpu size for an IoT device? Given that
> we’ve been using mDNS for more than a decade, the steady pace of
> improvement in semiconductors means that even the smallest device will have
> more than sufficient resources for mMDS.
>
> Best,
> Alf
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Sat, 15 Nov 2014 07:47:41 -1000

Daniel,
That's a good point.

One use case is IPv6 networking in smart grid networks and home area
networks
are based on IEEE 1901.2 Narrowband Powerline Communication Networks (PLC).
All IoT devices will not necessarily use only wireless communications for
LLN (low power and lossy networks),
such as IEEE 802.15.4.

Also, CoAP is indeed a useful protocol for IoT devices, but we cannot
preclude the cases
where IoT devices do not use CoAP.

Since low capacity IoT devices using IPv6 somehow are IPv6 hosts, it will
be useful
to let those IoT devices autoconfigure their unique DNS names and
tell a network managment entity (e.g., home network users or administrators)
their naming information in terms of management.

Thanks.

Paul

On Fri, Nov 14, 2014 at 3:10 PM, Daniel Park <[email-masked]> wrote:

> So, do you have any strong use case and requirement with DNS-based
> approach in IoT?
>
> Daniel.
>

---

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
Date: Mon, 17 Nov 2014 21:15:26 +0000

It seems to me that part of your intent is to include semantics (e.g., device category, device vendor, device model) in a standardized fashion into the DNS name.

On the other hand, while we often apply semantics to DNS names currently for human readers, these semantics typically are not standardized for machines.  For that, we have DNS-SD.

As an example from the IoT space, we use both mDNS and DNS-SD for SEP 2.0 (IEEE 2030.5).  While the DNS names often reflect aspects such as device manufacturer and category, these are not meant to be machine interpretable in SEP 2.0.  Rather, we use DNS-SD to advertise various functionality that is machine interpretable.

Perhaps I am misinterpreting, but is your intent to place machine-interpretable semantics into the actual DNS names themselves?

Thanks,
Robby

Robby Simpson, PhD

System Architect

GE

Digital Energy

M: +1 404 219 1851

[email-masked]

From: "Mr. Jaehoon Paul Jeong" <[email-masked]<mailto:[email-masked]>>
Date: Saturday, November 15, 2014 at 1:22 AM
To: Dave Thaler <[email-masked]<mailto:[email-masked]>>
Cc: Brian Haberman <[email-masked]<mailto:[email-masked]>>, Myung-Ki Shin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jung-Soo Park <[email-masked]<mailto:[email-masked]>>, Ted Lemon <[email-masked]<mailto:[email-masked]>>, Sejun Lee <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices

Dave,

In Page 32 in RFC 6762, there is the recommended course of action after probing and failing, but
there is no text about a random ID selection.
Anyway, we can perform a random ID selection for the uniqueness of a DNS name, but
the readability for such a DNS name is not good for the users.

My original intention for DNS name generation is to include device category (e.g., refrigerator),
device vendor (e.g., Samsung), device model (e.g., RH269LP).
This name itself delivers much information to users and mobile  smart devices (e.g., smartphone or smart TV)
to represent the device icon visually.

Paul

Email: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

On Fri, Nov 14, 2014 at 11:59 AM, Dave Thaler <[email-masked]<mailto:[email-masked]>> wrote:

-Dave

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 17 Nov 2014 18:09:12 -0500

I agree that overloading the DNS name is the wrong place for this information.

So would this be a good use for the device-info Pseudo Service Type TXT record?

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.

http://www.dns-sd.org/servicetypes.html

http://lists.apple.com/archives/bonjour-dev/2011/Jul/msg00016.html

Thanks,
Tom

> On Nov 17, 2014, at 4:15 PM, Simpson, Robby (GE Energy Management) <[email-masked]> wrote:
>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 18 Nov 2014 10:29:47 +0900

Hi Robby,
Yes, my intent is to to include semantics (e.g., device category, device
vendor, and device model)
in a standardized fashion into the DNS names of low-capacity IoT devices.

I intend to place machine-interpretable semantics into the actual DNS names
themselves
so that machines can use the DNS name for the identification of other
machines
without additional service discovery through mDNS.

The localization of devices is also possible with the DNS name
because the DNS name can include the location of the device,
as describe in Section 6 (Location-Aware DNS Name Configuration) in my
draft:
http://datatracker.ietf.org/doc/draft-jeong-homenet-device-name-autoconf/

Thanks for your good opinion.

Paul

On Tue, Nov 18, 2014 at 6:15 AM, Simpson, Robby (GE Energy Management) <
[email-masked]> wrote:

> It seems to me that part of your intent is to include semantics (e.g.,
> device category, device vendor, device model) in a standardized fashion
> into the DNS name.
>
> On the other hand, while we often apply semantics to DNS names currently
> for human readers, these semantics typically are not standardized for
> machines.  For that, we have DNS-SD.
>
> As an example from the IoT space, we use both mDNS and DNS-SD for SEP 2.0
> (IEEE 2030.5).  While the DNS names often reflect aspects such as device
> manufacturer and category, these are not meant to be machine interpretable
> in SEP 2.0.  Rather, we use DNS-SD to advertise various functionality that
> is machine interpretable.
>
> Perhaps I am misinterpreting, but is your intent to place
> machine-interpretable semantics into the actual DNS names themselves?
>
> Thanks,
> Robby
>
>
> Robby Simpson, PhD
>
> System Architect
>
> GE
>
> Digital Energy
>
> M: +1 404 219 1851
>
> [email-masked]
>
>
> Cc: Brian Haberman <[email-masked]<mailto:
> [email-masked]>>, Myung-Ki Shin <[email-masked]<mailto:
> [email-masked]>>, "[email-masked]<mailto:[email-masked]>" <
> [email-masked]<mailto:[email-masked]>>, Jung-Soo Park <[email-masked]
> <mailto:[email-masked]>>, Ted Lemon <[email-masked]<mailto:
> [email-masked]>>, Sejun Lee <[email-masked]<mailto:
> [email-masked]>>
> Email: [email-masked]<mailto:[email-masked]>,
> [email-masked]<mailto:[email-masked]>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 18 Nov 2014 10:33:09 +0900

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.

Thanks.

Paul

On Tue, Nov 18, 2014 at 8:09 AM, Tom Pusateri <[email-masked]> wrote:

> > As an example from the IoT space, we use both mDNS and DNS-SD for SEP
> 2.0 (IEEE 2030.5).  While the DNS names often reflect aspects such as
> device manufacturer and category, these are not meant to be machine
> interpretable in SEP 2.0.  Rather, we use DNS-SD to advertise various
> functionality that is machine interpretable.
> >

---

From: Alf Watt <[email-masked]>
Date: Tue, 18 Nov 2014 10:46:38 -0800

The proposal may have merit for other reasons but in terms of resource usage for IoT devices it’s very instructive to look at existing products.

The Phillips Hue lights are built around a 32 ARM core [1] with limited RAM (128kb). The Nest Protect smoke detector is also built around a similar 32bit ARM core from Freescale, the K60[2].

Both of these are attached to a Zigbee radio, which provides sufficient bandwidth for DNS-SD over mDNS, as per our charter[3].

Devices which need service discovery on batteries will very likely be using layer-2 discovery mechanisms for power consumption reasons (i.e. BT-LE). 

I have a hard time imagining that a device with much less capabilities than above will be a useful internet node. If it can't afford to run a simple discovery service then what is it doing on the network?

Best,
Alf

[1] http://www.digchip.com/datasheets/parts/datasheet/456/STM32F217VET6.php
"ARM-based 32-bit MCU, MB Flash/128+4KB RAM, crypto, USB OTG HS/FS, Ethernet, 17 TIMs, 3 ADCs, 15 	comm. interfaces & camera"
[2] http://cache.freescale.com/files/32bit/doc/data_sheet/K60P100M100SF2V2.pdf?fpsp=1&WT_TYPE=Data%20Sheets&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation
[3] http://datatracker.ietf.org/wg/dnssd/charter/

> On Nov 14, 2014, at 10:34 PM, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> 
> Alf,
> For embedded such as printers, cameras that have power and capacity equivalent to smartphone,
> you are right.
> 
> For low-power low-capacity devices, such as light bulb and smoke detecting sensor,
> Is there anyone else to comment on the hardware specification of such IoT devices?
> 
> Thanks.
> 
> Paul  
>

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 18 Nov 2014 14:46:49 -0800

On 17 Nov, 2014, at 17:33, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:

> 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): <http://netmedia.com/siteplayer/telnet/>

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

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 19 Nov 2014 11:49:53 +0900

Alf,
Thanks for your kind survey information.

It seems that the devices mentioned above will be able to run mDNS.
My point is to allow IoT device vendors to have an alternative way for a
simple DNS naming
that is based on IPv6 stateless autoconfiguration.

For the case where only the mapping between an IoT device's DNS name and
its IPv6 is required,
mDNS seems like an overkill.

Paul

On Wed, Nov 19, 2014 at 3:46 AM, Alf Watt <[email-masked]> wrote:

> The proposal may have merit for other reasons but in terms of resource
> usage for IoT devices it’s very instructive to look at existing products.
>
> The Phillips Hue lights are built around a 32 ARM core [1] with limited
> RAM (128kb). The Nest Protect smoke detector is also built around a similar
> 32bit ARM core from Freescale, the K60[2].
>
> Both of these are attached to a Zigbee radio, which provides sufficient
> bandwidth for DNS-SD over mDNS, as per our charter[3].
>
> Devices which need service discovery on batteries will very likely be
> using layer-2 discovery mechanisms for power consumption reasons (i.e.
> BT-LE).
>
> I have a hard time imagining that a device with much less capabilities
> than above will be a useful internet node. If it can't afford to run a
> simple discovery service then what is it doing on the network?
>
> Best,
> Alf
>
> [1]
> http://www.digchip.com/datasheets/parts/datasheet/456/STM32F217VET6.php
> "ARM-based 32-bit MCU, MB Flash/128+4KB RAM, crypto, USB OTG HS/FS,
> Ethernet, 17 TIMs, 3 ADCs, 15  comm. interfaces & camera"
> [2] *http://cache.freescale.com/files/32bit/doc/data_sheet/K60P100M100SF2V2.pdf?fpsp=1&WT_TYPE=Data%20Sheets&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation
> <http://cache.freescale.com/files/32bit/doc/data_sheet/K60P100M100SF2V2.pdf?fpsp=1&WT_TYPE=Data%20Sheets&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation>*

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Wed, 19 Nov 2014 13:00:27 +0900

Stuart,
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:
http://www.ietf.org/proceedings/91/slides/slides-91-dnssd-6.pdf

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

Paul

On Wed, Nov 19, 2014 at 7:46 AM, Stuart Cheshire <[email-masked]> wrote:

> > However, for low capacity IoT devices without mDNS, my proposal will be
> able to support an alternative way for DNS naming.
>
> 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): <
> http://netmedia.com/siteplayer/telnet/>
>
> 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
>

---

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
Date: Thu, 20 Nov 2014 15:51:24 +0000

>http://lists.apple.com/archives/bonjour-dev/2011/Jul/msg00016.html

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.

HTH,
Robby

---

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
Date: Thu, 20 Nov 2014 15:57:58 +0000

Hi Paul,

If the actual DNS name is used, I would be concerned by (at least) the following:
- Parsing — clearly there will be non-compliant DNS names out there, that these devices will have to parse and trash.  Looking at your draft, how would they know?
- Extensibility — in the future how could new information be included?  New categories?
- Size — as the target is IoT, bytes on the "wire" matter and this descriptive information is going to be quite large in the DNS format

My preference would be for devices to support some resource that is discovered via DNS-SD — see my other email for details.

- Robby

From: "Mr. Jaehoon Paul Jeong" <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 17, 2014 at 8:29 PM
To: Charles Simpson <[email-masked]<mailto:[email-masked]>>
Cc: Dave Thaler <[email-masked]<mailto:[email-masked]>>, Brian Haberman <[email-masked]<mailto:[email-masked]>>, Myung-Ki Shin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jung-Soo Park <[email-masked]<mailto:[email-masked]>>, Ted Lemon <[email-masked]<mailto:[email-masked]>>, Sejun Lee <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices

Hi Robby,
Yes, my intent is to to include semantics (e.g., device category, device vendor, and device model)
in a standardized fashion into the DNS names of low-capacity IoT devices.

I intend to place machine-interpretable semantics into the actual DNS names themselves
so that machines can use the DNS name for the identification of other machines
without additional service discovery through mDNS.

The localization of devices is also possible with the DNS name
because the DNS name can include the location of the device,
as describe in Section 6 (Location-Aware DNS Name Configuration) in my draft:
http://datatracker.ietf.org/doc/draft-jeong-homenet-device-name-autoconf/

Paul

On Tue, Nov 18, 2014 at 6:15 AM, Simpson, Robby (GE Energy Management) <[email-masked]<mailto:[email-masked]>> wrote:
It seems to me that part of your intent is to include semantics (e.g., device category, device vendor, device model) in a standardized fashion into the DNS name.

Thanks,
Robby

Robby Simpson, PhD

System Architect

GE

Digital Energy

M: +1 404 219 1851

[email-masked]<mailto:[email-masked]>

From: "Mr. Jaehoon Paul Jeong" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
Date: Saturday, November 15, 2014 at 1:22 AM
To: Dave Thaler <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
Cc: Brian Haberman <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Myung-Ki Shin <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Jung-Soo Park <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Ted Lemon <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, Sejun Lee <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>
Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices

Dave,

Paul

Email: [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>, [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>

On Fri, Nov 14, 2014 at 11:59 AM, Dave Thaler <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:

-Dave

---

From: Alf Watt <[email-masked]>
Date: Thu, 20 Nov 2014 11:02:13 -0800

Paul,

Thank you for responding. I took the time to read through your proposal and have the following suggestions:

- carefully consider the extent to which your proposal duplicates existing work, in particular:

	- 5.2.1. and 5.2.2. very closely resemble the current behavior of mDNS nodes choosing names

	- 5.2.3 the ‘collector’ is effectively an mDNS/DNS-SD browser which is limited to name records

	- Note well that mDNS/DNS-SD specifications carefully describe the desirable caching behavior
		for multiple ‘collectors’ on a multicast link, which significantly improves performance

- carefully consider the existing uses for the DNS name label for an internet host:

	- 6 - 6.2 while the concept of nested location for IoT devices is interesting, overloading the existing
		name parameter to convey this information does not seem like an appropriate tradeoff.

	- 6 - 6.2 it is also unclear how a device would be able to locate itself in a particular micro or macro location
		and therefore generate an appropriate name for itself, without user configuration

	- the ‘name’ of any object, networked or not, is generally the choice of the owner. In some cultures ‘naming’
		is synonymous with taking ownership. Taking away the end-users ability to name their IoT objects may
		result in poor usability, and potentially cause confusion with existing applications or network devices 
		which do not implement the proposed naming scheme.

- while naming is important, a device only needs to be discoverable and visible to users if some service is to be accessed:
	- your proposal covers only half of the solution currently provided by mDNS/DNS-SD: local naming AND service discovery
	- applications connect to services, not hosts; if a host offers no services then it does not need to be visible in a browser
	- most network users have little interest in discovery for the sake of discovery, they are interested in services

I suspect, that if you took the time to implement your proposal, you would quickly realize that the existing mDNS and DNS-SD standards aren't so much ‘overkill’ as the minimum set of features and optimizations which are required to efficiently implement the user experience your document calls for:

"This DNS name lets home residents easily identify each device for monitoring and remote-controlling it in a home network.”

Re-reading your proposal, no feature in it is not already possible using mDNS/DNS-SD, perhaps paired with new record types (ULOC, MLOC, or e.g. to represent the micro and macro location parameters, distinct from the existing LOC record), or existing ones (make, model and etc. could for e.g. be added to TXT records).

> On Nov 18, 2014, at 6:49 PM, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> 
> Alf,
> My point is to allow IoT device vendors to have an alternative way for a simple DNS naming 
> For the case where only the mapping between an IoT device's DNS name and its IPv6 is required,

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 21 Nov 2014 21:00:15 +0900

Hi Robby,
Thanks for your questions.

>- Parsing — clearly there will be non-compliant DNS names out there, that
these devices will have to parse and trash.  Looking at your draft, how
would they know?

In my proposal, an IoT device does not process the DNS query because it
does not run mDNS
for the DNS name resolution service.
Since the DNS name of the IoT device is registered into a DNS server via a
router that
is located at the same subnet with the IoT device.

>- Extensibility — in the future how could new information be included?
New categories?

When a new category is added into a new device's repository as factory
default,
such a new category will be used by the device for generating its DNS name.

>- Size — as the target is IoT, bytes on the "wire" matter and this
descriptive information is going to be quite large in the DNS format

In the case where the DNS name of an IoT device cannot be accommodated and
delivered by a MAC frame
to a router for the DNS name registration, multiple MAC frames having parts
of the DNS name will be sent and
merged at a gateway or router within the communication range of the IoT
device.
For 6LoWPAN, we can consider a compact DNS name format for IoT device for
the given device category
and model.

Paul

>
>My preference would be for devices to support some resource that is
discovered via DNS-SD — see my other email for details.

On Fri, Nov 21, 2014 at 12:57 AM, Simpson, Robby (GE Energy Management) <
[email-masked]> wrote:

> - Parsing — clearly there will be non-compliant DNS names out there, that
> these devices will have to parse and trash.  Looking at your draft, how
> would they know?
> - Size — as the target is IoT, bytes on the "wire" matter and this
> descriptive information is going to be quite large in the DNS format
>
> My preference would be for devices to support some resource that is
> discovered via DNS-SD — see my other email for details.
>
> - Robby
>
> Cc: Dave Thaler <[email-masked]<mailto:[email-masked]>>,
> Brian Haberman <[email-masked]<mailto:[email-masked]>>,
> Myung-Ki Shin <[email-masked]<mailto:[email-masked]>>, "
> [email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:
> [email-masked]>>, Jung-Soo Park <[email-masked]<mailto:[email-masked]>>,
> Ted Lemon <[email-masked]<mailto:[email-masked]>>, Sejun
> Lee <[email-masked]<mailto:[email-masked]>>
> [email-masked]<mailto:[email-masked]>> wrote:
> From: "Mr. Jaehoon Paul Jeong" <[email-masked]<mailto:
> [email-masked]><mailto:[email-masked]<mailto:
> [email-masked]>>>
> To: Dave Thaler <[email-masked]<mailto:[email-masked]
> ><mailto:[email-masked]<mailto:[email-masked]>>>
> [email-masked]><mailto:[email-masked]<mailto:
> [email-masked]>>>, Myung-Ki Shin <[email-masked]<mailto:
> [email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>, "
> [email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:
> [email-masked]>>" <[email-masked]<mailto:[email-masked]><mailto:
> [email-masked]<mailto:[email-masked]>>>, Jung-Soo Park <[email-masked]
> <mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>>,
> Ted Lemon <[email-masked]<mailto:[email-masked]><mailto:
> [email-masked]<mailto:[email-masked]>>>, Sejun Lee <
> [email-masked]<mailto:[email-masked]><mailto:
> [email-masked]<mailto:[email-masked]>>>
> Email: [email-masked]<mailto:[email-masked]><mailto:
> [email-masked]<mailto:[email-masked]>>, [email-masked]
> <mailto:[email-masked]><mailto:[email-masked]<mailto:
> [email-masked]>>
> On Fri, Nov 14, 2014 at 11:59 AM, Dave Thaler <[email-masked]
> <mailto:[email-masked]><mailto:[email-masked]<mailto:
> [email-masked]>>> wrote:
> Paul wrote:

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Fri, 21 Nov 2014 21:55:38 +0900

Alf,
It seems like you didn't attend the last DNSSD WG session in Hawaii.
Though my draft lacks explanation for DNS name registration into a DNS
server,
I did explain the presentation at the last DNSSD WG session with the
following slides,
especially slide 5:
http://www.ietf.org/proceedings/91/slides/slides-91-dnssd-6.pdf

>        - 5.2.1. and 5.2.2. very closely resemble the current behavior of
mDNS nodes choosing names

Though there exists a similarity for the DNS name generation, the
difference is that my scheme uses
the device category and device model for the DNS name to let an IoT device
be identified for its functionality
without an explicit service discovery procedure.

>        - 5.2.3 the ‘collector’ is effectively an mDNS/DNS-SD browser
which is limited to name records

Well, not exactly the same.
The collector is either a router or host that uses Node Information
protocol rather than mDNS.

>                name parameter to convey this information does not seem
like an appropriate tradeoff.

The method to find out the micro-location is out of scope in this scope.
It is assumed that the micro-location information (e.g., refrigerator) for
the macro-location information (e.g., kitchen)
is available.
The localization of the micro-location and macro-location is the current
feasible research subject under
the development of my research lab. We have a preliminary result based on
simulation in an apartment.

>        - 6 - 6.2 it is also unclear how a device would be able to locate
itself in a particular micro or macro location
>                and therefore generate an appropriate name for itself,
without user configuration

Like the above answer, the micro or macro location can be autoconfigured by
the smartphone in indoor environments,
such as an apartment. Take a look at the slide 9 among the slides that were
presented at Homenet WG
in the last IETF meeting:
http://www.ietf.org/proceedings/91/slides/slides-91-homenet-4.pdf

>
>        - the ‘name’ of any object, networked or not, is generally the
choice of the owner. In some cultures ‘naming’
>                is synonymous with taking ownership. Taking away the
end-users ability to name their IoT objects may
>                result in poor usability, and potentially cause confusion
with existing applications or network devices
>                which do not implement the proposed naming scheme.

My draft does not prevent end-users from manually configuring DNS name for
their IoT devices.
As you know, an IPv6 interface of the IoT device can have more than a DNS
name for the given, same IPv6 address.

>- while naming is important, a device only needs to be discoverable and
visible to users if some service is to be accessed:
>        - your proposal covers only half of the solution currently
provided by mDNS/DNS-SD: local naming AND service discovery
>        - applications connect to services, not hosts; if a host offers no
services then it does not need to be visible in a browser
>        - most network users have little interest in discovery for the
sake of discovery, they are interested in services

In my scheme, the device category and device type including vendor are
included into a DNS name,
these can be used to let users identify the available services when a
database having the mapping
the service information for the device category and device type (such as
unicast-based DNS server at home)
is available to the users.

In my approach, a unicast-based DNS server is required with the mapping
information of DNS names and IPv6 addresses
of IoT devices rather than running individual mDNS per IoT device.

>I suspect, that if you took the time to implement your proposal, you would
quickly realize that the existing mDNS and DNS-SD standards aren't so much
‘overkill’ as the minimum set of features and optimizations which are
required to >efficiently implement the user experience your document calls
for:

In my approach, IoT devices need a generic IPv6 stack with handling
additional ICMPv6 options,
such as DAD for DNS name and Node Information Protocol rather than mDNS as
application.
We need to consider which approach is easy for the implementers.

Paul

>"This DNS name lets home residents easily identify each device for
monitoring and remote-controlling it in a home network.”
>
>Re-reading your proposal, no feature in it is not already possible using
mDNS/DNS-SD, perhaps paired with new record types (ULOC, MLOC, or e.g. to
represent the micro and macro location parameters, distinct from the
existing LOC record), or existing ones (make, model and etc. could for e.g.
be added to TXT records).

On Fri, Nov 21, 2014 at 4:02 AM, Alf Watt <[email-masked]> wrote:

>         - 6 - 6.2 it is also unclear how a device would be able to locate
> itself in a particular micro or macro location
>         - the ‘name’ of any object, networked or not, is generally the
> choice of the owner. In some cultures ‘naming’
>                 is synonymous with taking ownership. Taking away the
> end-users ability to name their IoT objects may
>                 result in poor usability, and potentially cause confusion
> with existing applications or network devices
> - while naming is important, a device only needs to be discoverable and
> visible to users if some service is to be accessed:
>         - your proposal covers only half of the solution currently
> provided by mDNS/DNS-SD: local naming AND service discovery
>         - applications connect to services, not hosts; if a host offers no
> services then it does not need to be visible in a browser
>         - most network users have little interest in discovery for the
> sake of discovery, they are interested in services
>
> I suspect, that if you took the time to implement your proposal, you would
> quickly realize that the existing mDNS and DNS-SD standards aren't so much
> ‘overkill’ as the minimum set of features and optimizations which are
> required to efficiently implement the user experience your document calls
> for:
>
> "This DNS name lets home residents easily identify each device for
> monitoring and remote-controlling it in a home network.”
>
> Re-reading your proposal, no feature in it is not already possible using
> mDNS/DNS-SD, perhaps paired with new record types (ULOC, MLOC, or e.g. to
> represent the micro and macro location parameters, distinct from the
> existing LOC record), or existing ones (make, model and etc. could for e.g.
> be added to TXT records).
>
>
>
> > [2]
> http://cache.freescale.com/files/32bit/doc/data_sheet/K60P100M100SF2V2.pdf?fpsp=1&WT_TYPE=Data%20Sheets&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Nov 2014 08:36:25 -0500

I think we still haven't heard a clear explanation for why this new protocol work is needed.   That would be the key discussion to have.   Discussions about what the protocol work would entail, or how it would integrate with other work, are premature until that discussion has reached a conclusion.

---

From: "Guangqing Deng" <[email-masked]>
Date: Tue, 25 Nov 2014 00:26:37 +0800

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
cnnic 

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

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:
http://www.ietf.org/proceedings/91/slides/slides-91-dnssd-6.pdf

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

Paul

Stuart Cheshire

---

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
Date: Mon, 24 Nov 2014 16:32:47 +0000

When discussing constrained devices (which I think is the intent here), I find the definitions from RFC 7228 (https://datatracker.ietf.org/doc/rfc7228/) convenient.

- Robby

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

________________________________
Guangqing Deng
cnnic

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

Paul

On Wed, Nov 19, 2014 at 7:46 AM, Stuart Cheshire <[email-masked]<mailto:[email-masked]>> wrote:

Stuart Cheshire

_______________________________________________
dnssd mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dnssd

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 25 Nov 2014 09:44:24 +0900

Robby,
This is a good reference for constrained node, such as IoT.
I will include the definitions of constrained node and IoT in the next
version of my draft.

Thanks.

Paul

On Tue, Nov 25, 2014 at 1:32 AM, Simpson, Robby (GE Energy Management) <
[email-masked]> wrote:

> When discussing constrained devices (which I think is the intent here), I
> find the definitions from RFC 7228 (
> https://datatracker.ietf.org/doc/rfc7228/) convenient.
>
> - Robby
>
> From: Guangqing Deng <[email-masked]<mailto:[email-masked]
> >>
> 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?
>
> CC: [email-masked]<mailto:[email-masked]>; Myung-Ki Shin<mailto:
> [email-masked]>; Brian Haberman<mailto:[email-masked]>;
> Jung-Soo Park<mailto:[email-masked]>

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 25 Nov 2014 09:50:13 +0900

Guangqing,
Domain name has the meaning of both logical space and physical space.
For example, ".home" means the domain of logical space for home network and
also
the physical place of my home.

In my draft, the location as part of domain name puts more weight on
physical space and
the device category as part of domain name puts more weight on local space
as a device cluster in a home network.

Thanks.

Paul

On Tue, Nov 25, 2014 at 1:26 AM, Guangqing Deng <[email-masked]>
wrote:

>  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
> ------------------------------
>  Guangqing Deng
> cnnic
>
>  *From:* Mr. Jaehoon Paul Jeong <[email-masked]>
> *Date:* 2014-11-19 12:00
> *To:* Stuart Cheshire <[email-masked]>
> *CC:* [email-masked]; Myung-Ki Shin <[email-masked]>; Brian Haberman
> <[email-masked]>; Jung-Soo Park <[email-masked]>
> *Subject:* Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices
>  Stuart,
>> 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): <

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 25 Nov 2014 10:01:33 +0900

Ted and DNSSD people,
I believe that our DNSSD working group is worthy of working on DNS name
service
for constrained-node networks, such as IoT.

In order to lead the early deployment of IoT into the reality,
a simple light DNS naming approach with only IPv6 stateless
autoconfiguration
will be beneficial for LLN IoT devices while the mDNS approach is used for
appliances
and computers in home networks.

Thanks.

Best Regards,
Paul

On Fri, Nov 21, 2014 at 10:36 PM, Ted Lemon <[email-masked]> wrote:

> I think we still haven't heard a clear explanation for why this new
> protocol work is needed.   That would be the key discussion to have.
>  Discussions about what the protocol work would entail, or how it would
> integrate with other work, are premature until that discussion has reached
> a conclusion.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Nov 2014 21:42:43 -0500

On Nov 24, 2014, at 8:01 PM, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> a simple light DNS naming approach with only IPv6 stateless autoconfiguration 
> will be beneficial for LLN IoT devices while the mDNS approach is used for appliances 

You have said this numerous times.   However, in order to get IETF consensus on some work you want to do, you need to do more than say what work you want to do.   You also have to convince some IETF working group to adopt the work you want to do.   Stuart Cheshire gave you a pretty good summary of what you need to do to convince the working group that this work is worth doing.

Can you please read what Stuart wrote and try to do as he asked?   Please understand that if you can't show that your solution is so much smaller than an mDNS implementation that it makes sense to do it, there is no chance that this working group, or any other working group in the IETF, will agree to take on the work you propose to do, as you propose to do it.

"As you propose to do it" is really important, though.   If there is some problem you have that is not addressed by existing mDNS standards or by standards currently being contemplated by this working group, then you should try to explain how that problem is different from the problems mDNS already solves.   In that case, even if the working group doesn't agree to work on your specific solution to the problem, we may decide that the problem you want to solve is important, and may therefore agree to work on a solution to that problem.

---

From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Date: Tue, 25 Nov 2014 12:54:12 +0900

Ted,
I agree that mDNS with 850 bytes in binary does not require so much in
memory.
However, every engineer for IoT devices must implement much more source
code than 850 bytes for
a simple DNS name autoconfiguration.
On the other hand, my proposal will require much less source code than
mDNS,
allowing the engineers to make less efforts.
This is my point.

Paul

On Tue, Nov 25, 2014 at 11:42 AM, Ted Lemon <[email-masked]> wrote:

> You have said this numerous times.   However, in order to get IETF
> consensus on some work you want to do, you need to do more than say what
> work you want to do.   You also have to convince some IETF working group to
> adopt the work you want to do.   Stuart Cheshire gave you a pretty good
> summary of what you need to do to convince the working group that this work
> is worth doing.
>
> Can you please read what Stuart wrote and try to do as he asked?   Please
> understand that if you can't show that your solution is so much smaller
> than an mDNS implementation that it makes sense to do it, there is no
> chance that this working group, or any other working group in the IETF,
> will agree to take on the work you propose to do, as you propose to do it.
>
> "As you propose to do it" is really important, though.   If there is some
> problem you have that is not addressed by existing mDNS standards or by
> standards currently being contemplated by this working group, then you
> should try to explain how that problem is different from the problems mDNS
> already solves.   In that case, even if the working group doesn't agree to
> work on your specific solution to the problem, we may decide that the
> problem you want to solve is important, and may therefore agree to work on
> a solution to that problem.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Nov 2014 23:16:40 -0500

On Nov 24, 2014, at 10:54 PM, Mr. Jaehoon Paul Jeong <[email-masked]> wrote:
> However, every engineer for IoT devices must implement much more source code than 850 bytes for
> On the other hand, my proposal will require much less source code than mDNS, 

What matters is the size of the compiled code, no the size of the source code.   If you think Stuart is mistaken, please show your work: show that what you propose can be implemented in a significantly smaller code footprint than what Stuart is describing.