From nobody Sat Nov 1 01:22:05 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5C81A885D for ; Sat, 1 Nov 2014 01:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nhcBqCwineBy for ; Sat, 1 Nov 2014 01:22:02 -0700 (PDT) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 100051A885A for ; Sat, 1 Nov 2014 01:22:01 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id 6F35925CA0C5; Sat, 1 Nov 2014 08:21:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa2xuTuGR8TC; Sat, 1 Nov 2014 09:21:28 +0100 (CET) Received: from kopoli (p5B34173C.dip0.t-ipconnect.de [91.52.23.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 16C0E25CA073; Sat, 1 Nov 2014 09:21:28 +0100 (CET) From: "Hosnieh Rafiee" To: "'Douglas Otis'" , References: In-Reply-To: Date: Sat, 1 Nov 2014 09:21:24 +0100 Message-ID: <000801cff5ac$d3b861d0$7b292570$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIvjAR2/BqqOQ0IW5sobiaVDd+vQpuMQVJg Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/XB9oHlw-Zkj43ME9zV-9CS8nlDw Subject: Re: [dnssd] draft-ietf-dnssd-requirements-04 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Nov 2014 08:22:04 -0000 Hi Douglas, Some parts of that should be in threat model. If you think something is still missing from threat model, you can contribute text and add it. At the moment the threat model only focused on charter and requirement document. Best, Hosnieh > -----Original Message----- > From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Douglas Otis > Sent: Saturday, November 01, 2014 12:59 AM > To: dnssd@ietf.org > Cc: Douglas Otis > Subject: [dnssd] draft-ietf-dnssd-requirements-04 > > Dear dnssd wg, > > The requirements draft still has failed to consider new security considerations > caused by exposing link-local information to adjacent networks. This goes well > beyond being mere unions of mDNS and DNSSD issues. > > One solution might involve use of overlay network addressing, for example. > Without a well considered strategy, no firewall will be able protect local > networks. > > Regards, > Douglas Otis > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Tue Nov 4 13:22:06 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FAB01A000F for ; Tue, 4 Nov 2014 13:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, WEIRD_QUOTING=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oqj5Mcwz43wK for ; Tue, 4 Nov 2014 13:22:04 -0800 (PST) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A3FC1A0012 for ; Tue, 4 Nov 2014 13:22:04 -0800 (PST) Received: by mail-qg0-f42.google.com with SMTP id i50so10406683qgf.1 for ; Tue, 04 Nov 2014 13:22:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=/W4tjk9gDUGPcmIEv+EM8XiloefqJU97cTJQPFT+ewE=; b=ZHL9pZ1mmrFUFU0kJb4KcLiz5QKLcxehC7hu6nWpIIKSADziikIZGXu1ZcxlhrDcvR YniZj2ZvEBq43l3w9oXMsKcdvVudIyGvcOXAyTaMzCTNsxvsJvkFH0oFZBwS/O+SG48z XckCDDRGSzaSkMknXG5/RShueQjjmPEgHPi1ObDsZtotHMdQk5woj+E4owPPefcjoRQK MyJlg9azopVsNzFE5nsXxUxrcKEAfZ+EbxfHNskf0yENEGp0D/nr9tRjDHL6iLTu4VCD nQ4hu+YA+JI61BFSwYaqdOG1vDB4k9B1lKC1SoShK2enKm+yh9dm0MJdsSF0KcDpzfJ4 esbw== X-Received: by 10.229.176.70 with SMTP id bd6mr80503720qcb.12.1415136123282; Tue, 04 Nov 2014 13:22:03 -0800 (PST) Received: from [10.82.101.29] (rtp-isp-nat-pool1-1.cisco.com. [64.102.254.34]) by mx.google.com with ESMTPSA id 15sm1381386qgh.31.2014.11.04.13.22.01 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Nov 2014 13:22:02 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: Date: Tue, 4 Nov 2014 16:22:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <7BBEBE10-CFBD-4EED-9D76-091B34570DBF@gmail.com> References: To: dnssd@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/0tVD6g-tx50iFhY8b9_bKt6WFy0 Subject: Re: [dnssd] Upcoming meeting and call for agenda items X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Nov 2014 21:22:05 -0000 3rd announcement - still looking for volunteers to take notes for = minutes and to act as jabber scribe. Agenda has been updated. =3D=3D=3D=3D=3D The dnssd WG will meet in Hawaii 1300-1500 Thursday, Nov 12. The = following WGs will meet at the same time: lime, netvc, idr, saag, tsvwg Tim Chown won't be in Hawaii, so Andrew Sullivan has once again = graciously agreed to stand in as acting co-chair for the meeting. We are asking for volunteers for taking minutes and Jabber scribe. = Please let me know if you're willing to take on one of those roles. Here is the current draft agenda: dnssd WG Agenda - IETF 91 1300-1500GMT 2014-11-13 (Last revised 2014-11-04 04:15 PM ET) ------------------------------------- Administrivia Droms/Sullivan 10 = minutes Introduction and NoteWell Agenda bashing; blue sheets; scribe; Jabber scribe DNS Long-Lived Queries Pusateri 30 = minutes draft-sekar-dns-llq-01 (expired) Technology review Multicast DNS (mDNS) Threat Model and Security Consideration Rafiee 20 = minutes draft-rafiee-dnssd-mdns-threatmodel-01 Review of updates Special Use Top Level Domain ""home"" Cheshire 15 = minutes draft-cheshire-homenet-dot-home-00 Informational for WG On Interoperation of Labels Between mDNS and DNS Sullivan 20 = minutes draft-sullivan-dnssd-mdns-dns-interop-01 Review of updates = ----------- 95 = minutes Please reply to dnssd-chairs@tools.ietf.org with requests for additional = agenda slots. From nobody Thu Nov 6 07:16:25 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 674E51A88E4 for ; Thu, 6 Nov 2014 07:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBuOUUWn5nhA for ; Thu, 6 Nov 2014 07:16:22 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 203401A88ED for ; Thu, 6 Nov 2014 07:16:22 -0800 (PST) Received: by mail-qg0-f44.google.com with SMTP id q107so860426qgd.31 for ; Thu, 06 Nov 2014 07:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=2qxpOcc3RJRpjD5KMx7SRPvRuikPhJoOOkRm1ZKAzcw=; b=vwC1aBvbusVpS0RCayTNrYDSciGpRGKWp6oSVEK5tas9MduyK1AVwwqwTbWJWzMFhz g1cX8RdDz8a2bLYDr1MdpOnDA4mUyFggbGKE3vTfQqrKNZVCwleXecHW/Tcg3KZ+udrj h8yP0AyIHOu71bRbSwtw/6wTll9Mk00eWx8G7djIeg3RFUke063F6VoWyAIHxqv2f+uR xmV2+DyIzNlYCsqrTJKt5JBkogefTiWhic9QNJO/AWGEouqmPmhtGNaKblhldN33oy5e foceXfX7o9O5u/ZHczY2NrspHHdH4H4neechUS8cqASzPrvU4Wd0PL/EfaKwy90SCO2N doGw== X-Received: by 10.140.101.68 with SMTP id t62mr7286396qge.92.1415286980991; Thu, 06 Nov 2014 07:16:20 -0800 (PST) Received: from ?IPv6:2001:420:2481:20:78f5:66f8:de7:5393? ([2001:420:2481:20:78f5:66f8:de7:5393]) by mx.google.com with ESMTPSA id z9sm6098706qai.19.2014.11.06.07.16.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 06 Nov 2014 07:16:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: Date: Thu, 6 Nov 2014 10:16:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9E0548E3-C221-4C4C-8FB5-BB0470E30782@gmail.com> References: To: dnssd@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/1FZ53rrmfAqVAmgimNr1G_NVHoQ Subject: Re: [dnssd] Upcoming meeting and call for agenda items X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Nov 2014 15:16:23 -0000 Reminder - we're still looking for a volunteer to take notes for = minutes. We'll have the etherpad available so everyone can help out, = but we'll need to have at least one designated responsible adult: = http://tools.ietf.org/wg/dnssd/minutes The agenda has been updated with one additional agenda item: = http://www.ietf.org/proceedings/91/agenda/agenda-91-dnssd If you're on = the agenda, please send your presentation materials to me (PDF = preferred) by Sunday noon so I can post them prior to the WG meeting. - Ralph From nobody Sun Nov 9 01:53:30 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEF431A1A6A for ; Sun, 9 Nov 2014 01:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVLbqyJspEWy for ; Sun, 9 Nov 2014 01:53:27 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3021A1A64 for ; Sun, 9 Nov 2014 01:53:27 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id eu11so6305986pac.37 for ; Sun, 09 Nov 2014 01:53:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=eK+Jf7z6P0pjo/0sfzyYQpzDY7F4SSYPBPn2kNVTm7U=; b=LTMT34144q13dV3xSWjCsnF4rV/UIzKZc16SwHVSD9Uygq+Iu6fuRPDRI6tV7JPc+q NjMO24b9zrn7CX9EHeQ9gT24ToSTDwFB28ORMAoQuaRgYyiPwyKosiYjtKwT+G0wWxBD jpbPoFi2h3fiWltSwBpj3mRJo5wDHpMdPWgt7Z5IgeeRfCtjWdtHN8MIP3pgbAiEKfQo T+AaINUcqHXHo+TZU1gowKJEKN28i54Gl4Rx7bBKW31dMJGbZBSA5qWqgrmkQv9WCYat 9cxnvYZx8btCGJjKM/DO8y4f0DvfoLmUpdAdfkO6NZnHTM1jVTI9qSkq6rfh5YTkEj6k 4BhQ== X-Received: by 10.66.241.239 with SMTP id wl15mr25073905pac.15.1415526806392; Sun, 09 Nov 2014 01:53:26 -0800 (PST) Received: from [192.168.2.110] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id dp3sm13445912pdb.46.2014.11.09.01.53.25 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 09 Nov 2014 01:53:25 -0800 (PST) From: Douglas Otis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 9 Nov 2014 01:53:22 -0800 Message-Id: <5394C917-EDDA-4FDC-8221-1BE9CF1138DA@gmail.com> To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/qMQ8asPYaK6eaKikzfDB9n7p0SA Cc: Hosnieh Rafiee Subject: [dnssd] mDNS Proxy Security Concerns Omitted X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Nov 2014 09:53:28 -0000 Dear Hosnieh, Sorry for the delayed response. As previously discussed on the dnssd = mailing-list and at the last meeting, publishing mDNS information in DNS = removes a level of protection from devices needing isolation from direct = Internet access. Enterprise and modern home networks anticipate multiple = Internet links with configurations unable to propagate mDNS packets or = able to scale multicast within enterprise environments. Nevertheless = publishing routable address in DNS introduces concerns omitted from the = requirements draft. Use of overlay networks permit a safe automatic assignment strategy = offering assured protection for those devices unable to handle direct = Internet access. An overlay network might leverage Unique Local Unicast = Addresses defined by RFC4193 such as FD00::/8. | 7 bits |1| 40 bits | 16 bits | 64 bits = | = +--------+-+-------------+---------------+--------------------------------= ------+ | Prefix |L| Global ID | Subnet ID | Interface ID = | = +--------+-+-------------+---------------+--------------------------------= ------+ There are many devices unable to handle direct Internet access and yet = respond with their routable IP address over mDNS. Printers represent a = large install base where such a problem exists, although some can handle = such access. Most consumer grade routers either allow or disallow all IPv6 incoming = connections. This restriction inhibits use of multiple Internet access = links when initial incoming packets are blocked. Employing an overlay = network that simplifies network boundary conditions allows border = devices to be robust by enabling a lightweight filtering method, as = apposed to use of cryptography, as with VPNs for example. Also, when = bootstrapping an auto configuration process, it is not safe to assume = necessary certificates have been deployed and coordinated by disparate = manufactures when exchanging packets beyond the local network. Regards, Douglas Otis= From nobody Wed Nov 12 20:27:33 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D293A1A1B4D for ; Wed, 12 Nov 2014 20:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y7X97VNcygTo for ; Wed, 12 Nov 2014 20:27:31 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11461A1B4A for ; Wed, 12 Nov 2014 20:27:30 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id r20so7013759wiv.4 for ; Wed, 12 Nov 2014 20:27:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :cc:to; bh=aZmI29ipqKXzE+oK+MvcBcYcqYmsQBCDsj5UrMVW7OE=; b=Y3CfgnPdcDth5bfOx10z+JlKLSvgotkMvuhRst0kk165b+wvjqjO1GLKOdeusRLMql sUanLLOZhl4BwuXbhI18IZo7SoS8tSyexnQDd3nLJk1O2r2FeBmXueWV2IHvPZJRLzMp +wFAHu19i8U2hssjKbADAvWHh2Znx8Hcdo8JxN+/0hDhhqiXdKfxvslyly80RXwQE6+N hmDYP1F9iofR/2LEYY1sQXdsMVL+b5M64ZaVPThoXR2aiX4+N4jYXC5innqBQn63tErg 5EkKCWCEirDUO+DsJOAa5UcB4AQjWdIOPBGHV5Gz32j2FdGrM1OT5KULrYUo6lh0X6Ir F0iQ== X-Received: by 10.194.200.101 with SMTP id jr5mr157265wjc.6.1415852849477; Wed, 12 Nov 2014 20:27:29 -0800 (PST) Received: from t2001067c03700136a4c8f0e80f906626.hotel-wireless.v6.meeting.ietf.org (t2001067c03700136a4c8f0e80f906626.hotel-wireless.v6.meeting.ietf.org. [2001:67c:370:136:a4c8:f0e8:f90:6626]) by mx.google.com with ESMTPSA id v10sm24056229wiy.21.2014.11.12.20.27.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Nov 2014 20:27:28 -0800 (PST) From: Ralph Droms Content-Type: multipart/alternative; boundary="Apple-Mail=_38E472CA-A413-442B-A4FC-B53D092D8989" Message-Id: <7C1D0E1E-D801-465B-8C80-E838A99C7387@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Wed, 12 Nov 2014 18:27:32 -1000 References: To: dnssd@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/vL883jAjusyQcGJNiYwnCfplVNY Cc: dnssd-chairs@tools.ietf.org Subject: [dnssd] Fwd: Request for Timeslot for DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 04:27:33 -0000 --Apple-Mail=_38E472CA-A413-442B-A4FC-B53D092D8989 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii WG - FYI, this document may be of interest. At present, our agenda is almost full ... if we finish our announced = agenda items in time, we will give Paul a few minutes to explain his = draft. - Ralph Begin forwarded message: > From: "Mr. Jaehoon Paul Jeong" > Subject: Request for Timeslot for DNS Name Autoconfiguration for Home = Network Devices > Date: November 12, 2014 at 12:06:10 PM HST > To: Ralph Droms , Tim Chown = > Cc: Ted Lemon , "Mr. Jaehoon Paul Jeong" = >=20 > Hi Ralph and Tim, > This is Paul, the author of RFC 6106: IPv6 Router Advertisement = Options for DNS Configuration. >=20 > This time I proposed a draft about "DNS Name Autoconfiguration for = Home Network Devices (or IoT Devices)". >=20 > The main idea is to let IoT devices autoconfigure their DNS names by = using DNS search list that is advertised by RA or DHCP, and then = register their DNS names into DNS Server via router(s) having the IoT = devices. >=20 > My draft is located at: > = http://datatracker.ietf.org/doc/draft-jeong-homenet-device-name-autoconf/ >=20 > Title: DNS Name Autoconfiguration for Home Network Devices > Abstract: > This document specifies an autoconfiguration scheme for DNS names = of > home network devices. By this scheme, the DNS name of a home = network > device can be autoconfigured with the device's category and model = in > a home network. This DNS name lets home residents easily identify > each device for monitoring and remote-controlling it in a home = network. >=20 > I attach my presentation slides, too. >=20 > I presented my draft at homenet WG today,=20 > but Ted Lemon recommended to me that I present my draft > at your dnssd WG because my draft looks useful to your WG. >=20 > Could you give me a timeslot at the end of your session tomorrow? >=20 > Thanks. >=20 > Paul > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software / > Department of Computer Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Mobile: +82-10-4758-1765 > Fax: +82-31-290-5119 > Email: pauljeong@skku.edu, jaehoon.paul@gmail.com > CPS Lab Website: http://cpslab.skku.edu > Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php >=20 --Apple-Mail=_38E472CA-A413-442B-A4FC-B53D092D8989 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii WG - = FYI, this document may be of interest.

At present, = our agenda is almost full ... if we finish our announced agenda items in = time, we will give Paul a few minutes to explain his = draft.

- = Ralph


Begin forwarded message:

From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
<= /span>
Subject: = Request for = Timeslot for DNS Name Autoconfiguration for Home Network = Devices
Date: = November 12, 2014 at = 12:06:10 PM HST
To: = Ralph Droms <rdroms.ietf@gmail.com>, Tim = Chown <tjc@ecs.soton.ac.uk>
=
Cc: Ted Lemon <ted.lemon@nominum.com>, = "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com>
<= /span>

Hi Ralph and Tim,
This is = Paul, the author of RFC 6106: IPv6 Router Advertisement Options for DNS = Configuration.

This time I proposed a draft = about "DNS Name Autoconfiguration for Home Network Devices (or IoT = Devices)".

The main idea is to let IoT devices = autoconfigure their DNS names by using DNS search list that is = advertised by RA or DHCP, and then register their DNS names into DNS = Server via router(s) having the IoT devices.

My = draft is located at:

Title: DNS Name = Autoconfiguration for Home Network = Devices
Abstract:
   This = document specifies an autoconfiguration scheme for DNS names = of
   home network devices.  By this scheme, = the DNS name of a home network
   device can be = autoconfigured with the device's category and model in
  =  a home network.  This DNS name lets home residents easily = identify
   each device for monitoring and = remote-controlling it in a home = network.

I attach my presentation slides, = too.

I presented my draft at homenet WG = today, 
but Ted Lemon recommended to me that I present my = draft
at your dnssd WG because my draft looks useful to your = WG.

Could you give me a timeslot at the end of = your session = tomorrow?

Thanks.

Paul
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant = Professor
Department of Software /
Department of Computer = Engineering
Sungkyunkwan University
Office: = +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: = +82-31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php
<= /div>


= --Apple-Mail=_38E472CA-A413-442B-A4FC-B53D092D8989-- From nobody Thu Nov 13 11:07:28 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E5F1ACD14; Thu, 13 Nov 2014 11:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPXv4lKr4jkL; Thu, 13 Nov 2014 11:07:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D185B1ACCEF; Thu, 13 Nov 2014 11:05:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141113190502.804.25872.idtracker@ietfa.amsl.com> Date: Thu, 13 Nov 2014 11:05:02 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/-i5XtjILn06uE2jWhL6x1EPQQzI Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-hybrid-00.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 19:07:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Extensions for Scalable DNS Service Discovery Working Group of the IETF. Title : Hybrid Unicast/Multicast DNS-Based Service Discovery Author : Stuart Cheshire Filename : draft-ietf-dnssd-hybrid-00.txt Pages : 19 Date : 2014-11-13 Abstract: Performing DNS-Based Service Discovery using purely link-local Multicast DNS enables discovery of services that are on the local link, but not (without some kind of proxy or similar special support) of services that are outside the local link. Using a very large local link with thousands of hosts improves service discovery, but at the cost of large amounts of multicast traffic. Performing DNS-Based Service Discovery using purely Unicast DNS is more efficient, but requires configuration of DNS Update keys on the devices offering the services, which can be onerous for simple devices like printers and network cameras. Hence a compromise is needed, that provides easy service discovery without requiring either large amounts of multicast traffic or onerous configuration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-hybrid/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnssd-hybrid-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Nov 13 11:55:18 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D0D91ACEC7; Thu, 13 Nov 2014 11:55:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QMP9ZHrmUILi; Thu, 13 Nov 2014 11:55:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E10F91ACEE4; Thu, 13 Nov 2014 11:55:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Tim Chown" To: ted.lemon@nominum.com X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141113195501.32207.21097.idtracker@ietfa.amsl.com> Date: Thu, 13 Nov 2014 11:55:01 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/01hZk3RA2rXZrqOvgYLpMaUi2g0 Cc: dnssd@ietf.org, dnssd-chairs@tools.ietf.org, iesg-secretary@ietf.org, draft-ietf-dnssd-requirements.all@tools.ietf.org, tjc@ecs.soton.ac.uk Subject: [dnssd] Publication has been requested for draft-ietf-dnssd-requirements-04 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 19:55:15 -0000 Tim Chown has requested publication of draft-ietf-dnssd-requirements-04 as Informational on behalf of the DNSSD working group. Please verify the document's state at http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Thu Nov 13 12:07:31 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902DE1ACE43; Thu, 13 Nov 2014 12:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EzTI056zamHO; Thu, 13 Nov 2014 12:07:17 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5D41ACFFC; Thu, 13 Nov 2014 12:07:17 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 79BBEDA01FC; Thu, 13 Nov 2014 20:06:59 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id ED50053E080; Thu, 13 Nov 2014 12:06:46 -0800 (PST) Received: from nat64.meeting.ietf.org (31.130.238.77) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 13 Nov 2014 12:06:46 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <20141113195501.32207.21097.idtracker@ietfa.amsl.com> Date: Thu, 13 Nov 2014 10:06:40 -1000 Content-Transfer-Encoding: quoted-printable Message-ID: <6DE6B09D-A349-43F4-AA6F-81568BC549E2@nominum.com> References: <20141113195501.32207.21097.idtracker@ietfa.amsl.com> To: Tim Chown X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.77] Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/wB-EADbSPiwJPzIbKX21K2PMyyg Cc: dnssd@ietf.org, dnssd-chairs@tools.ietf.org, iesg-secretary@ietf.org, draft-ietf-dnssd-requirements.all@tools.ietf.org Subject: Re: [dnssd] Publication has been requested for draft-ietf-dnssd-requirements-04 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 20:07:26 -0000 On Nov 13, 2014, at 9:55 AM, Tim Chown wrote: > Tim Chown has requested publication of = draft-ietf-dnssd-requirements-04 as Informational on behalf of the DNSSD = working group. Looks like the right thing happened. Thanks! I will read it soon. From nobody Thu Nov 13 13:45:46 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E67EF1AD8D8 for ; Thu, 13 Nov 2014 13:45:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.095 X-Spam-Level: X-Spam-Status: No, score=-15.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CIlxKCJwGewv for ; Thu, 13 Nov 2014 13:45:43 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 584C81AD8CA for ; Thu, 13 Nov 2014 13:45:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=66; q=dns/txt; s=iport; t=1415915143; x=1417124743; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=y0Q7G4kiX7njVhmge1zP6/a2w3x9idqyWgzofHoC9O4=; b=CwnB1nxcaqI7oRGoBFgpCqOvj2xAzVhS/ph2r4Q1GublTUyagxf4Lghs pk7owD8G8JQDfGVTtOL+Y3TtBTYgVZq/v0Sak/Y1VwlR90u338Pyg7ht+ RHqpkZGGoe24vbBv+8rCYap6bD097ZlPWcow+wLqjnhei1JbNy0V24tT5 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAIQlZVStJV2S/2dsb2JhbABbgw6BMdRCgSQWAQEBAQFyC4QJOj8SAT5CHwgEDohG0RsBAQEBAQEBAQEBAQEBAQEBAQEakRSDNIEeBZAWgiSLd5Zng3yCNYEDAQEB X-IronPort-AV: E=Sophos;i="5.07,380,1413244800"; d="scan'208";a="368908758" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP; 13 Nov 2014 21:45:42 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id sADLjgVQ011875 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 13 Nov 2014 21:45:42 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.131]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Thu, 13 Nov 2014 15:45:42 -0600 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: dnssd meeting materials Thread-Index: AQHP/4srCh8JTlFsjEms+B5eMw2hrA== Date: Thu, 13 Nov 2014 21:45:41 +0000 Message-ID: <99D7B5CB-A3D3-4A7B-A464-FC78E338A731@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.244.205] Content-Type: text/plain; charset="us-ascii" Content-ID: <57B8225055BE1A4B861101CC936E18B0@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/OWHocniLqFHgdZy-3bi5h3g9wOA Cc: "dnssd-chairs@tools.ietf.org" , Andrew Sullivan Subject: [dnssd] dnssd meeting materials X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 21:45:45 -0000 ...have been uploaded. Meeting starts at 1300 HST. - Ralph From nobody Thu Nov 13 14:11:12 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9B71ADFC7 for ; Thu, 13 Nov 2014 14:11:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.438 X-Spam-Level: X-Spam-Status: No, score=-0.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_35=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nu1e5N_zVTWy for ; Thu, 13 Nov 2014 14:11:00 -0800 (PST) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E961B1ADFCB for ; Thu, 13 Nov 2014 14:10:59 -0800 (PST) Received: from dhcp-a274.meeting.ietf.org (dhcp-a274.meeting.ietf.org [31.133.162.116]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id E353A12EA for ; Thu, 13 Nov 2014 17:08:24 -0500 (EST) From: Tom Pusateri Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 13 Nov 2014 12:10:55 -1000 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/CmkyqW4NJwPujzVokiFX9dF8z-w Subject: [dnssd] Comments on draft-ietf-dnssd-hybrid-00 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Nov 2014 22:11:04 -0000 Thanks for the new draft. The updates did a good job of clarifying some = areas. There were two issues I brought up on the list regarding the previous = Hybrid Proxy draft that weren't addressed in this update. 1. The Hybrid Proxy needs to respond with an SOA record for LLQ = Discovery. A mention of this plus including recommendations for SOA = response values would be very helpful. Here are the values I'm using: Serial: number of seconds since the epoch (Since this value can change = more than 99 times per day, current conventions for the serial number = don't work.) Expire: 24 hours Refresh: this is probably meaningless in the context of the proxy but = I'll use 2 hours Retry: this is also probably meaningless but I'll use 30 minutes Min TTL: the default negative TTL [RFC 2308] could be used in the = context of the proxy but this isn't clear because the NSEC records are = impossible to proxy for since we don't know all of the records. I'll use = 30 minutes. 2. In section 3.4, it describes the translation of certain record types = that may be required by the hybrid proxy. A unicast query is received by the proxy for _domain._udp.Building = 1.example.com. and a query is sent for _domain._udp.local. to the = appropriate interface and this response is received: q: 1, tc: 0, qd: 0, an: 1, ns: 0, ar: 3, rcode: No Error hypd: rname: _domain._udp.local., rrtype: SRV, rrclass: 1, rrset: 0, = ttl: 120, data: foo.local. hypd: rname: foo.local., rrtype: AAAA, rrclass: 1, rrset: 1, ttl: 120, = data: fe80::2a37:37ff:fe40:4462 hypd: rname: foo.local., rrtype: A, rrclass: 1, rrset: 1, ttl: 120, = data: 198.51.100.1 hypd: rname: foo.local., rrtype: NSEC, rrclass: 1, rrset: 1, ttl: 120, = data: foo.local. A AAAA This response contains a link-local IPv6 address which should be = filtered before the unicast response is generated. Specific mention of rewriting the NSEC bitmap of records present to = remove the AAAA bit could be added to section 3.4 as another example of = necessary data translation. RFC 6762, Section 6.1 states that the Next Domain Name in the RDATA = section is the record's name and name compression is allowed. RFC 3845 = which defines NSEC says name compression is not allowed and the Next = Domain Name is the next name in lexicographical order. But since there is no way for the proxy to know all of the records in = the subdomain since they are discovered dynamically, the NSEC record = should probably just be filtered altogether and never translated. Filtering of NSEC records is not mentioned in this draft. Thanks, Tom From nobody Fri Nov 14 01:50:00 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCED1A87E9 for ; Fri, 14 Nov 2014 01:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xj1S36ZTQrXx for ; Fri, 14 Nov 2014 01:49:56 -0800 (PST) Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB591A87DB for ; Fri, 14 Nov 2014 01:49:56 -0800 (PST) Received: by mail-ig0-f180.google.com with SMTP id h15so1206299igd.7 for ; Fri, 14 Nov 2014 01:49:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Lnz7JGllG8zI13PfM7fOzWW10ESG/T39LgmpAuNKofE=; b=Yd4Yb7hs4C64oHjvgESMYnALaREUf9U7SqMGVHinjhEwRw5XRZeAaY/DqRHp7PVlxv pZhdwYCb/0oqoSkTcKlixwgIRFWHeNkVZiFJPel/WbFsjHhV88g6DcHrbyZPvNYiOIBx xqho48xZitSd0DZnXYS54pYLmGr7KxpHS+qescczemninCjYIdFfmd4+pzAld1Xm/GOH 9tZgWoxJ1KahL4PGKG4IaMWmWlz6YhTIVCzMiVRY0zB5crmPF7XysOlpwHDL5IMdy/6+ xxQpgdcS4tkyoW0PqgW+86BXNtqPV0i5AJUZHbCo2FsEWeIoYOacCwAVzw8GT7lHso+b lsog== MIME-Version: 1.0 X-Received: by 10.107.134.203 with SMTP id q72mr8776557ioi.51.1415958595257; Fri, 14 Nov 2014 01:49:55 -0800 (PST) Received: by 10.64.62.18 with HTTP; Fri, 14 Nov 2014 01:49:55 -0800 (PST) Date: Thu, 13 Nov 2014 23:49:55 -1000 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: dnssd@ietf.org Content-Type: multipart/alternative; boundary=001a113fbbbe1661e10507ce8d5e Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/XXhVfG7fXzpS9NWQ-B6Me118DWA Cc: "Mr. Jaehoon Paul Jeong" , Brian Haberman , Myung-Ki Shin , Ted Lemon , Jung-Soo Park Subject: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 09:49:58 -0000 --001a113fbbbe1661e10507ce8d5e Content-Type: text/plain; charset=UTF-8 Hi dnssg WG folks, This is Paul. Today I presented a new draft for DNS Name Autoconfiguration for Home Network Devices and IoT Devices at the end of dnssg WG session. I would like to get your comments on whether this new topic is worthy of work in our dnssg WG. My problem is how to make IoT devices have their unique DNS names without the intervention or with a minimal intervention of home network users. The draft information is as follows: Title: DNS Name Autoconfiguration for Home Network Devices Draft: http://datatracker.ietf.org/doc/draft-jeong-homenet-device-name-autoconf/ Abstract: This document specifies an autoconfiguration scheme for DNS names of home network devices. By this scheme, the DNS name of a home network device can be autoconfigured with the device's category and model in a home network. This DNS name lets home residents easily identify each device for monitoring and remote-controlling it in a home network. The procedure of DNS name autoconfiguration is as follows: - IoT devices autoconfigure their DNS names by using device information (e.g., device category, vendor name, and model) and a DNS suffix in DNS search list that is advertised by RA or Stateless DHCPv6. - A router then collects the DNS names and IPv6 addresses of IoT devices using Node Information Protocol. - After this DNS name collection, the router registers the pairs of DNS names and IPv6 addresses of the IoT devices into a DNS Server using DNS dynamic update. Once we agree on the usefulness of this draft, we can start to discuss the DNS name format and the autoconfiguration procedure based on this draft along with some assumptions, such as the trust model between a router and devices for DNS name registration. Thanks for your comments in advance. Paul =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php --001a113fbbbe1661e10507ce8d5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi dnssg WG folks,
This is Paul.

<= div>
Today I presented a new draft for=C2=A0DNS Name Autoconfiguration = for=C2=A0
Home Network Devices and IoT Devices at the end of dnss= g WG session.
I would like to get your comments on whether this n= ew topic is worthy of work=C2=A0
in our dnssg WG.

My problem is how to make IoT devices have their unique DNS= names=C2=A0
without the intervention or with a minimal intervent= ion of home network users.

The draft information i= s as follows:
Title: DNS Name Autoconfiguration for Hom= e Network Devices

<= br>
Abstract:
=C2=A0 =C2=A0This document specifies an a= utoconfiguration scheme for DNS names of
=C2=A0 =C2=A0home networ= k devices.=C2=A0 By this scheme, the DNS name of a home network
= =C2=A0 =C2=A0device can be autoconfigured with the device's category an= d model in
=C2=A0 =C2=A0a home network.=C2=A0 This DNS name lets = home residents easily identify
=C2=A0 =C2=A0each device for monit= oring and remote-controlling it in a home network.
The procedure of DNS name autoconfiguration is as follows:
- IoT devices autoconfigure their DNS names by using device informat= ion=C2=A0
=C2=A0 (e.g., device category, vendor name, and model) = and a DNS suffix in DNS search list=C2=A0
=C2=A0 that is advertis= ed by RA or Stateless DHCPv6.

- A router then= collects the DNS names and IPv6 addresses of IoT devices=C2=A0
= =C2=A0 using Node Information Protocol.

- After th= is DNS name collection, the router registers the pairs of DNS names and=C2= =A0
=C2=A0 IPv6 addresses of the IoT devices into a DNS Server us= ing DNS dynamic update.

Once we agree on the usefu= lness of this draft, we can start to discuss the DNS name format=C2=A0
and the autoconfiguration procedure based on this draft along with so= me assumptions, such as
the trust model between a router and devi= ces for DNS name registration.

Thanks for your com= ments in advance.

Paul
=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. J= aehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software= /
Department of Computer Engineering
Sungkyunkwan University
Offi= ce: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
= Email: pauljeong@sk= ku.edu, jae= hoon.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: h= ttp://cpslab.skku.edu/people-jaehoon-jeong.php
--001a113fbbbe1661e10507ce8d5e-- From nobody Fri Nov 14 01:52:36 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7263A1A8828 for ; Fri, 14 Nov 2014 01:52:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a0so2UmW7t-N for ; Fri, 14 Nov 2014 01:52:29 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D0D81A878E for ; Fri, 14 Nov 2014 01:52:26 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id hl2so1223387igb.4 for ; Fri, 14 Nov 2014 01:52:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9lgT7szJjUeumr/Rh2djldw/1H6Fd5sHCrNg6GpwypA=; b=qYFFKIq5PfCodvOPWXVQsrl4kk2OhLtueI9q6op3fZRdDKTwcYuZECzKr1B8SiwjuA 7ILKoHOoCA4BaCa+zGR0NTq/XZe9G4EN4Wc/av/oxml6bb+TGsA+cAw5Ha0RI/8q+er5 msdMiB3oUVN7/3oB0CTtySc4Uw3K87BuYxAgWf1ynjHQSu9mnf8JlsWE6VKs7BrMcuiS lIFPgW/OwqzUIbV2F911Gtur6S3Zr7WAeyrDPYPrOXtH9KOHrmvx9nKVa7L6132Wby6f VUNhoNPzfHAOJoHKvXzNjn+luMsFNYvB9QfXoyt9b8lB5nBgrMgKoIdFHmJ2uSfmnyDO qsDw== MIME-Version: 1.0 X-Received: by 10.51.16.37 with SMTP id ft5mr4832035igd.6.1415958744953; Fri, 14 Nov 2014 01:52:24 -0800 (PST) Received: by 10.64.62.18 with HTTP; Fri, 14 Nov 2014 01:52:24 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Nov 2014 23:52:24 -1000 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: dnssd@ietf.org Content-Type: multipart/alternative; boundary=001a1136024002d0790507ce96fd Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/2sgKsLU42NclVQ3BL9qssC8X4YM Cc: "Mr. Jaehoon Paul Jeong" , Brian Haberman , Myung-Ki Shin , Ted Lemon , Jung-Soo Park Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 09:52:31 -0000 --001a1136024002d0790507ce96fd Content-Type: text/plain; charset=UTF-8 Hi all, There is a typo on dnssd :-) Thanks. Paul =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Thu, Nov 13, 2014 at 11:49 PM, Mr. Jaehoon Paul Jeong < jaehoon.paul@gmail.com> wrote: > Hi dnssg WG folks, > This is Paul. > > Today I presented a new draft for DNS Name Autoconfiguration for > Home Network Devices and IoT Devices at the end of dnssg WG session. > I would like to get your comments on whether this new topic is worthy of > work > in our dnssg WG. > > My problem is how to make IoT devices have their unique DNS names > without the intervention or with a minimal intervention of home network > users. > > The draft information is as follows: > Title: DNS Name Autoconfiguration for Home Network Devices > > Draft: > http://datatracker.ietf.org/doc/draft-jeong-homenet-device-name-autoconf/ > > Abstract: > This document specifies an autoconfiguration scheme for DNS names of > home network devices. By this scheme, the DNS name of a home network > device can be autoconfigured with the device's category and model in > a home network. This DNS name lets home residents easily identify > each device for monitoring and remote-controlling it in a home network. > > The procedure of DNS name autoconfiguration is as follows: > - IoT devices autoconfigure their DNS names by using device information > (e.g., device category, vendor name, and model) and a DNS suffix in DNS > search list > that is advertised by RA or Stateless DHCPv6. > > - A router then collects the DNS names and IPv6 addresses of IoT devices > using Node Information Protocol. > > - After this DNS name collection, the router registers the pairs of DNS > names and > IPv6 addresses of the IoT devices into a DNS Server using DNS dynamic > update. > > Once we agree on the usefulness of this draft, we can start to discuss the > DNS name format > and the autoconfiguration procedure based on this draft along with some > assumptions, such as > the trust model between a router and devices for DNS name registration. > > Thanks for your comments in advance. > > Paul > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software / > Department of Computer Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Mobile: +82-10-4758-1765 > Fax: +82-31-290-5119 > Email: pauljeong@skku.edu, jaehoon.paul@gmail.com > CPS Lab Website: http://cpslab.skku.edu > Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php > --001a1136024002d0790507ce96fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,
There is a typo on dnssd :-)
<= div>
Thanks.

Paul

<= div dir=3D"ltr">=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Pr= ofessor
Department of Software /
Department of Computer EngineeringSungkyunkwan University
Office: +82-31-299-4957
Mobile: +82-10-4758= -1765
Fax: +82-31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmail.com
CPS Lab Website= : http://cpslab.skku.e= du
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong= .php

On Thu, Nov 13, 2014 at 11:49 PM, Mr. Jaehoo= n Paul Jeong <jaehoon.paul@gmail.com> wrote:
Hi dnssg WG folks,
This is Pau= l.

