Markus, Here are my answers. On Fri, Oct 10, 2014 at 5:46 PM, Markus Stenberg <[email protected]> wrote:
> On 10.10.2014, at 11.14, Mr. Jaehoon Paul Jeong <[email protected]> > 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
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
