Dear Stuart, Thanks for your constructive comments below. I answer your comments in lines.
On Thu, Nov 5, 2015 at 2:51 PM, Stuart Cheshire <chesh...@apple.com> wrote: > On 3 Nov 2015, at 01:51, Mr. Jaehoon Paul Jeong <jaehoon.p...@gmail.com> > wrote: > > > Hi 6man, 6lo and dnsop folks, > > > > There will be a talk about IoT DNS Name Autoconfiguration > > in 6man WG's morning session tomorrow, 11/4/2015. > > > > Title: DNS Name Autoconfiguration for Internet of Things Devices > > https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00 > > This was not actually discussed in 6man, 6lo, or dnsop, so I’ll make some > comments here. > > It’s hard to know where to start. > > Your document confuses device discovery with service discovery. What a > device *is* tells you virtually nothing about what it *does*. The “device > category” of my computer being “laptop” or “tablet” tells you *nothing* > about what services it offers. > >> 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 the device model's specification is available publicly. Of course, we can use service discovery for device functions, such as dnssd. This is the next step in my draft. 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 > > Your document assumes that every search domain your tablet encounters ( > starbucks.com, narita-airport.co.jp, meeting.ietf.org, comcast.com) will > allow your tablet to create global records in that domain. Clearly this is > nonsense. > >> In Section 7 (DNS Name Management for Mobile IoT Devices), https://tools.ietf.org/html/draft-jeong-6man-iot-dns-autoconf-00#section-7, I discuss the mobility issue of an IoT device to receive multiple search domains. Whenever the IoT device recognizes the movement into another subnet, it can delete its DNS names by DNS dynamic update. In reality, in public areas (e.g., starbucks and narita airport), we can disable the automatic DNS name registration in routers because the registration in the public areas makes some privacy issues. We can enable such automatic > > Having put global address records into starbucks.com, your document > assumes then assumes that starbucks.com will then allow you do to a zone > transfer to fetch the entire zone to discover the names of all the other > address records in starbucks.com. Clearly this is nonsense too. > > Your document proposes global address records with names with this form: > > unique_id.device_model.device_category.mic_loc.mac_loc.domain_name. > > For example: > > > jkadjkhdsafhjlsadfjklkljdgajknsadf.Sungkyunkwan-1234.cleaning-robot.right-upper-corner.living-room.comcast.com > . > > The host name of the cleaning robot keeps changing as it moves around the > room, requiring continual updates and continual zone transfers to keep > track of the name as it changes. Clearly this is infeasible. > > I would, however, love to get one of these new flying cleaning robots, > which can be located (as it was in your example), “in the right-upper > corner of a living room.” > > Stuart Cheshire > > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software Sungkyunkwan University Office: +82-31-299-4957 Email: jaehoon.p...@gmail.com, paulje...@skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