Today I presented a new draft for=C2=A0DNS= Name Autoconfiguration for=C2=A0
Home Network Devices and IoT De= vices at the end of dnssg WG session.
I would like to get your co= mments on whether this new topic is worthy of work=C2=A0
in our d= nssg WG.

My problem is how to make IoT devic= es have their unique DNS names=C2=A0
without the intervention or = with a minimal intervention of home network users.

The draft information is as follows:
Title: DNS Name A= utoconfiguration for Home Network Devices

Draft: <= a href=3D"http://datatracker.ietf.org/doc/draft-jeong-homenet-device-name-a= utoconf/" target=3D"_blank">http://datatracker.ietf.org/doc/draft-jeong-hom= enet-device-name-autoconf/

Abstract:
=C2=A0 =C2=A0This document specifies an autoconfiguration scheme for DNS n= ames of
=C2=A0 =C2=A0home network devices.=C2=A0 By this scheme, = the DNS name of a home network
=C2=A0 =C2=A0device can be autocon= figured with the device's category and model in
=C2=A0 =C2=A0= a home network.=C2=A0 This DNS name lets home residents easily identify
=C2=A0 =C2=A0each device for monitoring and remote-controlling it in= a home network.

The procedure of DNS = name autoconfiguration is as follows:
- IoT devices autoconfigure= their DNS names by using device information=C2=A0
=C2=A0 (e.g., = device category, vendor name, and model) and a DNS suffix in DNS search lis= t=C2=A0
=C2=A0 that is advertised by RA or Stateless DHCPv6.

- A router then collects the DNS names and IPv6 a= ddresses of IoT devices=C2=A0
=C2=A0 using Node Information Proto= col.

- After this DNS name collection, the router = registers the pairs of DNS names and=C2=A0
=C2=A0 IPv6 addresses = of the IoT devices into a DNS Server using DNS dynamic update.
Once we agree on the usefulness of this draft, we can start to= discuss the DNS name format=C2=A0
and the autoconfiguration proc= edure based on this draft along with some assumptions, such as
th= e trust model between a router and devices for DNS name registration.
=

Thanks for your comments in advance.

Paul
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Departme= nt of Software /
Department of Computer Engineering
Sungkyunkwan Univ= ersity
Office: +82-31-299-4957
Mobile: +82-10-4758-1765
= Fax: +82-31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php<= /a>

--001a1136024002d0790507ce96fd-- From nobody Fri Nov 14 07:09:00 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF24A1A1A6D for ; Fri, 14 Nov 2014 07:08:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.795 X-Spam-Level: X-Spam-Status: No, score=-4.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLGk9etTqIXR for ; Fri, 14 Nov 2014 07:08:53 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30271A19F5 for ; Fri, 14 Nov 2014 07:08:52 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml405-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BOU30026; Fri, 14 Nov 2014 15:08:51 +0000 (GMT) Received: from LHREML513-MBB.china.huawei.com ([fe80::b810:863:a57e:3ff]) by lhreml405-hub.china.huawei.com ([10.201.5.242]) with mapi id 14.03.0158.001; Fri, 14 Nov 2014 15:08:47 +0000 From: Hosnieh Rafiee To: "dnssd@ietf.org" Thread-Topic: Threat model - answer to questions Thread-Index: AdAAHOI1IabjPMLgS8G9/moucSe3Jg== Date: Fri, 14 Nov 2014 15:08:46 +0000 Message-ID: <814D0BFB77D95844A01CA29B44CBF8A7A5E576@lhreml513-mbb.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.221.82.100] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/b56f42hPXSaDrLXfhT_z6xnWJ6A Subject: [dnssd] Threat model - answer to questions X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 15:08:59 -0000 All, Thanks folks for taking your time to listen to my presentation. I do not kn= ow how was the quality. Since on my side I didn't see any face to react bas= ed on the faces of people. Probably if I was onsite and I could see the fac= es with big question mark during presenting the tables, I could clarify eve= rything.=20 I would like to answer some of unanswered questions/comments that raised du= ring my presentation and any aspects that confused folks.=20 (The names might not be accurate as I might confused the discussion of one = person with another)=20 1- There was discussion about privacy in local links (I think raised by Dav= e) Answer: I agree that privacy in general is really important. What I wanted = to point out during my presentation by my (confusing table) was that for DN= S-SD when the scope is only local link ,privacy might not be a big issue be= cause - service provider (a printer) needs to publicly advertise its service ins= ide the local link. Nothing can be hide without this multicast or broadcast= messages In other word, service provider cannot hide any information=20 - MAC addresses are also known to other nodes and hiding any IP address or= names of service providers does not much help to increase privacy in local= link. But this might be a big issue if the scope is larger and we are talk= ing the privacy inside enterprise network consisting on several local link. 2- DNSSD uses both unicast DNS and multicast DNS (I think raised by Cheshir= e)=20 Answer: This is true. In first slide I explained the differences of unicast= DNS with DNS-SD. Therefore I only talked about sending multicast messages In second slide I discussed about the similarities of these two. Therefore,= I only talked about both sending unicast messages. This was also as a part= of slides' title. If I passed on it very quickly then someone should ask m= e to slow down as I received no feedback during presentation :-| and could = not see your faces to know when I should explain something more or when I s= hould just skip a slide. 3- Why we need to compare unicast DNS with DNSSD? (I think raised by Cheshi= re) Answer: The comparison is just because to find out the threat scope. As fol= ks already know, there are lists of known threats that is applicable to uni= cast DNS. When there is any similarities between the FUNCTIONS of two proto= cols, all of these threats can be applicable to DNSSD the same way as it is= applicable to unicast DNS. Then there is possibility to check the current = available mechanisms and check to see whether with current requirements tha= t exist in DNSSD, whether or not we need another security mechanism or whet= her or not we need to any extension to current available security mechanism= or whether or not we can use them as it is. =20 4- Not agree that DNSSEC cannot be in solution space (Dave) Answer: I just explained in the draft it cannot be a solution space when we= are talking about zero configuration or plug and play solutions or minimal= configuration. If you are also talking about DANE + DNSSEC, the list of tr= usted anchors need to be introduced to your clients and also service advert= iser (that I called it service provider). IMO this is not minimum configur= ation. Since it is a requirement for each single nodes. This is almost not = feasible for public wireless networks. There might be different ways to pro= pagate this trusted lists to all nodes but probably there are other require= ments such as all nodes are inside one ADs domains or subdomains.=20 But configuration of middle boxes, routers and switches, IMO, is considered= minimal configuration since it is only limited to certain number of device= s. It is also possible to simplify this if the network supports software de= fined networking (SDN) based approaches as I explained in my last slide but= as a new use case for SSD. However It can be also a helpful solution for m= inimum configuration.=20 Any thought? 5- overlay networks and SSD (Douglas) Answer: I still do not understand what is the relationship of overlay netwo= rks to SSD. This was the case I did not know what to answer to your questio= n. Why should we consider this? What will happen if we do not consider this= ? 6- what is the relationship between spoofing and privacy (Dave) Answer: the rows in the table did not have any relationship to eachother. I= just used the rows to separate two different threats in one column but it = was nothing to do with the relationship of, e.g., group of threats in colu= mn 1 row 1 to column 3 row 1. I guess I had to remove the lines between row= s so that people did not have this misinterpretation of my tables. I only h= ad 3 groups (each in one columns) that the first group of threats was share= d between both, e.g., SSD and DNS-SD. One was only specific to DNS-SD and t= he last one was specific to SSD. This is also true for other table, i.e, un= icast DNS vs DNS-SD. Please share your thoughts. Thanks, Best, Hosnieh From nobody Fri Nov 14 11:40:30 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB651A8AC4 for ; Fri, 14 Nov 2014 11:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0hQjBa_d2E3 for ; Fri, 14 Nov 2014 11:40:26 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEEC31A00E1 for ; Fri, 14 Nov 2014 11:40:25 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 07A0FDA0220 for ; Fri, 14 Nov 2014 19:40:14 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id C5F0F53E077; Fri, 14 Nov 2014 11:39:55 -0800 (PST) Received: from dhcp-b655.meeting.ietf.org (31.133.182.85) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 14 Nov 2014 11:39:55 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Fri, 14 Nov 2014 09:39:49 -1000 Content-Transfer-Encoding: quoted-printable Message-ID: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> References: To: "Mr. Jaehoon Paul Jeong" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.133.182.85] Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/IKS_DxDS7tK0fEWTagDBNLeQHtc Cc: dnssd@ietf.org, Jung-Soo Park , Brian Haberman , Myung-Ki Shin Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 19:40:28 -0000 On Nov 13, 2014, at 11:49 PM, Mr. Jaehoon Paul Jeong = wrote: > My problem is how to make IoT devices have their unique DNS names=20 > without the intervention or with a minimal intervention of home = network users. RFC 6762 section 9 explains how to do this without operator = intervention. I presume that you do not find the solution given in = 6762 good enough for your specific use case. Can you explain why it = isn't good enough--why something better is needed? From nobody Fri Nov 14 13:34:20 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B833D1ACE3C for ; Fri, 14 Nov 2014 13:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5SUqbgrhxTKl for ; Fri, 14 Nov 2014 13:34:06 -0800 (PST) Received: from mail-ig0-x233.google.com (mail-ig0-x233.google.com [IPv6:2607:f8b0:4001:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA58B1ACE37 for ; Fri, 14 Nov 2014 13:34:06 -0800 (PST) Received: by mail-ig0-f179.google.com with SMTP id r10so2241600igi.12 for ; Fri, 14 Nov 2014 13:34:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mN6Ec7u+dK87HHhLUosUVq7UvsT+Qr4mOj01vlEEeGs=; b=Ypk2ZXLPEP5tDbF+skF6pkHIj9+OSETM20hqC27RrdjXVSjuP4zAmD8UOIoi2o+cXs XbirsgcD929fM/sU8UeGMUy9yoxMgIIiXDK3oTQ5rfErPLJRJ1KDVHkxa+qouGH0ONID xAHoPLPbOy3TygmQIRx71Ia3oipJgHy/gDUZNzX5XXKEGSJdkPfVAYXR3B3TfYITvBpT gVCKcodAE+WdD2pqB4EI5gIvBsabhrzk8XkBUvOac7PcJVatXVih3bPg8yRsLB+ncl1L UA/miKNQ1YcwGjG+JCT1FHDHXMJb0VMVmWlt+eoE0yE7kKU70lTpUI6aPvbU25msg+l6 sV9w== MIME-Version: 1.0 X-Received: by 10.107.156.131 with SMTP id f125mr13180747ioe.15.1416000845806; Fri, 14 Nov 2014 13:34:05 -0800 (PST) Received: by 10.64.62.18 with HTTP; Fri, 14 Nov 2014 13:34:05 -0800 (PST) In-Reply-To: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> Date: Fri, 14 Nov 2014 11:34:05 -1000 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: Ted Lemon Content-Type: multipart/alternative; boundary=001a1140c8d86a853f0507d8638d Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/Gt6520qHGBEt_B3OEmmFtErTNJE Cc: dnssd@ietf.org, Jung-Soo Park , Brian Haberman , Myung-Ki Shin Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 21:34:09 -0000 --001a1140c8d86a853f0507d8638d Content-Type: text/plain; charset=UTF-8 Ted, The solution in RFC 6762 (Multicast DNS) section 9 is viable for regular computers, such as laptop, desktop, and smartphone that can afford to run mDNS responder. For IoT devices, such as light bulb and fire detecting sensor, that have limited memory and storage, mDNS seems not viable for the DNS naming for them. For IoT devices, IETF is working for 6lo for the light interface with IPv6 layer. In this context, my proposal is based on IPv6 neighbor discovery, so it will be a viable option for the DNS name service of IoT devices. For the regeneration and verification of a unique DNS name under DNS name conflict, the solution in RFC 6762 recommends to use an incremental digit (such as 2, 3, 4, etc.) by trial and error. In an IoT scenario where there will be many IoT devices of the same type, such as light bulb in home or hotel here, this incremental numbering approach will be costly and slow to let each IoT device have a unique DNS name, especially in a multi-subset network. My proposal (not included in my current draft yet) is that the router will join the "multicast addresses for IoT devices" as a proxy for DNS name conflict detector in the home network whose DNS names are registered in a DNS server in the home network. Thanks for your good feedback. Paul =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Fri, Nov 14, 2014 at 9:39 AM, Ted Lemon wrote: > On Nov 13, 2014, at 11:49 PM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > > My problem is how to make IoT devices have their unique DNS names > > without the intervention or with a minimal intervention of home network > users. > > RFC 6762 section 9 explains how to do this without operator intervention. > I presume that you do not find the solution given in 6762 good enough for > your specific use case. Can you explain why it isn't good enough--why > something better is needed? > > > --001a1140c8d86a853f0507d8638d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ted,
The solution in RFC 6762 (Multicast DNS) section = 9 is viable for regular computers,=C2=A0
such as laptop, desktop,= and smartphone that can afford to run mDNS responder.
For IoT de= vices, such as light bulb and fire detecting sensor, that have limited memo= ry and storage,
mDNS seems not viable for the DNS naming for them= .

For IoT devices, IETF is working for 6lo for the= light interface with IPv6 layer.
In this context, my proposal is= based on IPv6 neighbor discovery, so it will be a viable option for
<= div>the DNS name service of IoT devices.

For the r= egeneration and verification of a unique DNS name under DNS name conflict,<= /div>
the solution in RFC 6762 recommends to use an incremental digit (= such as 2, 3, 4, etc.) by trial and error.
In an IoT scenario whe= re there will be many IoT devices of the same type, such as light bulb in h= ome or hotel here,
this incremental numbering approach will be co= stly and slow to let each IoT device have a unique DNS name,
espe= cially in a multi-subset network.

My proposal (not= included in my current draft yet) is that the router will join the "m= ulticast addresses for IoT devices" as=C2=A0
a proxy for DNS= name conflict detector in the home network whose DNS names are registered = in a DNS server=C2=A0
in the home network.

Thanks for your good feedback.

Paul
<= br>


=
On Fri, Nov 14, 2014 at 9:39 AM, Ted Lemon <= span dir=3D"ltr"><Ted.Lemon@nominum.com> wrote:
On Nov 13, 2014, at 11:49 PM, Mr. Jaehoon Paul Jeo= ng <jaehoon.paul@gmail.com= > wrote:
> My problem is how to make IoT devices have their unique DNS names
> without the intervention or with a minimal intervention of home networ= k users.

RFC 6762 section 9 explains how to do this without operator interven= tion.=C2=A0 =C2=A0I presume that you do not find the solution given in 6762= good enough for your specific use case.=C2=A0 =C2=A0Can you explain why it= isn't good enough--why something better is needed?



--001a1140c8d86a853f0507d8638d-- From nobody Fri Nov 14 14:00:11 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51ED81ACECF for ; Fri, 14 Nov 2014 14:00:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.902 X-Spam-Level: X-Spam-Status: No, score=-101.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6E7EQdIZYVL for ; Fri, 14 Nov 2014 14:00:07 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0711.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:711]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28D0E1ACECE for ; Fri, 14 Nov 2014 14:00:07 -0800 (PST) Received: from BY2PR03MB412.namprd03.prod.outlook.com (10.141.141.25) by BY2PR03MB410.namprd03.prod.outlook.com (10.141.141.16) with Microsoft SMTP Server (TLS) id 15.1.11.14; Fri, 14 Nov 2014 21:59:44 +0000 Received: from BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) by BY2PR03MB412.namprd03.prod.outlook.com ([10.141.141.25]) with mapi id 15.01.0011.000; Fri, 14 Nov 2014 21:59:44 +0000 From: Dave Thaler To: "Mr. Jaehoon Paul Jeong" , Ted Lemon Thread-Topic: [dnssd] DNS Name Autoconfiguration for Home Network Devices Thread-Index: AQHP//BdbIlYWo1W40+HoQ6kr/OanJxghaCAgAAf7YCAAAG9AA== Date: Fri, 14 Nov 2014 21:59:44 +0000 Message-ID: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [31.133.166.252] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB410; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB410; x-forefront-prvs: 03950F25EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(189002)(51884002)(24454002)(33646002)(76576001)(99396003)(2656002)(74316001)(20776003)(64706001)(97736003)(122556002)(21056001)(40100003)(101416001)(87936001)(66066001)(120916001)(4396001)(107046002)(76176999)(54356999)(50986999)(86362001)(99286002)(105586002)(62966003)(31966008)(86612001)(95666004)(108616004)(106356001)(92566001)(106116001)(77156002)(46102003)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB410; H:BY2PR03MB412.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/wBMlnrm7HQvLIokGQ1iXm9N6Gb4 Cc: "dnssd@ietf.org" , Myung-Ki Shin , Brian Haberman , Jung-Soo Park Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 22:00:09 -0000 UGF1bCB3cm90ZToNCj4gRm9yIHRoZSByZWdlbmVyYXRpb24gYW5kIHZlcmlmaWNhdGlvbiBvZiBh IHVuaXF1ZSBETlMgbmFtZSB1bmRlciBETlMgbmFtZSBjb25mbGljdCwNCj4gdGhlIHNvbHV0aW9u IGluIFJGQyA2NzYyIHJlY29tbWVuZHMgdG8gdXNlIGFuIGluY3JlbWVudGFsIGRpZ2l0IChzdWNo IGFzIDIsIDMsIDQsIGV0Yy4pDQo+IGJ5IHRyaWFsIGFuZCBlcnJvci4gSW4gYW4gSW9UIHNjZW5h cmlvIHdoZXJlIHRoZXJlIHdpbGwgYmUgbWFueSBJb1QgZGV2aWNlcyBvZiB0aGUgc2FtZQ0KPiB0 eXBlLCBzdWNoIGFzIGxpZ2h0IGJ1bGIgaW4gaG9tZSBvciBob3RlbCBoZXJlLCB0aGlzIGluY3Jl bWVudGFsIG51bWJlcmluZyBhcHByb2FjaA0KPiB3aWxsIGJlIGNvc3RseSBhbmQgc2xvdyB0byBs ZXQgZWFjaCBJb1QgZGV2aWNlIGhhdmUgYSB1bmlxdWUgRE5TIG5hbWUsIC4uLg0KDQpNeSByZWFk aW5nIGlzIHRoYXQgUkZDIDY3NjIgZG9lcyBub3QgX3JlcXVpcmVfIGFuIGluY3JlbWVudGFsIGRp Z2l0LiAgWW91IGNhbiBwdXQgaW4NCmEgcmFuZG9tIElEIG9yIE1BQy1kZXJpdmVkIElEIG9yIHNv bWV0aGluZyBlbHNlIGhpZ2hseSB1bmxpa2VseSB0byBjb2xsaWRlLg0KQXMgc3VjaCwgaXQgc2hv dWxkIG5vdCBiZSAiY29zdGx5IGFuZCBzbG93Ii4gIEluZGVlZCBSRkMgNjc2MiBkb2VzIG5vdCBz cGVjaWZ5IHdoYXQNCnlvdSBoYXZlIHRvIGRvLiAgIFdvdWxkIGl0IGJlIHBvc3NpYmxlIHRvIHJl Y2FzdCB5b3VyIGRyYWZ0IGFzDQoiaG93IHRvIGNob29zZSBhIHVuaXF1ZSBJRCBhbmQgdXNlIFJG QyA2NzYyIiA/IA0KDQotRGF2ZQ0K From nobody Fri Nov 14 14:02:32 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AE3D1ACEDD for ; Fri, 14 Nov 2014 14:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMCwb4LY1q3n for ; Fri, 14 Nov 2014 14:02:29 -0800 (PST) Received: from polaris.istumbler.net (polaris.istumbler.net [66.116.108.178]) by ietfa.amsl.com (Postfix) with ESMTP id EEE371ACED0 for ; Fri, 14 Nov 2014 14:02:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by polaris.istumbler.net (Postfix) with ESMTP id 86D3D304EAD9; Fri, 14 Nov 2014 14:02:30 -0800 (PST) X-Virus-Scanned: amavisd-new at example.com Received: from polaris.istumbler.net ([127.0.0.1]) by localhost (polaris.istumbler.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1VdAIlq3UArS; Fri, 14 Nov 2014 14:02:30 -0800 (PST) Received: from [10.0.1.10] (c-67-180-62-35.hsd1.ca.comcast.net [67.180.62.35]) by polaris.istumbler.net (Postfix) with ESMTPSA id D9B81304EAC0; Fri, 14 Nov 2014 14:02:29 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_F6F01A6F-4816-4E71-AED3-4E57ADBC9C5B" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Alf Watt In-Reply-To: Date: Fri, 14 Nov 2014 14:02:27 -0800 Message-Id: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> To: "Mr. Jaehoon Paul Jeong" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/egPy9boIUW0RftdKIhoteAgsnbo Cc: dnssd@ietf.org, Myung-Ki Shin , Ted Lemon , Brian Haberman , Jung-Soo Park Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 22:02:30 -0000 --Apple-Mail=_F6F01A6F-4816-4E71-AED3-4E57ADBC9C5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99m confused, the mDNSResponder code is very lightweight and = already runs on embedded devices such as printers, cameras and may other = low-memory and low-cpu devices. What is your target memory and cpu size for an IoT device? Given that = we=E2=80=99ve been using mDNS for more than a decade, the steady pace of = improvement in semiconductors means that even the smallest device will = have more than sufficient resources for mMDS. Best, Alf > On Nov 14, 2014, at 1:34 PM, Mr. Jaehoon Paul Jeong = wrote: >=20 > The solution in RFC 6762 (Multicast DNS) section 9 is viable for = regular computers,=20 > such as laptop, desktop, and smartphone that can afford to run mDNS = responder. > For IoT devices, such as light bulb and fire detecting sensor, that = have limited memory and storage, > mDNS seems not viable for the DNS naming for them. >=20 --Apple-Mail=_F6F01A6F-4816-4E71-AED3-4E57ADBC9C5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99m confused, the mDNSResponder code is very = lightweight and already runs on embedded devices such as printers, = cameras and may other low-memory and low-cpu devices.

What is your target memory and cpu size = for an IoT device? Given that we=E2=80=99ve been using mDNS for more = than a decade, the steady pace of improvement in semiconductors means = that even the smallest device will have more than sufficient resources = for mMDS.

Best,
Alf

On = Nov 14, 2014, at 1:34 PM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:

The solution in RFC = 6762 (Multicast DNS) section 9 is viable for regular = computers, 
such as laptop, desktop, and smartphone that can afford to = run mDNS responder.
For IoT devices, such as light bulb and fire detecting = sensor, that have limited memory and storage,
mDNS seems not viable = for the DNS naming for them.


= --Apple-Mail=_F6F01A6F-4816-4E71-AED3-4E57ADBC9C5B-- From nobody Fri Nov 14 14:17:37 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29BD1ACFB0 for ; Fri, 14 Nov 2014 14:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id amzjIlOlEYat for ; Fri, 14 Nov 2014 14:17:25 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBB01ACFAF for ; Fri, 14 Nov 2014 14:17:25 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id CD65FDA0222 for ; Fri, 14 Nov 2014 22:17:13 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id D7BCF53E07D; Fri, 14 Nov 2014 14:16:54 -0800 (PST) Received: from nat64.meeting.ietf.org (31.130.238.151) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 14 Nov 2014 14:16:54 -0800 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Fri, 14 Nov 2014 12:16:47 -1000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> To: Alf Watt X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [31.130.238.151] Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/M-MjHQoR6vJKPhg8QDq_EgZ_gRc Cc: dnssd@ietf.org, Myung-Ki Shin , "Mr. Jaehoon Paul Jeong" , Brian Haberman , Jung-Soo Park Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Nov 2014 22:17:30 -0000 On Nov 14, 2014, at 12:02 PM, Alf Watt wrote: > I=92m confused, the mDNSResponder code is very lightweight and already = runs on embedded devices such as printers, cameras and may other = low-memory and low-cpu devices. The issue for lln devices is often battery capacity. From nobody Fri Nov 14 17:11:00 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F181AD4B7 for ; Fri, 14 Nov 2014 17:10:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.451 X-Spam-Level: X-Spam-Status: No, score=0.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbz4rBt4h27g for ; Fri, 14 Nov 2014 17:10:52 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB34E1A1A46 for ; Fri, 14 Nov 2014 17:10:52 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id x19so19041674ier.33 for ; Fri, 14 Nov 2014 17:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IVoEX6dbLtJE5YzVdBySY6uh/Ew61+dRt8l/2ecXT98=; b=SX76G677o329W5Iw41Q1l3IONZONFw+CcDdnqyhdqkZfvqpk6Oue+SORkPgr9kMSHy IVzbn4+LoRjI3b7ticBFA4W13psvaNpVcSj6TrNV5WO8oeawngv7Eh9wNL8PZKW+eTFq 4PdXr/L9rTJSafPtAzoW5oidXXj2bJc1khG+fymtY6FAlOpCMstH2Tk0ISkRhsGm4GTU NuJp4Et0sNGHaA15Yp9AfX/lrTFDmD0jHbY2UVOvGqXDnaK5jxSCaOZFmzPVMFjlr51U alVJJh+Dmw8vPTv6BurUZw8f/PUQqr6D9sbmQpmomAqzfuHmM2Bmt2v0EbXINiWDAYqx VGtw== MIME-Version: 1.0 X-Received: by 10.107.29.5 with SMTP id d5mr589176iod.45.1416013851988; Fri, 14 Nov 2014 17:10:51 -0800 (PST) Received: by 10.50.47.200 with HTTP; Fri, 14 Nov 2014 17:10:51 -0800 (PST) Received: by 10.50.47.200 with HTTP; Fri, 14 Nov 2014 17:10:51 -0800 (PST) In-Reply-To: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> Date: Sat, 15 Nov 2014 10:10:51 +0900 Message-ID: From: Daniel Park To: Ted Lemon Content-Type: multipart/alternative; boundary=001a113fe4d2a51b450507db6a46 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/A1z8AiXi_5s-AXtAt9hnYOPxP9s Cc: brian@innovationslab.net, Myung-Ki Shin , dnssd@ietf.org, =?UTF-8?B?67CV7KCV7IiY?= , "Mr. Jaehoon Paul Jeong" Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 01:10:54 -0000 --001a113fe4d2a51b450507db6a46 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Before rushing this topic here, you should be clarifying why DNS-bases discovery is necessary for IoT lite things. As of now, CoAP is mostly popular in this world. It is well designed by IETF considering IoT resource model and simplified message exchanges... So, do you have any strong use case and requirement with DNS-based approach in IoT? Daniel. Soohong Daniel Park, Ph.D. Samsung Software R&D Center 2014. 11. 15. =BF=C0=C0=FC 7:18=BF=A1 "Ted Lemon" = =B4=D4=C0=CC =C0=DB=BC=BA: > On Nov 14, 2014, at 12:02 PM, Alf Watt wrote: > > I=A1=AFm confused, the mDNSResponder code is very lightweight and alrea= dy > runs on embedded devices such as printers, cameras and may other low-memo= ry > and low-cpu devices. > > The issue for lln devices is often battery capacity. > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --001a113fe4d2a51b450507db6a46 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable

Before rushing this topic here, you should be clarifying why= DNS-bases discovery is necessary for IoT lite things. As of now, CoAP is m= ostly popular in this world. It is well designed by IETF considering IoT re= source model and simplified message exchanges...

So, do you have any strong use case and requirement with DNS= -based approach in IoT?

Daniel.

Soohong Daniel Park, Ph.D.
Samsung Software R&D Center

2014. 11. 15. =BF=C0=C0=FC 7:18=BF=A1 "Ted = Lemon" <Ted.Lemon@nominum.= com>=B4=D4=C0=CC =C0=DB=BC=BA:
On Nov 14, 2014, at 12:02 PM, Alf Watt <alf@istumbler.net> wrote:
> I=A1=AFm confused, the mDNSResponder code is very lightweight and alre= ady runs on embedded devices such as printers, cameras and may other low-me= mory and low-cpu devices.

The issue for lln devices is often battery capacity.

_______________________________________________
dnssd mailing list
dnssd@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnssd
--001a113fe4d2a51b450507db6a46-- From nobody Fri Nov 14 22:22:48 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC901A1A5B for ; Fri, 14 Nov 2014 22:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdkP1gTHVcsi for ; Fri, 14 Nov 2014 22:22:42 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767AB1A1A2C for ; Fri, 14 Nov 2014 22:22:42 -0800 (PST) Received: by mail-ig0-f181.google.com with SMTP id l13so2902845iga.14 for ; Fri, 14 Nov 2014 22:22:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BxeYJwpvNggBTEs+ZIS4FU5D1x8qPOkf5gCXTOvzgYc=; b=tnkLHGIxDYZ4AxQQkbv0QCsaHWvUL1+6fVWwPOJqD0TQshcJN1rMtDmqx5SzA+dwcW fFOiDegJKKYHZ0DUCDMpWXPzXaYyWTKHasQJakocrAdaDSGAgv8QKVTphjT2HFgF1p1l Om7NaW8VDetM5J4nurPAFgUcUnlIEn2kG9F8SbeiKpD9m9FTZluozDvRivY5SgLfzaBd r00vCILKrEz5kDXIO4gvit1hMWR4JziHcdmmhzEKxUdvdL+Dfrr4f3998T6YFPuNOBw4 eZhimhr0t4+hgBUlStV0G0GQqCWeQEL2KOALwrKCgP+DKPMid3HqCeh6VXTztvU4F6M9 OEMg== MIME-Version: 1.0 X-Received: by 10.51.16.37 with SMTP id ft5mr11218745igd.6.1416032561693; Fri, 14 Nov 2014 22:22:41 -0800 (PST) Received: by 10.64.62.18 with HTTP; Fri, 14 Nov 2014 22:22:41 -0800 (PST) In-Reply-To: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> Date: Fri, 14 Nov 2014 20:22:41 -1000 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: Dave Thaler Content-Type: multipart/alternative; boundary=001a11360240d48c650507dfc5fa Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/6yFZYFwFpaXgXU9woV-b68yu5HU Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , Jung-Soo Park , Ted Lemon , Sejun Lee Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 06:22:45 -0000 --001a11360240d48c650507dfc5fa Content-Type: text/plain; charset=UTF-8 Dave, Thanks for your clarification. In Page 32 in RFC 6762, there is the recommended course of action after probing and failing, but there is no text about a random ID selection. Anyway, we can perform a random ID selection for the uniqueness of a DNS name, but the readability for such a DNS name is not good for the users. My original intention for DNS name generation is to include device category (e.g., refrigerator), device vendor (e.g., Samsung), device model (e.g., RH269LP). This name itself delivers much information to users and mobile smart devices (e.g., smartphone or smart TV) to represent the device icon visually. I am not sure this is enough answer for your last question. If you have more comments, please let me know. Paul =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Fri, Nov 14, 2014 at 11:59 AM, Dave Thaler wrote: > Paul wrote: > > For the regeneration and verification of a unique DNS name under DNS > name conflict, > > the solution in RFC 6762 recommends to use an incremental digit (such as > 2, 3, 4, etc.) > > by trial and error. In an IoT scenario where there will be many IoT > devices of the same > > type, such as light bulb in home or hotel here, this incremental > numbering approach > > will be costly and slow to let each IoT device have a unique DNS name, > ... > > My reading is that RFC 6762 does not _require_ an incremental digit. You > can put in > a random ID or MAC-derived ID or something else highly unlikely to collide. > As such, it should not be "costly and slow". Indeed RFC 6762 does not > specify what > you have to do. Would it be possible to recast your draft as > "how to choose a unique ID and use RFC 6762" ? > > -Dave > --001a11360240d48c650507dfc5fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dave,
Thanks for your clarification.

In Page 32 in RFC 6762, there is the recommended course of action a= fter probing and failing, but=C2=A0
there is no text about a rand= om ID selection.
Anyway, we can perform a random ID selection for= the uniqueness of a DNS name, but=C2=A0
the readability for such= a DNS name is not good for the users.

My original= intention for DNS name generation is to include device category (e.g., ref= rigerator),
device vendor (e.g., Samsung), device model (e.g., RH= 269LP).
This name itself delivers much information to users and m= obile =C2=A0smart devices (e.g., smartphone or smart TV)=C2=A0
to= represent the device icon visually.

I am not sure= this is enough answer for your last question.
If you have more c= omments, please let me know.

Paul

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Pr= ofessor
Department of Software /
Department of Computer EngineeringSungkyunkwan University
Office: +82-31-299-4957
Mobile: +82-10-4758= -1765
Fax: +82-31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmail.com
CPS Lab Website= : http://cpslab.skku.e= du
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong= .php

On Fri, Nov 14, 2014 at 11:59 AM, Dave Thale= r <dthaler@microsoft.com> wrote:
Paul wrote:
> For the regeneration and verification of a unique DNS name under DNS n= ame conflict,
> the solution in RFC 6762 recommends to use an incremental digit (such = as 2, 3, 4, etc.)
> by trial and error. In an IoT scenario where there will be many IoT de= vices of the same
> type, such as light bulb in home or hotel here, this incremental numbe= ring approach
> will be costly and slow to let each IoT device have a unique DN= S name, ...

My reading is that RFC 6762 does not _require_ an incremental digit.=C2=A0 = You can put in
a random ID or MAC-derived ID or something else highly unlikely to collide.=
As such, it should not be "costly and slow".=C2=A0 Indeed RFC 676= 2 does not specify what
you have to do.=C2=A0 =C2=A0Would it be possible to recast your draft as "how to choose a unique ID and use RFC 6762" ?

-Dave

--001a11360240d48c650507dfc5fa-- From nobody Fri Nov 14 22:34:56 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828771A1A75 for ; Fri, 14 Nov 2014 22:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7pG5hB9rq7R for ; Fri, 14 Nov 2014 22:34:52 -0800 (PST) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12EB31A1A5B for ; Fri, 14 Nov 2014 22:34:52 -0800 (PST) Received: by mail-ie0-f169.google.com with SMTP id y20so2417910ier.14 for ; Fri, 14 Nov 2014 22:34:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g/YoEG1OXNH9zy1XlMz0qfetjKkjkgdCC+5hKquRN/I=; b=A1xbvdKEpiz7KX+TIReCIOmrJwDscqE4OhWZ89IgTTXCygvmAxsPg9OAcGMlcoK8k0 OZZJ6sm36oOG3NEytDl/eqEL2x1naGIvBS4wWOrpV+fbpoLkDZajZo7Rm2y0piehyBVT d08ADyS9zK6Do5ZNiHUd9P6j2CdmNI6+xTafLGT6/+tXwFA+TRhod4pFZT6Vas8goPRE fV9ojfcy7MHLdcMz/iDhdcxMpNqXsAUWY4LMCphXWdc+BUUhlS2ZiW+v2M/PCwEAgyOq 36IBWnPPVK9RO7FvCpH9BkfD1oRvOoWNBWoD/3vfmx2tpNJ2c+nZg1lVPCN19/j317WA OUNg== MIME-Version: 1.0 X-Received: by 10.42.24.10 with SMTP id u10mr15475948icb.58.1416033291292; Fri, 14 Nov 2014 22:34:51 -0800 (PST) Received: by 10.64.62.18 with HTTP; Fri, 14 Nov 2014 22:34:51 -0800 (PST) In-Reply-To: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> Date: Fri, 14 Nov 2014 20:34:51 -1000 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: Alf Watt Content-Type: multipart/alternative; boundary=20cf3040e54a5156c50507dff1b6 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/nXVKzzxg1AWYMSH4_HGAbkgoV5s Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , Jung-Soo Park , Ted Lemon , Sejun Lee Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 06:34:54 -0000 --20cf3040e54a5156c50507dff1b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alf, For embedded such as printers, cameras that have power and capacity equivalent to smartphone, you are right. For low-power low-capacity devices, such as light bulb and smoke detecting sensor, I think that running server(s) seems not viable even though I have no exact number of target memory and cpu size for such low-power low-capacity IoT devices. Is there anyone else to comment on the hardware specification of such IoT devices? Thanks. Paul =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Fri, Nov 14, 2014 at 12:02 PM, Alf Watt wrote: > I=E2=80=99m confused, the mDNSResponder code is very lightweight and alre= ady runs > on embedded devices such as printers, cameras and may other low-memory an= d > low-cpu devices. > > What is your target memory and cpu size for an IoT device? Given that > we=E2=80=99ve been using mDNS for more than a decade, the steady pace of > improvement in semiconductors means that even the smallest device will ha= ve > more than sufficient resources for mMDS. > > Best, > Alf > > On Nov 14, 2014, at 1:34 PM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > > The solution in RFC 6762 (Multicast DNS) section 9 is viable for regular > computers, > such as laptop, desktop, and smartphone that can afford to run mDNS > responder. > For IoT devices, such as light bulb and fire detecting sensor, that have > limited memory and storage, > mDNS seems not viable for the DNS naming for them. > > > --20cf3040e54a5156c50507dff1b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alf,
For embedded such as printers, cameras that have = power and capacity equivalent to smartphone,
you are right.
=

For low-power low-capacity devices, such as light bulb = and smoke detecting sensor,
I think that running server(s) seems = not viable=C2=A0
even though I have no exact number of target mem= ory and cpu size=C2=A0
for such low-power low-capacity IoT device= s.

Is there anyone else to comment on the hardware= specification of such IoT devices?

Thanks.
<= div>
Paul =C2=A0

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3DMr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of So= ftware /
Department of Computer Engineering
Sungkyunkwan UniversityOffice: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-51= 19
Email: paulje= ong@skku.edu, jaehoon.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage= : http://cpslab.skku.edu/people-jaehoon-jeong.php

On Fri, Nov 14, 2014 at 12:02 PM, Alf Watt <= span dir=3D"ltr"><alf@istumbler.net> wrote:
=
I=E2=80=99m confused, the mDNSResponder= code is very lightweight and already runs on embedded devices such as prin= ters, cameras and may other low-memory and low-cpu devices.

<= div>What is your target memory and cpu size for an IoT device? Given that w= e=E2=80=99ve been using mDNS for more than a decade, the steady pace of imp= rovement in semiconductors means that even the smallest device will have mo= re than sufficient resources for mMDS.

Best,
Alf

