[prev in list] [next in list] [prev in thread] [next in thread]
List: ipng
Subject: Re: [DNSOP] Request for Comments on I-D about IoT DNS Name Autoconf
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul () gmail ! com>
Date: 2015-11-11 1:14:23
Message-ID: CAPK2DewrJKi3EdDvqmAu=-JmHbhYdudTsmcy9u5bv76py6M9dw () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Dear Mr. Cheshire,
Thanks for your frank thoughts and opinions.
On Tue, Nov 10, 2015 at 5:24 AM, Stuart Cheshire <cheshire@apple.com> wrote:
> On 4 Nov 2015, at 23:14, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com>
> 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.
>
>> Generally speaking, I tried to address useful comments on the
revisions as long as I understand,
such as location privacy for medical devices and a DNS name format.
Refer to the recent draft
https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00.
For the location privacy for IoT devices (e.g., medical devices and
smartphone),
in Section 8, the location of smartphone can be encrypted by a
shared key or public/privacy keys.
The device category or model can be encrypted based on my proposed
scheme.
For the DNS name format, though this version does not have the new
format based on Object ID,
this new name format is proposed in the slide 3 in my presentation
slides (https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00)
is proposed. The slides is attached in this email.
This new format is based on the standard format of ITU-T and
ISO/IEC for an object, such as IoT device.
On the next version of my draft, I will reflect this change.
In this version, the following are the new proposed ones:
- The global DNS name autoconfiguration as well as the local DNS
name autoconfiguration
(See Section 5.2.2. DNS Name Collection)
- The DNS name management for the mobility of IoT devices
(See Section 7. DNS Name Management for Mobile IoT Devices)
I discussed with 6lo folks, IoT software engineers, and IoT experts
for my proposed schemes.
They think that though my proposed one is a simple implementation
extension based on IPv6 ND and NI protocol,
it is efficient in multi-link network in terms of DNS packet number
and energy consumption because my resolution is based on
unicast rather than the multicast of mDNS.
My team at SKKU and Jubix (a startup company in Korea) are working
for simulation and implementation to compare
the overhead of mDNS and my proposed one (called DNSNA) in terms of
DNS packet number and energy consumption
in wireless networks (e.g., 6lo networks).
We have a plan to show the comparison in the next IETF 95 meeting.
> 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.
>
>> The service discovery, which gets information (e.g., services and
functions) from other devices, is out of scope in our current work.
Our goal in this draft is to provide a simple DNS name generation
and registration without any intervention of administrators and users.
>
> 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.
>
> >> The smart grid for KEPCO (Korea Electric Power Corporation) is an
example for DNSNA.
In addition to such a smart grid, other IoT devices including
wearable devices will be configured with their DNS names without running
mDNS.
My folk in IoT industry said that their device can run only part of
IPv6 core specification because of the device's constrained capability.
So he said that DNSNA is preferred over mDNS.
mDNS is good enough for high capability devices (e.g., computers,
smartphones, and appliances) and high-bandwidth networks (e.g., WiFi),
but for constrained IoT devices, which are reluctant to using
multicast, DNSNA may be a solution.
> 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.
>
>> I don't say that my DNSNA is the only solution for IoT devices, but
would say that we IETF need to consider a light-weight DNS naming for
IoT devices in order to deploy IPv6 in the IoT world.
mDNS may be modified for the IoT world, so I will also consider how
to extend mDNS for this new world along with DNSNA.
Thanks for your comments again.
Best Regards,
Mr. Jaehoon Paul Jeong
>
> Stuart Cheshire
>
>
>
[Attachment #5 (text/html)]
<div dir="ltr">Dear Mr. Cheshire,<div>Thanks for your frank thoughts and \
opinions.<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 10, \
2015 at 5:24 AM, Stuart Cheshire <span dir="ltr"><<a \
href="mailto:cheshire@apple.com" target="_blank">cheshire@apple.com</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="word-wrap:break-word"><span class="">On 4 Nov 2015, at 23:14, Mr. Jaehoon Paul \
Jeong <<a href="mailto:jaehoon.paul@gmail.com" \
target="_blank">jaehoon.paul@gmail.com</a>> wrote:<br><br></span><blockquote \
type="cite"><span class="">Device model (denoted as device_model) in my proposed \
DNS<br>name format can let an IoT device refer to the specification<br>of another \
device's functions, assuming that such a<br>device model's specification is \
available publicly.<br><br></span><span class="">For example, for a given \
Samsung's refrigerator model, such<br>as RF4287HARS (28 cu. ft. French Door \
Refrigerator Stainless<br>Steel), we can know the functions with the \
specification.<br>See Samsung's \
refrigerators:<br>h<a>ttp://www.samsung.com/us/support/appliances/refrigerators</a><br></span></blockquote><br>Mr \
Jeong,<br><br>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.<br></div></blockquote><div><br></div><div> \
>> Generally speaking, I tried to address useful comments on the revisions as \
long as I understand, </div><div> such as location privacy for medical \
devices and a DNS name format.</div><div> Refer to the recent draft <a \
href="https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00">https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00</a>.</div><div> \
</div><div> For the location privacy for IoT devices (e.g., medical \
devices and smartphone), </div><div> in Section 8, the location of \
smartphone can be encrypted by a shared key or public/privacy keys.</div><div> \
The device category or model can be encrypted based on my proposed scheme. \
</div><div><br></div><div> For the DNS name format, though this version \
does not have the new format based on Object ID,</div><div> this new name \
format is proposed in the slide 3 in my presentation slides (<a \
href="https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00">https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00</a>)</div><div> \
is proposed. The slides is attached in this email.</div><div> </div><div> \
This new format is based on the standard format of ITU-T and ISO/IEC for an object, \
such as IoT device.</div><div> On the next version of my draft, I will \
reflect this change.</div><div><br></div><div> In this version, the \
following are the new proposed ones:</div><div> - The global DNS name \
autoconfiguration as well as the local DNS name autoconfiguration</div><div> \
(See Section 5.2.2. DNS Name Collection)</div><div><br></div><div> - The \
DNS name management for the mobility of IoT devices</div><div> (See \
Section 7. DNS Name Management for Mobile IoT Devices) </div><div> \
</div><div> I discussed with 6lo folks, IoT software engineers, and IoT \
experts for my proposed schemes.</div><div> They think that though my \
proposed one is a simple implementation extension based on IPv6 ND and NI protocol, \
</div><div> it is efficient in multi-link network in terms of DNS packet \
number and energy consumption because my resolution is based on</div><div> \
unicast rather than the multicast of mDNS. </div><div> </div><div> \
My team at SKKU and Jubix (a startup company in Korea) are working for simulation and \
implementation to compare</div><div> the overhead of mDNS and my proposed \
one (called DNSNA) in terms of DNS packet number and energy consumption </div><div> \
in wireless networks (e.g., 6lo networks).</div><div><br></div><div> We \
have a plan to show the comparison in the next IETF 95 meeting. \
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="word-wrap:break-word"><br>You suggest above that the software running on a \
constrained IoT device should visit the web page you gave, explore the web site \
</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="word-wrap:break-word">to find some document specifying the network \
functionality provided by the refrigerator model, and the network protocol(s) used to \
access </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="word-wrap:break-word">that functionality (I, as a human, was unable to find \
that document myself) and then (presumably via some artificial intelligence \
algorithms) </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="word-wrap:break-word">the constrained IoT device would write itself a protocol \
implementation (and design itself a corresponding user interface) to control the \
refrigerator. </div></blockquote><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="word-wrap:break-word">I don't believe that IoT devices with such artificial \
intelligence capabilities currently exist outside of Hollywood \
movies.<br></div></blockquote><div> </div><div> >> The service discovery, \
which gets information (e.g., services and functions) from other devices, is out of \
scope in our current work.</div><div> Our goal in this draft is to provide \
a simple DNS name generation and registration without any intervention of \
administrators and users. </div><div> </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="word-wrap:break-word"><br>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 </div></blockquote><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="word-wrap:break-word">available for a while. I already have one in my house, \
provided at no charge to me by my local electricity \
company.</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="word-wrap:break-word">This is not some new experimental thing; it's a \
mainstream, widely-used product:</div></blockquote><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="word-wrap:break-word"><div><br><<a \
href="http://www.amazon.com/Rainforest-EAGLE-Ethernet-ZigBee-Gateway/dp/B00AII248U" \
target="_blank">http://www.amazon.com/Rainforest-EAGLE-Ethernet-ZigBee-Gateway/dp/B00AII248U</a>><br><br>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.</div><div><br></div></div></blockquote><div> >> The smart grid \
for KEPCO (Korea Electric Power Corporation) is an example for DNSNA.</div><div> \
In addition to such a smart grid, other IoT devices including wearable devices will \
be configured with their DNS names without running mDNS.</div><div><br></div><div> \
My folk in IoT industry said that their device can run only part of IPv6 core \
specification because of the device's constrained capability.</div><div> \
So he said that DNSNA is preferred over mDNS.</div><div> mDNS is good \
enough for high capability devices (e.g., computers, smartphones, and appliances) and \
high-bandwidth networks (e.g., WiFi), </div><div> but for constrained IoT \
devices, which are reluctant to using multicast, DNSNA may be a solution.</div><div> \
<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="word-wrap:break-word"><div>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, </div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="word-wrap:break-word"><div>rather than just doing the same thing a different \
way.<br></div></div></blockquote><div><br> >> I don't say that my DNSNA \
is the only solution for IoT devices, but would say that we IETF need to consider a \
light-weight DNS naming for</div><div> IoT devices in order to deploy IPv6 \
in the IoT world. </div><div> mDNS may be modified for the IoT world, so \
I will also consider how to extend mDNS for this new world along with \
DNSNA.</div><div><br></div><div> Thanks for your comments \
again.</div><div><br></div><div> Best Regards,</div><div> Mr. \
Jaehoon Paul Jeong</div><div> </div><div> </div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
style="word-wrap:break-word"><div><br>Stuart \
Cheshire<div><br><div><br></div></div></div></div></blockquote></div> \
</div></div></div>
--94eb2c07e590b885c40524398d59--
["DNS-Name-Format.jpg" (image/jpeg)]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic