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

[Stuart Cheshire <[e-mail]>]

On 4 Nov 2015, at 23:14, Mr. Jaehoon Paul Jeong <[e-mail]> 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:
> http://www.samsung.com/us/support/appliances/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.

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.

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:

<http://www.amazon.com/Rainforest-EAGLE-Ethernet-ZigBee-Gateway/dp/B00AII248U>

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.

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.

Stuart Cheshire