O= n Nov 14, 2014, at 1:34 PM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrot= e:

The solution in RFC 6762 (Multicast DNS) sec= tion 9 is viable for regular computers,=C2=A0
such as la= ptop, desktop, and smartphone that can afford to run mDNS responder.
<= div style=3D"font-family:Helvetica;font-size:12px;font-style:normal;font-va= riant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;te= xt-align:start;text-indent:0px;text-transform:none;white-space:normal;word-= spacing:0px">For IoT devices, such as light bulb and fire detecting sensor,= that have limited memory and storage,
mDNS seems not vi= able for the DNS naming for them.



--20cf3040e54a5156c50507dff1b6-- From nobody Sat Nov 15 09:47:45 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23AD61AC417 for ; Sat, 15 Nov 2014 09:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjrwCCJiIQ5W for ; Sat, 15 Nov 2014 09:47:43 -0800 (PST) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71D71A1AE1 for ; Sat, 15 Nov 2014 09:47:42 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id ar1so5034585iec.31 for ; Sat, 15 Nov 2014 09:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7wWLtRlr5/1nDHxLT60dQrG98PsiEsMUYMpBXjadSCI=; b=ODpAh1ZIlAsoey7zLtQVhSW/yWF03/E0ZqaqtiU1vYXmjKrRRw8r+lWsWZkbmExdU5 n+thYTs3TdYhhUSakYeilG5u9eFG4UCDx5bFLuMsLeB8QopFtQbOATWkT2rVi/IyzQ78 sb5z/INSXQWtm0DzHxtPvVKyCTOEWjy6Fuvf1J16HYOLyl+yw6U0sxnsuOSZKJMeZyeH wggC2by9yD5OIWzUsPiA/YtEmaLD8bre71yR7TylOCB7yvH8ZHT8u8KO29ryezlClc/8 /APKakQcRjfiz+xNz7VYhG0s7tHTGDQulY2Wq3fuRWeIJPGKSDjT3QOGqc7FPrI6RD/x Zn/g== MIME-Version: 1.0 X-Received: by 10.50.62.4 with SMTP id u4mr14428686igr.46.1416073662000; Sat, 15 Nov 2014 09:47:42 -0800 (PST) Received: by 10.64.62.18 with HTTP; Sat, 15 Nov 2014 09:47:41 -0800 (PST) In-Reply-To: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> Date: Sat, 15 Nov 2014 07:47:41 -1000 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: Daniel Park Content-Type: multipart/alternative; boundary=047d7bdca6e099a7f40507e957eb Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/xds6GfVINW0z-5JaBnpvJDMZRhM Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , =?UTF-8?B?67CV7KCV7IiY?= , Ted Lemon Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Nov 2014 17:47:45 -0000 --047d7bdca6e099a7f40507e957eb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Daniel, That's a good point. One use case is IPv6 networking in smart grid networks and home area networks are based on IEEE 1901.2 Narrowband Powerline Communication Networks (PLC). All IoT devices will not necessarily use only wireless communications for LLN (low power and lossy networks), such as IEEE 802.15.4. Also, CoAP is indeed a useful protocol for IoT devices, but we cannot preclude the cases where IoT devices do not use CoAP. Since low capacity IoT devices using IPv6 somehow are IPv6 hosts, it will be useful to let those IoT devices autoconfigure their unique DNS names and tell a network managment entity (e.g., home network users or administrators= ) their naming information in terms of management. Thanks. Paul =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Fri, Nov 14, 2014 at 3:10 PM, Daniel Park wrote: > Before rushing this topic here, you should be clarifying why DNS-bases > discovery is necessary for IoT lite things. As of now, CoAP is mostly > popular in this world. It is well designed by IETF considering IoT resour= ce > model and simplified message exchanges... > > So, do you have any strong use case and requirement with DNS-based > approach in IoT? > > Daniel. > > Soohong Daniel Park, Ph.D. > Samsung Software R&D Center > 2014. 11. 15. =EC=98=A4=EC=A0=84 7:18=EC=97=90 "Ted Lemon" =EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1: > >> On Nov 14, 2014, at 12:02 PM, Alf Watt wrote: >> > I=E2=80=99m confused, the mDNSResponder code is very lightweight and a= lready >> runs on embedded devices such as printers, cameras and may other low-mem= ory >> and low-cpu devices. >> >> The issue for lln devices is often battery capacity. >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> > --047d7bdca6e099a7f40507e957eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Daniel,
That's a good point.

<= div>
One use case is IPv6 networking in smart grid networks and home ar= ea networks=C2=A0
are based on IEEE 1901.2 Narrowband Powerline C= ommunication Networks (PLC).
All IoT devices will not necessarily= use only wireless communications for LLN (low power and lossy networks),= =C2=A0
such as IEEE 802.15.4.

Also, CoAP= is indeed a useful protocol for IoT devices, but we cannot preclude the ca= ses=C2=A0
where IoT devices do not use CoAP.

=
Since low capacity IoT devices using IPv6 somehow are IPv6 hosts, it w= ill be useful=C2=A0
to let those IoT devices autoconfigure their = unique DNS names and=C2=A0
tell a network managment entity (e.g.,= home network users or administrators)
their naming information i= n terms of management.

Thanks.
Paul=C2=A0

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaeh= oon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software /<= br>Department of Computer Engineering
Sungkyunkwan University
Office:= +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Ema= il: pauljeong@skku.= edu, jaehoo= n.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http= ://cpslab.skku.edu/people-jaehoon-jeong.php

On Fri, Nov 14, 2014 at 3:10 PM, Daniel Park= <soohongp@gmail.com> wrote:

Before rushing this topic here, you should be clarifying= why DNS-bases discovery is necessary for IoT lite things. As of now, CoAP = is mostly popular in this world. It is well designed by IETF considering Io= T resource model and simplified message exchanges...

So, do you have any strong use case and requirement with DNS= -based approach in IoT?

Daniel.

Soohong Daniel Park, Ph.D.
Samsung Software R&D Center

2014. 11. 15. =EC=98=A4=EC=A0=84 7:18=EC=97=90 &= quot;Ted Lemon" <Ted.Lemon@nominum.com>=EB=8B=98=EC=9D=B4 =EC=9E=91=EC=84=B1= :
O= n Nov 14, 2014, at 12:02 PM, Alf Watt <alf@istumbler.net> wrote:
> I=E2=80=99m confused, the mDNSResponder code is very lightweight and a= lready runs on embedded devices such as printers, cameras and may other low= -memory and low-cpu devices.

The issue for lln devices is often battery capacity.

 _______________________________________________
dnssd mailing list
dnssd@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnssd

