Re: [homenet] Request for Comments on New Internet Draft for Homenet WG

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Markus,
Here are my answers.

On Fri, Oct 10, 2014 at 5:46 PM, Markus Stenberg <[e-mail]>
wrote:

> On 10.10.2014, at 11.14, Mr. Jaehoon Paul Jeong <[e-mail]>
> wrote:
> > First, as a basic domain, link-local collision domain is assumed,
> > but we can extend it into multiple links (or subnets) naturally
> > if a router can work as a proxy for IPv6 hosts.
> > That is, if a host tries to autoconfigure its DNS name in a subnet and
> > there exists another host with the same DNS name in an adjacent subnet,
> > a router interconnecting these two subnets can responds to the DAD
> > to tell the first host the duplication of the DNS name due to the second
> host.
>
> So let us assume my 4 home router topology I use for testing homenet
> stuff. Does this imply flooding of those ICMPs? Limited by TTL? Something
> else?
>
>      => Since a router collects DNS names of IoT devices in its subnets,
           it limits ICMP messages for Node Information Query to each
subnet.


> (And it starts to look like L2 bridge at some point.)
>
> > Second, our proposed scheme can be used along with mDNS or SSDP
> > for IoT devices (e.g., lamp, door lock, and light sensor) whose capacity
> > cannot afford to run mDNS by itself in terms of memory or processor
> capacity.
> > It those tiny IoT devices with IPv6 stack and stateless
> autoconfiguration functionality,
> > they will be able to support the DNS name services without the
> intervention of a home network administrator.
>
> There are small mdns daemons, and if you do not want full functionality
> (just names), I am sure it could be even smaller.
>
     => Sure mDNS can be implemented lightly. However, my proposal scheme
can be implemented easily with small overhead
          for low-capacity IoT devices.

>
> To provide a service, you have to be discoverable anyway, and that implies
> mdns, ssdp, or something else that _will use IP address_ to contact your
> particular device anyway.
>
     => Once the DNS names of IoT devices are collected by a router, they
are self-explanatory for the service types
          through device category and device model in DNS names.

>
> > At least, Device Name Generation (in Section 5.2.1) can be used to
> generate a DNS name
> > for home network devices or IoT devices that run mDNS or SSDP.
>
> Use of sub-domains in mDNS is not allowed I think, or at least
> implementations behave badly with them. SSDP I cannot remember.
>
> (They are specified to be flatname.local.)
>
    => It seems like you are right in mDNS because .local is the DNS
top-level domain for a link-local scope network.
         However, I believe that my proposed DNS name format (i.e.,
unique_id.device_model.device_category.domain_name)
         can make it easy to perform service discovery by the DNS name
itself without actual network operations.

>
> > Third, for DNSSL, DNS suffixes announced by a router within a home
> network can be restricted
> > to a local domain, such as homenet. Since this can be decided by a local
> policy within a home network,
> > we can eliminate the propagation of ISP DNS suffix into a home network.
>
> This implies MUST just to support this, not ‘can’..
>
     => If my proposal is accepted by IETF, MUST may be used. :-)

>
> And if ISP provides home users with information such as ‘go
> http://coolservice', having it break suddenly sounds like a bad idea.
>
> Cheers,
>
> -Markus



   Thanks for your constructive feedback.

   Regards,
   Paul