--047d7bdca6e099a7f40507e957eb-- From nobody Sun Nov 16 16:07:03 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60EB1A038A for ; Sun, 16 Nov 2014 16:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXGbWfVLEoMh for ; Sun, 16 Nov 2014 16:06:45 -0800 (PST) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F851A0270 for ; Sun, 16 Nov 2014 16:06:44 -0800 (PST) Received: from [172.16.10.140] (gw.mountain2sea.com [71.70.135.90]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 010D816F1 for ; Sun, 16 Nov 2014 19:03:58 -0500 (EST) From: Tom Pusateri Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <2F90339E-5447-4CF2-B9C7-3FCCBF259A65@bangj.com> Date: Sun, 16 Nov 2014 14:06:42 -1000 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/SbJwqEpUQ2eyDHzKnSrSrEs6Ulc Subject: [dnssd] DNS SD Wiki X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 00:06:48 -0000 If you were at the meeting, you probably heard Dave Thaler mention we = could put the options and consensus about how to move forward with the = LLQ draft on our working group wiki. So I put those notes from my slides and the meeting discussion on our = wiki. You can read it here: https://tools.ietf.org/wg/dnssd/trac/wiki/WikiStart If you remember it differently or have something to add, you only need a = tools account to update it, so feel free. Thanks, Tom From nobody Mon Nov 17 13:16:54 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 028581ACCD8 for ; Mon, 17 Nov 2014 13:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucRzeLNsuZNE for ; Mon, 17 Nov 2014 13:16:48 -0800 (PST) Received: from mx0b-00176a03.pphosted.com (mx0b-00176a03.pphosted.com [67.231.157.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 407041AC428 for ; Mon, 17 Nov 2014 13:15:39 -0800 (PST) Received: from pps.filterd (m0048300.ppops.net [127.0.0.1]) by m0048300.ppops.net-00176a03. (8.14.7/8.14.7) with SMTP id sAHLFMbv010735 for ; Mon, 17 Nov 2014 16:15:38 -0500 Received: from cinmlip13.e2k.ad.ge.com (n165-156-000-000.static.ge.com [165.156.4.1] (may be forged)) by m0048300.ppops.net-00176a03. with ESMTP id 1qqqjt01g1-18 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 17 Nov 2014 16:15:37 -0500 Received: from unknown (HELO ALPMBHT01.e2k.ad.ge.com) ([3.159.19.194]) by cinmlip13.e2k.ad.ge.com with ESMTP/TLS/AES256-SHA; 17 Nov 2014 16:16:24 -0500 Received: from CINURAPD07.e2k.ad.ge.com (3.159.212.119) by ALPMBHT01.e2k.ad.ge.com (3.159.19.194) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 17 Nov 2014 16:15:27 -0500 Received: from CINURCNA14.e2k.ad.ge.com ([169.254.2.249]) by CINURAPD07.e2k.ad.ge.com ([3.159.212.119]) with mapi id 14.03.0195.001; Mon, 17 Nov 2014 16:15:27 -0500 From: "Simpson, Robby (GE Energy Management)" To: "Mr. Jaehoon Paul Jeong" , Dave Thaler Thread-Topic: [dnssd] DNS Name Autoconfiguration for Home Network Devices Thread-Index: AQHP//BdQI7OPQKTmku9cohwx5eWnZxg2XGAgAAf7YCAAAcrAIAAjIaAgAPKQ4A= Date: Mon, 17 Nov 2014 21:15:26 +0000 Message-ID: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.5.141003 x-originating-ip: [3.159.212.181] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.28, 0.0.0000 definitions=2014-11-17_03:2014-11-15,2014-11-17,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411170168 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/N_lJNPriHpKTCc7wA0Rlr2KEFdU Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , Jung-Soo Park , Ted Lemon , Sejun Lee Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 21:16:52 -0000 It seems to me that part of your intent is to include semantics (e.g., devi= ce category, device vendor, device model) in a standardized fashion into th= e DNS name. On the other hand, while we often apply semantics to DNS names currently fo= r human readers, these semantics typically are not standardized for machine= s. For that, we have DNS-SD. As an example from the IoT space, we use both mDNS and DNS-SD for SEP 2.0 (= IEEE 2030.5). While the DNS names often reflect aspects such as device man= ufacturer and category, these are not meant to be machine interpretable in = SEP 2.0. Rather, we use DNS-SD to advertise various functionality that is = machine interpretable. Perhaps I am misinterpreting, but is your intent to place machine-interpret= able semantics into the actual DNS names themselves? Thanks, Robby Robby Simpson, PhD System Architect GE Digital Energy M: +1 404 219 1851 Robby.Simpson@GE.com From: "Mr. Jaehoon Paul Jeong" > Date: Saturday, November 15, 2014 at 1:22 AM To: Dave Thaler > Cc: Brian Haberman >, Myung-Ki Shin >, "dnssd@ie= tf.org" >, Jun= g-Soo Park >, Ted Lemon >, Sejun Lee > Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices Dave, Thanks for your clarification. In Page 32 in RFC 6762, there is the recommended course of action after pro= bing and failing, but there is no text about a random ID selection. Anyway, we can perform a random ID selection for the uniqueness of a DNS na= me, but the readability for such a DNS name is not good for the users. My original intention for DNS name generation is to include device category= (e.g., refrigerator), device vendor (e.g., Samsung), device model (e.g., RH269LP). This name itself delivers much information to users and mobile smart devic= es (e.g., smartphone or smart TV) to represent the device icon visually. I am not sure this is enough answer for your last question. If you have more comments, please let me know. Paul =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.co= m CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Fri, Nov 14, 2014 at 11:59 AM, Dave Thaler > wrote: Paul wrote: > For the regeneration and verification of a unique DNS name under DNS name= conflict, > the solution in RFC 6762 recommends to use an incremental digit (such as = 2, 3, 4, etc.) > by trial and error. In an IoT scenario where there will be many IoT devic= es of the same > type, such as light bulb in home or hotel here, this incremental numberin= g approach > will be costly and slow to let each IoT device have a unique DNS name, ..= . My reading is that RFC 6762 does not _require_ an incremental digit. You c= an put in a random ID or MAC-derived ID or something else highly unlikely to collide. As such, it should not be "costly and slow". Indeed RFC 6762 does not spec= ify what you have to do. Would it be possible to recast your draft as "how to choose a unique ID and use RFC 6762" ? -Dave From nobody Mon Nov 17 15:09:20 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7191ACE6F for ; Mon, 17 Nov 2014 15:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjXqj1mKOH_0 for ; Mon, 17 Nov 2014 15:09:14 -0800 (PST) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 257021ACE67 for ; Mon, 17 Nov 2014 15:09:13 -0800 (PST) Received: from [172.16.10.140] (gw.mountain2sea.com [71.70.135.90]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 48A0C181E; Mon, 17 Nov 2014 18:06:23 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Tom Pusateri In-Reply-To: Date: Mon, 17 Nov 2014 18:09:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <42C3C87F-0D99-47CB-B50A-9107BD10A2E6@bangj.com> References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> To: "Simpson, Robby (GE Energy Management)" X-Mailer: Apple Mail (2.1990.1) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/ZBji6Ewv1G1NC0CLKA7VtNmo0Sw Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , Dave Thaler , Jung-Soo Park , Ted Lemon , Sejun Lee , "Mr. Jaehoon Paul Jeong" Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Nov 2014 23:09:16 -0000 I agree that overloading the DNS name is the wrong place for this = information. So would this be a good use for the device-info Pseudo Service Type TXT = record? I haven't been able to find much on "device-info" except for it's = definition and a short email about it. But it seems like a TXT record with key/value pairs would be more = suitable for this type of information. If device-info isn't right, then maybe a new service type can be defined = for this purpose. http://www.dns-sd.org/servicetypes.html http://lists.apple.com/archives/bonjour-dev/2011/Jul/msg00016.html Thanks, Tom > On Nov 17, 2014, at 4:15 PM, Simpson, Robby (GE Energy Management) = wrote: >=20 > It seems to me that part of your intent is to include semantics (e.g., = device category, device vendor, device model) in a standardized fashion = into the DNS name. >=20 > On the other hand, while we often apply semantics to DNS names = currently for human readers, these semantics typically are not = standardized for machines. For that, we have DNS-SD. >=20 > As an example from the IoT space, we use both mDNS and DNS-SD for SEP = 2.0 (IEEE 2030.5). While the DNS names often reflect aspects such as = device manufacturer and category, these are not meant to be machine = interpretable in SEP 2.0. Rather, we use DNS-SD to advertise various = functionality that is machine interpretable. >=20 > Perhaps I am misinterpreting, but is your intent to place = machine-interpretable semantics into the actual DNS names themselves? >=20 > Thanks, > Robby >=20 >=20 > Robby Simpson, PhD >=20 > System Architect >=20 > GE >=20 > Digital Energy >=20 > M: +1 404 219 1851 >=20 > Robby.Simpson@GE.com >=20 >=20 > From: "Mr. Jaehoon Paul Jeong" = > > Date: Saturday, November 15, 2014 at 1:22 AM > To: Dave Thaler > > Cc: Brian Haberman = >, Myung-Ki = Shin >, = "dnssd@ietf.org" = >, Jung-Soo Park = >, Ted Lemon = >, Sejun Lee = > > Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network = Devices >=20 > Dave, > Thanks for your clarification. >=20 > In Page 32 in RFC 6762, there is the recommended course of action = after probing and failing, but > there is no text about a random ID selection. > Anyway, we can perform a random ID selection for the uniqueness of a = DNS name, but > the readability for such a DNS name is not good for the users. >=20 > My original intention for DNS name generation is to include device = category (e.g., refrigerator), > device vendor (e.g., Samsung), device model (e.g., RH269LP). > This name itself delivers much information to users and mobile smart = devices (e.g., smartphone or smart TV) > to represent the device icon visually. >=20 > I am not sure this is enough answer for your last question. > If you have more comments, please let me know. >=20 > Paul >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software / > Department of Computer Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Mobile: +82-10-4758-1765 > Fax: +82-31-290-5119 > Email: pauljeong@skku.edu, = jaehoon.paul@gmail.com > CPS Lab Website: http://cpslab.skku.edu > Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php >=20 > On Fri, Nov 14, 2014 at 11:59 AM, Dave Thaler = > wrote: > Paul wrote: >> For the regeneration and verification of a unique DNS name under DNS = name conflict, >> the solution in RFC 6762 recommends to use an incremental digit (such = as 2, 3, 4, etc.) >> by trial and error. In an IoT scenario where there will be many IoT = devices of the same >> type, such as light bulb in home or hotel here, this incremental = numbering approach >> will be costly and slow to let each IoT device have a unique DNS = name, ... >=20 > My reading is that RFC 6762 does not _require_ an incremental digit. = You can put in > a random ID or MAC-derived ID or something else highly unlikely to = collide. > As such, it should not be "costly and slow". Indeed RFC 6762 does not = specify what > you have to do. Would it be possible to recast your draft as > "how to choose a unique ID and use RFC 6762" ? >=20 > -Dave >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Mon Nov 17 17:29:53 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172A91AD03B for ; Mon, 17 Nov 2014 17:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4z4WYvwmZwM5 for ; Mon, 17 Nov 2014 17:29:48 -0800 (PST) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751F11AD02F for ; Mon, 17 Nov 2014 17:29:48 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id rl12so2626954iec.2 for ; Mon, 17 Nov 2014 17:29:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d3ugc9zDkaZSXgD/mIee/rPkHznIt8J3Bl/Q2gL7EB0=; b=jSzizr07DO5qdfUGub9gb50cNUT5vJzCeacSkxSPVDu2Gp+T2TtmzIRnJ36c1MVf3m OFF5zU1dJsGahjebnbUBnDYYIDuzaXRXRCr5vin+Yq/4+TWfXjelXxpBnu4xIxQSgMtd 6M4EkQYgwDImWjyjKJRSPo37LDcmTSjpYmBSnE87+R3JDAzDb2TmUKHE64IDuUZsJc1N gojW5FNy4LT9FGZZOo0RAb1gCHipJCtmdICiUZuZ4F/dgvWj8Qmd3vpymsHfigUZo7T1 6z6kg0o534V9QUSvTHmFvkrTxF1o+0VpBUijYeNjeyAeXm3fktIrOoy2nmiwHxKH6G5r pAFg== MIME-Version: 1.0 X-Received: by 10.50.62.4 with SMTP id u4mr509957igr.46.1416274187525; Mon, 17 Nov 2014 17:29:47 -0800 (PST) Received: by 10.64.62.18 with HTTP; Mon, 17 Nov 2014 17:29:47 -0800 (PST) In-Reply-To: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> Date: Tue, 18 Nov 2014 10:29:47 +0900 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: "Simpson, Robby (GE Energy Management)" Content-Type: multipart/alternative; boundary=047d7bdca6e0da30b80508180734 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/amgJynITXz_NmWhoo4xHk9MyeqA Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , Dave Thaler , Jung-Soo Park , Ted Lemon , Sejun Lee Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 01:29:52 -0000 --047d7bdca6e0da30b80508180734 Content-Type: text/plain; charset=UTF-8 Hi Robby, Yes, my intent is to to include semantics (e.g., device category, device vendor, and device model) in a standardized fashion into the DNS names of low-capacity IoT devices. I intend to place machine-interpretable semantics into the actual DNS names themselves so that machines can use the DNS name for the identification of other machines without additional service discovery through mDNS. The localization of devices is also possible with the DNS name because the DNS name can include the location of the device, as describe in Section 6 (Location-Aware DNS Name Configuration) in my draft: http://datatracker.ietf.org/doc/draft-jeong-homenet-device-name-autoconf/ Thanks for your good opinion. Paul =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Tue, Nov 18, 2014 at 6:15 AM, Simpson, Robby (GE Energy Management) < robby.simpson@ge.com> wrote: > It seems to me that part of your intent is to include semantics (e.g., > device category, device vendor, device model) in a standardized fashion > into the DNS name. > > On the other hand, while we often apply semantics to DNS names currently > for human readers, these semantics typically are not standardized for > machines. For that, we have DNS-SD. > > As an example from the IoT space, we use both mDNS and DNS-SD for SEP 2.0 > (IEEE 2030.5). While the DNS names often reflect aspects such as device > manufacturer and category, these are not meant to be machine interpretable > in SEP 2.0. Rather, we use DNS-SD to advertise various functionality that > is machine interpretable. > > Perhaps I am misinterpreting, but is your intent to place > machine-interpretable semantics into the actual DNS names themselves? > > Thanks, > Robby > > > Robby Simpson, PhD > > System Architect > > GE > > Digital Energy > > M: +1 404 219 1851 > > Robby.Simpson@GE.com > > > From: "Mr. Jaehoon Paul Jeong" jaehoon.paul@gmail.com>> > Date: Saturday, November 15, 2014 at 1:22 AM > To: Dave Thaler > > Cc: Brian Haberman brian@innovationslab.net>>, Myung-Ki Shin mkshin@etri.re.kr>>, "dnssd@ietf.org" < > dnssd@ietf.org>, Jung-Soo Park >, Ted Lemon Ted.Lemon@nominum.com>>, Sejun Lee prosejun14@gmail.com>> > Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices > > Dave, > Thanks for your clarification. > > In Page 32 in RFC 6762, there is the recommended course of action after > probing and failing, but > there is no text about a random ID selection. > Anyway, we can perform a random ID selection for the uniqueness of a DNS > name, but > the readability for such a DNS name is not good for the users. > > My original intention for DNS name generation is to include device > category (e.g., refrigerator), > device vendor (e.g., Samsung), device model (e.g., RH269LP). > This name itself delivers much information to users and mobile smart > devices (e.g., smartphone or smart TV) > to represent the device icon visually. > > I am not sure this is enough answer for your last question. > If you have more comments, please let me know. > > Paul > > =========================== > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software / > Department of Computer Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Mobile: +82-10-4758-1765 > Fax: +82-31-290-5119 > Email: pauljeong@skku.edu, > jaehoon.paul@gmail.com > CPS Lab Website: http://cpslab.skku.edu > Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php > > On Fri, Nov 14, 2014 at 11:59 AM, Dave Thaler > wrote: > Paul wrote: > > For the regeneration and verification of a unique DNS name under DNS > name conflict, > > the solution in RFC 6762 recommends to use an incremental digit (such as > 2, 3, 4, etc.) > > by trial and error. In an IoT scenario where there will be many IoT > devices of the same > > type, such as light bulb in home or hotel here, this incremental > numbering approach > > will be costly and slow to let each IoT device have a unique DNS name, > ... > > My reading is that RFC 6762 does not _require_ an incremental digit. You > can put in > a random ID or MAC-derived ID or something else highly unlikely to collide. > As such, it should not be "costly and slow". Indeed RFC 6762 does not > specify what > you have to do. Would it be possible to recast your draft as > "how to choose a unique ID and use RFC 6762" ? > > -Dave > > --047d7bdca6e0da30b80508180734 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robby,
Yes, my intent is to=C2=A0to include semanti= cs (e.g., device category, device vendor, and device model)=C2=A0
in a standardized fashion into the DNS names of low-capacity IoT devices.<= /div>

I intend to place machine-interpretable seman= tics into the actual DNS names themselves
so that machines can us= e the DNS name for the identification of other machines=C2=A0
wit= hout additional service discovery through mDNS.

The localization of devices is also possible with the DNS name
= because the DNS name can include the location of the device,
as d= escribe in Section 6 (Location-Aware DNS Name Configuration) in my draft:

Thanks for your good = opinion.

Paul

= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Departm= ent of Software /
Department of Computer Engineering
Sungkyunkwan Uni= versity
Office: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-= 31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal= Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php
=

On Tue, Nov 18, 2014 at 6:15 AM, Simpson, Ro= bby (GE Energy Management) <robby.simpson@ge.com> wrote:<= br>
It seems to me that part of your intent i= s to include semantics (e.g., device category, device vendor, device model)= in a standardized fashion into the DNS name.

On the other hand, while we often apply semantics to DNS names currently fo= r human readers, these semantics typically are not standardized for machine= s.=C2=A0 For that, we have DNS-SD.

As an example from the IoT space, we use both mDNS and DNS-SD for SEP 2.0 (= IEEE 2030.5).=C2=A0 While the DNS names often reflect aspects such as devic= e manufacturer and category, these are not meant to be machine interpretabl= e in SEP 2.0.=C2=A0 Rather, we use DNS-SD to advertise various functionalit= y that is machine interpretable.

Perhaps I am misinterpreting, but is your intent to place machine-interpret= able semantics into the actual DNS names themselves?

Thanks,
Robby


Robby Simpson, PhD

System Architect

GE

Digital Energy

M: +1 404 219 1851

Robby.Simpson@GE.com


From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com<mailto:jaehoon.paul@gmail.com>>
Date: Saturday, November 15, 2014 at 1:22 AM
To: Dave Thaler <dthaler@micros= oft.com<mailto:dthaler@micr= osoft.com>>
Cc: Brian Haberman <brian@in= novationslab.net<mailto:= brian@innovationslab.net>>, Myung-Ki Shin <mkshin@etri.re.kr<mailto:mkshin@etri.re.kr>>, "dnssd@ietf.org<mailto:dnss= d@ietf.org>" <dnssd@ietf.o= rg<mailto:dnssd@ietf.org>&g= t;, Jung-Soo Park <pjs@etri.re.kr&= lt;mailto:pjs@etri.re.kr>>, Ted= Lemon <Ted.Lemon@nominum.com<mailto:Ted.Lemon@nominum.com= >>, Sejun Lee <proseju= n14@gmail.com<mailto:proseju= n14@gmail.com>>
Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices
Dave,
Thanks for your clarification.

In Page 32 in RFC 6762, there is the recommended course of action after pro= bing and failing, but
there is no text about a random ID selection.
Anyway, we can perform a random ID selection for the uniqueness of a DNS na= me, but
the readability for such a DNS name is not good for the users.

My original intention for DNS name generation is to include device category= (e.g., refrigerator),
device vendor (e.g., Samsung), device model (e.g., RH269LP).
This name itself delivers much information to users and mobile=C2=A0 smart = devices (e.g., smartphone or smart TV)
to represent the device icon visually.

I am not sure this is enough answer for your last question.
If you have more comments, please let me know.

Paul

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software /
Department of Computer Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Email: pauljeong@skku.edu&= lt;mailto:pauljeong@skku.edu>,= jaehoon.paul@gmail.com<ma= ilto:jaehoon.paul@gmail.com&g= t;
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php
On Fri, Nov 14, 2014 at 11:5= 9 AM, Dave Thaler <dthaler@micr= osoft.com<mailto:dthaler@mi= crosoft.com>> wrote:
Paul wrote:
> For the regeneration and verification of a unique DNS name under DNS n= ame conflict,
> the solution in RFC 6762 recommends to use an incremental digit (such = as 2, 3, 4, etc.)
> by trial and error. In an IoT scenario where there will be many IoT de= vices of the same
> type, such as light bulb in home or hotel here, this incremental numbe= ring approach
> will be costly and slow to let each IoT device have a unique DNS name,= ...

My reading is that RFC 6762 does not _require_ an incremental digit.=C2=A0 = You can put in
a random ID or MAC-derived ID or something else highly unlikely to collide.=
As such, it should not be "costly and slow".=C2=A0 Indeed RFC 676= 2 does not specify what
you have to do.=C2=A0 =C2=A0Would it be possible to recast your draft as "how to choose a unique ID and use RFC 6762" ?

-Dave


--047d7bdca6e0da30b80508180734-- From nobody Mon Nov 17 17:33:16 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6761C1AD039 for ; Mon, 17 Nov 2014 17:33:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGYbkNoxc2_U for ; Mon, 17 Nov 2014 17:33:11 -0800 (PST) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C419A1AD02F for ; Mon, 17 Nov 2014 17:33:10 -0800 (PST) Received: by mail-ie0-f177.google.com with SMTP id tr6so4151416ieb.36 for ; Mon, 17 Nov 2014 17:33:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5PA1BSblB8gUnb2KkkH35wXTXMZU2EZjiaTF/DueIDw=; b=Ja3I8T9Rwj0Wn88xt6JUzYIKpNnIHgyTCtIO3IQUVGqw5bRU1SgnVJV6S39EW0Wp9Y xUAxx6HdsotzoBLhzpidJijZSMwOTzQkiWKpG3A2idyqplmf8YNXb40vntUIEvnTTbqr kyiaTojj6myo8QD5d/jxRowGj+dEDLesIwF3j/58U3FujQ9GZx3dzzBgRNgDkyPj+LK0 JJZfWCsZAwgU+Q9DBpe55dfkyxw1lTM7E7NfhFnC7DFETPECkyxaWEqZJ05SkW//ATuD 6h+hTnZk8nKm6LbYRswWHCeoNWjBitezEwXRUaWKMfKlYQEpCmWstf47Rp5Ae8SB/y/i 8aeQ== MIME-Version: 1.0 X-Received: by 10.43.160.195 with SMTP id md3mr5672559icc.69.1416274389894; Mon, 17 Nov 2014 17:33:09 -0800 (PST) Received: by 10.64.62.18 with HTTP; Mon, 17 Nov 2014 17:33:09 -0800 (PST) In-Reply-To: <42C3C87F-0D99-47CB-B50A-9107BD10A2E6@bangj.com> References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <42C3C87F-0D99-47CB-B50A-9107BD10A2E6@bangj.com> Date: Tue, 18 Nov 2014 10:33:09 +0900 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: Tom Pusateri Content-Type: multipart/alternative; boundary=001a11c2f5b0ea328e050818139e Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/SpwnjLTJKZP3loVKe6q_lulDylU Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , Dave Thaler , Jung-Soo Park , Ted Lemon , Sejun Lee , "Simpson, Robby \(GE Energy Management\)" Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 01:33:14 -0000 --001a11c2f5b0ea328e050818139e Content-Type: text/plain; charset=UTF-8 Hi Tom, You are right for appliances with enough capacity to run mDNS. However, for low capacity IoT devices without mDNS, my proposal will be able to support an alternative way for DNS naming. Thanks. Paul =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Tue, Nov 18, 2014 at 8:09 AM, Tom Pusateri wrote: > I agree that overloading the DNS name is the wrong place for this > information. > > So would this be a good use for the device-info Pseudo Service Type TXT > record? > > I haven't been able to find much on "device-info" except for it's > definition and a short email about it. > > But it seems like a TXT record with key/value pairs would be more suitable > for this type of information. > If device-info isn't right, then maybe a new service type can be defined > for this purpose. > > http://www.dns-sd.org/servicetypes.html > > http://lists.apple.com/archives/bonjour-dev/2011/Jul/msg00016.html > > Thanks, > Tom > > > > On Nov 17, 2014, at 4:15 PM, Simpson, Robby (GE Energy Management) < > robby.simpson@ge.com> wrote: > > > > It seems to me that part of your intent is to include semantics (e.g., > device category, device vendor, device model) in a standardized fashion > into the DNS name. > > > > On the other hand, while we often apply semantics to DNS names currently > for human readers, these semantics typically are not standardized for > machines. For that, we have DNS-SD. > > > > As an example from the IoT space, we use both mDNS and DNS-SD for SEP > 2.0 (IEEE 2030.5). While the DNS names often reflect aspects such as > device manufacturer and category, these are not meant to be machine > interpretable in SEP 2.0. Rather, we use DNS-SD to advertise various > functionality that is machine interpretable. > > > > Perhaps I am misinterpreting, but is your intent to place > machine-interpretable semantics into the actual DNS names themselves? > > > > Thanks, > > Robby > > > > > > Robby Simpson, PhD > > > > System Architect > > > > GE > > > > Digital Energy > > > > M: +1 404 219 1851 > > > > Robby.Simpson@GE.com > > > > > > From: "Mr. Jaehoon Paul Jeong" jaehoon.paul@gmail.com>> > > Date: Saturday, November 15, 2014 at 1:22 AM > > To: Dave Thaler > > > Cc: Brian Haberman brian@innovationslab.net>>, Myung-Ki Shin mkshin@etri.re.kr>>, "dnssd@ietf.org" < > dnssd@ietf.org>, Jung-Soo Park >, Ted Lemon Ted.Lemon@nominum.com>>, Sejun Lee prosejun14@gmail.com>> > > Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices > > > > Dave, > > Thanks for your clarification. > > > > In Page 32 in RFC 6762, there is the recommended course of action after > probing and failing, but > > there is no text about a random ID selection. > > Anyway, we can perform a random ID selection for the uniqueness of a DNS > name, but > > the readability for such a DNS name is not good for the users. > > > > My original intention for DNS name generation is to include device > category (e.g., refrigerator), > > device vendor (e.g., Samsung), device model (e.g., RH269LP). > > This name itself delivers much information to users and mobile smart > devices (e.g., smartphone or smart TV) > > to represent the device icon visually. > > > > I am not sure this is enough answer for your last question. > > If you have more comments, please let me know. > > > > Paul > > > > =========================== > > Mr. Jaehoon (Paul) Jeong, Ph.D. > > Assistant Professor > > Department of Software / > > Department of Computer Engineering > > Sungkyunkwan University > > Office: +82-31-299-4957 > > Mobile: +82-10-4758-1765 > > Fax: +82-31-290-5119 > > Email: pauljeong@skku.edu, > jaehoon.paul@gmail.com > > CPS Lab Website: http://cpslab.skku.edu > > Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php > > > > On Fri, Nov 14, 2014 at 11:59 AM, Dave Thaler > wrote: > > Paul wrote: > >> For the regeneration and verification of a unique DNS name under DNS > name conflict, > >> the solution in RFC 6762 recommends to use an incremental digit (such > as 2, 3, 4, etc.) > >> by trial and error. In an IoT scenario where there will be many IoT > devices of the same > >> type, such as light bulb in home or hotel here, this incremental > numbering approach > >> will be costly and slow to let each IoT device have a unique DNS name, > ... > > > > My reading is that RFC 6762 does not _require_ an incremental digit. > You can put in > > a random ID or MAC-derived ID or something else highly unlikely to > collide. > > As such, it should not be "costly and slow". Indeed RFC 6762 does not > specify what > > you have to do. Would it be possible to recast your draft as > > "how to choose a unique ID and use RFC 6762" ? > > > > -Dave > > > > _______________________________________________ > > dnssd mailing list > > dnssd@ietf.org > > https://www.ietf.org/mailman/listinfo/dnssd > > --001a11c2f5b0ea328e050818139e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tom,
You are right for appliances with enough capac= ity to run mDNS.
However, for low capacity IoT devices without mD= NS,
my proposal will be able to support an alternative way for DN= S naming.

Thanks.

Paul

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.<= br>Assistant Professor
Department of Software /
Department of Compute= r Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Mobi= le: +82-10-4758-1765
Fax: +82-31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmail.com
= CPS Lab Website: http:= //cpslab.skku.edu
Personal Homepage: http://cpslab.skku.edu/peopl= e-jaehoon-jeong.php

On Tue, Nov 18, 2014 at 8:09 AM, Tom Pusater= i <pusateri@bangj.com> wrote:
I agree that overloading the DNS name is the wrong place for this info= rmation.

So would this be a good use for the device-info Pseudo Service Type TXT rec= ord?

I haven't been able to find much on "device-info" except for = it's definition and a short email about it.

But it seems like a TXT record with key/value pairs would be more suitable = for this type of information.
If device-info isn't right, then maybe a new service type can be define= d for this purpose.

http:= //www.dns-sd.org/servicetypes.html

http://lists.apple.com/archives/bonjour-dev/2011/Jul/= msg00016.html

Thanks,
Tom


> On Nov 17, 2014, at 4:15 PM, Simpson, Robby (GE Energy Management) <= ;robby.simpson@ge.com> wrote= :
>
> It seems to me that part of your intent is to include semantics (e.g.,= device category, device vendor, device model) in a standardized fashion in= to the DNS name.
>
> On the other hand, while we often apply semantics to DNS names current= ly for human readers, these semantics typically are not standardized for ma= chines.=C2=A0 For that, we have DNS-SD.
>
> As an example from the IoT space, we use both mDNS and DNS-SD for SEP = 2.0 (IEEE 2030.5).=C2=A0 While the DNS names often reflect aspects such as = device manufacturer and category, these are not meant to be machine interpr= etable in SEP 2.0.=C2=A0 Rather, we use DNS-SD to advertise various functio= nality that is machine interpretable.
>
> Perhaps I am misinterpreting, but is your intent to place machine-inte= rpretable semantics into the actual DNS names themselves?
>
> Thanks,
> Robby
>
>
> Robby Simpson, PhD
>
> System Architect
>
> GE
>
> Digital Energy
>
> M: +1 404 219 1851
>
> Robby.Simpson@GE.com
>
>
> From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com<mailto:jaehoon.paul@gmail.com>>
> Date: Saturday, November 15, 2014 at 1:22 AM
> To: Dave Thaler <dthaler@m= icrosoft.com<mailto:dthaler= @microsoft.com>>
> Cc: Brian Haberman <bri= an@innovationslab.net<mailto:brian@innovationslab.net>>, Myung-Ki Shin <mkshin@etri.re.kr<mailto:mkshin@etri.re.kr>>, "dnssd@ietf.org<mailto:dnssd@ietf.org>" <dnssd@i= etf.org<mailto:dnssd@ietf.org&= gt;>, Jung-Soo Park <pjs@etri.re.kr= <mailto:pjs@etri.re.kr>>= , Ted Lemon <Ted.Lemon@nominum.= com<mailto:Ted.Lemon@nominu= m.com>>, Sejun Lee <pr= osejun14@gmail.com<mailto:pr= osejun14@gmail.com>>
> Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devic= es
>
> Dave,
> Thanks for your clarification.
>
> In Page 32 in RFC 6762, there is the recommended course of action afte= r probing and failing, but
> there is no text about a random ID selection.
> Anyway, we can perform a random ID selection for the uniqueness of a D= NS name, but
> the readability for such a DNS name is not good for the users.
>
> My original intention for DNS name generation is to include device cat= egory (e.g., refrigerator),
> device vendor (e.g., Samsung), device model (e.g., RH269LP).
> This name itself delivers much information to users and mobile=C2=A0 s= mart devices (e.g., smartphone or smart TV)
> to represent the device icon visually.
>
> I am not sure this is enough answer for your last question.
> If you have more comments, please let me know.
>
> Paul
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
> Mr. Jaehoon (Paul) Jeong, Ph.D.
> Assistant Professor
> Department of Software /
> Department of Computer Engineering
> Sungkyunkwan University
> Office: +82-31-299-4957
> Mobile: +82-10-4758-1765
> Fax: +82-31-290-5119
> Email: pauljeong@skku.edu<= ;mailto:pauljeong@skku.edu>, <= a href=3D"mailto:jaehoon.paul@gmail.com">jaehoon.paul@gmail.com<mail= to:jaehoon.paul@gmail.com>=
> CPS Lab Website: = http://cpslab.skku.edu
> Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php<= /a>
>
> On Fri, Nov 14, 2014 at 11:59 AM, Dave Thaler <dthaler@microsoft.com<mailto:dthaler@microsoft.com>> wrote:
> Paul wrote:
>> For the regeneration and verification of a unique DNS name under D= NS name conflict,
>> the solution in RFC 6762 recommends to use an incremental digit (s= uch as 2, 3, 4, etc.)
>> by trial and error. In an IoT scenario where there will be many Io= T devices of the same
>> type, such as light bulb in home or hotel here, this incremental n= umbering approach
>> will be costly and slow to let each IoT device have a unique DNS n= ame, ...
>
> My reading is that RFC 6762 does not _require_ an incremental digit.= =C2=A0 You can put in
> a random ID or MAC-derived ID or something else highly unlikely to col= lide.
> As such, it should not be "costly and slow".=C2=A0 Indeed RF= C 6762 does not specify what
> you have to do.=C2=A0 =C2=A0Would it be possible to recast your draft = as
> "how to choose a unique ID and use RFC 6762" ?
>
> -Dave
>
> __________________= _____________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd


--001a11c2f5b0ea328e050818139e-- From nobody Tue Nov 18 10:46:57 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E591A6F21 for ; Tue, 18 Nov 2014 10:46:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.093 X-Spam-Level: X-Spam-Status: No, score=-1.093 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6TkXLfCXdjE for ; Tue, 18 Nov 2014 10:46:42 -0800 (PST) Received: from polaris.istumbler.net (polaris.istumbler.net [66.116.108.178]) by ietfa.amsl.com (Postfix) with ESMTP id EC0171A6F12 for ; Tue, 18 Nov 2014 10:46:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by polaris.istumbler.net (Postfix) with ESMTP id CC94F30B106B; Tue, 18 Nov 2014 10:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at example.com Received: from polaris.istumbler.net ([127.0.0.1]) by localhost (polaris.istumbler.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G4fQ-WqkyVeO; Tue, 18 Nov 2014 10:46:40 -0800 (PST) Received: from [10.0.20.27] (unknown [157.130.198.150]) by polaris.istumbler.net (Postfix) with ESMTPSA id 7B96030B1054; Tue, 18 Nov 2014 10:46:40 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-64001965-DE29-4073-8032-80210F936DD3 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Apple-Base-Url: x-msg://13/ X-Universally-Unique-Identifier: 7E5B8951-B03F-464D-95F6-0127BFF20C42 X-Apple-Mail-Remote-Attachments: YES X-Apple-Auto-Saved: 1 From: Alf Watt X-Mailer: iPhone Mail (12B411) In-Reply-To: X-Apple-Windows-Friendly: 1 Date: Tue, 18 Nov 2014 10:46:38 -0800 Content-Transfer-Encoding: 7bit X-Apple-Mail-Signature: Message-Id: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> X-Uniform-Type-Identifier: com.apple.mail-draft To: "Mr. Jaehoon Paul Jeong" Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/akd1-jOhFuN_uhIGamIUI6_-Lfk Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , Jung-Soo Park , Ted Lemon , Sejun Lee Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 18:46:55 -0000 --Apple-Mail-64001965-DE29-4073-8032-80210F936DD3 Content-Type: text/plain; charset=cp932 Content-Transfer-Encoding: quoted-printable The proposal may have merit for other reasons but in terms of resource usage= for IoT devices it=81fs very instructive to look at existing products. The Phillips Hue lights are built around a 32 ARM core [1] with limited RAM (= 128kb). The Nest Protect smoke detector is also built around a similar 32bit= ARM core from Freescale, the K60[2]. Both of these are attached to a Zigbee radio, which provides sufficient band= width for DNS-SD over mDNS, as per our charter[3]. Devices which need service discovery on batteries will very likely be using l= ayer-2 discovery mechanisms for power consumption reasons (i.e. BT-LE).=20 I have a hard time imagining that a device with much less capabilities than a= bove will be a useful internet node. If it can't afford to run a simple disc= overy service then what is it doing on the network? Best, Alf [1] http://www.digchip.com/datasheets/parts/datasheet/456/STM32F217VET6.php "ARM-based 32-bit MCU, MB Flash/128+4KB RAM, crypto, USB OTG HS/FS, Ethernet= , 17 TIMs, 3 ADCs, 15 comm. interfaces & camera" [2] http://cache.freescale.com/files/32bit/doc/data_sheet/K60P100M100SF2V2.p= df?fpsp=3D1&WT_TYPE=3DData%20Sheets&WT_VENDOR=3DFREESCALE&WT_FILE_FORMAT=3Dp= df&WT_ASSET=3DDocumentation [3] http://datatracker.ietf.org/wg/dnssd/charter/ > On Nov 14, 2014, at 10:34 PM, Mr. Jaehoon Paul Jeong wrote: >=20 > Alf, > For embedded such as printers, cameras that have power and capacity equiva= lent to smartphone, > you are right. >=20 > For low-power low-capacity devices, such as light bulb and smoke detecting= sensor, > I think that running server(s) seems not viable=20 > even though I have no exact number of target memory and cpu size=20 > for such low-power low-capacity IoT devices. >=20 > Is there anyone else to comment on the hardware specification of such IoT d= evices? >=20 > Thanks. >=20 > Paul =20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software / > Department of Computer Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Mobile: +82-10-4758-1765 > Fax: +82-31-290-5119 > Email: pauljeong@skku.edu, jaehoon.paul@gmail.com > CPS Lab Website: http://cpslab.skku.edu > Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php >=20 >> On Fri, Nov 14, 2014 at 12:02 PM, Alf Watt wrote: >> I=81fm confused, the mDNSResponder code is very lightweight and already r= uns on embedded devices such as printers, cameras and may other low-memory a= nd low-cpu devices. >>=20 >> What is your target memory and cpu size for an IoT device? Given that we=81= fve been using mDNS for more than a decade, the steady pace of improvement i= n semiconductors means that even the smallest device will have more than suf= ficient resources for mMDS. >>=20 >> Best, >> Alf >>=20 >>> On Nov 14, 2014, at 1:34 PM, Mr. Jaehoon Paul Jeong wrote: >>>=20 >>> The solution in RFC 6762 (Multicast DNS) section 9 is viable for regular= computers,=20 >>> such as laptop, desktop, and smartphone that can afford to run mDNS resp= onder. >>> For IoT devices, such as light bulb and fire detecting sensor, that have= limited memory and storage, >>> mDNS seems not viable for the DNS naming for them. --Apple-Mail-64001965-DE29-4073-8032-80210F936DD3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
The proposal may have merit for other reasons but in terms of resource usa= ge for IoT devices it=E2=80=99s very instructive to look at existing product= s.

The Phillips Hue lights are bui= lt around a 32 ARM core [1] with limited RAM (128kb). The Nest Protect smoke= detector is also built around a similar 32bit ARM core from Freescale, the K= 60[2].

Both of= these are attached to a Zigbee radio, which provides sufficient bandwidth f= or DNS-SD over mDNS, as per our charter[3].

<= div class=3D"">Devices which need service discovery on batteries will very l= ikely be using layer-2 discovery mechanisms for power consumption reasons (i= .e. BT-LE). 

= I have a hard time imagining that a device with much less capabilities than a= bove will be a useful internet node. If it can't afford to run a simple disc= overy service then what is it doing on the network?
Best,
Alf
<= br>
[1] http://www.digchip.com/datasheets/parts= /datasheet/456/STM32F217VET6.php
"ARM-based 32-bit MCU, MB Fl= ash/128+4KB RAM, crypto, USB OTG HS/FS, Ethernet, 17 TIMs, 3 ADCs, 15=   comm. interfaces & camera"
<= div class=3D"">[3] http://datatracker.ietf.org/wg/dnssd/charter/

On Nov 14, 2014, at 10:34 PM, M= r. Jaehoon Paul Jeong <jaehoon.= paul@gmail.com> wrote:

<= div class=3D"">
Alf,
For embedded s= uch as printers, cameras that have power and capacity equivalent to smartpho= ne,
you are right.

=
For low-power low-capacity devices, such as light bulb= and smoke detecting sensor,
I think that running serve= r(s) seems not viable 
even though I have no exact= number of target memory and cpu size 
for such lo= w-power low-capacity IoT devices.

=
Is there anyone else to comment on the hardware specificatio= n of such IoT devices?

Thanks.

Paul &n= bsp;

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= br class=3D"">Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Profes= sor
Department of Software /
Department of Compu= ter Engineering
Sungkyunkwan University
Office: += 82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82= -31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: <= a href=3D"http://cpslab.skku.edu/people-jaehoon-jeong.php" target=3D"_blank"= class=3D"">http://cpslab.skku.edu/people-jaehoon-jeong.php

On Fri, Nov 14, 2014 at 12:02 PM, A= lf Watt <alf@istumbler.net> wrote:
I=E2=80=99m confused, the mDNSResponder code is very lightweight a= nd already runs on embedded devices such as printers, cameras and may other l= ow-memory and low-cpu devices.

What is your target memory and cpu size for an IoT device? Given that= we=E2=80=99ve been using mDNS for more than a decade, the steady pace of im= provement in semiconductors means that even the smallest device will have mo= re than sufficient resources for mMDS.

Best,
Alf

On Nov 14, 2014, at 1:34 PM, Mr. Jaehoon Paul= Jeong <jaehoon.paul@gmail.com> wrote:

The solution in RFC 6762 (Multicast DNS) section 9 i= s viable for regular computers, 
such as lap= top, desktop, and smartphone that can afford to run mDNS responder.
For IoT devices, such as light bulb and fire detecting se= nsor, that have limited memory and storage,
mDNS s= eems not viable for the DNS naming for them.



= --Apple-Mail-64001965-DE29-4073-8032-80210F936DD3-- From nobody Tue Nov 18 14:46:58 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD391AC3C9 for ; Tue, 18 Nov 2014 14:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.685 X-Spam-Level: X-Spam-Status: No, score=-104.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 41DljH7XWuad for ; Tue, 18 Nov 2014 14:46:54 -0800 (PST) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A1801AC3BE for ; Tue, 18 Nov 2014 14:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1416350813; x=2280264413; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=3auKvwM+7HxZavaeS4HTHuCrqUXAOqjVn+NhCvMuHig=; b=LYoFI+i5gnLPutwVgr3sXNB0zhDrSJFADnxCSwcxOW8+JvUOTmhWLvirv0t791BN +qStmvNFY++26SMQBBtv0WppctGzSZ0gWi+Q0OjjEmDpu9tGjapk5uk1TNdjSakh gvxYXaXb576+nC1fuqs0kqyL60FJVnKd3Whm7DUl4IR9pkm9T8pH+eH3NrgrF+PQ ETTzSHACq5MGZfJf0QgcFPrYaxnBmQbDUn0XdfkycKi8pZoIeVDVT1b+lFG6ppmA YQE57sHn3wkMeNAYGrbKlui4qmU6x7Do8leX2zV9TJaBuD7x0WdJaK5LG1wnM4CN RPnqK4/7mzF1/8jgFxk1eQ==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id D7.34.18976.C5CCB645; Tue, 18 Nov 2014 14:46:52 -0800 (PST) X-AuditID: 11973e11-f79a66d000004a20-1d-546bcc5c8dae Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id EF.6D.05439.26CCB645; Tue, 18 Nov 2014 14:46:58 -0800 (PST) Received: from chesh1.apple.com (chesh1.apple.com [17.193.13.41]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NF900EYXBA4D540@spicerack.apple.com> for dnssd@ietf.org; Tue, 18 Nov 2014 14:46:52 -0800 (PST) Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Stuart Cheshire In-reply-to: Date: Tue, 18 Nov 2014 14:46:49 -0800 Content-transfer-encoding: quoted-printable Message-id: <26B22159-3630-493B-AAA0-BC2DEA9DBA7F@apple.com> References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <42C3C87F-0D99-47CB-B50A-9107BD10A2E6@bangj.com> To: "dnssd@ietf.org" X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUi2FAYrBtzJjvEYMdlG4v3S2cxOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4+vDaewFnzkrWnf9Z21g/MTexcjBISFgInH0VlAXIyeQKSZx 4d56ti5GLg4hgb2MEt8OnmaFqXl9XBgiPplJ4umceYwQznwmidVfLzGDFDEL6Encv6gFMogX yNy5dxsriC0s4CGxvPkHC4jNJqAl8eLzFTYQm1MgWGL27zdgN7AIqErMX2YBEmYW0JZ48u4C K8QYG4mpKxcxgthCAs0sElu3gtWIAJX3zjnFBHGzrMTpc89ZQM6REHjKKvHs5zPGCYxCsxAu moXkollIVixgZF7FKJSbmJmjm5lnpJdYUJCTqpecn7uJERSo0+0EdzAeX2V1iFGAg1GJhzdh alaIEGtiWXFl7iFGaQ4WJXHeT0VAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxJUatYPFOz NGOvra+/5FWz6/J2o/KgC9vurp8/49BpnlqLlJnNIYV1UWzpLtIKBxZX3yt3vJSqLGb+o/Tw jPbfQvvcnn+LmXaIh0lYxHNf9YPWe9Nj93BOeH306hrea0c8b+ww9Xl8X7HvQveHmK/zmfc2 N24/y7SD/fDrW/ofTWUbptumBZ1RYinOSDTUYi4qTgQAyBIFLjUCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUi2FCsoZt0JjvE4Mk0YYv3S2cxOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4+vDaewFnzkrWnf9Z21g/MTexcjBISFgIvH6uHAXIyeQKSZx 4d56ti5GLg4hgclMEk/nzGOEcOYzSaz+eokZpIFZQE/i/kUtkAZeIHPn3m2sILawgIfE8uYf LCA2m4CWxIvPV9hAbE6BYInZv9+A7WIRUJWYv8wCJMwsoC3x5N0FVogxNhJTVy5iBLGFBJpZ JLZuBasRASrvnXOKCeI2WYnT556zTGDkn4VwxCwkR8xCMnUBI/MqRoGi1JzESmO9xIKCnFS9 5PzcTYzg0CoM3sH4Z5nVIUYBDkYlHt6EqVkhQqyJZcWVuYcYJTiYlUR4BbuzQ4R4UxIrq1KL 8uOLSnNSiw8xSnOwKInzKgLDWUggPbEkNTs1tSC1CCbLxMEp1cDIetZLqKjV3XLZjA9SARsk k1va+91OtnfztuqUbIyZvH4Jj7Fp6isB/webOIOTe14cSz/7rbVDsfnd/P8NokcnlHQqhMv0 rb/ySdXXPGpBTHvDJvtPbr9avKb9fZvs9eZ8hAnLhAWnq2sC9ud/+rXgEJ+1Zqu+eYrf7biv C2dcmcx+913Px5NKLMUZiYZazEXFiQCFvyLPKQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/4bFvTbmAfGXS2NkJL4e6bypY59U Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Nov 2014 22:46:56 -0000 On 17 Nov, 2014, at 17:33, Mr. Jaehoon Paul Jeong = wrote: > Hi Tom, >=20 > You are right for appliances with enough capacity to run mDNS. >=20 > However, for low capacity IoT devices without mDNS, my proposal will = be able to support an alternative way for DNS naming. You assert that there are devices with insufficient resources to run = DNS-SD/mDNS. You assert that these devices would have sufficient resources to run = your alternative. I think you need data to substantiate these claims. Note that devices = like the SitePlayer Telnet implement DNS-SD/mDNS in under one kilobyte = (about 850 bytes of code, if I remember correctly): = So you need to demonstrate that: 1. That there are devices where 850 bytes of code is too much. 2. That these devices can implement your thing in under 850 bytes. 3. That your thing is useful. I=92m still unclear on what your thing is = useful for. Your proposal says how devices pick host names, but not how = users find out what those host names are, or find out what those devices = do, or what protocol to use to communicate with them, and how clients = resolve those host names to addresses. Stuart Cheshire From nobody Tue Nov 18 18:49:58 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562EC1ACF0E for ; Tue, 18 Nov 2014 18:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJgL2BCKAP-6 for ; Tue, 18 Nov 2014 18:49:54 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DF801A8A78 for ; Tue, 18 Nov 2014 18:49:54 -0800 (PST) Received: by mail-ig0-f177.google.com with SMTP id uq10so240299igb.4 for ; Tue, 18 Nov 2014 18:49:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tPOHuAcfm2SRACojhWg1BdJ+o6olq7hl8d0IDpPPHIc=; b=uQw0FBlh58D7M/OuwRUUWEbkZ7i6TJr8GuwpuhlQnftxXRKnAFCRpJ1wE4xnI/w7+1 AeJHQ7PMv+8vScYygOp8ZoEhl91WGzlUJsGphk8vYHg60SPfXNua8bTe/MYo6MG77pJk ZSvfbVrydVVbN35gRCMHCcTCbXqHNn0NaRF21k8l/HVj5+rzHl4YkAu+aKT50qB1z9/O BIlbZGYNmUp4W2nSambtWS4lC09Sv2p8JfcAnuxdPZbl+yoFVvGRETnZ6LxXA7KhgZNi 6043P86oPd2sfTjAUBFUw/jM4dIbtQ9+T1UbYvZEOQWM7nbmegBVHxJTSNiRZm8MZzNQ R7Zg== MIME-Version: 1.0 X-Received: by 10.51.16.37 with SMTP id ft5mr852081igd.6.1416365393248; Tue, 18 Nov 2014 18:49:53 -0800 (PST) Received: by 10.64.62.18 with HTTP; Tue, 18 Nov 2014 18:49:53 -0800 (PST) In-Reply-To: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> Date: Wed, 19 Nov 2014 11:49:53 +0900 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: Alf Watt Content-Type: multipart/alternative; boundary=001a113602402309b705082d4483 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/CEDPUhbeMgbHMggUElR8MkoLZkA Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , Jung-Soo Park , Ted Lemon , Sejun Lee Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 02:49:57 -0000 --001a113602402309b705082d4483 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alf, Thanks for your kind survey information. It seems that the devices mentioned above will be able to run mDNS. My point is to allow IoT device vendors to have an alternative way for a simple DNS naming that is based on IPv6 stateless autoconfiguration. For the case where only the mapping between an IoT device's DNS name and its IPv6 is required, mDNS seems like an overkill. Paul =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Wed, Nov 19, 2014 at 3:46 AM, Alf Watt wrote: > The proposal may have merit for other reasons but in terms of resource > usage for IoT devices it=E2=80=99s very instructive to look at existing p= roducts. > > The Phillips Hue lights are built around a 32 ARM core [1] with limited > RAM (128kb). The Nest Protect smoke detector is also built around a simil= ar > 32bit ARM core from Freescale, the K60[2]. > > Both of these are attached to a Zigbee radio, which provides sufficient > bandwidth for DNS-SD over mDNS, as per our charter[3]. > > Devices which need service discovery on batteries will very likely be > using layer-2 discovery mechanisms for power consumption reasons (i.e. > BT-LE). > > I have a hard time imagining that a device with much less capabilities > than above will be a useful internet node. If it can't afford to run a > simple discovery service then what is it doing on the network? > > Best, > Alf > > [1] > http://www.digchip.com/datasheets/parts/datasheet/456/STM32F217VET6.php > "ARM-based 32-bit MCU, MB Flash/128+4KB RAM, crypto, USB OTG HS/FS, > Ethernet, 17 TIMs, 3 ADCs, 15 comm. interfaces & camera" > [2] *http://cache.freescale.com/files/32bit/doc/data_sheet/K60P100M100SF2= V2.pdf?fpsp=3D1&WT_TYPE=3DData%20Sheets&WT_VENDOR=3DFREESCALE&WT_FILE_FORMA= T=3Dpdf&WT_ASSET=3DDocumentation > * > [3] http://datatracker.ietf.org/wg/dnssd/charter/ > > On Nov 14, 2014, at 10:34 PM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > > Alf, > For embedded such as printers, cameras that have power and capacity > equivalent to smartphone, > you are right. > > For low-power low-capacity devices, such as light bulb and smoke detectin= g > sensor, > I think that running server(s) seems not viable > even though I have no exact number of target memory and cpu size > for such low-power low-capacity IoT devices. > > Is there anyone else to comment on the hardware specification of such IoT > devices? > > Thanks. > > Paul > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software / > Department of Computer Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Mobile: +82-10-4758-1765 > Fax: +82-31-290-5119 > Email: pauljeong@skku.edu, jaehoon.paul@gmail.com > CPS Lab Website: http://cpslab.skku.edu > Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php > > On Fri, Nov 14, 2014 at 12:02 PM, Alf Watt wrote: > >> I=E2=80=99m confused, the mDNSResponder code is very lightweight and alr= eady runs >> on embedded devices such as printers, cameras and may other low-memory a= nd >> low-cpu devices. >> >> What is your target memory and cpu size for an IoT device? Given that >> we=E2=80=99ve been using mDNS for more than a decade, the steady pace of >> improvement in semiconductors means that even the smallest device will h= ave >> more than sufficient resources for mMDS. >> >> Best, >> Alf >> >> On Nov 14, 2014, at 1:34 PM, Mr. Jaehoon Paul Jeong < >> jaehoon.paul@gmail.com> wrote: >> >> The solution in RFC 6762 (Multicast DNS) section 9 is viable for regular >> computers, >> such as laptop, desktop, and smartphone that can afford to run mDNS >> responder. >> For IoT devices, such as light bulb and fire detecting sensor, that have >> limited memory and storage, >> mDNS seems not viable for the DNS naming for them. >> >> >> > > --001a113602402309b705082d4483 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alf,
Thanks for your kind survey information.

It seems that the devices mentioned above will be able to = run mDNS.
My point is to allow IoT device vendors to have an alte= rnative way for a simple DNS naming=C2=A0
that is based on IPv6 s= tateless autoconfiguration.

For the case where onl= y the mapping between an IoT device's DNS name and its IPv6 is required= ,
mDNS seems like an overkill.

Paul


=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) J= eong, Ph.D.
Assistant Professor
Department of Software /
Departmen= t of Computer Engineering
Sungkyunkwan University
Office: +82-31-299-= 4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmai= l.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.s= kku.edu/people-jaehoon-jeong.php

On Wed, Nov 19, 2014 at 3:46 AM, Alf Watt <= alf@istumbler.net> wrote:
<= div dir=3D"auto">
The proposal may have me= rit for other reasons but in terms of resource usage for IoT devices it=E2= =80=99s very instructive to look at existing products.

= The Phillips Hue lights are built around a 32 ARM core [1] with limited RAM= (128kb). The Nest Protect smoke detector is also built around a similar 32= bit ARM core from Freescale, the K60[2].

Both = of these are attached to a Zigbee radio, which provides sufficient bandwidt= h for DNS-SD over mDNS, as per our charter[3].

Dev= ices which need service discovery on batteries will very likely be using la= yer-2 discovery mechanisms for power consumption reasons (i.e. BT-LE).=C2= =A0

I have a hard time imagining that a device wit= h much less capabilities than above will be a useful internet node. If it c= an't afford to run a simple discovery service then what is it doing on = the network?

Best,
Alf

"ARM-based 32-bit MCU, MB= Flash/128+4KB RAM, crypto, USB OTG HS/FS, Ethernet, 17 TIMs, 3 ADCs, 15= =C2=A0 comm. interfaces & camera"<= /div>
<= div>[3]=C2=A0http://datatracker.ietf.org/wg/dnssd/charter/
<= div class=3D"h5">

On Nov 14, 2014, at 10:34 PM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com= > wrote:

Alf,
For embedded such a= s printers, cameras that have power and capacity equivalent to smartphone,<= /div>
you are right.

For low-power low-capacit= y devices, such as light bulb and smoke detecting sensor,
I think= that running server(s) seems not viable=C2=A0
even though I have= no exact number of target memory and cpu size=C2=A0
for such low= -power low-capacity IoT devices.

Is there anyone e= lse to comment on the hardware specification of such IoT devices?

Thanks.

Paul =C2=A0

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of= Software /
Department of Computer Engineering
Sungkyunkwan Universit= y
Office: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290= -5119
Email: pau= ljeong@skku.edu, jaehoon.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Home= page: http://cpslab.skku.edu/people-jaehoon-jeong.php

On Fri, Nov 14, 2014 at 12:02 PM, Alf Watt <= span dir=3D"ltr"><alf@istumbler.net> wrote:
=
I=E2=80=99m confused, the mDNSResponder= code is very lightweight and already runs on embedded devices such as prin= ters, cameras and may other low-memory and low-cpu devices.

<= div>What is your target memory and cpu size for an IoT device? Given that w= e=E2=80=99ve been using mDNS for more than a decade, the steady pace of imp= rovement in semiconductors means that even the smallest device will have mo= re than sufficient resources for mMDS.

Best,
Alf

On Nov 14, 2= 014, at 1:34 PM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:
The solution in RFC 6762 (Multicast DNS) section 9 is v= iable for regular computers,=C2=A0
such as laptop, deskt= op, and smartphone that can afford to run mDNS responder.
For IoT devices, such as light bulb and fire detecting sensor, that hav= e limited memory and storage,
mDNS seems not viable for = the DNS naming for them.





--001a113602402309b705082d4483-- From nobody Tue Nov 18 20:00:33 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF11E1ACF74 for ; Tue, 18 Nov 2014 20:00:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Mokcwt_eTLW for ; Tue, 18 Nov 2014 20:00:29 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3B51ACF67 for ; Tue, 18 Nov 2014 20:00:28 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id uq10so2254787igb.4 for ; Tue, 18 Nov 2014 20:00:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bYY4yeTCP3OdCB7MlsIj6H8GdG1g0hj+KdKEk+7Q/6o=; b=Z0Te79856EAWya3qgetHtgwJ83iUiNRgo+jjW3FTGeMBOofApZBsZO7hyupCPbeP8J PdmmaL+cn0mk5QDTQz7mOaP58pw+fNmQYkcigj0Kszxqf9CMVHhdSi8qxwDZFz1UPzGp 3ojwbLYjBlA3JFzhINDIQx4XoJfvi8iPrtI8IToWiJesDoecK4bno6NW+JzAlu65ooSF sgCtpri3NiUCVs8XOEFz1KcClra/1y++VDG2mUlypBcn3a9ITyBvaMvP9n2kpUtCCrhs WCFXx4tcSsy38b6FM7AI0JYJbhc+WasWJYkP1Sj5K9zgubL+326zdFM9N6YxtlAn7a7U BnKA== MIME-Version: 1.0 X-Received: by 10.50.103.3 with SMTP id fs3mr7910274igb.6.1416369627881; Tue, 18 Nov 2014 20:00:27 -0800 (PST) Received: by 10.64.62.18 with HTTP; Tue, 18 Nov 2014 20:00:27 -0800 (PST) In-Reply-To: <26B22159-3630-493B-AAA0-BC2DEA9DBA7F@apple.com> References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <42C3C87F-0D99-47CB-B50A-9107BD10A2E6@bangj.com> <26B22159-3630-493B-AAA0-BC2DEA9DBA7F@apple.com> Date: Wed, 19 Nov 2014 13:00:27 +0900 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: Stuart Cheshire Content-Type: multipart/alternative; boundary=047d7b2e15d78a686105082e401a Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/u-p4vTBqRJqeFbrsItYqkxRL92Y Cc: "dnssd@ietf.org" , Myung-Ki Shin , Brian Haberman , Jung-Soo Park Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 04:00:32 -0000 --047d7b2e15d78a686105082e401a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Stuart, Thanks for your constructive comments. As I answered Alf's email message just before, I would like to allow IoT vendors to have an alternative way for DNS naming with more compact implementation based on IPv6 stateless autoconfiguration. For the question about how users find out the host names and which protocols are used were presented with the following slides 4 and 5 during the last dnssd WG session in Hawaii: http://www.ietf.org/proceedings/91/slides/slides-91-dnssd-6.pdf To figure out what those devices do, we can use device category and device model in the DNS name format. Paul =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Wed, Nov 19, 2014 at 7:46 AM, Stuart Cheshire wrote= : > On 17 Nov, 2014, at 17:33, Mr. Jaehoon Paul Jeong > wrote: > > > Hi Tom, > > > > You are right for appliances with enough capacity to run mDNS. > > > > However, for low capacity IoT devices without mDNS, my proposal will be > able to support an alternative way for DNS naming. > > You assert that there are devices with insufficient resources to run > DNS-SD/mDNS. > > You assert that these devices would have sufficient resources to run your > alternative. > > I think you need data to substantiate these claims. Note that devices lik= e > the SitePlayer Telnet implement DNS-SD/mDNS in under one kilobyte (about > 850 bytes of code, if I remember correctly): < > http://netmedia.com/siteplayer/telnet/> > > So you need to demonstrate that: > > 1. That there are devices where 850 bytes of code is too much. > > 2. That these devices can implement your thing in under 850 bytes. > > 3. That your thing is useful. I=E2=80=99m still unclear on what your thin= g is > useful for. Your proposal says how devices pick host names, but not how > users find out what those host names are, or find out what those devices > do, or what protocol to use to communicate with them, and how clients > resolve those host names to addresses. > > Stuart Cheshire > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --047d7b2e15d78a686105082e401a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stuart,
Thanks for your constructive comments.

As I answered Alf's email message just before,
I = would like to allow IoT vendors to have an alternative way for DNS naming
with more compact implementation based on IPv6 stateless autoconfi= guration.

For the question about how users find ou= t the host names and which protocols are used
On Wed, Nov 19, 2014 at 7:46 AM, Stuart Ches= hire <cheshire@apple.com> wrote:
On 17 Nov, 2014, at 17:33, Mr. Jaehoon Paul Jeong = <jaehoon.paul@gmail.com>= ; wrote:

> Hi Tom,
>
> You are right for appliances with enough capacity to run mDNS.
>
> However, for low capacity IoT devices without mDNS, my proposal will b= e able to support an alternative way for DNS naming.

You assert that there are devices with insufficient resources to run= DNS-SD/mDNS.

You assert that these devices would have sufficient resources to run your a= lternative.

I think you need data to substantiate these claims. Note that devices like = the SitePlayer Telnet implement DNS-SD/mDNS in under one kilobyte (about 85= 0 bytes of code, if I remember correctly): <http://netmedia.com/siteplayer/tel= net/>

So you need to demonstrate that:

1. That there are devices where 850 bytes of code is too much.

2. That these devices can implement your thing in under 850 bytes.

3. That your thing is useful. I=E2=80=99m still unclear on what your thing = is useful for. Your proposal says how devices pick host names, but not how = users find out what those host names are, or find out what those devices do= , or what protocol to use to communicate with them, and how clients resolve= those host names to addresses.

Stuart Cheshire

_______________________________________________
dnssd mailing list
dnssd@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/dnssd

--047d7b2e15d78a686105082e401a-- From nobody Wed Nov 19 15:48:54 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C14C1A1B16 for ; Wed, 19 Nov 2014 15:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAeh9B3BXn0Z for ; Wed, 19 Nov 2014 15:48:50 -0800 (PST) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 210D61A1AF3 for ; Wed, 19 Nov 2014 15:48:50 -0800 (PST) Received: by mail-qg0-f44.google.com with SMTP id z60so1358735qgd.3 for ; Wed, 19 Nov 2014 15:48:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=pp6syO2tU+t9NQY5rP/PGLDgClbcO0V1uTl5iR/UZXA=; b=iUj12tcxpTc9XZ9EucYeIDjjQHuyeRZxLE38i2BiVZJ2Ol7sHVF3spSz6pUQGcnnp6 Ud/lvV2Z0P5fa44JOWoHlHVXKlc9enDurhzaYnT7S7FyFkzlzFuSDdBQgnDKIbNeuXEl 4M0uX8HD3Sn44jqHtveaVqdVVNSukzFYzaQn+nOrtyCe5Mphvk61AcBqhUt3Lln5/kj4 K2JgjfsrctFOI7rMcALyfKUgMj9kibrG7Si04cV6cApiDy1ZHEGuGCp2bk6aKUQSH6ev hj4iuI7CUqW6DAoOGDZhP0NCLHKTobr2neOTUVj6GY9cGf8roxC+7ZaIPejgqbOdtOFg YCGw== X-Received: by 10.140.30.201 with SMTP id d67mr32031224qgd.55.1416440929335; Wed, 19 Nov 2014 15:48:49 -0800 (PST) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id 11sm668227qab.23.2014.11.19.15.48.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Nov 2014 15:48:48 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=windows-1252 From: Douglas Otis In-Reply-To: <814D0BFB77D95844A01CA29B44CBF8A7A5E576@lhreml513-mbb.china.huawei.com> Date: Wed, 19 Nov 2014 15:48:47 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <814D0BFB77D95844A01CA29B44CBF8A7A5E576@lhreml513-mbb.china.huawei.com> To: Hosnieh Rafiee X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/rWM3lDDXjBOKzNNk-5oJKbNTMZk Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Threat model - answer to questions X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Nov 2014 23:48:52 -0000 On Nov 14, 2014, at 7:08 AM, Hosnieh Rafiee = wrote: > 5- overlay networks and SSD (Douglas) >=20 > Answer: I still do not understand what is the relationship of overlay = networks to SSD. This was the case I did not know what to answer to your = question. Why should we consider this? What will happen if we do not = consider this? Dear Hosnieh, For resource constrained devices, security is best enforced by use of = ULA address space defined by RFC4193. Few CPE devices conforming with = RFC7084 permit address specific exceptions for externally initiated = sessions. This limitation makes external exposure either a default = accept or deny setting. ULAs offer a means for resource constrained = devices to make exceptions for traffic within its domain. Otherwise, = exclusion of all external initiated sessions might inhibit domain = connectivity. ULA is not an IPv6 version of RFC1918 address space normally combined = with NAT/NAPT for Internet connectivity. ULAs do not require = translations since first hop communications can leverage IPv6=92s = default support of multiple-addresses-per-interface. This permits = network overlays rather than address translation techniques. An overlay = can be achieved by using centrally or locally assigned ULA prefixes = (FC00::/8 or FD00::/8). Apple currently represents the largest = deployment of locally assigned ULA prefixes in their Back-to-My-Mac = feature by making use of L2TP tunneling. A ULA prefix is not to be advertised outside a given domain used by = agreement of those networked within the domain. Administrators need to = clearly set the scope of the ULAs and configure ACLs on relevant border = routers to enforce their scope. If internal DNS is used, administrators = should use internal-only DNS names for ULAs and might need to use split = horizon DNS to ensure internal names do not resolve on the Internet as = described in RFC6950. To maintain security, address preference rules employed by a proxy = device should properly consider use of ULAs as described by RFC7368. = Per section 2.4, a device should only use its ULA address within its = domain. Even where multiple /48 ULA prefixes are in use within a single = domain, as may occur when there are multiple Internet uplinks, utilizing = a ULA source address and a ULA destination address from two disjoint = internal ULA prefixes should still be preferred over use of GUAs. When = a device has not been specifically enabled to be externally accessible, = mDNS proxy into DNS should not publish associated GUAs. Omitting proper address selection rules is unlikely to obtain the = desired security. This consideration was omitted in both the Hybrid = Proxy and Security Threat documents. =20 Note: Last hop security depends on header compliance with RA Guard = RFC7113.=20 Regards, Douglas Otis= From nobody Wed Nov 19 16:50:50 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E26E91A8823 for ; Wed, 19 Nov 2014 16:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R198gEZ98Xkt for ; Wed, 19 Nov 2014 16:50:42 -0800 (PST) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E519A1A876F for ; Wed, 19 Nov 2014 16:50:41 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id i8so1434875qcq.11 for ; Wed, 19 Nov 2014 16:50:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:date:subject:to :message-id:mime-version; bh=cTPWsmjECnVcnOfmKZWtq67W9I9uZqktudQeTe5Doys=; b=Xs+beRYWw9hrJIkb4BjUpsfY4G3QxgGBckaVaG8jvXZfK58fA9XA8drMVdYZRI6tKT E+RTrQBG1S+hv0QB+cW/w9Q27ckzuGR3R0pG/47KMXmz8jANYdOEdusEq40IoR+B78M8 196zf9vQ3BqZEnJpZEuwEsKCsXIfL4rrTdBYEBN/HnphdfmnNc85Q1hgUjQ3NT6FHEpC FbfYII3Kk2lZfEfD5wQTPtLL33K5TfQKVH5wfcKsNc0esLoQU1qTGyfQjVPJBuMmORtn pHhrsXg6IEXKDg9oTWJPDk6ZnwfpEwWpeN9axeDwH5RdgbFS/1zZsNIZWuhWm2bkSbMh W9Kw== X-Received: by 10.140.95.225 with SMTP id i88mr54877223qge.2.1416444641166; Wed, 19 Nov 2014 16:50:41 -0800 (PST) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id 4sm761644qah.46.2014.11.19.16.50.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 19 Nov 2014 16:50:40 -0800 (PST) From: Douglas Otis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Nov 2014 16:50:39 -0800 To: dnssd@ietf.org Message-Id: <0996A6E1-5218-4AFB-8646-D1047266C9ED@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/4sMGbmeythXDDPnwWiQyEvkYhlQ Subject: [dnssd] UTF8 use in DNS populated by mDNS X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 00:50:47 -0000 =20 Dear Dnssd Wg, If UTF-8 is to be permitted in DNS populated using mDNS inputs, a = superset of rules directly and indirectly established to support safe = use of IDNA labels are necessary, otherwise omitting such requirements = would permit trivial spoofing. The requirements should include IDNA2008 = considerations that restrict permitted code points. It seems some = advocate use of spaces in a domain name label be permitted. Even this = minor change may confuse users about the specific domain when seen with = respect to commandline based applications. Regards, Douglas Otis= From nobody Thu Nov 20 07:51:49 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0131A0A6A for ; Thu, 20 Nov 2014 07:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKrLzqx_NmeA for ; Thu, 20 Nov 2014 07:51:42 -0800 (PST) Received: from mx0a-00176a03.pphosted.com (mx0a-00176a03.pphosted.com [67.231.149.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E9381A1A77 for ; Thu, 20 Nov 2014 07:51:42 -0800 (PST) Received: from pps.filterd (m0048275.ppops.net [127.0.0.1]) by m0048275.ppops.net-00176a03. (8.14.7/8.14.7) with SMTP id sAKFjQSS004998 for ; Thu, 20 Nov 2014 10:51:42 -0500 Received: from cinmlip10.e2k.ad.ge.com ([12.71.149.1]) by m0048275.ppops.net-00176a03. with ESMTP id 1qsju6r0sc-11 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 20 Nov 2014 10:51:42 -0500 Received: from unknown (HELO ALPMBHT03.e2k.ad.ge.com) ([3.159.19.196]) by cinmlip10.e2k.ad.ge.com with ESMTP/TLS/AES256-SHA; 20 Nov 2014 10:50:07 -0500 Received: from ALPURTP01.e2k.ad.ge.com (3.159.16.200) by ALPMBHT03.e2k.ad.ge.com (3.159.19.196) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 20 Nov 2014 10:51:26 -0500 Received: from CINURCNA16.e2k.ad.ge.com (3.159.212.153) by ALPURTP01.e2k.ad.ge.com (3.159.16.200) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 20 Nov 2014 10:51:26 -0500 Received: from CINURCNA14.e2k.ad.ge.com ([169.254.2.249]) by CINURCNA16.e2k.ad.ge.com ([169.254.4.111]) with mapi id 14.03.0195.001; Thu, 20 Nov 2014 10:51:25 -0500 From: "Simpson, Robby (GE Energy Management)" To: Tom Pusateri Thread-Topic: [dnssd] DNS Name Autoconfiguration for Home Network Devices Thread-Index: AQHP//BdQI7OPQKTmku9cohwx5eWnZxg2XGAgAAf7YCAAAcrAIAAjIaAgAPKQ4CAAHOeAIAD6NqA Date: Thu, 20 Nov 2014 15:51:24 +0000 Message-ID: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <42C3C87F-0D99-47CB-B50A-9107BD10A2E6@bangj.com> In-Reply-To: <42C3C87F-0D99-47CB-B50A-9107BD10A2E6@bangj.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [3.159.212.182] Content-Type: text/plain; charset="us-ascii" Content-ID: <8B3785EB99FF6F429B287916B2AC8009@mail.ad.ge.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.28, 0.0.0000 definitions=2014-11-20_07:2014-11-20,2014-11-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411200126 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/PjMx8wtT9uClPXfne1yhhZSqPjo Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , Dave Thaler , Jung-Soo Park , Ted Lemon , Sejun Lee , "Mr. Jaehoon Paul Jeong" Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 15:51:46 -0000 On 11/17/14, 6:09 PM, "Tom Pusateri" wrote: >So would this be a good use for the device-info Pseudo Service Type TXT >record? > >I haven't been able to find much on "device-info" except for it's >definition and a short email about it. > >But it seems like a TXT record with key/value pairs would be more >suitable for this type of information. >If device-info isn't right, then maybe a new service type can be defined >for this purpose. > >http://www.dns-sd.org/servicetypes.html > >http://lists.apple.com/archives/bonjour-dev/2011/Jul/msg00016.html I myself am unfamiliar with device-info as well. In general, I would be concerned about putting too much of this information in TXT records as that could be quite a lot of information being sent, particularly in mDNS environments and also particularly if the target is IoT (where battery power is at a premium, packet sizes are especially limited, etc.). If you go down the route of not putting all of this information into TXT records, you then need to decide on format (e.g., JSON, XML) and query style, thus you end up with specific service types for "your world." Which I think is OK as many of us are concentrated on different use cases. To illustrate, once again I'll show what we did with SEP 2.0 (IEEE 2030.5): We defined a service type "smartenergy". All devices that would respond to the "smartenergy" service type would then return a "dcap" TXT record. That "dcap" was a URI that would lead an interested party to a "DeviceCapabilities" resource, which spelled out where everything was located on that device. One of those was the "DeviceInformation" resource, which contained various items such as manufacturer ID, model, serial number, etc. We also defined subtypes of the "smartenergy" service type that would allow finer grained discovery by functionality, such as locating devices that offered smart metering information. Contact me off-list if you want more details of this specific use, my point here is just trying to illustrate how mDNS and DNS-SD have been used in the wild to support this kind of information. HTH, Robby From nobody Thu Nov 20 07:58:21 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420CC1A1A65 for ; Thu, 20 Nov 2014 07:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruetsZ3h7A4r for ; Thu, 20 Nov 2014 07:58:16 -0800 (PST) Received: from mx0b-00176a03.pphosted.com (mx0b-00176a03.pphosted.com [67.231.157.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06F531A0A6A for ; Thu, 20 Nov 2014 07:58:15 -0800 (PST) Received: from pps.filterd (m0048205.ppops.net [127.0.0.1]) by m0048205.ppops.net-00176a03. (8.14.7/8.14.7) with SMTP id sAKFvSXE023261 for ; Thu, 20 Nov 2014 10:58:15 -0500 Received: from cinmlip14.e2k.ad.ge.com (n165-156-000-000.static.ge.com [165.156.4.1] (may be forged)) by m0048205.ppops.net-00176a03. with ESMTP id 1qsk3u00gu-11 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for ; Thu, 20 Nov 2014 10:58:14 -0500 Received: from unknown (HELO ALPMBHT04.e2k.ad.ge.com) ([3.159.19.197]) by cinmlip14.e2k.ad.ge.com with ESMTP/TLS/AES256-SHA; 20 Nov 2014 10:50:04 -0500 Received: from CINURCNA05.e2k.ad.ge.com (3.159.212.106) by ALPMBHT04.e2k.ad.ge.com (3.159.19.197) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 20 Nov 2014 10:57:59 -0500 Received: from CINURCNA14.e2k.ad.ge.com ([169.254.2.249]) by CINURCNA05.e2k.ad.ge.com ([169.254.5.11]) with mapi id 14.03.0195.001; Thu, 20 Nov 2014 10:57:59 -0500 From: "Simpson, Robby (GE Energy Management)" To: "Mr. Jaehoon Paul Jeong" Thread-Topic: [dnssd] DNS Name Autoconfiguration for Home Network Devices Thread-Index: AQHP//BdQI7OPQKTmku9cohwx5eWnZxg2XGAgAAf7YCAAAcrAIAAjIaAgAPKQ4CAAJrlgIADw2aA Date: Thu, 20 Nov 2014 15:57:58 +0000 Message-ID: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [3.159.212.182] Content-Type: text/plain; charset="Windows-1252" Content-ID: <0C1F932E5154C04296B037B36BDAEE87@mail.ad.ge.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.28, 0.0.0000 definitions=2014-11-20_07:2014-11-20,2014-11-20,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411200128 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/9DbVFMvDu5zbhr2JDFw-CmSs8EY Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , Dave Thaler , Jung-Soo Park , Ted Lemon , Sejun Lee Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 15:58:19 -0000 Hi Paul, If the actual DNS name is used, I would be concerned by (at least) the foll= owing: - Parsing =97 clearly there will be non-compliant DNS names out there, that= these devices will have to parse and trash. Looking at your draft, how wo= uld they know? - Extensibility =97 in the future how could new information be included? N= ew categories? - Size =97 as the target is IoT, bytes on the "wire" matter and this descri= ptive information is going to be quite large in the DNS format My preference would be for devices to support some resource that is discove= red via DNS-SD =97 see my other email for details. - Robby From: "Mr. Jaehoon Paul Jeong" > Date: Monday, November 17, 2014 at 8:29 PM To: Charles Simpson > Cc: Dave Thaler >, Bria= n Haberman >, Myu= ng-Ki Shin >, "dnssd@ietf.org" >, Jung-Soo Pa= rk >, Ted Lemon >, Sejun Lee > Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices Hi Robby, Yes, my intent is to to include semantics (e.g., device category, device ve= ndor, and device model) in a standardized fashion into the DNS names of low-capacity IoT devices. I intend to place machine-interpretable semantics into the actual DNS names= themselves so that machines can use the DNS name for the identification of other machi= nes without additional service discovery through mDNS. The localization of devices is also possible with the DNS name because the DNS name can include the location of the device, as describe in Section 6 (Location-Aware DNS Name Configuration) in my draf= t: http://datatracker.ietf.org/doc/draft-jeong-homenet-device-name-autoconf/ Thanks for your good opinion. Paul =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.co= m CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Tue, Nov 18, 2014 at 6:15 AM, Simpson, Robby (GE Energy Management) > wrote: It seems to me that part of your intent is to include semantics (e.g., devi= ce category, device vendor, device model) in a standardized fashion into th= e DNS name. On the other hand, while we often apply semantics to DNS names currently fo= r human readers, these semantics typically are not standardized for machine= s. For that, we have DNS-SD. As an example from the IoT space, we use both mDNS and DNS-SD for SEP 2.0 (= IEEE 2030.5). While the DNS names often reflect aspects such as device man= ufacturer and category, these are not meant to be machine interpretable in = SEP 2.0. Rather, we use DNS-SD to advertise various functionality that is = machine interpretable. Perhaps I am misinterpreting, but is your intent to place machine-interpret= able semantics into the actual DNS names themselves? Thanks, Robby Robby Simpson, PhD System Architect GE Digital Energy M: +1 404 219 1851 Robby.Simpson@GE.com From: "Mr. Jaehoon Paul Jeong" >> Date: Saturday, November 15, 2014 at 1:22 AM To: Dave Thaler >> Cc: Brian Haberman >>, Myun= g-Ki Shin >>, "dnssd@ietf.org>" >>, Jung-Soo Park >>, Ted Lemon >>, Sejun Lee >> Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices Dave, Thanks for your clarification. In Page 32 in RFC 6762, there is the recommended course of action after pro= bing and failing, but there is no text about a random ID selection. Anyway, we can perform a random ID selection for the uniqueness of a DNS na= me, but the readability for such a DNS name is not good for the users. My original intention for DNS name generation is to include device category= (e.g., refrigerator), device vendor (e.g., Samsung), device model (e.g., RH269LP). This name itself delivers much information to users and mobile smart devic= es (e.g., smartphone or smart TV) to represent the device icon visually. I am not sure this is enough answer for your last question. If you have more comments, please let me know. Paul =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu>, jaehoon.paul@gmail.com> CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Fri, Nov 14, 2014 at 11:59 AM, Dave Thaler >> wrote: Paul wrote: > For the regeneration and verification of a unique DNS name under DNS name= conflict, > the solution in RFC 6762 recommends to use an incremental digit (such as = 2, 3, 4, etc.) > by trial and error. In an IoT scenario where there will be many IoT devic= es of the same > type, such as light bulb in home or hotel here, this incremental numberin= g approach > will be costly and slow to let each IoT device have a unique DNS name, ..= . My reading is that RFC 6762 does not _require_ an incremental digit. You c= an put in a random ID or MAC-derived ID or something else highly unlikely to collide. As such, it should not be "costly and slow". Indeed RFC 6762 does not spec= ify what you have to do. Would it be possible to recast your draft as "how to choose a unique ID and use RFC 6762" ? -Dave From nobody Thu Nov 20 11:02:25 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B241A1B32 for ; Thu, 20 Nov 2014 11:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LwOgMACt3svl for ; Thu, 20 Nov 2014 11:02:20 -0800 (PST) Received: from polaris.istumbler.net (polaris.istumbler.net [66.116.108.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF711A1A4E for ; Thu, 20 Nov 2014 11:02:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by polaris.istumbler.net (Postfix) with ESMTP id 0740B30EB62E; Thu, 20 Nov 2014 11:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at example.com Received: from polaris.istumbler.net ([127.0.0.1]) by localhost (polaris.istumbler.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xN4PgKh4WHlr; Thu, 20 Nov 2014 11:02:18 -0800 (PST) Received: from [172.20.10.2] (unknown [172.56.39.96]) by polaris.istumbler.net (Postfix) with ESMTPSA id D7C1530EB614; Thu, 20 Nov 2014 11:02:17 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Alf Watt In-Reply-To: Date: Thu, 20 Nov 2014 11:02:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <12750388-E313-4364-8D42-9DF75C91D91C@istumbler.net> References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> To: "Mr. Jaehoon Paul Jeong" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/Bcwubaw5-8B233SWvthB3xFggwI Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , Jung-Soo Park , Ted Lemon , Sejun Lee Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 19:02:23 -0000 Paul, Thank you for responding. I took the time to read through your proposal = and have the following suggestions: - carefully consider the extent to which your proposal duplicates = existing work, in particular: - 5.2.1. and 5.2.2. very closely resemble the current behavior = of mDNS nodes choosing names - 5.2.3 the =E2=80=98collector=E2=80=99 is effectively an = mDNS/DNS-SD browser which is limited to name records - Note well that mDNS/DNS-SD specifications carefully describe = the desirable caching behavior for multiple =E2=80=98collectors=E2=80=99 on a multicast = link, which significantly improves performance - carefully consider the existing uses for the DNS name label for an = internet host: - 6 - 6.2 while the concept of nested location for IoT devices = is interesting, overloading the existing name parameter to convey this information does not seem = like an appropriate tradeoff. - 6 - 6.2 it is also unclear how a device would be able to = locate itself in a particular micro or macro location and therefore generate an appropriate name for itself, = without user configuration - the =E2=80=98name=E2=80=99 of any object, networked or not, is = generally the choice of the owner. In some cultures =E2=80=98naming=E2=80=99= is synonymous with taking ownership. Taking away the = end-users ability to name their IoT objects may result in poor usability, and potentially cause = confusion with existing applications or network devices=20 which do not implement the proposed naming scheme. - while naming is important, a device only needs to be discoverable and = visible to users if some service is to be accessed: - your proposal covers only half of the solution currently = provided by mDNS/DNS-SD: local naming AND service discovery - applications connect to services, not hosts; if a host offers = no services then it does not need to be visible in a browser - most network users have little interest in discovery for the = sake of discovery, they are interested in services I suspect, that if you took the time to implement your proposal, you = would quickly realize that the existing mDNS and DNS-SD standards aren't = so much =E2=80=98overkill=E2=80=99 as the minimum set of features and = optimizations which are required to efficiently implement the user = experience your document calls for: "This DNS name lets home residents easily identify each device for = monitoring and remote-controlling it in a home network.=E2=80=9D Re-reading your proposal, no feature in it is not already possible using = mDNS/DNS-SD, perhaps paired with new record types (ULOC, MLOC, or e.g. = to represent the micro and macro location parameters, distinct from the = existing LOC record), or existing ones (make, model and etc. could for = e.g. be added to TXT records). =09 > On Nov 18, 2014, at 6:49 PM, Mr. Jaehoon Paul Jeong = wrote: >=20 > Alf, > Thanks for your kind survey information. >=20 > It seems that the devices mentioned above will be able to run mDNS. > My point is to allow IoT device vendors to have an alternative way for = a simple DNS naming=20 > that is based on IPv6 stateless autoconfiguration. >=20 > For the case where only the mapping between an IoT device's DNS name = and its IPv6 is required, > mDNS seems like an overkill. >=20 > Paul >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software / > Department of Computer Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Mobile: +82-10-4758-1765 > Fax: +82-31-290-5119 > Email: pauljeong@skku.edu, jaehoon.paul@gmail.com > CPS Lab Website: http://cpslab.skku.edu > Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php >=20 > On Wed, Nov 19, 2014 at 3:46 AM, Alf Watt wrote: > The proposal may have merit for other reasons but in terms of resource = usage for IoT devices it=E2=80=99s very instructive to look at existing = products. >=20 > The Phillips Hue lights are built around a 32 ARM core [1] with = limited RAM (128kb). The Nest Protect smoke detector is also built = around a similar 32bit ARM core from Freescale, the K60[2]. >=20 > Both of these are attached to a Zigbee radio, which provides = sufficient bandwidth for DNS-SD over mDNS, as per our charter[3]. >=20 > Devices which need service discovery on batteries will very likely be = using layer-2 discovery mechanisms for power consumption reasons (i.e. = BT-LE).=20 >=20 > I have a hard time imagining that a device with much less capabilities = than above will be a useful internet node. If it can't afford to run a = simple discovery service then what is it doing on the network? >=20 > Best, > Alf >=20 > [1] = http://www.digchip.com/datasheets/parts/datasheet/456/STM32F217VET6.php > "ARM-based 32-bit MCU, MB Flash/128+4KB RAM, crypto, USB OTG HS/FS, = Ethernet, 17 TIMs, 3 ADCs, 15 comm. interfaces & camera" > [2] = http://cache.freescale.com/files/32bit/doc/data_sheet/K60P100M100SF2V2.pdf= ?fpsp=3D1&WT_TYPE=3DData%20Sheets&WT_VENDOR=3DFREESCALE&WT_FILE_FORMAT=3Dp= df&WT_ASSET=3DDocumentation > [3] http://datatracker.ietf.org/wg/dnssd/charter/ >=20 >> On Nov 14, 2014, at 10:34 PM, Mr. Jaehoon Paul Jeong = wrote: >>=20 >> Alf, >> For embedded such as printers, cameras that have power and capacity = equivalent to smartphone, >> you are right. >>=20 >> For low-power low-capacity devices, such as light bulb and smoke = detecting sensor, >> I think that running server(s) seems not viable=20 >> even though I have no exact number of target memory and cpu size=20 >> for such low-power low-capacity IoT devices. >>=20 >> Is there anyone else to comment on the hardware specification of such = IoT devices? >>=20 >> Thanks. >>=20 >> Paul =20 >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> Mr. Jaehoon (Paul) Jeong, Ph.D. >> Assistant Professor >> Department of Software / >> Department of Computer Engineering >> Sungkyunkwan University >> Office: +82-31-299-4957 >> Mobile: +82-10-4758-1765 >> Fax: +82-31-290-5119 >> Email: pauljeong@skku.edu, jaehoon.paul@gmail.com >> CPS Lab Website: http://cpslab.skku.edu >> Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php >>=20 >> On Fri, Nov 14, 2014 at 12:02 PM, Alf Watt wrote: >> I=E2=80=99m confused, the mDNSResponder code is very lightweight and = already runs on embedded devices such as printers, cameras and may other = low-memory and low-cpu devices. >>=20 >> What is your target memory and cpu size for an IoT device? Given that = we=E2=80=99ve been using mDNS for more than a decade, the steady pace of = improvement in semiconductors means that even the smallest device will = have more than sufficient resources for mMDS. >>=20 >> Best, >> Alf >>=20 >>> On Nov 14, 2014, at 1:34 PM, Mr. Jaehoon Paul Jeong = wrote: >>>=20 >>> The solution in RFC 6762 (Multicast DNS) section 9 is viable for = regular computers,=20 >>> such as laptop, desktop, and smartphone that can afford to run mDNS = responder. >>> For IoT devices, such as light bulb and fire detecting sensor, that = have limited memory and storage, >>> mDNS seems not viable for the DNS naming for them. >>>=20 >>=20 >>=20 >=20 >=20 From nobody Thu Nov 20 14:12:16 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2D41A87BC for ; Thu, 20 Nov 2014 14:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnkpCnnknI97 for ; Thu, 20 Nov 2014 14:12:08 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07F261A87A5 for ; Thu, 20 Nov 2014 14:12:03 -0800 (PST) Received: from mx1.yitter.info (unknown [50.189.173.0]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 2D0838A031 for ; Thu, 20 Nov 2014 22:11:59 +0000 (UTC) Date: Thu, 20 Nov 2014 17:11:51 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20141120221150.GA2345@mx1.yitter.info> References: <0996A6E1-5218-4AFB-8646-D1047266C9ED@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0996A6E1-5218-4AFB-8646-D1047266C9ED@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/tvLg1xeUryPSORZuA8tlc_io0dI Subject: Re: [dnssd] UTF8 use in DNS populated by mDNS X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Nov 2014 22:12:12 -0000 Hi, On Wed, Nov 19, 2014 at 04:50:39PM -0800, Douglas Otis wrote: > If UTF-8 is to be permitted in DNS populated using mDNS inputs, a > superset of rules directly and indirectly established to support > safe use of IDNA labels are necessary, otherwise omitting such > requirements would permit trivial spoofing. The requirements should > include IDNA2008 considerations that restrict permitted code points. In which part of the DNS-SD name do you want these restrictions? I think there is considerable discussion of the different parts of those names in the draft I discussed in Honolulu. Note that there is _already_ a standard for putting "UTF-8 labels" in the DNS (going back to STD 13 and reiterated by RFC 2181). In effect, they're not "UTF-8 labels" but rather series of octets. > It seems some advocate use of spaces in a domain name label be > permitted. Even this minor change may confuse users about the > specific domain when seen with respect to commandline based > applications. This is already permitted, of course, just like anything else in labels. But as I guess is plain from my work on the mdns-dns compatibility I-D, I do think there is a long-term problem here, which is why I recommend the minimal interoperable subset. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Nov 21 04:00:33 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E4A1AD415 for ; Fri, 21 Nov 2014 04:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5DEe4ptD_jNe for ; Fri, 21 Nov 2014 04:00:24 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 738021AD384 for ; Fri, 21 Nov 2014 04:00:16 -0800 (PST) Received: by mail-ig0-f172.google.com with SMTP id hl2so6439361igb.5 for ; Fri, 21 Nov 2014 04:00:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0yfx1fgzw7/LS6Z1+4YU+bySqguILzKyg0uB0pofkR0=; b=BHFasfTOlQDlyd4t3z/kyIxk+YrNERaMnx5JfZB5EmNVtGD6g9wvRR9HJPGQKvyOig 0AYOi0GPPZYGu54+mUIDAtEXU9GB/imcfXtkSJVF4L3jDy/ax0NtbYUfJnLnEmvYf/3d Rf1bGslzpCOEA/mlvAP2x1XDjUjk+Pe6rAAdT3Us4LbIbACZg98qJ925rlX2coy4s/IM Iz6jabTvEb9qpaS3NQZc/agPheK93UbD3K1CQrF6zvWdAHjw77n40ut7HgEmpWIOYswq s5uwk1KrjCrFTXCLgKBiewOIq04Rv3IymbCxc48EuGCZJPjWEjhPA8ExCXMfwXaI2oR2 T9iw== MIME-Version: 1.0 X-Received: by 10.42.110.195 with SMTP id r3mr12331314icp.12.1416571215367; Fri, 21 Nov 2014 04:00:15 -0800 (PST) Received: by 10.64.57.12 with HTTP; Fri, 21 Nov 2014 04:00:15 -0800 (PST) In-Reply-To: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> Date: Fri, 21 Nov 2014 21:00:15 +0900 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: "Simpson, Robby (GE Energy Management)" Content-Type: multipart/alternative; boundary=20cf303dda42177d2f05085d3026 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/uCsXNZa8ns-kImmNvdg6IS9tSA0 Cc: "dnssd@ietf.org" , Myung-Ki Shin , Ted Lemon , Brian Haberman , Jung-Soo Park Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 12:00:30 -0000 --20cf303dda42177d2f05085d3026 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Robby, Thanks for your questions. >Hi Paul, > >If the actual DNS name is used, I would be concerned by (at least) the following: >- Parsing =E2=80=94 clearly there will be non-compliant DNS names out ther= e, that these devices will have to parse and trash. Looking at your draft, how would they know? In my proposal, an IoT device does not process the DNS query because it does not run mDNS for the DNS name resolution service. Since the DNS name of the IoT device is registered into a DNS server via a router that is located at the same subnet with the IoT device. >- Extensibility =E2=80=94 in the future how could new information be inclu= ded? New categories? When a new category is added into a new device's repository as factory default, such a new category will be used by the device for generating its DNS name. >- Size =E2=80=94 as the target is IoT, bytes on the "wire" matter and this descriptive information is going to be quite large in the DNS format In the case where the DNS name of an IoT device cannot be accommodated and delivered by a MAC frame to a router for the DNS name registration, multiple MAC frames having parts of the DNS name will be sent and merged at a gateway or router within the communication range of the IoT device. For 6LoWPAN, we can consider a compact DNS name format for IoT device for the given device category and model. Paul > >My preference would be for devices to support some resource that is discovered via DNS-SD =E2=80=94 see my other email for details. > >- Robby =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Fri, Nov 21, 2014 at 12:57 AM, Simpson, Robby (GE Energy Management) < robby.simpson@ge.com> wrote: > Hi Paul, > > If the actual DNS name is used, I would be concerned by (at least) the > following: > - Parsing =E2=80=94 clearly there will be non-compliant DNS names out the= re, that > these devices will have to parse and trash. Looking at your draft, how > would they know? > - Extensibility =E2=80=94 in the future how could new information be incl= uded? > New categories? > - Size =E2=80=94 as the target is IoT, bytes on the "wire" matter and thi= s > descriptive information is going to be quite large in the DNS format > > My preference would be for devices to support some resource that is > discovered via DNS-SD =E2=80=94 see my other email for details. > > - Robby > > From: "Mr. Jaehoon Paul Jeong" jaehoon.paul@gmail.com>> > Date: Monday, November 17, 2014 at 8:29 PM > To: Charles Simpson > > Cc: Dave Thaler >, > Brian Haberman = >, > Myung-Ki Shin >, " > dnssd@ietf.org" dnssd@ietf.org>>, Jung-Soo Park >, > Ted Lemon >, Sejun > Lee > > Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices > > Hi Robby, > Yes, my intent is to to include semantics (e.g., device category, device > vendor, and device model) > in a standardized fashion into the DNS names of low-capacity IoT devices. > > I intend to place machine-interpretable semantics into the actual DNS > names themselves > so that machines can use the DNS name for the identification of other > machines > without additional service discovery through mDNS. > > The localization of devices is also possible with the DNS name > because the DNS name can include the location of the device, > as describe in Section 6 (Location-Aware DNS Name Configuration) in my > draft: > http://datatracker.ietf.org/doc/draft-jeong-homenet-device-name-autoconf/ > > Thanks for your good opinion. > > Paul > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software / > Department of Computer Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Mobile: +82-10-4758-1765 > Fax: +82-31-290-5119 > Email: pauljeong@skku.edu, > jaehoon.paul@gmail.com > CPS Lab Website: http://cpslab.skku.edu > Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php > > On Tue, Nov 18, 2014 at 6:15 AM, Simpson, Robby (GE Energy Management) < > robby.simpson@ge.com> wrote: > It seems to me that part of your intent is to include semantics (e.g., > device category, device vendor, device model) in a standardized fashion > into the DNS name. > > On the other hand, while we often apply semantics to DNS names currently > for human readers, these semantics typically are not standardized for > machines. For that, we have DNS-SD. > > As an example from the IoT space, we use both mDNS and DNS-SD for SEP 2.0 > (IEEE 2030.5). While the DNS names often reflect aspects such as device > manufacturer and category, these are not meant to be machine interpretabl= e > in SEP 2.0. Rather, we use DNS-SD to advertise various functionality tha= t > is machine interpretable. > > Perhaps I am misinterpreting, but is your intent to place > machine-interpretable semantics into the actual DNS names themselves? > > Thanks, > Robby > > > Robby Simpson, PhD > > System Architect > > GE > > Digital Energy > > M: +1 404 219 1851 > > Robby.Simpson@GE.com > > > From: "Mr. Jaehoon Paul Jeong" jaehoon.paul@gmail.com> jaehoon.paul@gmail.com>>> > Date: Saturday, November 15, 2014 at 1:22 AM > To: Dave Thaler >>> > Cc: Brian Haberman brian@innovationslab.net> brian@innovationslab.net>>>, Myung-Ki Shin mkshin@etri.re.kr>>>, = " > dnssd@ietf.org dnssd@ietf.org>>" dnssd@ietf.org>>, Jung-Soo Park >>, > Ted Lemon Ted.Lemon@nominum.com>>, Sejun Lee < > prosejun14@gmail.com prosejun14@gmail.com>> > Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices > > Dave, > Thanks for your clarification. > > In Page 32 in RFC 6762, there is the recommended course of action after > probing and failing, but > there is no text about a random ID selection. > Anyway, we can perform a random ID selection for the uniqueness of a DNS > name, but > the readability for such a DNS name is not good for the users. > > My original intention for DNS name generation is to include device > category (e.g., refrigerator), > device vendor (e.g., Samsung), device model (e.g., RH269LP). > This name itself delivers much information to users and mobile smart > devices (e.g., smartphone or smart TV) > to represent the device icon visually. > > I am not sure this is enough answer for your last question. > If you have more comments, please let me know. > > Paul > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software / > Department of Computer Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Mobile: +82-10-4758-1765 > Fax: +82-31-290-5119 > Email: pauljeong@skku.edu pauljeong@skku.edu>, jaehoon.paul@gmail.com > jaehoon.paul@gmail.com>> > CPS Lab Website: http://cpslab.skku.edu > Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php > > On Fri, Nov 14, 2014 at 11:59 AM, Dave Thaler dthaler@microsoft.com>>> wrote: > Paul wrote: > > For the regeneration and verification of a unique DNS name under DNS > name conflict, > > the solution in RFC 6762 recommends to use an incremental digit (such a= s > 2, 3, 4, etc.) > > by trial and error. In an IoT scenario where there will be many IoT > devices of the same > > type, such as light bulb in home or hotel here, this incremental > numbering approach > > will be costly and slow to let each IoT device have a unique DNS name, > ... > > My reading is that RFC 6762 does not _require_ an incremental digit. You > can put in > a random ID or MAC-derived ID or something else highly unlikely to collid= e. > As such, it should not be "costly and slow". Indeed RFC 6762 does not > specify what > you have to do. Would it be possible to recast your draft as > "how to choose a unique ID and use RFC 6762" ? > > -Dave > > > --20cf303dda42177d2f05085d3026 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Robby,
Thanks for your questions.

>Hi Paul,
>
>If the actual DNS name is used, I would be con= cerned by (at least) the following:
>- Parsing =E2=80=94 clearly there will be non-compliant DNS n= ames out there, that these devices will have to parse and trash.=C2=A0 Look= ing at your draft, how would they know?

In my pro= posal, an IoT device does not process the DNS query because it does not run= mDNS=C2=A0
for the DNS name resolution service.
Since = the DNS name of the IoT device is registered into a DNS server via a router= that=C2=A0
is located at the same subnet with the IoT device.

>- Extensibility =E2= =80=94 in the future how could new information be included?=C2=A0 New categ= ories?

When a new category is added into a = new device's repository as factory default,
such a new catego= ry will be used by the device for generating its DNS name.

>- Size =E2=80=94 as the target is = IoT, bytes on the "wire" matter and this descriptive information = is going to be quite large in the DNS format

In the case where the DNS name of an IoT device cannot be accommodated an= d delivered by a MAC frame=C2=A0
to a router for the DNS name reg= istration, multiple MAC frames having parts of the DNS name will be sent an= d=C2=A0
merged at a gateway or router within the communication ra= nge of the IoT device.
For 6LoWPAN, we can consider a compact DNS= name format for IoT device for the given device category=C2=A0
a= nd model.

Paul

>
>My preference would be for devices to support some resource that i= s discovered via DNS-SD =E2=80=94 see my other email for details.>
>- Robby

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant ProfessorDepartment of Software /
Department of Computer Engineering
Sungkyu= nkwan University
Office: +82-31-299-4957
Mobile: +82-10-4758-1765
= Fax: +82-31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmail.com
CPS Lab Website: http://cpslab.skku.eduPersonal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php<= br>

On Fri, Nov 21, 2014 at 12:57 AM, Simpson, R= obby (GE Energy Management) <robby.simpson@ge.com> wrote:=
Hi Paul,

If the actual DNS name is used, I would be concerned by (at least) the foll= owing:
- Parsing =E2=80=94 clearly there will be non-compliant DNS names out there= , that these devices will have to parse and trash.=C2=A0 Looking at your dr= aft, how would they know?
- Extensibility =E2=80=94 in the future how could new information be includ= ed?=C2=A0 New categories?
- Size =E2=80=94 as the target is IoT, bytes on the "wire" matter= and this descriptive information is going to be quite large in the DNS for= mat

My preference would be for devices to support some resource that is discove= red via DNS-SD =E2=80=94 see my other email for details.

- Robby

From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com<mailto:jaehoon.paul@gmail.com>>
Date: Monday, November 17, 2014 at 8:29 PM
To: Charles Simpson <Robby.Simpson@GE.com<mailto:Robby.Simpson@GE.com>>
Cc: Dave Thaler <dthaler@micros= oft.com<mailto:dthaler@micr= osoft.com>>, Brian Haberman <brian@innovationslab.net<mailto:brian@innovationslab.net>>, Myung-Ki Shin <= mkshin@etri.re.kr<mailto:mkshin@etri.re.kr>>, "dnssd@ietf.org<mailto:dnssd@ietf.org>" <dnssd@ietf.org<mailto:dnssd= @ietf.org>>, Jung-Soo Park <= pjs@etri.re.kr<mailto:pjs@etri.re.= kr>>, Ted Lemon <Ted.= Lemon@nominum.com<mailto:Te= d.Lemon@nominum.com>>, Sejun Lee <prosejun14@gmail.com<mailto:prosejun14@gmail.com>>
Subject: Re: [dnssd] DNS Name Autoconfiguration for Home N= etwork Devices

Hi Robby,
Yes, my intent is to to include semantics (e.g., device category, device ve= ndor, and device model)
in a standardized fashion into the DNS names of low-capacity IoT devices.
I intend to place machine-interpretable semantics into the actual DNS names= themselves
so that machines can use the DNS name for the identification of other machi= nes
without additional service discovery through mDNS.

The localization of devices is also possible with the DNS name
because the DNS name can include the location of the device,
as describe in Section 6 (Location-Aware DNS Name Configuration) in my draf= t:
http://datatracker.ietf.org/doc/draft-jeong-ho= menet-device-name-autoconf/

Thanks for your good opinion.

Paul

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software /
Department of Computer Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Email: paulje= ong@skku.edu<mailto:pauljeong@= skku.edu>, jaehoon.paul@gm= ail.com<mailto:jaehoon.pau= l@gmail.com>
CPS Lab Website: http:= //cpslab.skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php
On Tue, Nov 18, 2014 at 6:15 AM, Simpson, Robby (GE= Energy Management) <robby.simps= on@ge.com<mailto:robby.simps= on@ge.com>> wrote:
It seems to me that part of your intent is to include semantics (e.g., devi= ce category, device vendor, device model) in a standardized fashion into th= e DNS name.

On the other hand, while we often apply semantics to DNS names currently fo= r human readers, these semantics typically are not standardized for machine= s.=C2=A0 For that, we have DNS-SD.

As an example from the IoT space, we use both mDNS and DNS-SD for SEP 2.0 (= IEEE 2030.5).=C2=A0 While the DNS names often reflect aspects such as devic= e manufacturer and category, these are not meant to be machine interpretabl= e in SEP 2.0.=C2=A0 Rather, we use DNS-SD to advertise various functionalit= y that is machine interpretable.

Perhaps I am misinterpreting, but is your intent to place machine-interpret= able semantics into the actual DNS names themselves?

Thanks,
Robby


Robby Simpson, PhD

System Architect

GE

Digital Energy

M: +1 404 219 1851

Robby.Simpson@GE.com<mailto:Robby.Simpson@GE.com>


From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com<mailto:jaehoon.paul@gmail.com><mailto:jaehoon.paul@gmail.com<mailto:jaehoon.paul@gmail.com>>>
Date: Saturday, November 15, 2014 at 1:22 AM
To: Dave Thaler <dthaler= @microsoft.com<mailto:dthal= er@microsoft.com><mailto:dthaler@microsoft.com<mailto:dthaler@microsoft.com>>>
Cc: Brian Haberman <brian@in= novationslab.net<mailto:= brian@innovationslab.net><mailto:brian@innovationslab.net<mailto:brian@innovationslab.net>>>, Myung-Ki Shin= <mkshin@etri.re.kr<mailto:<= a href=3D"mailto:mkshin@etri.re.kr">mkshin@etri.re.kr><mailto:mkshin@etri.re.kr<mailto:mkshin@etri.re.kr>>>, "dnssd@ietf.org<mailto:dnssd@ietf.org><mailto:dnssd@ietf.org<mailto:dn= ssd@ietf.org>>" <dnssd@= ietf.org<mailto:dnssd@ietf.org= ><mailto:dnssd@ietf.org<mail= to:dnssd@ietf.org>>>, Jung-S= oo Park <pjs@etri.re.kr<mailto:= pjs@etri.re.kr><mailto:pjs@etri.re.kr<mailto:pjs@etri.re.kr>>>, Ted Lemon <Ted.Lemon@nominum.com<mailto:Ted.Lemon@nominum.com><mailto:Ted.Lemon@nominum.com<mailto:Ted.Lemon@nominum.com>>>,= Sejun Lee <prosejun14@gmail.com= <mailto:prosejun14@gmail.com= ><mailto:prosejun14@gmail= .com<mailto:prosejun14@gmail= .com>>>
Subject: Re: [dnssd] DNS Name Autoconfiguration for Home N= etwork Devices

Dave,
Thanks for your clarification.

In Page 32 in RFC 6762, there is the recommended course of action after pro= bing and failing, but
there is no text about a random ID selection.
Anyway, we can perform a random ID selection for the uniqueness of a DNS na= me, but
the readability for such a DNS name is not good for the users.

My original intention for DNS name generation is to include device category= (e.g., refrigerator),
device vendor (e.g., Samsung), device model (e.g., RH269LP).
This name itself delivers much information to users and mobile=C2=A0 smart = devices (e.g., smartphone or smart TV)
to represent the device icon visually.

I am not sure this is enough answer for your last question.
If you have more comments, please let me know.

Paul

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software /
Department of Computer Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Email: pauljeong@skku.edu&= lt;mailto:pauljeong@skku.edu>&= lt;mailto:pauljeong@skku.edu<m= ailto:pauljeong@skku.edu>>,= jaehoon.paul@gmail.com<ma= ilto:jaehoon.paul@gmail.com&g= t;<mailto:jaehoon.paul@gmail.c= om<mailto:jaehoon.paul@gma= il.com>>
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php
On Fri, Nov 14, 2014 at 11:5= 9 AM, Dave Thaler <dthaler@micr= osoft.com<mailto:dthaler@mi= crosoft.com><mailto:dtha= ler@microsoft.com<mailto:dt= haler@microsoft.com>>> wrote:
Paul wrote:
> For the regeneration and verification of a unique DNS name under DNS n= ame conflict,
> the solution in RFC 6762 recommends to use an incremental digit (such = as 2, 3, 4, etc.)
> by trial and error. In an IoT scenario where there will be many IoT de= vices of the same
> type, such as light bulb in home or hotel here, this incremental numbe= ring approach
> will be costly and slow to let each IoT device have a unique DNS name,= ...

My reading is that RFC 6762 does not _require_ an incremental digit.=C2=A0 = You can put in
a random ID or MAC-derived ID or something else highly unlikely to collide.=
As such, it should not be "costly and slow".=C2=A0 Indeed RFC 676= 2 does not specify what
you have to do.=C2=A0 =C2=A0Would it be possible to recast your draft as "how to choose a unique ID and use RFC 6762" ?

-Dave



--20cf303dda42177d2f05085d3026-- From nobody Fri Nov 21 04:55:50 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486AB1A0363 for ; Fri, 21 Nov 2014 04:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPTvMShhQ9zq for ; Fri, 21 Nov 2014 04:55:39 -0800 (PST) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF881A0164 for ; Fri, 21 Nov 2014 04:55:39 -0800 (PST) Received: by mail-ie0-f178.google.com with SMTP id tp5so4680821ieb.23 for ; Fri, 21 Nov 2014 04:55:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Qpjh//vQJfs2uEJ9Cnyzwsajl6bKifeXuomJrzS0NFI=; b=OFknLoo7N02N+ORGIipz3O/q2AAEhNsStFdqB9x0ydZCeWrR0KMXqBcIi4qNW8ZvyP zIWMbBvoAEAI88j4niuwaNoc1bxas6Pe6E3Yu5w8N1g/8S1CEFJjTQUch48LjGoaa6m7 zhgMhuoJlqpk+oUCgNQlIcaa1XrB+4k+OqvEFrUqXCuCWFxxE40SaE9eh0l0X6z/Xtu/ FV6ZGKtFF2YCfzkbFfJMnzKtEZYZUkGDEm+9yjBl5TsmyfHhtN3q6PK9RU4WT5P8FEsz RUzrsDzvU+V1xAoyI3t8mPHxLpyxJyUngJro2XT98+oRd05O2MNk6T8LLMvnDbDQnzgB y7Hw== MIME-Version: 1.0 X-Received: by 10.107.156.131 with SMTP id f125mr3768915ioe.15.1416574538348; Fri, 21 Nov 2014 04:55:38 -0800 (PST) Received: by 10.64.57.12 with HTTP; Fri, 21 Nov 2014 04:55:38 -0800 (PST) In-Reply-To: <12750388-E313-4364-8D42-9DF75C91D91C@istumbler.net> References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <12750388-E313-4364-8D42-9DF75C91D91C@istumbler.net> Date: Fri, 21 Nov 2014 21:55:38 +0900 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: Alf Watt Content-Type: multipart/alternative; boundary=001a1140c8d828336605085df612 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/BKLand0k-wKsksj5ATscnwSZ1o8 Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , Jung-Soo Park , Ted Lemon , Sejun Lee Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 12:55:47 -0000 --001a1140c8d828336605085df612 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alf, It seems like you didn't attend the last DNSSD WG session in Hawaii. Though my draft lacks explanation for DNS name registration into a DNS server, I did explain the presentation at the last DNSSD WG session with the following slides, especially slide 5: http://www.ietf.org/proceedings/91/slides/slides-91-dnssd-6.pdf >Paul, > >Thank you for responding. I took the time to read through your proposal and have the following suggestions: > >- carefully consider the extent to which your proposal duplicates existing work, in particular: > > - 5.2.1. and 5.2.2. very closely resemble the current behavior of mDNS nodes choosing names > Though there exists a similarity for the DNS name generation, the difference is that my scheme uses the device category and device model for the DNS name to let an IoT device be identified for its functionality without an explicit service discovery procedure. > - 5.2.3 the =E2=80=98collector=E2=80=99 is effectively an mDNS/DNS= -SD browser which is limited to name records > Well, not exactly the same. The collector is either a router or host that uses Node Information protocol rather than mDNS. > - Note well that mDNS/DNS-SD specifications carefully describe the desirable caching behavior > for multiple =E2=80=98collectors=E2=80=99 on a multicast l= ink, which significantly improves performance > >- carefully consider the existing uses for the DNS name label for an internet host: > > - 6 - 6.2 while the concept of nested location for IoT devices is interesting, overloading the existing > name parameter to convey this information does not seem like an appropriate tradeoff. > The method to find out the micro-location is out of scope in this scope. It is assumed that the micro-location information (e.g., refrigerator) for the macro-location information (e.g., kitchen) is available. The localization of the micro-location and macro-location is the current feasible research subject under the development of my research lab. We have a preliminary result based on simulation in an apartment. > - 6 - 6.2 it is also unclear how a device would be able to locate itself in a particular micro or macro location > and therefore generate an appropriate name for itself, without user configuration Like the above answer, the micro or macro location can be autoconfigured by the smartphone in indoor environments, such as an apartment. Take a look at the slide 9 among the slides that were presented at Homenet WG in the last IETF meeting: http://www.ietf.org/proceedings/91/slides/slides-91-homenet-4.pdf > > - the =E2=80=98name=E2=80=99 of any object, networked or not, is g= enerally the choice of the owner. In some cultures =E2=80=98naming=E2=80=99 > is synonymous with taking ownership. Taking away the end-users ability to name their IoT objects may > result in poor usability, and potentially cause confusion with existing applications or network devices > which do not implement the proposed naming scheme. > My draft does not prevent end-users from manually configuring DNS name for their IoT devices. As you know, an IPv6 interface of the IoT device can have more than a DNS name for the given, same IPv6 address. >- while naming is important, a device only needs to be discoverable and visible to users if some service is to be accessed: > - your proposal covers only half of the solution currently provided by mDNS/DNS-SD: local naming AND service discovery > - applications connect to services, not hosts; if a host offers no services then it does not need to be visible in a browser > - most network users have little interest in discovery for the sake of discovery, they are interested in services > In my scheme, the device category and device type including vendor are included into a DNS name, these can be used to let users identify the available services when a database having the mapping the service information for the device category and device type (such as unicast-based DNS server at home) is available to the users. In my approach, a unicast-based DNS server is required with the mapping information of DNS names and IPv6 addresses of IoT devices rather than running individual mDNS per IoT device. >I suspect, that if you took the time to implement your proposal, you would quickly realize that the existing mDNS and DNS-SD standards aren't so much =E2=80=98overkill=E2=80=99 as the minimum set of features and optimizations= which are required to >efficiently implement the user experience your document calls for: > In my approach, IoT devices need a generic IPv6 stack with handling additional ICMPv6 options, such as DAD for DNS name and Node Information Protocol rather than mDNS as application. We need to consider which approach is easy for the implementers. Paul >"This DNS name lets home residents easily identify each device for monitoring and remote-controlling it in a home network.=E2=80=9D > >Re-reading your proposal, no feature in it is not already possible using mDNS/DNS-SD, perhaps paired with new record types (ULOC, MLOC, or e.g. to represent the micro and macro location parameters, distinct from the existing LOC record), or existing ones (make, model and etc. could for e.g. be added to TXT records). > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Fri, Nov 21, 2014 at 4:02 AM, Alf Watt wrote: > Paul, > > Thank you for responding. I took the time to read through your proposal > and have the following suggestions: > > - carefully consider the extent to which your proposal duplicates existin= g > work, in particular: > > - 5.2.1. and 5.2.2. very closely resemble the current behavior of > mDNS nodes choosing names > > - 5.2.3 the =E2=80=98collector=E2=80=99 is effectively an mDNS/DN= S-SD browser > which is limited to name records > > - Note well that mDNS/DNS-SD specifications carefully describe th= e > desirable caching behavior > for multiple =E2=80=98collectors=E2=80=99 on a multicast = link, which > significantly improves performance > > - carefully consider the existing uses for the DNS name label for an > internet host: > > - 6 - 6.2 while the concept of nested location for IoT devices is > interesting, overloading the existing > name parameter to convey this information does not seem > like an appropriate tradeoff. > > - 6 - 6.2 it is also unclear how a device would be able to locate > itself in a particular micro or macro location > and therefore generate an appropriate name for itself, > without user configuration > > - the =E2=80=98name=E2=80=99 of any object, networked or not, is = generally the > choice of the owner. In some cultures =E2=80=98naming=E2=80=99 > is synonymous with taking ownership. Taking away the > end-users ability to name their IoT objects may > result in poor usability, and potentially cause confusion > with existing applications or network devices > which do not implement the proposed naming scheme. > > - while naming is important, a device only needs to be discoverable and > visible to users if some service is to be accessed: > - your proposal covers only half of the solution currently > provided by mDNS/DNS-SD: local naming AND service discovery > - applications connect to services, not hosts; if a host offers n= o > services then it does not need to be visible in a browser > - most network users have little interest in discovery for the > sake of discovery, they are interested in services > > I suspect, that if you took the time to implement your proposal, you woul= d > quickly realize that the existing mDNS and DNS-SD standards aren't so muc= h > =E2=80=98overkill=E2=80=99 as the minimum set of features and optimizatio= ns which are > required to efficiently implement the user experience your document calls > for: > > "This DNS name lets home residents easily identify each device for > monitoring and remote-controlling it in a home network.=E2=80=9D > > Re-reading your proposal, no feature in it is not already possible using > mDNS/DNS-SD, perhaps paired with new record types (ULOC, MLOC, or e.g. to > represent the micro and macro location parameters, distinct from the > existing LOC record), or existing ones (make, model and etc. could for e.= g. > be added to TXT records). > > > > > On Nov 18, 2014, at 6:49 PM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > > > > Alf, > > Thanks for your kind survey information. > > > > It seems that the devices mentioned above will be able to run mDNS. > > My point is to allow IoT device vendors to have an alternative way for = a > simple DNS naming > > that is based on IPv6 stateless autoconfiguration. > > > > For the case where only the mapping between an IoT device's DNS name an= d > its IPv6 is required, > > mDNS seems like an overkill. > > > > Paul > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > Mr. Jaehoon (Paul) Jeong, Ph.D. > > Assistant Professor > > Department of Software / > > Department of Computer Engineering > > Sungkyunkwan University > > Office: +82-31-299-4957 > > Mobile: +82-10-4758-1765 > > Fax: +82-31-290-5119 > > Email: pauljeong@skku.edu, jaehoon.paul@gmail.com > > CPS Lab Website: http://cpslab.skku.edu > > Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php > > > > On Wed, Nov 19, 2014 at 3:46 AM, Alf Watt wrote: > > The proposal may have merit for other reasons but in terms of resource > usage for IoT devices it=E2=80=99s very instructive to look at existing p= roducts. > > > > The Phillips Hue lights are built around a 32 ARM core [1] with limited > RAM (128kb). The Nest Protect smoke detector is also built around a simil= ar > 32bit ARM core from Freescale, the K60[2]. > > > > Both of these are attached to a Zigbee radio, which provides sufficient > bandwidth for DNS-SD over mDNS, as per our charter[3]. > > > > Devices which need service discovery on batteries will very likely be > using layer-2 discovery mechanisms for power consumption reasons (i.e. > BT-LE). > > > > I have a hard time imagining that a device with much less capabilities > than above will be a useful internet node. If it can't afford to run a > simple discovery service then what is it doing on the network? > > > > Best, > > Alf > > > > [1] > http://www.digchip.com/datasheets/parts/datasheet/456/STM32F217VET6.php > > "ARM-based 32-bit MCU, MB Flash/128+4KB RAM, crypto, USB OTG HS/FS, > Ethernet, 17 TIMs, 3 ADCs, 15 comm. interfaces & camera" > > [2] > http://cache.freescale.com/files/32bit/doc/data_sheet/K60P100M100SF2V2.pd= f?fpsp=3D1&WT_TYPE=3DData%20Sheets&WT_VENDOR=3DFREESCALE&WT_FILE_FORMAT=3Dp= df&WT_ASSET=3DDocumentation > > [3] http://datatracker.ietf.org/wg/dnssd/charter/ > > > >> On Nov 14, 2014, at 10:34 PM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > >> > >> Alf, > >> For embedded such as printers, cameras that have power and capacity > equivalent to smartphone, > >> you are right. > >> > >> For low-power low-capacity devices, such as light bulb and smoke > detecting sensor, > >> I think that running server(s) seems not viable > >> even though I have no exact number of target memory and cpu size > >> for such low-power low-capacity IoT devices. > >> > >> Is there anyone else to comment on the hardware specification of such > IoT devices? > >> > >> Thanks. > >> > >> Paul > >> > >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >> Mr. Jaehoon (Paul) Jeong, Ph.D. > >> Assistant Professor > >> Department of Software / > >> Department of Computer Engineering > >> Sungkyunkwan University > >> Office: +82-31-299-4957 > >> Mobile: +82-10-4758-1765 > >> Fax: +82-31-290-5119 > >> Email: pauljeong@skku.edu, jaehoon.paul@gmail.com > >> CPS Lab Website: http://cpslab.skku.edu > >> Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php > >> > >> On Fri, Nov 14, 2014 at 12:02 PM, Alf Watt wrote: > >> I=E2=80=99m confused, the mDNSResponder code is very lightweight and a= lready > runs on embedded devices such as printers, cameras and may other low-memo= ry > and low-cpu devices. > >> > >> What is your target memory and cpu size for an IoT device? Given that > we=E2=80=99ve been using mDNS for more than a decade, the steady pace of > improvement in semiconductors means that even the smallest device will ha= ve > more than sufficient resources for mMDS. > >> > >> Best, > >> Alf > >> > >>> On Nov 14, 2014, at 1:34 PM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > >>> > >>> The solution in RFC 6762 (Multicast DNS) section 9 is viable for > regular computers, > >>> such as laptop, desktop, and smartphone that can afford to run mDNS > responder. > >>> For IoT devices, such as light bulb and fire detecting sensor, that > have limited memory and storage, > >>> mDNS seems not viable for the DNS naming for them. > >>> > >> > >> > > > > > > --001a1140c8d828336605085df612 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Alf,
It seems like you didn't attend the last DNSSD WG session= in Hawaii.
Though my draft lacks explanation for DNS name registration i= nto a DNS server,
I did explain the presentation at the last DNSSD WG ses= sion with the following slides,=C2=A0
especially slide 5:
http://www.ietf.org/proceedings/91/slid= es/slides-91-dnssd-6.pdf

>Paul,
>
>Thank you for responding. I took the time to read through = your proposal and have the following suggestions:
>
>- carefully consider the extent to which your proposal dupli= cates existing work, in particular:
>
>= ; =C2=A0 =C2=A0 =C2=A0 =C2=A0- 5.2.1. and 5.2.2. very closely resemble the = current behavior of mDNS nodes choosing names
>

Though there exi= sts a similarity for the DNS name generation, the difference is that my sch= eme uses
the device category and device model for the DNS name to= let an IoT device be identified for its functionality
without an= explicit service discovery procedure.

> =C2=A0 =C2=A0 =C2=A0 =C2=A0- 5.2= .3 the =E2=80=98collector=E2=80=99 is effectively an mDNS/DNS-SD browser wh= ich is limited to name records
>

Well, not exactly the sam= e.
The collector is either a router or host that uses Node Inform= ation protocol rather than mDNS.

> =C2=A0 =C2=A0 =C2=A0 =C2=A0- Note well= that mDNS/DNS-SD specifications carefully describe the desirable caching b= ehavior
> =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0for multiple =E2=80=98collectors= =E2=80=99 on a multicast link, which significantly improves performance
>
>- carefully consider the existing use= s for the DNS name label for an internet host:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0- 6 - 6.2 while the concept of nest= ed location for IoT devices is interesting, overloading the existing=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0name parameter to convey this information does = not seem like an appropriate tradeoff.
>

The method to fin= d out the micro-location is out of scope in this scope.
It is ass= umed that the micro-location information (e.g., refrigerator) for the macro= -location information (e.g., kitchen)=C2=A0
is available.
The localization of the micro-location and macro-location is the current= feasible research subject under=C2=A0
the development of my rese= arch lab. We have a preliminary result based on simulation in an apartment.=

= > =C2=A0 =C2=A0 =C2=A0 =C2=A0- 6 - 6.2 it is also unclear how a device w= ould be able to locate itself in a particular micro or macro location
> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and therefore generate an appropriate name f= or itself, without user configuration

Like = the above answer, the micro or macro location can be autoconfigured by the = smartphone in indoor environments,
such as an apartment. Take a l= ook at the slide 9 among the slides that were presented at Homenet WG=C2=A0=
in the last IETF meeting:

>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0- the =E2=80= =98name=E2=80=99 of any object, networked or not, is generally the choice o= f the owner. In some cultures =E2=80=98naming=E2=80=99
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0is synonymous with taking ownership. Taking away the end-user= s ability to name their IoT objects may
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0r= esult in poor usability, and potentially cause confusion with existing appl= ications or network devices
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0which do not = implement the proposed naming scheme.
>

My draft does not = prevent end-users from manually configuring DNS name for their IoT devices.=
As you know, an IPv6 interface of the IoT device can have more t= han a DNS name for the given, same IPv6 address.

>- while naming is impo= rtant, a device only needs to be discoverable and visible to users if some = service is to be accessed:
> =C2=A0 =C2=A0 =C2=A0 =C2=A0- your proposal covers only half of the so= lution currently provided by mDNS/DNS-SD: local naming AND service discover= y
> =C2=A0 =C2=A0 =C2= =A0 =C2=A0- applications connect to services, not hosts; if a host offers n= o services then it does not need to be visible in a browser
> =C2=A0 =C2=A0 =C2=A0 =C2=A0- most ne= twork users have little interest in discovery for the sake of discovery, th= ey are interested in services
>

In my scheme, the device c= ategory and device type including vendor are included into a DNS name,
these can be used to let users identify the available services when a= database having the mapping=C2=A0
the service information for th= e device category and device type (such as unicast-based DNS server at home= )
is available to the users.

In my appro= ach, a unicast-based DNS server is required with the mapping information of= DNS names and IPv6 addresses
of IoT devices rather than running = individual mDNS per IoT device.

>I suspect, that if you took the time to = implement your proposal, you would quickly realize that the existing mDNS a= nd DNS-SD standards aren't so much =E2=80=98overkill=E2=80=99 as the mi= nimum set of features and optimizations which are required to >efficient= ly implement the user experience your document calls for:
>

<= div>In my approach, IoT devices need a generic IPv6 stack with handling add= itional ICMPv6 options,=C2=A0
such as DAD for DNS name and Node I= nformation Protocol rather than mDNS as application.=C2=A0
We nee= d to consider which approach is easy for the implementers.

Paul

>"This DNS name lets home residents easily identify ea= ch device for monitoring and remote-controlling it in a home network.=E2=80= =9D
>>Re-reading your proposal, no fe= ature in it is not already possible using mDNS/DNS-SD, perhaps paired with = new record types (ULOC, MLOC, or e.g. to represent the micro and macro loca= tion parameters, distinct from the existing LOC record), or existing ones (= make, model and etc. could for e.g. be added to TXT records).
>

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong, = Ph.D.
Assistant Professor
Department of Software /
Department of C= omputer Engineering
Sungkyunkwan University
Office: +82-31-299-4957Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul@gmail.com=
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.skku.e= du/people-jaehoon-jeong.php

On Fri, Nov 21, 2014 at 4:02 AM, Alf Watt <= alf@istumbler.net> wrote:
P= aul,

Thank you for responding. I took the time to read through your proposal and= have the following suggestions:

- carefully consider the extent to which your proposal duplicates existing = work, in particular:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - 5.2.1. and 5.2.2. very closely resemble the c= urrent behavior of mDNS nodes choosing names

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - 5.2.3 the =E2=80=98collector=E2=80=99 is effe= ctively an mDNS/DNS-SD browser which is limited to name records

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - Note well that mDNS/DNS-SD specifications car= efully describe the desirable caching behavior
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 for multiple =E2=80= =98collectors=E2=80=99 on a multicast link, which significantly improves pe= rformance

- carefully consider the existing uses for the DNS name label for an intern= et host:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - 6 - 6.2 while the concept of nested location = for IoT devices is interesting, overloading the existing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 name parameter to c= onvey this information does not seem like an appropriate tradeoff.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - 6 - 6.2 it is also unclear how a device would= be able to locate itself in a particular micro or macro location
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 and therefore gener= ate an appropriate name for itself, without user configuration

=C2=A0 =C2=A0 =C2=A0 =C2=A0 - the =E2=80=98name=E2=80=99 of any object, net= worked or not, is generally the choice of the owner. In some cultures =E2= =80=98naming=E2=80=99
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is synonymous with = taking ownership. Taking away the end-users ability to name their IoT objec= ts may
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 result in poor usab= ility, and potentially cause confusion with existing applications or networ= k devices
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 which do not implem= ent the proposed naming scheme.

- while naming is important, a device only needs to be discoverable and vis= ible to users if some service is to be accessed:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - your proposal covers only half of the solutio= n currently provided by mDNS/DNS-SD: local naming AND service discovery
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - applications connect to services, not hosts; = if a host offers no services then it does not need to be visible in a brows= er
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - most network users have little interest in di= scovery for the sake of discovery, they are interested in services

I suspect, that if you took the time to implement your proposal, you would = quickly realize that the existing mDNS and DNS-SD standards aren't so m= uch =E2=80=98overkill=E2=80=99 as the minimum set of features and optimizat= ions which are required to efficiently implement the user experience your d= ocument calls for:

"This DNS name lets home residents easily identify each device for mon= itoring and remote-controlling it in a home network.=E2=80=9D

Re-reading your proposal, no feature in it is not already possible using mD= NS/DNS-SD, perhaps paired with new record types (ULOC, MLOC, or e.g. to rep= resent the micro and macro location parameters, distinct from the existing = LOC record), or existing ones (make, model and etc. could for e.g. be added= to TXT records).



> On Nov 18, 2014, at 6:49 PM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote:
>
> Alf,
> Thanks for your kind survey information.
>
> It seems that the devices mentioned above will be able to run mDNS. > My point is to allow IoT device vendors to have an alternative way for= a simple DNS naming
> that is based on IPv6 stateless autoconfiguration.
>
> For the case where only the mapping between an IoT device's DNS na= me and its IPv6 is required,
> mDNS seems like an overkill.
>
> Paul
>
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D
> Mr. Jaehoon (Paul) Jeong, Ph.D.
> Assistant Professor
> Department of Software /
> Department of Computer Engineering
> Sungkyunkwan University
> Office: +82-31-299-4957
> Mobile: +82-10-4758-1765
> Fax: +82-31-290-5119
> Email: pauljeong@skku.edu, <= a href=3D"mailto:jaehoon.paul@gmail.com">jaehoon.paul@gmail.com
> CPS Lab Website: = http://cpslab.skku.edu
> Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php<= /a>
>
> On Wed, Nov 19, 2014 at 3:46 AM, Alf Watt <alf@istumbler.net> wrote:
> The proposal may have merit for other reasons but in terms of resource= usage for IoT devices it=E2=80=99s very instructive to look at existing pr= oducts.
>
> The Phillips Hue lights are built around a 32 ARM core [1] with limite= d RAM (128kb). The Nest Protect smoke detector is also built around a simil= ar 32bit ARM core from Freescale, the K60[2].
>
> Both of these are attached to a Zigbee radio, which provides sufficien= t bandwidth for DNS-SD over mDNS, as per our charter[3].
>
> Devices which need service discovery on batteries will very likely be = using layer-2 discovery mechanisms for power consumption reasons (i.e. BT-L= E).
>
> I have a hard time imagining that a device with much less capabilities= than above will be a useful internet node. If it can't afford to run a= simple discovery service then what is it doing on the network?
>
> Best,
> Alf
>
> [1] http://www.digchip.com/datasheets/parts= /datasheet/456/STM32F217VET6.php
> "ARM-based 32-bit MCU, MB Flash/128+4KB RAM, crypto, USB OTG HS/F= S, Ethernet, 17 TIMs, 3 ADCs, 15=C2=A0 =C2=A0 =C2=A0comm. interfaces & = camera"
> [2] http://cache.freescale.com/files/32bit/doc/data_sheet/K60P100M100SF2V= 2.pdf?fpsp=3D1&WT_TYPE=3DData%20Sheets&WT_VENDOR=3DFREESCALE&WT= _FILE_FORMAT=3Dpdf&WT_ASSET=3DDocumentation
> [3] http://datatracker.ietf.org/wg/dnssd/charter/
>
>> On Nov 14, 2014, at 10:34 PM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote: >>
>> Alf,
>> For embedded such as printers, cameras that have power and capacit= y equivalent to smartphone,
>> you are right.
>>
>> For low-power low-capacity devices, such as light bulb and smoke d= etecting sensor,
>> I think that running server(s) seems not viable
>> even though I have no exact number of target memory and cpu size >> for such low-power low-capacity IoT devices.
>>
>> Is there anyone else to comment on the hardware specification of s= uch IoT devices?
>>
>> Thanks.
>>
>> Paul
>>
>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
>> Mr. Jaehoon (Paul) Jeong, Ph.D.
>> Assistant Professor
>> Department of Software /
>> Department of Computer Engineering
>> Sungkyunkwan University
>> Office: +82-31-299-4957
>> Mobile: +82-10-4758-1765
>> Fax: +82-31-290-5119
>> Email: pauljeong@skku.edu, jaehoon.paul@gmail.com
>> CPS Lab Website: http://cpslab.skku.edu
>> Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.= php
>>
>> On Fri, Nov 14, 2014 at 12:02 PM, Alf Watt <alf@istumbler.net> wrote:
>> I=E2=80=99m confused, the mDNSResponder code is very lightweight a= nd already runs on embedded devices such as printers, cameras and may other= low-memory and low-cpu devices.
>>
>> What is your target memory and cpu size for an IoT device? Given t= hat we=E2=80=99ve been using mDNS for more than a decade, the steady pace o= f improvement in semiconductors means that even the smallest device will ha= ve more than sufficient resources for mMDS.
>>
>> Best,
>> Alf
>>
>>> On Nov 14, 2014, at 1:34 PM, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com> wrote: >>>
>>> The solution in RFC 6762 (Multicast DNS) section 9 is viable f= or regular computers,
>>> such as laptop, desktop, and smartphone that can afford to run= mDNS responder.
>>> For IoT devices, such as light bulb and fire detecting sensor,= that have limited memory and storage,
>>> mDNS seems not viable for the DNS naming for them.
>>>
>>
>>
>
>


--001a1140c8d828336605085df612-- From nobody Fri Nov 21 05:38:53 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E0DD1A0371 for ; Fri, 21 Nov 2014 05:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id okmjzLAyxJGR for ; Fri, 21 Nov 2014 05:38:50 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFF01A037D for ; Fri, 21 Nov 2014 05:37:16 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 10D1ADA02E8 for ; Fri, 21 Nov 2014 13:37:45 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 88E1953E07B; Fri, 21 Nov 2014 05:36:46 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 21 Nov 2014 05:36:46 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Fri, 21 Nov 2014 08:36:25 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <71A17712-B6C3-436D-840F-D32F654F04C9@nominum.com> References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <12750388-E313-4364-8D42-9DF75C91D91C@istumbler.net> To: "Mr. Jaehoon Paul Jeong" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/lFNFHmmWZq9FV_97VbqpFMjVgik Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , Jung-Soo Park , Sejun Lee Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 13:38:51 -0000 I think we still haven't heard a clear explanation for why this new = protocol work is needed. That would be the key discussion to have. = Discussions about what the protocol work would entail, or how it would = integrate with other work, are premature until that discussion has = reached a conclusion. From nobody Fri Nov 21 07:43:30 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9461A1A36 for ; Fri, 21 Nov 2014 07:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6HppXk5J6OO for ; Fri, 21 Nov 2014 07:43:20 -0800 (PST) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C4261A1A39 for ; Fri, 21 Nov 2014 07:43:10 -0800 (PST) Received: from [192.168.3.214] (unknown [109.107.209.90]) by mail.frobbit.se (Postfix) with ESMTPSA id E6BC92276F; Fri, 21 Nov 2014 16:42:13 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0DABB839-5BD0-47E2-9F94-24917DA2FD31"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b2 From: =?utf-8?Q?Patrik_F=C3=A4ltstr=C3=B6m?= In-Reply-To: <20141120221150.GA2345@mx1.yitter.info> Date: Fri, 21 Nov 2014 16:42:18 +0100 Message-Id: References: <0996A6E1-5218-4AFB-8646-D1047266C9ED@gmail.com> <20141120221150.GA2345@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/ohDuVojmcDTOwJyX-vdCIgHzWrY Cc: dnssd@ietf.org Subject: Re: [dnssd] UTF8 use in DNS populated by mDNS X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 15:43:29 -0000 --Apple-Mail=_0DABB839-5BD0-47E2-9F94-24917DA2FD31 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 20 nov 2014, at 23:11, Andrew Sullivan = wrote: >=20 > On Wed, Nov 19, 2014 at 04:50:39PM -0800, Douglas Otis wrote: >> If UTF-8 is to be permitted in DNS populated using mDNS inputs, a >> superset of rules directly and indirectly established to support >> safe use of IDNA labels are necessary, otherwise omitting such >> requirements would permit trivial spoofing. The requirements should >> include IDNA2008 considerations that restrict permitted code points. >=20 > In which part of the DNS-SD name do you want these restrictions? I > think there is considerable discussion of the different parts of those > names in the draft I discussed in Honolulu. >=20 > Note that there is _already_ a standard for putting "UTF-8 labels" in > the DNS (going back to STD 13 and reiterated by RFC 2181). In effect, > they're not "UTF-8 labels" but rather series of octets. FWIW I agree. One either have to add some kind of restriction on Unicode = Codepoints or not, and if you start to go down the path of choosing code = points (including normalization forms to use etc) that also impacts = matching, then you have something much more complicated than what DNSSD = was intended to do (according to my view). So, I can not personally recommend any more work be done regarding = specification on Unicode and DNSSD unless there are very compelling = arguments on what problems there are to solve and why. Patrik --Apple-Mail=_0DABB839-5BD0-47E2-9F94-24917DA2FD31 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFUb11arMabGguI180RAgMqAJ92NbARv8hca69o0+AlqABx1TL8dQCdHjwM ATlrQSok4I9m/Zr4QRnYtsY= =Ew/V -----END PGP SIGNATURE----- --Apple-Mail=_0DABB839-5BD0-47E2-9F94-24917DA2FD31-- From nobody Fri Nov 21 12:20:29 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 571751A6F99 for ; Fri, 21 Nov 2014 12:20:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wPSb9_RcgRw for ; Fri, 21 Nov 2014 12:20:13 -0800 (PST) Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C1B1A6FA3 for ; Fri, 21 Nov 2014 12:20:09 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id r5so4416678qcx.27 for ; Fri, 21 Nov 2014 12:20:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=E44irMkGzqX2aFDMuEEv79m85XN+F1Kq1nABaR3ruOk=; b=IBIMPImU6d/xAnpor9ODQIIB9vepKqcxAkH8n+mS9glSaQco0sHfaVYGXEB0AdcKJj UNLLRb63OioTMqTqz3R6ar41MJ/+FJTelUkvHLaWrUwh/E1Sb9Z8uRTbbx95/sZ1bS7h J36CIII7vq5VWxn56nz6XEP/oG9lwfZVkVwwO0IA7KAM8TbW46R0aJEIBusJYrURMtG2 9sSKo6nOyPw3UP6SpCtaRK2bPOMGdKGLsNkhO8VltJzKQBsqq3PVLDTpXcdoE9qI2d8Y Ype37iKSezNtBX5X66zxK8ZhNrbmgvG1ivCZFwAKBE1IteyvYEnZ+Ad4Wps1RRnRlytI Ktzw== X-Received: by 10.224.92.81 with SMTP id q17mr9064351qam.66.1416601209137; Fri, 21 Nov 2014 12:20:09 -0800 (PST) Received: from [10.86.252.34] (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPSA id a12sm5564982qai.1.2014.11.21.12.20.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Nov 2014 12:20:08 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ralph Droms In-Reply-To: <2F90339E-5447-4CF2-B9C7-3FCCBF259A65@bangj.com> Date: Fri, 21 Nov 2014 10:20:04 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <0C838131-0238-46DB-B37E-2B18642AC671@gmail.com> References: <2F90339E-5447-4CF2-B9C7-3FCCBF259A65@bangj.com> To: Tom Pusateri X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/JoyF3X7HuWDgaran5w-O83Vm9r0 Cc: dnssd@ietf.org Subject: Re: [dnssd] DNS SD Wiki X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2014 20:20:18 -0000 Thanks, Tom. - Ralph On Nov 16, 2014, at 2:06 PM 11/16/14, Tom Pusateri = wrote: > If you were at the meeting, you probably heard Dave Thaler mention we = could put the options and consensus about how to move forward with the = LLQ draft on our working group wiki. >=20 > So I put those notes from my slides and the meeting discussion on our = wiki. You can read it here: >=20 > https://tools.ietf.org/wg/dnssd/trac/wiki/WikiStart >=20 > If you remember it differently or have something to add, you only need = a tools account to update it, so feel free. >=20 > Thanks, > Tom >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Fri Nov 21 18:29:20 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA1E1AC3A7 for ; Fri, 21 Nov 2014 18:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvqYMa7DcD85 for ; Fri, 21 Nov 2014 18:29:17 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 895641AC3A5 for ; Fri, 21 Nov 2014 18:29:17 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id rd3so6088185pab.7 for ; Fri, 21 Nov 2014 18:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MQ2CsmVypflLflHVYsGcVETdBouBTWRfpLilXvplHmA=; b=JNJaXBPO/RJFjJE1hUwV7C7LqY7OCkg+2bMCoo1LmdmuWtQQ9Uo1IN4+hzSnJCEJvb qblQpM2zlhAQjaAKrCk5gT8PDu4LV/JL2KhNhbKlvlxCBt2MN4Vv6QDjnIIBm8zCfQT+ a8yyqoocUpRSixKIy8O7NPBzis4Teg9pcByY1kTZBxJJe9N1vS27T4l3pAc+DbbNflYf xioDM5A1rt10pqcNrlkdjad7HkJ8m0Bsgvpj5HGzGZWDiHbjgJnMZilXsCPShUAt2xqI ggkRjOeTJXGVdFIRqL1R1Ivr9C1DNcOSCDAn7hkSIMzS3Gajr3hkFpuJORcuNrwCfIBn QY0A== X-Received: by 10.66.121.130 with SMTP id lk2mr12442773pab.61.1416623356804; Fri, 21 Nov 2014 18:29:16 -0800 (PST) Received: from [192.168.2.226] (c-67-188-1-12.hsd1.ca.comcast.net. [67.188.1.12]) by mx.google.com with ESMTPSA id lm3sm6016316pab.34.2014.11.21.18.29.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Nov 2014 18:29:14 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: <20141120221150.GA2345@mx1.yitter.info> Date: Fri, 21 Nov 2014 18:29:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <5C4A3890-E575-4A88-81E6-F1EFF9930FB1@gmail.com> References: <0996A6E1-5218-4AFB-8646-D1047266C9ED@gmail.com> <20141120221150.GA2345@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/1oBuMlZ7AslQPhJRj34cmJssRmE Cc: dnssd@ietf.org, Douglas Otis Subject: Re: [dnssd] UTF8 use in DNS populated by mDNS X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Nov 2014 02:29:20 -0000 On Nov 20, 2014, at 2:11 PM, Andrew Sullivan = wrote: > Hi, >=20 > On Wed, Nov 19, 2014 at 04:50:39PM -0800, Douglas Otis wrote: >> If UTF-8 is to be permitted in DNS populated using mDNS inputs, a >> superset of rules directly and indirectly established to support >> safe use of IDNA labels are necessary, otherwise omitting such >> requirements would permit trivial spoofing. The requirements should >> include IDNA2008 considerations that restrict permitted code points. >=20 > In which part of the DNS-SD name do you want these restrictions? I > think there is considerable discussion of the different parts of those > names in the draft I discussed in Honolulu. >=20 > Note that there is _already_ a standard for putting "UTF-8 labels" in > the DNS (going back to STD 13 and reiterated by RFC 2181). In effect, > they're not "UTF-8 labels" but rather series of octets. Dear Andrew, DNS-SD generates: 'Service Instance Name =3D . . ' While there are restrictions on code points that define 'Instance' per = RFC5198 with an additional stipulation not to include values between = 0x00-0x1F and 0x7F, how the 'Domain' portion is determined is far less = clear. This is a concern when derived from easily spoofed multicast = mDNS responses. It is important a visual selection process does its = best to preclude trivial domain spoofing which might resolve malicious = sources. =20 >> It seems some advocate use of spaces in a domain name label be >> permitted. Even this minor change may confuse users about the >> specific domain when seen with respect to commandline based >> applications. >=20 > This is already permitted, of course, just like anything else in > labels. >=20 > But as I guess is plain from my work on the mdns-dns compatibility > I-D, I do think there is a long-term problem here, which is why I > recommend the minimal interoperable subset. The concern is specifically with visually deceptive resources. = Limitations on what is allowed should ensure against abuse of = right-to-left and left-to-right issues for example. Some TLDs protect = users with additional rules enforced by registrars that extend beyond = those imposed by IDNA2008. Allowing naive UTF-8 publication of mDNS = resources into DNS without conversion to A-labels permitted for DNS = suggests there will be an even greater need to qualify what appears to = be external actually resides within the Internet. A step facilitated by = imposing use of ugly A-labels within local publication should also = better guard against cache abuse as well. Regards, Douglas Otis= From nobody Mon Nov 24 08:26:56 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88B511A01D5 for ; Mon, 24 Nov 2014 08:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.77 X-Spam-Level: * X-Spam-Status: No, score=1.77 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bn-Nk7uED5oB for ; Mon, 24 Nov 2014 08:26:52 -0800 (PST) Received: from cnnic.cn (smtp13.cnnic.cn [218.241.118.13]) by ietfa.amsl.com (Postfix) with ESMTP id 450C71A6EEF for ; Mon, 24 Nov 2014 08:26:50 -0800 (PST) Received: from dgq-PC (unknown [123.123.63.18]) by ocmail02.zx.nicx.cn (Coremail) with SMTP id AQAAf0BJUMA9XHNUuZLTAA--.3132S2; Tue, 25 Nov 2014 00:26:38 +0800 (CST) Date: Tue, 25 Nov 2014 00:26:37 +0800 From: "Guangqing Deng" To: "Mr. Jaehoon Paul Jeong" References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <42C3C87F-0D99-47CB-B50A-9107BD10A2E6@bangj.com> <26B22159-3630-493B-AAA0-BC2DEA9DBA7F@apple.com>, X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7, 1, 2, 36[cn] Mime-Version: 1.0 Message-ID: <201411250026365350479@cnnic.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart774738355674_=----" X-CM-TRANSID: AQAAf0BJUMA9XHNUuZLTAA--.3132S2 X-Coremail-Antispam: 1UD129KBjvJXoWxurWDGryrAF13Cr43WF4fGrg_yoW5urykpF Z3tFyvkrn8Kry7G3y7uw1kuFWrZryfAw15Jwn5Jr1UCF98uFyftr1jkr1Fva4DCrsaya47 ZFWa9r1DGwn8ZFJanT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUB2b7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVWxJVW8Jr1l84ACjcxK6I 8E87Iv6xkF7I0E14v26r4j6r4UJwAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40E57IF 67AEF4xIwI1l5I8CrVCF0I0E4I0vr24lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2js IE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvY0x0EwIxGrwACY4xI67k0 4243AVAKzVAKj4xxM4xvF2IEb7IF0Fy26I8I3I1l42xK82IYc2Ij64vIr41l4I8I3I0E4I kC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWUGVWU WwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr 0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWr Zr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr 1l6VACY4xI67k04243AbIYCTnIWIevJa73UjIFyTuYvjxU2b10UUUUU X-CM-SenderInfo: 5ghqww5xdqw1xlqjqupqqluhdfq/ Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/NhfdESdtA6Pmw4SI2j1XON0bVHs Cc: "dnssd@ietf.org" Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:26:54 -0000 This is a multi-part message in MIME format. ------=_001_NextPart774738355674_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 VGhlIHRlcm0gb2YgIklvVCBkZXZpY2UiIGlzIG1lbnRpb25lZCBtYW55IHRpbWVzIGhlcmUgYW5k IGluIHRoZSBkcmFmdCwgYW5kIGl0IHNlZW1zIG5lY2Vzc2FyeSB0byBnaXZlIGEgcmVsYXRpdmVs eSBmb3JtYWwgZGVmaW5hdGlvbiB0byBpdCBpbnN0ZWFkIG9mIG9ubHkgcHJlc2VudGluZyBzb21l IGluc3RhbmNlcyBvZiBzbyBjYWxsZWQgIklvVCBkZXZpY2UiLiBUaGUgZG9tYWluIG5hbWUgaXMg dXN1YWxseSB1c2VkIHRvIHVuaXF1ZWx5IGFuZCBjb25zaXN0ZW50bHkgaWRlbnRpZnkgb2JqZWN0 cyBhbmQgdGh1cyBpdCBpcyBiZXR0ZXIgdG8ga2VlcCB0aGUgZG9tYWluIG5hbWUgdW5jaGFuZ2Vh YmxlLiBJZiBtYW55IGtpbmRzIG9mIGluZm9ybWF0aW9uIG9mICJJb1QgZGV2aWNlcyIgKHN1Y2gg YXMgdGhlaXIgbG9jYXRpb25zIGFuZCBjYXRlZ29yaWVzKSBhcmUgaW5zZXJ0ZWQgaW50byB0aGUg ZG9tYWluIG5hbWUgaW4gc29tZSB3YXksIHdoZXRoZXIgd2Ugc2hvdWxkIGNoYW5nZSB0aGUgZG9t YWluIG5hbWUgb3Igbm90IGlmIHNvbWUga2luZHMgb2YgaW5mb3JtYXRpb24gKGxpa2UgdGhlIGxv Y2F0aW9uKSBjaGFuZ2VzPyANCg0KDQoNCg0KR3VhbmdxaW5nIERlbmcNCmNubmljIA0KDQpGcm9t OiBNci4gSmFlaG9vbiBQYXVsIEplb25nDQpEYXRlOiAyMDE0LTExLTE5IDEyOjAwDQpUbzogU3R1 YXJ0IENoZXNoaXJlDQpDQzogZG5zc2RAaWV0Zi5vcmc7IE15dW5nLUtpIFNoaW47IEJyaWFuIEhh YmVybWFuOyBKdW5nLVNvbyBQYXJrDQpTdWJqZWN0OiBSZTogW2Ruc3NkXSBETlMgTmFtZSBBdXRv Y29uZmlndXJhdGlvbiBmb3IgSG9tZSBOZXR3b3JrIERldmljZXMNClN0dWFydCwNClRoYW5rcyBm b3IgeW91ciBjb25zdHJ1Y3RpdmUgY29tbWVudHMuDQoNCg0KQXMgSSBhbnN3ZXJlZCBBbGYncyBl bWFpbCBtZXNzYWdlIGp1c3QgYmVmb3JlLA0KSSB3b3VsZCBsaWtlIHRvIGFsbG93IElvVCB2ZW5k b3JzIHRvIGhhdmUgYW4gYWx0ZXJuYXRpdmUgd2F5IGZvciBETlMgbmFtaW5nDQp3aXRoIG1vcmUg Y29tcGFjdCBpbXBsZW1lbnRhdGlvbiBiYXNlZCBvbiBJUHY2IHN0YXRlbGVzcyBhdXRvY29uZmln dXJhdGlvbi4NCg0KDQpGb3IgdGhlIHF1ZXN0aW9uIGFib3V0IGhvdyB1c2VycyBmaW5kIG91dCB0 aGUgaG9zdCBuYW1lcyBhbmQgd2hpY2ggcHJvdG9jb2xzIGFyZSB1c2VkDQp3ZXJlIHByZXNlbnRl ZCB3aXRoIHRoZSBmb2xsb3dpbmcgc2xpZGVzIDQgYW5kIDUgZHVyaW5nIHRoZSBsYXN0IGRuc3Nk IFdHIHNlc3Npb24gaW4gSGF3YWlpOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85 MS9zbGlkZXMvc2xpZGVzLTkxLWRuc3NkLTYucGRmDQoNCg0KDQpUbyBmaWd1cmUgb3V0IHdoYXQg dGhvc2UgZGV2aWNlcyBkbywgd2UgY2FuIHVzZSBkZXZpY2UgY2F0ZWdvcnkgYW5kIGRldmljZSBt b2RlbCANCmluIHRoZSBETlMgbmFtZSBmb3JtYXQuDQoNCg0KUGF1bA0KDQoNCj09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KTXIuIEphZWhvb24gKFBhdWwpIEplb25nLCBQaC5ELg0KQXNzaXN0 YW50IFByb2Zlc3Nvcg0KRGVwYXJ0bWVudCBvZiBTb2Z0d2FyZSAvDQpEZXBhcnRtZW50IG9mIENv bXB1dGVyIEVuZ2luZWVyaW5nDQpTdW5na3l1bmt3YW4gVW5pdmVyc2l0eQ0KT2ZmaWNlOiArODIt MzEtMjk5LTQ5NTcNCk1vYmlsZTogKzgyLTEwLTQ3NTgtMTc2NQ0KRmF4OiArODItMzEtMjkwLTUx MTkNCkVtYWlsOiBwYXVsamVvbmdAc2trdS5lZHUsIGphZWhvb24ucGF1bEBnbWFpbC5jb20NCkNQ UyBMYWIgV2Vic2l0ZTogaHR0cDovL2Nwc2xhYi5za2t1LmVkdQ0KUGVyc29uYWwgSG9tZXBhZ2U6 IGh0dHA6Ly9jcHNsYWIuc2trdS5lZHUvcGVvcGxlLWphZWhvb24tamVvbmcucGhwDQoNCg0KDQpP biBXZWQsIE5vdiAxOSwgMjAxNCBhdCA3OjQ2IEFNLCBTdHVhcnQgQ2hlc2hpcmUgPGNoZXNoaXJl QGFwcGxlLmNvbT4gd3JvdGU6DQoNCk9uIDE3IE5vdiwgMjAxNCwgYXQgMTc6MzMsIE1yLiBKYWVo b29uIFBhdWwgSmVvbmcgPGphZWhvb24ucGF1bEBnbWFpbC5jb20+IHdyb3RlOg0KDQo+IEhpIFRv bSwNCj4NCj4gWW91IGFyZSByaWdodCBmb3IgYXBwbGlhbmNlcyB3aXRoIGVub3VnaCBjYXBhY2l0 eSB0byBydW4gbUROUy4NCj4NCj4gSG93ZXZlciwgZm9yIGxvdyBjYXBhY2l0eSBJb1QgZGV2aWNl cyB3aXRob3V0IG1ETlMsIG15IHByb3Bvc2FsIHdpbGwgYmUgYWJsZSB0byBzdXBwb3J0IGFuIGFs dGVybmF0aXZlIHdheSBmb3IgRE5TIG5hbWluZy4NCg0KWW91IGFzc2VydCB0aGF0IHRoZXJlIGFy ZSBkZXZpY2VzIHdpdGggaW5zdWZmaWNpZW50IHJlc291cmNlcyB0byBydW4gRE5TLVNEL21ETlMu DQoNCllvdSBhc3NlcnQgdGhhdCB0aGVzZSBkZXZpY2VzIHdvdWxkIGhhdmUgc3VmZmljaWVudCBy ZXNvdXJjZXMgdG8gcnVuIHlvdXIgYWx0ZXJuYXRpdmUuDQoNCkkgdGhpbmsgeW91IG5lZWQgZGF0 YSB0byBzdWJzdGFudGlhdGUgdGhlc2UgY2xhaW1zLiBOb3RlIHRoYXQgZGV2aWNlcyBsaWtlIHRo ZSBTaXRlUGxheWVyIFRlbG5ldCBpbXBsZW1lbnQgRE5TLVNEL21ETlMgaW4gdW5kZXIgb25lIGtp bG9ieXRlIChhYm91dCA4NTAgYnl0ZXMgb2YgY29kZSwgaWYgSSByZW1lbWJlciBjb3JyZWN0bHkp OiA8aHR0cDovL25ldG1lZGlhLmNvbS9zaXRlcGxheWVyL3RlbG5ldC8+DQoNClNvIHlvdSBuZWVk IHRvIGRlbW9uc3RyYXRlIHRoYXQ6DQoNCjEuIFRoYXQgdGhlcmUgYXJlIGRldmljZXMgd2hlcmUg ODUwIGJ5dGVzIG9mIGNvZGUgaXMgdG9vIG11Y2guDQoNCjIuIFRoYXQgdGhlc2UgZGV2aWNlcyBj YW4gaW1wbGVtZW50IHlvdXIgdGhpbmcgaW4gdW5kZXIgODUwIGJ5dGVzLg0KDQozLiBUaGF0IHlv dXIgdGhpbmcgaXMgdXNlZnVsLiBJ4oCZbSBzdGlsbCB1bmNsZWFyIG9uIHdoYXQgeW91ciB0aGlu ZyBpcyB1c2VmdWwgZm9yLiBZb3VyIHByb3Bvc2FsIHNheXMgaG93IGRldmljZXMgcGljayBob3N0 IG5hbWVzLCBidXQgbm90IGhvdyB1c2VycyBmaW5kIG91dCB3aGF0IHRob3NlIGhvc3QgbmFtZXMg YXJlLCBvciBmaW5kIG91dCB3aGF0IHRob3NlIGRldmljZXMgZG8sIG9yIHdoYXQgcHJvdG9jb2wg dG8gdXNlIHRvIGNvbW11bmljYXRlIHdpdGggdGhlbSwgYW5kIGhvdyBjbGllbnRzIHJlc29sdmUg dGhvc2UgaG9zdCBuYW1lcyB0byBhZGRyZXNzZXMuDQoNClN0dWFydCBDaGVzaGlyZQ0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpkbnNzZCBtYWls aW5nIGxpc3QNCmRuc3NkQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2Ruc3Nk ------=_001_NextPart774738355674_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
The term of "= IoT=20 device" is mentioned many times here and in the draft, and it se= ems=20 necessary to give a relatively formal defination to it instead of only=20 presenting some instances of so called "IoT device". The domain=20 name is usually used to uniquely and consistently identify objects and thu= s it=20 is better to keep the domain name unchangeable. If many kinds of informati= on of=20 "IoT devices" (such as their locations and categories) are inserted into t= he=20 domain name in some way, whether we should change the domain name or not i= f some=20 kinds of information (like the location) changes?= =20
 
Guangqing=20 Deng
cnnic 
 
Date: 2014-11-19 12:00
CC: dnssd@ietf.org;= Myung-Ki Shin; Brian Haberman; Jung-Soo Park
Subject: Re: [dnssd] DNS Name Autoconfiguration for Home=20 Network Devices
Stuart,
Thanks for your constructive comments.

As I answered Alf's email message just before,
I would like to allow IoT vendors to have an alternative way for DNS=20 naming
with more compact implementation based on IPv6 stateless=20 autoconfiguration.

For the question about how users find out the host names and which=20 protocols are used
were presented with the following slides 4 and 5 during the last dnss= d WG=20 session in Hawaii:
h= ttp://www.ietf.org/proceedings/91/slides/slides-91-dnssd-6.pdf

To figure out what those devices do, we can use device category and d= evice=20 model 
in the DNS name format.

Paul

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong,=20 Ph.D.
Assistant Professor
Department of Software /
Department of=20 Computer Engineering
Sungkyunkwan University
Office:=20 +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Ema= il: pauljeong@skku.edu,= jaehoon.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php

On Wed, Nov 19, 2014 at 7:46 AM, Stuart Cheshire = <cheshire@apple.com> wrote:
On 17 Nov, 2014, at 17:33, Mr. Jaehoon Paul Jeon= g=20 <jaehoon.paul@gmail.com= >=20 wrote:

> Hi Tom,
>
> You are right for appliances = with=20 enough capacity to run mDNS.
>
> However, for low capacity I= oT=20 devices without mDNS, my proposal will be able to support an alternative= way=20 for DNS naming.

You assert that there are devices with=20 insufficient resources to run DNS-SD/mDNS.

You assert that these=20 devices would have sufficient resources to run your alternative.

= I=20 think you need data to substantiate these claims. Note that devices like= the=20 SitePlayer Telnet implement DNS-SD/mDNS in under one kilobyte (about 850= bytes=20 of code, if I remember correctly): <http://netmedia.com/siteplayer/telnet/>

So= you=20 need to demonstrate that:

1. That there are devices where 850 byt= es of=20 code is too much.

2. That these devices can implement your thing = in=20 under 850 bytes.

3. That your thing is useful. I=E2=80=99m still = unclear on=20 what your thing is useful for. Your proposal says how devices pick host = names,=20 but not how users find out what those host names are, or find out what t= hose=20 devices do, or what protocol to use to communicate with them, and how cl= ients=20 resolve those host names to addresses.

Stuart Cheshire

_______________________________________________
d= nssd=20 mailing list
dnssd@ietf.org
= https://www.ietf.org/mailman/listinfo/dnssd

------=_001_NextPart774738355674_=------ From nobody Mon Nov 24 08:33:33 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 078031A8710 for ; Mon, 24 Nov 2014 08:33:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AYKn-q06qwnL for ; Mon, 24 Nov 2014 08:33:18 -0800 (PST) Received: from mx0b-00176a03.pphosted.com (mx0b-00176a03.pphosted.com [67.231.157.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 393BA1A711A for ; Mon, 24 Nov 2014 08:33:04 -0800 (PST) Received: from pps.filterd (m0048204.ppops.net [127.0.0.1]) by m0048204.ppops.net-00176a03. (8.14.7/8.14.7) with SMTP id sAOG7MNB043884 for ; Mon, 24 Nov 2014 11:33:03 -0500 Received: from cinmlip14.e2k.ad.ge.com ([12.71.149.1]) by m0048204.ppops.net-00176a03. with ESMTP id 1qv6btg332-9 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 24 Nov 2014 11:33:03 -0500 Received: from unknown (HELO CINMBHT04.e2k.ad.ge.com) ([3.159.212.197]) by cinmlip14.e2k.ad.ge.com with ESMTP/TLS/AES128-SHA; 24 Nov 2014 11:24:41 -0500 Received: from CINURAPD14.e2k.ad.ge.com (3.159.212.142) by CINMBHT04.e2k.ad.ge.com (3.159.212.197) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 24 Nov 2014 11:32:48 -0500 Received: from CINURCNA14.e2k.ad.ge.com ([169.254.2.138]) by CINURAPD14.e2k.ad.ge.com ([3.159.212.142]) with mapi id 14.03.0195.001; Mon, 24 Nov 2014 11:32:48 -0500 From: "Simpson, Robby (GE Energy Management)" To: Guangqing Deng , "Mr. Jaehoon Paul Jeong" Thread-Topic: [dnssd] DNS Name Autoconfiguration for Home Network Devices Thread-Index: AQHP//BdQI7OPQKTmku9cohwx5eWnZxg2XGAgAAf7YCAAAcrAIAAjIaAgAPKQ4CACq/BDIAAAZaA Date: Mon, 24 Nov 2014 16:32:47 +0000 Message-ID: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <42C3C87F-0D99-47CB-B50A-9107BD10A2E6@bangj.com> <26B22159-3630-493B-AAA0-BC2DEA9DBA7F@apple.com> <201411250026365350479@cnnic.cn> In-Reply-To: <201411250026365350479@cnnic.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [3.159.212.182] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.28, 0.0.0000 definitions=2014-11-24_02:2014-11-24,2014-11-24,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1411240132 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/kRP6XP7rZ81ZCa49qMpZ6Ukfh88 Cc: "dnssd@ietf.org" Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:33:28 -0000 V2hlbiBkaXNjdXNzaW5nIGNvbnN0cmFpbmVkIGRldmljZXMgKHdoaWNoIEkgdGhpbmsgaXMgdGhl IGludGVudCBoZXJlKSwgSSBmaW5kIHRoZSBkZWZpbml0aW9ucyBmcm9tIFJGQyA3MjI4IChodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9yZmM3MjI4LykgY29udmVuaWVudC4NCg0KLSBS b2JieQ0KDQpGcm9tOiBHdWFuZ3FpbmcgRGVuZyA8ZGVuZ2d1YW5ncWluZ0Bjbm5pYy5jbjxtYWls dG86ZGVuZ2d1YW5ncWluZ0Bjbm5pYy5jbj4+DQpEYXRlOiBNb25kYXksIE5vdmVtYmVyIDI0LCAy MDE0IGF0IDExOjI2IEFNDQpUbzogIk1yLiBKYWVob29uIFBhdWwgSmVvbmciIDxqYWVob29uLnBh dWxAZ21haWwuY29tPG1haWx0bzpqYWVob29uLnBhdWxAZ21haWwuY29tPj4NCkNjOiAiZG5zc2RA aWV0Zi5vcmc8bWFpbHRvOmRuc3NkQGlldGYub3JnPiIgPGRuc3NkQGlldGYub3JnPG1haWx0bzpk bnNzZEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW2Ruc3NkXSBETlMgTmFtZSBBdXRvY29uZmln dXJhdGlvbiBmb3IgSG9tZSBOZXR3b3JrIERldmljZXMNCg0KVGhlIHRlcm0gb2YgIklvVCBkZXZp Y2UiIGlzIG1lbnRpb25lZCBtYW55IHRpbWVzIGhlcmUgYW5kIGluIHRoZSBkcmFmdCwgYW5kIGl0 IHNlZW1zIG5lY2Vzc2FyeSB0byBnaXZlIGEgcmVsYXRpdmVseSBmb3JtYWwgZGVmaW5hdGlvbiB0 byBpdCBpbnN0ZWFkIG9mIG9ubHkgcHJlc2VudGluZyBzb21lIGluc3RhbmNlcyBvZiBzbyBjYWxs ZWQgIklvVCBkZXZpY2UiLiBUaGUgZG9tYWluIG5hbWUgaXMgdXN1YWxseSB1c2VkIHRvIHVuaXF1 ZWx5IGFuZCBjb25zaXN0ZW50bHkgaWRlbnRpZnkgb2JqZWN0cyBhbmQgdGh1cyBpdCBpcyBiZXR0 ZXIgdG8ga2VlcCB0aGUgZG9tYWluIG5hbWUgdW5jaGFuZ2VhYmxlLiBJZiBtYW55IGtpbmRzIG9m IGluZm9ybWF0aW9uIG9mICJJb1QgZGV2aWNlcyIgKHN1Y2ggYXMgdGhlaXIgbG9jYXRpb25zIGFu ZCBjYXRlZ29yaWVzKSBhcmUgaW5zZXJ0ZWQgaW50byB0aGUgZG9tYWluIG5hbWUgaW4gc29tZSB3 YXksIHdoZXRoZXIgd2Ugc2hvdWxkIGNoYW5nZSB0aGUgZG9tYWluIG5hbWUgb3Igbm90IGlmIHNv bWUga2luZHMgb2YgaW5mb3JtYXRpb24gKGxpa2UgdGhlIGxvY2F0aW9uKSBjaGFuZ2VzPw0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KR3VhbmdxaW5nIERlbmcNCmNubmljDQoN CkZyb206IE1yLiBKYWVob29uIFBhdWwgSmVvbmc8bWFpbHRvOmphZWhvb24ucGF1bEBnbWFpbC5j b20+DQpEYXRlOiAyMDE0LTExLTE5IDEyOjAwDQpUbzogU3R1YXJ0IENoZXNoaXJlPG1haWx0bzpj aGVzaGlyZUBhcHBsZS5jb20+DQpDQzogZG5zc2RAaWV0Zi5vcmc8bWFpbHRvOmRuc3NkQGlldGYu b3JnPjsgTXl1bmctS2kgU2hpbjxtYWlsdG86bWtzaGluQGV0cmkucmUua3I+OyBCcmlhbiBIYWJl cm1hbjxtYWlsdG86YnJpYW5AaW5ub3ZhdGlvbnNsYWIubmV0PjsgSnVuZy1Tb28gUGFyazxtYWls dG86cGpzQGV0cmkucmUua3I+DQpTdWJqZWN0OiBSZTogW2Ruc3NkXSBETlMgTmFtZSBBdXRvY29u ZmlndXJhdGlvbiBmb3IgSG9tZSBOZXR3b3JrIERldmljZXMNClN0dWFydCwNClRoYW5rcyBmb3Ig eW91ciBjb25zdHJ1Y3RpdmUgY29tbWVudHMuDQoNCkFzIEkgYW5zd2VyZWQgQWxmJ3MgZW1haWwg bWVzc2FnZSBqdXN0IGJlZm9yZSwNCkkgd291bGQgbGlrZSB0byBhbGxvdyBJb1QgdmVuZG9ycyB0 byBoYXZlIGFuIGFsdGVybmF0aXZlIHdheSBmb3IgRE5TIG5hbWluZw0Kd2l0aCBtb3JlIGNvbXBh Y3QgaW1wbGVtZW50YXRpb24gYmFzZWQgb24gSVB2NiBzdGF0ZWxlc3MgYXV0b2NvbmZpZ3VyYXRp b24uDQoNCkZvciB0aGUgcXVlc3Rpb24gYWJvdXQgaG93IHVzZXJzIGZpbmQgb3V0IHRoZSBob3N0 IG5hbWVzIGFuZCB3aGljaCBwcm90b2NvbHMgYXJlIHVzZWQNCndlcmUgcHJlc2VudGVkIHdpdGgg dGhlIGZvbGxvd2luZyBzbGlkZXMgNCBhbmQgNSBkdXJpbmcgdGhlIGxhc3QgZG5zc2QgV0cgc2Vz c2lvbiBpbiBIYXdhaWk6DQpodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzkxL3NsaWRl cy9zbGlkZXMtOTEtZG5zc2QtNi5wZGYNCg0KVG8gZmlndXJlIG91dCB3aGF0IHRob3NlIGRldmlj ZXMgZG8sIHdlIGNhbiB1c2UgZGV2aWNlIGNhdGVnb3J5IGFuZCBkZXZpY2UgbW9kZWwNCmluIHRo ZSBETlMgbmFtZSBmb3JtYXQuDQoNClBhdWwNCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09 DQpNci4gSmFlaG9vbiAoUGF1bCkgSmVvbmcsIFBoLkQuDQpBc3Npc3RhbnQgUHJvZmVzc29yDQpE ZXBhcnRtZW50IG9mIFNvZnR3YXJlIC8NCkRlcGFydG1lbnQgb2YgQ29tcHV0ZXIgRW5naW5lZXJp bmcNClN1bmdreXVua3dhbiBVbml2ZXJzaXR5DQpPZmZpY2U6ICs4Mi0zMS0yOTktNDk1Nw0KTW9i aWxlOiArODItMTAtNDc1OC0xNzY1DQpGYXg6ICs4Mi0zMS0yOTAtNTExOQ0KRW1haWw6IHBhdWxq ZW9uZ0Bza2t1LmVkdTxtYWlsdG86cGF1bGplb25nQHNra3UuZWR1PiwgamFlaG9vbi5wYXVsQGdt YWlsLmNvbTxtYWlsdG86amFlaG9vbi5wYXVsQGdtYWlsLmNvbT4NCkNQUyBMYWIgV2Vic2l0ZTog aHR0cDovL2Nwc2xhYi5za2t1LmVkdQ0KUGVyc29uYWwgSG9tZXBhZ2U6IGh0dHA6Ly9jcHNsYWIu c2trdS5lZHUvcGVvcGxlLWphZWhvb24tamVvbmcucGhwDQoNCk9uIFdlZCwgTm92IDE5LCAyMDE0 IGF0IDc6NDYgQU0sIFN0dWFydCBDaGVzaGlyZSA8Y2hlc2hpcmVAYXBwbGUuY29tPG1haWx0bzpj aGVzaGlyZUBhcHBsZS5jb20+PiB3cm90ZToNCk9uIDE3IE5vdiwgMjAxNCwgYXQgMTc6MzMsIE1y LiBKYWVob29uIFBhdWwgSmVvbmcgPGphZWhvb24ucGF1bEBnbWFpbC5jb208bWFpbHRvOmphZWhv b24ucGF1bEBnbWFpbC5jb20+PiB3cm90ZToNCg0KPiBIaSBUb20sDQo+DQo+IFlvdSBhcmUgcmln aHQgZm9yIGFwcGxpYW5jZXMgd2l0aCBlbm91Z2ggY2FwYWNpdHkgdG8gcnVuIG1ETlMuDQo+DQo+ IEhvd2V2ZXIsIGZvciBsb3cgY2FwYWNpdHkgSW9UIGRldmljZXMgd2l0aG91dCBtRE5TLCBteSBw cm9wb3NhbCB3aWxsIGJlIGFibGUgdG8gc3VwcG9ydCBhbiBhbHRlcm5hdGl2ZSB3YXkgZm9yIERO UyBuYW1pbmcuDQoNCllvdSBhc3NlcnQgdGhhdCB0aGVyZSBhcmUgZGV2aWNlcyB3aXRoIGluc3Vm ZmljaWVudCByZXNvdXJjZXMgdG8gcnVuIEROUy1TRC9tRE5TLg0KDQpZb3UgYXNzZXJ0IHRoYXQg dGhlc2UgZGV2aWNlcyB3b3VsZCBoYXZlIHN1ZmZpY2llbnQgcmVzb3VyY2VzIHRvIHJ1biB5b3Vy IGFsdGVybmF0aXZlLg0KDQpJIHRoaW5rIHlvdSBuZWVkIGRhdGEgdG8gc3Vic3RhbnRpYXRlIHRo ZXNlIGNsYWltcy4gTm90ZSB0aGF0IGRldmljZXMgbGlrZSB0aGUgU2l0ZVBsYXllciBUZWxuZXQg aW1wbGVtZW50IEROUy1TRC9tRE5TIGluIHVuZGVyIG9uZSBraWxvYnl0ZSAoYWJvdXQgODUwIGJ5 dGVzIG9mIGNvZGUsIGlmIEkgcmVtZW1iZXIgY29ycmVjdGx5KTogPGh0dHA6Ly9uZXRtZWRpYS5j b20vc2l0ZXBsYXllci90ZWxuZXQvPg0KDQpTbyB5b3UgbmVlZCB0byBkZW1vbnN0cmF0ZSB0aGF0 Og0KDQoxLiBUaGF0IHRoZXJlIGFyZSBkZXZpY2VzIHdoZXJlIDg1MCBieXRlcyBvZiBjb2RlIGlz IHRvbyBtdWNoLg0KDQoyLiBUaGF0IHRoZXNlIGRldmljZXMgY2FuIGltcGxlbWVudCB5b3VyIHRo aW5nIGluIHVuZGVyIDg1MCBieXRlcy4NCg0KMy4gVGhhdCB5b3VyIHRoaW5nIGlzIHVzZWZ1bC4g SeKAmW0gc3RpbGwgdW5jbGVhciBvbiB3aGF0IHlvdXIgdGhpbmcgaXMgdXNlZnVsIGZvci4gWW91 ciBwcm9wb3NhbCBzYXlzIGhvdyBkZXZpY2VzIHBpY2sgaG9zdCBuYW1lcywgYnV0IG5vdCBob3cg dXNlcnMgZmluZCBvdXQgd2hhdCB0aG9zZSBob3N0IG5hbWVzIGFyZSwgb3IgZmluZCBvdXQgd2hh dCB0aG9zZSBkZXZpY2VzIGRvLCBvciB3aGF0IHByb3RvY29sIHRvIHVzZSB0byBjb21tdW5pY2F0 ZSB3aXRoIHRoZW0sIGFuZCBob3cgY2xpZW50cyByZXNvbHZlIHRob3NlIGhvc3QgbmFtZXMgdG8g YWRkcmVzc2VzLg0KDQpTdHVhcnQgQ2hlc2hpcmUNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCmRuc3NkIG1haWxpbmcgbGlzdA0KZG5zc2RAaWV0Zi5v cmc8bWFpbHRvOmRuc3NkQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9kbnNzZA0KDQo= From nobody Mon Nov 24 08:43:44 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88E091A6EDA for ; Mon, 24 Nov 2014 08:43:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.559 X-Spam-Level: ** X-Spam-Status: No, score=2.559 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coO8jAg33EkP for ; Mon, 24 Nov 2014 08:43:36 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E6351A6ED8 for ; Mon, 24 Nov 2014 08:43:35 -0800 (PST) Received: from mx1.yitter.info (nat-07-mht.dyndns.com [216.146.45.246]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 5DFA58A031 for ; Mon, 24 Nov 2014 16:43:34 +0000 (UTC) Date: Mon, 24 Nov 2014 11:43:34 -0500 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20141124164333.GK2860@mx1.yitter.info> References: <0996A6E1-5218-4AFB-8646-D1047266C9ED@gmail.com> <20141120221150.GA2345@mx1.yitter.info> <5C4A3890-E575-4A88-81E6-F1EFF9930FB1@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5C4A3890-E575-4A88-81E6-F1EFF9930FB1@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/NfzgMTfYBDzrkjeozfkMD0aaDWA Subject: Re: [dnssd] UTF8 use in DNS populated by mDNS X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Nov 2014 16:43:37 -0000 Hi, On Fri, Nov 21, 2014 at 06:29:12PM -0800, Douglas Otis wrote: > Dear Andrew, > > DNS-SD generates: > 'Service Instance Name = . . ' Yes. > While there are restrictions on code points that define 'Instance' per RFC5198 with an additional stipulation not to include values between 0x00-0x1F and 0x7F Yes. > , how the 'Domain' portion is determined is far less clear. No. If you read RFC 6763 carefully, you will note that the Domain portion is also restricted to RFC 5198, which is approximately UTF-8 in NFC. > This is a concern when derived from easily spoofed multicast mDNS responses. It is important a visual selection process does its best to preclude trivial domain spoofing which might resolve malicious sources. > If what you're attempting to do is prescribe, in the output of this WG, general rules for "anti-phishing" for domain names, I am going to resist the creation of such rules by this WG. The WG doesn't have the requisite expertise to do that, and DNSOP is an already-existing WG that has a possibly relevant charter (though unfortunately almost certainly inadequate clue about the relevant i18n issues). > The concern is specifically with visually deceptive resources. Limitations on what is allowed should ensure against abuse of right-to-left and left-to-right issues for example. LTR and RTL issues have remarkably little to do with phishing except in some quite specific circumstances, and in those cases it is _imposible_ for an application to cope with the edge case in general, because of the distributed operation of the DNS. > Some TLDs protect users with additional rules enforced by registrars that extend beyond those imposed by IDNA2008. Yes. That's registration policy and it is way beyond the capability of this WG to create in a perfectly general way. > Allowing naive UTF-8 publication of mDNS resources into DNS without conversion to A-labels permitted for DNS suggests there will be an even greater need to qualify what appears to be external actually resides within the Internet. No. As Dave Thaler argued quite clearly in Honolulu, you can have all the phishing problems you want using either IDNA2008 or plain UTF-8 labels. These are totally orthoganal problems. > A step facilitated by imposing use of ugly A-labels within local publication should also better guard against cache abuse as well. > How? Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Nov 24 16:44:29 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5971A6FF6 for ; Mon, 24 Nov 2014 16:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwF8g6nZEt_0 for ; Mon, 24 Nov 2014 16:44:26 -0800 (PST) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5C8F1A6F5A for ; Mon, 24 Nov 2014 16:44:25 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id at20so10071603iec.20 for ; Mon, 24 Nov 2014 16:44:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SIEPAwpdJWbDGMJgD3FoOZZjxvP2V6e4BHRZXJhzpqM=; b=igzJT8xOl1p2cHYpeGZHxPgxRQAVqpXACAqG+ziTbbXXAEGy2zDYtSCUJcEBXnmcgV HaJd1JE+OPCD/vUSpStb0rLqvs8tmrMeRnhfBHlhzoI6WfxvgoERtkuaoH3w1q6iY0qr vwLU3etucqWoEhvAVzs31lGHaViDt9fyiSD2TVFE4gmQO5NXg5tZ1sM5tYVePUiyW4lt U+w5kCWcFkiE38GLQPzcLl0mWmlYChM1+rwgpCMzk4VCzDp2vsiYRQRglXSXcRgIOIKs xjnT0Axa9TCCrT86euqFmxtIgjRp+nQc17pCVvjdXq+2qhUJHi6NDr17MgJRzpyJWH9t YGrA== MIME-Version: 1.0 X-Received: by 10.43.74.3 with SMTP id yu3mr27243693icb.15.1416876264807; Mon, 24 Nov 2014 16:44:24 -0800 (PST) Received: by 10.64.57.14 with HTTP; Mon, 24 Nov 2014 16:44:24 -0800 (PST) In-Reply-To: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <42C3C87F-0D99-47CB-B50A-9107BD10A2E6@bangj.com> <26B22159-3630-493B-AAA0-BC2DEA9DBA7F@apple.com> <201411250026365350479@cnnic.cn> Date: Tue, 25 Nov 2014 09:44:24 +0900 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: "Simpson, Robby (GE Energy Management)" Content-Type: multipart/alternative; boundary=001a11c20c087464cf0508a43632 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/fV53zQU9By7nsdCUvzrfmQYEUKg Cc: "dnssd@ietf.org" , Guangqing Deng Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 00:44:29 -0000 --001a11c20c087464cf0508a43632 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Robby, This is a good reference for constrained node, such as IoT. I will include the definitions of constrained node and IoT in the next version of my draft. Thanks. Paul =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Tue, Nov 25, 2014 at 1:32 AM, Simpson, Robby (GE Energy Management) < robby.simpson@ge.com> wrote: > When discussing constrained devices (which I think is the intent here), I > find the definitions from RFC 7228 ( > https://datatracker.ietf.org/doc/rfc7228/) convenient. > > - Robby > > From: Guangqing Deng >> > Date: Monday, November 24, 2014 at 11:26 AM > To: "Mr. Jaehoon Paul Jeong" jaehoon.paul@gmail.com>> > Cc: "dnssd@ietf.org" dnssd@ietf.org>> > Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices > > The term of "IoT device" is mentioned many times here and in the draft, > and it seems necessary to give a relatively formal defination to it inste= ad > of only presenting some instances of so called "IoT device". The domain > name is usually used to uniquely and consistently identify objects and th= us > it is better to keep the domain name unchangeable. If many kinds of > information of "IoT devices" (such as their locations and categories) are > inserted into the domain name in some way, whether we should change the > domain name or not if some kinds of information (like the location) chang= es? > > ________________________________ > Guangqing Deng > cnnic > > From: Mr. Jaehoon Paul Jeong > Date: 2014-11-19 12:00 > To: Stuart Cheshire > CC: dnssd@ietf.org; Myung-Ki Shin mkshin@etri.re.kr>; Brian Haberman; > Jung-Soo Park > Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices > Stuart, > Thanks for your constructive comments. > > As I answered Alf's email message just before, > I would like to allow IoT vendors to have an alternative way for DNS nami= ng > with more compact implementation based on IPv6 stateless autoconfiguratio= n. > > For the question about how users find out the host names and which > protocols are used > were presented with the following slides 4 and 5 during the last dnssd WG > session in Hawaii: > http://www.ietf.org/proceedings/91/slides/slides-91-dnssd-6.pdf > > To figure out what those devices do, we can use device category and devic= e > model > in the DNS name format. > > Paul > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software / > Department of Computer Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Mobile: +82-10-4758-1765 > Fax: +82-31-290-5119 > Email: pauljeong@skku.edu, > jaehoon.paul@gmail.com > CPS Lab Website: http://cpslab.skku.edu > Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php > > On Wed, Nov 19, 2014 at 7:46 AM, Stuart Cheshire > wrote: > On 17 Nov, 2014, at 17:33, Mr. Jaehoon Paul Jeong > wrote: > > > Hi Tom, > > > > You are right for appliances with enough capacity to run mDNS. > > > > However, for low capacity IoT devices without mDNS, my proposal will be > able to support an alternative way for DNS naming. > > You assert that there are devices with insufficient resources to run > DNS-SD/mDNS. > > You assert that these devices would have sufficient resources to run your > alternative. > > I think you need data to substantiate these claims. Note that devices lik= e > the SitePlayer Telnet implement DNS-SD/mDNS in under one kilobyte (about > 850 bytes of code, if I remember correctly): < > http://netmedia.com/siteplayer/telnet/> > > So you need to demonstrate that: > > 1. That there are devices where 850 bytes of code is too much. > > 2. That these devices can implement your thing in under 850 bytes. > > 3. That your thing is useful. I=E2=80=99m still unclear on what your thin= g is > useful for. Your proposal says how devices pick host names, but not how > users find out what those host names are, or find out what those devices > do, or what protocol to use to communicate with them, and how clients > resolve those host names to addresses. > > Stuart Cheshire > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > --001a11c20c087464cf0508a43632 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Robby,
This is a good reference for constrained node, = such as IoT.
I will include the definitions of constrained node a= nd IoT in the next version of my draft.

Thanks.

Paul

=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr= . Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Softw= are /
Department of Computer Engineering
Sungkyunkwan University
O= ffice: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119<= br>Email: pauljeong= @skku.edu, = jaehoon.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: <= a href=3D"http://cpslab.skku.edu/people-jaehoon-jeong.php" target=3D"_blank= ">http://cpslab.skku.edu/people-jaehoon-jeong.php

On Tue, Nov 25, 2014 at 1:32 AM, Simpson, Ro= bby (GE Energy Management) <robby.simpson@ge.com> wrote:<= br>
When discussing constrained devices (whic= h I think is the intent here), I find the definitions from RFC 7228 (https://d= atatracker.ietf.org/doc/rfc7228/) convenient.

- Robby

From: Guangqing Deng <dengguan= gqing@cnnic.cn<mailto:deng= guangqing@cnnic.cn>>
Date: Monday, November 24, 2014 at 11:26 AM
To: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@gmail.com<mailto:jaehoon.paul@gmail.com>>
Cc: "dnssd@ietf.org<mailto:dnssd@ietf.org>" <dnssd@ietf.org<mailto:dnssd@ietf.org>>
Subject: Re: [dnssd] DNS Name Autoconfiguration for Home N= etwork Devices

The term of "IoT device" is mentioned man= y times here and in the draft, and it seems necessary to give a relatively = formal defination to it instead of only presenting some instances of so cal= led "IoT device". The domain name is usually used to uniquely and= consistently identify objects and thus it is better to keep the domain nam= e unchangeable. If many kinds of information of "IoT devices" (su= ch as their locations and categories) are inserted into the domain name in = some way, whether we should change the domain name or not if some kinds of = information (like the location) changes?

________________________________
Guangqing Deng
cnnic

From: Mr. Jaehoon Paul Jeong<mailto:jaehoon.paul@gmail.com>
Date: 2014-11-19 12:00
To: Stuart Cheshire<mailto:cheshir= e@apple.com>
CC: dnssd@ietf.org<mailto:dnssd@ietf.org>; Myung-Ki Shin<mailto:= mkshin@etri.re.kr>; Brian Haber= man<mailto:brian@innovations= lab.net>; Jung-Soo Park<mailto:= pjs@etri.re.kr>
Subject: Re: [dnssd] DNS Name Autoconfiguration for Home N= etwork Devices
Stuart,
Thanks for your constructive comments.

As I answered Alf's email message just before,
I would like to allow IoT vendors to have an alternative way for DNS naming=
with more compact implementation based on IPv6 stateless autoconfiguration.=

For the question about how users find out the host names and which protocol= s are used
were presented with the following slides 4 and 5 during the last dnssd WG s= ession in Hawaii:
http://www.ietf.org/proceedings/91/slides/slides-91-dnss= d-6.pdf

To figure out what those devices do, we can use device category and device = model
in the DNS name format.

Paul

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D
Mr. Jaehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software /
Department of Computer Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Email: pauljeong@skku.edu&= lt;mailto:pauljeong@skku.edu>,= jaehoon.paul@gmail.com<ma= ilto:jaehoon.paul@gmail.com&g= t;
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php
On Wed, Nov 19, 2014 at 7:46 AM, Stuart Cheshire &l= t;cheshire@apple.com<mailto:cheshire@apple.com>> wrote: On 17 Nov, 2014, at 17:33, Mr. Jaehoon Paul Jeong <jaehoon.paul@gmail.com<mailto:jaehoon.paul@gmail.com>> wrote:

> Hi Tom,
>
> You are right for appliances with enough capacity to run mDNS.
>
> However, for low capacity IoT devices without mDNS, my proposal will b= e able to support an alternative way for DNS naming.

You assert that there are devices with insufficient resources to run DNS-SD= /mDNS.

You assert that these devices would have sufficient resources to run your a= lternative.

I think you need data to substantiate these claims. Note that devices like = the SitePlayer Telnet implement DNS-SD/mDNS in under one kilobyte (about 85= 0 bytes of code, if I remember correctly): <http://netmedia.com/siteplayer/tel= net/>

So you need to demonstrate that:

1. That there are devices where 850 bytes of code is too much.

2. That these devices can implement your thing in under 850 bytes.

3. That your thing is useful. I=E2=80=99m still unclear on what your thing = is useful for. Your proposal says how devices pick host names, but not how = users find out what those host names are, or find out what those devices do= , or what protocol to use to communicate with them, and how clients resolve= those host names to addresses.

Stuart Cheshire

_______________________________________________
dnssd mailing list
dnssd@ietf.org<mailto:dnssd@ietf.org>
h= ttps://www.ietf.org/mailman/listinfo/dnssd


--001a11c20c087464cf0508a43632-- From nobody Mon Nov 24 16:50:20 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE761A7018 for ; Mon, 24 Nov 2014 16:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTJwZFpnhGTo for ; Mon, 24 Nov 2014 16:50:15 -0800 (PST) Received: from mail-ig0-x22b.google.com (mail-ig0-x22b.google.com [IPv6:2607:f8b0:4001:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF2B11A700C for ; Mon, 24 Nov 2014 16:50:14 -0800 (PST) Received: by mail-ig0-f171.google.com with SMTP id z20so102742igj.16 for ; Mon, 24 Nov 2014 16:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kckmwZvPjd7LRgs4/x+7ylwoetFoeec7zfdWSgDEEy8=; b=Sx9r86Vi4Gmkk+OaVaBYvK3aINZNlWVaGjt28QcGRrD3UiVznTOqUDfKS/ibM/W0DF L86qT3sKtrk8Cnr3LOn14goTVj5oz9h6nP8FfIKtQyNe70kyaUGvol+YsRBGrrCgjK22 ORw/vu7J4IWO4jh0yGf+Y8J7p5KeZ2GaiuOrvYrUjkthQoq62Cunm/a8RRlNYB4932tq z5X7rx7z7V58RdQi92hM6Uisiem6YGzdBxNGGDHJFx2tNA1KVeISnNf8S02ZwDFiDZ+c 5WJgq0z5Dvwa347tGnfX3/JKzFUmgNkqg6EC+O8v4o9DXmmGngoBtd2AL11TS5gIHAXh f66w== MIME-Version: 1.0 X-Received: by 10.107.156.131 with SMTP id f125mr21466267ioe.15.1416876613894; Mon, 24 Nov 2014 16:50:13 -0800 (PST) Received: by 10.64.57.14 with HTTP; Mon, 24 Nov 2014 16:50:13 -0800 (PST) In-Reply-To: <201411250026365350479@cnnic.cn> References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <42C3C87F-0D99-47CB-B50A-9107BD10A2E6@bangj.com> <26B22159-3630-493B-AAA0-BC2DEA9DBA7F@apple.com> <201411250026365350479@cnnic.cn> Date: Tue, 25 Nov 2014 09:50:13 +0900 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: Guangqing Deng Content-Type: multipart/alternative; boundary=001a1140c8d84308870508a44bbf Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/eswpk9GbuTtHtIczPYaciac2xUU Cc: "dnssd@ietf.org" Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 00:50:17 -0000 --001a1140c8d84308870508a44bbf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Guangqing, Domain name has the meaning of both logical space and physical space. For example, ".home" means the domain of logical space for home network and also the physical place of my home. In my draft, the location as part of domain name puts more weight on physical space and the device category as part of domain name puts more weight on local space as a device cluster in a home network. Thanks. Paul =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Tue, Nov 25, 2014 at 1:26 AM, Guangqing Deng wrote: > The term of "IoT device" is mentioned many times here and in the > draft, and it seems necessary to give a relatively formal defination to i= t > instead of only presenting some instances of so called "IoT device". The > domain name is usually used to uniquely and consistently identify objects > and thus it is better to keep the domain name unchangeable. If many kinds > of information of "IoT devices" (such as their locations and categories) > are inserted into the domain name in some way, whether we should change t= he > domain name or not if some kinds of information (like the location) chang= es? > > ------------------------------ > Guangqing Deng > cnnic > > *From:* Mr. Jaehoon Paul Jeong > *Date:* 2014-11-19 12:00 > *To:* Stuart Cheshire > *CC:* dnssd@ietf.org; Myung-Ki Shin ; Brian Haberman > ; Jung-Soo Park > *Subject:* Re: [dnssd] DNS Name Autoconfiguration for Home Network Device= s > Stuart, > Thanks for your constructive comments. > > As I answered Alf's email message just before, > I would like to allow IoT vendors to have an alternative way for DNS nami= ng > with more compact implementation based on IPv6 stateless autoconfiguratio= n. > > For the question about how users find out the host names and which > protocols are used > were presented with the following slides 4 and 5 during the last dnssd WG > session in Hawaii: > http://www.ietf.org/proceedings/91/slides/slides-91-dnssd-6.pdf > > To figure out what those devices do, we can use device category and devic= e > model > in the DNS name format. > > Paul > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D > Mr. Jaehoon (Paul) Jeong, Ph.D. > Assistant Professor > Department of Software / > Department of Computer Engineering > Sungkyunkwan University > Office: +82-31-299-4957 > Mobile: +82-10-4758-1765 > Fax: +82-31-290-5119 > Email: pauljeong@skku.edu, jaehoon.paul@gmail.com > CPS Lab Website: http://cpslab.skku.edu > Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php > > On Wed, Nov 19, 2014 at 7:46 AM, Stuart Cheshire > wrote: > >> On 17 Nov, 2014, at 17:33, Mr. Jaehoon Paul Jeong >> wrote: >> >> > Hi Tom, >> > >> > You are right for appliances with enough capacity to run mDNS. >> > >> > However, for low capacity IoT devices without mDNS, my proposal will b= e >> able to support an alternative way for DNS naming. >> >> You assert that there are devices with insufficient resources to run >> DNS-SD/mDNS. >> >> You assert that these devices would have sufficient resources to run you= r >> alternative. >> >> I think you need data to substantiate these claims. Note that devices >> like the SitePlayer Telnet implement DNS-SD/mDNS in under one kilobyte >> (about 850 bytes of code, if I remember correctly): < >> http://netmedia.com/siteplayer/telnet/> >> >> So you need to demonstrate that: >> >> 1. That there are devices where 850 bytes of code is too much. >> >> 2. That these devices can implement your thing in under 850 bytes. >> >> 3. That your thing is useful. I=E2=80=99m still unclear on what your thi= ng is >> useful for. Your proposal says how devices pick host names, but not how >> users find out what those host names are, or find out what those devices >> do, or what protocol to use to communicate with them, and how clients >> resolve those host names to addresses. >> >> Stuart Cheshire >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> > > --001a1140c8d84308870508a44bbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Guangqing,
Domain name has the meaning of both logical= space and physical space.
For example, ".home" means t= he domain of logical space for home network and also
the physical= place of my home.

In my draft, the location as pa= rt of domain name puts more weight on physical space and=C2=A0
th= e device category as part of domain name puts more weight on local space as= a device cluster in a home network.

Thanks.
=

Paul

=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. J= aehoon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software= /
Department of Computer Engineering
Sungkyunkwan University
Offi= ce: +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
= Email: pauljeong@sk= ku.edu, jae= hoon.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: h= ttp://cpslab.skku.edu/people-jaehoon-jeong.php

On Tue, Nov 25, 2014 at 1:26 AM, Guangqing D= eng <dengguangqing@cnnic.cn> wrote:
The term of "= ;IoT=20 device" is mentioned many times=C2=A0here and in the draft,=C2=A0and i= t seems=20 necessary to give a relatively formal defination to it instead of only=20 presenting some instances of so=C2=A0called=C2=A0"IoT device". The domain=20 name is usually used to uniquely and consistently identify objects and thus= it=20 is better to keep the domain name unchangeable. If many kinds of informatio= n of=20 "IoT devices" (such as their locations and categories) are insert= ed into the=20 domain name in some way, whether we should change the domain name or not if= some=20 kinds of information (like the location) changes?=20
=C2=A0
Guangqing=20 Deng
cnnic=C2=A0
=C2=A0
Date:=C2=A02014-11-19=C2=A012:00
Subject:=C2=A0Re: [dnssd] DNS Name Autoconfiguration for Home= =20 Network Devices
Stuart,
Thanks for your constructive comments.

As I answered Alf's email message just before,
I would like to allow IoT vendors to have an alternative way for DNS= =20 naming
with more compact implementation based on IPv6 stateless=20 autoconfiguration.

For the question about how users find out the host names and which=20 protocols are used
were presented with the following slides 4 and 5 during the last dnssd= WG=20 session in Hawaii:

To figure out what those devices do, we can use device category and de= vice=20 model=C2=A0
in the DNS name format.

Paul

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (Paul) Jeong,=20 Ph.D.
Assistant Professor
Department of Software /
Department of= =20 Computer Engineering
Sungkyunkwan University
Office:=20 +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Emai= l: pauljeong@skku.e= du, jaehoon= .paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http= ://cpslab.skku.edu/people-jaehoon-jeong.php

On Wed, Nov 19, 2014 at 7:46 AM, Stuart Cheshire= <cheshire@apple.com> wrote:
On 17 Nov, 2014, at 17:33, Mr. = Jaehoon Paul Jeong=20 <jaehoon.p= aul@gmail.com>=20 wrote:

> Hi Tom,
>
> You are right for appliances w= ith=20 enough capacity to run mDNS.
>
> However, for low capacity Io= T=20 devices without mDNS, my proposal will be able to support an alternative = way=20 for DNS naming.

You assert that there are devices with=20 insufficient resources to run DNS-SD/mDNS.

You assert that these= =20 devices would have sufficient resources to run your alternative.

I= =20 think you need data to substantiate these claims. Note that devices like = the=20 SitePlayer Telnet implement DNS-SD/mDNS in under one kilobyte (about 850 = bytes=20 of code, if I remember correctly): <http://netmedia.com/siteplayer/telnet/>

So you=20 need to demonstrate that:

1. That there are devices where 850 byte= s of=20 code is too much.

2. That these devices can implement your thing i= n=20 under 850 bytes.

3. That your thing is useful. I=E2=80=99m still u= nclear on=20 what your thing is useful for. Your proposal says how devices pick host n= ames,=20 but not how users find out what those host names are, or find out what th= ose=20 devices do, or what protocol to use to communicate with them, and how cli= ents=20 resolve those host names to addresses.
<= br>Stuart Cheshire


--001a1140c8d84308870508a44bbf-- From nobody Mon Nov 24 17:01:39 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A6A1A6F6B for ; Mon, 24 Nov 2014 17:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHCUk5nC7zmD for ; Mon, 24 Nov 2014 17:01:35 -0800 (PST) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F3781A6F1D for ; Mon, 24 Nov 2014 17:01:35 -0800 (PST) Received: by mail-ie0-f176.google.com with SMTP id tr6so2380206ieb.21 for ; Mon, 24 Nov 2014 17:01:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=za8nL8KeEcjg9RFh878WEqjqpbBKObbWnmsRxw8Px/Q=; b=NCcdc/WIZmTSlaFZ1+rNn2ooLlKtWj7Z/s0CanfyPMoowRA1fnmpBA/am7SVG1C/fO 8elStZy+jevMhznKRTQE2ostS/321YUPMWulIxNtZLBnNRC4zWvQbSouT0o6NqNWEs4m FfDwvQLF2AQPzN0mpuYCEV4I71moVSxAoxf1HZcEFEqS/dqxyd4ia+/9tr9uT/xxEuQQ jVbrozYSM15Wvri7IlliZKQopLZDoM7wX/HK2pN4PLJcx4adPPar8BsRrFSmzJ4Zuns0 wWkz/ysqvxBcuUIAC8GDoUjIXr5nxTd7x4YBag0oPq4mUolN6vIszmdpaP/WQmXdkbX8 E4Lg== MIME-Version: 1.0 X-Received: by 10.50.43.170 with SMTP id x10mr9659532igl.46.1416877293428; Mon, 24 Nov 2014 17:01:33 -0800 (PST) Received: by 10.64.57.14 with HTTP; Mon, 24 Nov 2014 17:01:33 -0800 (PST) In-Reply-To: <71A17712-B6C3-436D-840F-D32F654F04C9@nominum.com> References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <12750388-E313-4364-8D42-9DF75C91D91C@istumbler.net> <71A17712-B6C3-436D-840F-D32F654F04C9@nominum.com> Date: Tue, 25 Nov 2014 10:01:33 +0900 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: Ted Lemon Content-Type: multipart/alternative; boundary=089e01176cadc40e620508a473e2 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/oFzLRHBiSt_CFhzV3SqDK7idb1k Cc: Brian Haberman , Myung-Ki Shin , "dnssd@ietf.org" , Jung-Soo Park , Sejun Lee Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 01:01:37 -0000 --089e01176cadc40e620508a473e2 Content-Type: text/plain; charset=UTF-8 Ted and DNSSD people, I believe that our DNSSD working group is worthy of working on DNS name service for constrained-node networks, such as IoT. In order to lead the early deployment of IoT into the reality, a simple light DNS naming approach with only IPv6 stateless autoconfiguration will be beneficial for LLN IoT devices while the mDNS approach is used for appliances and computers in home networks. Thanks. Best Regards, Paul =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Fri, Nov 21, 2014 at 10:36 PM, Ted Lemon wrote: > I think we still haven't heard a clear explanation for why this new > protocol work is needed. That would be the key discussion to have. > Discussions about what the protocol work would entail, or how it would > integrate with other work, are premature until that discussion has reached > a conclusion. > > --089e01176cadc40e620508a473e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ted and DNSSD people,
I believe that our DNSSD working= group is worthy of working on DNS name service=C2=A0
for constra= ined-node networks, such as IoT.

In order to lead = the early deployment of IoT into the reality,=C2=A0
a simple ligh= t DNS naming approach with only IPv6 stateless autoconfiguration=C2=A0
will be beneficial for LLN IoT devices while the mDNS approach is use= d for appliances=C2=A0
and computers in home networks.
=
Thanks.

Best Regards,
Pau= l


=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaehoon (P= aul) Jeong, Ph.D.
Assistant Professor
Department of Software /
Dep= artment of Computer Engineering
Sungkyunkwan University
Office: +82-3= 1-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Email: pauljeong@skku.edu, jaehoon.paul= @gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http://cps= lab.skku.edu/people-jaehoon-jeong.php

On Fri, Nov 21, 2014 at 10:36 PM, Ted Lemon = <Ted.Lemon@nominum.com> wrote:
I think we still haven't heard a clear explanation for why thi= s new protocol work is needed.=C2=A0 =C2=A0That would be the key discussion= to have.=C2=A0 =C2=A0Discussions about what the protocol work would entail= , or how it would integrate with other work, are premature until that discu= ssion has reached a conclusion.


--089e01176cadc40e620508a473e2-- From nobody Mon Nov 24 18:25:09 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CD11A88CC for ; Mon, 24 Nov 2014 18:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtglU70Q8fWe for ; Mon, 24 Nov 2014 18:25:05 -0800 (PST) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E39581A88C0 for ; Mon, 24 Nov 2014 18:25:04 -0800 (PST) Received: by mail-qg0-f51.google.com with SMTP id l89so7600010qgf.24 for ; Mon, 24 Nov 2014 18:25:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5VPYQZOh7Oyvt3AGM29RGT9v+lRqRm3NbISNCbvC7jI=; b=z/S1vUkET+6u+N93mdelstfPg8gEilYIzviJllwo693ghy0O2SuVFWDsmACw8FdeNe L9MY4So1YsNPobtIEdgiGObrRBCQKSej6JeJ4WCR1kehCNifmpra2j/CnwLA640CyXlP W/+Vumt+5nhmmspE1CkWmFgovtL9Ri65HUG1/FpneM3uiyokyeUVp2SrToa8UHGLRGSy mVSAn8NhEjPMeQ5DbIheVjRSlY6zh/YbHObewLScOachHULWFXYs9XYj9H+7HMmpFMww QYV2AqQajfysEuDnprnA3oBZ4vlNzu3Dg4zy1HyWSFInZfWZSJEX56l+QD+/1TnIaHyn xYYw== X-Received: by 10.140.46.52 with SMTP id j49mr15112069qga.30.1416882304220; Mon, 24 Nov 2014 18:25:04 -0800 (PST) Received: from [192.168.0.54] (107-0-5-6-ip-static.hfc.comcastbusiness.net. [107.0.5.6]) by mx.google.com with ESMTPSA id u8sm13611385qat.27.2014.11.24.18.25.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Nov 2014 18:25:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Douglas Otis In-Reply-To: <20141124164333.GK2860@mx1.yitter.info> Date: Mon, 24 Nov 2014 18:25:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <1DCC9163-1439-4458-897F-9AAD1F9345CA@gmail.com> References: <0996A6E1-5218-4AFB-8646-D1047266C9ED@gmail.com> <20141120221150.GA2345@mx1.yitter.info> <5C4A3890-E575-4A88-81E6-F1EFF9930FB1@gmail.com> <20141124164333.GK2860@mx1.yitter.info> To: Andrew Sullivan X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/H13WPPDn9CvVsh4C-TWcvZgdQL0 Cc: dnssd@ietf.org Subject: Re: [dnssd] UTF8 use in DNS populated by mDNS X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 02:25:07 -0000 On Nov 24, 2014, at 8:43 AM, Andrew Sullivan = wrote: > Hi, >=20 > On Fri, Nov 21, 2014 at 06:29:12PM -0800, Douglas Otis wrote: >> Dear Andrew, >>=20 >> DNS-SD generates: >> 'Service Instance Name =3D . . ' >=20 > Yes. >=20 >> While there are restrictions on code points that define 'Instance' = per RFC5198 with an additional stipulation not to include values between = 0x00-0x1F and 0x7F >=20 > Yes. >=20 >> , how the 'Domain' portion is determined is far less clear. =20 >=20 > No. >=20 > If you read RFC 6763 carefully, you will note that the Domain portion > is also restricted to RFC 5198, which is approximately UTF-8 in NFC. It does not clearly defined where this string is obtained however, and = RFC5198 offers scant protection from trivially spoofed domains.=20 >> This is a concern when derived from easily spoofed multicast mDNS = responses. It is important a visual selection process does its best to = preclude trivial domain spoofing which might resolve malicious sources. =20= >=20 > If what you're attempting to do is prescribe, in the output of this > WG, general rules for "anti-phishing" for domain names, I am going to > resist the creation of such rules by this WG. The WG doesn't have the > requisite expertise to do that, and DNSOP is an already-existing WG > that has a possibly relevant charter (though unfortunately almost > certainly inadequate clue about the relevant i18n issues).=20 If so, a logical approach would be to specify rules currently defined = for domains permitted by registrars using IDNA2008. Unless otherwise = constrained by manual lists, this will still represent a difficult = albeit vital check. =20 >> The concern is specifically with visually deceptive resources. = Limitations on what is allowed should ensure against abuse of = right-to-left and left-to-right issues for example. >=20 > LTR and RTL issues have remarkably little to do with phishing except > in some quite specific circumstances, and in those cases it is > _imposible_ for an application to cope with the edge case in > general, because of the distributed operation of the DNS. Strongly disagree. Some type of TLD restriction MUST be imposed to = prevent rampant abuse. This might mean only allowing domains found in = the search domain list, or those defined for local networks. =20 >> Some TLDs protect users with additional rules enforced by registrars = that extend beyond those imposed by IDNA2008. =20 >=20 > Yes. That's registration policy and it is way beyond the capability > of this WG to create in a perfectly general way. Being defined in the search list, or resolved within the Internet after = conversion to A-Label form is well within the WG's ability.=20 >> Allowing naive UTF-8 publication of mDNS resources into DNS without = conversion to A-labels permitted for DNS suggests there will be an even = greater need to qualify what appears to be external actually resides = within the Internet. >=20 > No. As Dave Thaler argued quite clearly in Honolulu, you can have all > the phishing problems you want using either IDNA2008 or plain UTF-8 > labels. These are totally orthoganal problems. Again strongly disagree. Only when there is a way to constrain the = domains administrators may wish to permit, the there is no limit on the = level of very nasty spoofing techniques possible. Leaving this open to = any domain permitted by RFC5198 makes controlling this issue fairly = impractical. >> A step facilitated by imposing use of ugly A-labels within local = publication should also better guard against cache abuse as well. > =20 > How? By constraining the range of domains local DNS is expected to handle = prevents trivial exploits that may also overwhelm local storage. Such = an impact might defeat TOFU methods for example. Regards, Douglas Otis= From nobody Mon Nov 24 18:43:26 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6595D1A1B87 for ; Mon, 24 Nov 2014 18:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5mHelFLYUM9 for ; Mon, 24 Nov 2014 18:43:22 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA7F1A1B60 for ; Mon, 24 Nov 2014 18:43:22 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id EE7DBDA02EE for ; Tue, 25 Nov 2014 02:43:11 +0000 (UTC) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id 342EA53E078; Mon, 24 Nov 2014 18:42:52 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-02.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 24 Nov 2014 18:42:51 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Mon, 24 Nov 2014 21:42:43 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <12750388-E313-4364-8D42-9DF75C91D91C@istumbler.net> <71A17712-B6C3-436D-840F-D32F654F04C9@nominum.com> To: "Mr. Jaehoon Paul Jeong" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/gltHOJ02AbfBro_K0uxlZRu6tco Cc: Brian Haberman , Jung-Soo Park , Sejun Lee , "dnssd@ietf.org" , Myung-Ki Shin Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 02:43:24 -0000 On Nov 24, 2014, at 8:01 PM, Mr. Jaehoon Paul Jeong = wrote: > In order to lead the early deployment of IoT into the reality,=20 > a simple light DNS naming approach with only IPv6 stateless = autoconfiguration=20 > will be beneficial for LLN IoT devices while the mDNS approach is used = for appliances=20 > and computers in home networks. You have said this numerous times. However, in order to get IETF = consensus on some work you want to do, you need to do more than say what = work you want to do. You also have to convince some IETF working group = to adopt the work you want to do. Stuart Cheshire gave you a pretty = good summary of what you need to do to convince the working group that = this work is worth doing. Can you please read what Stuart wrote and try to do as he asked? = Please understand that if you can't show that your solution is so much = smaller than an mDNS implementation that it makes sense to do it, there = is no chance that this working group, or any other working group in the = IETF, will agree to take on the work you propose to do, as you propose = to do it. "As you propose to do it" is really important, though. If there is = some problem you have that is not addressed by existing mDNS standards = or by standards currently being contemplated by this working group, then = you should try to explain how that problem is different from the = problems mDNS already solves. In that case, even if the working group = doesn't agree to work on your specific solution to the problem, we may = decide that the problem you want to solve is important, and may = therefore agree to work on a solution to that problem. From nobody Mon Nov 24 19:54:17 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00771A1B8A for ; Mon, 24 Nov 2014 19:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RUF0aeAt42-p for ; Mon, 24 Nov 2014 19:54:15 -0800 (PST) Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3AC1A1B7D for ; Mon, 24 Nov 2014 19:54:14 -0800 (PST) Received: by mail-ie0-f174.google.com with SMTP id rl12so10227789iec.33 for ; Mon, 24 Nov 2014 19:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZjuGmKO5r99Xhx2nxKDEUCMPrf1Wme1FoL7FcX9PebU=; b=SEqtzw8+DyZVovBP0pzG6krnGeziyh0W4Egh9iGZfzTOHGtbSxkih5TDeuTl8bTQSq PukYdUlXTgQyYlqliq/RuwRshgkwK+LS8CfS5h9IvCjyTqypNQxEtrJlG9d1ji9sWaWf AVK96FAaXqNw7CXAOZLiJWXjUHZ2GWN3rl10cuMiwLIVQNiwGqXlOxbzFGFzY+WZBBfq rOqeJC5+PXy2wh84wSlLilJaZZHuYmL6zUn1sq6LKKtmsa02wVeU+2U5tRN2MsJ6vob/ /9r4X9lnZ0g/7egR9GRGFk+N5TrEKo8JqsGO5/kMH818U4EHEwurYP3nA9SD1eIdq/qi hMsw== MIME-Version: 1.0 X-Received: by 10.50.66.179 with SMTP id g19mr15671142igt.40.1416887653092; Mon, 24 Nov 2014 19:54:13 -0800 (PST) Received: by 10.64.57.14 with HTTP; Mon, 24 Nov 2014 19:54:12 -0800 (PST) In-Reply-To: References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <12750388-E313-4364-8D42-9DF75C91D91C@istumbler.net> <71A17712-B6C3-436D-840F-D32F654F04C9@nominum.com> Date: Tue, 25 Nov 2014 12:54:12 +0900 Message-ID: From: "Mr. Jaehoon Paul Jeong" To: Ted Lemon Content-Type: multipart/alternative; boundary=047d7bdc15b23fd81b0508a6dd79 Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/8CsFhJefep7RzvmsAfvrO1pkG4A Cc: Brian Haberman , Jung-Soo Park , Sejun Lee , "dnssd@ietf.org" , Myung-Ki Shin Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 03:54:17 -0000 --047d7bdc15b23fd81b0508a6dd79 Content-Type: text/plain; charset=UTF-8 Ted, I agree that mDNS with 850 bytes in binary does not require so much in memory. However, every engineer for IoT devices must implement much more source code than 850 bytes for a simple DNS name autoconfiguration. On the other hand, my proposal will require much less source code than mDNS, allowing the engineers to make less efforts. This is my point. Paul =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Assistant Professor Department of Software / Department of Computer Engineering Sungkyunkwan University Office: +82-31-299-4957 Mobile: +82-10-4758-1765 Fax: +82-31-290-5119 Email: pauljeong@skku.edu, jaehoon.paul@gmail.com CPS Lab Website: http://cpslab.skku.edu Personal Homepage: http://cpslab.skku.edu/people-jaehoon-jeong.php On Tue, Nov 25, 2014 at 11:42 AM, Ted Lemon wrote: > On Nov 24, 2014, at 8:01 PM, Mr. Jaehoon Paul Jeong < > jaehoon.paul@gmail.com> wrote: > > In order to lead the early deployment of IoT into the reality, > > a simple light DNS naming approach with only IPv6 stateless > autoconfiguration > > will be beneficial for LLN IoT devices while the mDNS approach is used > for appliances > > and computers in home networks. > > You have said this numerous times. However, in order to get IETF > consensus on some work you want to do, you need to do more than say what > work you want to do. You also have to convince some IETF working group to > adopt the work you want to do. Stuart Cheshire gave you a pretty good > summary of what you need to do to convince the working group that this work > is worth doing. > > Can you please read what Stuart wrote and try to do as he asked? Please > understand that if you can't show that your solution is so much smaller > than an mDNS implementation that it makes sense to do it, there is no > chance that this working group, or any other working group in the IETF, > will agree to take on the work you propose to do, as you propose to do it. > > "As you propose to do it" is really important, though. If there is some > problem you have that is not addressed by existing mDNS standards or by > standards currently being contemplated by this working group, then you > should try to explain how that problem is different from the problems mDNS > already solves. In that case, even if the working group doesn't agree to > work on your specific solution to the problem, we may decide that the > problem you want to solve is important, and may therefore agree to work on > a solution to that problem. > > --047d7bdc15b23fd81b0508a6dd79 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ted,
I agree that mDNS with 850 bytes in binary does n= ot require so much in memory.
However, every engineer for IoT dev= ices must implement much more source code than 850 bytes for
a si= mple DNS name autoconfiguration.
On the other hand, my proposal w= ill require much less source code than mDNS,=C2=A0
allowing the e= ngineers to make less efforts.
This is my point.

Paul =C2=A0

=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Mr. Jaeh= oon (Paul) Jeong, Ph.D.
Assistant Professor
Department of Software /<= br>Department of Computer Engineering
Sungkyunkwan University
Office:= +82-31-299-4957
Mobile: +82-10-4758-1765
Fax: +82-31-290-5119
Ema= il: pauljeong@skku.= edu, jaehoo= n.paul@gmail.com
CPS Lab Website: http://cpslab.skku.edu
Personal Homepage: http= ://cpslab.skku.edu/people-jaehoon-jeong.php

On Tue, Nov 25, 2014 at 11:42 AM, Ted Lemon = <Ted.Lemon@nominum.com> wrote:
On Nov 24, 2014, at 8:01 PM, Mr. Jaehoon Paul Jeo= ng <jaehoon.paul@gmail.com= > wrote:
> In order to lead the early deployment of IoT into the reality,
> a simple light DNS naming approach with only IPv6 stateless autoconfig= uration
> will be beneficial for LLN IoT devices while the mDNS approach is used= for appliances
> and computers in home networks.

You have said this numerous times.=C2=A0 =C2=A0However, in order to = get IETF consensus on some work you want to do, you need to do more than sa= y what work you want to do.=C2=A0 =C2=A0You also have to convince some IETF= working group to adopt the work you want to do.=C2=A0 =C2=A0Stuart Cheshir= e gave you a pretty good summary of what you need to do to convince the wor= king group that this work is worth doing.

Can you please read what Stuart wrote and try to do as he asked?=C2=A0 =C2= =A0Please understand that if you can't show that your solution is so mu= ch smaller than an mDNS implementation that it makes sense to do it, there = is no chance that this working group, or any other working group in the IET= F, will agree to take on the work you propose to do, as you propose to do i= t.

"As you propose to do it" is really important, though.=C2=A0 =C2= =A0If there is some problem you have that is not addressed by existing mDNS= standards or by standards currently being contemplated by this working gro= up, then you should try to explain how that problem is different from the p= roblems mDNS already solves.=C2=A0 =C2=A0In that case, even if the working = group doesn't agree to work on your specific solution to the problem, w= e may decide that the problem you want to solve is important, and may there= fore agree to work on a solution to that problem.


--047d7bdc15b23fd81b0508a6dd79-- From nobody Mon Nov 24 20:17:26 2014 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA41F1A1B89 for ; Mon, 24 Nov 2014 20:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcKnj_IY8c2N for ; Mon, 24 Nov 2014 20:17:22 -0800 (PST) Received: from sjc1-mx02-inside.nominum.com (sjc1-mx02-inside.nominum.com [64.89.234.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E151A1B87 for ; Mon, 24 Nov 2014 20:17:21 -0800 (PST) Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 32A3DDA02EE for ; Tue, 25 Nov 2014 04:17:11 +0000 (UTC) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTP id E699653E078; Mon, 24 Nov 2014 20:16:50 -0800 (PST) Received: from [10.0.20.107] (71.233.43.215) by CAS-01.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 24 Nov 2014 20:16:50 -0800 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: Date: Mon, 24 Nov 2014 23:16:40 -0500 Content-Transfer-Encoding: quoted-printable Message-ID: <5C66B178-8446-4F2D-B08F-E203B5285664@nominum.com> References: <436692B4-978D-4E62-868E-78FA8AF3F26F@nominum.com> <12750388-E313-4364-8D42-9DF75C91D91C@istumbler.net> <71A17712-B6C3-436D-840F-D32F654F04C9@nominum.com> To: "Mr. Jaehoon Paul Jeong" X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: http://mailarchive.ietf.org/arch/msg/dnssd/wO8DCCz6UEbFpkW4yK5xLDIG3fY Cc: Brian Haberman , Jung-Soo Park , Sejun Lee , "dnssd@ietf.org" , Myung-Ki Shin Subject: Re: [dnssd] DNS Name Autoconfiguration for Home Network Devices X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 04:17:24 -0000 On Nov 24, 2014, at 10:54 PM, Mr. Jaehoon Paul Jeong = wrote: > However, every engineer for IoT devices must implement much more = source code than 850 bytes for > a simple DNS name autoconfiguration. > On the other hand, my proposal will require much less source code than = mDNS,=20 > allowing the engineers to make less efforts. > This is my point. What matters is the size of the compiled code, no the size of the source = code. If you think Stuart is mistaken, please show your work: show = that what you propose can be implemented in a significantly smaller code = footprint than what Stuart is describing.