From nobody Mon Mar 2 02:18:28 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0C43A1A701E; Mon, 2 Mar 2015 01:53:54 -0800 (PST) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F921A701C for ; Mon, 2 Mar 2015 01:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 JxbddtdGuckW for ; Mon, 2 Mar 2015 01:53:53 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08E7B1A7012 for ; Mon, 2 Mar 2015 01:53:53 -0800 (PST) Received: from szxga03-in.huawei.com ([119.145.14.66]:16229) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YSN2t-0001iN-EM; Mon, 02 Mar 2015 01:53:52 -0800 Received: from 172.24.2.119 (EHLO nkgeml405-hub.china.huawei.com) ([172.24.2.119]) by szxrg03-dlp.huawei.com (MOS 4.4.3-GA FastPath queued) with ESMTP id BCM66307; Mon, 02 Mar 2015 17:53:42 +0800 (CST) Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 2 Mar 2015 17:53:40 +0800 From: Sheng Jiang To: "ops-ads@tools.ietf.org" Thread-Topic: OPS-DiR review of draft-ietf-dnssd-requirements Thread-Index: AQHQJ8XIgwFBXRH7RkGjqN7sfmgVl50JTRbg Date: Mon, 2 Mar 2015 09:53:39 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B053E83@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B0041C0@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923B0041C0@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.54F43326.0509, ss=1, re=0.001, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.106, so=2013-05-26 15:14:31, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9f7f7239c6681ad000e9538f944c5e90 X-SA-Exim-Connect-IP: 119.145.14.66 X-SA-Exim-Rcpt-To: draft-ietf-dnssd-requirements.all@tools.ietf.org, ops-ads@tools.ietf.org X-SA-Exim-Mail-From: jiangsheng@huawei.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-dnssd-requirements.all@ietf.org Resent-To: bclaise@cisco.com, joelja@bogus.com, joelja@bogus.com Resent-Message-Id: <20150302095353.08E7B1A7012@ietfa.amsl.com> Resent-Date: Mon, 2 Mar 2015 01:53:53 -0800 (PST) Resent-From: jiangsheng@huawei.com Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 02 Mar 2015 02:18:26 -0800 Cc: "'draft-ietf-dnssd-requirements.all@tools.ietf.org'" , "ops-ads@tools.ietf.org" Subject: Re: [dnssd] OPS-DiR review of draft-ietf-dnssd-requirements 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, 02 Mar 2015 09:53:54 -0000 UmVzZW5kIHRoaXMgd2l0aCByaWdodCBlbWFpbCBhZGRyZXNzLiBTb21laG93LCB0aGUgb3JpZ2lu YWwgZW1haWwgbWlzc2VkIHRoZSBtb3N0IGltcG9ydGFudCBPUFMgZGlyIG1haWwgbGlzdC4gSXQg d2FzIGFsbW9zdCB0d28gbW9udGhzIGFnby4gSG9wZWZ1bGx5LCB3aXRoIHRoZSBkcmFmdC5hbGwg ZW1haWwgYWRkcmVzcywgaXQgYXJyaXZlZCB0aGUgYXV0aG9ycyBhbmQgbWFpbCBsaXN0Lg0KDQpC ZXN0IHJlZ2FyZHMsDQoNClNoZW5nDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZy b206IFNoZW5nIEppYW5nDQo+U2VudDogVHVlc2RheSwgSmFudWFyeSAwNiwgMjAxNSAxMTowNSBQ TQ0KPlRvOiBvcHMtYWRzQHRvb2xzLmlldGYub3JnDQo+Q2M6IGRyYWZ0LWlldGYtZG5zc2QtcmVx dWlyZW1lbnRzLmFsbEB0b29scy5pZXRmLm9yZw0KPlN1YmplY3Q6IE9QUy1EaVIgcmV2aWV3IG9m IGRyYWZ0LWlldGYtZG5zc2QtcmVxdWlyZW1lbnRzDQo+DQo+RGVhciBhbGwsDQo+DQo+SSBoYXZl IHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgT3BlcmF0aW9uYWwgZGlyZWN0 b3JhdGUncw0KPm9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVp bmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLg0KPlRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBw cmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBvcGVyYXRpb25hbA0KPmFyZWEgZGlyZWN0 b3JzLiBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNv bW1lbnRzDQo+anVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+DQo+SW50 ZW5kZWQgc3RhdHVzOiBJbmZvcm1hdGlvbmFsDQo+DQo+U3VtbWFyeTogVGhpcyBkb2N1bWVudCBw cm92aWRlcyBhIHByb2JsZW0gc3RhdGVtZW50IGFuZCBhIGxpc3Qgb2YNCj5yZXF1aXJlbWVudHMg Zm9yIHNjYWxhYmxlIEROUy1TRC9tRE5TIGV4dGVuc2lvbnMuIEkgZm91bmQgaXQgaXMgd2VsbCB3 cml0dGVuDQo+d2l0aCBubyBiaWcgY29uY2VybnMuIEkgZG8gaGF2ZSBzb21lIG1pbm9yIGNvbW1l bnRzLg0KPg0KPkluIHNlY3Rpb24gMi4xLCB0aGUgbGFzdCAoZmlmdGgpIGJ1bGxldCBpdGVtIG9m IHRlY2huaWNhbCBpc3N1ZXMgaXMgYWN0dWFsbHkgdGhlDQo+c3VtbWFyaWVkIHJlcXVpcmVtZW50 LiBUaGUgZm9sbG93ZWQgdGVjaG5pY2FsIHJlcXVpcmVtZW50cyBhcmUgYWN0dWFsbHkgdGhlDQo+ ZGV0YWlsZWQgcmVxdWlyZW1lbnRzIGZvciB0aGUgcmVxdWlyZWQgbWVjaGFuaXNtIGluIHRoaXMg YnVsbGV0IGl0ZW0uDQo+DQo+VGhlIGZpcnN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDIuMyBtYXkg bmVlZCBhIGxpdHRsZSBiaXQgcmVvcmdhbml6ZWQuIGhlIGN1cnJlbnQNCj5mb3JtIGRvZXMgbm90 IGNsZWFybHkgZGVzY3JpYmUgd2h5IHRoZSB3aXJlbGVzcyBtZXNoIG5ldHdvcmsgcmVxdWlyZSBt RE5TDQo+bmVlZCB0byBzdXBwb3J0IG92ZXIgbXVsdGlwbGUgbGlua3MgaW4gYSB3aXJlbGVzcyBt ZXNjaCBuZXR3b3JrLg0KPg0KPlNlY3Rpb24gMywgdXNlIGNhc2UgQSwgaXQgd291bGQgYmUgdmVy eSB1c2VmdWwgaWYgc29tZSBhZG9wdGlvbiBzdGF0dXMgb2YgWmVybw0KPkNvbmZpZ3VyYXRpb24g TmV0d29yayBbWkNdIGNvdWxkIGJlIGdpdmVuLiBGb3Igbm93LCB0aGVyZSBtYXkgYmUgc29tZQ0K PmNvbmNlcm4gb3ZlciB3aGV0aGVyIGl0IGlzIGEgd2lkZWx5IHVzZWQgdGVjaG5vbG9neS4NCj4N Cj5TZWN0aW9uMywgaXQgc2VlbXMgYWxsIHVzZSBjYXNlcyBhcmUgYXNzdW1pbmcgdGhlIHNpbmds ZSBleGl0IHJvdXRlci4gQnV0IHRoZQ0KPnNjZXJhcmlvcyBvZiBtdWx0aXBsZSBleGl0IHJvdXRl cnMgd291bGQgYmUgYSBjb21tb24gdXNlIGNhc2UgYXMgd2VsbC4gSXMgdGhpcw0KPmxlZnQgb3V0 IG9mIHNjb3BlIGludGVudGlvbmFsbHk/IElmIHNvLCBzb21lIGV4cGxhbmF0aW9uIGZvciB0aGUg cmVhc29uIG1heQ0KPmhlbHBmdWwuDQo+DQo+U2VjdGlvbiA0LCBSRVE4IGxvb2tzIGEgdmVyeSBm dW5kZW1lbnRhbCByZXF1aXJlbWVudCBmb3IgYWxsIHNlcnZpY2UNCj5kaXNjb3ZlcnkgbWVjaGFu aXNtLiBJdCBkb2VzIG5vdCBsb29rIGxpa2UgYSBzcGVjaWZpYyByZXF1aXJlbWVudCBmb3IgU1NE Lg0KPg0KPlNlY3Rpb24gNCwgUkVRMTMgbWF5IG5lZWQgcmV3b3JkZWQuIFRoZSBmaXJzdCBzZW50 ZW5zZSBzYWlkICJjbG9zZWx5DQo+cmVmbGVjdGlvbiByZWFsaXR5Ii4gVGhlIGZvbGxvdy11cCBl eHBsYW5hdGlvbnMgYXJlIGFsbCBhYm91dCByZWFsLXRpbWUgb3IgY2xvc2UNCj50byByZWFsLXRp bWUuDQo+DQo+U2VjdGlvbiA0LCBSRVExNCwgU1NEIHJlcXVlc3RzIHNvbWUgbmV3IGZ1bmN0aW9u cyBvbiBuZXR3b3JrIGRldmljZXMuIEl0IGlzDQo+YSBjaGFuZ2UgdG8gdGhlIG5ldHdvcmsgdGVj aG5vbG9neS4NCj4NCj5TZWN0aW9uIDUgbG9va3MgYSBzcGVjaWZpYyBwcm9ibGVtIHN0YXRlbWVu dCBmb3IgbmFtZXNwYWNlLiBBIGJldHRlciBwbGFjZQ0KPm1heSBiZSBhcyBzZWN0aW9uIDIuNC4g QWxzbywgdGhlcmUgc2hvdWxkIGJlIHNvbWUgY29ycmVzcG9uZGVudA0KPnJlcXVpcmVtZW50cywg SSBiZWxpZXZlLg0KPg0KPlNlY3Rpb24gNiByYWlzZXMgc29tZSBzZWN1cml0eSByZXF1aXJlbWVu dHMgZm9yIFNTRC4gVGhleSBzaG91bGQgYWxzbyBiZQ0KPnN1bW1hcmllZCBhbmQgbGlzdGVkIGFz IG51bWJlcmVkIHJlcXVpcmVtZW50cyBpbiBTZWN0aW9uIDQuDQo+DQo+QmVzdCByZWdhcmRzLA0K Pg0KPlNoZW5nDQo= From nobody Tue Mar 3 04:09:36 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B64F91A9027; Mon, 2 Mar 2015 17:07:10 -0800 (PST) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960DF1A9026 for ; Mon, 2 Mar 2015 17:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] 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 Rk-oL2fL3o09 for ; Mon, 2 Mar 2015 17:07:09 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A92201A901F for ; Mon, 2 Mar 2015 17:07:09 -0800 (PST) Received: from szxga02-in.huawei.com ([119.145.14.65]:16080) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YSbIi-0002Th-Dc for draft-ietf-dnssd-requirements.all@tools.ietf.org; Mon, 02 Mar 2015 17:07:09 -0800 Received: from 172.24.2.119 (EHLO nkgeml403-hub.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CHW63953; Mon, 02 Mar 2015 17:57:10 +0800 (CST) Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.106]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Mon, 2 Mar 2015 17:57:08 +0800 From: Sheng Jiang To: "ops-dir@ietf.org" Thread-Topic: OPS-DIR review of draft-ietf-dnssd-requirements Thread-Index: AQHQJ8XIgwFBXRH7RkGjqN7sfmgVl50JTRbggAABMdA= Date: Mon, 2 Mar 2015 09:57:08 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923B053E9C@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923B0041C0@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.99.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-SA-Exim-Connect-IP: 119.145.14.65 X-SA-Exim-Rcpt-To: draft-ietf-dnssd-requirements.all@tools.ietf.org X-SA-Exim-Mail-From: jiangsheng@huawei.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-dnssd-requirements.all@ietf.org Resent-Message-Id: <20150303010709.A92201A901F@ietfa.amsl.com> Resent-Date: Mon, 2 Mar 2015 17:07:09 -0800 (PST) Resent-From: jiangsheng@huawei.com Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 03 Mar 2015 04:09:35 -0800 Cc: "'draft-ietf-dnssd-requirements.all@tools.ietf.org'" Subject: Re: [dnssd] OPS-DIR review of draft-ietf-dnssd-requirements 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, 03 Mar 2015 01:07:10 -0000 UmVzZW5kIHRoaXMgd2l0aCByaWdodCBlbWFpbCBhZGRyZXNzLiBJbiB0aGUgb3JpZ2luYWwgZW1h aWwsIG15IGVtYWlsIHNvZnR3YXJlIG1hZGUgYSBtaXN0YWtlIHRvIGF1dG8tc3BlbGwgdGhlIE9Q UyBkaXIgbWFpbCBsaXN0IHRvIG9wcy1hZHMuIEl0IHdhcyBhbG1vc3QgdHdvIG1vbnRocyBhZ28u IEhvcGVmdWxseSwgd2l0aCB0aGUgZHJhZnQuYWxsIGVtYWlsIGFkZHJlc3MsIGl0IGFycml2ZWQg dGhlIGF1dGhvcnMgYW5kIG1haWwgbGlzdC4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+ LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBTaGVuZyBKaWFuZw0KPlNlbnQ6IFR1 ZXNkYXksIEphbnVhcnkgMDYsIDIwMTUgMTE6MDUgUE0NCj5Ubzogb3BzLWFkc0B0b29scy5pZXRm Lm9yZw0KPkNjOiBkcmFmdC1pZXRmLWRuc3NkLXJlcXVpcmVtZW50cy5hbGxAdG9vbHMuaWV0Zi5v cmcNCj5TdWJqZWN0OiBPUFMtRGlSIHJldmlldyBvZiBkcmFmdC1pZXRmLWRuc3NkLXJlcXVpcmVt ZW50cw0KPg0KPkRlYXIgYWxsLA0KPg0KPkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFz IHBhcnQgb2YgdGhlIE9wZXJhdGlvbmFsIGRpcmVjdG9yYXRlJ3MNCj5vbmdvaW5nIGVmZm9ydCB0 byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4N Cj5UaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBv ZiB0aGUgb3BlcmF0aW9uYWwNCj5hcmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQg V0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cw0KPmp1c3QgbGlrZSBhbnkgb3Ro ZXIgbGFzdCBjYWxsIGNvbW1lbnRzLg0KPg0KPkludGVuZGVkIHN0YXR1czogSW5mb3JtYXRpb25h bA0KPg0KPlN1bW1hcnk6IFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBwcm9ibGVtIHN0YXRlbWVu dCBhbmQgYSBsaXN0IG9mDQo+cmVxdWlyZW1lbnRzIGZvciBzY2FsYWJsZSBETlMtU0QvbUROUyBl eHRlbnNpb25zLiBJIGZvdW5kIGl0IGlzIHdlbGwgd3JpdHRlbg0KPndpdGggbm8gYmlnIGNvbmNl cm5zLiBJIGRvIGhhdmUgc29tZSBtaW5vciBjb21tZW50cy4NCj4NCj5JbiBzZWN0aW9uIDIuMSwg dGhlIGxhc3QgKGZpZnRoKSBidWxsZXQgaXRlbSBvZiB0ZWNobmljYWwgaXNzdWVzIGlzIGFjdHVh bGx5IHRoZQ0KPnN1bW1hcmllZCByZXF1aXJlbWVudC4gVGhlIGZvbGxvd2VkIHRlY2huaWNhbCBy ZXF1aXJlbWVudHMgYXJlIGFjdHVhbGx5IHRoZQ0KPmRldGFpbGVkIHJlcXVpcmVtZW50cyBmb3Ig dGhlIHJlcXVpcmVkIG1lY2hhbmlzbSBpbiB0aGlzIGJ1bGxldCBpdGVtLg0KPg0KPlRoZSBmaXJz dCBwYXJhZ3JhcGggb2Ygc2VjdGlvbiAyLjMgbWF5IG5lZWQgYSBsaXR0bGUgYml0IHJlb3JnYW5p emVkLiBoZSBjdXJyZW50DQo+Zm9ybSBkb2VzIG5vdCBjbGVhcmx5IGRlc2NyaWJlIHdoeSB0aGUg d2lyZWxlc3MgbWVzaCBuZXR3b3JrIHJlcXVpcmUgbUROUw0KPm5lZWQgdG8gc3VwcG9ydCBvdmVy IG11bHRpcGxlIGxpbmtzIGluIGEgd2lyZWxlc3MgbWVzY2ggbmV0d29yay4NCj4NCj5TZWN0aW9u IDMsIHVzZSBjYXNlIEEsIGl0IHdvdWxkIGJlIHZlcnkgdXNlZnVsIGlmIHNvbWUgYWRvcHRpb24g c3RhdHVzIG9mIFplcm8NCj5Db25maWd1cmF0aW9uIE5ldHdvcmsgW1pDXSBjb3VsZCBiZSBnaXZl bi4gRm9yIG5vdywgdGhlcmUgbWF5IGJlIHNvbWUNCj5jb25jZXJuIG92ZXIgd2hldGhlciBpdCBp cyBhIHdpZGVseSB1c2VkIHRlY2hub2xvZ3kuDQo+DQo+U2VjdGlvbjMsIGl0IHNlZW1zIGFsbCB1 c2UgY2FzZXMgYXJlIGFzc3VtaW5nIHRoZSBzaW5nbGUgZXhpdCByb3V0ZXIuIEJ1dCB0aGUNCj5z Y2VyYXJpb3Mgb2YgbXVsdGlwbGUgZXhpdCByb3V0ZXJzIHdvdWxkIGJlIGEgY29tbW9uIHVzZSBj YXNlIGFzIHdlbGwuIElzIHRoaXMNCj5sZWZ0IG91dCBvZiBzY29wZSBpbnRlbnRpb25hbGx5PyBJ ZiBzbywgc29tZSBleHBsYW5hdGlvbiBmb3IgdGhlIHJlYXNvbiBtYXkNCj5oZWxwZnVsLg0KPg0K PlNlY3Rpb24gNCwgUkVROCBsb29rcyBhIHZlcnkgZnVuZGVtZW50YWwgcmVxdWlyZW1lbnQgZm9y IGFsbCBzZXJ2aWNlDQo+ZGlzY292ZXJ5IG1lY2hhbmlzbS4gSXQgZG9lcyBub3QgbG9vayBsaWtl IGEgc3BlY2lmaWMgcmVxdWlyZW1lbnQgZm9yIFNTRC4NCj4NCj5TZWN0aW9uIDQsIFJFUTEzIG1h eSBuZWVkIHJld29yZGVkLiBUaGUgZmlyc3Qgc2VudGVuc2Ugc2FpZCAiY2xvc2VseQ0KPnJlZmxl Y3Rpb24gcmVhbGl0eSIuIFRoZSBmb2xsb3ctdXAgZXhwbGFuYXRpb25zIGFyZSBhbGwgYWJvdXQg cmVhbC10aW1lIG9yIGNsb3NlDQo+dG8gcmVhbC10aW1lLg0KPg0KPlNlY3Rpb24gNCwgUkVRMTQs IFNTRCByZXF1ZXN0cyBzb21lIG5ldyBmdW5jdGlvbnMgb24gbmV0d29yayBkZXZpY2VzLiBJdCBp cw0KPmEgY2hhbmdlIHRvIHRoZSBuZXR3b3JrIHRlY2hub2xvZ3kuDQo+DQo+U2VjdGlvbiA1IGxv b2tzIGEgc3BlY2lmaWMgcHJvYmxlbSBzdGF0ZW1lbnQgZm9yIG5hbWVzcGFjZS4gQSBiZXR0ZXIg cGxhY2UNCj5tYXkgYmUgYXMgc2VjdGlvbiAyLjQuIEFsc28sIHRoZXJlIHNob3VsZCBiZSBzb21l IGNvcnJlc3BvbmRlbnQNCj5yZXF1aXJlbWVudHMsIEkgYmVsaWV2ZS4NCj4NCj5TZWN0aW9uIDYg cmFpc2VzIHNvbWUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZvciBTU0QuIFRoZXkgc2hvdWxkIGFs c28gYmUNCj5zdW1tYXJpZWQgYW5kIGxpc3RlZCBhcyBudW1iZXJlZCByZXF1aXJlbWVudHMgaW4g U2VjdGlvbiA0Lg0KPg0KPkJlc3QgcmVnYXJkcywNCj4NCj5TaGVuZw0K From nobody Tue Mar 3 16:09:57 2015 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 5EF2D1A875B for ; Tue, 3 Mar 2015 16:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.311 X-Spam-Level: X-Spam-Status: No, score=-104.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=unavailable 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 VUO4p2JPhfbC for ; Tue, 3 Mar 2015 16:09:49 -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 6C0371A1BF5 for ; Tue, 3 Mar 2015 16:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1425427786; x=2289341386; 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=yFsRoTA/HB8tcN4euEWkxIzGleLvqQ1r566gJEY10aE=; b=tTR8IGyShIjbHroSrhgrpsMBMwnaweNageyXzEPWssesouPuxWJUHeb2+MvbjhtT U65RCUGMsTEamIOO7TckqcnTCXCZFaEx9glCv2neDJle0ZY5m0oODpNicSX86af5 7AH6iZE1u9l8f3UYZYxDFA23Q9Pf0opmv3IJ9jSW2ivy/WeDgVA9frq+CWq40J7k GXcJSUOHk0ey4GoDhENrlK7KpBGKQ7JWIYSIXyZiRmd1E99WbYtI7JwTviKeyq7I erH65ZO/Oj8NfhkvigTIskwzOy6qw49GluPn4zL5tBTXkFwZ1ae0fO2uu8f65s85 dffgva+Xht0YL2e72WMeUA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 0F.F2.00537.A4D46F45; Tue, 3 Mar 2015 16:09:46 -0800 (PST) X-AuditID: 11973e11-f79e16d000000219-48-54f64d4a1ed0 Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id F9.EA.05157.51D46F45; Tue, 3 Mar 2015 16:08:53 -0800 (PST) Received: from [17.153.23.83] by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NKN006YGV3Y7I20@nwk-phonehomebzp-sz01.apple.com>; Tue, 03 Mar 2015 16:09:45 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Stuart Cheshire In-reply-to: <90A26CE2-87CC-4C8C-BEF9-FDF021C4FE97@iki.fi> Date: Tue, 03 Mar 2015 16:09:46 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <20141217201155.19208.95569.idtracker@ietfa.amsl.com> <90A26CE2-87CC-4C8C-BEF9-FDF021C4FE97@iki.fi> To: Markus Stenberg X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUi2FAYpevl+y3EYNJHFov3S2cxWjzbOJ/F gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZs+6uYSqYwFzROXkdYwPjDqYuRk4OCQETif3vJrND 2GISF+6tZ+ti5OIQEtjLKLFz5jp2mKKlS24yQiQWMEncnDuXGSQhJPCPUeL4R5MuRg4OZgF1 iSlTckHCvAIGEl92HgXrFRaYwCjxbUkAiM0moCXx4vMVNpByTgEridvLzUHCLAKqEmfXnWEB sZkFFCWO/FrECmFrSzx5d4EVYqSNxOU9MxghthZK7JhyGux+EQEdiQufDrKCjJQQkJfo2ZQO cqWEQCObxML2XywTGIVnIRw3C8lxs5BsWMDIvIpRKDcxM0c3M89IL7GgICdVLzk/dxMjKJSn 2wnuYDy+yuoQowAHoxIP7wT2ryFCrIllxZW5hxilOViUxHnX1X4JERJITyxJzU5NLUgtii8q zUktPsTIxMEp1cC4J8gx3K+koeNrjZPRqidh7adYzq48bHRu5X/+nT1/g9czfisN3+r/RsU5 eX0MQ7DpsleyL7qzu/cE5qmW+0TemRfk6P7ci9ezPJtBevcXt5DpsqGyfxdvXDjzyI4JVUbp uk8adA7pp+/a9sB23o9b2kYK7z+/3LgkYfXimz5JzF0xa0rOXJ6hxFKckWioxVxUnAgAFfKT zUYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUiON3OQVfU91uIwfF90hbvl85itHi2cT6L A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyZt1dw1Qwgbmic/I6xgbGHUxdjJwcEgImEkuX3GSE sMUkLtxbz9bFyMUhJLCASeLm3LnMIAkhgX+MEsc/mnQxcnAwC6hLTJmSCxLmFTCQ+LLzKDuI LSwwgVHi25IAEJtNQEvixecrbCDlnAJWEreXm4OEWQRUJc6uO8MCYjMLKEoc+bWIFcLWlnjy 7gIrxEgbict7ZjBCbC2U2DHlNNiZIgI6Ehc+HWQFGSkhIC/Rsyl9AqPALIR7ZiG5ZxaSoQsY mVcxChSl5iRWmuklFhTkpOol5+duYgSFXkNh1A7GhuVWhxgFOBiVeHgnsH8NEWJNLCuuzD3E KMHBrCTC+9jgW4gQb0piZVVqUX58UWlOavEhRmkOFiVx3g07P4QICaQnlqRmp6YWpBbBZJk4 OKUaGO38zi1JOHP8v/SZp64R0/JS3l24VZLYx50ov8N2e1Qn8zV26xnVy35Lua7XUPGVNWOP fLB2x9R539IPxEoyBjyf/ulu1+6dvO8ePZ1t+ffgk6i5D7R+RPZnzZRccWi/UGl86vHGF9of Jd3Ls30ftrzffebx4oNH13/9V5BT1rnhuPd3mbs+SW+VWIozEg21mIuKEwGhJBRJOQIAAA== Archived-At: Cc: dnssd@ietf.org, ietf@ietf.org Subject: Re: [dnssd] Last Call: (Requirements for Scalable DNS-SD/mDNS Extensions) to Informational RFC 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, 04 Mar 2015 00:09:51 -0000 On 5 Jan, 2015, at 03:44, Markus Stenberg = wrote: > - REQ5: I am not sure what =E2=80=98integrate=E2=80=99 means here. = Unidirectional access (SSD -> DNS-SD/mDNS? SSD <- DNS-SD/mDNS?)? = Bidirectional? Is this better? REQ5: SSD should leverage and build upon with current link scope DNS-SD/mDNS protocols and deployments. Stuart Cheshire From nobody Tue Mar 3 17:03:58 2015 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 F2C4A1A89AB for ; Tue, 3 Mar 2015 17:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 uZC_EPopVHSA for ; Tue, 3 Mar 2015 17:03:54 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9D01A88E7 for ; Tue, 3 Mar 2015 17:03:54 -0800 (PST) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 3 Mar 2015 19:03:53 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f181.google.com [209.85.223.181] #+LO+TS+TR X-Umn-Classification: local Received: by iery20 with SMTP id y20so10006498ier.13 for ; Tue, 03 Mar 2015 17:03:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=whNVDlCasXlOINf3kjwIu273SWdbfWfEM9zk2Fr+9JI=; b=A2NG6qUJ51/6j6XZpxE2cX0UPOlLZhMNXI/42/PGHcFn4LW0slRxDMDZoDAgHdK2Tp zlacycvs+ITmjEE5Doo7mNOqDyEIxnXM8Bj/vBVN2LL6jvzRw/twlrRzseJmAJrMB7fv nvPXinmwsiuPYbQrsX3PTpmgxRi0tmsqKuqbo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=whNVDlCasXlOINf3kjwIu273SWdbfWfEM9zk2Fr+9JI=; b=IvSovax2QkDwfFS/y1JTnfYvcnbp8ekXxuuXMhUzAnFPuiFdBJ7E/pMYeXpA913+xj WffT6v1cxZfnnjxiNBFqwzzVClaDLkPR6XUfzOCnqDa+1IhfWSWUgoqlMKYnORZZsdBY scRruJVspXhRs2JdyEVgGukcOYiY6kGfAk1sbYdp5iEDcNMbK/vlIL2qztf2L2FSxQXH lGPw0AHfOEDLgb3YMYfqNrUIiEx15AMlIL+rOkXhBIMDp9RovBoNN71WjJeSSn0zHJ9b DMoDypNIyn0kUKIQGcPNH2S/U3xwdXNy0ltiOOGPlxuSRqzm5XbJ3zL1YQHAZS5jhZuR 6Tbg== X-Gm-Message-State: ALoCoQknKqU1BSR5ZxoEN6OOikzInyKYtHG99yNB4jLkjCNjAqmuqEBEx7Pz8QK3ZDYypH6cLXnn02NWLtD2f6UwUdubBV4uxz98ieEVQc379CRr7A0fysrqmCmXyhCVvzHXS0it+F3s X-Received: by 10.50.32.70 with SMTP id g6mr6516088igi.35.1425431032579; Tue, 03 Mar 2015 17:03:52 -0800 (PST) X-Received: by 10.50.32.70 with SMTP id g6mr6516061igi.35.1425431032389; Tue, 03 Mar 2015 17:03:52 -0800 (PST) Received: from nat-10-22-223-229.uofm.wireless.umn.edu ([2607:ea00:106:2001:4958:b1a7:5816:71c5]) by mx.google.com with ESMTPSA id g20sm9788262igt.14.2015.03.03.17.03.46 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2015 17:03:50 -0800 (PST) Message-ID: <54F659EE.8000307@umn.edu> Date: Tue, 03 Mar 2015 19:03:42 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stuart Cheshire , Markus Stenberg References: <20141217201155.19208.95569.idtracker@ietfa.amsl.com> <90A26CE2-87CC-4C8C-BEF9-FDF021C4FE97@iki.fi> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: David Farmer , dnssd@ietf.org, ietf@ietf.org Subject: Re: [dnssd] Last Call: (Requirements for Scalable DNS-SD/mDNS Extensions) to Informational RFC X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer 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, 04 Mar 2015 01:03:56 -0000 On 3/3/15 18:09 , Stuart Cheshire wrote: > On 5 Jan, 2015, at 03:44, Markus Stenberg wrote: > >> - REQ5: I am not sure what ‘integrate’ means here. Unidirectional access (SSD -> DNS-SD/mDNS? SSD <- DNS-SD/mDNS?)? Bidirectional? > > Is this better? > > REQ5: SSD should leverage and build upon with current link scope > DNS-SD/mDNS protocols and deployments. > > Stuart Cheshire The original wording at least implied some level of interoperability, I'm not sure "leverage and build upon" does that. It sound more like code reuse is important rather than interoperability. REQ5: SSD should inter-operate with current link scope DNS-SD/mDNS protocols and deployments to the extent practicable. I think my answer to the question is bidirectional would be the best case. But, remember these are competing requirements to be balanced. So, in the worst case ships-in-the-night meets REQ5 and REQ6. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Tue Mar 3 17:08:36 2015 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 5CF821A89B0 for ; Tue, 3 Mar 2015 17:08:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.311 X-Spam-Level: X-Spam-Status: No, score=-104.311 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_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-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 tDQICc0bCyQx for ; Tue, 3 Mar 2015 17:08:32 -0800 (PST) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 458C71A89AB for ; Tue, 3 Mar 2015 17:08:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1425431311; x=2289344911; 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=M6yMWP1GnsHvwQvq2hEXqUAXxuu0bpU8MbVERwwzmcM=; b=PjvUgUjG4QhNkpAMIdfYKB2Pvz2mUBZn0DnpmddPWBTyLu31oOPXt3tNYqTol7qg kO8QBNh+W9+hV2FT3C5rJFdRLipwzcAQKY+RV2nCQG4dPP3a8NKOfUXbUk7iawgm oY5ZQBMKlOYRaVHxIQzxaQrSD5lfzbX1hhPq7y2/d+DF8VjsxNgz8vOXa3nshhIP a8jgsAn1hWBGHL+medFD3gH7UAXg7968zTdwwdXGfto9wt+67+Jiw0E0QKZfZUP/ hZCJxjoiOw4O5J0eO/Z40GIoxTiA4vMLF7JlaiaJW+XF+SqQ9EXc4MTkIz3rOT1c k7uT9r2hDGz01w1LoREpVw==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 68.5A.12706.F0B56F45; Tue, 3 Mar 2015 17:08:31 -0800 (PST) X-AuditID: 11973e12-f79d66d0000031a2-74-54f65b0f7414 Received: from kencur (kencur.apple.com [17.151.62.38]) (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 CC.60.17961.61B56F45; Tue, 3 Mar 2015 17:08:38 -0800 (PST) Received: from [17.153.23.83] by kencur.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NKN004TCXU6M450@kencur.apple.com>; Tue, 03 Mar 2015 17:08:31 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Stuart Cheshire In-reply-to: <54F659EE.8000307@umn.edu> Date: Tue, 03 Mar 2015 17:08:31 -0800 Content-transfer-encoding: quoted-printable Message-id: <464FA0B5-367E-4009-A548-6EDBE19E0B7B@apple.com> References: <20141217201155.19208.95569.idtracker@ietfa.amsl.com> <90A26CE2-87CC-4C8C-BEF9-FDF021C4FE97@iki.fi> <54F659EE.8000307@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUi2FAYrMsf/S3EYPUuY4v3S2cxWjzbOJ/F gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZ03buYSu4wlFx5O9l9gbGt2xdjJwcEgImEksuH2CF sMUkLtxbDxTn4hAS2MsocWPZXiaYoouNrewQiSYmicXfz0JVPWCUaDxzCaidg4NZQF1iypRc kAZeAQOJLzuPsoPYwgITGCW+LQkAsdkEtCRefL7CBlLOCVTetiMQJMwioCqxefVLsCOYBbwl pm89wQZha0s8eXeBFWKkjcSe/fcYIdbuZ5T4cOw52HwRAUWJ98dbGUFmSgjIS/RsSoe4+Ser xNpd+hMYhWchHDcLyXGzkGxYwMi8ilEoNzEzRzczz0QvsaAgJ1UvOT93EyMomKfbCe1gPLXK 6hCjAAejEg/vBPavIUKsiWXFlbmHGKU5WJTEedfVfgkREkhPLEnNTk0tSC2KLyrNSS0+xMjE wSnVwGiiuWzarpUnA6apmqmzdSUL/c+3apRK0dZ41BOc36ByU5f56a8HHb3qsbqNG89XPMt3 +CAlmFu18cSJ2ReYt4XwF/Fe+3Rb7vKyQvb7WiH7i9RqDDYe25/k1zDnQGjrwoc/tjFffMOt J8D8Vvjm/JKr7WaxP3MVDhyc4q455WnLrkt2TlOXr1JiKc5INNRiLipOBADT/rBjRwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUiON1OTVcs+luIwaUJghbvl85itHi2cT6L A5PHkiU/mQIYo7hsUlJzMstSi/TtErgypu3cw1ZwhaPiyN/L7A2Mb9m6GDk5JARMJC42trJD 2GISF+6tB4pzcQgJNDFJLP5+Fsp5wCjReOYSaxcjBwezgLrElCm5IA28AgYSX3YeBWsWFpjA KPFtSQCIzSagJfHi8xU2kHJOoPK2HYEgYRYBVYnNq1+ygtjMAt4S07eeYIOwtSWevLvACjHS RmLP/nuMEGv3M0p8OPYcbL6IgKLE++OtjCAzJQTkJXo2pU9gFJiFcNAsJAfNQjJ1ASPzKkaB otScxEpjvcSCgpxUveT83E2MoPBrKAzewfhnmdUhRgEORiUe3hecX0OEWBPLiitzDzFKcDAr ifA+NvgWIsSbklhZlVqUH19UmpNafIhRmoNFSZz39c4PIUIC6YklqdmpqQWpRTBZJg5OqQbG qM/W+w0l3nXsErmdlatjx7S07tG9v6/Y67tbl54uO+J2WKD897b3NYl/Xaxyk/893bzv98km y/glufXWZQK8PO4T327nuOhRMXe30fwH7FeCn/3cwh4qYi73pvTAt6ZZK59o9D88Z/E7ubrd 7YrPr1KFWokJDK6hcQuv3pMyufCK7eOLzsSVSizFGYmGWsxFxYkAFB06HjsCAAA= Archived-At: Cc: dnssd@ietf.org, Markus Stenberg , ietf@ietf.org Subject: Re: [dnssd] Last Call: (Requirements for Scalable DNS-SD/mDNS Extensions) to Informational RFC 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, 04 Mar 2015 01:08:33 -0000 On 3 Mar, 2015, at 17:03, David Farmer wrote: > The original wording at least implied some level of interoperability, = I'm not sure "leverage and build upon" does that. It sound more like = code reuse is important rather than interoperability. >=20 > REQ5: SSD should inter-operate with current link scope > DNS-SD/mDNS protocols and deployments to the extent > practicable. >=20 > I think my answer to the question is bidirectional would be the best = case. But, remember these are competing requirements to be balanced. = So, in the worst case ships-in-the-night meets REQ5 and REQ6. No, it=E2=80=99s more device reuse than code reuse. You shouldn=E2=80=99t = have to buy a new printer to use it with SSD. Or new network cameras, = home thermostats, etc. No it=E2=80=99s not a bidirectional requirement. It=E2=80=99s = unidirectional: A modern client needs to be able to discover a ten-year-old printer even = when it=E2=80=99s remote. The ten-year-old printer doesn=E2=80=99t need to discover anything new. Stuart Cheshire From nobody Tue Mar 3 17:28:29 2015 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 438391A8A28 for ; Tue, 3 Mar 2015 17:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 7TlrmWsPy-tL for ; Tue, 3 Mar 2015 17:28:25 -0800 (PST) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.119.120]) by ietfa.amsl.com (Postfix) with ESMTP id DB7671A8A14 for ; Tue, 3 Mar 2015 17:28:24 -0800 (PST) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 3 Mar 2015 19:28:23 -0600 (CST) X-Umn-Remote-Mta: [N] mail-ie0-f178.google.com [209.85.223.178] #+LO+TS+TR X-Umn-Classification: local Received: by iecar1 with SMTP id ar1so63654695iec.0 for ; Tue, 03 Mar 2015 17:28:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umn.edu; s=google; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=ijf595fwwfG+wlxqDb080XNfv/3io8kSxozkiIaFXII=; b=Tue5RMULPudbAGp5Xfu2oi4TDOFZMGjY3uJvOmdivypIT9Lvb2WflSEaGt/4PO3U8C N2igE3Plt16Qmd0iWpXJNfG6AdOprtxsgJF8pbmcBtcGJwhO07/rt7E5hiA4zXrgiF/v ZXcjfcz+oXWD3WcedXhJDOrLq1pbOT+6j6yvc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:reply-to:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ijf595fwwfG+wlxqDb080XNfv/3io8kSxozkiIaFXII=; b=e37Uw3sTnaBeZ/P+xQftShIGkk2Q0BWDwDKY1L8upr62EROkT4w2tPXS8fidGfzVxO 5axOm2D/0ZRMbakGwdXuNXifzMuGhVV8c3bX5TVSCCE3+XcUOdz+FGFcgW6SaXO+IvCK Tpc2kjTQZgD6IQchZDLuXmsaoozV6gNSO+DqdSV1MDidLX6ohF6+ff0jgKYcMIeNsX5f Bk9pyVOMKjBnSung9dy2PHlllQbO5jhAIlfPX2TOoHp2rUO557HZUrdhXfq+NylLF8x6 2/O1QtSWgdk4nBK6DTdxobAf1QZOeIHbZq3Fhsevy81NZKOlzg897Hrvg5uqOLoQ2m91 3ejg== X-Gm-Message-State: ALoCoQnh5YlrH51SGBiRWjOEQ0J77A3vxwmOgclfJUGYuQRh5f6pKzbod20995Fob2j4TblNMOBW4yHcyU5B94h1/b2o6N4kJy1zcD5lZ5Gbs/V94SalAAp3AwM/33B1bto61MoeTSmC X-Received: by 10.107.15.156 with SMTP id 28mr6827526iop.57.1425432503309; Tue, 03 Mar 2015 17:28:23 -0800 (PST) X-Received: by 10.107.15.156 with SMTP id 28mr6827502iop.57.1425432503137; Tue, 03 Mar 2015 17:28:23 -0800 (PST) Received: from nat-10-22-223-229.uofm.wireless.umn.edu ([2607:ea00:106:2001:4958:b1a7:5816:71c5]) by mx.google.com with ESMTPSA id x10sm2015119igl.13.2015.03.03.17.28.18 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Mar 2015 17:28:21 -0800 (PST) Message-ID: <54F65FAD.2010904@umn.edu> Date: Tue, 03 Mar 2015 19:28:13 -0600 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Stuart Cheshire References: <20141217201155.19208.95569.idtracker@ietfa.amsl.com> <90A26CE2-87CC-4C8C-BEF9-FDF021C4FE97@iki.fi> <54F659EE.8000307@umn.edu> <464FA0B5-367E-4009-A548-6EDBE19E0B7B@apple.com> In-Reply-To: <464FA0B5-367E-4009-A548-6EDBE19E0B7B@apple.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: David Farmer , dnssd@ietf.org, Markus Stenberg , ietf@ietf.org Subject: Re: [dnssd] Last Call: (Requirements for Scalable DNS-SD/mDNS Extensions) to Informational RFC X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Farmer 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, 04 Mar 2015 01:28:26 -0000 On 3/3/15 19:08 , Stuart Cheshire wrote: > On 3 Mar, 2015, at 17:03, David Farmer wrote: > >> The original wording at least implied some level of interoperability, I'm not sure "leverage and build upon" does that. It sound more like code reuse is important rather than interoperability. >> >> REQ5: SSD should inter-operate with current link scope >> DNS-SD/mDNS protocols and deployments to the extent >> practicable. >> >> I think my answer to the question is bidirectional would be the best case. But, remember these are competing requirements to be balanced. So, in the worst case ships-in-the-night meets REQ5 and REQ6. > > No, it’s more device reuse than code reuse. You shouldn’t have to buy a new printer to use it with SSD. Or new network cameras, home thermostats, etc. Agreed. > No it’s not a bidirectional requirement. It’s unidirectional: > > A modern client needs to be able to discover a ten-year-old printer even when it’s remote. > > The ten-year-old printer doesn’t need to discover anything new. > > Stuart Cheshire If possible I'd like both an old client to discover a new printer, as well as a new client to discover an old printer. That was my interpretation of bidirectional. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ From nobody Wed Mar 4 01:11:39 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E25661A89B0; Tue, 3 Mar 2015 16:54:58 -0800 (PST) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12C41A89AC for ; Tue, 3 Mar 2015 16:54:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.125 X-Spam-Level: X-Spam-Status: No, score=-101.125 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_SOFTFAIL=0.665, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] 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 aEhW42TETWi7 for ; Tue, 3 Mar 2015 16:54:58 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C88F1A89AB for ; Tue, 3 Mar 2015 16:54:55 -0800 (PST) Received: from mail-out4.apple.com ([17.151.62.26]:62295 helo=mail-in4.apple.com) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YSxaQ-00056w-0J for draft-ietf-dnssd-requirements.all@tools.ietf.org; Tue, 03 Mar 2015 16:54:54 -0800 DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1425427776; x=2289341376; 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=+ILDu6JPOIJMfJoc3+cONTcdDPgREuCL5LO9/GSoLxM=; b=o2JUVlJXP+TbATGVrJyB+HRUCwFIHYE1oMkfFNza/DHKbtNiCHv5A14uUKMlMt5q zgPgpQG+dQaKMHIksuzw+HBnwIveStnY6B21b2sNQe6H3tV55uDR36aKkJ9x6mK3 8Ql1aopWVn0YSEruqfgZNryWFeAP7Kbugsg9Gui7k07r/B3/BaaFwn6vkvSz3vOY jp0gs3O5/CdzDIUCocQSWjUB9YaDAHTdcIVJKFE2vSxmvuaMPegYgJD7kjN0F8Je iAdwDNqOmID69VrW225aUKf8ZgB4tsVzW9kYWOzfjxQJvApZfxwOHMQg2aqRA+WK 0EWG0OTz4WWM5kaL8DEfxQ==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id A3.7F.12706.04D46F45; Tue, 3 Mar 2015 16:09:36 -0800 (PST) X-AuditID: 11973e12-f79d66d0000031a2-f8-54f64d40eedb Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) (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 DF.40.17961.64D46F45; Tue, 3 Mar 2015 16:09:42 -0800 (PST) Received: from [17.153.23.83] by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NKN006YGV3Y7I20@nwk-phonehomebzp-sz01.apple.com> for draft-ietf-dnssd-requirements.all@tools.ietf.org; Tue, 03 Mar 2015 16:09:36 -0800 (PST) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Stuart Cheshire In-reply-to: <17D4E7BD-2961-4D16-B46D-4C8999BF3A7E@nominum.com> Date: Tue, 03 Mar 2015 16:09:36 -0800 Content-transfer-encoding: quoted-printable Message-id: References: <1CE5A7D5-3CB4-4991-86CE-94288599825F@nostrum.com> <633CD902-FE17-4783-9AF4-D0419D99A926@nostrum.com> <17D4E7BD-2961-4D16-B46D-4C8999BF3A7E@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FAYrOvg+y3EYO9tPoudKx8zOzB6fLn8 mS2AMYrLJiU1J7MstUjfLoEro793N0vBBbaKZ9+3MTcwfmTpYuTkkBAwkehv62OCsMUkLtxb z9bFyMUhJLCXUaKj7z87TNGE1WcYIRILmCSeHJzIAuFsZZI4efQzaxcjBwezgLrElCm5IA28 AgYSX3YeBWsWFnCSuPB9PtgGNgEtiRefr7CB2JwC9hJ3r04Bu4JFQFVixrRrYAuYBbYySvx7 epcVJMEsoC3x5N0FVoihNhIbD81ghVi8jUnixfFNjCAJEaDu7a0TWECOkBCQl+jZlA5SIyHw k1WiacZClgmMwrMQ7puF5L5ZSFYsYGRexSiUm5iZo5uZZ6KXWFCQk6qXnJ+7iREUyNPthHYw nlpldYhRgINRiYd3AvvXECHWxLLiytxDjNIcLErivOtqv4QICaQnlqRmp6YWpBbFF5XmpBYf YmTi4JRqYAz5kilocGCGicf5usmV+v/WnFq+9+qv1bVBV37L2j0pf/d0r8djud5Mj98vfW+t n2Aj2F/BeayqROZAwrEZJ2XiBXQds1lWzDl6cZq0onqX9YXkfd8WfTnY8cdXgfHQVEY2lbx+ x4lXLHeWRL1S1igN2OF+TyBZnFt0if8HrhmqPtr6k1uEvyqxFGckGmoxFxUnAgDkIl6jRQIA AA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUiON3OQdfN91uIwaQ+TYudKx8zOzB6fLn8 mS2AMYrLJiU1J7MstUjfLoEro793N0vBBbaKZ9+3MTcwfmTpYuTkkBAwkZiw+gwjhC0mceHe erYuRi4OIYEFTBJPDk5kgXC2MkmcPPqZtYuRg4NZQF1iypRckAZeAQOJLzuPsoPYwgJOEhe+ z2cCsdkEtCRefL7CBmJzCthL3L06BWwZi4CqxIxp1xhBZjILbGWU+Pf0LitIgllAW+LJuwus EENtJDYemsEKsXgbk8SL45vAzhMB6t7eOoEF5AgJAXmJnk3pExgFZiGcNAvJSbOQTF3AyLyK UaAoNSex0lgvsaAgJ1UvOT93EyMo8BoKg3cw/llmdYhRgINRiYf3BefXECHWxLLiytxDjBIc zEoivI8NvoUI8aYkVlalFuXHF5XmpBYfYpTmYFES532980OIkEB6YklqdmpqQWoRTJaJg1Oq gVF/6qa43xflL93cxeO44c6PsLw3Mg2fvhbOcbSM+Wo1fW/dxi/KX29lRXcF1da31OUtW/DN LZjx5OKNzjWNWzQKClK6VgQLH2yuULef+s6L3ywg3/ICe/qpMB47h5bLHAtPPijedbU4ye4l 5w/938pruP4EJSbyzYtxvMSo3n7nNnNoqXCckBJLcUaioRZzUXEiAAKNat44AgAA X-Helo-Check-Failed: Verification failed for HELO mail-in4.apple.com X-SA-Exim-Connect-IP: 17.151.62.26 X-SA-Exim-Rcpt-To: draft-ietf-dnssd-requirements.all@tools.ietf.org X-SA-Exim-Mail-From: cheshire@apple.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-dnssd-requirements.all@ietf.org Resent-Message-Id: <20150304005458.2C88F1A89AB@ietfa.amsl.com> Resent-Date: Tue, 3 Mar 2015 16:54:55 -0800 (PST) Resent-From: cheshire@apple.com Archived-At: Archived-At: X-Mailman-Approved-At: Wed, 04 Mar 2015 01:11:38 -0800 Cc: Ben Campbell , Kerry Lynn , draft-ietf-dnssd-requirements.all@tools.ietf.org, "gen-art@ietf.org Team \(gen-art@ietf.org\)" Subject: Re: [dnssd] Gen-ART LC Review of 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: Wed, 04 Mar 2015 00:54:59 -0000 On 23 Dec, 2014, at 19:03, Ted Lemon wrote: > Why not update the document to say so explicitly, and fix the idnits = while you're at it? I have added some text to clarify this. REQ2: For use cases C, D, and E, there should be a way to configure Scopes of Discovery that support a range of topologically- independent zones (e.g., from department to campus-wide). This capability must exist in the protocol; individual operators are not required to use this capability in all cases -- in particular, use case C should support Zero Configuration operation where that is desired. We should let the RFC Editor update the references at publication time = -- there=E2=80=99s little benefit in chasing a moving target. Stuart Cheshire From nobody Wed Mar 4 11:39:04 2015 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 072701AC429; Wed, 4 Mar 2015 11:39:03 -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 pk2VR-mCsVfS; Wed, 4 Mar 2015 11:39:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E11A01A8727; Wed, 4 Mar 2015 11:39:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304193901.6522.72051.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 11:39:01 -0800 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-requirements-05.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: Wed, 04 Mar 2015 19:39:03 -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 : Requirements for Scalable DNS-SD/mDNS Extensions Authors : Kerry Lynn Stuart Cheshire Marc Blanchet Daniel Migault Filename : draft-ietf-dnssd-requirements-05.txt Pages : 13 Date : 2015-03-04 Abstract: DNS-SD over mDNS is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and a list of requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnssd-requirements-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-requirements-05 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 Wed Mar 4 11:39:14 2015 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 94F161AC429; Wed, 4 Mar 2015 11:39:04 -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 XjbT8FaDSX13; Wed, 4 Mar 2015 11:39:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F40C81A88CB; Wed, 4 Mar 2015 11:39:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304193901.6522.93280.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 11:39:01 -0800 Archived-At: Subject: [dnssd] New Version Notification - draft-ietf-dnssd-requirements-05.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: Wed, 04 Mar 2015 19:39:04 -0000 A new version (-05) has been submitted for draft-ietf-dnssd-requirements: http://www.ietf.org/internet-drafts/draft-ietf-dnssd-requirements-05.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-requirements-05 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. IETF Secretariat. From nobody Wed Mar 4 11:39:16 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B42251AC432; Wed, 4 Mar 2015 11:39:04 -0800 (PST) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F161AC429; Wed, 4 Mar 2015 11:39:04 -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 XjbT8FaDSX13; Wed, 4 Mar 2015 11:39:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F40C81A88CB; Wed, 4 Mar 2015 11:39:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304193901.6522.93280.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 11:39:01 -0800 Archived-At: Subject: [dnssd] New Version Notification - draft-ietf-dnssd-requirements-05.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: Wed, 04 Mar 2015 19:39:04 -0000 A new version (-05) has been submitted for draft-ietf-dnssd-requirements: http://www.ietf.org/internet-drafts/draft-ietf-dnssd-requirements-05.txt Sub state has been changed to AD Followup from Revised ID Needed The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-requirements-05 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. IETF Secretariat. From nobody Wed Mar 4 11:49:15 2015 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 637AE1ACE49; Wed, 4 Mar 2015 11:49: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 TS3hdgVCmDJY; Wed, 4 Mar 2015 11:49:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A611ACE43; Wed, 4 Mar 2015 11:49:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304194907.23366.32590.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 11:49:07 -0800 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: 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: Wed, 04 Mar 2015 19:49:13 -0000 IESG state changed to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Wed Mar 4 11:49:16 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8C0751ACE43; Wed, 4 Mar 2015 11:49:13 -0800 (PST) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637AE1ACE49; Wed, 4 Mar 2015 11:49: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 TS3hdgVCmDJY; Wed, 4 Mar 2015 11:49:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11A611ACE43; Wed, 4 Mar 2015 11:49:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304194907.23366.32590.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 11:49:07 -0800 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: 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: Wed, 04 Mar 2015 19:49:13 -0000 IESG state changed to IESG Evaluation::AD Followup from Waiting for AD Go-Ahead::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Wed Mar 4 11:49:17 2015 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 69CC91ACE4B; Wed, 4 Mar 2015 11:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 uArX-2q5-Je2; Wed, 4 Mar 2015 11:49:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBBE1ACE41; Wed, 4 Mar 2015 11:49:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304194913.12287.6838.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 11:49:13 -0800 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: 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: Wed, 04 Mar 2015 19:49:14 -0000 IESG state changed to IESG Evaluation from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Wed Mar 4 11:49:19 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 99ED61ACE38; Wed, 4 Mar 2015 11:49:14 -0800 (PST) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69CC91ACE4B; Wed, 4 Mar 2015 11:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 uArX-2q5-Je2; Wed, 4 Mar 2015 11:49:13 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FBBE1ACE41; Wed, 4 Mar 2015 11:49:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304194913.12287.6838.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 11:49:13 -0800 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: 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: Wed, 04 Mar 2015 19:49:14 -0000 IESG state changed to IESG Evaluation from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Wed Mar 4 11:49:26 2015 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 1619C1ACE4E; Wed, 4 Mar 2015 11:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 JFEm5zx05zR2; Wed, 4 Mar 2015 11:49:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF9F1ACE37; Wed, 4 Mar 2015 11:49:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304194921.20823.27978.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 11:49:21 -0800 From: IETF Secretariat Archived-At: Subject: [dnssd] Telechat update notice: 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: Wed, 04 Mar 2015 19:49:23 -0000 Placed on agenda for telechat - 2015-03-12 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Wed Mar 4 11:49:27 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 313011ACE58; Wed, 4 Mar 2015 11:49:23 -0800 (PST) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1619C1ACE4E; Wed, 4 Mar 2015 11:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 JFEm5zx05zR2; Wed, 4 Mar 2015 11:49:21 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF9F1ACE37; Wed, 4 Mar 2015 11:49:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304194921.20823.27978.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 11:49:21 -0800 From: IETF Secretariat Archived-At: Subject: [dnssd] Telechat update notice: 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: Wed, 04 Mar 2015 19:49:23 -0000 Placed on agenda for telechat - 2015-03-12 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Wed Mar 4 14:06:16 2015 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 B391D1ACC88; Wed, 4 Mar 2015 14:06: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 AKgIK1GnqW9h; Wed, 4 Mar 2015 14:06:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AADB81AC447; Wed, 4 Mar 2015 14:06:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304220613.341.32868.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 14:06:13 -0800 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: 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: Wed, 04 Mar 2015 22:06:15 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Wed Mar 4 14:06:17 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id DBAA41ACCDA; Wed, 4 Mar 2015 14:06:15 -0800 (PST) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B391D1ACC88; Wed, 4 Mar 2015 14:06: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 AKgIK1GnqW9h; Wed, 4 Mar 2015 14:06:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AADB81AC447; Wed, 4 Mar 2015 14:06:13 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304220613.341.32868.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 14:06:13 -0800 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: 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: Wed, 04 Mar 2015 22:06:16 -0000 IANA review state changed to IANA OK - No Actions Needed ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Wed Mar 4 14:12:27 2015 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 322E31ACCED; Wed, 4 Mar 2015 14:12:22 -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 vrZ8x1p0CdCp; Wed, 4 Mar 2015 14:12:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9105F1A88EA; Wed, 4 Mar 2015 14:12:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150304221218.25794.33511.idtracker@ietfa.amsl.com> Date: Wed, 04 Mar 2015 14:12:18 -0800 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-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: Wed, 04 Mar 2015 22:12:22 -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 : On Interoperation of Labels Between mDNS and DNS Author : Andrew Sullivan Filename : draft-ietf-dnssd-mdns-dns-interop-00.txt Pages : 8 Date : 2015-03-04 Abstract: Despite its name, DNS-Based Service Discovery can use naming systems other than the Domain Name System when looking for services. Different name systems use different conventions for the characters allowed in any name. In order for DNS-SD to be used effectively in environments where multiple different name systems are in use, it is important to attend to differences in the underlying technology. This memo presents an outline of the requirements for selection of labels for mDNS and DNS when they are expected to interoperate in this manner. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-mdns-dns-interop/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-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 Mon Mar 9 14:46:02 2015 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 B19031A90BE; Mon, 9 Mar 2015 14:45:57 -0700 (PDT) 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 0wHccJtZN4Kn; Mon, 9 Mar 2015 14:45:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4631ACD8F; Mon, 9 Mar 2015 14:45:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150309214550.17061.85196.idtracker@ietfa.amsl.com> Date: Mon, 09 Mar 2015 14:45:50 -0700 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-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: Mon, 09 Mar 2015 21:45:57 -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 : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-00.txt Pages : 17 Date : 2015-03-09 Abstract: The Domain Name System (DNS) was designed to efficiently return matching records for queries for data that is relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled. But there exists no mechanism for a client to be asynchronously notified when these changes occur. This document defines a mechanism for a client to be notified of such changes to DNS records, called DNS Push Notifications. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnssd-push-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 Tue Mar 10 16:04:36 2015 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 0C3661A90B1; Tue, 10 Mar 2015 16:04:35 -0700 (PDT) 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 I1FrUrkypyVK; Tue, 10 Mar 2015 16:04:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A5C1A90AD; Tue, 10 Mar 2015 16:04:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> Date: Tue, 10 Mar 2015 16:04:33 -0700 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, tjc@ecs.soton.ac.uk Subject: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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: Tue, 10 Mar 2015 23:04:35 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-dnssd-requirements-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - section 6 intro: I'm not sure I buy that the set of relevant threats is only a union as stated. There are often new threats in new environments. - 6.6: I think one can also leak private information by searching in too broad a scope, e.g. if the client can be fingerprinted allowing re-identification. I think that's different from the example given, and maybe worth noting too. From nobody Tue Mar 10 16:04:44 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2C4C81A90B5; Tue, 10 Mar 2015 16:04:35 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3661A90B1; Tue, 10 Mar 2015 16:04:35 -0700 (PDT) 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 I1FrUrkypyVK; Tue, 10 Mar 2015 16:04:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A5C1A90AD; Tue, 10 Mar 2015 16:04:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> Date: Tue, 10 Mar 2015 16:04:33 -0700 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, tjc@ecs.soton.ac.uk Subject: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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: Tue, 10 Mar 2015 23:04:35 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-dnssd-requirements-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - section 6 intro: I'm not sure I buy that the set of relevant threats is only a union as stated. There are often new threats in new environments. - 6.6: I think one can also leak private information by searching in too broad a scope, e.g. if the client can be fingerprinted allowing re-identification. I think that's different from the example given, and maybe worth noting too. From nobody Tue Mar 10 23:21:11 2015 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 69B4B1A1A32; Tue, 10 Mar 2015 23:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 6MTWGRAJra0S; Tue, 10 Mar 2015 23:21:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 048771A1A27; Tue, 10 Mar 2015 23:21:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150311062107.16301.27032.idtracker@ietfa.amsl.com> Date: Tue, 10 Mar 2015 23:21:07 -0700 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, tjc@ecs.soton.ac.uk Subject: [dnssd] Spencer Dawkins' No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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: Wed, 11 Mar 2015 06:21:08 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-dnssd-requirements-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm glad to see this moving forward. I have a few minor comments, but just do the right thing. I was at at least one BOF where this was discussed, so I kind of knew what to expect, but I didn't find the title clear. Could the word "multi-link" be added someplace? This text: It is common practice for enterprises and institutions to use wireless links for client access and wired networks for server infrastructure, typically on different subnets. didn't seem quite right. Is it saying It is common practice for enterprises and institutions to use wireless links for client access to wired ^^ networks for server infrastructure, typically on different subnets. ? As written, this excludes my office network, which includes both clients on wired and wireless links, and I suppose that's an environment where this extension might be useful ... (an embarrassingly small nit) In this text: SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today. SSD must not negatively impact the global DNS namespace or infrastructure. the two requirements don't seem particularly related, and I wonder if the second would get more attention if it was a separate paragraph. From nobody Tue Mar 10 23:21:12 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 882B91A1A39; Tue, 10 Mar 2015 23:21:08 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B4B1A1A32; Tue, 10 Mar 2015 23:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 6MTWGRAJra0S; Tue, 10 Mar 2015 23:21:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 048771A1A27; Tue, 10 Mar 2015 23:21:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150311062107.16301.27032.idtracker@ietfa.amsl.com> Date: Tue, 10 Mar 2015 23:21:07 -0700 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, tjc@ecs.soton.ac.uk Subject: [dnssd] Spencer Dawkins' No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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: Wed, 11 Mar 2015 06:21:08 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-dnssd-requirements-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I'm glad to see this moving forward. I have a few minor comments, but just do the right thing. I was at at least one BOF where this was discussed, so I kind of knew what to expect, but I didn't find the title clear. Could the word "multi-link" be added someplace? This text: It is common practice for enterprises and institutions to use wireless links for client access and wired networks for server infrastructure, typically on different subnets. didn't seem quite right. Is it saying It is common practice for enterprises and institutions to use wireless links for client access to wired ^^ networks for server infrastructure, typically on different subnets. ? As written, this excludes my office network, which includes both clients on wired and wireless links, and I suppose that's an environment where this extension might be useful ... (an embarrassingly small nit) In this text: SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today. SSD must not negatively impact the global DNS namespace or infrastructure. the two requirements don't seem particularly related, and I wonder if the second would get more attention if it was a separate paragraph. From nobody Wed Mar 11 19:07:13 2015 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 A05F81A89B8; Wed, 11 Mar 2015 19:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 JKu31J19LOcu; Wed, 11 Mar 2015 19:07:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F551A89AB; Wed, 11 Mar 2015 19:07:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 19:07:08 -0700 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, tjc@ecs.soton.ac.uk Subject: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 12 Mar 2015 02:07:10 -0000 Pete Resnick has entered the following ballot position for draft-ietf-dnssd-requirements-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Procedural issue - The shepherd writeup says: (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? The draft includes the boilerplate confirming that the document "is submitted in full conformance with the provisions of BCP 78 and BCP 79". No disclosures have been made, nor are expected to be made in an Informational requirements draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. There was an IPR disclosure made on the earlier pre-WG version of this document back in 2013. Were the authors asked whether that disclosure also applies to this version of the document? Is the WG aware of this disclosure? Did the WG discuss the disclosure? Were any concerns raised? Section 5: OLD Devices on different links may have the same mDNS name (perhaps due to vendor defaults), because link-local mDNS names are only guaranteed to be unique on a per-link basis. Also, even devices that are on the same link may have similar-looking names, such as one device with the name "Bill" and another device using the similar- looking name "Bi11" (using the digit "1" in place of the letter "l"). This may lead to a local label disambiguation problem between presented results. SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today. SSD must not negatively impact the global DNS namespace or infrastructure. The part about name collisions is fine, and should be said. The part about disambiguating similar characters is a rat's nest I really think you need to avoid. We can discuss this further, but the i18n community is dealing with this issue right now and it's a mess you really don't want to get into. I think you should simply stick to something like this: NEW Devices on different links may have the same mDNS name (perhaps due to vendor defaults), because link-local mDNS names are only guaranteed to be unique on a per-link basis. SSD needs to deal with name collisions beyond local link considerations. SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today and should look to work in using internationalize strings in application protocols [soon-to-be-RFC-draft-ietf-precis-framework]. SSD must not negatively impact the global DNS namespace or infrastructure. From nobody Wed Mar 11 19:07:15 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id CA5D21A89C5; Wed, 11 Mar 2015 19:07:10 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05F81A89B8; Wed, 11 Mar 2015 19:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 JKu31J19LOcu; Wed, 11 Mar 2015 19:07:08 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F551A89AB; Wed, 11 Mar 2015 19:07:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 19:07:08 -0700 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, tjc@ecs.soton.ac.uk Subject: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 12 Mar 2015 02:07:11 -0000 Pete Resnick has entered the following ballot position for draft-ietf-dnssd-requirements-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Procedural issue - The shepherd writeup says: (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? The draft includes the boilerplate confirming that the document "is submitted in full conformance with the provisions of BCP 78 and BCP 79". No disclosures have been made, nor are expected to be made in an Informational requirements draft. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No. There was an IPR disclosure made on the earlier pre-WG version of this document back in 2013. Were the authors asked whether that disclosure also applies to this version of the document? Is the WG aware of this disclosure? Did the WG discuss the disclosure? Were any concerns raised? Section 5: OLD Devices on different links may have the same mDNS name (perhaps due to vendor defaults), because link-local mDNS names are only guaranteed to be unique on a per-link basis. Also, even devices that are on the same link may have similar-looking names, such as one device with the name "Bill" and another device using the similar- looking name "Bi11" (using the digit "1" in place of the letter "l"). This may lead to a local label disambiguation problem between presented results. SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today. SSD must not negatively impact the global DNS namespace or infrastructure. The part about name collisions is fine, and should be said. The part about disambiguating similar characters is a rat's nest I really think you need to avoid. We can discuss this further, but the i18n community is dealing with this issue right now and it's a mess you really don't want to get into. I think you should simply stick to something like this: NEW Devices on different links may have the same mDNS name (perhaps due to vendor defaults), because link-local mDNS names are only guaranteed to be unique on a per-link basis. SSD needs to deal with name collisions beyond local link considerations. SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today and should look to work in using internationalize strings in application protocols [soon-to-be-RFC-draft-ietf-precis-framework]. SSD must not negatively impact the global DNS namespace or infrastructure. From nobody Wed Mar 11 19:20:10 2015 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 AC09C1A89C6; Wed, 11 Mar 2015 19:20:08 -0700 (PDT) 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 uS1CJJU1sdvN; Wed, 11 Mar 2015 19:20:04 -0700 (PDT) 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 92F021A89D3; Wed, 11 Mar 2015 19:20:01 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 4EF45DA0488; Thu, 12 Mar 2015 02:20:01 +0000 (UTC) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 11 Mar 2015 19:20:01 -0700 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: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 22:19:56 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , tjc@ecs.soton.ac.uk Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 12 Mar 2015 02:20:08 -0000 On Mar 11, 2015, at 10:07 PM, Pete Resnick = wrote: > The draft includes the boilerplate confirming that the document "is > submitted in full conformance with the provisions of BCP 78 and BCP > 79". No disclosures have been made, nor are expected to be made in = an > Informational requirements draft. Argh, sorry, I didn't catch that. Tim, please ask the authors to say = explicitly whether they are aware of any additional IPR. The = boilerplate isn't adequate, because it is added by a tool, and is not = present in the XML source. > There was an IPR disclosure made on the earlier pre-WG version of this > document back in 2013. Were the authors asked whether that disclosure > also applies to this version of the document? Is the WG aware of this > disclosure? Did the WG discuss the disclosure? Were any concerns = raised? Hm. This has certainly come up in meetings. I think the only time it = was mentioned on the mailing list was prior to the BoF that produced = dnssd. The disclosure has been in the tracker all along. Are you = suggesting that the working group may have agreed to advance the = document without being aware of this, despite the IPR having been = present in the tracker? From nobody Wed Mar 11 19:20:15 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id D1CC01A89ED; Wed, 11 Mar 2015 19:20:08 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC09C1A89C6; Wed, 11 Mar 2015 19:20:08 -0700 (PDT) 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 uS1CJJU1sdvN; Wed, 11 Mar 2015 19:20:04 -0700 (PDT) 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 92F021A89D3; Wed, 11 Mar 2015 19:20:01 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 4EF45DA0488; Thu, 12 Mar 2015 02:20:01 +0000 (UTC) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 11 Mar 2015 19:20:01 -0700 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: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 22:19:56 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , tjc@ecs.soton.ac.uk Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 12 Mar 2015 02:20:09 -0000 On Mar 11, 2015, at 10:07 PM, Pete Resnick = wrote: > The draft includes the boilerplate confirming that the document "is > submitted in full conformance with the provisions of BCP 78 and BCP > 79". No disclosures have been made, nor are expected to be made in = an > Informational requirements draft. Argh, sorry, I didn't catch that. Tim, please ask the authors to say = explicitly whether they are aware of any additional IPR. The = boilerplate isn't adequate, because it is added by a tool, and is not = present in the XML source. > There was an IPR disclosure made on the earlier pre-WG version of this > document back in 2013. Were the authors asked whether that disclosure > also applies to this version of the document? Is the WG aware of this > disclosure? Did the WG discuss the disclosure? Were any concerns = raised? Hm. This has certainly come up in meetings. I think the only time it = was mentioned on the mailing list was prior to the BoF that produced = dnssd. The disclosure has been in the tracker all along. Are you = suggesting that the working group may have agreed to advance the = document without being aware of this, despite the IPR having been = present in the tracker? From nobody Wed Mar 11 19:26:29 2015 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 4F5281A8A10; Wed, 11 Mar 2015 19:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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, SPF_PASS=-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 jpcBEfV8ZvFZ; Wed, 11 Mar 2015 19:26:23 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FD31A8A06; Wed, 11 Mar 2015 19:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426127182; x=1457663182; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=j9HBP2uqJ836mk9WavWMkpkazoFzFC2vkHjo8mTXiZY=; b=zfqsoZ9e5BZEe2j1oXtet5leWeYMvon12pUf6KxjOftfPS1nqj9m8X4r 0rZBciu5zRFGRcbbCFQpWY94bmPmE5itbGA7Y5VJE1nXa54fbOLjn+Bne verLPUc1WQ/1LDr/O2DxEjTTovdl9alK3Te4MucP1KNdEUcRPz0vRpu9l 4=; X-IronPort-AV: E=McAfee;i="5600,1067,7737"; a="84722541" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 11 Mar 2015 19:26:22 -0700 X-IronPort-AV: E=Sophos;i="5.11,385,1422950400"; d="scan'208";a="31974843" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Mar 2015 19:26:21 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 11 Mar 2015 19:26:20 -0700 Message-ID: <5500F94C.90702@qti.qualcomm.com> Date: Wed, 11 Mar 2015 19:26:20 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ted Lemon References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> In-Reply-To: <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , tjc@ecs.soton.ac.uk Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 12 Mar 2015 02:26:25 -0000 On 3/11/15 7:19 PM, Ted Lemon wrote: > On Mar 11, 2015, at 10:07 PM, Pete Resnick wrote: > >> The draft includes the boilerplate confirming that the document "is >> submitted in full conformance with the provisions of BCP 78 and BCP >> 79". No disclosures have been made, nor are expected to be made in an >> Informational requirements draft. >> > Argh, sorry, I didn't catch that. Tim, please ask the authors to say explicitly whether they are aware of any additional IPR. The boilerplate isn't adequate, because it is added by a tool, and is not present in the XML source. > As we've said in the past, it's fine if the relationship between a shepherd and the authors is such that the shepherd can confidently say, "Yeah, these folks did the right thing." But in this case, there's this IPR declaration, and the answer to the next question about whether there were any IPR declarations was "No". So I'd like to be sure that due diligence was done here. >> There was an IPR disclosure made on the earlier pre-WG version of this >> document back in 2013. Were the authors asked whether that disclosure >> also applies to this version of the document? Is the WG aware of this >> disclosure? Did the WG discuss the disclosure? Were any concerns raised? >> > Hm. This has certainly come up in meetings. I think the only time it was mentioned on the mailing list was prior to the BoF that produced dnssd. The disclosure has been in the tracker all along. Are you suggesting that the working group may have agreed to advance the document without being aware of this, despite the IPR having been present in the tracker? > If it's come up in meetings, that's enough to convince me that the WG was aware of this. It was the existence of it in the tracker and the shepherd's comment that there was no related IPR that caused me to ask what was going on here. As far as I'm concerned, I've made you (Ted) aware of this issue and I'm happy to clear this part of the DISCUSS and let you contend with it. (Or I can track it; whichever works for you.) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Mar 11 19:26:30 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 740261A8A17; Wed, 11 Mar 2015 19:26:25 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F5281A8A10; Wed, 11 Mar 2015 19:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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, SPF_PASS=-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 jpcBEfV8ZvFZ; Wed, 11 Mar 2015 19:26:23 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1FD31A8A06; Wed, 11 Mar 2015 19:26:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426127182; x=1457663182; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=j9HBP2uqJ836mk9WavWMkpkazoFzFC2vkHjo8mTXiZY=; b=zfqsoZ9e5BZEe2j1oXtet5leWeYMvon12pUf6KxjOftfPS1nqj9m8X4r 0rZBciu5zRFGRcbbCFQpWY94bmPmE5itbGA7Y5VJE1nXa54fbOLjn+Bne verLPUc1WQ/1LDr/O2DxEjTTovdl9alK3Te4MucP1KNdEUcRPz0vRpu9l 4=; X-IronPort-AV: E=McAfee;i="5600,1067,7737"; a="84722541" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by sabertooth01.qualcomm.com with ESMTP; 11 Mar 2015 19:26:22 -0700 X-IronPort-AV: E=Sophos;i="5.11,385,1422950400"; d="scan'208";a="31974843" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Mar 2015 19:26:21 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 11 Mar 2015 19:26:20 -0700 Message-ID: <5500F94C.90702@qti.qualcomm.com> Date: Wed, 11 Mar 2015 19:26:20 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Ted Lemon References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> In-Reply-To: <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01G.na.qualcomm.com (10.85.0.33) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , tjc@ecs.soton.ac.uk Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 12 Mar 2015 02:26:25 -0000 On 3/11/15 7:19 PM, Ted Lemon wrote: > On Mar 11, 2015, at 10:07 PM, Pete Resnick wrote: > >> The draft includes the boilerplate confirming that the document "is >> submitted in full conformance with the provisions of BCP 78 and BCP >> 79". No disclosures have been made, nor are expected to be made in an >> Informational requirements draft. >> > Argh, sorry, I didn't catch that. Tim, please ask the authors to say explicitly whether they are aware of any additional IPR. The boilerplate isn't adequate, because it is added by a tool, and is not present in the XML source. > As we've said in the past, it's fine if the relationship between a shepherd and the authors is such that the shepherd can confidently say, "Yeah, these folks did the right thing." But in this case, there's this IPR declaration, and the answer to the next question about whether there were any IPR declarations was "No". So I'd like to be sure that due diligence was done here. >> There was an IPR disclosure made on the earlier pre-WG version of this >> document back in 2013. Were the authors asked whether that disclosure >> also applies to this version of the document? Is the WG aware of this >> disclosure? Did the WG discuss the disclosure? Were any concerns raised? >> > Hm. This has certainly come up in meetings. I think the only time it was mentioned on the mailing list was prior to the BoF that produced dnssd. The disclosure has been in the tracker all along. Are you suggesting that the working group may have agreed to advance the document without being aware of this, despite the IPR having been present in the tracker? > If it's come up in meetings, that's enough to convince me that the WG was aware of this. It was the existence of it in the tracker and the shepherd's comment that there was no related IPR that caused me to ask what was going on here. As far as I'm concerned, I've made you (Ted) aware of this issue and I'm happy to clear this part of the DISCUSS and let you contend with it. (Or I can track it; whichever works for you.) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Wed Mar 11 19:30:31 2015 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 7C1591A8A1B; Wed, 11 Mar 2015 19:30:30 -0700 (PDT) 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 Wv4fTyRJNAPS; Wed, 11 Mar 2015 19:30:26 -0700 (PDT) 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 3D0D71A8A11; Wed, 11 Mar 2015 19:30:26 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 1052BDA048A; Thu, 12 Mar 2015 02:30:26 +0000 (UTC) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 11 Mar 2015 19:30:25 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <5500F94C.90702@qti.qualcomm.com> Date: Wed, 11 Mar 2015 22:30:21 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7E4F8F92-000D-4869-816F-D73F62C77E28@nominum.com> References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> <5500F94C.90702@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , tjc@ecs.soton.ac.uk Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 12 Mar 2015 02:30:30 -0000 On Mar 11, 2015, at 10:26 PM, Pete Resnick = wrote: > As far as I'm concerned, I've made you (Ted) aware of this issue and = I'm happy to clear this part of the DISCUSS and let you contend with it. = (Or I can track it; whichever works for you.) Let's see what Tim says. From nobody Wed Mar 11 19:30:42 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A12161A8A23; Wed, 11 Mar 2015 19:30:30 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1591A8A1B; Wed, 11 Mar 2015 19:30:30 -0700 (PDT) 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 Wv4fTyRJNAPS; Wed, 11 Mar 2015 19:30:26 -0700 (PDT) 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 3D0D71A8A11; Wed, 11 Mar 2015 19:30:26 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id 1052BDA048A; Thu, 12 Mar 2015 02:30:26 +0000 (UTC) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Wed, 11 Mar 2015 19:30:25 -0700 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ted Lemon In-Reply-To: <5500F94C.90702@qti.qualcomm.com> Date: Wed, 11 Mar 2015 22:30:21 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <7E4F8F92-000D-4869-816F-D73F62C77E28@nominum.com> References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> <5500F94C.90702@qti.qualcomm.com> To: Pete Resnick X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , tjc@ecs.soton.ac.uk Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 12 Mar 2015 02:30:30 -0000 On Mar 11, 2015, at 10:26 PM, Pete Resnick = wrote: > As far as I'm concerned, I've made you (Ted) aware of this issue and = I'm happy to clear this part of the DISCUSS and let you contend with it. = (Or I can track it; whichever works for you.) Let's see what Tim says. From nobody Wed Mar 11 23:09:53 2015 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 461E01A8A87; Wed, 11 Mar 2015 23:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 6TLor_z5c7fs; Wed, 11 Mar 2015 23:09:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DFA1A0362; Wed, 11 Mar 2015 23:09:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150312060951.8282.11525.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 23:09:51 -0700 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, tjc@ecs.soton.ac.uk Subject: [dnssd] Martin Stiemerling's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 12 Mar 2015 06:09:52 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-dnssd-requirements-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A nit: Please expand the terms DNS-SD and mDNS at their first use, for instance, in the Abstract. From nobody Wed Mar 11 23:09:56 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 636F71A8A8C; Wed, 11 Mar 2015 23:09:52 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461E01A8A87; Wed, 11 Mar 2015 23:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=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 6TLor_z5c7fs; Wed, 11 Mar 2015 23:09:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 30DFA1A0362; Wed, 11 Mar 2015 23:09:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Martin Stiemerling" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150312060951.8282.11525.idtracker@ietfa.amsl.com> Date: Wed, 11 Mar 2015 23:09:51 -0700 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, tjc@ecs.soton.ac.uk Subject: [dnssd] Martin Stiemerling's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 12 Mar 2015 06:09:52 -0000 Martin Stiemerling has entered the following ballot position for draft-ietf-dnssd-requirements-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- A nit: Please expand the terms DNS-SD and mDNS at their first use, for instance, in the Abstract. From nobody Thu Mar 12 04:41:21 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 914C01A90DD; Thu, 12 Mar 2015 03:04:56 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683C91A90DC for ; Thu, 12 Mar 2015 03:04:56 -0700 (PDT) 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=unavailable 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 DhE4xAPQpSCa for ; Thu, 12 Mar 2015 03:04:55 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 893531A90DB for ; Thu, 12 Mar 2015 03:04:55 -0700 (PDT) Received: from p130.piuha.net ([2a00:1d50:2::130]:60790) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YVzz4-0005D3-KQ for draft-ietf-dnssd-requirements.all@tools.ietf.org; Thu, 12 Mar 2015 03:04:55 -0700 Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id ECEAB2CCCF; Thu, 12 Mar 2015 12:04:48 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdXLQivGVwjn; Thu, 12 Mar 2015 12:04:47 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 8B06E2CC6F; Thu, 12 Mar 2015 12:04:47 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: multipart/signed; boundary="Apple-Mail=_3A57C85C-50A0-4C13-8B14-33858808CF14"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Jari Arkko In-Reply-To: <1CE5A7D5-3CB4-4991-86CE-94288599825F@nostrum.com> Date: Thu, 12 Mar 2015 12:04:47 +0200 Message-Id: References: <1CE5A7D5-3CB4-4991-86CE-94288599825F@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.1878.6) X-SA-Exim-Connect-IP: 2a00:1d50:2::130 X-SA-Exim-Rcpt-To: draft-ietf-dnssd-requirements.all@tools.ietf.org X-SA-Exim-Mail-From: jari.arkko@piuha.net X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-dnssd-requirements.all@ietf.org Resent-Message-Id: <20150312100455.893531A90DB@ietfa.amsl.com> Resent-Date: Thu, 12 Mar 2015 03:04:55 -0700 (PDT) Resent-From: jari.arkko@piuha.net Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 04:41:20 -0700 Cc: draft-ietf-dnssd-requirements.all@tools.ietf.org, "gen-art@ietf.org Team \(gen-art@ietf.org\)" Subject: Re: [dnssd] [Gen-art] Gen-ART LC Review of 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, 12 Mar 2015 10:04:56 -0000 --Apple-Mail=_3A57C85C-50A0-4C13-8B14-33858808CF14 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Big thanks for your review, Ben. Jari On 23 Dec 2014, at 01:40, Ben Campbell wrote: > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at >=20 > . >=20 > Please resolve these comments along with any other Last Call comments > you may receive. >=20 > Document: draft-ietf-dnssd-requirements-04 > Reviewer: Ben Campbell > Review Date: 2014-12-22 > IETF LC End Date: 2015-01-07 > IESG Telechat date: (if known) >=20 > Summary: This draft is basically ready for publication as an = informational RFC. Its well written and easy to understand. >=20 > Major issues: >=20 > None >=20 > Minor issues: >=20 > The acronym is a bit unfortunate. I suspect that much of the target = audience already knows SSD as "solid-state drive" Of course, I don't = really expect you to change it at this point in the process. :-) >=20 > Nits/editorial comments: >=20 > -- IDNits reports a couple of out-of-date references. >=20 > -- REQ2: >=20 > Am I correct in assuming that this would not apply to case C when used = in zero configuration mode? >=20 >=20 > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art --Apple-Mail=_3A57C85C-50A0-4C13-8B14-33858808CF14 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 - https://gpgtools.org iQIcBAEBCgAGBQJVAWS/AAoJEM80gCTQU46qNk0QAJcVKUoPjTqEartdznn4RDHm UTfFCp/C0zeM0HG+Xhpmm5CG2W5bWhnJT1zt/ijtF5/zaHENOJ62s99oPUME8bm6 vWColO8SG4jy4caB2ryrmJMbcBwIMlmhpe5MKwC0xeBBshO/e1pjWgfE8oseS2j+ ncZpZ+51K8z3EwoDMnx47I9bH1kQ1327usEgAZOIAJRA7+LWoqdCogTKnQMg5Mkl wfCzGZHTNQjKrjv89P5MO2RDziOSh/PPgmWL2RLUCL4KlRXAtXJDp70/gIGBxHP7 GmELtMBP0PXdm67kz5fTbAYXMQQjVEwPcJ+1AbBOvj6xkrlOxgyRF8vjJT733btP XWs9n8fbwZp+NNnZRwGAtFw0q62JAHcmcFhH5seMFZTe184EcJ3w6F2TGsQCh7Dk Tm3LpGm3h4YZa6lpCQpbrAnhkPm6IWTFEA/tmbHX+D6AmXqA0uhZWqEIRKaw4zvN e1aEqhNe08T+KqSJadcYxphm9rVfJpXy8qQG8LQzfZfm5e3vGSGeXH7gqA1R11Fw yJPIQ1dNACFAIAWvSat1CSrbpQfcue3/nrA7KzIjZoc7MNGCOdYtnLsx5dtIQEjs XN4Jcc7uNGmWxH0yph18L2n81Q2+sa9p8e8FWIClh1X85FCNvxRc7Xl5z+73HN6a w8vG3MdvetXLoq39m64C =xJlI -----END PGP SIGNATURE----- --Apple-Mail=_3A57C85C-50A0-4C13-8B14-33858808CF14-- From nobody Thu Mar 12 06:00:36 2015 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 D9E4C1A00F4; Thu, 12 Mar 2015 06:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, 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 8jE2EcZ71PeH; Thu, 12 Mar 2015 06:00:24 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB7D1A00CC; Thu, 12 Mar 2015 06:00:23 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2CD0GaP003251; Thu, 12 Mar 2015 13:00:16 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t2CD0GaP003251 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1426165217; bh=7g/pbg+ed4XFf0yqbfEdPvvk26g=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=XhqZ8L/DpJERfzniTm5FINyaLW9n16qQC1XsPbrrowLiU2v7QkGIIYDYckrfsfmwl +Bm3PoiDaLGX3BNl8pLHEvSRA8cFBGOfg93gKDyVMhHPknc3eXkx81PSIwGtHv8E+e E6bJo+wK3K2DYkiJ+VGWZLSuDY1c3OVBV7iCTY4Q= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id r2BD0G1194707680iw ret-id none; Thu, 12 Mar 2015 13:00:16 +0000 Received: from [IPv6:2001:630:d0:f111:1c53:dbf6:34e2:c371] ([IPv6:2001:630:d0:f111:1c53:dbf6:34e2:c371]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2CD0EX1013195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 13:00:14 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_D8939B77-AFE9-4874-B5A1-10CED7C42983" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Tim Chown In-Reply-To: <7E4F8F92-000D-4869-816F-D73F62C77E28@nominum.com> Date: Thu, 12 Mar 2015 13:00:15 +0000 Message-ID: References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> <5500F94C.90702@qti.qualcomm.com> <7E4F8F92-000D-4869-816F-D73F62C77E28@nominum.com> <1AC6F6B1-4BB2-46C1-8E42-3AC55E338479@ecs.soton.ac.uk> To: Ted Lemon X-Mailer: Apple Mail (2.2070.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=r2BD0G119470768000; tid=r2BD0G1194707680iw; client=relay,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t2CD0GaP003251 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, Pete Resnick , dnssd-chairs@ietf.org, dnssd@ietf.org, The IESG Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 12 Mar 2015 13:00:34 -0000 --Apple-Mail=_D8939B77-AFE9-4874-B5A1-10CED7C42983 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On 12 Mar 2015, at 02:30, Ted Lemon wrote: >=20 > On Mar 11, 2015, at 10:26 PM, Pete Resnick = wrote: >> As far as I'm concerned, I've made you (Ted) aware of this issue and = I'm happy to clear this part of the DISCUSS and let you contend with it. = (Or I can track it; whichever works for you.) >=20 > Let's see what Tim says. Apologies, I overlooked referring to this in the shepherding document = for the requirements draft, as I had thought the disclosure was intended = to be on the hybrid solution draft, i.e. on the document proposing a = solution for scalable DNS-based SD, as opposed to on the document = stating the problem. Pete is absolutely right that we should review and check this. Looking at the disclosures, I see that = https://datatracker.ietf.org/ipr/2114/ = (on the pre-WG adoption = requirements draft) points to an updated disclosure = https://datatracker.ietf.org/ipr/2119/ = on the hybrid draft (again, pre = WG-adoption). We should probably report this from the chair=E2=80=99s introduction = during dnssd in Dallas, and field any questions if they arise. As Ted = says, it has been discussed before. I can add a note to the shepherd = document. Tim --Apple-Mail=_D8939B77-AFE9-4874-B5A1-10CED7C42983 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

On 12 Mar 2015, at 02:30, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Mar 11, 2015, at = 10:26 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
As far as I'm concerned, = I've made you (Ted) aware of this issue and I'm happy to clear this part = of the DISCUSS and let you contend with it. (Or I can track it; = whichever works for you.)

Let's = see what Tim says.

Apologies, I overlooked referring to this in = the shepherding document for the requirements draft, as I had thought = the disclosure was intended to be on the hybrid solution draft, i.e. on = the document proposing a solution for scalable DNS-based SD, as opposed = to on the document stating the problem.

Pete is absolutely right that we should = review and check this.

Looking at the disclosures, I see that https://datatracker.ietf.org/ipr/2114/ (on the = pre-WG adoption requirements draft) points to an updated = disclosure https://datatracker.ietf.org/ipr/2119/ on the hybrid = draft (again, pre WG-adoption).

We should probably report this from the = chair=E2=80=99s introduction during dnssd in Dallas, and field any = questions if they arise. As Ted says, it has been discussed before. I = can add a note to the shepherd document.

Tim


= --Apple-Mail=_D8939B77-AFE9-4874-B5A1-10CED7C42983-- From nobody Thu Mar 12 06:00:41 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0E9291A00CC; Thu, 12 Mar 2015 06:00:34 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9E4C1A00F4; Thu, 12 Mar 2015 06:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, 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 8jE2EcZ71PeH; Thu, 12 Mar 2015 06:00:24 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB7D1A00CC; Thu, 12 Mar 2015 06:00:23 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2CD0GaP003251; Thu, 12 Mar 2015 13:00:16 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t2CD0GaP003251 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1426165217; bh=7g/pbg+ed4XFf0yqbfEdPvvk26g=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=XhqZ8L/DpJERfzniTm5FINyaLW9n16qQC1XsPbrrowLiU2v7QkGIIYDYckrfsfmwl +Bm3PoiDaLGX3BNl8pLHEvSRA8cFBGOfg93gKDyVMhHPknc3eXkx81PSIwGtHv8E+e E6bJo+wK3K2DYkiJ+VGWZLSuDY1c3OVBV7iCTY4Q= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id r2BD0G1194707680iw ret-id none; Thu, 12 Mar 2015 13:00:16 +0000 Received: from [IPv6:2001:630:d0:f111:1c53:dbf6:34e2:c371] ([IPv6:2001:630:d0:f111:1c53:dbf6:34e2:c371]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2CD0EX1013195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 13:00:14 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_D8939B77-AFE9-4874-B5A1-10CED7C42983" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Tim Chown In-Reply-To: <7E4F8F92-000D-4869-816F-D73F62C77E28@nominum.com> Date: Thu, 12 Mar 2015 13:00:15 +0000 Message-ID: References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> <5500F94C.90702@qti.qualcomm.com> <7E4F8F92-000D-4869-816F-D73F62C77E28@nominum.com> <1AC6F6B1-4BB2-46C1-8E42-3AC55E338479@ecs.soton.ac.uk> To: Ted Lemon X-Mailer: Apple Mail (2.2070.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=r2BD0G119470768000; tid=r2BD0G1194707680iw; client=relay,ipv6; mail=; rcpt=; nrcpt=6:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t2CD0GaP003251 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, Pete Resnick , dnssd-chairs@ietf.org, dnssd@ietf.org, The IESG Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 12 Mar 2015 13:00:34 -0000 --Apple-Mail=_D8939B77-AFE9-4874-B5A1-10CED7C42983 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On 12 Mar 2015, at 02:30, Ted Lemon wrote: >=20 > On Mar 11, 2015, at 10:26 PM, Pete Resnick = wrote: >> As far as I'm concerned, I've made you (Ted) aware of this issue and = I'm happy to clear this part of the DISCUSS and let you contend with it. = (Or I can track it; whichever works for you.) >=20 > Let's see what Tim says. Apologies, I overlooked referring to this in the shepherding document = for the requirements draft, as I had thought the disclosure was intended = to be on the hybrid solution draft, i.e. on the document proposing a = solution for scalable DNS-based SD, as opposed to on the document = stating the problem. Pete is absolutely right that we should review and check this. Looking at the disclosures, I see that = https://datatracker.ietf.org/ipr/2114/ = (on the pre-WG adoption = requirements draft) points to an updated disclosure = https://datatracker.ietf.org/ipr/2119/ = on the hybrid draft (again, pre = WG-adoption). We should probably report this from the chair=E2=80=99s introduction = during dnssd in Dallas, and field any questions if they arise. As Ted = says, it has been discussed before. I can add a note to the shepherd = document. Tim --Apple-Mail=_D8939B77-AFE9-4874-B5A1-10CED7C42983 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

On 12 Mar 2015, at 02:30, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Mar 11, 2015, at = 10:26 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
As far as I'm concerned, = I've made you (Ted) aware of this issue and I'm happy to clear this part = of the DISCUSS and let you contend with it. (Or I can track it; = whichever works for you.)

Let's = see what Tim says.

Apologies, I overlooked referring to this in = the shepherding document for the requirements draft, as I had thought = the disclosure was intended to be on the hybrid solution draft, i.e. on = the document proposing a solution for scalable DNS-based SD, as opposed = to on the document stating the problem.

Pete is absolutely right that we should = review and check this.

Looking at the disclosures, I see that https://datatracker.ietf.org/ipr/2114/ (on the = pre-WG adoption requirements draft) points to an updated = disclosure https://datatracker.ietf.org/ipr/2119/ on the hybrid = draft (again, pre WG-adoption).

We should probably report this from the = chair=E2=80=99s introduction during dnssd in Dallas, and field any = questions if they arise. As Ted says, it has been discussed before. I = can add a note to the shepherd document.

Tim


= --Apple-Mail=_D8939B77-AFE9-4874-B5A1-10CED7C42983-- From nobody Thu Mar 12 06:05:11 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5D15E1A0119; Thu, 12 Mar 2015 05:47:05 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 380BB1A00C0 for ; Thu, 12 Mar 2015 05:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.22 X-Spam-Level: X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] 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 afews913TdCu for ; Thu, 12 Mar 2015 05:47:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408221A0126 for ; Thu, 12 Mar 2015 05:46:30 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk ([2001:630:d0:f102::25e]:53679) by zinfandel.tools.ietf.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YW2VP-0007SR-UH for draft-ietf-dnssd-requirements.all@tools.ietf.org; Thu, 12 Mar 2015 05:46:30 -0700 Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2CCk916030848; Thu, 12 Mar 2015 12:46:09 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t2CCk916030848 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1426164370; bh=sf8hnYRQb7CeHbv82rVf2Z8CyE4=; h=Subject:Mime-Version:From:In-Reply-To:Date:Cc:References:To; b=iuSIjtOSpxUAfPu+ZvE++IV/LbVLfK4Gng/RHS/WyTozyywPxAMMqyX/vNjzhNZv8 WzPjYL1WoeQi0MsyNPml21xxDpcQt6LDKfGWOrMI4OMb4eicPJIHUCnCQ1BgHQN1EN nRYGqE9gaZhLvN5PVyGIGfXzQAipgENGpjkvH64M= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id r2BCk91194707562Gz ret-id none; Thu, 12 Mar 2015 12:46:10 +0000 Received: from tjc-macbook01.ecs.soton.ac.uk (tjc-macbook01.ecs.soton.ac.uk [152.78.65.100]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2CCk6rV009857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 12:46:06 GMT Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DCC8C4FD-0188-4480-A22D-6A724F4B85A3"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Tim Chown In-Reply-To: Date: Thu, 12 Mar 2015 12:46:06 +0000 Message-ID: References: <1CE5A7D5-3CB4-4991-86CE-94288599825F@nostrum.com> To: Arkko Jari X-Mailer: Apple Mail (2.2070.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=r2BCk9119470756200; tid=r2BCk91194707562Gz; client=relay,ipv6; mail=; rcpt=; nrcpt=4:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t2CCk916030848 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk X-SA-Exim-Connect-IP: 2001:630:d0:f102::25e X-SA-Exim-Rcpt-To: draft-ietf-dnssd-requirements.all@tools.ietf.org X-SA-Exim-Mail-From: tjc@ecs.soton.ac.uk X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-dnssd-requirements.all@ietf.org Resent-Message-Id: <20150312124630.408221A0126@ietfa.amsl.com> Resent-Date: Thu, 12 Mar 2015 05:46:30 -0700 (PDT) Resent-From: tjc@ecs.soton.ac.uk Archived-At: Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 06:05:06 -0700 Cc: Ben Campbell , draft-ietf-dnssd-requirements.all@tools.ietf.org, "gen-art@ietf.org Team \(gen-art@ietf.org\)" Subject: Re: [dnssd] [Gen-art] Gen-ART LC Review of 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, 12 Mar 2015 12:47:05 -0000 --Apple-Mail=_DCC8C4FD-0188-4480-A22D-6A724F4B85A3 Content-Type: multipart/alternative; boundary="Apple-Mail=_6FA0D2BD-A11F-45BB-ABC1-144B5B94B04E" --Apple-Mail=_6FA0D2BD-A11F-45BB-ABC1-144B5B94B04E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yep, thanks, and Stuart for proposed text. Tim > On 12 Mar 2015, at 10:04, Jari Arkko wrote: >=20 > Big thanks for your review, Ben. >=20 > Jari >=20 > On 23 Dec 2014, at 01:40, Ben Campbell wrote: >=20 >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >>=20 >> . >>=20 >> Please resolve these comments along with any other Last Call comments >> you may receive. >>=20 >> Document: draft-ietf-dnssd-requirements-04 >> Reviewer: Ben Campbell >> Review Date: 2014-12-22 >> IETF LC End Date: 2015-01-07 >> IESG Telechat date: (if known) >>=20 >> Summary: This draft is basically ready for publication as an = informational RFC. Its well written and easy to understand. >>=20 >> Major issues: >>=20 >> None >>=20 >> Minor issues: >>=20 >> The acronym is a bit unfortunate. I suspect that much of the target = audience already knows SSD as "solid-state drive" Of course, I don't = really expect you to change it at this point in the process. :-) >>=20 >> Nits/editorial comments: >>=20 >> -- IDNits reports a couple of out-of-date references. >>=20 >> -- REQ2: >>=20 >> Am I correct in assuming that this would not apply to case C when = used in zero configuration mode? >>=20 >>=20 >> _______________________________________________ >> Gen-art mailing list >> Gen-art@ietf.org >> https://www.ietf.org/mailman/listinfo/gen-art >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_6FA0D2BD-A11F-45BB-ABC1-144B5B94B04E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yep, thanks, and Stuart for proposed text.

Tim

On 12 Mar 2015, at 10:04, Jari Arkko <jari.arkko@piuha.net> wrote:

Big thanks for your = review, Ben.

Jari

On 23 Dec 2014, at 01:40, Ben Campbell <ben@nostrum.com> = wrote:

I= am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>= .

Please resolve these comments along with = any other Last Call comments
you may receive.

Document: draft-ietf-dnssd-requirements-04
Reviewer: Ben Campbell
Review Date: = 2014-12-22
IETF LC End Date: 2015-01-07
IESG = Telechat date: (if known)

Summary: This = draft is basically ready for publication as an informational RFC. Its = well written and easy to understand.

Major = issues:

None

Minor issues:

The acronym is a = bit unfortunate. I suspect that much of the target audience already = knows SSD as "solid-state drive" Of course, I don't really expect you to = change it at this point in the process. :-)

Nits/editorial comments:

-- = IDNits reports a couple of out-of-date references.

-- REQ2:

Am I correct in = assuming that this would not apply to case C when used in zero = configuration mode?


_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

= --Apple-Mail=_6FA0D2BD-A11F-45BB-ABC1-144B5B94B04E-- --Apple-Mail=_DCC8C4FD-0188-4480-A22D-6A724F4B85A3 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 - https://gpgtools.org iQEcBAEBCgAGBQJVAYqPAAoJEFoq8u2Gfpfeub0H/iuLYnSfJJLQLoCl8FRHSbZd 36A3nZLDmObAaG1eRREAP0qbMIuSdyQW8zlYB6ck2Ng7+094BIsUeJzpoItC6n3a TVZssW54QZfCoJxrJyby5iVLE1cedWd6uCHTODdNE2RqOQ98ByBdNm1ZBrux1TDp 1J8tvMStVbHYc/+5x6CprOIayBYAX2tbaZUx8ZSA4gqyy4SwMRzlUf22wkzv2Wuf 08jQNCrtvqZghhH9uiYCvr6/hRDZ+N4QWsedSBh907YXudGQeYpOOKiY6heIfFhi d3w4lFvLgVsp3AmyZiauU1FQvH5TemQ8zS2exa+o7JcQfLde15opt+vdvkn07Nc= =c/DG -----END PGP SIGNATURE----- --Apple-Mail=_DCC8C4FD-0188-4480-A22D-6A724F4B85A3-- From nobody Thu Mar 12 06:05:12 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7F5421A00C5; Thu, 12 Mar 2015 06:04:31 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AAD1A00C5; Thu, 12 Mar 2015 06:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, 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 0qKkzgSG0QL9; Thu, 12 Mar 2015 06:04:24 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26A4D1A00DF; Thu, 12 Mar 2015 06:04:24 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2CD4JBM004126; Thu, 12 Mar 2015 13:04:19 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t2CD4JBM004126 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1426165460; bh=1JzC5rdvjuyNUPlI/n957kZMgKM=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=ZDms3ClZnnSNw3k+T6lNKRv5OP0KDduwLXe948QOUhpNftRV30MFI/5SfvFvB/Hsb w7I69CO51WTqFE2xZ97zTKRCSx68qROnk82w8kp7FFfjCk9wyL5l7KJtvI0FVUz+Cd rEtIvlx3wKtaDffrsAe66nLm5EeQlMRfgBr9yoWQ= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id r2BD4J1194707713BL ret-id none; Thu, 12 Mar 2015 13:04:19 +0000 Received: from [IPv6:2001:630:d0:f111:1c53:dbf6:34e2:c371] ([IPv6:2001:630:d0:f111:1c53:dbf6:34e2:c371]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2CD4Gl4013894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 13:04:17 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_76654316-F46E-46B4-8E5F-354662A28A46" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Tim Chown In-Reply-To: <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> Date: Thu, 12 Mar 2015 13:04:17 +0000 Message-ID: References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> To: draft-ietf-dnssd-requirements.all@ietf.org X-Mailer: Apple Mail (2.2070.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=r2BD4J119470771300; tid=r2BD4J1194707713BL; client=relay,ipv6; mail=; rcpt=; nrcpt=3:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t2CD4JBM004126 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 06:05:06 -0700 Cc: dnssd-chairs@ietf.org, Ted Lemon Subject: [dnssd] Further IPR disclosures on draft-ietf-dnssd-requirements-05 ? 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, 12 Mar 2015 13:04:31 -0000 --Apple-Mail=_76654316-F46E-46B4-8E5F-354662A28A46 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Kerry, Stuart, Marc, Daniel, Please can you confirm whether there is any additional IPR on the = requirements draft as per Ted=E2=80=99s request below? As per my other email just now, I understood that the IPR statement on = the requirements draft (i.e. https://datatracker.ietf.org/ipr/2114/ = ) had intended to be on the = hybrid solution draft (i.e. https://datatracker.ietf.org/ipr/2119/ = ). Apologies for this extra late (hopefully small) hurdle. Thanks, Tim=20 > On 12 Mar 2015, at 02:19, Ted Lemon wrote: >=20 > On Mar 11, 2015, at 10:07 PM, Pete Resnick = wrote: >> The draft includes the boilerplate confirming that the document "is >> submitted in full conformance with the provisions of BCP 78 and BCP >> 79". No disclosures have been made, nor are expected to be made in = an >> Informational requirements draft. >=20 > Argh, sorry, I didn't catch that. Tim, please ask the authors to say = explicitly whether they are aware of any additional IPR. The = boilerplate isn't adequate, because it is added by a tool, and is not = present in the XML source. >=20 >> There was an IPR disclosure made on the earlier pre-WG version of = this >> document back in 2013. Were the authors asked whether that disclosure >> also applies to this version of the document? Is the WG aware of this >> disclosure? Did the WG discuss the disclosure? Were any concerns = raised? >=20 > Hm. This has certainly come up in meetings. I think the only time = it was mentioned on the mailing list was prior to the BoF that produced = dnssd. The disclosure has been in the tracker all along. Are you = suggesting that the working group may have agreed to advance the = document without being aware of this, despite the IPR having been = present in the tracker? >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_76654316-F46E-46B4-8E5F-354662A28A46 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Kerry, Stuart, Marc, Daniel,

Please can you confirm whether there is any = additional IPR on the requirements draft as per Ted=E2=80=99s request = below?

As per my other email just = now, I understood that the IPR statement on the requirements draft (i.e. =  https://datatracker.ietf.org/ipr/2114/) had intended = to be on the hybrid solution draft (i.e. https://datatracker.ietf.org/ipr/2119/ ).
Apologies for this extra late (hopefully small) = hurdle.

Thanks,
Tim 

On 12 = Mar 2015, at 02:19, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Mar 11, 2015, at = 10:07 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
 The draft = includes the boilerplate confirming that the document "is
=  submitted in full conformance with the provisions of BCP 78 and = BCP
 79". No disclosures have been made, nor are = expected to be made in an
 Informational = requirements draft.

Argh, = sorry, I didn't catch that.   Tim, please ask the authors to = say explicitly whether they are aware of any additional IPR. =   The boilerplate isn't adequate, because it is added by a = tool, and is not present in the XML source.

There was an IPR = disclosure made on the earlier pre-WG version of this
document back in 2013. Were the authors asked whether that = disclosure
also applies to this version of the document? = Is the WG aware of this
disclosure? Did the WG discuss the = disclosure? Were any concerns raised?

Hm.   This has certainly come up in meetings. =   I think the only time it was mentioned on the mailing list = was prior to the BoF that produced dnssd.   The disclosure has = been in the tracker all along.   Are you suggesting that the = working group may have agreed to advance the document without being = aware of this, despite the IPR having been present in the tracker?

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

= --Apple-Mail=_76654316-F46E-46B4-8E5F-354662A28A46-- From nobody Thu Mar 12 06:59:05 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E45E31A0174; Thu, 12 Mar 2015 06:20:51 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FA21A00B0; Thu, 12 Mar 2015 06:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 D864SrYbKeHJ; Thu, 12 Mar 2015 06:16:59 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 554471A00F3; Thu, 12 Mar 2015 06:16:59 -0700 (PDT) X-AuditID: c6180641-f790b6d000004359-e3-5501308347d4 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9A.07.17241.38031055; Thu, 12 Mar 2015 07:21:55 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Thu, 12 Mar 2015 09:16:57 -0400 From: Daniel Migault To: Tim Chown , "draft-ietf-dnssd-requirements.all@ietf.org" Thread-Topic: Further IPR disclosures on draft-ietf-dnssd-requirements-05 ? Thread-Index: AQHQXMUYANusZjHzlUicO0bQ0Vcq4J0Y07OA Date: Thu, 12 Mar 2015 13:16:56 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C15D8C0D@eusaamb107.ericsson.se> References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_2DD56D786E600F45AC6BDE7DA4E8A8C15D8C0Deusaamb107ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjkeLIzCtJLcpLzFFi42KZXLrHW7fZgDHUYM45RYsr7/qYLXrOT2Ky 2Noda3Foz3M2BxaPv+tcPZYs+cnk8frAfNYA5igum5TUnMyy1CJ9uwSujBkX+9gLdiRV7F9/ jbWB8UF8FyMHh4SAicTrazJdjJxAppjEhXvr2UBsIYEjjBIPLiR0MXIB2csZJQ5+72EBSbAJ GEm0HepnB0mICDQxSry6Mgesg1kgQmLmgj9MILawgJdE+/eDYHERAW+JmQ83Q9lGEh+ebGcG sVkEVCWuHu0Ai/MC1Rw68pQdYtsqJomlL8+ygDicAq2MEr/PfQLrYAS67/upNUwQ28Qlbj2Z zwRxt4DEkj3nmSFsUYmXj/+xQthKEpOWnmOFqM+XOHTvPBPENkGJkzOfsExgFJ2FZNQsJGWz kJTNAoYSs4CmxPpd+hAlihJTuh+yQ9gaEq1z5rIjiy9gZF/FyFFanFqWm25kuIkRGHHHJNgc dzAu+GR5iFGAg1GJh/fDCYZQIdbEsuLK3EOM0hwsSuK8ZVcOhggJpCeWpGanphakFsUXleak Fh9iZOLglGpgrO9f+HldxexjAXf85EsUmA6Xn1nTsU34kYpSwalrrHH8W73OMbc7dUbb61hu EljudtOtkn2C2X4ru+X553P5z19gKgnWuyF5lauwY39P2/nVi4KLvPdoFxQ1Moodasr/LbDN Ksb3h+OtMqVrKZtvRrYX7n17Zo/r3hvzj/3rVfPfsv91mPw8JZbijERDLeai4kQAn89UhpkC AAA= Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 06:59:03 -0700 Cc: "dnssd-chairs@ietf.org" , Ted Lemon Subject: Re: [dnssd] Further IPR disclosures on draft-ietf-dnssd-requirements-05 ? 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, 12 Mar 2015 13:20:52 -0000 --_000_2DD56D786E600F45AC6BDE7DA4E8A8C15D8C0Deusaamb107ericsso_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYW0gbm90IGF3YXJlIG9mIGFueSBhZGRpdGlvbmFsIElQUi4NCg0KQlINCkRhbmll bA0KDQpGcm9tOiBUaW0gQ2hvd24gW21haWx0bzp0amNAZWNzLnNvdG9uLmFjLnVrXQ0KU2VudDog VGh1cnNkYXksIE1hcmNoIDEyLCAyMDE1IDk6MDQgQU0NClRvOiBkcmFmdC1pZXRmLWRuc3NkLXJl cXVpcmVtZW50cy5hbGxAaWV0Zi5vcmcNCkNjOiBkbnNzZC1jaGFpcnNAaWV0Zi5vcmc7IFRlZCBM ZW1vbg0KU3ViamVjdDogRnVydGhlciBJUFIgZGlzY2xvc3VyZXMgb24gZHJhZnQtaWV0Zi1kbnNz ZC1yZXF1aXJlbWVudHMtMDUgPw0KDQpLZXJyeSwgU3R1YXJ0LCBNYXJjLCBEYW5pZWwsDQoNClBs ZWFzZSBjYW4geW91IGNvbmZpcm0gd2hldGhlciB0aGVyZSBpcyBhbnkgYWRkaXRpb25hbCBJUFIg b24gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCBhcyBwZXIgVGVk4oCZcyByZXF1ZXN0IGJlbG93Pw0K DQpBcyBwZXIgbXkgb3RoZXIgZW1haWwganVzdCBub3csIEkgdW5kZXJzdG9vZCB0aGF0IHRoZSBJ UFIgc3RhdGVtZW50IG9uIHRoZSByZXF1aXJlbWVudHMgZHJhZnQgKGkuZS4gIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvaXByLzIxMTQvKSBoYWQgaW50ZW5kZWQgdG8gYmUgb24gdGhlIGh5 YnJpZCBzb2x1dGlvbiBkcmFmdCAoaS5lLiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lw ci8yMTE5LyApLg0KDQpBcG9sb2dpZXMgZm9yIHRoaXMgZXh0cmEgbGF0ZSAoaG9wZWZ1bGx5IHNt YWxsKSBodXJkbGUuDQoNClRoYW5rcywNClRpbQ0KDQoNCk9uIDEyIE1hciAyMDE1LCBhdCAwMjox OSwgVGVkIExlbW9uIDxUZWQuTGVtb25Abm9taW51bS5jb208bWFpbHRvOlRlZC5MZW1vbkBub21p bnVtLmNvbT4+IHdyb3RlOg0KDQpPbiBNYXIgMTEsIDIwMTUsIGF0IDEwOjA3IFBNLCBQZXRlIFJl c25pY2sgPHByZXNuaWNrQHF0aS5xdWFsY29tbS5jb208bWFpbHRvOnByZXNuaWNrQHF0aS5xdWFs Y29tbS5jb20+PiB3cm90ZToNCg0KIFRoZSBkcmFmdCBpbmNsdWRlcyB0aGUgYm9pbGVycGxhdGUg Y29uZmlybWluZyB0aGF0IHRoZSBkb2N1bWVudCAiaXMNCiBzdWJtaXR0ZWQgaW4gZnVsbCBjb25m b3JtYW5jZSB3aXRoIHRoZSBwcm92aXNpb25zIG9mIEJDUCA3OCBhbmQgQkNQDQogNzkiLiBObyBk aXNjbG9zdXJlcyBoYXZlIGJlZW4gbWFkZSwgbm9yIGFyZSBleHBlY3RlZCB0byBiZSBtYWRlIGlu IGFuDQogSW5mb3JtYXRpb25hbCByZXF1aXJlbWVudHMgZHJhZnQuDQoNCkFyZ2gsIHNvcnJ5LCBJ IGRpZG4ndCBjYXRjaCB0aGF0LiAgIFRpbSwgcGxlYXNlIGFzayB0aGUgYXV0aG9ycyB0byBzYXkg ZXhwbGljaXRseSB3aGV0aGVyIHRoZXkgYXJlIGF3YXJlIG9mIGFueSBhZGRpdGlvbmFsIElQUi4g ICBUaGUgYm9pbGVycGxhdGUgaXNuJ3QgYWRlcXVhdGUsIGJlY2F1c2UgaXQgaXMgYWRkZWQgYnkg YSB0b29sLCBhbmQgaXMgbm90IHByZXNlbnQgaW4gdGhlIFhNTCBzb3VyY2UuDQoNCg0KVGhlcmUg d2FzIGFuIElQUiBkaXNjbG9zdXJlIG1hZGUgb24gdGhlIGVhcmxpZXIgcHJlLVdHIHZlcnNpb24g b2YgdGhpcw0KZG9jdW1lbnQgYmFjayBpbiAyMDEzLiBXZXJlIHRoZSBhdXRob3JzIGFza2VkIHdo ZXRoZXIgdGhhdCBkaXNjbG9zdXJlDQphbHNvIGFwcGxpZXMgdG8gdGhpcyB2ZXJzaW9uIG9mIHRo ZSBkb2N1bWVudD8gSXMgdGhlIFdHIGF3YXJlIG9mIHRoaXMNCmRpc2Nsb3N1cmU/IERpZCB0aGUg V0cgZGlzY3VzcyB0aGUgZGlzY2xvc3VyZT8gV2VyZSBhbnkgY29uY2VybnMgcmFpc2VkPw0KDQpI bS4gICBUaGlzIGhhcyBjZXJ0YWlubHkgY29tZSB1cCBpbiBtZWV0aW5ncy4gICBJIHRoaW5rIHRo ZSBvbmx5IHRpbWUgaXQgd2FzIG1lbnRpb25lZCBvbiB0aGUgbWFpbGluZyBsaXN0IHdhcyBwcmlv ciB0byB0aGUgQm9GIHRoYXQgcHJvZHVjZWQgZG5zc2QuICAgVGhlIGRpc2Nsb3N1cmUgaGFzIGJl ZW4gaW4gdGhlIHRyYWNrZXIgYWxsIGFsb25nLiAgIEFyZSB5b3Ugc3VnZ2VzdGluZyB0aGF0IHRo ZSB3b3JraW5nIGdyb3VwIG1heSBoYXZlIGFncmVlZCB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCB3 aXRob3V0IGJlaW5nIGF3YXJlIG9mIHRoaXMsIGRlc3BpdGUgdGhlIElQUiBoYXZpbmcgYmVlbiBw cmVzZW50IGluIHRoZSB0cmFja2VyPw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KZG5zc2QgbWFpbGluZyBsaXN0DQpkbnNzZEBpZXRmLm9yZzxtYWls dG86ZG5zc2RAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2Ruc3NkDQoNCg== --_000_2DD56D786E600F45AC6BDE7DA4E8A8C15D8C0Deusaamb107ericsso_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgYW0gbm90IGF3YXJlIG9m IGFueSBhZGRpdGlvbmFsIElQUi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJSPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkRhbmllbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFRpbSBDaG93biBbbWFpbHRvOnRqY0Bl Y3Muc290b24uYWMudWtdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDEyLCAy MDE1IDk6MDQgQU08YnI+DQo8Yj5Ubzo8L2I+IGRyYWZ0LWlldGYtZG5zc2QtcmVxdWlyZW1lbnRz LmFsbEBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gZG5zc2QtY2hhaXJzQGlldGYub3JnOyBUZWQg TGVtb248YnI+DQo8Yj5TdWJqZWN0OjwvYj4gRnVydGhlciBJUFIgZGlzY2xvc3VyZXMgb24gZHJh ZnQtaWV0Zi1kbnNzZC1yZXF1aXJlbWVudHMtMDUgPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZXJyeSwgU3R1YXJ0LCBNYXJjLCBEYW5pZWws PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBs ZWFzZSBjYW4geW91IGNvbmZpcm0gd2hldGhlciB0aGVyZSBpcyBhbnkgYWRkaXRpb25hbCBJUFIg b24gdGhlIHJlcXVpcmVtZW50cyBkcmFmdCBhcyBwZXIgVGVk4oCZcyByZXF1ZXN0IGJlbG93Pzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBw ZXIgbXkgb3RoZXIgZW1haWwganVzdCBub3csIEkgdW5kZXJzdG9vZCB0aGF0IHRoZSBJUFIgc3Rh dGVtZW50IG9uIHRoZSByZXF1aXJlbWVudHMgZHJhZnQgKGkuZS4gJm5ic3A7PGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvMjExNC8iPmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvaXByLzIxMTQvPC9hPikmbmJzcDtoYWQgaW50ZW5kZWQgdG8gYmUgb24gdGhlIGh5 YnJpZCBzb2x1dGlvbg0KIGRyYWZ0IChpLmUuJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9pcHIvMjExOS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXBy LzIxMTkvPC9hPiZuYnNwOykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkFwb2xvZ2llcyBmb3IgdGhpcyBleHRyYSBsYXRlIChob3BlZnVsbHkg c21hbGwpIGh1cmRsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGltJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAxMiBNYXIgMjAxNSwgYXQgMDI6MTksIFRlZCBMZW1vbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOlRlZC5MZW1vbkBub21pbnVtLmNvbSI+VGVkLkxlbW9uQG5vbWlu dW0uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIE1hciAxMSwgMjAxNSwgYXQgMTA6MDcgUE0sIFBldGUgUmVzbmljayAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnByZXNuaWNrQHF0aS5xdWFsY29tbS5jb20iPnByZXNuaWNrQHF0aS5xdWFsY29t bS5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwO1RoZSBkcmFmdCBpbmNsdWRlcyB0aGUgYm9pbGVycGxhdGUgY29u ZmlybWluZyB0aGF0IHRoZSBkb2N1bWVudCAmcXVvdDtpczxicj4NCiZuYnNwO3N1Ym1pdHRlZCBp biBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlIHByb3Zpc2lvbnMgb2YgQkNQIDc4IGFuZCBCQ1A8 YnI+DQombmJzcDs3OSZxdW90Oy4gTm8gZGlzY2xvc3VyZXMgaGF2ZSBiZWVuIG1hZGUsIG5vciBh cmUgZXhwZWN0ZWQgdG8gYmUgbWFkZSBpbiBhbjxicj4NCiZuYnNwO0luZm9ybWF0aW9uYWwgcmVx dWlyZW1lbnRzIGRyYWZ0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJy Pg0KQXJnaCwgc29ycnksIEkgZGlkbid0IGNhdGNoIHRoYXQuICZuYnNwOyZuYnNwO1RpbSwgcGxl YXNlIGFzayB0aGUgYXV0aG9ycyB0byBzYXkgZXhwbGljaXRseSB3aGV0aGVyIHRoZXkgYXJlIGF3 YXJlIG9mIGFueSBhZGRpdGlvbmFsIElQUi4gJm5ic3A7Jm5ic3A7VGhlIGJvaWxlcnBsYXRlIGlz bid0IGFkZXF1YXRlLCBiZWNhdXNlIGl0IGlzIGFkZGVkIGJ5IGEgdG9vbCwgYW5kIGlzIG5vdCBw cmVzZW50IGluIHRoZSBYTUwgc291cmNlLjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgd2FzIGFuIElQUiBkaXNjbG9zdXJlIG1hZGUg b24gdGhlIGVhcmxpZXIgcHJlLVdHIHZlcnNpb24gb2YgdGhpczxicj4NCmRvY3VtZW50IGJhY2sg aW4gMjAxMy4gV2VyZSB0aGUgYXV0aG9ycyBhc2tlZCB3aGV0aGVyIHRoYXQgZGlzY2xvc3VyZTxi cj4NCmFsc28gYXBwbGllcyB0byB0aGlzIHZlcnNpb24gb2YgdGhlIGRvY3VtZW50PyBJcyB0aGUg V0cgYXdhcmUgb2YgdGhpczxicj4NCmRpc2Nsb3N1cmU/IERpZCB0aGUgV0cgZGlzY3VzcyB0aGUg ZGlzY2xvc3VyZT8gV2VyZSBhbnkgY29uY2VybnMgcmFpc2VkPzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSG0uICZuYnNwOyZuYnNwO1RoaXMgaGFzIGNlcnRhaW5s eSBjb21lIHVwIGluIG1lZXRpbmdzLiAmbmJzcDsmbmJzcDtJIHRoaW5rIHRoZSBvbmx5IHRpbWUg aXQgd2FzIG1lbnRpb25lZCBvbiB0aGUgbWFpbGluZyBsaXN0IHdhcyBwcmlvciB0byB0aGUgQm9G IHRoYXQgcHJvZHVjZWQgZG5zc2QuICZuYnNwOyZuYnNwO1RoZSBkaXNjbG9zdXJlIGhhcyBiZWVu IGluIHRoZSB0cmFja2VyIGFsbCBhbG9uZy4gJm5ic3A7Jm5ic3A7QXJlIHlvdSBzdWdnZXN0aW5n IHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgbWF5IGhhdmUgYWdyZWVkDQogdG8gYWR2YW5jZSB0aGUg ZG9jdW1lbnQgd2l0aG91dCBiZWluZyBhd2FyZSBvZiB0aGlzLCBkZXNwaXRlIHRoZSBJUFIgaGF2 aW5nIGJlZW4gcHJlc2VudCBpbiB0aGUgdHJhY2tlcj88YnI+DQo8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmRuc3NkIG1haWxpbmcgbGlz dDxicj4NCjxhIGhyZWY9Im1haWx0bzpkbnNzZEBpZXRmLm9yZyI+ZG5zc2RAaWV0Zi5vcmc8L2E+ PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNz ZCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kbnNzZDwvYT48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_2DD56D786E600F45AC6BDE7DA4E8A8C15D8C0Deusaamb107ericsso_-- From nobody Thu Mar 12 06:59:07 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7C1AD1A00A2; Thu, 12 Mar 2015 06:27:21 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 540651A00A2; Thu, 12 Mar 2015 06:27:21 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-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 opekiMfHgPWs; Thu, 12 Mar 2015 06:27:19 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id 127441A00F4; Thu, 12 Mar 2015 06:27:19 -0700 (PDT) Received: from MB.local (h194.viagenie.ca [206.123.31.194]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9845840218; Thu, 12 Mar 2015 09:27:20 -0400 (EDT) Message-ID: <55019436.4010106@viagenie.ca> Date: Thu, 12 Mar 2015 09:27:18 -0400 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tim Chown , draft-ietf-dnssd-requirements.all@ietf.org References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000408060408020601020609" Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 06:59:03 -0700 Cc: dnssd-chairs@ietf.org, Ted Lemon Subject: Re: [dnssd] Further IPR disclosures on draft-ietf-dnssd-requirements-05 ? 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, 12 Mar 2015 13:27:21 -0000 This is a multi-part message in MIME format. --------------000408060408020601020609 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Le 2015-03-12 09:04, Tim Chown a écrit : > Kerry, Stuart, Marc, Daniel, > > Please can you confirm whether there is any additional IPR on the > requirements draft as per Ted’s request below? not on my side. Marc. > > As per my other email just now, I understood that the IPR statement on > the requirements draft (i.e. > https://datatracker.ietf.org/ipr/2114/) had intended to be on the > hybrid solution draft (i.e. https://datatracker.ietf.org/ipr/2119/ ). > > Apologies for this extra late (hopefully small) hurdle. > > Thanks, > Tim > >> On 12 Mar 2015, at 02:19, Ted Lemon > > wrote: >> >> On Mar 11, 2015, at 10:07 PM, Pete Resnick > > wrote: >>> The draft includes the boilerplate confirming that the document "is >>> submitted in full conformance with the provisions of BCP 78 and BCP >>> 79". No disclosures have been made, nor are expected to be made in an >>> Informational requirements draft. >> >> Argh, sorry, I didn't catch that. Tim, please ask the authors to >> say explicitly whether they are aware of any additional IPR. The >> boilerplate isn't adequate, because it is added by a tool, and is not >> present in the XML source. >> >>> There was an IPR disclosure made on the earlier pre-WG version of this >>> document back in 2013. Were the authors asked whether that disclosure >>> also applies to this version of the document? Is the WG aware of this >>> disclosure? Did the WG discuss the disclosure? Were any concerns raised? >> >> Hm. This has certainly come up in meetings. I think the only time >> it was mentioned on the mailing list was prior to the BoF that >> produced dnssd. The disclosure has been in the tracker all along. >> Are you suggesting that the working group may have agreed to >> advance the document without being aware of this, despite the IPR >> having been present in the tracker? >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd > --------------000408060408020601020609 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Le 2015-03-12 09:04, Tim Chown a écrit :
Kerry, Stuart, Marc, Daniel,

Please can you confirm whether there is any additional IPR on the requirements draft as per Ted’s request below?

not on my side. Marc.


As per my other email just now, I understood that the IPR statement on the requirements draft (i.e.  https://datatracker.ietf.org/ipr/2114/) had intended to be on the hybrid solution draft (i.e. https://datatracker.ietf.org/ipr/2119/ ).

Apologies for this extra late (hopefully small) hurdle.

Thanks,
Tim 

On 12 Mar 2015, at 02:19, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Mar 11, 2015, at 10:07 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
 The draft includes the boilerplate confirming that the document "is
 submitted in full conformance with the provisions of BCP 78 and BCP
 79". No disclosures have been made, nor are expected to be made in an
 Informational requirements draft.

Argh, sorry, I didn't catch that.   Tim, please ask the authors to say explicitly whether they are aware of any additional IPR.   The boilerplate isn't adequate, because it is added by a tool, and is not present in the XML source.

There was an IPR disclosure made on the earlier pre-WG version of this
document back in 2013. Were the authors asked whether that disclosure
also applies to this version of the document? Is the WG aware of this
disclosure? Did the WG discuss the disclosure? Were any concerns raised?

Hm.   This has certainly come up in meetings.   I think the only time it was mentioned on the mailing list was prior to the BoF that produced dnssd.   The disclosure has been in the tracker all along.   Are you suggesting that the working group may have agreed to advance the document without being aware of this, despite the IPR having been present in the tracker?

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd


--------------000408060408020601020609-- From nobody Thu Mar 12 07:12:48 2015 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 8C1881A066C; Thu, 12 Mar 2015 07:12:46 -0700 (PDT) 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 xg-LMt_PVoSR; Thu, 12 Mar 2015 07:12:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BBE1A0264; Thu, 12 Mar 2015 07:12:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150312141244.8415.9203.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 07:12:44 -0700 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, tjc@ecs.soton.ac.uk, jiangsheng@huawei.com Subject: [dnssd] Benoit Claise's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 12 Mar 2015 14:12:46 -0000 Benoit Claise has entered the following ballot position for draft-ietf-dnssd-requirements-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The IETF should definitively focus on this problem space. Thanks. Some comments below: - I agree with Martin's comment. - Section 4, REQ8 looks a very fundemental requirement for all service discovery mechanism. It does not look like a specific requirement for SSD - Some of the requirements will be hard to fulfill, if taken literally: REQ9: SSD should operate efficiently on common link layers and link types. REQ12: SSD should enable a way to provide a consistent user experience whether local or remote services are being discovered. - Very surprised that the Security Considerations don't lead to formal requirements For example, in connection with "6.1 Scope of Discovery" and "6.5 Access Control", I was expecting a requirement such as REQXX: the owner of the advertised service must be able to configure whether his service should be advertised beyond the local link The way the requirements are specified: all services will be visible to everybody, and the access control will accept/reject the service request. That reminds me of the typical airport wireless situation: you try every wireless network to see which one will accept you. From nobody Thu Mar 12 07:12:51 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A8EEF1A0A6A; Thu, 12 Mar 2015 07:12:46 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1881A066C; Thu, 12 Mar 2015 07:12:46 -0700 (PDT) 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 xg-LMt_PVoSR; Thu, 12 Mar 2015 07:12:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 17BBE1A0264; Thu, 12 Mar 2015 07:12:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Benoit Claise" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150312141244.8415.9203.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 07:12:44 -0700 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, tjc@ecs.soton.ac.uk, jiangsheng@huawei.com Subject: [dnssd] Benoit Claise's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 12 Mar 2015 14:12:46 -0000 Benoit Claise has entered the following ballot position for draft-ietf-dnssd-requirements-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The IETF should definitively focus on this problem space. Thanks. Some comments below: - I agree with Martin's comment. - Section 4, REQ8 looks a very fundemental requirement for all service discovery mechanism. It does not look like a specific requirement for SSD - Some of the requirements will be hard to fulfill, if taken literally: REQ9: SSD should operate efficiently on common link layers and link types. REQ12: SSD should enable a way to provide a consistent user experience whether local or remote services are being discovered. - Very surprised that the Security Considerations don't lead to formal requirements For example, in connection with "6.1 Scope of Discovery" and "6.5 Access Control", I was expecting a requirement such as REQXX: the owner of the advertised service must be able to configure whether his service should be advertised beyond the local link The way the requirements are specified: all services will be visible to everybody, and the access control will accept/reject the service request. That reminds me of the typical airport wireless situation: you try every wireless network to see which one will accept you. From nobody Thu Mar 12 09:39:54 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id DE0A61A8774; Thu, 12 Mar 2015 08:04:34 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA681A0334; Thu, 12 Mar 2015 07:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 GalUPsAR3Onz; Thu, 12 Mar 2015 07:56:51 -0700 (PDT) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4C4A1A7002; Thu, 12 Mar 2015 07:56:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1426172208; x=1457708208; h=from:to:cc:date:subject:message-id:references: in-reply-to:mime-version; bh=8vBVO2nEkvp25Qp1qNaCq0Nmd5JmjaumtStUx40BHeo=; b=OebrcP5lyTcG5zPYPQa4csLr8LOYP3OUEyVucLGKT9n3JKbuD/z6coIk OFSdBDncexRODnMvIC2pFwkDUi+0e03RBZMFMMTg1uvPNwi0Wn2yw1vcT c3kcVwNVIu67OKHigGlhvZK/sjVKc/CQwe8G6EQYGLROgLWUdwDn/vI9f E=; X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi02.verizon.com) ([166.68.71.144]) by fldsmtpe02.verizon.com with ESMTP; 12 Mar 2015 14:56:47 +0000 From: "Lynn, Kerry E" X-IronPort-AV: E=Sophos;i="5.11,389,1422921600"; d="scan'208,217";a="961699314" Received: from fldp1lumxc7hb05.verizon.com (HELO FLDP1LUMXC7HB05.us.one.verizon.com) ([166.68.75.87]) by fldsmtpi02.verizon.com with ESMTP; 12 Mar 2015 14:28:43 +0000 Received: from fldp1lumxc7v103.us.one.verizon.com ([169.254.3.146]) by FLDP1LUMXC7HB05.us.one.verizon.com ([166.68.75.87]) with mapi; Thu, 12 Mar 2015 10:28:42 -0400 To: Tim Chown , "draft-ietf-dnssd-requirements.all@ietf.org" Date: Thu, 12 Mar 2015 10:28:42 -0400 Thread-Topic: Further IPR disclosures on draft-ietf-dnssd-requirements-05 ? Thread-Index: AdBc0NZVlLnkn5m9QMGhnlzbjHt4rA== Message-ID: References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@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.8.150116 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_D1271A9363Dkerrylynnoneverizoncom_" MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 09:39:53 -0700 Cc: "dnssd-chairs@ietf.org" , Ted Lemon Subject: Re: [dnssd] Further IPR disclosures on draft-ietf-dnssd-requirements-05 ? 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, 12 Mar 2015 15:04:35 -0000 --_000_D1271A9363Dkerrylynnoneverizoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Tim, The draft contains no IPR that I'm aware of. I'm not sure I understand how an informational I-D addressing requirements could even contain IPR. Regards, Kerry From: Tim Chown > Date: Thursday, March 12, 2015 at 9:04 AM To: "draft-ietf-dnssd-requirements.all@ietf.org" > Cc: "dnssd-chairs@ietf.org" >, Ted Lemon > Subject: Further IPR disclosures on draft-ietf-dnssd-requirements-05 ? Kerry, Stuart, Marc, Daniel, Please can you confirm whether there is any additional IPR on the requireme= nts draft as per Ted=92s request below? As per my other email just now, I understood that the IPR statement on the = requirements draft (i.e. https://datatracker.ietf.org/ipr/2114/) had inten= ded to be on the hybrid solution draft (i.e. https://datatracker.ietf.org/i= pr/2119/ ). Apologies for this extra late (hopefully small) hurdle. Thanks, Tim On 12 Mar 2015, at 02:19, Ted Lemon > wrote: On Mar 11, 2015, at 10:07 PM, Pete Resnick > wrote: The draft includes the boilerplate confirming that the document "is submitted in full conformance with the provisions of BCP 78 and BCP 79". No disclosures have been made, nor are expected to be made in an Informational requirements draft. Argh, sorry, I didn't catch that. Tim, please ask the authors to say expl= icitly whether they are aware of any additional IPR. The boilerplate isn'= t adequate, because it is added by a tool, and is not present in the XML so= urce. There was an IPR disclosure made on the earlier pre-WG version of this document back in 2013. Were the authors asked whether that disclosure also applies to this version of the document? Is the WG aware of this disclosure? Did the WG discuss the disclosure? Were any concerns raised? Hm. This has certainly come up in meetings. I think the only time it wa= s mentioned on the mailing list was prior to the BoF that produced dnssd. = The disclosure has been in the tracker all along. Are you suggesting tha= t the working group may have agreed to advance the document without being a= ware of this, despite the IPR having been present in the tracker? _______________________________________________ dnssd mailing list dnssd@ietf.org https://www.ietf.org/mailman/listinfo/dnssd --_000_D1271A9363Dkerrylynnoneverizoncom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Tim,

Th= e draft contains no IPR that I'm aware of.  I'm not sure I understand<= /div>
how an informational I-D addressing requirements could even conta= in
IPR.

Regards, Kerry

From: Tim Chown <tjc@ecs.soton.ac.uk>
Date: Thursday, March 12, 2015 at 9:04 AM
= To: "draft-ietf-dnssd-requirements.all@iet= f.org" <draft-ietf-dnssd-requirements.all@ietf.org>
Cc: "dnssd-chairs@ietf.org" <dnssd-chairs@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: Further IPR disclosures on draft-ietf-dnssd-require= ments-05 ?

Kerry, Stuart, Marc, Daniel,

Please can you confirm whether there is any additional IPR on the requirem= ents draft as per Ted=92s request below?

As per my other email just now, I understood that the IPR statement on th= e requirements draft (i.e.  https://datatracker.ietf.org/ipr/2114/) had in= tended to be on the hybrid solution draft (i.e. https://datatracker.ietf.org/ipr/21= 19/ ).

Apologies for this extr= a late (hopefully small) hurdle.

Thanks= ,
Tim 

On 12 Mar 2015, at 02:19, Ted Lemon <Ted.Lemon@nominum.com> wro= te:

On Mar 11,= 2015, at 10:07 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
 The draft includes the boilerplat= e confirming that the document "is
 submitted in f= ull conformance with the provisions of BCP 78 and BCP
 = 79". No disclosures have been made, nor are expected to be made in an<= br class=3D"">  Informational requirements draft.

Argh, sorry, I didn't catch that.   Tim, pl= ease ask the authors to say explicitly whether they are aware of any additi= onal IPR.   The boilerplate isn't adequate, because it is added b= y a tool, and is not present in the XML source.

There was an IPR disclosure made on = the earlier pre-WG version of this
document back in 2013. Wer= e the authors asked whether that disclosure
also applies to t= his version of the document? Is the WG aware of this
disclosu= re? Did the WG discuss the disclosure? Were any concerns raised?

Hm.   This has certainly come u= p in meetings.   I think the only time it was mentioned on the ma= iling list was prior to the BoF that produced dnssd.   The disclo= sure has been in the tracker all along.   Are you suggesting that= the working group may have agreed to advance the document without being aw= are of this, despite the IPR having been present in the tracker?

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

--_000_D1271A9363Dkerrylynnoneverizoncom_-- From nobody Thu Mar 12 09:39:55 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 329B71A8774; Thu, 12 Mar 2015 08:06:29 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081251A8757; Thu, 12 Mar 2015 08:06:29 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-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 ysHFqxRVJeG2; Thu, 12 Mar 2015 08:06:22 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id ECCF01A7113; Thu, 12 Mar 2015 08:06:21 -0700 (PDT) Received: from kuwa.viagenie.ca (kuwa.viagenie.ca [206.123.31.98]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 8336C40DB3; Thu, 12 Mar 2015 11:06:23 -0400 (EDT) Message-ID: <5501AB6C.5080106@viagenie.ca> Date: Thu, 12 Mar 2015 11:06:20 -0400 From: Marc Blanchet User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "Lynn, Kerry E" , Tim Chown , "draft-ietf-dnssd-requirements.all@ietf.org" References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070505060407060907050905" Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 09:39:53 -0700 Cc: "dnssd-chairs@ietf.org" , Ted Lemon Subject: Re: [dnssd] Further IPR disclosures on draft-ietf-dnssd-requirements-05 ? 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, 12 Mar 2015 15:06:29 -0000 This is a multi-part message in MIME format. --------------070505060407060907050905 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 2015-03-12 10:28, Lynn, Kerry E a écrit : > Tim, > > The draft contains no IPR that I'm aware of. I'm not sure I understand > how an informational I-D addressing requirements could even contain > IPR. my take too. Not sure there is any IPR that could be claimed on this document. But, I guess it is safer and appropriate for our process to double check. I guess we are now just waiting for Stuart to confirm. Marc. > > Regards, Kerry > > From: Tim Chown > > Date: Thursday, March 12, 2015 at 9:04 AM > To: "draft-ietf-dnssd-requirements.all@ietf.org > " > > > Cc: "dnssd-chairs@ietf.org " > >, Ted Lemon > > > Subject: Further IPR disclosures on draft-ietf-dnssd-requirements-05 ? > > Kerry, Stuart, Marc, Daniel, > > Please can you confirm whether there is any additional IPR on the > requirements draft as per Ted’s request below? > > As per my other email just now, I understood that the IPR statement on > the requirements draft (i.e. > https://datatracker.ietf.org/ipr/2114/) had intended to be on the > hybrid solution draft (i.e. https://datatracker.ietf.org/ipr/2119/ ). > > Apologies for this extra late (hopefully small) hurdle. > > Thanks, > Tim > >> On 12 Mar 2015, at 02:19, Ted Lemon > > wrote: >> >> On Mar 11, 2015, at 10:07 PM, Pete Resnick > > wrote: >>> The draft includes the boilerplate confirming that the document "is >>> submitted in full conformance with the provisions of BCP 78 and BCP >>> 79". No disclosures have been made, nor are expected to be made in an >>> Informational requirements draft. >> >> Argh, sorry, I didn't catch that. Tim, please ask the authors to >> say explicitly whether they are aware of any additional IPR. The >> boilerplate isn't adequate, because it is added by a tool, and is not >> present in the XML source. >> >>> There was an IPR disclosure made on the earlier pre-WG version of this >>> document back in 2013. Were the authors asked whether that disclosure >>> also applies to this version of the document? Is the WG aware of this >>> disclosure? Did the WG discuss the disclosure? Were any concerns raised? >> >> Hm. This has certainly come up in meetings. I think the only time >> it was mentioned on the mailing list was prior to the BoF that >> produced dnssd. The disclosure has been in the tracker all along. >> Are you suggesting that the working group may have agreed to >> advance the document without being aware of this, despite the IPR >> having been present in the tracker? >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd > --------------070505060407060907050905 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Le 2015-03-12 10:28, Lynn, Kerry E a écrit :
Tim,

The draft contains no IPR that I'm aware of.  I'm not sure I understand
how an informational I-D addressing requirements could even contain
IPR.
my take too. Not sure there is any IPR that could be claimed on this document. But, I guess it is safer and appropriate for our process to double check. I guess we are now just waiting for Stuart to confirm.

Marc.

Regards, Kerry

From: Tim Chown <tjc@ecs.soton.ac.uk>
Date: Thursday, March 12, 2015 at 9:04 AM
To: "draft-ietf-dnssd-requirements.all@ietf.org" <draft-ietf-dnssd-requirements.all@ietf.org>
Cc: "dnssd-chairs@ietf.org" <dnssd-chairs@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>
Subject: Further IPR disclosures on draft-ietf-dnssd-requirements-05 ?

Kerry, Stuart, Marc, Daniel,

Please can you confirm whether there is any additional IPR on the requirements draft as per Ted’s request below?

As per my other email just now, I understood that the IPR statement on the requirements draft (i.e.  https://datatracker.ietf.org/ipr/2114/) had intended to be on the hybrid solution draft (i.e. https://datatracker.ietf.org/ipr/2119/ ).

Apologies for this extra late (hopefully small) hurdle.

Thanks,
Tim 

On 12 Mar 2015, at 02:19, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Mar 11, 2015, at 10:07 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
 The draft includes the boilerplate confirming that the document "is
 submitted in full conformance with the provisions of BCP 78 and BCP
 79". No disclosures have been made, nor are expected to be made in an
 Informational requirements draft.

Argh, sorry, I didn't catch that.   Tim, please ask the authors to say explicitly whether they are aware of any additional IPR.   The boilerplate isn't adequate, because it is added by a tool, and is not present in the XML source.

There was an IPR disclosure made on the earlier pre-WG version of this
document back in 2013. Were the authors asked whether that disclosure
also applies to this version of the document? Is the WG aware of this
disclosure? Did the WG discuss the disclosure? Were any concerns raised?

Hm.   This has certainly come up in meetings.   I think the only time it was mentioned on the mailing list was prior to the BoF that produced dnssd.   The disclosure has been in the tracker all along.   Are you suggesting that the working group may have agreed to advance the document without being aware of this, despite the IPR having been present in the tracker?

_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

--------------070505060407060907050905-- From nobody Thu Mar 12 09:39:57 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2F3BD1A885E; Thu, 12 Mar 2015 08:57:56 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02151A88AB; Thu, 12 Mar 2015 08:57:55 -0700 (PDT) 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 UUQRDy-BRG2t; Thu, 12 Mar 2015 08:57:54 -0700 (PDT) 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 CBD101A885E; Thu, 12 Mar 2015 08:57:52 -0700 (PDT) Received: from webmail.nominum.com (cas-03.win.nominum.com [64.89.235.66]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id A118EDA03EE; Thu, 12 Mar 2015 15:57:52 +0000 (UTC) Received: from [10.0.20.107] (71.233.43.215) by CAS-03.WIN.NOMINUM.COM (192.168.1.100) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 12 Mar 2015 08:57:52 -0700 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: <5501AB6C.5080106@viagenie.ca> Date: Thu, 12 Mar 2015 11:57:48 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <72B9E980-F231-48E3-87E5-090504F9D545@nominum.com> References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> <5501AB6C.5080106@viagenie.ca> To: Marc Blanchet X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 09:39:53 -0700 Cc: "draft-ietf-dnssd-requirements.all@ietf.org" , Tim Chown , "dnssd-chairs@ietf.org" , "Lynn, Kerry E" Subject: Re: [dnssd] Further IPR disclosures on draft-ietf-dnssd-requirements-05 ? 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, 12 Mar 2015 15:57:56 -0000 On Mar 12, 2015, at 11:06 AM, Marc Blanchet = wrote: > my take too. Not sure there is any IPR that could be claimed on this = document. But, I guess it is safer and appropriate for our process to = double check. I guess we are now just waiting for Stuart to confirm. IPR can be claimed on _any_ document by submitting an IPR disclosure. = We (the IETF) do not judge the validity of IPR disclosures--we simply = track them and decide whether they affect our willingness to publish a = document. From nobody Thu Mar 12 09:52:02 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 123BF1A88C0; Thu, 12 Mar 2015 09:50:55 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D831F1A88DD; Thu, 12 Mar 2015 09:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.231 X-Spam-Level: X-Spam-Status: No, score=-1.231 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_NEUTRAL=0.779, 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 1TK9qiceMAEy; Thu, 12 Mar 2015 09:50:54 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29F9B1A88C0; Thu, 12 Mar 2015 09:50:54 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2CGok8u019387; Thu, 12 Mar 2015 16:50:46 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t2CGok8u019387 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1426179046; bh=nZxWFN45NiCSGrxM9cWZ3KO6qqI=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=Bv9q7NuU5a9SoUBL4lzQlWRN9aq8EOIRWcucUR6sbUoBypMBu2WmSmrjgnCeK6UiF 9PcL38LvvbWmFool8kkesF1OUhzVX/Ez8zIt2ym+JBaYUabV82bYyPW8ki6as0qK2Y mfrslpc77iSTNxaV3J217IfiDXHDDVicH7AyqLSs= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id r2BGok11947105873O ret-id none; Thu, 12 Mar 2015 16:50:46 +0000 Received: from [IPv6:2001:630:d0:f111:1c53:dbf6:34e2:c371] ([IPv6:2001:630:d0:f111:1c53:dbf6:34e2:c371]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2CGoh9G012070 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Mar 2015 16:50:44 GMT Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Tim Chown In-Reply-To: <72B9E980-F231-48E3-87E5-090504F9D545@nominum.com> Date: Thu, 12 Mar 2015 16:50:44 +0000 Content-Transfer-Encoding: quoted-printable Message-ID: References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> <5501AB6C.5080106@viagenie.ca> <72B9E980-F231-48E3-87E5-090504F9D545@nominum.com> <0FA0680A-39C4-46A3-A14C-45B3AAE8B3FF@ecs.soton.ac.uk> To: Ted Lemon X-Mailer: Apple Mail (2.2070.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=r2BGok119471058700; tid=r2BGok11947105873O; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t2CGok8u019387 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 09:52:02 -0700 Cc: Marc Blanchet , "dnssd-chairs@ietf.org" , "Lynn, Kerry E" , "draft-ietf-dnssd-requirements.all@ietf.org" Subject: Re: [dnssd] Further IPR disclosures on draft-ietf-dnssd-requirements-05 ? 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, 12 Mar 2015 16:50:56 -0000 > On 12 Mar 2015, at 15:57, Ted Lemon wrote: >=20 > On Mar 12, 2015, at 11:06 AM, Marc Blanchet = wrote: >> my take too. Not sure there is any IPR that could be claimed on this = document. But, I guess it is safer and appropriate for our process to = double check. I guess we are now just waiting for Stuart to confirm. >=20 > IPR can be claimed on _any_ document by submitting an IPR disclosure. = We (the IETF) do not judge the validity of IPR disclosures--we simply = track them and decide whether they affect our willingness to publish a = document. Right. But I believe in this case the disclosure was (accidentally) put = on the wrong draft, hence the update / re-pointer to the hybrid draft. Tim From nobody Thu Mar 12 10:44:32 2015 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 2AAE21A8F3C; Thu, 12 Mar 2015 10:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 2CDz8hMYcKHA; Thu, 12 Mar 2015 10:44:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A88931A8BBD; Thu, 12 Mar 2015 10:44:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150312174429.16246.99420.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 10:44:29 -0700 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: 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, 12 Mar 2015 17:44:31 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Thu Mar 12 10:44:34 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 45EB51A8F3F; Thu, 12 Mar 2015 10:44:31 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAE21A8F3C; Thu, 12 Mar 2015 10:44:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 2CDz8hMYcKHA; Thu, 12 Mar 2015 10:44:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A88931A8BBD; Thu, 12 Mar 2015 10:44:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150312174429.16246.99420.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 10:44:29 -0700 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: 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, 12 Mar 2015 17:44:31 -0000 IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Thu Mar 12 11:12:34 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 36AA81A03F9; Thu, 12 Mar 2015 10:02:14 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18F671A0145; Thu, 12 Mar 2015 10:02:14 -0700 (PDT) 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 ULC_DXeKMGfk; Thu, 12 Mar 2015 10:02:13 -0700 (PDT) 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 2EECB1A0039; Thu, 12 Mar 2015 10:02:13 -0700 (PDT) Received: from webmail.nominum.com (cas-04.win.nominum.com [64.89.235.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by sjc1-mx02-inside.nominum.com (Postfix) with ESMTPS id C33E2DA03D2; Thu, 12 Mar 2015 17:02:12 +0000 (UTC) Received: from [10.0.20.107] (71.233.43.215) by CAS-04.WIN.NOMINUM.COM (192.168.1.101) with Microsoft SMTP Server (TLS) id 14.3.224.2; Thu, 12 Mar 2015 10:02:12 -0700 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: Thu, 12 Mar 2015 13:02:07 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3DB4B852-DED5-4742-95D5-14E495B2E1B8@nominum.com> References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> <5501AB6C.5080106@viagenie.ca> <72B9E980-F231-48E3-87E5-090504F9D545@nominum.com> <0FA0680A-39C4-46A3-A14C-45B3AAE8B3FF@ecs.soton.ac.uk> To: Tim Chown X-Mailer: Apple Mail (2.1878.6) X-Originating-IP: [71.233.43.215] Archived-At: X-Mailman-Approved-At: Thu, 12 Mar 2015 11:12:32 -0700 Cc: Marc Blanchet , "dnssd-chairs@ietf.org" , "Lynn, Kerry E" , "draft-ietf-dnssd-requirements.all@ietf.org" Subject: Re: [dnssd] Further IPR disclosures on draft-ietf-dnssd-requirements-05 ? 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, 12 Mar 2015 17:02:14 -0000 On Mar 12, 2015, at 12:50 PM, Tim Chown wrote: > Right. But I believe in this case the disclosure was (accidentally) = put on the wrong draft, hence the update / re-pointer to the hybrid = draft. Ah. That's unfortunate. From nobody Thu Mar 12 11:25:19 2015 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 2E6BF1A06E9; Thu, 12 Mar 2015 11:25:02 -0700 (PDT) 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 0ezc3jq4xhzC; Thu, 12 Mar 2015 11:24:58 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3441A03E1; Thu, 12 Mar 2015 11:24:56 -0700 (PDT) Received: by padet14 with SMTP id et14so22470394pad.11; Thu, 12 Mar 2015 11:24:55 -0700 (PDT) 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=qh4LHa//74U7i3/xJ6pKAShz7q141CNm3hop2B8+9/U=; b=hOX2bOtIUzasSJbZCVJNqGfoaiI3iO74EQhn+NwzgF6ekbo9xYevBA31YtPMy+jKKl Cl7pqtaAiKVYGwaZuDMzO50M8EXpphoff18/jxqFuRg9MIL1Pm+IcOQRputS24bapZGP W7FEcMqhwMVoPTkb0w0UlM/AefJAgyMgpO+3XVY6XCBive5l7o50XJwt0QaDFlbUkIv/ kpTMcCJP4rMiR7rGYp2zisLjoE9zdvLt40tnUfWrmepVkgX7LZ3lKYjKDiTUOZhlStUJ 9xwfuBU2jVOKgMS/85wALlAMDcqkuVq1wvTqGqF+CIceluvqdoBg/jEm0hRRTMdV3WR5 JJvA== X-Received: by 10.66.171.199 with SMTP id aw7mr94438089pac.6.1426184695752; Thu, 12 Mar 2015 11:24:55 -0700 (PDT) Received: from [192.168.248.115] (c-24-6-60-244.hsd1.ca.comcast.net. [24.6.60.244]) by mx.google.com with ESMTPSA id dt10sm11966227pdb.82.2015.03.12.11.24.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Mar 2015 11:24:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Douglas Otis In-Reply-To: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 11:24:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , tjc@ecs.soton.ac.uk Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 12 Mar 2015 18:25:02 -0000 X-List-Received-Date: Thu, 12 Mar 2015 18:25:02 -0000 > On Mar 10, 2015, at 4:04 PM, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-dnssd-requirements-05: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - section 6 intro: I'm not sure I buy that the set of relevant > threats is only a union as stated. There are often new threats > in new environments. >=20 > - 6.6: I think one can also leak private information by > searching in too broad a scope, e.g. if the client can be > fingerprinted allowing re-identification. I think that's > different from the example given, and maybe worth noting too. Dear Stephen, I agree with your statement and, based on our tests, these concerns are = very real!=20 IPv6 can not be defended in the same manner as with IPv4. With Homenet, = an effort was made to ensure address selection preferences critical when publishing addresses within DNS but omitted from the requirements = documents. =20 The statement made in Section 6.1 is poorly considered. ,-- Section 6.1 ... Note that discovery of a service does not necessarily imply that the service is reachable by, or can be connected to, or can be used by, a given client. Specific access control mechanisms are out of scope of this document. '--- Or the false statement: ,-- 6.5. Access Control ... While controlling access to an advertised service is outside the scope of DNS-SD, we note that access control today often is provided by existing site infrastructure (e.g., router access control lists, firewalls) and/or by service-specific mechanisms (e.g., user authentication to the service). For example, networked printers can control access via a user-id and password. Apple's software supports such access control for USB printers shared via Mac OS X Printer Sharing, as do many networked printers themselves. So the reliance on existing service-specific security mechanisms (i.e. outside the scope of DNS-SD) does not create new security considerations. '--- Most printers DO NOT offer user-id/password access mechanisms and often IPv6 support removes access control lists. Homenet and Apples BTMM make use of an important overlay approach being ignored both here and = with the the insecure UPnP. For this protocol to safely interoperate, an=20 overlay approach must be supported. This approach might use ULAs, for=20= example. For this to work properly, locally defined addresses must be preferred when publishing in DNS. As previously presented, it is minor fix to correct this oversight.=20 Regards, Douglas Otis= From nobody Thu Mar 12 11:25:23 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 5B6E31A1A03; Thu, 12 Mar 2015 11:25:02 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6BF1A06E9; Thu, 12 Mar 2015 11:25:02 -0700 (PDT) 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 0ezc3jq4xhzC; Thu, 12 Mar 2015 11:24:58 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A3441A03E1; Thu, 12 Mar 2015 11:24:56 -0700 (PDT) Received: by padet14 with SMTP id et14so22470394pad.11; Thu, 12 Mar 2015 11:24:55 -0700 (PDT) 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=qh4LHa//74U7i3/xJ6pKAShz7q141CNm3hop2B8+9/U=; b=hOX2bOtIUzasSJbZCVJNqGfoaiI3iO74EQhn+NwzgF6ekbo9xYevBA31YtPMy+jKKl Cl7pqtaAiKVYGwaZuDMzO50M8EXpphoff18/jxqFuRg9MIL1Pm+IcOQRputS24bapZGP W7FEcMqhwMVoPTkb0w0UlM/AefJAgyMgpO+3XVY6XCBive5l7o50XJwt0QaDFlbUkIv/ kpTMcCJP4rMiR7rGYp2zisLjoE9zdvLt40tnUfWrmepVkgX7LZ3lKYjKDiTUOZhlStUJ 9xwfuBU2jVOKgMS/85wALlAMDcqkuVq1wvTqGqF+CIceluvqdoBg/jEm0hRRTMdV3WR5 JJvA== X-Received: by 10.66.171.199 with SMTP id aw7mr94438089pac.6.1426184695752; Thu, 12 Mar 2015 11:24:55 -0700 (PDT) Received: from [192.168.248.115] (c-24-6-60-244.hsd1.ca.comcast.net. [24.6.60.244]) by mx.google.com with ESMTPSA id dt10sm11966227pdb.82.2015.03.12.11.24.54 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Mar 2015 11:24:55 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Douglas Otis In-Reply-To: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> Date: Thu, 12 Mar 2015 11:24:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , tjc@ecs.soton.ac.uk Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 12 Mar 2015 18:25:02 -0000 > On Mar 10, 2015, at 4:04 PM, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-dnssd-requirements-05: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - section 6 intro: I'm not sure I buy that the set of relevant > threats is only a union as stated. There are often new threats > in new environments. >=20 > - 6.6: I think one can also leak private information by > searching in too broad a scope, e.g. if the client can be > fingerprinted allowing re-identification. I think that's > different from the example given, and maybe worth noting too. Dear Stephen, I agree with your statement and, based on our tests, these concerns are = very real!=20 IPv6 can not be defended in the same manner as with IPv4. With Homenet, = an effort was made to ensure address selection preferences critical when publishing addresses within DNS but omitted from the requirements = documents. =20 The statement made in Section 6.1 is poorly considered. ,-- Section 6.1 ... Note that discovery of a service does not necessarily imply that the service is reachable by, or can be connected to, or can be used by, a given client. Specific access control mechanisms are out of scope of this document. '--- Or the false statement: ,-- 6.5. Access Control ... While controlling access to an advertised service is outside the scope of DNS-SD, we note that access control today often is provided by existing site infrastructure (e.g., router access control lists, firewalls) and/or by service-specific mechanisms (e.g., user authentication to the service). For example, networked printers can control access via a user-id and password. Apple's software supports such access control for USB printers shared via Mac OS X Printer Sharing, as do many networked printers themselves. So the reliance on existing service-specific security mechanisms (i.e. outside the scope of DNS-SD) does not create new security considerations. '--- Most printers DO NOT offer user-id/password access mechanisms and often IPv6 support removes access control lists. Homenet and Apples BTMM make use of an important overlay approach being ignored both here and = with the the insecure UPnP. For this protocol to safely interoperate, an=20 overlay approach must be supported. This approach might use ULAs, for=20= example. For this to work properly, locally defined addresses must be preferred when publishing in DNS. As previously presented, it is minor fix to correct this oversight.=20 Regards, Douglas Otis= From nobody Fri Mar 13 06:48:46 2015 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 789F91A8700 for ; Fri, 13 Mar 2015 06:48:45 -0700 (PDT) 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 jJPPPRxxZW7K for ; Fri, 13 Mar 2015 06:48:44 -0700 (PDT) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AAF81A871F for ; Fri, 13 Mar 2015 06:48:44 -0700 (PDT) Received: by qgfh3 with SMTP id h3so25903723qgf.2 for ; Fri, 13 Mar 2015 06:48:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:subject:mime-version:from:date :content-transfer-encoding:reply-to:message-id:to; bh=iJb7O5vxltrfsIKiiNCO0ejQhIAatF17Vv9JmKAPZWE=; b=tKPKU6nFiMOIc1SDc03bEi3Q+M3ZWPhgwnc5C1hFZAAYn25xzVIYqKQHk8UnJimUf8 xaLW52yQ4B67dhcbiWbgCn1aUy3Q7U10ZXTXiseuSJQc4jQ64TfQhPXQi3tsI/okpNDg ZSuDqwQ5P3vreNcyKjmvmXPCZ+9Fy2w1YLZa/6KgAHBJ+IoVUK3astc7dkFaRVxYkNiY jpUSTtPleDKWlry0n6DytB9xCuI27K55apPuz1AuDcVroidehD0jidy8i/fIar19SCz/ yxNWYgJ+hSuoSa1Jz/y+4xNFrCP56RUjZkI35nwkeab3+1z2EW0i3rynWnc7dbHvzj8G tLlw== X-Received: by 10.140.89.146 with SMTP id v18mr57901885qgd.65.1426254523363; Fri, 13 Mar 2015 06:48:43 -0700 (PDT) Received: from ?IPv6:2001:420:2c8b:1300:18e6:dc2d:e21b:8558? ([2001:420:2c8b:1300:18e6:dc2d:e21b:8558]) by mx.google.com with ESMTPSA id 63sm1396796qkx.31.2015.03.13.06.48.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Mar 2015 06:48:42 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ralph Droms Date: Fri, 13 Mar 2015 13:48:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: To: dnssd@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [dnssd] Draft agenda for IETF-92 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "" 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, 13 Mar 2015 13:48:45 -0000 I've included the draft agenda below. Please contact the chairs if you = would like a slot at the meeting. - Ralph dnssd WG Agenda - IETF 92 1300-1500CDT 2015-03-23 (Last revised 2015-03-13 13:39 ET) ---------------------------------- Administrivia Droms/Chown 10 = minutes =20 Introduction and NoteWell Agenda bashing; blue sheets; scribe; Jabber scribe DNS Long-Lived Queries Pusateri/Cheshire 30 = minutes draft-ietf-dnssd-push-00 New draft review; discuss adoption as WG document Multicast DNS (mDNS) Threat Model and Security Consideration Rafiee 20 = minutes draft-rafiee-dnssd-mdns-threatmodel-01 Review of updates Hybrid Unicast/Multicast DNS-Based Service Discovery Cheshire 15 = minutes draft-ietf-dnssd-hybrid-00 Review of document against requirements On Interoperation of Labels Between mDNS and DNS Sullivan 20 = minutes draft-sullivan-dnssd-mdns-dns-interop-01 Update on WG document; prepare for WG last call = ----------- 95 = minutes =20 From nobody Fri Mar 13 10:09:14 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id BAB671AC422; Thu, 12 Mar 2015 20:47:12 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A4F1AC3D6 for ; Thu, 12 Mar 2015 20:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.101 X-Spam-Level: X-Spam-Status: No, score=-104.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=unavailable 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 OCXI6soSHGxZ for ; Thu, 12 Mar 2015 20:47:11 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19D681A89FB for ; Thu, 12 Mar 2015 20:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1426218430; x=2290132030; 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=UynAI1tE1S0w9a5hbsh7Kkk4HWJK5Ba7R84C8gmLTZc=; b=S8n57NOuUWO1QS0addt7ruz7kk71qdgQZVT25f5xx57BehNx2w5e838rvzqBbqx5 98YTiy9ICkZgOkTwu0UqHrOXKpkeibT6WNuuKtwbC8Ll6uznKAwXWvQ+w/vY6g8u 37jP6yMLKy5EI1dvQ/HYdAoUqNMag6LNCa0avMwFWoH5KgceLNo0PGP/PB8VvwKS 7sMHzkGpMiV5hofph0ymDmkjaxIhpuZJqGwjrGhgP6F8trjAClSjCenGF0Vey6jm 3EC6i/9VPLGPg8xVroT/UUxq4POv85JILhiDURYMW2XwRu3ez/IGqV8DhAETCPqf KjF1+Mhjy8Og6y4IUSoYvA==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id D9.30.03354.EBD52055; Thu, 12 Mar 2015 20:47:10 -0700 (PDT) X-AuditID: 11973e16-f79b66d000000d1a-60-55025dbee29f Received: from nwk-phonehomebzp-sz01 (nwk-phonehomebzp-sz01.apple.com [17.151.62.64]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id 30.E7.06911.3CD52055; Thu, 12 Mar 2015 20:47:15 -0700 (PDT) Received: from [10.0.1.14] ([173.164.252.149]) by nwk-phonehomebzp-sz01.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NL40050GT6L4M80@nwk-phonehomebzp-sz01.apple.com>; Thu, 12 Mar 2015 20:47:10 -0700 (PDT) Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Stuart Cheshire In-reply-to: Date: Thu, 12 Mar 2015 20:47:09 -0700 Content-transfer-encoding: quoted-printable Message-id: <138A7610-424A-4A83-8222-6A887F958BFF@apple.com> References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> To: Marc Braner , Helene Plotka Workman X-Mailer: Apple Mail (2.2070.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUi2FCYprsvlinUYN53SYsr7/qYLXrOT2Jy YPJYsuQnUwBjFJdNSmpOZllqkb5dAlfGpq9TmAquiVZsurWaqYHxgGAXIyeHhICJRO/qGywQ tpjEhXvr2UBsIYF9jBIrLvPC1Kx5uYuxi5ELKL6ASeLXu6usEM5EJok9y5cCORwczALqElOm 5II08AoYSHzZeZQdxBYW8JKY/+or2AI2AS2JF5+vsIH0cgq0M0q86P0Pto1FQFVi7SSQIi6g OX8ZJd6cuMUMkmAW0JZ48u4C2AJeARuJU00yEItXMUksfXkWbKqIgK9E/4UpYDUSAvISPZvS QWokBBrZJFbf/c4+gVF4FsJ9s5DcNwvJhgWMzKsYhXITM3N0M/PM9RILCnJS9ZLzczcxggJ6 up3YDsaHq6wOMQpwMCrx8HYwM4YKsSaWFVfmHmKU5mBREudt7PsfIiSQnliSmp2aWpBaFF9U mpNafIiRiYNTqoHxiHeNyMWK1mdXjcv1/ucGH9vVMOVHd1l+QOxkuw8+WotOfN/bWH5PPfju nefhD9rl3lsoWy46veWn91qF979/qFp9Vdtxbo7CT751P11K3c42JlX92mi1sEp+cWKLwqL+ Q5lekzV3fDvbLjPpiddK117/z03mnmfWh85VSZy1buasByluZ6vvKbEUZyQaajEXFScCAA33 BJhJAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUiON3OQfdwLFOowfcjshZX3vUxW/Scn8Tk wOSxZMlPpgDGKC6blNSczLLUIn27BK6MTV+nMBVcE63YdGs1UwPjAcEuRk4OCQETiTUvdzFC 2GISF+6tZ+ti5OIQEljAJPHr3VVWCGcik8Se5UuBHA4OZgF1iSlTckEaeAUMJL7sPMoOYgsL eEnMf/WVBcRmE9CSePH5CtggToF2RokXvf/ZQBIsAqoSayeBFHEBzfnLKPHmxC1mkASzgLbE k3cXwBbwCthInGqSgVi8ikli6cuzYFNFBHwl+i9MAauREJCX6NmUPoFRYBbCSbOQnDQLydAF jMyrGAWKUnMSKy30EgsKclL1kvNzNzGCQrChMG0HY9Nyq0OMAhyMSjy8HcyMoUKsiWXFlbmH GCU4mJVEeBeHMYUK8aYkVlalFuXHF5XmpBYfYpTmYFES59158UeIkEB6YklqdmpqQWoRTJaJ g1OqgXHxM4HPG7UvdZzoa3n1pXL3vvl176PmVWftnHM95dv1JyVhf/MFZuQ4/w6dpikXwaGr aFI45d2k56ezXxzoq9bcPb9Xkn3lupbMGyteGTBrlMguVAn6nJgvfPu0nfiJZb0a8s89hB2N Qo7uenbisW6eTMa3Cf/OhJ1ftFDrk3yrn3/TqvOvNvQrsRRnJBpqMRcVJwIAOw1j1j0CAAA= Archived-At: X-Mailman-Approved-At: Fri, 13 Mar 2015 10:09:13 -0700 Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, Pete Resnick , Tim Chown , Ted Lemon , Vividh Siddha , David Singer Subject: Re: [dnssd] Further IPR disclosures on draft-ietf-dnssd-requirements-05 ? 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, 13 Mar 2015 03:47:12 -0000 Marc and Helene, Can you formally retract Apple=E2=80=99s erroneous IPR disclosure = ? It=E2=80=99s preventing publication of = After all the work we did to get though Working Group adoption, Working = Group Last Call, and IETF Last Call, this is an unfortunate last-minute = road block. I have stated that I am not aware of any IPR relating to this document, = and the existence of an IPR disclosure to the contrary is causing some = raised eyebrows. Can we get this mistake cleared up? Stuart Cheshire > On 12 Mar, 2015, at 06:04, Tim Chown wrote: >=20 > Kerry, Stuart, Marc, Daniel, >=20 > Please can you confirm whether there is any additional IPR on the = requirements draft as per Ted=E2=80=99s request below? >=20 > As per my other email just now, I understood that the IPR statement on = the requirements draft (i.e. https://datatracker.ietf.org/ipr/2114/) = had intended to be on the hybrid solution draft (i.e. = https://datatracker.ietf.org/ipr/2119/ ). >=20 > Apologies for this extra late (hopefully small) hurdle. >=20 > Thanks, > Tim=20 >=20 >> On 12 Mar 2015, at 02:19, Ted Lemon wrote: >>=20 >> On Mar 11, 2015, at 10:07 PM, Pete Resnick = wrote: >>> The draft includes the boilerplate confirming that the document "is >>> submitted in full conformance with the provisions of BCP 78 and BCP >>> 79". No disclosures have been made, nor are expected to be made in = an >>> Informational requirements draft. >>=20 >> Argh, sorry, I didn't catch that. Tim, please ask the authors to = say explicitly whether they are aware of any additional IPR. The = boilerplate isn't adequate, because it is added by a tool, and is not = present in the XML source. >>=20 >>> There was an IPR disclosure made on the earlier pre-WG version of = this >>> document back in 2013. Were the authors asked whether that = disclosure >>> also applies to this version of the document? Is the WG aware of = this >>> disclosure? Did the WG discuss the disclosure? Were any concerns = raised? >>=20 >> Hm. This has certainly come up in meetings. I think the only time = it was mentioned on the mailing list was prior to the BoF that produced = dnssd. The disclosure has been in the tracker all along. Are you = suggesting that the working group may have agreed to advance the = document without being aware of this, despite the IPR having been = present in the tracker? >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd From nobody Fri Mar 13 10:48:02 2015 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 3B8451A1AC1; Fri, 13 Mar 2015 10:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 rP65Zf28BmAM; Fri, 13 Mar 2015 10:47:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C27841A0145; Fri, 13 Mar 2015 10:47:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150313174749.2435.7999.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 10:47:49 -0700 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, tjc@ecs.soton.ac.uk Subject: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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: Fri, 13 Mar 2015 17:47:55 -0000 Pete Resnick has entered the following ballot position for draft-ietf-dnssd-requirements-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [Updating to reflect that the IPR disclosure issue is addressed. There is an IPR disclosure that appears for this document, but it was a mistakenly filed disclosure that still remains in the system. We will deal with that issue separately.] Section 5: OLD Devices on different links may have the same mDNS name (perhaps due to vendor defaults), because link-local mDNS names are only guaranteed to be unique on a per-link basis. Also, even devices that are on the same link may have similar-looking names, such as one device with the name "Bill" and another device using the similar- looking name "Bi11" (using the digit "1" in place of the letter "l"). This may lead to a local label disambiguation problem between presented results. SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today. SSD must not negatively impact the global DNS namespace or infrastructure. The part about name collisions is fine, and should be said. The part about disambiguating similar characters is a rat's nest I really think you need to avoid. We can discuss this further, but the i18n community is dealing with this issue right now and it's a mess you really don't want to get into. I think you should simply stick to something like this: NEW Devices on different links may have the same mDNS name (perhaps due to vendor defaults), because link-local mDNS names are only guaranteed to be unique on a per-link basis. SSD needs to deal with name collisions beyond local link considerations. SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today and should look to work in using internationalize strings in application protocols [soon-to-be-RFC-draft-ietf-precis-framework]. SSD must not negatively impact the global DNS namespace or infrastructure. From nobody Fri Mar 13 10:48:04 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 673251A0145; Fri, 13 Mar 2015 10:47:55 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B8451A1AC1; Fri, 13 Mar 2015 10:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.9 X-Spam-Level: X-Spam-Status: No, score=-3.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2] 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 rP65Zf28BmAM; Fri, 13 Mar 2015 10:47:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C27841A0145; Fri, 13 Mar 2015 10:47:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150313174749.2435.7999.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 10:47:49 -0700 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, tjc@ecs.soton.ac.uk Subject: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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: Fri, 13 Mar 2015 17:47:55 -0000 Pete Resnick has entered the following ballot position for draft-ietf-dnssd-requirements-05: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- [Updating to reflect that the IPR disclosure issue is addressed. There is an IPR disclosure that appears for this document, but it was a mistakenly filed disclosure that still remains in the system. We will deal with that issue separately.] Section 5: OLD Devices on different links may have the same mDNS name (perhaps due to vendor defaults), because link-local mDNS names are only guaranteed to be unique on a per-link basis. Also, even devices that are on the same link may have similar-looking names, such as one device with the name "Bill" and another device using the similar- looking name "Bi11" (using the digit "1" in place of the letter "l"). This may lead to a local label disambiguation problem between presented results. SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today. SSD must not negatively impact the global DNS namespace or infrastructure. The part about name collisions is fine, and should be said. The part about disambiguating similar characters is a rat's nest I really think you need to avoid. We can discuss this further, but the i18n community is dealing with this issue right now and it's a mess you really don't want to get into. I think you should simply stick to something like this: NEW Devices on different links may have the same mDNS name (perhaps due to vendor defaults), because link-local mDNS names are only guaranteed to be unique on a per-link basis. SSD needs to deal with name collisions beyond local link considerations. SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today and should look to work in using internationalize strings in application protocols [soon-to-be-RFC-draft-ietf-precis-framework]. SSD must not negatively impact the global DNS namespace or infrastructure. From nobody Fri Mar 13 13:39:40 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id CBCBF1A1BA7; Fri, 13 Mar 2015 13:37:42 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A991C1A1E0B; Fri, 13 Mar 2015 13:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.23 X-Spam-Level: X-Spam-Status: No, score=-1.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, 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 n-HLZK2OcYKM; Fri, 13 Mar 2015 13:37:41 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ACBF1A6EDB; Fri, 13 Mar 2015 13:37:37 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost.ecs.soton.ac.uk [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2DKbXwq024250; Fri, 13 Mar 2015 20:37:33 GMT X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk t2DKbXwq024250 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1426279054; bh=XKe0Wd00ugLIvxHZEDc3FsSeUIE=; h=Mime-Version:Subject:From:In-Reply-To:Date:Cc:References:To; b=oFy0UfxZpMjtm5QUs6vWhHd6hkKGZO4Kk/fml4EYktrnK74UyD8dWOgvCsgwQ7T32 CgWbpG98fZQKhxUM/Zo7LLc+GKX+sd4x5YjEJTUS4xU6yJsuncWHPdFqcWBvFFuQ4w q09GVKz1KYm0Va7TEEvsxnKS6qdG5HVi+6x+cPdI= Received: from gander.ecs.soton.ac.uk (gander.ecs.soton.ac.uk [2001:630:d0:f102::25d]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102::25e]) envelope-from with ESMTP (valid=N/A) id r2CKbX0944513662PJ ret-id none; Fri, 13 Mar 2015 20:37:33 +0000 Received: from [192.168.1.105] (host213-123-213-183.in-addr.btopenworld.com [213.123.213.183]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id t2DKbSoF006397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Mar 2015 20:37:29 GMT Content-Type: multipart/alternative; boundary="Apple-Mail=_AD4277D8-36F1-457B-BF74-C9485347250E" Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Tim Chown In-Reply-To: <72B9E980-F231-48E3-87E5-090504F9D545@nominum.com> Date: Fri, 13 Mar 2015 20:37:29 +0000 Message-ID: References: <20150312020708.27620.27985.idtracker@ietfa.amsl.com> <64537593-69EF-43FA-8660-58812A265EFB@nominum.com> <5501AB6C.5080106@viagenie.ca> <72B9E980-F231-48E3-87E5-090504F9D545@nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.2070.6) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=r2CKbX094451366200; tid=r2CKbX0944513662PJ; client=relay,ipv6; mail=; rcpt=; nrcpt=5:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: t2DKbXwq024250 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Archived-At: X-Mailman-Approved-At: Fri, 13 Mar 2015 13:39:38 -0700 Cc: Marc Blanchet , "dnssd-chairs@ietf.org" , "Lynn, Kerry E" , "draft-ietf-dnssd-requirements.all@ietf.org" Subject: Re: [dnssd] Further IPR disclosures on draft-ietf-dnssd-requirements-05 ? 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, 13 Mar 2015 20:37:43 -0000 --Apple-Mail=_AD4277D8-36F1-457B-BF74-C9485347250E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Tim > On 12 Mar 2015, at 15:57, Ted Lemon wrote: >=20 > On Mar 12, 2015, at 11:06 AM, Marc Blanchet = wrote: >> my take too. Not sure there is any IPR that could be claimed on this = document. But, I guess it is safer and appropriate for our process to = double check. I guess we are now just waiting for Stuart to confirm. >=20 > IPR can be claimed on _any_ document by submitting an IPR disclosure. = We (the IETF) do not judge the validity of IPR disclosures--we simply = track them and decide whether they affect our willingness to publish a = document. Fair point.=20 I think we also now have statements from all authors that there are no = additional IPR claims on this doc. Tim= --Apple-Mail=_AD4277D8-36F1-457B-BF74-C9485347250E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

Tim

On 12 Mar 2015, at 15:57, Ted Lemon <Ted.Lemon@nominum.com> wrote:

On Mar 12, 2015, at = 11:06 AM, Marc Blanchet <marc.blanchet@viagenie.ca> wrote:
my take too. Not sure = there is any IPR that could be claimed on this document. But, I guess it = is safer and appropriate for our process to double check. I guess we are = now just waiting for Stuart to confirm.

IPR can be claimed on _any_ document by submitting an IPR = disclosure.   We (the IETF) do not judge the validity of IPR = disclosures--we simply track them and decide whether they affect our = willingness to publish a document.

Fair = point. 

I = think we also now have statements from all authors that there are no = additional IPR claims on this doc.

Tim
= --Apple-Mail=_AD4277D8-36F1-457B-BF74-C9485347250E-- From nobody Fri Mar 13 13:41:02 2015 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 B132B1A6F7C; Fri, 13 Mar 2015 13:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 pQL1rw5VXBzu; Fri, 13 Mar 2015 13:40:58 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659501A6F11; Fri, 13 Mar 2015 13:40:56 -0700 (PDT) Received: by obcuz6 with SMTP id uz6so22295635obc.7; Fri, 13 Mar 2015 13:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lymHLMEeump7OcE/NVU8MnPvBMuzi/rygQNSvXILx3s=; b=x0rvpMpzsOJdyu4AXlA/nrZOSOx4tcVaIJdeewjix/qQZOkEIwAA7WNVD57GXgyv+r IZVHxC7D25U/Df1TIyLl3Mfo6VyAV5W4+8D/IbbvuDEKehvsp6T5Zq+Lf9DNp6B4ddaa 3v+yFaWKR7xcgXJCNEyA4dH0Xb9FBBTcJoumajOiW5XHnnkjYMBGFJh0HjAsgyFjo6Ft t6ex0fl/AvPPM7ocQewuVZ2hsaazUIf7tI5Zfow+3bXRz7vydFucgY/8UyGIGoSG7Xkd icCd5DH54D6I/wEU9T03oANMmoQY5yumo7IXHPKCTnHAFOOLNPLrJwonqwM847XvwEhY Q5Hg== MIME-Version: 1.0 X-Received: by 10.60.245.165 with SMTP id xp5mr5179504oec.84.1426279255754; Fri, 13 Mar 2015 13:40:55 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.11.136 with HTTP; Fri, 13 Mar 2015 13:40:55 -0700 (PDT) In-Reply-To: <20150311062107.16301.27032.idtracker@ietfa.amsl.com> References: <20150311062107.16301.27032.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 16:40:55 -0400 X-Google-Sender-Auth: wwIaKvSrmBs5d36V9BBkeOoxbCQ Message-ID: From: Kerry Lynn To: Spencer Dawkins Content-Type: multipart/alternative; boundary=001a11341f5e63cec5051131846a Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , Tim Chown Subject: Re: [dnssd] Spencer Dawkins' No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 13 Mar 2015 20:40:59 -0000 --001a11341f5e63cec5051131846a Content-Type: text/plain; charset=UTF-8 On Wed, Mar 11, 2015 at 2:21 AM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-dnssd-requirements-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm glad to see this moving forward. I have a few minor comments, but > just do the right thing. > > I was at at least one BOF where this was discussed, so I kind of knew > what to expect, but I didn't find the title clear. Could the word > "multi-link" be added someplace? > > This text: > > It is common practice for enterprises and > institutions to use wireless links for client access and wired > networks for server infrastructure, typically on different > subnets. > > didn't seem quite right. Is it saying > > It is common practice for enterprises and > institutions to use wireless links for client access to wired > ^^ > networks for server infrastructure, typically on different > subnets. > > ? As written, this excludes my office network, which includes both > clients on wired and wireless links, and I suppose that's an environment > where this extension might be useful ... > > What it's trying to say is that large networks are typically *not* one large bridged collection of wired and wireless links, but I guess we could sharpen this up a bit. > (an embarrassingly small nit) In this text: > > SSD should support rich internationalized labels within Service > Instance Names, as DNS-SD/mDNS does today. SSD must not negatively > impact the global DNS namespace or infrastructure. > > the two requirements don't seem particularly related, and I wonder if the > second would get more attention if it was a separate paragraph. > > They are related to the extent that DNS-SD/mDNS and the global DNS currently use different namespaces (see my reply to Pete R). Regards, Kerry Lynn --001a11341f5e63cec5051131846a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 11, 2015 at 2:21 AM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
Spenc= er Dawkins has entered the following ballot position for
draft-ietf-dnssd-requirements-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirem= ents/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm glad to see this moving forward. I have a few minor comments, but just do the right thing.

I was at at least one BOF where this was discussed, so I kind of knew
what to expect, but I didn't find the title clear. Could the word
"multi-link" be added someplace?

This text:

=C2=A0 =C2=A0 =C2=A0 It is common practice for enterprises and
=C2=A0 =C2=A0 =C2=A0 institutions to use wireless links for client access a= nd wired
=C2=A0 =C2=A0 =C2=A0 networks for server infrastructure, typically on diffe= rent
=C2=A0 =C2=A0 =C2=A0 subnets.

didn't seem quite right. Is it saying

=C2=A0 =C2=A0 =C2=A0 It is common practice for enterprises and
=C2=A0 =C2=A0 =C2=A0 institutions to use wireless links for client access t= o wired
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^
=C2=A0 =C2=A0 =C2=A0 networks for server infrastructure, typically on diffe= rent
=C2=A0 =C2=A0 =C2=A0 subnets.

? As written, this excludes my office network, which includes both
clients on wired and wireless links, and I suppose that's an environmen= t
where this extension might be useful ...

<KEL> What it's trying to say is that large= networks are typically *not* one
large bridged collection of= wired and wireless links, but I guess we could sharpen
this = up a bit.
=C2=A0
(an embarrassingly small nit) In this text:

=C2=A0 =C2=A0SSD should support rich internationalized labels within Servic= e
=C2=A0 =C2=A0Instance Names, as DNS-SD/mDNS does today.=C2=A0 SSD must not = negatively
=C2=A0 =C2=A0impact the global DNS namespace or infrastructure.

the two requirements don't seem particularly related, and I wonder if t= he
second would get more attention if it was a separate paragraph.

<KEL> They are related to the extent that DNS-S= D/mDNS and the global DNS
currently use different namespaces = (see my reply to Pete R).

Regards, Kerry Lynn
<= /div>
--001a11341f5e63cec5051131846a-- From nobody Fri Mar 13 13:41:07 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id F33621A6F30; Fri, 13 Mar 2015 13:40:59 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B132B1A6F7C; Fri, 13 Mar 2015 13:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 pQL1rw5VXBzu; Fri, 13 Mar 2015 13:40:58 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659501A6F11; Fri, 13 Mar 2015 13:40:56 -0700 (PDT) Received: by obcuz6 with SMTP id uz6so22295635obc.7; Fri, 13 Mar 2015 13:40:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=lymHLMEeump7OcE/NVU8MnPvBMuzi/rygQNSvXILx3s=; b=x0rvpMpzsOJdyu4AXlA/nrZOSOx4tcVaIJdeewjix/qQZOkEIwAA7WNVD57GXgyv+r IZVHxC7D25U/Df1TIyLl3Mfo6VyAV5W4+8D/IbbvuDEKehvsp6T5Zq+Lf9DNp6B4ddaa 3v+yFaWKR7xcgXJCNEyA4dH0Xb9FBBTcJoumajOiW5XHnnkjYMBGFJh0HjAsgyFjo6Ft t6ex0fl/AvPPM7ocQewuVZ2hsaazUIf7tI5Zfow+3bXRz7vydFucgY/8UyGIGoSG7Xkd icCd5DH54D6I/wEU9T03oANMmoQY5yumo7IXHPKCTnHAFOOLNPLrJwonqwM847XvwEhY Q5Hg== MIME-Version: 1.0 X-Received: by 10.60.245.165 with SMTP id xp5mr5179504oec.84.1426279255754; Fri, 13 Mar 2015 13:40:55 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.11.136 with HTTP; Fri, 13 Mar 2015 13:40:55 -0700 (PDT) In-Reply-To: <20150311062107.16301.27032.idtracker@ietfa.amsl.com> References: <20150311062107.16301.27032.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 16:40:55 -0400 X-Google-Sender-Auth: wwIaKvSrmBs5d36V9BBkeOoxbCQ Message-ID: From: Kerry Lynn To: Spencer Dawkins Content-Type: multipart/alternative; boundary=001a11341f5e63cec5051131846a Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , Tim Chown Subject: Re: [dnssd] Spencer Dawkins' No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 13 Mar 2015 20:41:00 -0000 --001a11341f5e63cec5051131846a Content-Type: text/plain; charset=UTF-8 On Wed, Mar 11, 2015 at 2:21 AM, Spencer Dawkins < spencerdawkins.ietf@gmail.com> wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-dnssd-requirements-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I'm glad to see this moving forward. I have a few minor comments, but > just do the right thing. > > I was at at least one BOF where this was discussed, so I kind of knew > what to expect, but I didn't find the title clear. Could the word > "multi-link" be added someplace? > > This text: > > It is common practice for enterprises and > institutions to use wireless links for client access and wired > networks for server infrastructure, typically on different > subnets. > > didn't seem quite right. Is it saying > > It is common practice for enterprises and > institutions to use wireless links for client access to wired > ^^ > networks for server infrastructure, typically on different > subnets. > > ? As written, this excludes my office network, which includes both > clients on wired and wireless links, and I suppose that's an environment > where this extension might be useful ... > > What it's trying to say is that large networks are typically *not* one large bridged collection of wired and wireless links, but I guess we could sharpen this up a bit. > (an embarrassingly small nit) In this text: > > SSD should support rich internationalized labels within Service > Instance Names, as DNS-SD/mDNS does today. SSD must not negatively > impact the global DNS namespace or infrastructure. > > the two requirements don't seem particularly related, and I wonder if the > second would get more attention if it was a separate paragraph. > > They are related to the extent that DNS-SD/mDNS and the global DNS currently use different namespaces (see my reply to Pete R). Regards, Kerry Lynn --001a11341f5e63cec5051131846a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Mar 11, 2015 at 2:21 AM, Spencer Dawkins <spencerdawkins.ietf@gmail.com> wrote:
Spenc= er Dawkins has entered the following ballot position for
draft-ietf-dnssd-requirements-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirem= ents/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm glad to see this moving forward. I have a few minor comments, but just do the right thing.

I was at at least one BOF where this was discussed, so I kind of knew
what to expect, but I didn't find the title clear. Could the word
"multi-link" be added someplace?

This text:

=C2=A0 =C2=A0 =C2=A0 It is common practice for enterprises and
=C2=A0 =C2=A0 =C2=A0 institutions to use wireless links for client access a= nd wired
=C2=A0 =C2=A0 =C2=A0 networks for server infrastructure, typically on diffe= rent
=C2=A0 =C2=A0 =C2=A0 subnets.

didn't seem quite right. Is it saying

=C2=A0 =C2=A0 =C2=A0 It is common practice for enterprises and
=C2=A0 =C2=A0 =C2=A0 institutions to use wireless links for client access t= o wired
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0^^
=C2=A0 =C2=A0 =C2=A0 networks for server infrastructure, typically on diffe= rent
=C2=A0 =C2=A0 =C2=A0 subnets.

? As written, this excludes my office network, which includes both
clients on wired and wireless links, and I suppose that's an environmen= t
where this extension might be useful ...

<KEL> What it's trying to say is that large= networks are typically *not* one
large bridged collection of= wired and wireless links, but I guess we could sharpen
this = up a bit.
=C2=A0
(an embarrassingly small nit) In this text:

=C2=A0 =C2=A0SSD should support rich internationalized labels within Servic= e
=C2=A0 =C2=A0Instance Names, as DNS-SD/mDNS does today.=C2=A0 SSD must not = negatively
=C2=A0 =C2=A0impact the global DNS namespace or infrastructure.

the two requirements don't seem particularly related, and I wonder if t= he
second would get more attention if it was a separate paragraph.

<KEL> They are related to the extent that DNS-S= D/mDNS and the global DNS
currently use different namespaces = (see my reply to Pete R).

Regards, Kerry Lynn
<= /div>
--001a11341f5e63cec5051131846a-- From nobody Fri Mar 13 13:41:22 2015 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 69D991A6F7C; Fri, 13 Mar 2015 13:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 HBjiovh2BdpH; Fri, 13 Mar 2015 13:41:05 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5FD1A1B5F; Fri, 13 Mar 2015 13:41:05 -0700 (PDT) Received: by oiga141 with SMTP id a141so905011oig.11; Fri, 13 Mar 2015 13:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=owUzb0XMtHxANN+tW5vuOl236jmduoemsZJaFWgaygU=; b=0XG8mfHtnT6Hlatrpg/ICzbQJ+kVIv3j/mzyUikG4UcUUKk0y6EUBpEiIgWPG9GbxC MjSzDWyCi8tHXVAE8aOLD1F1OjnroRgFBYsFjR5AsHQWmKBErvyOhA022Z5amor89r3f Ge155B9AFWswfkjpTwMOyEu+GlqtMKGhRgiTUnemiQzR9hXavH/mD5jAhhTUdeAEk2n2 49xS0jeguAbliY1C7SGk2OmMaAKXBNF6C8chw0krTeK7pPJJOrvjnEnfmmR11rD7Uz6c cBZ9nTH/pA3zsx2RIbKMiLTUJ4gDvufjBTWy+c2c4GXCQ2uE7x3CVwN3KIwP+Clf+BWz hTaA== MIME-Version: 1.0 X-Received: by 10.182.241.38 with SMTP id wf6mr40139870obc.81.1426279264558; Fri, 13 Mar 2015 13:41:04 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.11.136 with HTTP; Fri, 13 Mar 2015 13:41:04 -0700 (PDT) In-Reply-To: <20150312060951.8282.11525.idtracker@ietfa.amsl.com> References: <20150312060951.8282.11525.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 16:41:04 -0400 X-Google-Sender-Auth: PvMIwfkKjtQIIsPT_9MOFdxpL84 Message-ID: From: Kerry Lynn To: Martin Stiemerling Content-Type: multipart/alternative; boundary=001a11c30f80ea25830511318418 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , Tim Chown Subject: Re: [dnssd] Martin Stiemerling's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 13 Mar 2015 20:41:07 -0000 --001a11c30f80ea25830511318418 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 12, 2015 at 2:09 AM, Martin Stiemerling wrote: > Martin Stiemerling has entered the following ballot position for > draft-ietf-dnssd-requirements-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > A nit: > Please expand the terms DNS-SD and mDNS at their first use, for instance, > in the Abstract. > > Will do. Kerry Lynn > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --001a11c30f80ea25830511318418 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 12, 2015 at 2:09 AM, Martin Stiemerling <mls= .ietf@gmail.com> wrote:
Martin Stiemerling has e= ntered the following ballot position for
draft-ietf-dnssd-requirements-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirem= ents/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A nit:
Please expand the terms DNS-SD and mDNS at their first use, for instance, in the Abstract.

Will do.

Kerry Lynn

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

--001a11c30f80ea25830511318418-- From nobody Fri Mar 13 13:41:29 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 154B11A7001; Fri, 13 Mar 2015 13:41:07 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D991A6F7C; Fri, 13 Mar 2015 13:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 HBjiovh2BdpH; Fri, 13 Mar 2015 13:41:05 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5FD1A1B5F; Fri, 13 Mar 2015 13:41:05 -0700 (PDT) Received: by oiga141 with SMTP id a141so905011oig.11; Fri, 13 Mar 2015 13:41:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=owUzb0XMtHxANN+tW5vuOl236jmduoemsZJaFWgaygU=; b=0XG8mfHtnT6Hlatrpg/ICzbQJ+kVIv3j/mzyUikG4UcUUKk0y6EUBpEiIgWPG9GbxC MjSzDWyCi8tHXVAE8aOLD1F1OjnroRgFBYsFjR5AsHQWmKBErvyOhA022Z5amor89r3f Ge155B9AFWswfkjpTwMOyEu+GlqtMKGhRgiTUnemiQzR9hXavH/mD5jAhhTUdeAEk2n2 49xS0jeguAbliY1C7SGk2OmMaAKXBNF6C8chw0krTeK7pPJJOrvjnEnfmmR11rD7Uz6c cBZ9nTH/pA3zsx2RIbKMiLTUJ4gDvufjBTWy+c2c4GXCQ2uE7x3CVwN3KIwP+Clf+BWz hTaA== MIME-Version: 1.0 X-Received: by 10.182.241.38 with SMTP id wf6mr40139870obc.81.1426279264558; Fri, 13 Mar 2015 13:41:04 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.11.136 with HTTP; Fri, 13 Mar 2015 13:41:04 -0700 (PDT) In-Reply-To: <20150312060951.8282.11525.idtracker@ietfa.amsl.com> References: <20150312060951.8282.11525.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 16:41:04 -0400 X-Google-Sender-Auth: PvMIwfkKjtQIIsPT_9MOFdxpL84 Message-ID: From: Kerry Lynn To: Martin Stiemerling Content-Type: multipart/alternative; boundary=001a11c30f80ea25830511318418 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , Tim Chown Subject: Re: [dnssd] Martin Stiemerling's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 13 Mar 2015 20:41:07 -0000 --001a11c30f80ea25830511318418 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 12, 2015 at 2:09 AM, Martin Stiemerling wrote: > Martin Stiemerling has entered the following ballot position for > draft-ietf-dnssd-requirements-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > A nit: > Please expand the terms DNS-SD and mDNS at their first use, for instance, > in the Abstract. > > Will do. Kerry Lynn > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --001a11c30f80ea25830511318418 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 12, 2015 at 2:09 AM, Martin Stiemerling <mls= .ietf@gmail.com> wrote:
Martin Stiemerling has e= ntered the following ballot position for
draft-ietf-dnssd-requirements-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirem= ents/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

A nit:
Please expand the terms DNS-SD and mDNS at their first use, for instance, in the Abstract.

Will do.

Kerry Lynn

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

--001a11c30f80ea25830511318418-- From nobody Fri Mar 13 13:41:31 2015 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 C5A401A1B5F; Fri, 13 Mar 2015 13:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 pG2uwOiAy0gd; Fri, 13 Mar 2015 13:41:11 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5051A6F30; Fri, 13 Mar 2015 13:41:11 -0700 (PDT) Received: by oifz81 with SMTP id z81so6158427oif.6; Fri, 13 Mar 2015 13:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qQ28aTzFUldhbl++KXdo2epet9BOg9JNujvGH/dzfDk=; b=GFSZJtgAMFoSSJGuG1SBTrB+PTmgaAar8j3MqoFlmqRg73IPbkE3wrx5nKq+P+hGTu PS6nqM2HMHibnzN0ZRWJkr2/qw53WWP9i/ENU/unsS3Hd/yXO+BMtHrG/hJHdObQ8j9U vrI3sk+GaJau3Es5xCuqtSCCdaD8win/FBo3M/EqTCd/tVwQKYkn0mLS7ML1nFtyNDEz kxiQeBLVKry7AsKC+VP5JjNXdzzH3wwcpLLZFsO5ZC0M6BEkPP7EG751kc8OKC+6/bkn Soxg1x6E28iPzaRl/MSNVDPhBbW+iI6qcnaDvhJNkaWCVOHLsqNFlxEJS5PwXlJnTx4p qMQA== MIME-Version: 1.0 X-Received: by 10.202.71.83 with SMTP id u80mr11752154oia.88.1426279270645; Fri, 13 Mar 2015 13:41:10 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.11.136 with HTTP; Fri, 13 Mar 2015 13:41:10 -0700 (PDT) In-Reply-To: <20150312141244.8415.9203.idtracker@ietfa.amsl.com> References: <20150312141244.8415.9203.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 16:41:10 -0400 X-Google-Sender-Auth: Z9EPdOrxXMNOzVeNplYB6SjhJS4 Message-ID: From: Kerry Lynn To: Benoit Claise Content-Type: multipart/alternative; boundary=001a113e4f8c47040f051131856f Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Tim Chown , The IESG , jiangsheng@huawei.com Subject: Re: [dnssd] Benoit Claise's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 13 Mar 2015 20:41:13 -0000 --001a113e4f8c47040f051131856f Content-Type: text/plain; charset=UTF-8 On Thu, Mar 12, 2015 at 10:12 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-dnssd-requirements-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The IETF should definitively focus on this problem space. Thanks. > > Some comments below: > > - I agree with Martin's comment. > > As do I. > - Section 4, REQ8 looks a very fundemental requirement for all service > discovery mechanism. It does not look like a specific requirement for > SSD > > Are you suggesting we should remove REQ8? This specifically includes M2M, which may not be a requirement of *all* SD mechanisms. > - Some of the requirements will be hard to fulfill, if taken literally: > REQ9: SSD should operate efficiently on common link layers and link > types. > > Are you suggesting we should remove REQ9? I think this specifically relates to reducing the dependence on multicast. > REQ12: SSD should enable a way to provide a consistent user > experience whether local or remote services are being > discovered. > > I agree; this one seems hard. But I still think we should try to satisfy it. > - Very surprised that the Security Considerations don't lead to formal > requirements > For example, in connection with "6.1 Scope of Discovery" and "6.5 Access > Control", I was expecting a requirement such as > REQXX: the owner of the advertised service must be able to configure > whether his service should be advertised beyond the local link > > I think you make a good point. As I read REQ1 & REQ2, it seems that in a typical multi-subnet residential case the user might have to take some action to make a service visible beyond the local link or site. OTOH, it might be a good idea to explicitly say that a user must OPT-IN to global advertisements. BTW, I believe it's in plan to produce a separate threat analysis document which may help clarify additional requirements. Regards, Kerry Lynn > The way the requirements are specified: all services will be visible to > everybody, and the access control will accept/reject the service request. > That reminds me of the typical airport wireless situation: you try every > wireless network to see which one will accept you. > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --001a113e4f8c47040f051131856f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 12, 2015 at 10:12 AM, Benoit Claise <bclaise= @cisco.com> wrote:
Benoit Claise has entered t= he following ballot position for
draft-ietf-dnssd-requirements-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirem= ents/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The IETF should definitively focus on this problem space. Thanks.

Some comments below:

- I agree with Martin's comment.

As do I.
=C2=A0
- Section 4, REQ8 looks a very fundemental requirement for all service
discovery mechanism. It does not look like a specific requirement for
SSD

Are you suggesting we should remove REQ8?=C2=A0 This = specifically includes
M2M, which may not be a requirement of = *all* SD mechanisms.
=C2=A0
- Some of the requirements will be hard to fulfill, if taken literally:
=C2=A0 =C2=A0REQ9:=C2=A0 =C2=A0SSD should operate efficiently on common lin= k layers and link
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0types.

Are you suggesting we should remove REQ9?=C2=A0 I thi= nk this specifically relates
to reducing the dependence on mu= lticast.
=C2=A0
=C2=A0 =C2=A0REQ12:=C2=A0 SSD should enable a way to provide a consistent u= ser
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0experience whether local or remote= services are being
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discovered.

I agree; this one seems hard.=C2=A0 But I still think= we should try to satisfy it.
=C2=A0
- Very surprised that the Security Considerations don't lead to formal<= br> requirements
For example, in connection with "6.1 Scope of Discovery" and &quo= t;6.5 Access
Control", I was expecting a requirement such as
=C2=A0 =C2=A0REQXX:=C2=A0 the owner of the advertised service must be able = to configure
whether his service should be advertised beyond the local link

I think you make a good point.=C2=A0 As I read REQ1 &= amp; REQ2, it seems that in a
typical multi-subnet residentia= l case the user might have to take some action
to make a serv= ice visible beyond the local link or site.=C2=A0 OTOH, it might be a
good idea to explicitly say that a user must OPT-IN to global adver= tisements.

BTW, I believe it's in plan to produce a s= eparate threat analysis document
which may help clarify addit= ional requirements.

Regards, Kerry Lynn
=C2= =A0
The way the requirements are specified: all services will be visible to
everybody, and the access control will accept/reject the service request. That reminds me of the typical airport wireless situation: you try every wireless network to see which one will accept you.


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

--001a113e4f8c47040f051131856f-- From nobody Fri Mar 13 13:41:41 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id EB0081A7001; Fri, 13 Mar 2015 13:41:12 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A401A1B5F; Fri, 13 Mar 2015 13:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 pG2uwOiAy0gd; Fri, 13 Mar 2015 13:41:11 -0700 (PDT) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5051A6F30; Fri, 13 Mar 2015 13:41:11 -0700 (PDT) Received: by oifz81 with SMTP id z81so6158427oif.6; Fri, 13 Mar 2015 13:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=qQ28aTzFUldhbl++KXdo2epet9BOg9JNujvGH/dzfDk=; b=GFSZJtgAMFoSSJGuG1SBTrB+PTmgaAar8j3MqoFlmqRg73IPbkE3wrx5nKq+P+hGTu PS6nqM2HMHibnzN0ZRWJkr2/qw53WWP9i/ENU/unsS3Hd/yXO+BMtHrG/hJHdObQ8j9U vrI3sk+GaJau3Es5xCuqtSCCdaD8win/FBo3M/EqTCd/tVwQKYkn0mLS7ML1nFtyNDEz kxiQeBLVKry7AsKC+VP5JjNXdzzH3wwcpLLZFsO5ZC0M6BEkPP7EG751kc8OKC+6/bkn Soxg1x6E28iPzaRl/MSNVDPhBbW+iI6qcnaDvhJNkaWCVOHLsqNFlxEJS5PwXlJnTx4p qMQA== MIME-Version: 1.0 X-Received: by 10.202.71.83 with SMTP id u80mr11752154oia.88.1426279270645; Fri, 13 Mar 2015 13:41:10 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.11.136 with HTTP; Fri, 13 Mar 2015 13:41:10 -0700 (PDT) In-Reply-To: <20150312141244.8415.9203.idtracker@ietfa.amsl.com> References: <20150312141244.8415.9203.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 16:41:10 -0400 X-Google-Sender-Auth: Z9EPdOrxXMNOzVeNplYB6SjhJS4 Message-ID: From: Kerry Lynn To: Benoit Claise Content-Type: multipart/alternative; boundary=001a113e4f8c47040f051131856f Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Tim Chown , The IESG , jiangsheng@huawei.com Subject: Re: [dnssd] Benoit Claise's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 13 Mar 2015 20:41:13 -0000 --001a113e4f8c47040f051131856f Content-Type: text/plain; charset=UTF-8 On Thu, Mar 12, 2015 at 10:12 AM, Benoit Claise wrote: > Benoit Claise has entered the following ballot position for > draft-ietf-dnssd-requirements-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The IETF should definitively focus on this problem space. Thanks. > > Some comments below: > > - I agree with Martin's comment. > > As do I. > - Section 4, REQ8 looks a very fundemental requirement for all service > discovery mechanism. It does not look like a specific requirement for > SSD > > Are you suggesting we should remove REQ8? This specifically includes M2M, which may not be a requirement of *all* SD mechanisms. > - Some of the requirements will be hard to fulfill, if taken literally: > REQ9: SSD should operate efficiently on common link layers and link > types. > > Are you suggesting we should remove REQ9? I think this specifically relates to reducing the dependence on multicast. > REQ12: SSD should enable a way to provide a consistent user > experience whether local or remote services are being > discovered. > > I agree; this one seems hard. But I still think we should try to satisfy it. > - Very surprised that the Security Considerations don't lead to formal > requirements > For example, in connection with "6.1 Scope of Discovery" and "6.5 Access > Control", I was expecting a requirement such as > REQXX: the owner of the advertised service must be able to configure > whether his service should be advertised beyond the local link > > I think you make a good point. As I read REQ1 & REQ2, it seems that in a typical multi-subnet residential case the user might have to take some action to make a service visible beyond the local link or site. OTOH, it might be a good idea to explicitly say that a user must OPT-IN to global advertisements. BTW, I believe it's in plan to produce a separate threat analysis document which may help clarify additional requirements. Regards, Kerry Lynn > The way the requirements are specified: all services will be visible to > everybody, and the access control will accept/reject the service request. > That reminds me of the typical airport wireless situation: you try every > wireless network to see which one will accept you. > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --001a113e4f8c47040f051131856f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 12, 2015 at 10:12 AM, Benoit Claise <bclaise= @cisco.com> wrote:
Benoit Claise has entered t= he following ballot position for
draft-ietf-dnssd-requirements-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirem= ents/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The IETF should definitively focus on this problem space. Thanks.

Some comments below:

- I agree with Martin's comment.

As do I.
=C2=A0
- Section 4, REQ8 looks a very fundemental requirement for all service
discovery mechanism. It does not look like a specific requirement for
SSD

Are you suggesting we should remove REQ8?=C2=A0 This = specifically includes
M2M, which may not be a requirement of = *all* SD mechanisms.
=C2=A0
- Some of the requirements will be hard to fulfill, if taken literally:
=C2=A0 =C2=A0REQ9:=C2=A0 =C2=A0SSD should operate efficiently on common lin= k layers and link
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0types.

Are you suggesting we should remove REQ9?=C2=A0 I thi= nk this specifically relates
to reducing the dependence on mu= lticast.
=C2=A0
=C2=A0 =C2=A0REQ12:=C2=A0 SSD should enable a way to provide a consistent u= ser
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0experience whether local or remote= services are being
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0discovered.

I agree; this one seems hard.=C2=A0 But I still think= we should try to satisfy it.
=C2=A0
- Very surprised that the Security Considerations don't lead to formal<= br> requirements
For example, in connection with "6.1 Scope of Discovery" and &quo= t;6.5 Access
Control", I was expecting a requirement such as
=C2=A0 =C2=A0REQXX:=C2=A0 the owner of the advertised service must be able = to configure
whether his service should be advertised beyond the local link

I think you make a good point.=C2=A0 As I read REQ1 &= amp; REQ2, it seems that in a
typical multi-subnet residentia= l case the user might have to take some action
to make a serv= ice visible beyond the local link or site.=C2=A0 OTOH, it might be a
good idea to explicitly say that a user must OPT-IN to global adver= tisements.

BTW, I believe it's in plan to produce a s= eparate threat analysis document
which may help clarify addit= ional requirements.

Regards, Kerry Lynn
=C2= =A0
The way the requirements are specified: all services will be visible to
everybody, and the access control will accept/reject the service request. That reminds me of the typical airport wireless situation: you try every wireless network to see which one will accept you.


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

--001a113e4f8c47040f051131856f-- From nobody Fri Mar 13 13:41:54 2015 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 E653D1A7003; Fri, 13 Mar 2015 13:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 nrKP8NsQ2Koy; Fri, 13 Mar 2015 13:41:17 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4381A7007; Fri, 13 Mar 2015 13:41:17 -0700 (PDT) Received: by obcvb8 with SMTP id vb8so22195450obc.10; Fri, 13 Mar 2015 13:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kB1PHIR8oIWWSBvXyB0rON/xW4YGJsfAZrwErOq1FUE=; b=IoyzSk1GGZi1JuSmVbdXHRfd5W4pLlfJTougdFGsyYutYVDw3BdrD+D555/unT8HNL sZGfOYVtXcUEZZTYl9iCERi5R+UNpocScDAPU8m5Eb97vAB8ZLktAObB4SS6QAlE/buO BbVM32VCcFnZ0S8U0rTBMBEM/r+q9/yuJc5+CeIiPD0tt9kKZhtFcv1C7D3gNc5AT9iH cFX2p0KpUmncFzLMpoS2rMcu2mXdzlld/tuJAQyIG+LqGmRDahJ3JblIOp3EhXSa+kcQ N36xWWT+XLKHOiCzgD31UQd9QQygScwKqdNVyciHKAXUFJipIOmFVrhR7+cYmg8Xo9B+ PExg== MIME-Version: 1.0 X-Received: by 10.182.119.232 with SMTP id kx8mr5969obb.37.1426279276963; Fri, 13 Mar 2015 13:41:16 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.11.136 with HTTP; Fri, 13 Mar 2015 13:41:16 -0700 (PDT) In-Reply-To: <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> Date: Fri, 13 Mar 2015 16:41:16 -0400 X-Google-Sender-Auth: S_Wmd9aEg4j1l_RUF5hk8YyKqIE Message-ID: From: Kerry Lynn To: Douglas Otis Content-Type: multipart/alternative; boundary=001a11c2f43aa76eaa051131859c Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Tim Chown , The IESG , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 13 Mar 2015 20:41:20 -0000 --001a11c2f43aa76eaa051131859c Content-Type: text/plain; charset=UTF-8 On Thu, Mar 12, 2015 at 2:24 PM, Douglas Otis wrote: > > > On Mar 10, 2015, at 4:04 PM, Stephen Farrell > wrote: > > > > Stephen Farrell has entered the following ballot position for > > draft-ietf-dnssd-requirements-05: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > > - section 6 intro: I'm not sure I buy that the set of relevant > > threats is only a union as stated. There are often new threats > > in new environments. > > > The current text reads "likely to include the union...", not "only the union..." > - 6.6: I think one can also leak private information by > > searching in too broad a scope, e.g. if the client can be > > fingerprinted allowing re-identification. I think that's > > different from the example given, and maybe worth noting too. > > The current plan is to produce a separate security threats document; see https://tools.ietf.org/id/draft-rafiee-dnssd-mdns-threatmodel-01.txt. We will make sure to include this issue (although I'm not sure at this point if/how a DNS-SD query would differ significantly from a DNS query in that respect). I feel that the current Requirements draft represents a consensus of the WG (but not unanimity, as can be seen below): Dear Stephen, > > I agree with your statement and, based on our tests, these concerns are > very real! > > IPv6 can not be defended in the same manner as with IPv4. With Homenet, an > effort was made to ensure address selection preferences critical when > publishing addresses within DNS but omitted from the requirements > documents. > > Doug, can your concern be addressed by specifically stating a requirement that advertising a service in the global internet should be an opt-in decision of the user, as suggested by Benoit? > > The statement made in Section 6.1 is poorly considered. > ,-- > Section 6.1 > ... > Note that discovery of a service does not necessarily imply that the > service is reachable by, or can be connected to, or can be used by, a > given client. Specific access control mechanisms are out of scope of > this document. > '--- > > Let's take these "poorly considered" assertions one-by-one: - reachable (a route may not exist to the advertised address) - connected to (the device may be offline) - used by (the user of the service may lack authorization) - access control is out of scope (not in our charter) Which of these do you specifically have an issue with? Or the false statement: > ,-- > 6.5. Access Control > ... > While controlling access to an advertised service is outside the > scope of DNS-SD, we note that access control today often is provided > by existing site infrastructure (e.g., router access control lists, > firewalls) and/or by service-specific mechanisms (e.g., user > authentication to the service). For example, networked printers can > control access via a user-id and password. Apple's software supports > such access control for USB printers shared via Mac OS X Printer > Sharing, as do many networked printers themselves. So the reliance > on existing service-specific security mechanisms (i.e. outside the > scope of DNS-SD) does not create new security considerations. > '--- > > Most printers DO NOT offer user-id/password access mechanisms and often > IPv6 support removes access control lists. Homenet and Apples BTMM > make use of an important overlay approach being ignored both here and with > the the insecure UPnP. For this protocol to safely interoperate, an > overlay approach must be supported. This approach might use ULAs, for > example. For this to work properly, locally defined addresses must be > preferred when publishing in DNS. > > As previously presented, it is minor fix to correct this oversight. > > Doug, you have had ample opportunity to argue your position before the WG and again during WGLC. Your concern has been duly noted, but it is not the consensus of the WG to mandate a particular solution in an *informative* requirements draft. To your point about specific devices lacking access control mechanisms, my personal response would be to a) mitigate that problem with an appliance (such as described in http://spectrum.ieee.org/telecom/security/how-to-build-a-safer-internet-of-things ), b) put it behind a device that implements access control (e.g. a Mac- or PC-to- USB print server), c) get a printer that supports access control (yes, they do exist), or d) don't advertise the service beyond the local link. Note that in the topologies we're specifically targeting (enterprise, higher ed) implementing an overlay is no guarantee that an adversary with access to the network won't be able to use your consumables (ink & paper). Regards, Kerry Lynn Regards, > Douglas Otis > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --001a11c2f43aa76eaa051131859c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 12, 2015 at 2:24 PM, Douglas Otis <doug.m= tview@gmail.com> wrote:
=

> On Mar 10, 2015, at 4:04 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>= wrote:
>
> Stephen Farrell has entered the following ballot position for
> draft-ietf-dnssd-requirements-05: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss= -criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-req= uirements/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
>
> - section 6 intro: I'm not sure I buy that the set of relevant
> threats is only a union as stated. There are often new threats
> in new environments.
>
<KEL> The current text reads &q= uot;likely to include the union...", not "only the union..."=

=
> - 6.6: I think one can also leak private information by
> searching in too broad a scope, e.g. if the client can be
> fingerprinted allowing re-identification. I think that's
> different from the example given, and maybe worth noting too.

<KEL> The current plan is to produc= e a separate security threats document; see
http= s://tools.ietf.org/id/draft-rafiee-dnssd-mdns-threatmodel-01.txt.=C2=A0= We will make
sure to include this issue (although I'm no= t sure at this point if/how a DNS-SD
query would differ signi= ficantly from a DNS query in that respect).

I feel that t= he current Requirements draft represents a consensus of the WG (but
not unanimity, as can be seen below):

Dear Stephen,

I agree with your statement and, based on our tests, these concerns are ver= y real!

IPv6 can not be defended in the same manner as with IPv4.=C2=A0 With Homene= t, an
effort was made to ensure address selection preferences critical when
publishing addresses within DNS but omitted from the requirements documents= .

<KEL> Doug, can your concern be addressed by sp= ecifically stating a requirement
that advertising a service i= n the global internet should be an opt-in decision of the
use= r, as suggested by Benoit?

The statement made in Section 6.1 is poorly considered.
,--
Section 6.1
=C2=A0...
=C2=A0Note that discovery of a service does not necessarily imply that the<= br> =C2=A0service is reachable by, or can be connected to, or can be used by, a=
=C2=A0given client.=C2=A0 Specific access control mechanisms are out of sco= pe of
=C2=A0this document.
'---

<KEL> Let's take these "poorly conside= red" assertions one-by-one:
=C2=A0 - reachable (a route = may not exist to the advertised address)
=C2=A0 - connected t= o (the device may be offline)
=C2=A0 - used by (the user of t= he service may lack authorization)
=C2=A0 - access control is= out of scope (not in our charter)
Which of these do you spec= ifically have an issue with?

Or the false statement:
,--
6.5.=C2=A0 Access Control
=C2=A0...
=C2=A0While controlling access to an advertised service is outside the
=C2=A0scope of DNS-SD, we note that access control today often is provided<= br> =C2=A0by existing site infrastructure (e.g., router access control lists, =C2=A0firewalls) and/or by service-specific mechanisms (e.g., user
=C2=A0authentication to the service).=C2=A0 For example, networked printers= can
=C2=A0control access via a user-id and password.=C2=A0 Apple's software= supports
=C2=A0such access control for USB printers shared via Mac OS X Printer
=C2=A0Sharing, as do many networked printers themselves.=C2=A0 So the relia= nce
=C2=A0on existing service-specific security mechanisms (i.e. outside the =C2=A0scope of DNS-SD) does not create new security considerations.
'---

Most printers DO NOT offer user-id/password access mechanisms and often
IPv6 support removes access control lists.=C2=A0 Homenet and Apples BTMM make use of an important overlay approach being ignored both here and with<= br> the the insecure UPnP. For this protocol to safely interoperate, an
overlay approach must be supported.=C2=A0 This approach might use ULAs, for=
example. For this to work properly, locally defined addresses must be
preferred when publishing in DNS.

As previously presented, it is minor fix to correct this oversight.

<KEL> Doug, you have had ample opportunity to a= rgue your position before
the WG and again during WGLC.=C2=A0= Your concern has been duly noted, but it
is not the consensu= s of the WG to mandate a particular solution in an
*informati= ve* requirements draft.

To your point about specific devi= ces lacking access control mechanisms, my
personal response w= ould be to a) mitigate that problem with an appliance (such
<= div>b) put it behind a device that implements access control (e.g. a Mac- o= r PC-to-
USB print server), c) get a printer that supports ac= cess control (yes, they do exist),
or d) don't advertise = the service beyond the local link.

Note that in the topol= ogies we're specifically targeting (enterprise, higher ed)
implementing an overlay is no guarantee that an adversary with access to = the
network won't be able to use your consumables (ink &a= mp; paper).

Regards, Kerry Lynn

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

--001a11c2f43aa76eaa051131859c-- From nobody Fri Mar 13 13:41:55 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1FD4B1A7014; Fri, 13 Mar 2015 13:41:20 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E653D1A7003; Fri, 13 Mar 2015 13:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.027 X-Spam-Level: X-Spam-Status: No, score=-1.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, 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 nrKP8NsQ2Koy; Fri, 13 Mar 2015 13:41:17 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4381A7007; Fri, 13 Mar 2015 13:41:17 -0700 (PDT) Received: by obcvb8 with SMTP id vb8so22195450obc.10; Fri, 13 Mar 2015 13:41:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=kB1PHIR8oIWWSBvXyB0rON/xW4YGJsfAZrwErOq1FUE=; b=IoyzSk1GGZi1JuSmVbdXHRfd5W4pLlfJTougdFGsyYutYVDw3BdrD+D555/unT8HNL sZGfOYVtXcUEZZTYl9iCERi5R+UNpocScDAPU8m5Eb97vAB8ZLktAObB4SS6QAlE/buO BbVM32VCcFnZ0S8U0rTBMBEM/r+q9/yuJc5+CeIiPD0tt9kKZhtFcv1C7D3gNc5AT9iH cFX2p0KpUmncFzLMpoS2rMcu2mXdzlld/tuJAQyIG+LqGmRDahJ3JblIOp3EhXSa+kcQ N36xWWT+XLKHOiCzgD31UQd9QQygScwKqdNVyciHKAXUFJipIOmFVrhR7+cYmg8Xo9B+ PExg== MIME-Version: 1.0 X-Received: by 10.182.119.232 with SMTP id kx8mr5969obb.37.1426279276963; Fri, 13 Mar 2015 13:41:16 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.11.136 with HTTP; Fri, 13 Mar 2015 13:41:16 -0700 (PDT) In-Reply-To: <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> Date: Fri, 13 Mar 2015 16:41:16 -0400 X-Google-Sender-Auth: S_Wmd9aEg4j1l_RUF5hk8YyKqIE Message-ID: From: Kerry Lynn To: Douglas Otis Content-Type: multipart/alternative; boundary=001a11c2f43aa76eaa051131859c Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Tim Chown , The IESG , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 13 Mar 2015 20:41:20 -0000 --001a11c2f43aa76eaa051131859c Content-Type: text/plain; charset=UTF-8 On Thu, Mar 12, 2015 at 2:24 PM, Douglas Otis wrote: > > > On Mar 10, 2015, at 4:04 PM, Stephen Farrell > wrote: > > > > Stephen Farrell has entered the following ballot position for > > draft-ietf-dnssd-requirements-05: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > > > - section 6 intro: I'm not sure I buy that the set of relevant > > threats is only a union as stated. There are often new threats > > in new environments. > > > The current text reads "likely to include the union...", not "only the union..." > - 6.6: I think one can also leak private information by > > searching in too broad a scope, e.g. if the client can be > > fingerprinted allowing re-identification. I think that's > > different from the example given, and maybe worth noting too. > > The current plan is to produce a separate security threats document; see https://tools.ietf.org/id/draft-rafiee-dnssd-mdns-threatmodel-01.txt. We will make sure to include this issue (although I'm not sure at this point if/how a DNS-SD query would differ significantly from a DNS query in that respect). I feel that the current Requirements draft represents a consensus of the WG (but not unanimity, as can be seen below): Dear Stephen, > > I agree with your statement and, based on our tests, these concerns are > very real! > > IPv6 can not be defended in the same manner as with IPv4. With Homenet, an > effort was made to ensure address selection preferences critical when > publishing addresses within DNS but omitted from the requirements > documents. > > Doug, can your concern be addressed by specifically stating a requirement that advertising a service in the global internet should be an opt-in decision of the user, as suggested by Benoit? > > The statement made in Section 6.1 is poorly considered. > ,-- > Section 6.1 > ... > Note that discovery of a service does not necessarily imply that the > service is reachable by, or can be connected to, or can be used by, a > given client. Specific access control mechanisms are out of scope of > this document. > '--- > > Let's take these "poorly considered" assertions one-by-one: - reachable (a route may not exist to the advertised address) - connected to (the device may be offline) - used by (the user of the service may lack authorization) - access control is out of scope (not in our charter) Which of these do you specifically have an issue with? Or the false statement: > ,-- > 6.5. Access Control > ... > While controlling access to an advertised service is outside the > scope of DNS-SD, we note that access control today often is provided > by existing site infrastructure (e.g., router access control lists, > firewalls) and/or by service-specific mechanisms (e.g., user > authentication to the service). For example, networked printers can > control access via a user-id and password. Apple's software supports > such access control for USB printers shared via Mac OS X Printer > Sharing, as do many networked printers themselves. So the reliance > on existing service-specific security mechanisms (i.e. outside the > scope of DNS-SD) does not create new security considerations. > '--- > > Most printers DO NOT offer user-id/password access mechanisms and often > IPv6 support removes access control lists. Homenet and Apples BTMM > make use of an important overlay approach being ignored both here and with > the the insecure UPnP. For this protocol to safely interoperate, an > overlay approach must be supported. This approach might use ULAs, for > example. For this to work properly, locally defined addresses must be > preferred when publishing in DNS. > > As previously presented, it is minor fix to correct this oversight. > > Doug, you have had ample opportunity to argue your position before the WG and again during WGLC. Your concern has been duly noted, but it is not the consensus of the WG to mandate a particular solution in an *informative* requirements draft. To your point about specific devices lacking access control mechanisms, my personal response would be to a) mitigate that problem with an appliance (such as described in http://spectrum.ieee.org/telecom/security/how-to-build-a-safer-internet-of-things ), b) put it behind a device that implements access control (e.g. a Mac- or PC-to- USB print server), c) get a printer that supports access control (yes, they do exist), or d) don't advertise the service beyond the local link. Note that in the topologies we're specifically targeting (enterprise, higher ed) implementing an overlay is no guarantee that an adversary with access to the network won't be able to use your consumables (ink & paper). Regards, Kerry Lynn Regards, > Douglas Otis > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --001a11c2f43aa76eaa051131859c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 12, 2015 at 2:24 PM, Douglas Otis <doug.m= tview@gmail.com> wrote:
=

> On Mar 10, 2015, at 4:04 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>= wrote:
>
> Stephen Farrell has entered the following ballot position for
> draft-ietf-dnssd-requirements-05: No Objection
>
> When responding, please keep the subject line intact and reply to all<= br> > email addresses included in the To and CC lines. (Feel free to cut thi= s
> introductory paragraph, however.)
>
>
> Please refer to http://www.ietf.org/iesg/statement/discuss= -criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-req= uirements/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
>
> - section 6 intro: I'm not sure I buy that the set of relevant
> threats is only a union as stated. There are often new threats
> in new environments.
>
<KEL> The current text reads &q= uot;likely to include the union...", not "only the union..."=

=
> - 6.6: I think one can also leak private information by
> searching in too broad a scope, e.g. if the client can be
> fingerprinted allowing re-identification. I think that's
> different from the example given, and maybe worth noting too.

<KEL> The current plan is to produc= e a separate security threats document; see
http= s://tools.ietf.org/id/draft-rafiee-dnssd-mdns-threatmodel-01.txt.=C2=A0= We will make
sure to include this issue (although I'm no= t sure at this point if/how a DNS-SD
query would differ signi= ficantly from a DNS query in that respect).

I feel that t= he current Requirements draft represents a consensus of the WG (but
not unanimity, as can be seen below):

Dear Stephen,

I agree with your statement and, based on our tests, these concerns are ver= y real!

IPv6 can not be defended in the same manner as with IPv4.=C2=A0 With Homene= t, an
effort was made to ensure address selection preferences critical when
publishing addresses within DNS but omitted from the requirements documents= .

<KEL> Doug, can your concern be addressed by sp= ecifically stating a requirement
that advertising a service i= n the global internet should be an opt-in decision of the
use= r, as suggested by Benoit?

The statement made in Section 6.1 is poorly considered.
,--
Section 6.1
=C2=A0...
=C2=A0Note that discovery of a service does not necessarily imply that the<= br> =C2=A0service is reachable by, or can be connected to, or can be used by, a=
=C2=A0given client.=C2=A0 Specific access control mechanisms are out of sco= pe of
=C2=A0this document.
'---

<KEL> Let's take these "poorly conside= red" assertions one-by-one:
=C2=A0 - reachable (a route = may not exist to the advertised address)
=C2=A0 - connected t= o (the device may be offline)
=C2=A0 - used by (the user of t= he service may lack authorization)
=C2=A0 - access control is= out of scope (not in our charter)
Which of these do you spec= ifically have an issue with?

Or the false statement:
,--
6.5.=C2=A0 Access Control
=C2=A0...
=C2=A0While controlling access to an advertised service is outside the
=C2=A0scope of DNS-SD, we note that access control today often is provided<= br> =C2=A0by existing site infrastructure (e.g., router access control lists, =C2=A0firewalls) and/or by service-specific mechanisms (e.g., user
=C2=A0authentication to the service).=C2=A0 For example, networked printers= can
=C2=A0control access via a user-id and password.=C2=A0 Apple's software= supports
=C2=A0such access control for USB printers shared via Mac OS X Printer
=C2=A0Sharing, as do many networked printers themselves.=C2=A0 So the relia= nce
=C2=A0on existing service-specific security mechanisms (i.e. outside the =C2=A0scope of DNS-SD) does not create new security considerations.
'---

Most printers DO NOT offer user-id/password access mechanisms and often
IPv6 support removes access control lists.=C2=A0 Homenet and Apples BTMM make use of an important overlay approach being ignored both here and with<= br> the the insecure UPnP. For this protocol to safely interoperate, an
overlay approach must be supported.=C2=A0 This approach might use ULAs, for=
example. For this to work properly, locally defined addresses must be
preferred when publishing in DNS.

As previously presented, it is minor fix to correct this oversight.

<KEL> Doug, you have had ample opportunity to a= rgue your position before
the WG and again during WGLC.=C2=A0= Your concern has been duly noted, but it
is not the consensu= s of the WG to mandate a particular solution in an
*informati= ve* requirements draft.

To your point about specific devi= ces lacking access control mechanisms, my
personal response w= ould be to a) mitigate that problem with an appliance (such
<= div>b) put it behind a device that implements access control (e.g. a Mac- o= r PC-to-
USB print server), c) get a printer that supports ac= cess control (yes, they do exist),
or d) don't advertise = the service beyond the local link.

Note that in the topol= ogies we're specifically targeting (enterprise, higher ed)
implementing an overlay is no guarantee that an adversary with access to = the
network won't be able to use your consumables (ink &a= mp; paper).

Regards, Kerry Lynn

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

--001a11c2f43aa76eaa051131859c-- From nobody Fri Mar 13 13:41:56 2015 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 65AFC1A6F11; Fri, 13 Mar 2015 13:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 Db9Xx1AdrtFF; Fri, 13 Mar 2015 13:41:24 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FCC1A86E4; Fri, 13 Mar 2015 13:41:23 -0700 (PDT) Received: by oifz81 with SMTP id z81so3777477oif.13; Fri, 13 Mar 2015 13:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h+RsLR6uPIcP/GRiCjaATOdUrVuJ9gRodY4I/33VmDY=; b=N42ovGXvBWXIKMISsmQ/J+xT9YwGr74EsVLR61IVRVBQSAdWXktO8UP0iq+bQksJuB zvhKB9lNweGIy9tu8APzNoBJIJVey8tPQcwcyxZxkC0daFLQcUZpcDJExK4h6122PTxP +h1NTrPskxOXoNN20hNtAU/AUNa46tMtLnC/3htF7K7P3UUOx4GRFJaa9cIq1jpz9scW nvVS+U961aLBJpK8+aOOkaShFeXDnpgZnrBXCNoQBz201zgyYNW+8DOt7NbPwgKCu2+S 0475CpY8g3Jr02OnVwu9F4wrr1gfHmaZQLHtwommaA4fYFTRbmPfWPpyTkHs7Jrjl+8c mgqA== MIME-Version: 1.0 X-Received: by 10.202.168.15 with SMTP id r15mr7063293oie.92.1426279283017; Fri, 13 Mar 2015 13:41:23 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.11.136 with HTTP; Fri, 13 Mar 2015 13:41:22 -0700 (PDT) In-Reply-To: <20150313174749.2435.7999.idtracker@ietfa.amsl.com> References: <20150313174749.2435.7999.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 16:41:22 -0400 X-Google-Sender-Auth: 5woBakU7ZlfH5_VcWrDn6KgKavA Message-ID: From: Kerry Lynn To: Pete Resnick Content-Type: multipart/alternative; boundary=001a113c328c03cde105113186c4 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , Tim Chown Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 13 Mar 2015 20:41:29 -0000 --001a113c328c03cde105113186c4 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick wrote: > Pete Resnick has entered the following ballot position for > draft-ietf-dnssd-requirements-05: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > [Updating to reflect that the IPR disclosure issue is addressed. There is > an IPR disclosure that appears for this document, but it was a mistakenly > filed disclosure that still remains in the system. We will deal with that > issue separately.] > > Section 5: > > OLD > Devices on different links may have the same mDNS name (perhaps due > to vendor defaults), because link-local mDNS names are only > guaranteed to be unique on a per-link basis. Also, even devices that > are on the same link may have similar-looking names, such as one > device with the name "Bill" and another device using the similar- > looking name "Bi11" (using the digit "1" in place of the letter "l"). > This may lead to a local label disambiguation problem between > presented results. > > SSD should support rich internationalized labels within Service > Instance Names, as DNS-SD/mDNS does today. SSD must not negatively > impact the global DNS namespace or infrastructure. > > The part about name collisions is fine, and should be said. The part > about disambiguating similar characters is a rat's nest I really think > you need to avoid. We can discuss this further, but the i18n community is > dealing with this issue right now and it's a mess you really don't want > to get into. I think you should simply stick to something like this: > > NEW > Devices on different links may have the same mDNS name (perhaps due > to vendor defaults), because link-local mDNS names are only > guaranteed to be unique on a per-link basis. SSD needs to deal with > name collisions beyond local link considerations. > > SSD should support rich internationalized labels within Service > Instance Names, as DNS-SD/mDNS does today and should look to work in > using internationalize strings in application protocols > [soon-to-be-RFC-draft-ietf-precis-framework]. SSD must not > negatively impact the global DNS namespace or infrastructure. > > Hi Pete, This draft is now more than a year late, due in part to much discussion about the differences between DNS-SD/mDNS and DNS (IDNA2008) name spaces. Looking back at our charter, we have a requirement To document challenges and problems encountered in the coexistence of zero configuration and global DNS name services in such multi-link networks, including consideration of both the name resolution mechanism and the namespace. without necessarily proposing a solution (however, the latter may ultimately come about via https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-00). The language you have flagged was inserted during WGLC in response to one very vocal critic and addresses, I believe, a different problem. It is often the case that DNS-SD/mDNS query results are displayed to the user through the UI. The OLD language simply notes that various, otherwise legal, names may have a similar appearance (without proposing a solution). If you still find that a change is necessary, I would first ask what we can merely delete. I'm afraid that any additions to this section may require us to go back to the WG for further discussion. Regards, Kerry Lynn --001a113c328c03cde105113186c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
Pete Resnick has entered the following ballot position for
draft-ietf-dnssd-requirements-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirem= ents/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[Updating to reflect that the IPR disclosure issue is addressed. There is an IPR disclosure that appears for this document, but it was a mistakenly filed disclosure that still remains in the system. We will deal with that issue separately.]

Section 5:

OLD
=C2=A0 =C2=A0Devices on different links may have the same mDNS name (perhap= s due
=C2=A0 =C2=A0to vendor defaults), because link-local mDNS names are only =C2=A0 =C2=A0guaranteed to be unique on a per-link basis.=C2=A0 Also, even = devices that
=C2=A0 =C2=A0are on the same link may have similar-looking names, such as o= ne
=C2=A0 =C2=A0device with the name "Bill" and another device using= the similar-
=C2=A0 =C2=A0looking name "Bi11" (using the digit "1" i= n place of the letter "l").
=C2=A0 =C2=A0This may lead to a local label disambiguation problem between<= br> =C2=A0 =C2=A0presented results.

=C2=A0 =C2=A0SSD should support rich internationalized labels within Servic= e
=C2=A0 =C2=A0Instance Names, as DNS-SD/mDNS does today.=C2=A0 SSD must not = negatively
=C2=A0 =C2=A0impact the global DNS namespace or infrastructure.

The part about name collisions is fine, and should be said. The part
about disambiguating similar characters is a rat's nest I really think<= br> you need to avoid. We can discuss this further, but the i18n community is dealing with this issue right now and it's a mess you really don't = want
to get into. I think you should simply stick to something like this:

NEW
=C2=A0 =C2=A0Devices on different links may have the same mDNS name (perhap= s due
=C2=A0 =C2=A0to vendor defaults), because link-local mDNS names are only =C2=A0 =C2=A0guaranteed to be unique on a per-link basis. SSD needs to deal= with
=C2=A0 =C2=A0name collisions beyond local link considerations.

=C2=A0 =C2=A0SSD should support rich internationalized labels within Servic= e
=C2=A0 =C2=A0Instance Names, as DNS-SD/mDNS does today and should look to w= ork in
=C2=A0 =C2=A0using internationalize strings in application protocols
=C2=A0 =C2=A0[soon-to-be-RFC-draft-ietf-precis-framework].=C2=A0 SSD must n= ot
=C2=A0 =C2=A0negatively impact the global DNS namespace or infrastructure.<= br>
Hi Pete,

This draft is now more tha= n a year late, due in part to much discussion about
the diffe= rences between DNS-SD/mDNS and DNS (IDNA2008) name spaces.
Lo= oking back at our charter, we have a requirement
To document challe=
nges and problems encountered in the coexistence
of zero configuration and global DNS name services in such
multi-link networks, including consideration of both the name
resolution mechanism and the namespace.
without necessarily proposing= a solution (however, the latter may ultimately come
The language you have flagged was inser= ted during WGLC in response to one
very vocal critic and addr= esses, I believe, a different problem.=C2=A0 It is often the
= case that DNS-SD/mDNS query results are displayed to the user through the
UI.=C2=A0 The OLD language simply notes that various, otherwis= e legal, names may
have a similar appearance (without proposi= ng a solution).

If you still find that a change is necess= ary, I would first ask what we can merely
delete.=C2=A0 I'm afraid t= hat any additions to this section may require us to go back to
the WG fo= r further discussion.

Regards, Kerry Lynn
=
--001a113c328c03cde105113186c4-- From nobody Fri Mar 13 13:42:04 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A77731A7004; Fri, 13 Mar 2015 13:41:29 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65AFC1A6F11; Fri, 13 Mar 2015 13:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 Db9Xx1AdrtFF; Fri, 13 Mar 2015 13:41:24 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FCC1A86E4; Fri, 13 Mar 2015 13:41:23 -0700 (PDT) Received: by oifz81 with SMTP id z81so3777477oif.13; Fri, 13 Mar 2015 13:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=h+RsLR6uPIcP/GRiCjaATOdUrVuJ9gRodY4I/33VmDY=; b=N42ovGXvBWXIKMISsmQ/J+xT9YwGr74EsVLR61IVRVBQSAdWXktO8UP0iq+bQksJuB zvhKB9lNweGIy9tu8APzNoBJIJVey8tPQcwcyxZxkC0daFLQcUZpcDJExK4h6122PTxP +h1NTrPskxOXoNN20hNtAU/AUNa46tMtLnC/3htF7K7P3UUOx4GRFJaa9cIq1jpz9scW nvVS+U961aLBJpK8+aOOkaShFeXDnpgZnrBXCNoQBz201zgyYNW+8DOt7NbPwgKCu2+S 0475CpY8g3Jr02OnVwu9F4wrr1gfHmaZQLHtwommaA4fYFTRbmPfWPpyTkHs7Jrjl+8c mgqA== MIME-Version: 1.0 X-Received: by 10.202.168.15 with SMTP id r15mr7063293oie.92.1426279283017; Fri, 13 Mar 2015 13:41:23 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.11.136 with HTTP; Fri, 13 Mar 2015 13:41:22 -0700 (PDT) In-Reply-To: <20150313174749.2435.7999.idtracker@ietfa.amsl.com> References: <20150313174749.2435.7999.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 16:41:22 -0400 X-Google-Sender-Auth: 5woBakU7ZlfH5_VcWrDn6KgKavA Message-ID: From: Kerry Lynn To: Pete Resnick Content-Type: multipart/alternative; boundary=001a113c328c03cde105113186c4 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , Tim Chown Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 13 Mar 2015 20:41:29 -0000 --001a113c328c03cde105113186c4 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick wrote: > Pete Resnick has entered the following ballot position for > draft-ietf-dnssd-requirements-05: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > [Updating to reflect that the IPR disclosure issue is addressed. There is > an IPR disclosure that appears for this document, but it was a mistakenly > filed disclosure that still remains in the system. We will deal with that > issue separately.] > > Section 5: > > OLD > Devices on different links may have the same mDNS name (perhaps due > to vendor defaults), because link-local mDNS names are only > guaranteed to be unique on a per-link basis. Also, even devices that > are on the same link may have similar-looking names, such as one > device with the name "Bill" and another device using the similar- > looking name "Bi11" (using the digit "1" in place of the letter "l"). > This may lead to a local label disambiguation problem between > presented results. > > SSD should support rich internationalized labels within Service > Instance Names, as DNS-SD/mDNS does today. SSD must not negatively > impact the global DNS namespace or infrastructure. > > The part about name collisions is fine, and should be said. The part > about disambiguating similar characters is a rat's nest I really think > you need to avoid. We can discuss this further, but the i18n community is > dealing with this issue right now and it's a mess you really don't want > to get into. I think you should simply stick to something like this: > > NEW > Devices on different links may have the same mDNS name (perhaps due > to vendor defaults), because link-local mDNS names are only > guaranteed to be unique on a per-link basis. SSD needs to deal with > name collisions beyond local link considerations. > > SSD should support rich internationalized labels within Service > Instance Names, as DNS-SD/mDNS does today and should look to work in > using internationalize strings in application protocols > [soon-to-be-RFC-draft-ietf-precis-framework]. SSD must not > negatively impact the global DNS namespace or infrastructure. > > Hi Pete, This draft is now more than a year late, due in part to much discussion about the differences between DNS-SD/mDNS and DNS (IDNA2008) name spaces. Looking back at our charter, we have a requirement To document challenges and problems encountered in the coexistence of zero configuration and global DNS name services in such multi-link networks, including consideration of both the name resolution mechanism and the namespace. without necessarily proposing a solution (however, the latter may ultimately come about via https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-00). The language you have flagged was inserted during WGLC in response to one very vocal critic and addresses, I believe, a different problem. It is often the case that DNS-SD/mDNS query results are displayed to the user through the UI. The OLD language simply notes that various, otherwise legal, names may have a similar appearance (without proposing a solution). If you still find that a change is necessary, I would first ask what we can merely delete. I'm afraid that any additions to this section may require us to go back to the WG for further discussion. Regards, Kerry Lynn --001a113c328c03cde105113186c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick <pr= esnick@qti.qualcomm.com> wrote:
Pete Resnick has entered the following ballot position for
draft-ietf-dnssd-requirements-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirem= ents/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[Updating to reflect that the IPR disclosure issue is addressed. There is an IPR disclosure that appears for this document, but it was a mistakenly filed disclosure that still remains in the system. We will deal with that issue separately.]

Section 5:

OLD
=C2=A0 =C2=A0Devices on different links may have the same mDNS name (perhap= s due
=C2=A0 =C2=A0to vendor defaults), because link-local mDNS names are only =C2=A0 =C2=A0guaranteed to be unique on a per-link basis.=C2=A0 Also, even = devices that
=C2=A0 =C2=A0are on the same link may have similar-looking names, such as o= ne
=C2=A0 =C2=A0device with the name "Bill" and another device using= the similar-
=C2=A0 =C2=A0looking name "Bi11" (using the digit "1" i= n place of the letter "l").
=C2=A0 =C2=A0This may lead to a local label disambiguation problem between<= br> =C2=A0 =C2=A0presented results.

=C2=A0 =C2=A0SSD should support rich internationalized labels within Servic= e
=C2=A0 =C2=A0Instance Names, as DNS-SD/mDNS does today.=C2=A0 SSD must not = negatively
=C2=A0 =C2=A0impact the global DNS namespace or infrastructure.

The part about name collisions is fine, and should be said. The part
about disambiguating similar characters is a rat's nest I really think<= br> you need to avoid. We can discuss this further, but the i18n community is dealing with this issue right now and it's a mess you really don't = want
to get into. I think you should simply stick to something like this:

NEW
=C2=A0 =C2=A0Devices on different links may have the same mDNS name (perhap= s due
=C2=A0 =C2=A0to vendor defaults), because link-local mDNS names are only =C2=A0 =C2=A0guaranteed to be unique on a per-link basis. SSD needs to deal= with
=C2=A0 =C2=A0name collisions beyond local link considerations.

=C2=A0 =C2=A0SSD should support rich internationalized labels within Servic= e
=C2=A0 =C2=A0Instance Names, as DNS-SD/mDNS does today and should look to w= ork in
=C2=A0 =C2=A0using internationalize strings in application protocols
=C2=A0 =C2=A0[soon-to-be-RFC-draft-ietf-precis-framework].=C2=A0 SSD must n= ot
=C2=A0 =C2=A0negatively impact the global DNS namespace or infrastructure.<= br>
Hi Pete,

This draft is now more tha= n a year late, due in part to much discussion about
the diffe= rences between DNS-SD/mDNS and DNS (IDNA2008) name spaces.
Lo= oking back at our charter, we have a requirement
To document challe=
nges and problems encountered in the coexistence
of zero configuration and global DNS name services in such
multi-link networks, including consideration of both the name
resolution mechanism and the namespace.
without necessarily proposing= a solution (however, the latter may ultimately come
The language you have flagged was inser= ted during WGLC in response to one
very vocal critic and addr= esses, I believe, a different problem.=C2=A0 It is often the
= case that DNS-SD/mDNS query results are displayed to the user through the
UI.=C2=A0 The OLD language simply notes that various, otherwis= e legal, names may
have a similar appearance (without proposi= ng a solution).

If you still find that a change is necess= ary, I would first ask what we can merely
delete.=C2=A0 I'm afraid t= hat any additions to this section may require us to go back to
the WG fo= r further discussion.

Regards, Kerry Lynn
=
--001a113c328c03cde105113186c4-- From nobody Fri Mar 13 15:07:45 2015 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 6EB881A8984; Fri, 13 Mar 2015 15:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 Effqmu1B5Y1G; Fri, 13 Mar 2015 15:07:40 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96271A89A8; Fri, 13 Mar 2015 15:07:39 -0700 (PDT) Received: by obcxo2 with SMTP id xo2so58153obc.0; Fri, 13 Mar 2015 15:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uZ4L+MsVncggvFmLC3GsQ8wVYXIN+oK1Mrj4MhaU79I=; b=SDLDyctghC/Y/JvTvuHmN8VVVORFcGhPz1p3r7jK8TBT9qXE2DnLsGhsUs0S63QBpO 9AY72Xm5fUEApEpHc6TpKfbBxYFhKELl3eMnbpZTPaE/XLDxtV90Escbf4Cs05daAJEF KzICImw2JPCQzWHoXiU462/KJtCk/ii7DXenXz2dUMtbFHxXXPuhqgu6i8zT5eV7AGG3 APBN/WvgjN845P4CPSxQsCyKvVoBnj1BIevv16dmISG+iSrGxLMhA62gclzVCltiI3xE cRkTI1B1lAION2uS+ilEC4QxcLHXmIOtn6uGb14aWM/jnKUoTrsZZK57BsY3dMgSsAyn LOWw== MIME-Version: 1.0 X-Received: by 10.182.241.38 with SMTP id wf6mr40334031obc.81.1426284453889; Fri, 13 Mar 2015 15:07:33 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.11.136 with HTTP; Fri, 13 Mar 2015 15:07:33 -0700 (PDT) In-Reply-To: References: <20150313174749.2435.7999.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 18:07:33 -0400 X-Google-Sender-Auth: T9XUNJ4B-Y7wr92h8HEN583MdRU Message-ID: From: Kerry Lynn To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c30f80390d91051132ba19 Archived-At: Cc: "draft-ietf-dnssd-requirements.all" , dnssd@ietf.org, dnssd-chairs , The IESG , Tim Chown Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 13 Mar 2015 22:07:42 -0000 --001a11c30f80390d91051132ba19 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 13, 2015 at 4:41 PM, Kerry Lynn wrote: > On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick > wrote: > >> Pete Resnick has entered the following ballot position for >> draft-ietf-dnssd-requirements-05: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> [Updating to reflect that the IPR disclosure issue is addressed. There is >> an IPR disclosure that appears for this document, but it was a mistakenly >> filed disclosure that still remains in the system. We will deal with that >> issue separately.] >> >> Section 5: >> >> OLD >> Devices on different links may have the same mDNS name (perhaps due >> to vendor defaults), because link-local mDNS names are only >> guaranteed to be unique on a per-link basis. Also, even devices that >> are on the same link may have similar-looking names, such as one >> device with the name "Bill" and another device using the similar- >> looking name "Bi11" (using the digit "1" in place of the letter "l"). >> This may lead to a local label disambiguation problem between >> presented results. >> >> SSD should support rich internationalized labels within Service >> Instance Names, as DNS-SD/mDNS does today. SSD must not negatively >> impact the global DNS namespace or infrastructure. >> >> The part about name collisions is fine, and should be said. The part >> about disambiguating similar characters is a rat's nest I really think >> you need to avoid. We can discuss this further, but the i18n community is >> dealing with this issue right now and it's a mess you really don't want >> to get into. I think you should simply stick to something like this: >> >> NEW >> Devices on different links may have the same mDNS name (perhaps due >> to vendor defaults), because link-local mDNS names are only >> guaranteed to be unique on a per-link basis. SSD needs to deal with >> name collisions beyond local link considerations. >> >> SSD should support rich internationalized labels within Service >> Instance Names, as DNS-SD/mDNS does today and should look to work in >> using internationalize strings in application protocols >> [soon-to-be-RFC-draft-ietf-precis-framework]. SSD must not >> negatively impact the global DNS namespace or infrastructure. >> >> Hi Pete, > > This draft is now more than a year late, due in part to much discussion > about > the differences between DNS-SD/mDNS and DNS (IDNA2008) name spaces. > Looking back at our charter, we have a requirement > > To document challenges and problems encountered in the coexistence > of zero configuration and global DNS name services in such > multi-link networks, including consideration of both the name > resolution mechanism and the namespace. > > without necessarily proposing a solution (however, the latter may > ultimately come > about via https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-00 > ). > > The language you have flagged was inserted during WGLC in response to one > very vocal critic and addresses, I believe, a different problem. It is > often the > case that DNS-SD/mDNS query results are displayed to the user through the > UI. The OLD language simply notes that various, otherwise legal, names may > have a similar appearance (without proposing a solution). > > If you still find that a change is necessary, I would first ask what we > can merely > delete. I'm afraid that any additions to this section may require us to > go back to > the WG for further discussion. > > Regards, Kerry Lynn > BTW, with the IPR question resolved, did you mean for this to remain a DISCUSS or should it be a COMMENT instead? --001a11c30f80390d91051132ba19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 13, 2015 at 4:41 PM, Kerry Lynn <kerlyn@ieee.or= g> wrote:
On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick <presnick@qti.qual= comm.com> wrote:
Pete Resnick has entered the following ballot positi= on for
draft-ietf-dnssd-requirements-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirem= ents/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[Updating to reflect that the IPR disclosure issue is addressed. There is an IPR disclosure that appears for this document, but it was a mistakenly filed disclosure that still remains in the system. We will deal with that issue separately.]

Section 5:

OLD
=C2=A0 =C2=A0Devices on different links may have the same mDNS name (perhap= s due
=C2=A0 =C2=A0to vendor defaults), because link-local mDNS names are only =C2=A0 =C2=A0guaranteed to be unique on a per-link basis.=C2=A0 Also, even = devices that
=C2=A0 =C2=A0are on the same link may have similar-looking names, such as o= ne
=C2=A0 =C2=A0device with the name "Bill" and another device using= the similar-
=C2=A0 =C2=A0looking name "Bi11" (using the digit "1" i= n place of the letter "l").
=C2=A0 =C2=A0This may lead to a local label disambiguation problem between<= br> =C2=A0 =C2=A0presented results.

=C2=A0 =C2=A0SSD should support rich internationalized labels within Servic= e
=C2=A0 =C2=A0Instance Names, as DNS-SD/mDNS does today.=C2=A0 SSD must not = negatively
=C2=A0 =C2=A0impact the global DNS namespace or infrastructure.

The part about name collisions is fine, and should be said. The part
about disambiguating similar characters is a rat's nest I really think<= br> you need to avoid. We can discuss this further, but the i18n community is dealing with this issue right now and it's a mess you really don't = want
to get into. I think you should simply stick to something like this:

NEW
=C2=A0 =C2=A0Devices on different links may have the same mDNS name (perhap= s due
=C2=A0 =C2=A0to vendor defaults), because link-local mDNS names are only =C2=A0 =C2=A0guaranteed to be unique on a per-link basis. SSD needs to deal= with
=C2=A0 =C2=A0name collisions beyond local link considerations.

=C2=A0 =C2=A0SSD should support rich internationalized labels within Servic= e
=C2=A0 =C2=A0Instance Names, as DNS-SD/mDNS does today and should look to w= ork in
=C2=A0 =C2=A0using internationalize strings in application protocols
=C2=A0 =C2=A0[soon-to-be-RFC-draft-ietf-precis-framework].=C2=A0 SSD must n= ot
=C2=A0 =C2=A0negatively impact the global DNS namespace or infrastructure.<= br>
Hi Pete,

This draft is = now more than a year late, due in part to much discussion about
the differences between DNS-SD/mDNS and DNS (IDNA2008) name spaces.
<= /div>
Looking back at our charter, we have a requirement
To doc=
ument challenges and problems encountered in the coexistence
of zero configuration and global DNS name services in such
multi-link networks, including consideration of both the name
resolution mechanism and the namespace.
without necessarily proposing= a solution (however, the latter may ultimately come
The language you have flagged was inser= ted during WGLC in response to one
very vocal critic and addr= esses, I believe, a different problem.=C2=A0 It is often the
= case that DNS-SD/mDNS query results are displayed to the user through the
UI.=C2=A0 The OLD language simply notes that various, otherwis= e legal, names may
have a similar appearance (without proposi= ng a solution).

If you still find that a change is necess= ary, I would first ask what we can merely
delete.=C2=A0 I'm afraid t= hat any additions to this section may require us to go back to
the WG fo= r further discussion.

Regards, Kerry Lynn
=

BTW, with the IPR question res= olved, did you mean for this to remain a DISCUSS
or should it= be a COMMENT instead?

--001a11c30f80390d91051132ba19-- From nobody Fri Mar 13 15:07:49 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 961851A89AD; Fri, 13 Mar 2015 15:07:42 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB881A8984; Fri, 13 Mar 2015 15:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 Effqmu1B5Y1G; Fri, 13 Mar 2015 15:07:40 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E96271A89A8; Fri, 13 Mar 2015 15:07:39 -0700 (PDT) Received: by obcxo2 with SMTP id xo2so58153obc.0; Fri, 13 Mar 2015 15:07:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=uZ4L+MsVncggvFmLC3GsQ8wVYXIN+oK1Mrj4MhaU79I=; b=SDLDyctghC/Y/JvTvuHmN8VVVORFcGhPz1p3r7jK8TBT9qXE2DnLsGhsUs0S63QBpO 9AY72Xm5fUEApEpHc6TpKfbBxYFhKELl3eMnbpZTPaE/XLDxtV90Escbf4Cs05daAJEF KzICImw2JPCQzWHoXiU462/KJtCk/ii7DXenXz2dUMtbFHxXXPuhqgu6i8zT5eV7AGG3 APBN/WvgjN845P4CPSxQsCyKvVoBnj1BIevv16dmISG+iSrGxLMhA62gclzVCltiI3xE cRkTI1B1lAION2uS+ilEC4QxcLHXmIOtn6uGb14aWM/jnKUoTrsZZK57BsY3dMgSsAyn LOWw== MIME-Version: 1.0 X-Received: by 10.182.241.38 with SMTP id wf6mr40334031obc.81.1426284453889; Fri, 13 Mar 2015 15:07:33 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.11.136 with HTTP; Fri, 13 Mar 2015 15:07:33 -0700 (PDT) In-Reply-To: References: <20150313174749.2435.7999.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 18:07:33 -0400 X-Google-Sender-Auth: T9XUNJ4B-Y7wr92h8HEN583MdRU Message-ID: From: Kerry Lynn To: Pete Resnick Content-Type: multipart/alternative; boundary=001a11c30f80390d91051132ba19 Archived-At: Cc: "draft-ietf-dnssd-requirements.all" , dnssd@ietf.org, dnssd-chairs , The IESG , Tim Chown Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 13 Mar 2015 22:07:42 -0000 --001a11c30f80390d91051132ba19 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 13, 2015 at 4:41 PM, Kerry Lynn wrote: > On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick > wrote: > >> Pete Resnick has entered the following ballot position for >> draft-ietf-dnssd-requirements-05: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> [Updating to reflect that the IPR disclosure issue is addressed. There is >> an IPR disclosure that appears for this document, but it was a mistakenly >> filed disclosure that still remains in the system. We will deal with that >> issue separately.] >> >> Section 5: >> >> OLD >> Devices on different links may have the same mDNS name (perhaps due >> to vendor defaults), because link-local mDNS names are only >> guaranteed to be unique on a per-link basis. Also, even devices that >> are on the same link may have similar-looking names, such as one >> device with the name "Bill" and another device using the similar- >> looking name "Bi11" (using the digit "1" in place of the letter "l"). >> This may lead to a local label disambiguation problem between >> presented results. >> >> SSD should support rich internationalized labels within Service >> Instance Names, as DNS-SD/mDNS does today. SSD must not negatively >> impact the global DNS namespace or infrastructure. >> >> The part about name collisions is fine, and should be said. The part >> about disambiguating similar characters is a rat's nest I really think >> you need to avoid. We can discuss this further, but the i18n community is >> dealing with this issue right now and it's a mess you really don't want >> to get into. I think you should simply stick to something like this: >> >> NEW >> Devices on different links may have the same mDNS name (perhaps due >> to vendor defaults), because link-local mDNS names are only >> guaranteed to be unique on a per-link basis. SSD needs to deal with >> name collisions beyond local link considerations. >> >> SSD should support rich internationalized labels within Service >> Instance Names, as DNS-SD/mDNS does today and should look to work in >> using internationalize strings in application protocols >> [soon-to-be-RFC-draft-ietf-precis-framework]. SSD must not >> negatively impact the global DNS namespace or infrastructure. >> >> Hi Pete, > > This draft is now more than a year late, due in part to much discussion > about > the differences between DNS-SD/mDNS and DNS (IDNA2008) name spaces. > Looking back at our charter, we have a requirement > > To document challenges and problems encountered in the coexistence > of zero configuration and global DNS name services in such > multi-link networks, including consideration of both the name > resolution mechanism and the namespace. > > without necessarily proposing a solution (however, the latter may > ultimately come > about via https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-00 > ). > > The language you have flagged was inserted during WGLC in response to one > very vocal critic and addresses, I believe, a different problem. It is > often the > case that DNS-SD/mDNS query results are displayed to the user through the > UI. The OLD language simply notes that various, otherwise legal, names may > have a similar appearance (without proposing a solution). > > If you still find that a change is necessary, I would first ask what we > can merely > delete. I'm afraid that any additions to this section may require us to > go back to > the WG for further discussion. > > Regards, Kerry Lynn > BTW, with the IPR question resolved, did you mean for this to remain a DISCUSS or should it be a COMMENT instead? --001a11c30f80390d91051132ba19 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 13, 2015 at 4:41 PM, Kerry Lynn <kerlyn@ieee.or= g> wrote:
On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick <presnick@qti.qual= comm.com> wrote:
Pete Resnick has entered the following ballot positi= on for
draft-ietf-dnssd-requirements-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-crit= eria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirem= ents/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

[Updating to reflect that the IPR disclosure issue is addressed. There is an IPR disclosure that appears for this document, but it was a mistakenly filed disclosure that still remains in the system. We will deal with that issue separately.]

Section 5:

OLD
=C2=A0 =C2=A0Devices on different links may have the same mDNS name (perhap= s due
=C2=A0 =C2=A0to vendor defaults), because link-local mDNS names are only =C2=A0 =C2=A0guaranteed to be unique on a per-link basis.=C2=A0 Also, even = devices that
=C2=A0 =C2=A0are on the same link may have similar-looking names, such as o= ne
=C2=A0 =C2=A0device with the name "Bill" and another device using= the similar-
=C2=A0 =C2=A0looking name "Bi11" (using the digit "1" i= n place of the letter "l").
=C2=A0 =C2=A0This may lead to a local label disambiguation problem between<= br> =C2=A0 =C2=A0presented results.

=C2=A0 =C2=A0SSD should support rich internationalized labels within Servic= e
=C2=A0 =C2=A0Instance Names, as DNS-SD/mDNS does today.=C2=A0 SSD must not = negatively
=C2=A0 =C2=A0impact the global DNS namespace or infrastructure.

The part about name collisions is fine, and should be said. The part
about disambiguating similar characters is a rat's nest I really think<= br> you need to avoid. We can discuss this further, but the i18n community is dealing with this issue right now and it's a mess you really don't = want
to get into. I think you should simply stick to something like this:

NEW
=C2=A0 =C2=A0Devices on different links may have the same mDNS name (perhap= s due
=C2=A0 =C2=A0to vendor defaults), because link-local mDNS names are only =C2=A0 =C2=A0guaranteed to be unique on a per-link basis. SSD needs to deal= with
=C2=A0 =C2=A0name collisions beyond local link considerations.

=C2=A0 =C2=A0SSD should support rich internationalized labels within Servic= e
=C2=A0 =C2=A0Instance Names, as DNS-SD/mDNS does today and should look to w= ork in
=C2=A0 =C2=A0using internationalize strings in application protocols
=C2=A0 =C2=A0[soon-to-be-RFC-draft-ietf-precis-framework].=C2=A0 SSD must n= ot
=C2=A0 =C2=A0negatively impact the global DNS namespace or infrastructure.<= br>
Hi Pete,

This draft is = now more than a year late, due in part to much discussion about
the differences between DNS-SD/mDNS and DNS (IDNA2008) name spaces.
<= /div>
Looking back at our charter, we have a requirement
To doc=
ument challenges and problems encountered in the coexistence
of zero configuration and global DNS name services in such
multi-link networks, including consideration of both the name
resolution mechanism and the namespace.
without necessarily proposing= a solution (however, the latter may ultimately come
The language you have flagged was inser= ted during WGLC in response to one
very vocal critic and addr= esses, I believe, a different problem.=C2=A0 It is often the
= case that DNS-SD/mDNS query results are displayed to the user through the
UI.=C2=A0 The OLD language simply notes that various, otherwis= e legal, names may
have a similar appearance (without proposi= ng a solution).

If you still find that a change is necess= ary, I would first ask what we can merely
delete.=C2=A0 I'm afraid t= hat any additions to this section may require us to go back to
the WG fo= r further discussion.

Regards, Kerry Lynn
=

BTW, with the IPR question res= olved, did you mean for this to remain a DISCUSS
or should it= be a COMMENT instead?

--001a11c30f80390d91051132ba19-- From nobody Fri Mar 13 15:43:03 2015 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 1B0211A6FEC; Fri, 13 Mar 2015 15:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.01 X-Spam-Level: X-Spam-Status: No, score=-9.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 PqSNWoc0aoiN; Fri, 13 Mar 2015 15:42:54 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD9A1A0217; Fri, 13 Mar 2015 15:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426286574; x=1457822574; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=65HE0tcpjjpBbZAebGvT6d35S0MPlvAKMCH9AiJ2B3A=; b=xOuhqSPhqtJ97gcDRTMv/WPSRG9XsdYGOX0NhxBPa888WvsU0RpLTRQr PFOGAdpdYVejMKoRT/uyetq3VroHb2mgdXZAQrktpwSMcdUhPY4nEg5K8 XFokYkDklRKCJy2OHCn2m9fjmxkuMl/6gzK5z0XAaxbmK9tIDM6AR3ATx I=; X-IronPort-AV: E=McAfee;i="5600,1067,7739"; a="108258160" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Mar 2015 15:42:53 -0700 X-IronPort-AV: E=Sophos;i="5.11,397,1422950400"; d="scan'208,217";a="836339846" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Mar 2015 15:42:52 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 13 Mar 2015 15:42:52 -0700 Message-ID: <550367EB.3090508@qti.qualcomm.com> Date: Fri, 13 Mar 2015 15:42:51 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Kerry Lynn References: <20150313174749.2435.7999.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030505060902000403030501" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: "draft-ietf-dnssd-requirements.all" , dnssd@ietf.org, dnssd-chairs , The IESG , Tim Chown Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 13 Mar 2015 22:43:00 -0000 --------------030505060902000403030501 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Starting with the last question first: On 3/13/15 3:07 PM, Kerry Lynn wrote: > BTW, with the IPR question resolved, did you mean for this to remain a > DISCUSS > or should it be a COMMENT instead? I absolutely meant for this to remain a DISCUSS. I think the current text is a real problem. > On Fri, Mar 13, 2015 at 4:41 PM, Kerry Lynn > wrote: > > On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick > > wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 5: > > OLD > Devices on different links may have the same mDNS name > (perhaps due > to vendor defaults), because link-local mDNS names are only > guaranteed to be unique on a per-link basis. Also, even > devices that > are on the same link may have similar-looking names, such > as one > device with the name "Bill" and another device using the > similar- > looking name "Bi11" (using the digit "1" in place of the > letter "l"). > This may lead to a local label disambiguation problem between > presented results. > > SSD should support rich internationalized labels within Service > Instance Names, as DNS-SD/mDNS does today. SSD must not > negatively > impact the global DNS namespace or infrastructure. > > The part about name collisions is fine, and should be said. > The part > about disambiguating similar characters is a rat's nest I > really think > you need to avoid. We can discuss this further, but the i18n > community is > dealing with this issue right now and it's a mess you really > don't want > to get into. I think you should simply stick to something like > this: > > NEW > Devices on different links may have the same mDNS name > (perhaps due > to vendor defaults), because link-local mDNS names are only > guaranteed to be unique on a per-link basis. SSD needs to > deal with > name collisions beyond local link considerations. > > SSD should support rich internationalized labels within Service > Instance Names, as DNS-SD/mDNS does today and should look > to work in > using internationalize strings in application protocols > [soon-to-be-RFC-draft-ietf-precis-framework]. SSD must not > negatively impact the global DNS namespace or infrastructure. > > Hi Pete, > > This draft is now more than a year late, due in part to much > discussion about > the differences between DNS-SD/mDNS and DNS (IDNA2008) name spaces. > I am happy (and committed) to figure out a way to get this to move forward as quickly as possible. > Looking back at our charter, we have a requirement > > To document challenges and problems encountered in the coexistence > of zero configuration and global DNS name services in such > multi-link networks, including consideration of both the name > resolution mechanism and the namespace. > > without necessarily proposing a solution (however, the latter may > ultimately come > about via > https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-00). > Sure, but you don't want to be documenting problems for which there is no technical solution ("People tend to drop mDNS consumer devices on the floor because they're small and they break easily, and they get upset about that"), at least in your layer. So when I see this: > The language you have flagged was inserted during WGLC in response > to one > very vocal critic and addresses, I believe, a different problem. > It is often the > case that DNS-SD/mDNS query results are displayed to the user > through the > UI. The OLD language simply notes that various, otherwise legal, > names may > have a similar appearance (without proposing a solution). > I suspect it's not a helpful piece of text to have in the document. If you think "l" vs. "1" is fun, wait until you get to "ø" vs. "?" vs. "o?". The issue of confusable characters upon display is several layers above what this WG can do something about, and even bringing up the topic in a requirements document suggests that you intend to tackle it. I think you very much should not. > If you still find that a change is necessary, I would first ask > what we can merely > delete. I'm afraid that any additions to this section may require > us to go back to > the WG for further discussion. > So, I suggested above simply removing the second sentence of the first paragraph. I changed the last sentence of the first paragraph because without the second sentence, it doesn't track, but I don't really care how you word that. The only other thing I added was "and should look to work in using internationalize strings in application protocols [soon-to-be-RFC-draft-ietf-precis-framework]." I am not insistent on that, but I think in reality, if you're going to "support rich internationalized labels" as you do today, looking to the PRECIS work is exactly what you're going to do. All that said, this shouldn't be a heavy lift one way or the other. If your chair (and AD) think that whatever changes I suggest still represent the consensus of the WG, they can say so and you can make the change. If the WG disagrees, I'm sure they will let them know. But I do take the word "DISCUSS" quite seriously: I am ready and willing to engage in a discussion with you and the rest of the WG and drive that discussion to completion right quick (in particular, before we all show up in Dallas). Either you'll convince me that this isn't a big deal and we should leave the text as it is, or I'll convince you that it is a big deal and you should change it, or something in between. The bad outcome is to have an open issue that hasn't been addressed. (I think someone wrote a document about that. [1] ;-).) So let's discuss. pr [1] https://datatracker.ietf.org/doc/rfc7282/ -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------030505060902000403030501 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Starting with the last question first:

On 3/13/15 3:07 PM, Kerry Lynn wrote:

BTW, with the IPR question resolved, did you mean for this to remain a DISCUSS
or should it be a COMMENT instead?

I absolutely meant for this to remain a DISCUSS. I think the current text is a real problem.

On Fri, Mar 13, 2015 at 4:41 PM, Kerry Lynn <kerlyn@ieee.org> wrote:
On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 5:

OLD
   Devices on different links may have the same mDNS name (perhaps due
   to vendor defaults), because link-local mDNS names are only
   guaranteed to be unique on a per-link basis.  Also, even devices that
   are on the same link may have similar-looking names, such as one
   device with the name "Bill" and another device using the similar-
   looking name "Bi11" (using the digit "1" in place of the letter "l").
   This may lead to a local label disambiguation problem between
   presented results.

   SSD should support rich internationalized labels within Service
   Instance Names, as DNS-SD/mDNS does today.  SSD must not negatively
   impact the global DNS namespace or infrastructure.

The part about name collisions is fine, and should be said. The part
about disambiguating similar characters is a rat's nest I really think
you need to avoid. We can discuss this further, but the i18n community is
dealing with this issue right now and it's a mess you really don't want
to get into. I think you should simply stick to something like this:

NEW
   Devices on different links may have the same mDNS name (perhaps due
   to vendor defaults), because link-local mDNS names are only
   guaranteed to be unique on a per-link basis. SSD needs to deal with
   name collisions beyond local link considerations.

   SSD should support rich internationalized labels within Service
   Instance Names, as DNS-SD/mDNS does today and should look to work in
   using internationalize strings in application protocols
   [soon-to-be-RFC-draft-ietf-precis-framework].  SSD must not
   negatively impact the global DNS namespace or infrastructure.

Hi Pete,

This draft is now more than a year late, due in part to much discussion about
the differences between DNS-SD/mDNS and DNS (IDNA2008) name spaces.

I am happy (and committed) to figure out a way to get this to move forward as quickly as possible.

Looking back at our charter, we have a requirement
To document challenges and problems encountered in the coexistence
of zero configuration and global DNS name services in such
multi-link networks, including consideration of both the name
resolution mechanism and the namespace.
without necessarily proposing a solution (however, the latter may ultimately come

Sure, but you don't want to be documenting problems for which there is no technical solution ("People tend to drop mDNS consumer devices on the floor because they're small and they break easily, and they get upset about that"), at least in your layer. So when I see this:

The language you have flagged was inserted during WGLC in response to one
very vocal critic and addresses, I believe, a different problem.  It is often the
case that DNS-SD/mDNS query results are displayed to the user through the
UI.  The OLD language simply notes that various, otherwise legal, names may
have a similar appearance (without proposing a solution).

I suspect it's not a helpful piece of text to have in the document. If you think "l" vs. "1" is fun, wait until you get to "ø" vs. "⌀" vs. "o̷". The issue of confusable characters upon display is several layers above what this WG can do something about, and even bringing up the topic in a requirements document suggests that you intend to tackle it. I think you very much should not.

If you still find that a change is necessary, I would first ask what we can merely
delete.  I'm afraid that any additions to this section may require us to go back to
the WG for further discussion.

So, I suggested above simply removing the second sentence of the first paragraph. I changed the last sentence of the first paragraph because without the second sentence, it doesn't track, but I don't really care how you word that. The only other thing I added was "and should look to work in using internationalize strings in application protocols [soon-to-be-RFC-draft-ietf-precis-framework]." I am not insistent on that, but I think in reality, if you're going to "support rich internationalized labels" as you do today, looking to the PRECIS work is exactly what you're going to do.

All that said, this shouldn't be a heavy lift one way or the other. If your chair (and AD) think that whatever changes I suggest still represent the consensus of the WG, they can say so and you can make the change. If the WG disagrees, I'm sure they will let them know. But I do take the word "DISCUSS" quite seriously: I am ready and willing to engage in a discussion with you and the rest of the WG and drive that discussion to completion right quick (in particular, before we all show up in Dallas). Either you'll convince me that this isn't a big deal and we should leave the text as it is, or I'll convince you that it is a big deal and you should change it, or something in between. The bad outcome is to have an open issue that hasn't been addressed. (I think someone wrote a document about that. [1] ;-).) So let's discuss.

pr

[1] https://datatracker.ietf.org/doc/rfc7282/
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------030505060902000403030501-- From nobody Fri Mar 13 15:43:07 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 46D201A70E2; Fri, 13 Mar 2015 15:43:00 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0211A6FEC; Fri, 13 Mar 2015 15:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.01 X-Spam-Level: X-Spam-Status: No, score=-9.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 PqSNWoc0aoiN; Fri, 13 Mar 2015 15:42:54 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD9A1A0217; Fri, 13 Mar 2015 15:42:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426286574; x=1457822574; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=65HE0tcpjjpBbZAebGvT6d35S0MPlvAKMCH9AiJ2B3A=; b=xOuhqSPhqtJ97gcDRTMv/WPSRG9XsdYGOX0NhxBPa888WvsU0RpLTRQr PFOGAdpdYVejMKoRT/uyetq3VroHb2mgdXZAQrktpwSMcdUhPY4nEg5K8 XFokYkDklRKCJy2OHCn2m9fjmxkuMl/6gzK5z0XAaxbmK9tIDM6AR3ATx I=; X-IronPort-AV: E=McAfee;i="5600,1067,7739"; a="108258160" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by wolverine01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Mar 2015 15:42:53 -0700 X-IronPort-AV: E=Sophos;i="5.11,397,1422950400"; d="scan'208,217";a="836339846" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Mar 2015 15:42:52 -0700 Received: from presnick-mac.local (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 13 Mar 2015 15:42:52 -0700 Message-ID: <550367EB.3090508@qti.qualcomm.com> Date: Fri, 13 Mar 2015 15:42:51 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Kerry Lynn References: <20150313174749.2435.7999.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030505060902000403030501" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01F.na.qualcomm.com (10.85.0.32) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: "draft-ietf-dnssd-requirements.all" , dnssd@ietf.org, dnssd-chairs , The IESG , Tim Chown Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 13 Mar 2015 22:43:00 -0000 --------------030505060902000403030501 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Starting with the last question first: On 3/13/15 3:07 PM, Kerry Lynn wrote: > BTW, with the IPR question resolved, did you mean for this to remain a > DISCUSS > or should it be a COMMENT instead? I absolutely meant for this to remain a DISCUSS. I think the current text is a real problem. > On Fri, Mar 13, 2015 at 4:41 PM, Kerry Lynn > wrote: > > On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick > > wrote: > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Section 5: > > OLD > Devices on different links may have the same mDNS name > (perhaps due > to vendor defaults), because link-local mDNS names are only > guaranteed to be unique on a per-link basis. Also, even > devices that > are on the same link may have similar-looking names, such > as one > device with the name "Bill" and another device using the > similar- > looking name "Bi11" (using the digit "1" in place of the > letter "l"). > This may lead to a local label disambiguation problem between > presented results. > > SSD should support rich internationalized labels within Service > Instance Names, as DNS-SD/mDNS does today. SSD must not > negatively > impact the global DNS namespace or infrastructure. > > The part about name collisions is fine, and should be said. > The part > about disambiguating similar characters is a rat's nest I > really think > you need to avoid. We can discuss this further, but the i18n > community is > dealing with this issue right now and it's a mess you really > don't want > to get into. I think you should simply stick to something like > this: > > NEW > Devices on different links may have the same mDNS name > (perhaps due > to vendor defaults), because link-local mDNS names are only > guaranteed to be unique on a per-link basis. SSD needs to > deal with > name collisions beyond local link considerations. > > SSD should support rich internationalized labels within Service > Instance Names, as DNS-SD/mDNS does today and should look > to work in > using internationalize strings in application protocols > [soon-to-be-RFC-draft-ietf-precis-framework]. SSD must not > negatively impact the global DNS namespace or infrastructure. > > Hi Pete, > > This draft is now more than a year late, due in part to much > discussion about > the differences between DNS-SD/mDNS and DNS (IDNA2008) name spaces. > I am happy (and committed) to figure out a way to get this to move forward as quickly as possible. > Looking back at our charter, we have a requirement > > To document challenges and problems encountered in the coexistence > of zero configuration and global DNS name services in such > multi-link networks, including consideration of both the name > resolution mechanism and the namespace. > > without necessarily proposing a solution (however, the latter may > ultimately come > about via > https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-00). > Sure, but you don't want to be documenting problems for which there is no technical solution ("People tend to drop mDNS consumer devices on the floor because they're small and they break easily, and they get upset about that"), at least in your layer. So when I see this: > The language you have flagged was inserted during WGLC in response > to one > very vocal critic and addresses, I believe, a different problem. > It is often the > case that DNS-SD/mDNS query results are displayed to the user > through the > UI. The OLD language simply notes that various, otherwise legal, > names may > have a similar appearance (without proposing a solution). > I suspect it's not a helpful piece of text to have in the document. If you think "l" vs. "1" is fun, wait until you get to "ø" vs. "?" vs. "o?". The issue of confusable characters upon display is several layers above what this WG can do something about, and even bringing up the topic in a requirements document suggests that you intend to tackle it. I think you very much should not. > If you still find that a change is necessary, I would first ask > what we can merely > delete. I'm afraid that any additions to this section may require > us to go back to > the WG for further discussion. > So, I suggested above simply removing the second sentence of the first paragraph. I changed the last sentence of the first paragraph because without the second sentence, it doesn't track, but I don't really care how you word that. The only other thing I added was "and should look to work in using internationalize strings in application protocols [soon-to-be-RFC-draft-ietf-precis-framework]." I am not insistent on that, but I think in reality, if you're going to "support rich internationalized labels" as you do today, looking to the PRECIS work is exactly what you're going to do. All that said, this shouldn't be a heavy lift one way or the other. If your chair (and AD) think that whatever changes I suggest still represent the consensus of the WG, they can say so and you can make the change. If the WG disagrees, I'm sure they will let them know. But I do take the word "DISCUSS" quite seriously: I am ready and willing to engage in a discussion with you and the rest of the WG and drive that discussion to completion right quick (in particular, before we all show up in Dallas). Either you'll convince me that this isn't a big deal and we should leave the text as it is, or I'll convince you that it is a big deal and you should change it, or something in between. The bad outcome is to have an open issue that hasn't been addressed. (I think someone wrote a document about that. [1] ;-).) So let's discuss. pr [1] https://datatracker.ietf.org/doc/rfc7282/ -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------030505060902000403030501 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Starting with the last question first:

On 3/13/15 3:07 PM, Kerry Lynn wrote:

BTW, with the IPR question resolved, did you mean for this to remain a DISCUSS
or should it be a COMMENT instead?

I absolutely meant for this to remain a DISCUSS. I think the current text is a real problem.

On Fri, Mar 13, 2015 at 4:41 PM, Kerry Lynn <kerlyn@ieee.org> wrote:
On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Section 5:

OLD
   Devices on different links may have the same mDNS name (perhaps due
   to vendor defaults), because link-local mDNS names are only
   guaranteed to be unique on a per-link basis.  Also, even devices that
   are on the same link may have similar-looking names, such as one
   device with the name "Bill" and another device using the similar-
   looking name "Bi11" (using the digit "1" in place of the letter "l").
   This may lead to a local label disambiguation problem between
   presented results.

   SSD should support rich internationalized labels within Service
   Instance Names, as DNS-SD/mDNS does today.  SSD must not negatively
   impact the global DNS namespace or infrastructure.

The part about name collisions is fine, and should be said. The part
about disambiguating similar characters is a rat's nest I really think
you need to avoid. We can discuss this further, but the i18n community is
dealing with this issue right now and it's a mess you really don't want
to get into. I think you should simply stick to something like this:

NEW
   Devices on different links may have the same mDNS name (perhaps due
   to vendor defaults), because link-local mDNS names are only
   guaranteed to be unique on a per-link basis. SSD needs to deal with
   name collisions beyond local link considerations.

   SSD should support rich internationalized labels within Service
   Instance Names, as DNS-SD/mDNS does today and should look to work in
   using internationalize strings in application protocols
   [soon-to-be-RFC-draft-ietf-precis-framework].  SSD must not
   negatively impact the global DNS namespace or infrastructure.

Hi Pete,

This draft is now more than a year late, due in part to much discussion about
the differences between DNS-SD/mDNS and DNS (IDNA2008) name spaces.

I am happy (and committed) to figure out a way to get this to move forward as quickly as possible.

Looking back at our charter, we have a requirement
To document challenges and problems encountered in the coexistence
of zero configuration and global DNS name services in such
multi-link networks, including consideration of both the name
resolution mechanism and the namespace.
without necessarily proposing a solution (however, the latter may ultimately come

Sure, but you don't want to be documenting problems for which there is no technical solution ("People tend to drop mDNS consumer devices on the floor because they're small and they break easily, and they get upset about that"), at least in your layer. So when I see this:

The language you have flagged was inserted during WGLC in response to one
very vocal critic and addresses, I believe, a different problem.  It is often the
case that DNS-SD/mDNS query results are displayed to the user through the
UI.  The OLD language simply notes that various, otherwise legal, names may
have a similar appearance (without proposing a solution).

I suspect it's not a helpful piece of text to have in the document. If you think "l" vs. "1" is fun, wait until you get to "ø" vs. "⌀" vs. "o̷". The issue of confusable characters upon display is several layers above what this WG can do something about, and even bringing up the topic in a requirements document suggests that you intend to tackle it. I think you very much should not.

If you still find that a change is necessary, I would first ask what we can merely
delete.  I'm afraid that any additions to this section may require us to go back to
the WG for further discussion.

So, I suggested above simply removing the second sentence of the first paragraph. I changed the last sentence of the first paragraph because without the second sentence, it doesn't track, but I don't really care how you word that. The only other thing I added was "and should look to work in using internationalize strings in application protocols [soon-to-be-RFC-draft-ietf-precis-framework]." I am not insistent on that, but I think in reality, if you're going to "support rich internationalized labels" as you do today, looking to the PRECIS work is exactly what you're going to do.

All that said, this shouldn't be a heavy lift one way or the other. If your chair (and AD) think that whatever changes I suggest still represent the consensus of the WG, they can say so and you can make the change. If the WG disagrees, I'm sure they will let them know. But I do take the word "DISCUSS" quite seriously: I am ready and willing to engage in a discussion with you and the rest of the WG and drive that discussion to completion right quick (in particular, before we all show up in Dallas). Either you'll convince me that this isn't a big deal and we should leave the text as it is, or I'll convince you that it is a big deal and you should change it, or something in between. The bad outcome is to have an open issue that hasn't been addressed. (I think someone wrote a document about that. [1] ;-).) So let's discuss.

pr

[1] https://datatracker.ietf.org/doc/rfc7282/
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------030505060902000403030501-- From nobody Fri Mar 13 17:49:35 2015 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 EC8761A90D5; Fri, 13 Mar 2015 17:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 5zMsMGZPQNMl; Fri, 13 Mar 2015 17:49:25 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B0B1A90CA; Fri, 13 Mar 2015 17:49:25 -0700 (PDT) Received: by obfv9 with SMTP id v9so2257628obf.2; Fri, 13 Mar 2015 17:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=aRYFo9SBeapn38XzPbeZasrYEnMXvBGPgmiXBcne+nc=; b=LKDVoHXd/WRM3h5uBatVsci9huj4RXaw8nfHM6jaCGswvduG4VN73BzA40y5o18/KM AjUGq1Hyk3R7flNw8vQGjrSIXMsA3KdZvccVHSphznGk6UZiovQ4HOlG0zhpc/H2NnwJ 4JfT8csIosyCgGqjHcVzlrhWKM4fJXllmA0fMv03yKqrJCwxbvDwIQTrrQHYiWR/C7KT RDnjBkNd33RazmX4OFin2ylOdzDTcex5ugZNLQryl7bpYsrNeXSYrArUsoP2uBrkZLfL VO3VVUY0Hslyqy2YUilSP1jSF6N/GJS5qHHWc2hNNZrOjgi6gPcE7V9ERXtW5Giiadck nUAQ== MIME-Version: 1.0 X-Received: by 10.202.229.141 with SMTP id c135mr38219126oih.44.1426294164861; Fri, 13 Mar 2015 17:49:24 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.11.136 with HTTP; Fri, 13 Mar 2015 17:49:24 -0700 (PDT) In-Reply-To: <550367EB.3090508@qti.qualcomm.com> References: <20150313174749.2435.7999.idtracker@ietfa.amsl.com> <550367EB.3090508@qti.qualcomm.com> Date: Fri, 13 Mar 2015 20:49:24 -0400 X-Google-Sender-Auth: --OZnCAbo_bkEcE2OTpWJGvvpmw Message-ID: From: Kerry Lynn To: Pete Resnick Content-Type: multipart/alternative; boundary=001a114074400ab784051134fdb8 Archived-At: Cc: "draft-ietf-dnssd-requirements.all" , dnssd@ietf.org, dnssd-chairs , The IESG , Tim Chown Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 14 Mar 2015 00:49:29 -0000 --001a114074400ab784051134fdb8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 13, 2015 at 6:42 PM, Pete Resnick wrote: > Starting with the last question first: > > On 3/13/15 3:07 PM, Kerry Lynn wrote: > > BTW, with the IPR question resolved, did you mean for this to remain a > DISCUSS > or should it be a COMMENT instead? > > > I absolutely meant for this to remain a DISCUSS. I think the current text > is a real problem. > > On Fri, Mar 13, 2015 at 4:41 PM, Kerry Lynn wrote: > >> On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick > > wrote: >> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> Section 5: >>> >>> OLD >>> Devices on different links may have the same mDNS name (perhaps due >>> to vendor defaults), because link-local mDNS names are only >>> guaranteed to be unique on a per-link basis. Also, even devices tha= t >>> are on the same link may have similar-looking names, such as one >>> device with the name "Bill" and another device using the similar- >>> looking name "Bi11" (using the digit "1" in place of the letter "l")= . >>> This may lead to a local label disambiguation problem between >>> presented results. >>> >>> SSD should support rich internationalized labels within Service >>> Instance Names, as DNS-SD/mDNS does today. SSD must not negatively >>> impact the global DNS namespace or infrastructure. >>> >>> The part about name collisions is fine, and should be said. The part >>> about disambiguating similar characters is a rat's nest I really think >>> you need to avoid. We can discuss this further, but the i18n community = is >>> dealing with this issue right now and it's a mess you really don't want >>> to get into. I think you should simply stick to something like this: >>> >>> NEW >>> Devices on different links may have the same mDNS name (perhaps due >>> to vendor defaults), because link-local mDNS names are only >>> guaranteed to be unique on a per-link basis. SSD needs to deal with >>> name collisions beyond local link considerations. >>> >>> SSD should support rich internationalized labels within Service >>> Instance Names, as DNS-SD/mDNS does today and should look to work in >>> using internationalize strings in application protocols >>> [soon-to-be-RFC-draft-ietf-precis-framework]. SSD must not >>> negatively impact the global DNS namespace or infrastructure. >>> >>> Hi Pete, >> >> This draft is now more than a year late, due in part to much discussion >> about >> the differences between DNS-SD/mDNS and DNS (IDNA2008) name spaces. >> > > I am happy (and committed) to figure out a way to get this to move forwar= d > as quickly as possible. > > Looking back at our charter, we have a requirement >> >> To document challenges and problems encountered in the coexistence >> of zero configuration and global DNS name services in such >> multi-link networks, including consideration of both the name >> resolution mechanism and the namespace. >> >> without necessarily proposing a solution (however, the latter may >> ultimately come >> about via >> https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-00). >> > > Sure, but you don't want to be documenting problems for which there is no > technical solution ("People tend to drop mDNS consumer devices on the flo= or > because they're small and they break easily, and they get upset about > that"), at least in your layer. So when I see this: > > The language you have flagged was inserted during WGLC in response to >> one >> very vocal critic and addresses, I believe, a different problem. It is >> often the >> case that DNS-SD/mDNS query results are displayed to the user through >> the >> UI. The OLD language simply notes that various, otherwise legal, names >> may >> have a similar appearance (without proposing a solution). >> > > I suspect it's not a helpful piece of text to have in the document. If yo= u > think "l" vs. "1" is fun, wait until you get to "=C3=B8" vs. "=E2=8C=80" = vs. "o=CC=B7". The > issue of confusable characters upon display is several layers above what > this WG can do something about, and even bringing up the topic in a > requirements document suggests that you intend to tackle it. I think you > very much should not. > > If you still find that a change is necessary, I would first ask what >> we can merely >> delete. I'm afraid that any additions to this section may require us to >> go back to >> the WG for further discussion. >> > > So, I suggested above simply removing the second sentence of the first > paragraph. I changed the last sentence of the first paragraph because > without the second sentence, it doesn't track, but I don't really care ho= w > you word that. The only other thing I added was "and should look to work = in > using internationalize strings in application protocols > [soon-to-be-RFC-draft-ietf-precis-framework]." I am not insistent on that= , > but I think in reality, if you're going to "support rich internationalize= d > labels" as you do today, looking to the PRECIS work is exactly what you'r= e > going to do. > > I don't have a problem with deleting that sentence and patching the prose as necessary. Hopefully the chairs and AD will agree. Are you OK with something like: NEW Devices on different links may have the same mDNS name (perhaps due to vendor defaults), because link-local mDNS names are only guaranteed to be unique on a per-link basis. This may lead to a local label disambiguation problem when results are aggregated (e.g. for presentation). I have more of an issue with the insertion of PRECIS at this late date. Insofar as that draft and this one have a common co-author, I think it is reasonable to assume that it will receive full consideration during the solution phase. Regards, -K- > All that said, this shouldn't be a heavy lift one way or the other. If > your chair (and AD) think that whatever changes I suggest still represent > the consensus of the WG, they can say so and you can make the change. If > the WG disagrees, I'm sure they will let them know. But I do take the wor= d > "DISCUSS" quite seriously: I am ready and willing to engage in a discussi= on > with you and the rest of the WG and drive that discussion to completion > right quick (in particular, before we all show up in Dallas). Either you'= ll > convince me that this isn't a big deal and we should leave the text as it > is, or I'll convince you that it is a big deal and you should change it, = or > something in between. The bad outcome is to have an open issue that hasn'= t > been addressed. (I think someone wrote a document about that. [1] ;-).) S= o > let's discuss. > > pr > > [1] https://datatracker.ietf.org/doc/rfc7282/ > > -- > Pete Resnick > Qualcomm Technologies, Inc. - +1 (858)651-4478 > > --001a114074400ab784051134fdb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Mar 13, 2015 at 6:42 PM, Pete Resnick <presnick@qti.qualcomm.c= om> wrote:
=20
Starting with the last question first:

On 3/13/15 3:07 PM, Kerry Lynn wrote:

BTW, with the IPR question resolved, did you mean for this to remain a DISCUSS
or should it be a COMMENT instead?

 I absolutely meant for this to remain a DISCUSS. I think the current text is a real problem.

On Fri, Mar 13, 2015 at 4:41 PM, Kerry = Lynn <kerlyn@ieee.org> wrote:
On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick &l= t;presnick@q= ti.qualcomm.com> wrote:
------------------------------------------------------= ----------------
DISCUSS:
----------------------------------------------------------------------
=


Section 5:

OLD
=C2=A0 =C2=A0Devices on different links may have the same mDNS name (perhap= s due
=C2=A0 =C2=A0to vendor defaults), because link-local mDNS names are only =C2=A0 =C2=A0guaranteed to be unique on a per-link basis.=C2=A0 Also, even = devices that
=C2=A0 =C2=A0are on the same link may have similar-looking names, such as o= ne
=C2=A0 =C2=A0device with the name "Bill" and another device using= the similar-
=C2=A0 =C2=A0looking name "Bi11" (using the digit "1" i= n place of the letter "l").
=C2=A0 =C2=A0This may lead to a local label disambiguation problem between<= br> =C2=A0 =C2=A0presented results.

=C2=A0 =C2=A0SSD should support rich internationalized labels within Servic= e
=C2=A0 =C2=A0Instance Names, as DNS-SD/mDNS does today.=C2=A0 SSD must not = negatively
=C2=A0 =C2=A0impact the global DNS namespace or infrastructure.

The part about name collisions is fine, and should be said. The part
about disambiguating similar characters is a rat's nest I really think<= br> you need to avoid. We can discuss this further, but the i18n community is
dealing with this issue right now and it's a mess you really don't = want
to get into. I think you should simply stick to something like this:

NEW
=C2=A0 =C2=A0Devices on different links may have the same mDNS name (perhap= s due
=C2=A0 =C2=A0to vendor defaults), because link-local mDNS names are only =C2=A0 =C2=A0guaranteed to be unique on a per-link basis. SSD needs to deal= with
=C2=A0 =C2=A0name collisions beyond local link considerations.

=C2=A0 =C2=A0SSD should support rich internationalized labels within Servic= e
=C2=A0 =C2=A0Instance Names, as DNS-SD/mDNS does today and should look to w= ork in
=C2=A0 =C2=A0using internationalize strings in application protocols
=C2=A0 =C2=A0[soon-to-be-RFC-draft-ietf-precis-framework].=C2=A0 SSD must n= ot
=C2=A0 =C2=A0negatively impact the global DNS namespace or infrastructure.<= br>
Hi Pete,

This draft is now more than a year late, due in part to much discussion about
the differences between DNS-SD/mDNS and DNS (IDNA2008) name spaces.

I am happy (and committed) to figure out a way to get this to move forward as quickly as possible.

Looking back at our charter, we have a requirement
To document challenges and problems encountered in the coexistence
of zero configuration and global DNS name services in such
multi-link networks, including consideration of both the name
resolution mechanism and the namespace.
without necessarily proposing a solution (however, the latter may ultimately come

 Sure, but you don't want to be documenting problems for which there is no technical solution ("People tend to drop mDNS consumer devices on the floor because they're small and they break easily, and they get upset about that"), at least in your layer. So when I see this:

The language you have flagged was inserted during WGLC in response to one
very vocal critic and addresses, I believe, a different problem.=C2=A0 It is often the
case that DNS-SD/mDNS query results are displayed to the user through the
UI.=C2=A0 The OLD language simply notes that various, otherwise legal, names may
have a similar appearance (without proposing a solution).

 I suspect it's not a helpful piece of text to have in the document. If you think "l" vs. "1" is fun, wait until you get to &qu= ot;=C3=B8" vs. "=E2=8C=80" vs. "o=CC=B7". The issue of confusable characters upon display is sev= eral layers above what this WG can do something about, and even bringing up the topic in a requirements document suggests that you intend to tackle it. I think you very much should not.

If you still find that a change is necessary, I would first ask what we can merely
delete.=C2=A0 I'm afraid that any additions to this section may require= us to go back to
the WG for further discussion.

So, I suggested above simply removing the second sentence of the first paragraph. I changed the last sentence of the first paragraph because without the second sentence, it doesn't track, but I don't really c= are how you word that. The only other thing I added was "and should look t= o work in using internationalize strings in application protocols [soon-to-be-RFC-draft-ietf-precis-framework]." I am not insistent on that, but I think in reality, if you're going to "support rich internationalized labels" as you do today, looking to the PRECIS work is exactly what you're going to do.

<KEL>I don't have a problem with dele= ting that sentence and patching the prose as necessary.
Hopefully= the chairs and AD will agree.=C2=A0 Are you OK with something like:

NEW

=C2=A0 =C2=A0Devices on different = links may have the same mDNS name (perhaps
=C2=A0 =C2=A0= due to vendor defaults), because link-local mDNS names are only
=C2=A0 =C2=A0guaranteed to be unique on a per-link basis.=C2=A0 This may lead to a local
=C2=A0 =C2=A0l= abel disambiguation problem when results are aggregated (e.g. for
=C2=A0 =C2=A0presentat= ion).

I have more of an issue with the insertion of PRECIS at thi= s late date.=C2=A0 Insofar as that draft
and this one have a comm= on co-author, I think it is reasonable to assume that it will receive
=
full consideration during the solution phase.

Regards, -K-

=C2=A0
All that said, this shouldn't be a heavy lift one way or the other. If your chair (and AD) think that whatever changes I suggest still represent the consensus of the WG, they can say so and you can make the change. If the WG disagrees, I'm sure they will let them know. But I do take the word "DISCUSS" quite seriously: I am ready and willing t= o engage in a discussion with you and the rest of the WG and drive that discussion to completion right quick (in particular, before we all show up in Dallas). Either you'll convince me that this isn't a big deal= and we should leave the text as it is, or I'll convince you that it is a big deal and you should change it, or something in between. The bad outcome is to have an open issue that hasn't been addressed. (I think someone wrote a document about that. [1] ;-).) So let's discuss.

pr

[1] https://datatracker.ietf.org/doc/rfc7282/
--=20
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

--001a114074400ab784051134fdb8-- From nobody Fri Mar 13 17:49:36 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2DC7C1A90CA; Fri, 13 Mar 2015 17:49:29 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8761A90D5; Fri, 13 Mar 2015 17:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.027 X-Spam-Level: X-Spam-Status: No, score=-3.027 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, 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 5zMsMGZPQNMl; Fri, 13 Mar 2015 17:49:25 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B0B1A90CA; Fri, 13 Mar 2015 17:49:25 -0700 (PDT) Received: by obfv9 with SMTP id v9so2257628obf.2; Fri, 13 Mar 2015 17:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=aRYFo9SBeapn38XzPbeZasrYEnMXvBGPgmiXBcne+nc=; b=LKDVoHXd/WRM3h5uBatVsci9huj4RXaw8nfHM6jaCGswvduG4VN73BzA40y5o18/KM AjUGq1Hyk3R7flNw8vQGjrSIXMsA3KdZvccVHSphznGk6UZiovQ4HOlG0zhpc/H2NnwJ 4JfT8csIosyCgGqjHcVzlrhWKM4fJXllmA0fMv03yKqrJCwxbvDwIQTrrQHYiWR/C7KT RDnjBkNd33RazmX4OFin2ylOdzDTcex5ugZNLQryl7bpYsrNeXSYrArUsoP2uBrkZLfL VO3VVUY0Hslyqy2YUilSP1jSF6N/GJS5qHHWc2hNNZrOjgi6gPcE7V9ERXtW5Giiadck nUAQ== MIME-Version: 1.0 X-Received: by 10.202.229.141 with SMTP id c135mr38219126oih.44.1426294164861; Fri, 13 Mar 2015 17:49:24 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.11.136 with HTTP; Fri, 13 Mar 2015 17:49:24 -0700 (PDT) In-Reply-To: <550367EB.3090508@qti.qualcomm.com> References: <20150313174749.2435.7999.idtracker@ietfa.amsl.com> <550367EB.3090508@qti.qualcomm.com> Date: Fri, 13 Mar 2015 20:49:24 -0400 X-Google-Sender-Auth: --OZnCAbo_bkEcE2OTpWJGvvpmw Message-ID: From: Kerry Lynn To: Pete Resnick Content-Type: multipart/alternative; boundary=001a114074400ab784051134fdb8 Archived-At: Cc: "draft-ietf-dnssd-requirements.all" , dnssd@ietf.org, dnssd-chairs , The IESG , Tim Chown Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 14 Mar 2015 00:49:29 -0000 --001a114074400ab784051134fdb8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Mar 13, 2015 at 6:42 PM, Pete Resnick wrote: > Starting with the last question first: > > On 3/13/15 3:07 PM, Kerry Lynn wrote: > > BTW, with the IPR question resolved, did you mean for this to remain a > DISCUSS > or should it be a COMMENT instead? > > > I absolutely meant for this to remain a DISCUSS. I think the current text > is a real problem. > > On Fri, Mar 13, 2015 at 4:41 PM, Kerry Lynn wrote: > >> On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick > > wrote: >> >>> ---------------------------------------------------------------------- >>> DISCUSS: >>> ---------------------------------------------------------------------- >>> >>> >>> Section 5: >>> >>> OLD >>> Devices on different links may have the same mDNS name (perhaps due >>> to vendor defaults), because link-local mDNS names are only >>> guaranteed to be unique on a per-link basis. Also, even devices tha= t >>> are on the same link may have similar-looking names, such as one >>> device with the name "Bill" and another device using the similar- >>> looking name "Bi11" (using the digit "1" in place of the letter "l")= --001a114074400ab784051134fdb8-- From nobody Fri Mar 13 17:58:40 2015 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 0DA931A90F0; Fri, 13 Mar 2015 17:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.01 X-Spam-Level: X-Spam-Status: No, score=-9.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 mEokfj5CkDbf; Fri, 13 Mar 2015 17:58:32 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CCAE1A90E1; Fri, 13 Mar 2015 17:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426294712; x=1457830712; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=tPw8nR3GNVxjElv5oEGBMeENIsxBU8/0hIKqHcpjFKU=; b=V4v0MQwqoO3dQde2rqovcSRejHsI/BkB3lGL+mu46pteo7ESP5QjkfyO ZU0UtSP+YViUZS/TVeigk3vvdGsHJCR2k30ihwXRSOyJk/tyKevEEtB/f tp0ywMz/jrwjT4W5MgGmrpelDllJvuuivVIbXh2xO1wHnBPb+FAB+vWA7 E=; X-IronPort-AV: E=McAfee;i="5600,1067,7739"; a="200426640" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine02.qualcomm.com with ESMTP; 13 Mar 2015 17:58:31 -0700 X-IronPort-AV: E=Sophos; i="5.11,398,1422950400"; d="scan'208,217"; a="31995844" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Mar 2015 17:58:31 -0700 Received: from presnick-mac.wlan.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 13 Mar 2015 17:58:30 -0700 Message-ID: <550387B6.5040303@qti.qualcomm.com> Date: Fri, 13 Mar 2015 17:58:30 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Kerry Lynn References: <20150313174749.2435.7999.idtracker@ietfa.amsl.com> <550367EB.3090508@qti.qualcomm.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040009070900090400070502" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: "draft-ietf-dnssd-requirements.all" , dnssd@ietf.org, dnssd-chairs , The IESG , Tim Chown Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 14 Mar 2015 00:58:36 -0000 --------------040009070900090400070502 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 3/13/15 5:49 PM, Kerry Lynn wrote: >> On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick >> > > wrote: >> >> OLD >> Devices on different links may have the same mDNS name >> (perhaps due >> to vendor defaults), because link-local mDNS names are >> only >> guaranteed to be unique on a per-link basis. Also, >> even devices that >> are on the same link may have similar-looking names, >> such as one >> device with the name "Bill" and another device using >> the similar- >> looking name "Bi11" (using the digit "1" in place of >> the letter "l"). >> This may lead to a local label disambiguation problem >> between >> presented results. >> >> SSD should support rich internationalized labels >> within Service >> Instance Names, as DNS-SD/mDNS does today. SSD must >> not negatively >> impact the global DNS namespace or infrastructure. >> >> NEW >> Devices on different links may have the same mDNS name >> (perhaps due >> to vendor defaults), because link-local mDNS names are >> only >> guaranteed to be unique on a per-link basis. SSD needs >> to deal with >> name collisions beyond local link considerations. >> >> SSD should support rich internationalized labels >> within Service >> Instance Names, as DNS-SD/mDNS does today and should >> look to work in >> using internationalize strings in application protocols >> [soon-to-be-RFC-draft-ietf-precis-framework]. SSD >> must not >> negatively impact the global DNS namespace or >> infrastructure. >> > > I don't have a problem with deleting that sentence and patching the > prose as necessary. > Hopefully the chairs and AD will agree. Are you OK with something like: > > NEW > > Devices on different links may have the same mDNS name (perhaps > due to vendor defaults), because link-local mDNS names are only > guaranteed to be unique on a per-link basis. This may lead to a local > label disambiguation problem when results are aggregated (e.g. for > presentation). Seems perfectly reasonable to me. > I have more of an issue with the insertion of PRECIS at this late > date. Insofar as that draft > and this one have a common co-author, I think it is reasonable to > assume that it will receive > full consideration during the solution phase. I'm not about to hold up the document over that. I think you ought to put it in as a reminder to consider the IETF technology that has been worked on to deal with the issue, but enough folks will certainly remind you later if you forget when it comes time to work on the protocol. :-) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------040009070900090400070502 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 3/13/15 5:49 PM, Kerry Lynn wrote:

On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
OLD
   Devices on different links may have the same mDNS name (perhaps due
   to vendor defaults), because link-local mDNS names are only
   guaranteed to be unique on a per-link basis.  Also, even devices that
   are on the same link may have similar-looking names, such as one
   device with the name "Bill" and another device using the similar-
   looking name "Bi11" (using the digit "1" in place of the letter "l").
   This may lead to a local label disambiguation problem between
   presented results.

   SSD should support rich internationalized labels within Service
   Instance Names, as DNS-SD/mDNS does today.  SSD must not negatively
   impact the global DNS namespace or infrastructure.

NEW
   Devices on different links may have the same mDNS name (perhaps due
   to vendor defaults), because link-local mDNS names are only
   guaranteed to be unique on a per-link basis. SSD needs to deal with
   name collisions beyond local link considerations.

   SSD should support rich internationalized labels within Service
   Instance Names, as DNS-SD/mDNS does today and should look to work in
   using internationalize strings in application protocols
   [soon-to-be-RFC-draft-ietf-precis-framework].  SSD must not
   negatively impact the global DNS namespace or infrastructure.

I don't have a problem with deleting that sentence and patching the prose as necessary.
Hopefully the chairs and AD will agree.  Are you OK with something like:

NEW

   Devices on different links may have the same mDNS name (perhaps
   due to vendor defaults), because link-local mDNS names are only
   guaranteed to be unique on a per-link basis.  This may lead to a local
   label disambiguation problem when results are aggregated (e.g. for
   presentation).

Seems perfectly reasonable to me.

I have more of an issue with the insertion of PRECIS at this late date.  Insofar as that draft
and this one have a common co-author, I think it is reasonable to assume that it will receive
full consideration during the solution phase.

I'm not about to hold up the document over that. I think you ought to put it in as a reminder to consider the IETF technology that has been worked on to deal with the issue, but enough folks will certainly remind you later if you forget when it comes time to work on the protocol. :-)

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------040009070900090400070502-- From nobody Fri Mar 13 17:58:42 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 45CBF1A90E1; Fri, 13 Mar 2015 17:58:36 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA931A90F0; Fri, 13 Mar 2015 17:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.01 X-Spam-Level: X-Spam-Status: No, score=-9.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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 mEokfj5CkDbf; Fri, 13 Mar 2015 17:58:32 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CCAE1A90E1; Fri, 13 Mar 2015 17:58:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1426294712; x=1457830712; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=tPw8nR3GNVxjElv5oEGBMeENIsxBU8/0hIKqHcpjFKU=; b=V4v0MQwqoO3dQde2rqovcSRejHsI/BkB3lGL+mu46pteo7ESP5QjkfyO ZU0UtSP+YViUZS/TVeigk3vvdGsHJCR2k30ihwXRSOyJk/tyKevEEtB/f tp0ywMz/jrwjT4W5MgGmrpelDllJvuuivVIbXh2xO1wHnBPb+FAB+vWA7 E=; X-IronPort-AV: E=McAfee;i="5600,1067,7739"; a="200426640" Received: from ironmsg02-lv.qualcomm.com ([10.47.202.183]) by wolverine02.qualcomm.com with ESMTP; 13 Mar 2015 17:58:31 -0700 X-IronPort-AV: E=Sophos; i="5.11,398,1422950400"; d="scan'208,217"; a="31995844" Received: from nasanexm01f.na.qualcomm.com ([10.85.0.32]) by ironmsg02-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 13 Mar 2015 17:58:31 -0700 Received: from presnick-mac.wlan.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.85.0.32) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 13 Mar 2015 17:58:30 -0700 Message-ID: <550387B6.5040303@qti.qualcomm.com> Date: Fri, 13 Mar 2015 17:58:30 -0700 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Kerry Lynn References: <20150313174749.2435.7999.idtracker@ietfa.amsl.com> <550367EB.3090508@qti.qualcomm.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040009070900090400070502" X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: NASANEXM01C.na.qualcomm.com (10.85.0.83) To NASANEXM01F.na.qualcomm.com (10.85.0.32) Archived-At: Cc: "draft-ietf-dnssd-requirements.all" , dnssd@ietf.org, dnssd-chairs , The IESG , Tim Chown Subject: Re: [dnssd] Pete Resnick's Discuss on draft-ietf-dnssd-requirements-05: (with DISCUSS) 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, 14 Mar 2015 00:58:36 -0000 --------------040009070900090400070502 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit On 3/13/15 5:49 PM, Kerry Lynn wrote: >> On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick >> > > wrote: >> >> OLD >> Devices on different links may have the same mDNS name >> (perhaps due >> to vendor defaults), because link-local mDNS names are >> only >> guaranteed to be unique on a per-link basis. Also, >> even devices that >> are on the same link may have similar-looking names, >> such as one >> device with the name "Bill" and another device using >> the similar- >> looking name "Bi11" (using the digit "1" in place of >> the letter "l"). >> This may lead to a local label disambiguation problem >> between >> presented results. >> >> SSD should support rich internationalized labels >> within Service >> Instance Names, as DNS-SD/mDNS does today. SSD must >> not negatively >> impact the global DNS namespace or infrastructure. >> >> NEW >> Devices on different links may have the same mDNS name >> (perhaps due >> to vendor defaults), because link-local mDNS names are >> only >> guaranteed to be unique on a per-link basis. SSD needs >> to deal with >> name collisions beyond local link considerations. >> >> SSD should support rich internationalized labels >> within Service >> Instance Names, as DNS-SD/mDNS does today and should >> look to work in >> using internationalize strings in application protocols >> [soon-to-be-RFC-draft-ietf-precis-framework]. SSD >> must not >> negatively impact the global DNS namespace or >> infrastructure. >> > > I don't have a problem with deleting that sentence and patching the > prose as necessary. > Hopefully the chairs and AD will agree. Are you OK with something like: > > NEW > > Devices on different links may have the same mDNS name (perhaps > due to vendor defaults), because link-local mDNS names are only > guaranteed to be unique on a per-link basis. This may lead to a local > label disambiguation problem when results are aggregated (e.g. for > presentation). Seems perfectly reasonable to me. > I have more of an issue with the insertion of PRECIS at this late > date. Insofar as that draft > and this one have a common co-author, I think it is reasonable to > assume that it will receive > full consideration during the solution phase. I'm not about to hold up the document over that. I think you ought to put it in as a reminder to consider the IETF technology that has been worked on to deal with the issue, but enough folks will certainly remind you later if you forget when it comes time to work on the protocol. :-) pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------040009070900090400070502 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
On 3/13/15 5:49 PM, Kerry Lynn wrote:

On Fri, Mar 13, 2015 at 1:47 PM, Pete Resnick <presnick@qti.qualcomm.com> wrote:
OLD
   Devices on different links may have the same mDNS name (perhaps due
   to vendor defaults), because link-local mDNS names are only
   guaranteed to be unique on a per-link basis.  Also, even devices that
   are on the same link may have similar-looking names, such as one
   device with the name "Bill" and another device using the similar-
   looking name "Bi11" (using the digit "1" in place of the letter "l").
   This may lead to a local label disambiguation problem between
   presented results.

   SSD should support rich internationalized labels within Service
   Instance Names, as DNS-SD/mDNS does today.  SSD must not negatively
   impact the global DNS namespace or infrastructure.

NEW
   Devices on different links may have the same mDNS name (perhaps due
   to vendor defaults), because link-local mDNS names are only
   guaranteed to be unique on a per-link basis. SSD needs to deal with
   name collisions beyond local link considerations.

   SSD should support rich internationalized labels within Service
   Instance Names, as DNS-SD/mDNS does today and should look to work in
   using internationalize strings in application protocols
   [soon-to-be-RFC-draft-ietf-precis-framework].  SSD must not
   negatively impact the global DNS namespace or infrastructure.

I don't have a problem with deleting that sentence and patching the prose as necessary.
Hopefully the chairs and AD will agree.  Are you OK with something like:

NEW

   Devices on different links may have the same mDNS name (perhaps
   due to vendor defaults), because link-local mDNS names are only
   guaranteed to be unique on a per-link basis.  This may lead to a local
   label disambiguation problem when results are aggregated (e.g. for
   presentation).

Seems perfectly reasonable to me.

I have more of an issue with the insertion of PRECIS at this late date.  Insofar as that draft
and this one have a common co-author, I think it is reasonable to assume that it will receive
full consideration during the solution phase.

I'm not about to hold up the document over that. I think you ought to put it in as a reminder to consider the IETF technology that has been worked on to deal with the issue, but enough folks will certainly remind you later if you forget when it comes time to work on the protocol. :-)

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------040009070900090400070502-- From nobody Fri Mar 13 19:08:58 2015 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 8F2E71A01F6; Fri, 13 Mar 2015 19:08:55 -0700 (PDT) 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 N8lbEs5VfaBs; Fri, 13 Mar 2015 19:08:52 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8924E1A01BA; Fri, 13 Mar 2015 19:08:52 -0700 (PDT) Received: by pdbop1 with SMTP id op1so2134202pdb.2; Fri, 13 Mar 2015 19:08:52 -0700 (PDT) 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=G7fkiLcfFN98k+i5KloXPCSVU6I1Sqvy0vziFluKzjI=; b=XKsfBSflTa31TS+kbMOQSG/k/LangU+gePWNKc2EPZM4nnr6hEiUD2nFck235Lcq1h 38dVjNYqeiQWXIuQQGFKOf28MyrhAls755BRd2rGU/Q6sXbdqR11y0qEZlu2nYP39pv+ vArLYF0qmIS4WSjO31q4LOcWkTkSh+QYVexTouKtRZQ12bwTOuWN6LYOAnySu1D3jivy CnAR5ghOAL+4LL8BptvIFFEJeGW5aoXcvsCaOGUwwuA3tw0vWQWfO3QyBagqHjrxSWFO x6mgXd5VRU0K22lrys1abNSCOo2z00ZBG9hIeyzJzeY3pMNnbK2+r/JsfrDAQFmnOlW4 Sv0Q== X-Received: by 10.67.7.195 with SMTP id de3mr2959276pad.79.1426298932125; Fri, 13 Mar 2015 19:08:52 -0700 (PDT) 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 cz10sm5561670pdb.9.2015.03.13.19.08.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Mar 2015 19:08:51 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: Date: Fri, 13 Mar 2015 19:08:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> To: Kerry Lynn X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Tim Chown , The IESG , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 14 Mar 2015 02:08:55 -0000 > On Mar 13, 2015, at 1:41 PM, Kerry Lynn wrote: >=20 > On Thu, Mar 12, 2015 at 2:24 PM, Douglas Otis = wrote: >=20 > > On Mar 10, 2015, at 4:04 PM, Stephen Farrell = wrote: > > > > Stephen Farrell has entered the following ballot position for > > draft-ietf-dnssd-requirements-05: No Objection > > > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut = this > > introductory paragraph, however.) > > > > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > > > > - section 6 intro: I'm not sure I buy that the set of relevant > > threats is only a union as stated. There are often new threats > > in new environments. > > > The current text reads "likely to include the union...", not = "only the union..." >=20 > > - 6.6: I think one can also leak private information by > > searching in too broad a scope, e.g. if the client can be > > fingerprinted allowing re-identification. I think that's > > different from the example given, and maybe worth noting too. >=20 > The current plan is to produce a separate security threats = document; see > https://tools.ietf.org/id/draft-rafiee-dnssd-mdns-threatmodel-01.txt. = We will make > sure to include this issue (although I'm not sure at this point if/how = a DNS-SD > query would differ significantly from a DNS query in that respect). >=20 > I feel that the current Requirements draft represents a consensus of = the WG (but > not unanimity, as can be seen below): >=20 > Dear Stephen, >=20 > I agree with your statement and, based on our tests, these concerns = are very real! >=20 > IPv6 can not be defended in the same manner as with IPv4. With = Homenet, an > effort was made to ensure address selection preferences critical when > publishing addresses within DNS but omitted from the requirements = documents. >=20 > Doug, can your concern be addressed by specifically stating a = requirement > that advertising a service in the global internet should be an opt-in = decision of the > user, as suggested by Benoit? Dear Kerry,=20 Thank you for you comments. See reply below.=20 > The statement made in Section 6.1 is poorly considered. > ,-- > Section 6.1 > ... > Note that discovery of a service does not necessarily imply that the > service is reachable by, or can be connected to, or can be used by, a > given client. Specific access control mechanisms are out of scope of > this document. > '--- >=20 > Let's take these "poorly considered" assertions one-by-one: > - reachable (a route may not exist to the advertised address) > - connected to (the device may be offline) > - used by (the user of the service may lack authorization) > - access control is out of scope (not in our charter) > Which of these do you specifically have an issue with? Controlling access becomes unmanageable with automatic expansion of -- a) discovery of all network details reported by mDNS beyond local = networks b) routing beyond local networks using all mDNS details conveyed to DNS For example, an older Mac Book excluded from receiving security updates=20= fixing an NTP DDOS vulnerability, a concern that applies equally to any consumer device placed at risk by unwarrantedly increased discovery. Examples might include printers or a baby monitors heavily depending on access limited to local networks which conflicts with a goal of reduced dependence on multi-cast discovery.=20 A typical IPv6 router is unable to differentiate hosts given a routable address published in DNS by an mDNS proxy. To safely bridge this gap, address preferences MUST USE the smallest practical scope available. = The=20 ability to do so MUST BE a requirement. As such, direct Internet access would require other methods be used. This means there MUST BE a requirement to understand address scope differentiation. A requirement related to mDNS --> DNS publication that is missing. =20 Once a malefactor discovers addresses having global scope not uniquely identifiable at a firewall, an entire class of devices immediately = become vulnerable.=20 As with Homenet, mDNS to DNS proxy should prefer the most conservative = scope that meets the desired goals. When done correctly, this should not require an Internet Opt-in = mechanism=20 that is impractical for hosts assigned global IPv6 addresses. > Or the false statement: > ,-- > 6.5. Access Control > ... > While controlling access to an advertised service is outside the > scope of DNS-SD, we note that access control today often is provided > by existing site infrastructure (e.g., router access control lists, > firewalls) and/or by service-specific mechanisms (e.g., user > authentication to the service). For example, networked printers can > control access via a user-id and password. Apple's software supports > such access control for USB printers shared via Mac OS X Printer > Sharing, as do many networked printers themselves. So the reliance > on existing service-specific security mechanisms (i.e. outside the > scope of DNS-SD) does not create new security considerations. > '--- >=20 > Most printers DO NOT offer user-id/password access mechanisms and = often > IPv6 support removes access control lists. Homenet and Apples BTMM > make use of an important overlay approach being ignored both here and = with > the the insecure UPnP. For this protocol to safely interoperate, an > overlay approach must be supported. This approach might use ULAs, for > example. For this to work properly, locally defined addresses must be > preferred when publishing in DNS. >=20 > As previously presented, it is minor fix to correct this oversight. >=20 > Doug, you have had ample opportunity to argue your position = before > the WG and again during WGLC. Your concern has been duly noted, but = it > is not the consensus of the WG to mandate a particular solution in an > *informative* requirements draft. The suggestion was to consider Homenet and to leverage their consensus. There was very little discussion within this WG, other than to deny = concerns at the beginning and final hours. A point in time which excluded my = participation due to momentary health issues. > To your point about specific devices lacking access control = mechanisms, my > personal response would be to a) mitigate that problem with an = appliance (such > as described in = http://spectrum.ieee.org/telecom/security/how-to-build-a-safer-internet-of= -things), > b) put it behind a device that implements access control (e.g. a Mac- = or PC-to- > USB print server), c) get a printer that supports access control (yes, = they do exist), > or d) don't advertise the service beyond the local link. Firewall policies white-listing specific IPv6 addresses is not = practical. This is why=20 such a feature is often excluded in IPv6 supported devices, yet present = with IPv4. > Note that in the topologies we're specifically targeting (enterprise, = higher ed) > implementing an overlay is no guarantee that an adversary with access = to the > network won't be able to use your consumables (ink & paper). Doing this for higher education is great. However, there is no reason = this can't be done in a safer manner by requiring a few basic functional requirements = still missing. See: RFC7368 Section 3.6.6. ULAs as a Hint of Connection Origin RFC7084 Section 4.1 General Requirements RFC7068 Section 4.3. LAN-Side Configuration RFC4864 Section 3.2. Unique Local Addresses Omitting proper address selection rules will not ensure basic = deployments offer desired security. This consideration was omitted in = both the Hybrid Proxy and the requirements documents. Threat related = documents should also include header compliance requirements as = specified by RA Guard RFC7113 also omitted by this draft to better = ensure administrative control of host naming conventions in lieu of IDNA = naming restrictions. Again, the issue is to get ahead of security threats. We have the = opportunity to do this correctly - and at virtually no cost. If we = wait, it will be deployed, and exploited at great cost. Regards, Douglas Otis= From nobody Fri Mar 13 19:09:02 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id ED9DF1A01BA; Fri, 13 Mar 2015 19:08:55 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2E71A01F6; Fri, 13 Mar 2015 19:08:55 -0700 (PDT) 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 N8lbEs5VfaBs; Fri, 13 Mar 2015 19:08:52 -0700 (PDT) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8924E1A01BA; Fri, 13 Mar 2015 19:08:52 -0700 (PDT) Received: by pdbop1 with SMTP id op1so2134202pdb.2; Fri, 13 Mar 2015 19:08:52 -0700 (PDT) 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=G7fkiLcfFN98k+i5KloXPCSVU6I1Sqvy0vziFluKzjI=; b=XKsfBSflTa31TS+kbMOQSG/k/LangU+gePWNKc2EPZM4nnr6hEiUD2nFck235Lcq1h 38dVjNYqeiQWXIuQQGFKOf28MyrhAls755BRd2rGU/Q6sXbdqR11y0qEZlu2nYP39pv+ vArLYF0qmIS4WSjO31q4LOcWkTkSh+QYVexTouKtRZQ12bwTOuWN6LYOAnySu1D3jivy CnAR5ghOAL+4LL8BptvIFFEJeGW5aoXcvsCaOGUwwuA3tw0vWQWfO3QyBagqHjrxSWFO x6mgXd5VRU0K22lrys1abNSCOo2z00ZBG9hIeyzJzeY3pMNnbK2+r/JsfrDAQFmnOlW4 Sv0Q== X-Received: by 10.67.7.195 with SMTP id de3mr2959276pad.79.1426298932125; Fri, 13 Mar 2015 19:08:52 -0700 (PDT) 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 cz10sm5561670pdb.9.2015.03.13.19.08.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 13 Mar 2015 19:08:51 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: Date: Fri, 13 Mar 2015 19:08:49 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> To: Kerry Lynn X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Tim Chown , The IESG , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 14 Mar 2015 02:08:56 -0000 > On Mar 13, 2015, at 1:41 PM, Kerry Lynn wrote: >=20 > On Thu, Mar 12, 2015 at 2:24 PM, Douglas Otis = wrote: >=20 > > On Mar 10, 2015, at 4:04 PM, Stephen Farrell = wrote: > > > > Stephen Farrell has entered the following ballot position for > > draft-ietf-dnssd-requirements-05: No Objection > > > > When responding, please keep the subject line intact and reply to = all > > email addresses included in the To and CC lines. (Feel free to cut = this > > introductory paragraph, however.) > > > > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > The document, along with other ballot positions, can be found here: > > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > > > = ---------------------------------------------------------------------- > > COMMENT: > > = ---------------------------------------------------------------------- > > > > - section 6 intro: I'm not sure I buy that the set of relevant > > threats is only a union as stated. There are often new threats > > in new environments. > > > The current text reads "likely to include the union...", not = "only the union..." >=20 > > - 6.6: I think one can also leak private information by > > searching in too broad a scope, e.g. if the client can be > > fingerprinted allowing re-identification. I think that's > > different from the example given, and maybe worth noting too. >=20 > The current plan is to produce a separate security threats = document; see > https://tools.ietf.org/id/draft-rafiee-dnssd-mdns-threatmodel-01.txt. = We will make > sure to include this issue (although I'm not sure at this point if/how = a DNS-SD > query would differ significantly from a DNS query in that respect). >=20 > I feel that the current Requirements draft represents a consensus of = the WG (but > not unanimity, as can be seen below): >=20 > Dear Stephen, >=20 > I agree with your statement and, based on our tests, these concerns = are very real! >=20 > IPv6 can not be defended in the same manner as with IPv4. With = Homenet, an > effort was made to ensure address selection preferences critical when > publishing addresses within DNS but omitted from the requirements = documents. >=20 > Doug, can your concern be addressed by specifically stating a = requirement > that advertising a service in the global internet should be an opt-in = decision of the > user, as suggested by Benoit? Dear Kerry,=20 Thank you for you comments. See reply below.=20 > The statement made in Section 6.1 is poorly considered. > ,-- > Section 6.1 > ... > Note that discovery of a service does not necessarily imply that the > service is reachable by, or can be connected to, or can be used by, a > given client. Specific access control mechanisms are out of scope of > this document. > '--- >=20 > Let's take these "poorly considered" assertions one-by-one: > - reachable (a route may not exist to the advertised address) > - connected to (the device may be offline) > - used by (the user of the service may lack authorization) > - access control is out of scope (not in our charter) > Which of these do you specifically have an issue with? Controlling access becomes unmanageable with automatic expansion of -- a) discovery of all network details reported by mDNS beyond local = networks b) routing beyond local networks using all mDNS details conveyed to DNS For example, an older Mac Book excluded from receiving security updates=20= fixing an NTP DDOS vulnerability, a concern that applies equally to any consumer device placed at risk by unwarrantedly increased discovery. Examples might include printers or a baby monitors heavily depending on access limited to local networks which conflicts with a goal of reduced dependence on multi-cast discovery.=20 A typical IPv6 router is unable to differentiate hosts given a routable address published in DNS by an mDNS proxy. To safely bridge this gap, address preferences MUST USE the smallest practical scope available. = The=20 ability to do so MUST BE a requirement. As such, direct Internet access would require other methods be used. This means there MUST BE a requirement to understand address scope differentiation. A requirement related to mDNS --> DNS publication that is missing. =20 Once a malefactor discovers addresses having global scope not uniquely identifiable at a firewall, an entire class of devices immediately = become vulnerable.=20 As with Homenet, mDNS to DNS proxy should prefer the most conservative = scope that meets the desired goals. When done correctly, this should not require an Internet Opt-in = mechanism=20 that is impractical for hosts assigned global IPv6 addresses. > Or the false statement: > ,-- > 6.5. Access Control > ... > While controlling access to an advertised service is outside the > scope of DNS-SD, we note that access control today often is provided > by existing site infrastructure (e.g., router access control lists, > firewalls) and/or by service-specific mechanisms (e.g., user > authentication to the service). For example, networked printers can > control access via a user-id and password. Apple's software supports > such access control for USB printers shared via Mac OS X Printer > Sharing, as do many networked printers themselves. So the reliance > on existing service-specific security mechanisms (i.e. outside the > scope of DNS-SD) does not create new security considerations. > '--- >=20 > Most printers DO NOT offer user-id/password access mechanisms and = often > IPv6 support removes access control lists. Homenet and Apples BTMM > make use of an important overlay approach being ignored both here and = with > the the insecure UPnP. For this protocol to safely interoperate, an > overlay approach must be supported. This approach might use ULAs, for > example. For this to work properly, locally defined addresses must be > preferred when publishing in DNS. >=20 > As previously presented, it is minor fix to correct this oversight. >=20 > Doug, you have had ample opportunity to argue your position = before > the WG and again during WGLC. Your concern has been duly noted, but = it > is not the consensus of the WG to mandate a particular solution in an > *informative* requirements draft. The suggestion was to consider Homenet and to leverage their consensus. There was very little discussion within this WG, other than to deny = concerns at the beginning and final hours. A point in time which excluded my = participation due to momentary health issues. > To your point about specific devices lacking access control = mechanisms, my > personal response would be to a) mitigate that problem with an = appliance (such > as described in = http://spectrum.ieee.org/telecom/security/how-to-build-a-safer-internet-of= -things), > b) put it behind a device that implements access control (e.g. a Mac- = or PC-to- > USB print server), c) get a printer that supports access control (yes, = they do exist), > or d) don't advertise the service beyond the local link. Firewall policies white-listing specific IPv6 addresses is not = practical. This is why=20 such a feature is often excluded in IPv6 supported devices, yet present = with IPv4. > Note that in the topologies we're specifically targeting (enterprise, = higher ed) > implementing an overlay is no guarantee that an adversary with access = to the > network won't be able to use your consumables (ink & paper). Doing this for higher education is great. However, there is no reason = this can't be done in a safer manner by requiring a few basic functional requirements = still missing. See: RFC7368 Section 3.6.6. ULAs as a Hint of Connection Origin RFC7084 Section 4.1 General Requirements RFC7068 Section 4.3. LAN-Side Configuration RFC4864 Section 3.2. Unique Local Addresses Omitting proper address selection rules will not ensure basic = deployments offer desired security. This consideration was omitted in = both the Hybrid Proxy and the requirements documents. Threat related = documents should also include header compliance requirements as = specified by RA Guard RFC7113 also omitted by this draft to better = ensure administrative control of host naming conventions in lieu of IDNA = naming restrictions. Again, the issue is to get ahead of security threats. We have the = opportunity to do this correctly - and at virtually no cost. If we = wait, it will be deployed, and exploited at great cost. Regards, Douglas Otis= From nobody Mon Mar 16 02:38:33 2015 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 F1AA61A86E0; Mon, 16 Mar 2015 02:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 DbukVFdu248R; Mon, 16 Mar 2015 02:38:29 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56521A0111; Mon, 16 Mar 2015 02:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12091; q=dns/txt; s=iport; t=1426498709; x=1427708309; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=nqtRjax/yYpzG88JJF3ndaY4Df7OcetOaQqVc881D34=; b=VB7fh7wYdTKx8m7qZF9RdO/lVbcRgrFXHwMH6pUecXAtyxHXr++6Bot+ fxOK7oDfHuN5Cb4rVCAweZ5YgX7kPDx0UZObkNpU21RRIqU6RBlxz1oU9 okOL33hc6hQQO9VBfIh7Qc5gvnWRzXBNg6KrzpNGPRBE0aE3S4EpO9lvU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CuBAB5owZV/xbLJq1bg1hagwy3YolXAQmFdAKBcgEBAQEBAX2EEAEBBAEBASBLCgEQCQIOCgkWCAMCAgkDAgECARUfEQYNAQUCAQEFiCYNjDycbpp/AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXhA8RAVAHgmiBRQWGDogjhXSFe4EbOYJygjMhjHojgjKBPT0xAYEKgTgBAQE X-IronPort-AV: E=Sophos;i="5.11,407,1422921600"; d="scan'208,217";a="387323213" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 16 Mar 2015 09:38:26 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2G9cQaq020935; Mon, 16 Mar 2015 09:38:26 GMT Message-ID: <5506A490.5060004@cisco.com> Date: Mon, 16 Mar 2015 10:38:24 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kerry Lynn References: <20150312141244.8415.9203.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060006070808010706060401" Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Tim Chown , The IESG , jiangsheng@huawei.com Subject: Re: [dnssd] Benoit Claise's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 16 Mar 2015 09:38:32 -0000 This is a multi-part message in MIME format. --------------060006070808010706060401 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Kerry, > On Thu, Mar 12, 2015 at 10:12 AM, Benoit Claise > wrote: > > Benoit Claise has entered the following ballot position for > draft-ietf-dnssd-requirements-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The IETF should definitively focus on this problem space. Thanks. > > Some comments below: > > > - Section 4, REQ8 looks a very fundemental requirement for all service > discovery mechanism. It does not look like a specific requirement for > SSD > > Are you suggesting we should remove REQ8? This specifically includes > M2M, which may not be a requirement of *all* SD mechanisms. No need to remove it. > > - Some of the requirements will be hard to fulfill, if taken > literally: > REQ9: SSD should operate efficiently on common link layers > and link > types. > > Are you suggesting we should remove REQ9? I think this specifically > relates > to reducing the dependence on multicast. I'm just asking: what does "efficiently" mean? How are you going to evaluate this criteria? > > REQ12: SSD should enable a way to provide a consistent user > experience whether local or remote services are being > discovered. > > I agree; this one seems hard. But I still think we should try to > satisfy it. > > - Very surprised that the Security Considerations don't lead to formal > requirements > For example, in connection with "6.1 Scope of Discovery" and "6.5 > Access > Control", I was expecting a requirement such as > REQXX: the owner of the advertised service must be able to > configure > whether his service should be advertised beyond the local link > > I think you make a good point. As I read REQ1 & REQ2, it seems that in a > typical multi-subnet residential case the user might have to take some > action > to make a service visible beyond the local link or site. OTOH, it > might be a > good idea to explicitly say that a user must OPT-IN to global > advertisements. > > BTW, I believe it's in plan to produce a separate threat analysis document > which may help clarify additional requirements. Regards, Benoit > > Regards, Kerry Lynn > > The way the requirements are specified: all services will be > visible to > everybody, and the access control will accept/reject the service > request. > That reminds me of the typical airport wireless situation: you try > every > wireless network to see which one will accept you. > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > --------------060006070808010706060401 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Kerry,
On Thu, Mar 12, 2015 at 10:12 AM, Benoit Claise <bclaise@cisco.com> wrote:
Benoit Claise has entered the following ballot position for
draft-ietf-dnssd-requirements-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The IETF should definitively focus on this problem space. Thanks.

Some comments below:
 
- Section 4, REQ8 looks a very fundemental requirement for all service
discovery mechanism. It does not look like a specific requirement for
SSD

Are you suggesting we should remove REQ8?  This specifically includes
M2M, which may not be a requirement of *all* SD mechanisms.
No need to remove it.
 
- Some of the requirements will be hard to fulfill, if taken literally:
   REQ9:   SSD should operate efficiently on common link layers and link
           types.

Are you suggesting we should remove REQ9?  I think this specifically relates
to reducing the dependence on multicast.
I'm just asking: what does "efficiently" mean? How are you going to evaluate this criteria?
 
   REQ12:  SSD should enable a way to provide a consistent user
           experience whether local or remote services are being
           discovered.

I agree; this one seems hard.  But I still think we should try to satisfy it.
 
- Very surprised that the Security Considerations don't lead to formal
requirements
For example, in connection with "6.1 Scope of Discovery" and "6.5 Access
Control", I was expecting a requirement such as
   REQXX:  the owner of the advertised service must be able to configure
whether his service should be advertised beyond the local link

I think you make a good point.  As I read REQ1 & REQ2, it seems that in a
typical multi-subnet residential case the user might have to take some action
to make a service visible beyond the local link or site.  OTOH, it might be a
good idea to explicitly say that a user must OPT-IN to global advertisements.

BTW, I believe it's in plan to produce a separate threat analysis document
which may help clarify additional requirements.
Regards, Benoit

Regards, Kerry Lynn
 
The way the requirements are specified: all services will be visible to
everybody, and the access control will accept/reject the service request.
That reminds me of the typical airport wireless situation: you try every
wireless network to see which one will accept you.


_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd


--------------060006070808010706060401-- From nobody Mon Mar 16 02:38:37 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 1F7791A86E6; Mon, 16 Mar 2015 02:38:32 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AA61A86E0; Mon, 16 Mar 2015 02:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 DbukVFdu248R; Mon, 16 Mar 2015 02:38:29 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56521A0111; Mon, 16 Mar 2015 02:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12091; q=dns/txt; s=iport; t=1426498709; x=1427708309; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=nqtRjax/yYpzG88JJF3ndaY4Df7OcetOaQqVc881D34=; b=VB7fh7wYdTKx8m7qZF9RdO/lVbcRgrFXHwMH6pUecXAtyxHXr++6Bot+ fxOK7oDfHuN5Cb4rVCAweZ5YgX7kPDx0UZObkNpU21RRIqU6RBlxz1oU9 okOL33hc6hQQO9VBfIh7Qc5gvnWRzXBNg6KrzpNGPRBE0aE3S4EpO9lvU k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CuBAB5owZV/xbLJq1bg1hagwy3YolXAQmFdAKBcgEBAQEBAX2EEAEBBAEBASBLCgEQCQIOCgkWCAMCAgkDAgECARUfEQYNAQUCAQEFiCYNjDycbpp/AQEBAQEBAQEBAQEBAQEBAQEBAQEBF4sXhA8RAVAHgmiBRQWGDogjhXSFe4EbOYJygjMhjHojgjKBPT0xAYEKgTgBAQE X-IronPort-AV: E=Sophos;i="5.11,407,1422921600"; d="scan'208,217";a="387323213" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 16 Mar 2015 09:38:26 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t2G9cQaq020935; Mon, 16 Mar 2015 09:38:26 GMT Message-ID: <5506A490.5060004@cisco.com> Date: Mon, 16 Mar 2015 10:38:24 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kerry Lynn References: <20150312141244.8415.9203.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060006070808010706060401" Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Tim Chown , The IESG , jiangsheng@huawei.com Subject: Re: [dnssd] Benoit Claise's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 16 Mar 2015 09:38:32 -0000 This is a multi-part message in MIME format. --------------060006070808010706060401 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Kerry, > On Thu, Mar 12, 2015 at 10:12 AM, Benoit Claise > wrote: > > Benoit Claise has entered the following ballot position for > draft-ietf-dnssd-requirements-05: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut > this > introductory paragraph, however.) > > > Please refer to > http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The IETF should definitively focus on this problem space. Thanks. > > Some comments below: > > > - Section 4, REQ8 looks a very fundemental requirement for all service > discovery mechanism. It does not look like a specific requirement for > SSD > > Are you suggesting we should remove REQ8? This specifically includes > M2M, which may not be a requirement of *all* SD mechanisms. No need to remove it. > > - Some of the requirements will be hard to fulfill, if taken > literally: > REQ9: SSD should operate efficiently on common link layers > and link > types. > > Are you suggesting we should remove REQ9? I think this specifically > relates > to reducing the dependence on multicast. I'm just asking: what does "efficiently" mean? How are you going to evaluate this criteria? > > REQ12: SSD should enable a way to provide a consistent user > experience whether local or remote services are being > discovered. > > I agree; this one seems hard. But I still think we should try to > satisfy it. > > - Very surprised that the Security Considerations don't lead to formal > requirements > For example, in connection with "6.1 Scope of Discovery" and "6.5 > Access > Control", I was expecting a requirement such as > REQXX: the owner of the advertised service must be able to > configure > whether his service should be advertised beyond the local link > > I think you make a good point. As I read REQ1 & REQ2, it seems that in a > typical multi-subnet residential case the user might have to take some > action > to make a service visible beyond the local link or site. OTOH, it > might be a > good idea to explicitly say that a user must OPT-IN to global > advertisements. > > BTW, I believe it's in plan to produce a separate threat analysis document > which may help clarify additional requirements. Regards, Benoit > > Regards, Kerry Lynn > > The way the requirements are specified: all services will be > visible to > everybody, and the access control will accept/reject the service > request. > That reminds me of the typical airport wireless situation: you try > every > wireless network to see which one will accept you. > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > --------------060006070808010706060401 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi Kerry,
On Thu, Mar 12, 2015 at 10:12 AM, Benoit Claise <bclaise@cisco.com> wrote:
Benoit Claise has entered the following ballot position for
draft-ietf-dnssd-requirements-05: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

The IETF should definitively focus on this problem space. Thanks.

Some comments below:
 
- Section 4, REQ8 looks a very fundemental requirement for all service
discovery mechanism. It does not look like a specific requirement for
SSD

Are you suggesting we should remove REQ8?  This specifically includes
M2M, which may not be a requirement of *all* SD mechanisms.
No need to remove it.
 
- Some of the requirements will be hard to fulfill, if taken literally:
   REQ9:   SSD should operate efficiently on common link layers and link
           types.

Are you suggesting we should remove REQ9?  I think this specifically relates
to reducing the dependence on multicast.
I'm just asking: what does "efficiently" mean? How are you going to evaluate this criteria?
 
   REQ12:  SSD should enable a way to provide a consistent user
           experience whether local or remote services are being
           discovered.

I agree; this one seems hard.  But I still think we should try to satisfy it.
 
- Very surprised that the Security Considerations don't lead to formal
requirements
For example, in connection with "6.1 Scope of Discovery" and "6.5 Access
Control", I was expecting a requirement such as
   REQXX:  the owner of the advertised service must be able to configure
whether his service should be advertised beyond the local link

I think you make a good point.  As I read REQ1 & REQ2, it seems that in a
typical multi-subnet residential case the user might have to take some action
to make a service visible beyond the local link or site.  OTOH, it might be a
good idea to explicitly say that a user must OPT-IN to global advertisements.

BTW, I believe it's in plan to produce a separate threat analysis document
which may help clarify additional requirements.
Regards, Benoit

Regards, Kerry Lynn
 
The way the requirements are specified: all services will be visible to
everybody, and the access control will accept/reject the service request.
That reminds me of the typical airport wireless situation: you try every
wireless network to see which one will accept you.


_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd


--------------060006070808010706060401-- From nobody Mon Mar 16 11:10:33 2015 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 B65AF1A89A8; Mon, 16 Mar 2015 11:10:31 -0700 (PDT) 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 vGDOOuAUqdNk; Mon, 16 Mar 2015 11:10:30 -0700 (PDT) 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 2E1741A89AA; Mon, 16 Mar 2015 11:10:29 -0700 (PDT) Received: from [192.168.15.226] (64.203.236.12.static-pool-1.pool.hargray.net [64.203.236.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id D2D40205B; Mon, 16 Mar 2015 14:06:22 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DD4F769E-558B-461E-9DD5-8BFD86260D10"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Tom Pusateri In-Reply-To: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> Date: Mon, 16 Mar 2015 14:10:24 -0400 Message-Id: <1E100FC1-888D-4FFE-80DB-9AAC8EB99BA5@bangj.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> To: Stephen Farrell , Kerry Lynn X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , Tim Chown Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 16 Mar 2015 18:10:31 -0000 --Apple-Mail=_DD4F769E-558B-461E-9DD5-8BFD86260D10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 10, 2015, at 7:04 PM, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-dnssd-requirements-05: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - section 6 intro: I'm not sure I buy that the set of relevant > threats is only a union as stated. There are often new threats > in new environments. >=20 Maybe this text would be more clear for the introduction: Insofar as SSD may automatically gather DNS-SD resource records and publish them over a wide area, the security issues that could be discussed here include the security issues already discussed in the Multicast DNS and DNS-Based Service Discovery specifications. We will not re-discuss those issues here. Please see those specifications for a detailed discussion of those common issues. In this section we will discuss new potential threats that are posed by deploying DNS-SD over multiple links or by automating DNS-SD administration. > - 6.6: I think one can also leak private information by > searching in too broad a scope, e.g. if the client can be > fingerprinted allowing re-identification. I think that's > different from the example given, and maybe worth noting too. The scope of the search is based on the domain name in the request and = is perfectly controllable by the client. Unicast queries for PTR service = records in no way leaks any more private information about the client = than unicast queries for A records. Thanks, Tom --Apple-Mail=_DD4F769E-558B-461E-9DD5-8BFD86260D10 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 iQEcBAEBAgAGBQJVBxyRAAoJEPk0GMVmUuYMYg0IAKlNCZAqOAdPrZhz3OE5rYrk aV2xfuGv/L7UF9jwuBrfYYfkx7RLfk9MdDTJJTTlTRO07xdJL9eZPqIalGvzXXKq 2D3Ex9EzsXg/jxXCBr1RMIeHsuisqixFqjxYjjkEpN2SdNWOGk5EkweQG/SomLim 7St4Cti8aD5tHwZJSXC0AKyGO3urnC6t2P0AkCMqbM/Cy1Edb0Vi/cmuyLE3APrb SHpHoPYI7cJNjAomHte9JdAYJLaUuEa0KpxUtiZS8jSVknDHq88ya47HBB8luOzF 4r7z+G7255NxvX1qgAgwa4j3FRUo8tVNOlQ/kFrHl+6qXCwrY01hje9Z32zVD0s= =QXY0 -----END PGP SIGNATURE----- --Apple-Mail=_DD4F769E-558B-461E-9DD5-8BFD86260D10-- From nobody Mon Mar 16 11:10:37 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E68BE1A89AA; Mon, 16 Mar 2015 11:10:31 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B65AF1A89A8; Mon, 16 Mar 2015 11:10:31 -0700 (PDT) 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 vGDOOuAUqdNk; Mon, 16 Mar 2015 11:10:30 -0700 (PDT) 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 2E1741A89AA; Mon, 16 Mar 2015 11:10:29 -0700 (PDT) Received: from [192.168.15.226] (64.203.236.12.static-pool-1.pool.hargray.net [64.203.236.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id D2D40205B; Mon, 16 Mar 2015 14:06:22 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_DD4F769E-558B-461E-9DD5-8BFD86260D10"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Tom Pusateri In-Reply-To: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> Date: Mon, 16 Mar 2015 14:10:24 -0400 Message-Id: <1E100FC1-888D-4FFE-80DB-9AAC8EB99BA5@bangj.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> To: Stephen Farrell , Kerry Lynn X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , Tim Chown Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 16 Mar 2015 18:10:32 -0000 --Apple-Mail=_DD4F769E-558B-461E-9DD5-8BFD86260D10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 10, 2015, at 7:04 PM, Stephen Farrell = wrote: >=20 > Stephen Farrell has entered the following ballot position for > draft-ietf-dnssd-requirements-05: No Objection >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - section 6 intro: I'm not sure I buy that the set of relevant > threats is only a union as stated. There are often new threats > in new environments. >=20 Maybe this text would be more clear for the introduction: Insofar as SSD may automatically gather DNS-SD resource records and publish them over a wide area, the security issues that could be discussed here include the security issues already discussed in the Multicast DNS and DNS-Based Service Discovery specifications. We will not re-discuss those issues here. Please see those specifications for a detailed discussion of those common issues. In this section we will discuss new potential threats that are posed by deploying DNS-SD over multiple links or by automating DNS-SD administration. > - 6.6: I think one can also leak private information by > searching in too broad a scope, e.g. if the client can be > fingerprinted allowing re-identification. I think that's > different from the example given, and maybe worth noting too. The scope of the search is based on the domain name in the request and = is perfectly controllable by the client. Unicast queries for PTR service = records in no way leaks any more private information about the client = than unicast queries for A records. Thanks, Tom --Apple-Mail=_DD4F769E-558B-461E-9DD5-8BFD86260D10 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 iQEcBAEBAgAGBQJVBxyRAAoJEPk0GMVmUuYMYg0IAKlNCZAqOAdPrZhz3OE5rYrk aV2xfuGv/L7UF9jwuBrfYYfkx7RLfk9MdDTJJTTlTRO07xdJL9eZPqIalGvzXXKq 2D3Ex9EzsXg/jxXCBr1RMIeHsuisqixFqjxYjjkEpN2SdNWOGk5EkweQG/SomLim 7St4Cti8aD5tHwZJSXC0AKyGO3urnC6t2P0AkCMqbM/Cy1Edb0Vi/cmuyLE3APrb SHpHoPYI7cJNjAomHte9JdAYJLaUuEa0KpxUtiZS8jSVknDHq88ya47HBB8luOzF 4r7z+G7255NxvX1qgAgwa4j3FRUo8tVNOlQ/kFrHl+6qXCwrY01hje9Z32zVD0s= =QXY0 -----END PGP SIGNATURE----- --Apple-Mail=_DD4F769E-558B-461E-9DD5-8BFD86260D10-- From nobody Mon Mar 16 12:52:27 2015 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 8C0781A9057; Mon, 16 Mar 2015 12:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.861 X-Spam-Level: X-Spam-Status: No, score=0.861 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 TnDBz8MTi9ch; Mon, 16 Mar 2015 12:52:21 -0700 (PDT) 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 01F791A1B78; Mon, 16 Mar 2015 12:52:21 -0700 (PDT) Received: from [192.168.1.123] (unknown [216.16.214.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 0E22A208C; Mon, 16 Mar 2015 15:48:06 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FEADF599-6400-4DB6-AF1D-D7A20ACBC882"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Tom Pusateri In-Reply-To: <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> Date: Mon, 16 Mar 2015 15:52:09 -0400 Message-Id: References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Kerry Lynn , dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Tim Chown , The IESG , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 16 Mar 2015 19:52:23 -0000 --Apple-Mail=_FEADF599-6400-4DB6-AF1D-D7A20ACBC882 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 13, 2015, at 10:08 PM, Douglas Otis = wrote: >=20 >=20 >> On Mar 13, 2015, at 1:41 PM, Kerry Lynn wrote: >>=20 >> On Thu, Mar 12, 2015 at 2:24 PM, Douglas Otis = wrote: >>=20 >> Dear Stephen, >>=20 >> I agree with your statement and, based on our tests, these concerns = are very real! >>=20 >> IPv6 can not be defended in the same manner as with IPv4. With = Homenet, an >> effort was made to ensure address selection preferences critical when >> publishing addresses within DNS but omitted from the requirements = documents. >>=20 >> Doug, can your concern be addressed by specifically stating a = requirement >> that advertising a service in the global internet should be an opt-in = decision of the >> user, as suggested by Benoit? I'm not sure how practical this is. In order to work with existing = service advertisements, these decisions should be made in the device = that translates the mDNS advertisements not the device that originates = the advertisement. But there is plenty of room for policy controls in = the translation device to filter and provide access control based on = local criteria. > Dear Kerry, >=20 > Thank you for you comments. See reply below. >=20 >> The statement made in Section 6.1 is poorly considered. >> ,-- >> Section 6.1 >> ... >> Note that discovery of a service does not necessarily imply that the >> service is reachable by, or can be connected to, or can be used by, a >> given client. Specific access control mechanisms are out of scope of >> this document. >> '--- >>=20 >> Let's take these "poorly considered" assertions one-by-one: >> - reachable (a route may not exist to the advertised address) >> - connected to (the device may be offline) >> - used by (the user of the service may lack authorization) >> - access control is out of scope (not in our charter) >> Which of these do you specifically have an issue with? >=20 > Controlling access becomes unmanageable with automatic expansion of -- >=20 > a) discovery of all network details reported by mDNS beyond local = networks >=20 > b) routing beyond local networks using all mDNS details conveyed to = DNS >=20 > For example, an older Mac Book excluded from receiving security = updates > fixing an NTP DDOS vulnerability, a concern that applies equally to = any > consumer device placed at risk by unwarrantedly increased discovery. > Examples might include printers or a baby monitors heavily depending > on access limited to local networks which conflicts with a goal of > reduced dependence on multi-cast discovery. >=20 I don't agree. Controlling access is perfectly manageable and done by a = variety of institutions across a broad array of services. Do not = incorrectly equate discovery with access. > A typical IPv6 router is unable to differentiate hosts given a = routable > address published in DNS by an mDNS proxy. To safely bridge this gap, > address preferences MUST USE the smallest practical scope available. = The > ability to do so MUST BE a requirement. As such, direct Internet > access would require other methods be used. This means there MUST BE = a > requirement to understand address scope differentiation. A requirement > related to mDNS --> DNS publication that is missing. While a device translating multicast DNS services to a unicast DNS = infrastructure MAY choose to limit the scope of the addresses it = advertises, this is not a MUST and the smallest scope MAY NOT be the = correct scope. This decision is best left to the administrator of the = translating device and we should not limit the applicability of the = protocol meeting these requirements. >=20 > Once a malefactor discovers addresses having global scope not uniquely > identifiable at a firewall, an entire class of devices immediately = become > vulnerable. These devices are vulnerable regardless and to pretend otherwise is just = an attempt to derail this effort. There are many ways to discover = internal devices without DNS-SD service advertisements. >=20 > As with Homenet, mDNS to DNS proxy should prefer the most conservative = scope > that meets the desired goals. This is a good recommendation but it SHOULD be up to the administrator = of the translating device. >=20 > When done correctly, this should not require an Internet Opt-in = mechanism > that is impractical for hosts assigned global IPv6 addresses. Agreed. Opt-in or Opt-out mechanisms are not practical when considering = existing services. >=20 >> Or the false statement: >> ,-- >> 6.5. Access Control >> ... >> While controlling access to an advertised service is outside the >> scope of DNS-SD, we note that access control today often is provided >> by existing site infrastructure (e.g., router access control lists, >> firewalls) and/or by service-specific mechanisms (e.g., user >> authentication to the service). For example, networked printers can >> control access via a user-id and password. Apple's software supports >> such access control for USB printers shared via Mac OS X Printer >> Sharing, as do many networked printers themselves. So the reliance >> on existing service-specific security mechanisms (i.e. outside the >> scope of DNS-SD) does not create new security considerations. >> '--- >>=20 >> Most printers DO NOT offer user-id/password access mechanisms and = often >> IPv6 support removes access control lists. Homenet and Apples BTMM >> make use of an important overlay approach being ignored both here and = with >> the the insecure UPnP. For this protocol to safely interoperate, an >> overlay approach must be supported. This approach might use ULAs, = for >> example. For this to work properly, locally defined addresses must be >> preferred when publishing in DNS. >>=20 >> As previously presented, it is minor fix to correct this oversight. >>=20 >> Doug, you have had ample opportunity to argue your position = before >> the WG and again during WGLC. Your concern has been duly noted, but = it >> is not the consensus of the WG to mandate a particular solution in an >> *informative* requirements draft. >=20 > The suggestion was to consider Homenet and to leverage their = consensus. >=20 > There was very little discussion within this WG, other than to deny = concerns at > the beginning and final hours. A point in time which excluded my = participation due > to momentary health issues. There was ample discussion of this topic in the working group including = your participation. This text accurately represents the consensus of the = working group. Stuart described how these services could be secured with = user authentication today and products that are vulnerable are = vulnerable with or without service discovery advertisements. >=20 >> To your point about specific devices lacking access control = mechanisms, my >> personal response would be to a) mitigate that problem with an = appliance (such >> as described in = http://spectrum.ieee.org/telecom/security/how-to-build-a-safer-internet-of= -things), >> b) put it behind a device that implements access control (e.g. a Mac- = or PC-to- >> USB print server), c) get a printer that supports access control = (yes, they do exist), >> or d) don't advertise the service beyond the local link. >=20 > Firewall policies white-listing specific IPv6 addresses is not = practical. This is why > such a feature is often excluded in IPv6 supported devices, yet = present with IPv4. Same as above. DNS-SD can't be responsible for broken products that are = vulnerable with or without service discovery advertisements. Policy at = the translating device is no different for IPv6 as it is for IPv4. NAT = is not a security solution. >=20 >> Note that in the topologies we're specifically targeting (enterprise, = higher ed) >> implementing an overlay is no guarantee that an adversary with access = to the >> network won't be able to use your consumables (ink & paper). >=20 > Doing this for higher education is great. However, there is no reason = this can't be > done in a safer manner by requiring a few basic functional = requirements still missing. >=20 > See: > RFC7368 Section 3.6.6. ULAs as a Hint of Connection Origin > RFC7084 Section 4.1 General Requirements > RFC7068 Section 4.3. LAN-Side Configuration > RFC4864 Section 3.2. Unique Local Addresses >=20 > Omitting proper address selection rules will not ensure basic = deployments offer desired security. This consideration was omitted in = both the Hybrid Proxy and the requirements documents. Threat related = documents should also include header compliance requirements as = specified by RA Guard RFC7113 also omitted by this draft to better = ensure administrative control of host naming conventions in lieu of IDNA = naming restrictions. >=20 > Again, the issue is to get ahead of security threats. We have the = opportunity to do this correctly - and at virtually no cost. If we = wait, it will be deployed, and exploited at great cost. >=20 > Regards, > Douglas Otis These are good recommendations for an administrator but again I don't = see the need to force it as a requirement. That will restrict the use = cases. The use case you are thinking of MAY benefit from this approach = and you may even want to make defaults that guide the administrator in = this way but by no means will it apply to every use case. I don't see anything new here. Tom --Apple-Mail=_FEADF599-6400-4DB6-AF1D-D7A20ACBC882 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 iQEcBAEBAgAGBQJVBzRqAAoJEPk0GMVmUuYMhvUH/RoK1+8XNvZ1zjGI9OPp4RC5 fTwxypkTl1pFrXu1JO1HdtgMG+/WWUAFV9jSv0yvNlZtT3yvvbkFxgjObwRipnaR f6wYIkAV97F4CnJBIIDCjE16HiTU5nHhFc1OtduTxa3/gOvDkTI7zt0btig0IDCz 602gqIuGN1ECOxUMJQHQIcXfN5dJu50iGCuXp0o1i471SFOV1+gIVWio27NmfuzB 4MNZIzsKPgY89iq2hHKALygsFHC+lhiDbdkMfCe6iZKedL3MEYGNsEgDH1CLwrv7 LcyY9Gy2oa5WMX7LdvjPaDtrMin8q9f3eLC66iVVFl/1jmUiQN5i0AP4ac4dW5w= =jLpN -----END PGP SIGNATURE----- --Apple-Mail=_FEADF599-6400-4DB6-AF1D-D7A20ACBC882-- From nobody Mon Mar 16 12:52:29 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id BC6D71A1B78; Mon, 16 Mar 2015 12:52:23 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0781A9057; Mon, 16 Mar 2015 12:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.861 X-Spam-Level: X-Spam-Status: No, score=0.861 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 TnDBz8MTi9ch; Mon, 16 Mar 2015 12:52:21 -0700 (PDT) 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 01F791A1B78; Mon, 16 Mar 2015 12:52:21 -0700 (PDT) Received: from [192.168.1.123] (unknown [216.16.214.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 0E22A208C; Mon, 16 Mar 2015 15:48:06 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FEADF599-6400-4DB6-AF1D-D7A20ACBC882"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Tom Pusateri In-Reply-To: <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> Date: Mon, 16 Mar 2015 15:52:09 -0400 Message-Id: References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Kerry Lynn , dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Tim Chown , The IESG , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 16 Mar 2015 19:52:23 -0000 --Apple-Mail=_FEADF599-6400-4DB6-AF1D-D7A20ACBC882 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 13, 2015, at 10:08 PM, Douglas Otis = wrote: >=20 >=20 >> On Mar 13, 2015, at 1:41 PM, Kerry Lynn wrote: >>=20 >> On Thu, Mar 12, 2015 at 2:24 PM, Douglas Otis = wrote: >>=20 >> Dear Stephen, >>=20 >> I agree with your statement and, based on our tests, these concerns = are very real! >>=20 >> IPv6 can not be defended in the same manner as with IPv4. With = Homenet, an >> effort was made to ensure address selection preferences critical when >> publishing addresses within DNS but omitted from the requirements = documents. >>=20 >> Doug, can your concern be addressed by specifically stating a = requirement >> that advertising a service in the global internet should be an opt-in = decision of the >> user, as suggested by Benoit? I'm not sure how practical this is. In order to work with existing = service advertisements, these decisions should be made in the device = that translates the mDNS advertisements not the device that originates = the advertisement. But there is plenty of room for policy controls in = the translation device to filter and provide access control based on = local criteria. > Dear Kerry, >=20 > Thank you for you comments. See reply below. >=20 >> The statement made in Section 6.1 is poorly considered. >> ,-- >> Section 6.1 >> ... >> Note that discovery of a service does not necessarily imply that the >> service is reachable by, or can be connected to, or can be used by, a >> given client. Specific access control mechanisms are out of scope of >> this document. >> '--- >>=20 >> Let's take these "poorly considered" assertions one-by-one: >> - reachable (a route may not exist to the advertised address) >> - connected to (the device may be offline) >> - used by (the user of the service may lack authorization) >> - access control is out of scope (not in our charter) >> Which of these do you specifically have an issue with? >=20 > Controlling access becomes unmanageable with automatic expansion of -- >=20 > a) discovery of all network details reported by mDNS beyond local = networks >=20 > b) routing beyond local networks using all mDNS details conveyed to = DNS >=20 > For example, an older Mac Book excluded from receiving security = updates > fixing an NTP DDOS vulnerability, a concern that applies equally to = any > consumer device placed at risk by unwarrantedly increased discovery. > Examples might include printers or a baby monitors heavily depending > on access limited to local networks which conflicts with a goal of > reduced dependence on multi-cast discovery. >=20 I don't agree. Controlling access is perfectly manageable and done by a = variety of institutions across a broad array of services. Do not = incorrectly equate discovery with access. > A typical IPv6 router is unable to differentiate hosts given a = routable > address published in DNS by an mDNS proxy. To safely bridge this gap, > address preferences MUST USE the smallest practical scope available. = The > ability to do so MUST BE a requirement. As such, direct Internet > access would require other methods be used. This means there MUST BE = a > requirement to understand address scope differentiation. A requirement > related to mDNS --> DNS publication that is missing. While a device translating multicast DNS services to a unicast DNS = infrastructure MAY choose to limit the scope of the addresses it = advertises, this is not a MUST and the smallest scope MAY NOT be the = correct scope. This decision is best left to the administrator of the = translating device and we should not limit the applicability of the = protocol meeting these requirements. >=20 > Once a malefactor discovers addresses having global scope not uniquely > identifiable at a firewall, an entire class of devices immediately = become > vulnerable. These devices are vulnerable regardless and to pretend otherwise is just = an attempt to derail this effort. There are many ways to discover = internal devices without DNS-SD service advertisements. >=20 > As with Homenet, mDNS to DNS proxy should prefer the most conservative = scope > that meets the desired goals. This is a good recommendation but it SHOULD be up to the administrator = of the translating device. >=20 > When done correctly, this should not require an Internet Opt-in = mechanism > that is impractical for hosts assigned global IPv6 addresses. Agreed. Opt-in or Opt-out mechanisms are not practical when considering = existing services. >=20 >> Or the false statement: >> ,-- >> 6.5. Access Control >> ... >> While controlling access to an advertised service is outside the >> scope of DNS-SD, we note that access control today often is provided >> by existing site infrastructure (e.g., router access control lists, >> firewalls) and/or by service-specific mechanisms (e.g., user >> authentication to the service). For example, networked printers can >> control access via a user-id and password. Apple's software supports >> such access control for USB printers shared via Mac OS X Printer >> Sharing, as do many networked printers themselves. So the reliance >> on existing service-specific security mechanisms (i.e. outside the >> scope of DNS-SD) does not create new security considerations. >> '--- >>=20 >> Most printers DO NOT offer user-id/password access mechanisms and = often >> IPv6 support removes access control lists. Homenet and Apples BTMM >> make use of an important overlay approach being ignored both here and = with >> the the insecure UPnP. For this protocol to safely interoperate, an >> overlay approach must be supported. This approach might use ULAs, = for >> example. For this to work properly, locally defined addresses must be >> preferred when publishing in DNS. >>=20 >> As previously presented, it is minor fix to correct this oversight. >>=20 >> Doug, you have had ample opportunity to argue your position = before >> the WG and again during WGLC. Your concern has been duly noted, but = it >> is not the consensus of the WG to mandate a particular solution in an >> *informative* requirements draft. >=20 > The suggestion was to consider Homenet and to leverage their = consensus. >=20 > There was very little discussion within this WG, other than to deny = concerns at > the beginning and final hours. A point in time which excluded my = participation due > to momentary health issues. There was ample discussion of this topic in the working group including = your participation. This text accurately represents the consensus of the = working group. Stuart described how these services could be secured with = user authentication today and products that are vulnerable are = vulnerable with or without service discovery advertisements. >=20 >> To your point about specific devices lacking access control = mechanisms, my >> personal response would be to a) mitigate that problem with an = appliance (such >> as described in = http://spectrum.ieee.org/telecom/security/how-to-build-a-safer-internet-of= -things), >> b) put it behind a device that implements access control (e.g. a Mac- = or PC-to- >> USB print server), c) get a printer that supports access control = (yes, they do exist), >> or d) don't advertise the service beyond the local link. >=20 > Firewall policies white-listing specific IPv6 addresses is not = practical. This is why > such a feature is often excluded in IPv6 supported devices, yet = present with IPv4. Same as above. DNS-SD can't be responsible for broken products that are = vulnerable with or without service discovery advertisements. Policy at = the translating device is no different for IPv6 as it is for IPv4. NAT = is not a security solution. >=20 >> Note that in the topologies we're specifically targeting (enterprise, = higher ed) >> implementing an overlay is no guarantee that an adversary with access = to the >> network won't be able to use your consumables (ink & paper). >=20 > Doing this for higher education is great. However, there is no reason = this can't be > done in a safer manner by requiring a few basic functional = requirements still missing. >=20 > See: > RFC7368 Section 3.6.6. ULAs as a Hint of Connection Origin > RFC7084 Section 4.1 General Requirements > RFC7068 Section 4.3. LAN-Side Configuration > RFC4864 Section 3.2. Unique Local Addresses >=20 > Omitting proper address selection rules will not ensure basic = deployments offer desired security. This consideration was omitted in = both the Hybrid Proxy and the requirements documents. Threat related = documents should also include header compliance requirements as = specified by RA Guard RFC7113 also omitted by this draft to better = ensure administrative control of host naming conventions in lieu of IDNA = naming restrictions. >=20 > Again, the issue is to get ahead of security threats. We have the = opportunity to do this correctly - and at virtually no cost. If we = wait, it will be deployed, and exploited at great cost. >=20 > Regards, > Douglas Otis These are good recommendations for an administrator but again I don't = see the need to force it as a requirement. That will restrict the use = cases. The use case you are thinking of MAY benefit from this approach = and you may even want to make defaults that guide the administrator in = this way but by no means will it apply to every use case. I don't see anything new here. Tom --Apple-Mail=_FEADF599-6400-4DB6-AF1D-D7A20ACBC882 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 iQEcBAEBAgAGBQJVBzRqAAoJEPk0GMVmUuYMhvUH/RoK1+8XNvZ1zjGI9OPp4RC5 fTwxypkTl1pFrXu1JO1HdtgMG+/WWUAFV9jSv0yvNlZtT3yvvbkFxgjObwRipnaR f6wYIkAV97F4CnJBIIDCjE16HiTU5nHhFc1OtduTxa3/gOvDkTI7zt0btig0IDCz 602gqIuGN1ECOxUMJQHQIcXfN5dJu50iGCuXp0o1i471SFOV1+gIVWio27NmfuzB 4MNZIzsKPgY89iq2hHKALygsFHC+lhiDbdkMfCe6iZKedL3MEYGNsEgDH1CLwrv7 LcyY9Gy2oa5WMX7LdvjPaDtrMin8q9f3eLC66iVVFl/1jmUiQN5i0AP4ac4dW5w= =jLpN -----END PGP SIGNATURE----- --Apple-Mail=_FEADF599-6400-4DB6-AF1D-D7A20ACBC882-- From nobody Mon Mar 16 18:07:41 2015 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 694621ACDA6; Mon, 16 Mar 2015 18:07:40 -0700 (PDT) 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 strMz0okqDmI; Mon, 16 Mar 2015 18:07:37 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C792B1ACDA5; Mon, 16 Mar 2015 18:07:36 -0700 (PDT) Received: by qgh62 with SMTP id 62so56632450qgh.1; Mon, 16 Mar 2015 18:07:36 -0700 (PDT) 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=95D4mnlnzXbXrWjQPTFq5rSB//s4oTd5mp/JZ1tZABU=; b=cr09aKVmrzXkVdn+aAbpa7KX39//BnUej0mkHRicJztJgoVbUNXmmecNS/D2qRlSRK eVbR5E3H0O/wZMY17fIhoO92bHKGgHTMVmUwltNp8dGClMIxGfpaxa0Yg6HrVHtnW0V4 H1qlXD7hv/sP4YBtajwdj0Oz+xTVmt6SRRGkExB819Xx2ZH+5Xfopxsl9WahhXsH6qjV v4SpqlJKMdb92Pa09HKxKi1gQxcxjtA4GGkbGEPlkwYRZ9LsoboNRJ8np94noNYBNkxB DyhWSgu4pSd0wCJgrTtVd22+mS6DL7mRNmzl0CB/zvzzUucmDLE4BjCKX9bcens0QCMZ Mvmw== X-Received: by 10.140.101.22 with SMTP id t22mr78845113qge.9.1426554456007; Mon, 16 Mar 2015 18:07:36 -0700 (PDT) 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 j94sm8661032qgd.47.2015.03.16.18.07.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Mar 2015 18:07:35 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: Date: Mon, 16 Mar 2015 18:07:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <80E11ACB-1AE9-479E-A36A-1610C0EF307A@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> To: Tom Pusateri X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Kerry Lynn , dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Tim Chown , The IESG , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 01:07:40 -0000 > On Mar 16, 2015, at 12:52 PM, Tom Pusateri wrote: >=20 >> On Mar 13, 2015, at 10:08 PM, Douglas Otis = wrote: >>=20 >>> On Mar 13, 2015, at 1:41 PM, Kerry Lynn wrote: >>>=20 >>> On Thu, Mar 12, 2015 at 2:24 PM, Douglas Otis = wrote: >>>=20 >>> Dear Stephen, >>>=20 >>> I agree with your statement and, based on our tests, these concerns = are very real! >>>=20 >>> IPv6 can not be defended in the same manner as with IPv4. With = Homenet, an >>> effort was made to ensure address selection preferences critical = when >>> publishing addresses within DNS but omitted from the requirements = documents. >>>=20 >>> Doug, can your concern be addressed by specifically stating a = requirement >>> that advertising a service in the global internet should be an = opt-in decision of the >>> user, as suggested by Benoit? >=20 > I'm not sure how practical this is. In order to work with > existing service advertisements, these decisions should be > made in the device that translates the mDNS advertisements > not the device that originates the advertisement. But there > is plenty of room for policy controls in the translation device > to filter and provide access control based on local criteria. Dear Tom, Automatic publishing of mDNS as DNS-SD introduces concerns NOT=20 adequately covered by either mDNS or DNS-SD respective security sections. When either RFC1918 or RFC4193 host addresses are=20 present, there is no need to expose other address categories. After all, mDNS is bound to local networks by limitation of multicast. =20 RFC4193 offers local network containment strategies not dependent on multicast. Offering routable IP addresses introduces unwarranted and unnecessary exposure when enabled beyond the local network, and it is clear such limitations are not imposed by hosts supporting mDNS since such exposure is expected limited by multicast constraints. However, the effort to automatically publish mDNS in DNS-SD form removes these constraints and creates new risk not yet properly addressed. =20 >> Dear Kerry, >>=20 >> Thank you for you comments. See reply below. >>=20 >>> The statement made in Section 6.1 is poorly considered. >>> ,-- >>> Section 6.1 >>> ... >>> Note that discovery of a service does not necessarily imply that the >>> service is reachable by, or can be connected to, or can be used by, = a >>> given client. Specific access control mechanisms are out of scope = of >>> this document. >>> '--- >>>=20 >>> Let's take these "poorly considered" assertions one-by-one: >>> - reachable (a route may not exist to the advertised address) >>> - connected to (the device may be offline) >>> - used by (the user of the service may lack authorization) >>> - access control is out of scope (not in our charter) >>> Which of these do you specifically have an issue with? >>=20 >> Controlling access becomes unmanageable with automatic expansion of = -- >>=20 >> a) discovery of all network details reported by mDNS beyond local = networks >>=20 >> b) routing beyond local networks using all mDNS details conveyed to = DNS >>=20 >> For example, an older Mac Book excluded from receiving security = updates >> fixing an NTP DDOS vulnerability, a concern that applies equally to = any >> consumer device placed at risk by unwarrantedly increased discovery. >> Examples might include printers or a baby monitors heavily depending >> on access limited to local networks which conflicts with a goal of >> reduced dependence on multi-cast discovery. >=20 > I don't agree. Controlling access is perfectly manageable and done > by a variety of institutions across a broad array of services. Do not > incorrectly equate discovery with access. Since IPv6 permits dynamic network prefixes, this makes it relatively impractical to exclude traffic from the Internet while allowing traffic from isolated bridges without reliance on conventions established by RFC4193 as used by Homenet and various enterprise deployments. >> A typical IPv6 router is unable to differentiate hosts given a = routable >> address published in DNS by an mDNS proxy. To safely bridge this = gap, >> address preferences MUST USE the smallest practical scope available. = The >> ability to do so MUST BE a requirement. As such, direct Internet >> access would require other methods be used. This means there MUST BE = a >> requirement to understand address scope differentiation. A = requirement >> related to mDNS --> DNS publication that is missing. >=20 > While a device translating multicast DNS services to a unicast DNS > infrastructure MAY choose to limit the scope of the addresses it > advertises, this is not a MUST and the smallest scope MAY NOT be > the correct scope. This decision is best left to the administrator > of the translating device and we should not limit the applicability > of the protocol meeting these requirements. RFC4193 avoids network translations by use of a network overlay. A technique that leverages IPv6's ability to support multiple IP addresses per network adapter. Many different network boundaries can be safely established through an address category selection made in a publication process. The ability to establish publication preferences MUST BE a requirement for any proposed publications of mDNS into DNS. Publishing a host on the Internet SHOULD NEVER be automatic, nor depend on administrative intervention. The selection process using _stable_ prefixes is thereby better able to select the smallest _practical_ realm based on administrative policy. >> Once a malefactor discovers addresses having global scope not = uniquely >> identifiable at a firewall, an entire class of devices immediately = become >> vulnerable. >=20 > These devices are vulnerable regardless and to pretend otherwise is > just an attempt to derail this effort. There are many ways to discover > internal devices without DNS-SD service advertisements. An RFC4193 address better isolates sensitive devices having limited = resources from direct Internet access, while still enabling various authenticated tunneling methods. It is also wrong to suggest such devices are not far=20= better protected by such schemes. >> As with Homenet, mDNS to DNS proxy should prefer the most = conservative scope >> that meets the desired goals. >=20 > This is a good recommendation but it SHOULD be up to the administrator = of the > translating device. Before an administrator is able to isolate a network realm, basic = support methods must be made available as a protocol requirement. A requirement that = remains missing in the form of address publication selection. >> When done correctly, this should not require an Internet Opt-in = mechanism >> that is impractical for hosts assigned global IPv6 addresses. >=20 > Agreed. Opt-in or Opt-out mechanisms are not practical when = considering > existing services. >=20 >>> Or the false statement: >>> ,-- >>> 6.5. Access Control >>> ... >>> While controlling access to an advertised service is outside the >>> scope of DNS-SD, we note that access control today often is provided >>> by existing site infrastructure (e.g., router access control lists, >>> firewalls) and/or by service-specific mechanisms (e.g., user >>> authentication to the service). For example, networked printers can >>> control access via a user-id and password. Apple's software = supports >>> such access control for USB printers shared via Mac OS X Printer >>> Sharing, as do many networked printers themselves. So the reliance >>> on existing service-specific security mechanisms (i.e. outside the >>> scope of DNS-SD) does not create new security considerations. >>> '--- >>>=20 >>> Most printers DO NOT offer user-id/password access mechanisms and = often >>> IPv6 support removes access control lists. Homenet and Apples BTMM >>> make use of an important overlay approach being ignored both here = and with >>> the the insecure UPnP. For this protocol to safely interoperate, an >>> overlay approach must be supported. This approach might use ULAs, = for >>> example. For this to work properly, locally defined addresses must = be >>> preferred when publishing in DNS. >>>=20 >>> As previously presented, it is minor fix to correct this oversight. >>>=20 >>> Doug, you have had ample opportunity to argue your position = before >>> the WG and again during WGLC. Your concern has been duly noted, but = it >>> is not the consensus of the WG to mandate a particular solution in = an >>> *informative* requirements draft. >>=20 >> The suggestion was to consider Homenet and to leverage their = consensus. >>=20 >> There was very little discussion within this WG, other than to deny = concerns at >> the beginning and final hours. A point in time which excluded my = participation due >> to momentary health issues. >=20 > There was ample discussion of this topic in the working group = including > your participation. This text accurately represents the consensus of = the > working group. Stuart described how these services could be secured = with > user authentication today and products that are vulnerable are = vulnerable > with or without service discovery advertisements. Nevertheless, a few key statements were factually in error and = challenged, but never adequately discussed on a rather quiet WG. >>> To your point about specific devices lacking access control = mechanisms, my >>> personal response would be to a) mitigate that problem with an = appliance (such >>> as described in = http://spectrum.ieee.org/telecom/security/how-to-build-a-safer-internet-of= -things), >>> b) put it behind a device that implements access control (e.g. a = Mac- or PC-to- >>> USB print server), c) get a printer that supports access control = (yes, they do exist), >>> or d) don't advertise the service beyond the local link. >>=20 >> Firewall policies white-listing specific IPv6 addresses is not = practical. This is why >> such a feature is often excluded in IPv6 supported devices, yet = present with IPv4. >=20 > Same as above. DNS-SD can't be responsible for broken products that = are > vulnerable with or without service discovery advertisements. Policy at = the > translating device is no different for IPv6 as it is for IPv4. NAT is = not a > security solution. This is not about use of a NAT. With IPv6, it is about use of overlays. These might be in the form of VLANs or VPNs for example. Methods that = are=20 able to offer very strong security.=20 >>> Note that in the topologies we're specifically targeting = (enterprise, higher ed) >>> implementing an overlay is no guarantee that an adversary with = access to the >>> network won't be able to use your consumables (ink & paper). >>=20 >> Doing this for higher education is great. However, there is >> no reason this can't be done in a safer manner by requiring a >> few basic functional requirements still missing. >>=20 >> See: >> RFC7368 Section 3.6.6. ULAs as a Hint of Connection Origin >> RFC7084 Section 4.1 General Requirements >> RFC7068 Section 4.3. LAN-Side Configuration >> RFC4864 Section 3.2. Unique Local Addresses >>=20 >> Omitting proper address selection rules will not ensure basic >> deployments offer desired security. This consideration was >> omitted in both the Hybrid Proxy and the requirements documents. >> Threat related documents should also include header compliance >> requirements as specified by RA Guard RFC7113 also omitted by >> this draft to better ensure administrative control of host naming >> conventions in lieu of IDNA naming restrictions. >>=20 >> Again, the issue is to get ahead of security threats. We have >> the opportunity to do this correctly - and at virtually no cost. >> If we wait, it will be deployed, and exploited at great cost. >=20 > These are good recommendations for an administrator but again I don't = see > the need to force it as a requirement. That will restrict the use = cases. Not imposing a MUST requirement on an address selection ability prevents safer deployment possibilities. Security will be significantly weakened by this address selection requirement oversight! This scheme should = also ensure of the integrity of basic configurations being published, since IDNA is also being ignored. > The use case you are thinking of MAY benefit from this approach and = you > may even want to make defaults that guide the administrator in this = way > but by no means will it apply to every use case. The current attitude is all devices inadvertently exposed by mDNS ->=20 DNS-SD automatic publishing schemes will be able to cope with direct Internet access or will be administratively excluded. Similar attitudes have been expressed in the past, many of which later proved recklessly optimistic. A few simple changes can and will significantly enhance the ease and stability of the desired security.=20 Regards, Douglas Otis From nobody Mon Mar 16 18:07:45 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9776E1ACDAA; Mon, 16 Mar 2015 18:07:40 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694621ACDA6; Mon, 16 Mar 2015 18:07:40 -0700 (PDT) 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 strMz0okqDmI; Mon, 16 Mar 2015 18:07:37 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C792B1ACDA5; Mon, 16 Mar 2015 18:07:36 -0700 (PDT) Received: by qgh62 with SMTP id 62so56632450qgh.1; Mon, 16 Mar 2015 18:07:36 -0700 (PDT) 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=95D4mnlnzXbXrWjQPTFq5rSB//s4oTd5mp/JZ1tZABU=; b=cr09aKVmrzXkVdn+aAbpa7KX39//BnUej0mkHRicJztJgoVbUNXmmecNS/D2qRlSRK eVbR5E3H0O/wZMY17fIhoO92bHKGgHTMVmUwltNp8dGClMIxGfpaxa0Yg6HrVHtnW0V4 H1qlXD7hv/sP4YBtajwdj0Oz+xTVmt6SRRGkExB819Xx2ZH+5Xfopxsl9WahhXsH6qjV v4SpqlJKMdb92Pa09HKxKi1gQxcxjtA4GGkbGEPlkwYRZ9LsoboNRJ8np94noNYBNkxB DyhWSgu4pSd0wCJgrTtVd22+mS6DL7mRNmzl0CB/zvzzUucmDLE4BjCKX9bcens0QCMZ Mvmw== X-Received: by 10.140.101.22 with SMTP id t22mr78845113qge.9.1426554456007; Mon, 16 Mar 2015 18:07:36 -0700 (PDT) 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 j94sm8661032qgd.47.2015.03.16.18.07.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Mar 2015 18:07:35 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: Date: Mon, 16 Mar 2015 18:07:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <80E11ACB-1AE9-479E-A36A-1610C0EF307A@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> To: Tom Pusateri X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Kerry Lynn , dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Tim Chown , The IESG , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 01:07:40 -0000 > On Mar 16, 2015, at 12:52 PM, Tom Pusateri wrote: >=20 >> On Mar 13, 2015, at 10:08 PM, Douglas Otis = wrote: >>=20 >>> On Mar 13, 2015, at 1:41 PM, Kerry Lynn wrote: >>>=20 >>> On Thu, Mar 12, 2015 at 2:24 PM, Douglas Otis = wrote: >>>=20 >>> Dear Stephen, >>>=20 >>> I agree with your statement and, based on our tests, these concerns = are very real! >>>=20 >>> IPv6 can not be defended in the same manner as with IPv4. With = Homenet, an >>> effort was made to ensure address selection preferences critical = when >>> publishing addresses within DNS but omitted from the requirements = documents. >>>=20 >>> Doug, can your concern be addressed by specifically stating a = requirement >>> that advertising a service in the global internet should be an = opt-in decision of the >>> user, as suggested by Benoit? >=20 > I'm not sure how practical this is. In order to work with > existing service advertisements, these decisions should be > made in the device that translates the mDNS advertisements > not the device that originates the advertisement. But there > is plenty of room for policy controls in the translation device > to filter and provide access control based on local criteria. Dear Tom, Automatic publishing of mDNS as DNS-SD introduces concerns NOT=20 adequately covered by either mDNS or DNS-SD respective security sections. When either RFC1918 or RFC4193 host addresses are=20 present, there is no need to expose other address categories. After all, mDNS is bound to local networks by limitation of multicast. =20 RFC4193 offers local network containment strategies not dependent on multicast. Offering routable IP addresses introduces unwarranted and unnecessary exposure when enabled beyond the local network, and it is clear such limitations are not imposed by hosts supporting mDNS since such exposure is expected limited by multicast constraints. However, the effort to automatically publish mDNS in DNS-SD form removes these constraints and creates new risk not yet properly addressed. =20 >> Dear Kerry, >>=20 >> Thank you for you comments. See reply below. >>=20 >>> The statement made in Section 6.1 is poorly considered. >>> ,-- >>> Section 6.1 >>> ... >>> Note that discovery of a service does not necessarily imply that the >>> service is reachable by, or can be connected to, or can be used by, = a >>> given client. Specific access control mechanisms are out of scope = of >>> this document. >>> '--- >>>=20 >>> Let's take these "poorly considered" assertions one-by-one: >>> - reachable (a route may not exist to the advertised address) >>> - connected to (the device may be offline) >>> - used by (the user of the service may lack authorization) >>> - access control is out of scope (not in our charter) >>> Which of these do you specifically have an issue with? >>=20 >> Controlling access becomes unmanageable with automatic expansion of = -- >>=20 >> a) discovery of all network details reported by mDNS beyond local = networks >>=20 >> b) routing beyond local networks using all mDNS details conveyed to = DNS >>=20 >> For example, an older Mac Book excluded from receiving security = updates >> fixing an NTP DDOS vulnerability, a concern that applies equally to = any >> consumer device placed at risk by unwarrantedly increased discovery. >> Examples might include printers or a baby monitors heavily depending >> on access limited to local networks which conflicts with a goal of >> reduced dependence on multi-cast discovery. >=20 > I don't agree. Controlling access is perfectly manageable and done > by a variety of institutions across a broad array of services. Do not > incorrectly equate discovery with access. Since IPv6 permits dynamic network prefixes, this makes it relatively impractical to exclude traffic from the Internet while allowing traffic from isolated bridges without reliance on conventions established by RFC4193 as used by Homenet and various enterprise deployments. >> A typical IPv6 router is unable to differentiate hosts given a = routable >> address published in DNS by an mDNS proxy. To safely bridge this = gap, >> address preferences MUST USE the smallest practical scope available. = The >> ability to do so MUST BE a requirement. As such, direct Internet >> access would require other methods be used. This means there MUST BE = a >> requirement to understand address scope differentiation. A = requirement >> related to mDNS --> DNS publication that is missing. >=20 > While a device translating multicast DNS services to a unicast DNS > infrastructure MAY choose to limit the scope of the addresses it > advertises, this is not a MUST and the smallest scope MAY NOT be > the correct scope. This decision is best left to the administrator > of the translating device and we should not limit the applicability > of the protocol meeting these requirements. RFC4193 avoids network translations by use of a network overlay. A technique that leverages IPv6's ability to support multiple IP addresses per network adapter. Many different network boundaries can be safely established through an address category selection made in a publication process. The ability to establish publication preferences MUST BE a requirement for any proposed publications of mDNS into DNS. Publishing a host on the Internet SHOULD NEVER be automatic, nor depend on administrative intervention. The selection process using _stable_ prefixes is thereby better able to select the smallest _practical_ realm based on administrative policy. >> Once a malefactor discovers addresses having global scope not = uniquely >> identifiable at a firewall, an entire class of devices immediately = become >> vulnerable. >=20 > These devices are vulnerable regardless and to pretend otherwise is > just an attempt to derail this effort. There are many ways to discover > internal devices without DNS-SD service advertisements. An RFC4193 address better isolates sensitive devices having limited = resources from direct Internet access, while still enabling various authenticated tunneling methods. It is also wrong to suggest such devices are not far=20= better protected by such schemes. >> As with Homenet, mDNS to DNS proxy should prefer the most = conservative scope >> that meets the desired goals. >=20 > This is a good recommendation but it SHOULD be up to the administrator = of the > translating device. Before an administrator is able to isolate a network realm, basic = support methods must be made available as a protocol requirement. A requirement that = remains missing in the form of address publication selection. >> When done correctly, this should not require an Internet Opt-in = mechanism >> that is impractical for hosts assigned global IPv6 addresses. >=20 > Agreed. Opt-in or Opt-out mechanisms are not practical when = considering > existing services. >=20 >>> Or the false statement: >>> ,-- >>> 6.5. Access Control >>> ... >>> While controlling access to an advertised service is outside the >>> scope of DNS-SD, we note that access control today often is provided >>> by existing site infrastructure (e.g., router access control lists, >>> firewalls) and/or by service-specific mechanisms (e.g., user >>> authentication to the service). For example, networked printers can >>> control access via a user-id and password. Apple's software = supports >>> such access control for USB printers shared via Mac OS X Printer >>> Sharing, as do many networked printers themselves. So the reliance >>> on existing service-specific security mechanisms (i.e. outside the >>> scope of DNS-SD) does not create new security considerations. >>> '--- >>>=20 >>> Most printers DO NOT offer user-id/password access mechanisms and = often >>> IPv6 support removes access control lists. Homenet and Apples BTMM >>> make use of an important overlay approach being ignored both here = and with >>> the the insecure UPnP. For this protocol to safely interoperate, an >>> overlay approach must be supported. This approach might use ULAs, = for >>> example. For this to work properly, locally defined addresses must = be >>> preferred when publishing in DNS. >>>=20 >>> As previously presented, it is minor fix to correct this oversight. >>>=20 >>> Doug, you have had ample opportunity to argue your position = before >>> the WG and again during WGLC. Your concern has been duly noted, but = it >>> is not the consensus of the WG to mandate a particular solution in = an >>> *informative* requirements draft. >>=20 >> The suggestion was to consider Homenet and to leverage their = consensus. >>=20 >> There was very little discussion within this WG, other than to deny = concerns at >> the beginning and final hours. A point in time which excluded my = participation due >> to momentary health issues. >=20 > There was ample discussion of this topic in the working group = including > your participation. This text accurately represents the consensus of = the > working group. Stuart described how these services could be secured = with > user authentication today and products that are vulnerable are = vulnerable > with or without service discovery advertisements. Nevertheless, a few key statements were factually in error and = challenged, but never adequately discussed on a rather quiet WG. >>> To your point about specific devices lacking access control = mechanisms, my >>> personal response would be to a) mitigate that problem with an = appliance (such >>> as described in = http://spectrum.ieee.org/telecom/security/how-to-build-a-safer-internet-of= -things), >>> b) put it behind a device that implements access control (e.g. a = Mac- or PC-to- >>> USB print server), c) get a printer that supports access control = (yes, they do exist), >>> or d) don't advertise the service beyond the local link. >>=20 >> Firewall policies white-listing specific IPv6 addresses is not = practical. This is why >> such a feature is often excluded in IPv6 supported devices, yet = present with IPv4. >=20 > Same as above. DNS-SD can't be responsible for broken products that = are > vulnerable with or without service discovery advertisements. Policy at = the > translating device is no different for IPv6 as it is for IPv4. NAT is = not a > security solution. This is not about use of a NAT. With IPv6, it is about use of overlays. These might be in the form of VLANs or VPNs for example. Methods that = are=20 able to offer very strong security.=20 >>> Note that in the topologies we're specifically targeting = (enterprise, higher ed) >>> implementing an overlay is no guarantee that an adversary with = access to the >>> network won't be able to use your consumables (ink & paper). >>=20 >> Doing this for higher education is great. However, there is >> no reason this can't be done in a safer manner by requiring a >> few basic functional requirements still missing. >>=20 >> See: >> RFC7368 Section 3.6.6. ULAs as a Hint of Connection Origin >> RFC7084 Section 4.1 General Requirements >> RFC7068 Section 4.3. LAN-Side Configuration >> RFC4864 Section 3.2. Unique Local Addresses >>=20 >> Omitting proper address selection rules will not ensure basic >> deployments offer desired security. This consideration was >> omitted in both the Hybrid Proxy and the requirements documents. >> Threat related documents should also include header compliance >> requirements as specified by RA Guard RFC7113 also omitted by >> this draft to better ensure administrative control of host naming >> conventions in lieu of IDNA naming restrictions. >>=20 >> Again, the issue is to get ahead of security threats. We have >> the opportunity to do this correctly - and at virtually no cost. >> If we wait, it will be deployed, and exploited at great cost. >=20 > These are good recommendations for an administrator but again I don't = see > the need to force it as a requirement. That will restrict the use = cases. Not imposing a MUST requirement on an address selection ability prevents safer deployment possibilities. Security will be significantly weakened by this address selection requirement oversight! This scheme should = also ensure of the integrity of basic configurations being published, since IDNA is also being ignored. > The use case you are thinking of MAY benefit from this approach and = you > may even want to make defaults that guide the administrator in this = way > but by no means will it apply to every use case. The current attitude is all devices inadvertently exposed by mDNS ->=20 DNS-SD automatic publishing schemes will be able to cope with direct Internet access or will be administratively excluded. Similar attitudes have been expressed in the past, many of which later proved recklessly optimistic. A few simple changes can and will significantly enhance the ease and stability of the desired security.=20 Regards, Douglas Otis From nobody Tue Mar 17 10:51:38 2015 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 F2A201A8852; Tue, 17 Mar 2015 10:51:32 -0700 (PDT) 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 SAhJOfDTEHIq; Tue, 17 Mar 2015 10:51:30 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D491A883F; Tue, 17 Mar 2015 10:51:29 -0700 (PDT) Received: by qgf3 with SMTP id 3so15236746qgf.3; Tue, 17 Mar 2015 10:51:29 -0700 (PDT) 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=wWZjg5dGa9kOQIQ/JErsuHun89o1di42RdnY/ja5/4M=; b=WvvOiovB5UjcwgH5W+tPurA4qoTWlQ0iXZKBQmOEdgBmP8QLr6VGeCXRY1FwD/3qN7 u1n3ooZwNNuU1Cw5SCatVAEvETAfX88cEdcPQFavjKTvcJ63nnB8Ai1i1kD5rG6chBjy ce/seqtlZEPof8NMK8Ml7mkXm8GwaCsiatOZeM/AFR9u8VYwRaL/aJmgoHRpOQCcgfEy aIuPyrcU5Ev3gHfBBejsgjkehvMF7Eqt1V885wUNoLjd20I9l+5hSEI0Z+EOHHR3OEVu W/G/L5qooB01UZmVvkMjBW+zcZGC3R3kywUiJXExniMZeDFmfQyBc+z5q1jgMJZUlG/C KTaQ== X-Received: by 10.140.149.4 with SMTP id 4mr49236205qhv.10.1426614689137; Tue, 17 Mar 2015 10:51:29 -0700 (PDT) Received: from ?IPv6:2001:420:2c8b:1300:18e6:dc2d:e21b:8558? ([2001:420:2c8b:1300:18e6:dc2d:e21b:8558]) by mx.google.com with ESMTPSA id t102sm10095320qgt.45.2015.03.17.10.51.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 10:51:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ralph Droms In-Reply-To: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> Date: Tue, 17 Mar 2015 13:51:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , Chown Tim Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 17:51:33 -0000 Stephen - let me summarize the responses to your comments; please let us = know if these responses will be sufficient to address your comments... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - section 6 intro: I'm not sure I buy that the set of relevant > threats is only a union as stated. There are often new threats > in new environments. As Kerry wrote, the text is "the security issues are likely to include = the union of those discussed in the Multicast DNS [mDNS] and DNS-Based = Service Discovery [DNS-SD] specifications." Given that this text allows = for other issues, and the rest of section 6 raises other issues, are you = OK with the text as it exists in draft-ietf-dnssd-requirements-05? > - 6.6: I think one can also leak private information by > searching in too broad a scope, e.g. if the client can be > fingerprinted allowing re-identification. I think that's > different from the example given, and maybe worth noting too. Kerry pointed out that the difference between the threat from searching = for services as opposed to other forms of name resolution in arbitrary = zones is unclear. While it would be possible to edit this text to = include searching as well as registration, I think the resulting text = would be too restrictive to allow for useful solutions. Would you be = willing to accept the text as it exists or do you have some other new = text to suggest? - Ralph From nobody Tue Mar 17 10:51:44 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2A7691A8853; Tue, 17 Mar 2015 10:51:33 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A201A8852; Tue, 17 Mar 2015 10:51:32 -0700 (PDT) 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 SAhJOfDTEHIq; Tue, 17 Mar 2015 10:51:30 -0700 (PDT) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3D491A883F; Tue, 17 Mar 2015 10:51:29 -0700 (PDT) Received: by qgf3 with SMTP id 3so15236746qgf.3; Tue, 17 Mar 2015 10:51:29 -0700 (PDT) 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=wWZjg5dGa9kOQIQ/JErsuHun89o1di42RdnY/ja5/4M=; b=WvvOiovB5UjcwgH5W+tPurA4qoTWlQ0iXZKBQmOEdgBmP8QLr6VGeCXRY1FwD/3qN7 u1n3ooZwNNuU1Cw5SCatVAEvETAfX88cEdcPQFavjKTvcJ63nnB8Ai1i1kD5rG6chBjy ce/seqtlZEPof8NMK8Ml7mkXm8GwaCsiatOZeM/AFR9u8VYwRaL/aJmgoHRpOQCcgfEy aIuPyrcU5Ev3gHfBBejsgjkehvMF7Eqt1V885wUNoLjd20I9l+5hSEI0Z+EOHHR3OEVu W/G/L5qooB01UZmVvkMjBW+zcZGC3R3kywUiJXExniMZeDFmfQyBc+z5q1jgMJZUlG/C KTaQ== X-Received: by 10.140.149.4 with SMTP id 4mr49236205qhv.10.1426614689137; Tue, 17 Mar 2015 10:51:29 -0700 (PDT) Received: from ?IPv6:2001:420:2c8b:1300:18e6:dc2d:e21b:8558? ([2001:420:2c8b:1300:18e6:dc2d:e21b:8558]) by mx.google.com with ESMTPSA id t102sm10095320qgt.45.2015.03.17.10.51.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 10:51:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ralph Droms In-Reply-To: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> Date: Tue, 17 Mar 2015 13:51:25 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> To: Stephen Farrell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , Chown Tim Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 17:51:33 -0000 Stephen - let me summarize the responses to your comments; please let us = know if these responses will be sufficient to address your comments... > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 >=20 > - section 6 intro: I'm not sure I buy that the set of relevant > threats is only a union as stated. There are often new threats > in new environments. As Kerry wrote, the text is "the security issues are likely to include = the union of those discussed in the Multicast DNS [mDNS] and DNS-Based = Service Discovery [DNS-SD] specifications." Given that this text allows = for other issues, and the rest of section 6 raises other issues, are you = OK with the text as it exists in draft-ietf-dnssd-requirements-05? > - 6.6: I think one can also leak private information by > searching in too broad a scope, e.g. if the client can be > fingerprinted allowing re-identification. I think that's > different from the example given, and maybe worth noting too. Kerry pointed out that the difference between the threat from searching = for services as opposed to other forms of name resolution in arbitrary = zones is unclear. While it would be possible to edit this text to = include searching as well as registration, I think the resulting text = would be too restrictive to allow for useful solutions. Would you be = willing to accept the text as it exists or do you have some other new = text to suggest? - Ralph From nobody Tue Mar 17 10:58:21 2015 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 57C1B1A8821; Tue, 17 Mar 2015 10:58:19 -0700 (PDT) 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 Ieie36TExYNG; Tue, 17 Mar 2015 10:58:15 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFCA31A87E7; Tue, 17 Mar 2015 10:58:14 -0700 (PDT) Received: by qcaz10 with SMTP id z10so16124401qca.1; Tue, 17 Mar 2015 10:58:14 -0700 (PDT) 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=krbJVDEjx0geIOfjFIrgZuw3kjEr6TltlB8zfq28gpU=; b=KIZdsgGyDOu3MP9GlRPtkBPfRVw6b0CtCw/sixz44iwhDbDqW22aIp/dZcIQqgvYD2 W0iORISwL5jXHDiVKSNY/ZyMkf8yt6NG60OsqDbLZSvguKZbWRvyLUyiFaP0dizmu8ND B0HSMDynYx876GIwY035496zAWKDDHgdNIwbfXeMOIC5UimazNX7aEq8iEgREd2aWb1u WYFK56Z+H1VO+Z1hVbX3/J1Dqi79TuaCItFMi6wWk8Z1Z7zaJKURuLn5tl6AZ7eqpo/P AWHVL3XvRQs4aCQ3Y+CWrUEW39KtMCrA9ZZ2lRIgG6LF12j6ldta1LmWwGPZOGOk3qh+ 9udg== X-Received: by 10.140.150.149 with SMTP id 143mr87486792qhw.4.1426615094097; Tue, 17 Mar 2015 10:58:14 -0700 (PDT) Received: from ?IPv6:2001:420:2c8b:1300:18e6:dc2d:e21b:8558? ([2001:420:2c8b:1300:18e6:dc2d:e21b:8558]) by mx.google.com with ESMTPSA id x10sm10068330qha.2.2015.03.17.10.58.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 10:58:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ralph Droms In-Reply-To: <80E11ACB-1AE9-479E-A36A-1610C0EF307A@gmail.com> Date: Tue, 17 Mar 2015 13:58:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> <80E11ACB-1AE9-479E-A36A-1610C0EF307A@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Kerry Lynn , dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , The IESG , Tom Pusateri , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 17:58:19 -0000 Doug - Here is my summary of what I understand to be your concerns with = draft-ietf-dnssd-requirements-05: 1) A change from link-scope mDNS SD to a larger scope may result in the = existence and address of a device being made more widely available than = currently expected. 2) Some devices and networks are incapable of defending themselves = against unwanted access or other attacks once the address of the device = to be attacked is known. 3) Use of RFC 4193 is a way to protect against attacks enabled by the = increased scope of discovery envisioned by extended DNS-SD. You expressed these concerns during WG development and review of = draft-ietf-dnssd-requirements. Tim and I judged the consensus of the WG = to be in support of advancing the document to the IESG, based in part on = the following analysis: Points 1 and 2 are answered by the third paragraph of section 6.1. For = completeness, the last sentence of that paragraph might be extended to = include "and protection against other forms of attack". Point 3 tries to mandate a solution through a specific deployment = mechanism and is, therefore, out of scope for a requirements document. = It may also be more broadly out of scope of the dnssd charter, which = addresses just DNS-based service discovery and does not include = mandating network deployment requirements as part of a solution. If you do not agree that your concerns have been answered by this = analysis, please state the basis for your continued concern, so that we = can judge rough consensus on support for publication of the document. - Ralph From nobody Tue Mar 17 10:58:26 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7F01C1A87E7; Tue, 17 Mar 2015 10:58:19 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C1B1A8821; Tue, 17 Mar 2015 10:58:19 -0700 (PDT) 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 Ieie36TExYNG; Tue, 17 Mar 2015 10:58:15 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFCA31A87E7; Tue, 17 Mar 2015 10:58:14 -0700 (PDT) Received: by qcaz10 with SMTP id z10so16124401qca.1; Tue, 17 Mar 2015 10:58:14 -0700 (PDT) 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=krbJVDEjx0geIOfjFIrgZuw3kjEr6TltlB8zfq28gpU=; b=KIZdsgGyDOu3MP9GlRPtkBPfRVw6b0CtCw/sixz44iwhDbDqW22aIp/dZcIQqgvYD2 W0iORISwL5jXHDiVKSNY/ZyMkf8yt6NG60OsqDbLZSvguKZbWRvyLUyiFaP0dizmu8ND B0HSMDynYx876GIwY035496zAWKDDHgdNIwbfXeMOIC5UimazNX7aEq8iEgREd2aWb1u WYFK56Z+H1VO+Z1hVbX3/J1Dqi79TuaCItFMi6wWk8Z1Z7zaJKURuLn5tl6AZ7eqpo/P AWHVL3XvRQs4aCQ3Y+CWrUEW39KtMCrA9ZZ2lRIgG6LF12j6ldta1LmWwGPZOGOk3qh+ 9udg== X-Received: by 10.140.150.149 with SMTP id 143mr87486792qhw.4.1426615094097; Tue, 17 Mar 2015 10:58:14 -0700 (PDT) Received: from ?IPv6:2001:420:2c8b:1300:18e6:dc2d:e21b:8558? ([2001:420:2c8b:1300:18e6:dc2d:e21b:8558]) by mx.google.com with ESMTPSA id x10sm10068330qha.2.2015.03.17.10.58.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 10:58:13 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ralph Droms In-Reply-To: <80E11ACB-1AE9-479E-A36A-1610C0EF307A@gmail.com> Date: Tue, 17 Mar 2015 13:58:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> <80E11ACB-1AE9-479E-A36A-1610C0EF307A@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Kerry Lynn , dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , The IESG , Tom Pusateri , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 17:58:19 -0000 Doug - Here is my summary of what I understand to be your concerns with = draft-ietf-dnssd-requirements-05: 1) A change from link-scope mDNS SD to a larger scope may result in the = existence and address of a device being made more widely available than = currently expected. 2) Some devices and networks are incapable of defending themselves = against unwanted access or other attacks once the address of the device = to be attacked is known. 3) Use of RFC 4193 is a way to protect against attacks enabled by the = increased scope of discovery envisioned by extended DNS-SD. You expressed these concerns during WG development and review of = draft-ietf-dnssd-requirements. Tim and I judged the consensus of the WG = to be in support of advancing the document to the IESG, based in part on = the following analysis: Points 1 and 2 are answered by the third paragraph of section 6.1. For = completeness, the last sentence of that paragraph might be extended to = include "and protection against other forms of attack". Point 3 tries to mandate a solution through a specific deployment = mechanism and is, therefore, out of scope for a requirements document. = It may also be more broadly out of scope of the dnssd charter, which = addresses just DNS-based service discovery and does not include = mandating network deployment requirements as part of a solution. If you do not agree that your concerns have been answered by this = analysis, please state the basis for your continued concern, so that we = can judge rough consensus on support for publication of the document. - Ralph From nobody Tue Mar 17 11:22:16 2015 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 971471A883C; Tue, 17 Mar 2015 11:22:10 -0700 (PDT) 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 ApaTFVN7LY_e; Tue, 17 Mar 2015 11:22:09 -0700 (PDT) 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 39A7F1A886F; Tue, 17 Mar 2015 11:22:08 -0700 (PDT) Received: from [192.168.1.116] (67.20.136.197.dyn-e120.pool.hargray.net [67.20.136.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 60CB0230B; Tue, 17 Mar 2015 14:17:58 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_61649CBE-9E40-4CC1-A776-CC7D7E5058C2"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Tom Pusateri In-Reply-To: <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> Date: Tue, 17 Mar 2015 14:22:05 -0400 Message-Id: References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , The IESG , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 18:22:10 -0000 --Apple-Mail=_61649CBE-9E40-4CC1-A776-CC7D7E5058C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 17, 2015, at 1:51 PM, Ralph Droms = wrote: >=20 > Stephen - let me summarize the responses to your comments; please let = us know if these responses will be sufficient to address your = comments... >=20 >> - 6.6: I think one can also leak private information by >> searching in too broad a scope, e.g. if the client can be >> fingerprinted allowing re-identification. I think that's >> different from the example given, and maybe worth noting too. >=20 > Kerry pointed out that the difference between the threat from = searching for services as opposed to other forms of name resolution in = arbitrary zones is unclear. While it would be possible to edit this = text to include searching as well as registration, I think the resulting = text would be too restrictive to allow for useful solutions. Would you = be willing to accept the text as it exists or do you have some other new = text to suggest? >=20 > - Ralph >=20 I tried to make it clear in my response yesterday that this was a = non-issue but maybe I wasn't as direct as I should have been. There is no leak of private information by the client. The client is in = total control of the scope and the recipient of it's query. Tom --Apple-Mail=_61649CBE-9E40-4CC1-A776-CC7D7E5058C2 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 iQEcBAEBAgAGBQJVCHDNAAoJEPk0GMVmUuYMFt4IAMai9NlKwUwPr/GgLI5A3Vx5 8SZ93R3v+9kwE4zpy2odKE99LR25OE7PjDROhv0UnPjh8dO+YEzbws8XL60BraGv Ql5sne2FJlQf5E4fHojzysRF9+gyruGF6sM9mm/on8tJkD86g30yg9tg/VT5YQ57 1lEzv8gFUvL17j7egd4Hsp1Iz1AMTpwrkrudyCPB0M0IejXGydaHq7WtxQg5+MxM KSrkeY199HkIlYtBB1cFGiJQ07dDiHBuKh6h9E/h78IfRn3ojPbBBqHYYPSdWbiJ iGCGAilZsiS7XtKGXdNJ008V1qrxqesImJwTbMOQriySTuivZhemWpo9/2V7CiY= =s/AI -----END PGP SIGNATURE----- --Apple-Mail=_61649CBE-9E40-4CC1-A776-CC7D7E5058C2-- From nobody Tue Mar 17 11:22:18 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id C32291A886F; Tue, 17 Mar 2015 11:22:10 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971471A883C; Tue, 17 Mar 2015 11:22:10 -0700 (PDT) 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 ApaTFVN7LY_e; Tue, 17 Mar 2015 11:22:09 -0700 (PDT) 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 39A7F1A886F; Tue, 17 Mar 2015 11:22:08 -0700 (PDT) Received: from [192.168.1.116] (67.20.136.197.dyn-e120.pool.hargray.net [67.20.136.197]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 60CB0230B; Tue, 17 Mar 2015 14:17:58 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_61649CBE-9E40-4CC1-A776-CC7D7E5058C2"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Tom Pusateri In-Reply-To: <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> Date: Tue, 17 Mar 2015 14:22:05 -0400 Message-Id: References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , The IESG , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 18:22:10 -0000 --Apple-Mail=_61649CBE-9E40-4CC1-A776-CC7D7E5058C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 17, 2015, at 1:51 PM, Ralph Droms = wrote: >=20 > Stephen - let me summarize the responses to your comments; please let = us know if these responses will be sufficient to address your = comments... >=20 >> - 6.6: I think one can also leak private information by >> searching in too broad a scope, e.g. if the client can be >> fingerprinted allowing re-identification. I think that's >> different from the example given, and maybe worth noting too. >=20 > Kerry pointed out that the difference between the threat from = searching for services as opposed to other forms of name resolution in = arbitrary zones is unclear. While it would be possible to edit this = text to include searching as well as registration, I think the resulting = text would be too restrictive to allow for useful solutions. Would you = be willing to accept the text as it exists or do you have some other new = text to suggest? >=20 > - Ralph >=20 I tried to make it clear in my response yesterday that this was a = non-issue but maybe I wasn't as direct as I should have been. There is no leak of private information by the client. The client is in = total control of the scope and the recipient of it's query. Tom --Apple-Mail=_61649CBE-9E40-4CC1-A776-CC7D7E5058C2 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 iQEcBAEBAgAGBQJVCHDNAAoJEPk0GMVmUuYMFt4IAMai9NlKwUwPr/GgLI5A3Vx5 8SZ93R3v+9kwE4zpy2odKE99LR25OE7PjDROhv0UnPjh8dO+YEzbws8XL60BraGv Ql5sne2FJlQf5E4fHojzysRF9+gyruGF6sM9mm/on8tJkD86g30yg9tg/VT5YQ57 1lEzv8gFUvL17j7egd4Hsp1Iz1AMTpwrkrudyCPB0M0IejXGydaHq7WtxQg5+MxM KSrkeY199HkIlYtBB1cFGiJQ07dDiHBuKh6h9E/h78IfRn3ojPbBBqHYYPSdWbiJ iGCGAilZsiS7XtKGXdNJ008V1qrxqesImJwTbMOQriySTuivZhemWpo9/2V7CiY= =s/AI -----END PGP SIGNATURE----- --Apple-Mail=_61649CBE-9E40-4CC1-A776-CC7D7E5058C2-- From nobody Tue Mar 17 12:32:22 2015 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 F2ECB1A888F; Tue, 17 Mar 2015 12:32:21 -0700 (PDT) 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 mtuOBw-Pm_6n; Tue, 17 Mar 2015 12:32:20 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF791A1B76; Tue, 17 Mar 2015 12:32:20 -0700 (PDT) Received: by qgez64 with SMTP id z64so18072005qge.2; Tue, 17 Mar 2015 12:32:19 -0700 (PDT) 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=v0RtKZ0VTFykhNV0msF9KvLF5fxvdnLFIFeIxKuHJ+o=; b=rRfBtNe+A1dKe1gcToN89Dv1+xDUStediQav4D2CRLwOjLcZrVL+3g1sjdhPEgI4VM mFdVWTbsWHuAECI59mnY5dml7A0mySZ2vq7R3ngEl08jtaHOmilQPjkgv7ukBDDzW2vS Kmapr632RoHItwJ5mgjN7a8wuhNeNYMiGuGiiKOb+XXNfSwPBdZ+Pil8xSjLc15of6D0 JD1JckEWtLSjKOEy2fEGt2q8j9RtCbpHq69RqMfGiOmJUttad1R0HSKCpGUbfQsRkne5 zcMDfh+mIyDHsbPbn72bFjH1je7Vly7ta+2ZK9fP+Pt+O69lwRpWNhx5unXZrIb6ViSA IDGg== X-Received: by 10.140.81.242 with SMTP id f105mr83059591qgd.33.1426620739394; Tue, 17 Mar 2015 12:32:19 -0700 (PDT) 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 132sm10235071qhf.17.2015.03.17.12.32.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 12:32:18 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: Date: Tue, 17 Mar 2015 12:32:17 -0700 Content-Transfer-Encoding: 7bit Message-Id: <695E3CFA-B385-481E-9333-68BE1862B29F@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> <80E11ACB-1AE9-479E-A36A-1610C0EF307A@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Kerry Lynn , dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , The IESG , Tom Pusateri , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 19:32:22 -0000 Dear Ralph, > On Mar 17, 2015, at 10:58 AM, Ralph Droms wrote: > > Doug - Here is my summary of what I understand to be your concerns with > draft-ietf-dnssd-requirements-05: > > 1) A change from link-scope mDNS SD to a larger scope may result in the > existence and address of a device being made more widely available than > currently expected. Of course. > 2) Some devices and networks are incapable of defending themselves > against unwanted access or other attacks once the address of the device > to be attacked is known. When the _wrong_ address is published within DNS that then permits direct Internet access, this may evade desired protections. Although many mDNS devices report all such options, such reporting is only seen on the local network. > 3) Use of RFC 4193 is a way to protect against attacks enabled by the > increased scope of discovery envisioned by extended DNS-SD. Use of RFC4193 is used to protect Homenet as well as various enterprise environments. It is also used by Apple in their Back-To-My-Mac scheme. > You expressed these concerns during WG development and review of > draft-ietf-dnssd-requirements. Tim and I judged the consensus of the > WG to be in support of advancing the document to the IESG, based in part > on the following analysis: > > Points 1 and 2 are answered by the third paragraph of section 6.1. For > completeness, the last sentence of that paragraph might be extended to > include "and protection against other forms of attack". Address selection preferences represent critical security aspects that MUST BE supported by the protocol. If RFC1918 or RFC4193 addresses are reported via mDNS to the DNS-SD proxy, there MUST be a requirement for these addresses to be used over any Internet routable address. It is important these requirements make it clear mDNS is not suitable for publishing hosts on the Internet. Where safer alternatives exist, such publication MUST REQUIRE administrative intervention. Otherwise organizations making use of such schemes will be placed at great risk. > > Point 3 tries to mandate a solution through a specific deployment > mechanism and is, therefore, out of scope for a requirements document. > It may also be more broadly out of scope of the dnssd charter, which > addresses just DNS-based service discovery and does not include mandating > network deployment requirements as part of a solution. This point offers an example strategy (address preferences) that MUST be supported. Ensuring support is not the same as making this a mandate! It seems clear this group failed to develop schemes to protect devices that normally limit access to that of the local network, as provided by constraints imposed by mDNS. As such, there should have been greater review of those offered by Homenet or even Back-To-My-Mac. > If you do not agree that your concerns have been answered by this > analysis, please state the basis for your continued concern, so that we > can judge rough consensus on support for publication of the document. The requirements document remains critically flawed without justification. Ensuring an ability to offer safe deployment unfortunately does not prevent less safe schemes. Nevertheless, supporting a safe scheme should be a basic requirement. Regards, Douglas Otis From nobody Tue Mar 17 12:32:31 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 235791A88A5; Tue, 17 Mar 2015 12:32:22 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2ECB1A888F; Tue, 17 Mar 2015 12:32:21 -0700 (PDT) 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 mtuOBw-Pm_6n; Tue, 17 Mar 2015 12:32:20 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF791A1B76; Tue, 17 Mar 2015 12:32:20 -0700 (PDT) Received: by qgez64 with SMTP id z64so18072005qge.2; Tue, 17 Mar 2015 12:32:19 -0700 (PDT) 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=v0RtKZ0VTFykhNV0msF9KvLF5fxvdnLFIFeIxKuHJ+o=; b=rRfBtNe+A1dKe1gcToN89Dv1+xDUStediQav4D2CRLwOjLcZrVL+3g1sjdhPEgI4VM mFdVWTbsWHuAECI59mnY5dml7A0mySZ2vq7R3ngEl08jtaHOmilQPjkgv7ukBDDzW2vS Kmapr632RoHItwJ5mgjN7a8wuhNeNYMiGuGiiKOb+XXNfSwPBdZ+Pil8xSjLc15of6D0 JD1JckEWtLSjKOEy2fEGt2q8j9RtCbpHq69RqMfGiOmJUttad1R0HSKCpGUbfQsRkne5 zcMDfh+mIyDHsbPbn72bFjH1je7Vly7ta+2ZK9fP+Pt+O69lwRpWNhx5unXZrIb6ViSA IDGg== X-Received: by 10.140.81.242 with SMTP id f105mr83059591qgd.33.1426620739394; Tue, 17 Mar 2015 12:32:19 -0700 (PDT) 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 132sm10235071qhf.17.2015.03.17.12.32.17 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 12:32:18 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: text/plain; charset=us-ascii From: Douglas Otis In-Reply-To: Date: Tue, 17 Mar 2015 12:32:17 -0700 Content-Transfer-Encoding: 7bit Message-Id: <695E3CFA-B385-481E-9333-68BE1862B29F@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> <80E11ACB-1AE9-479E-A36A-1610C0EF307A@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Kerry Lynn , dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , The IESG , Tom Pusateri , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 19:32:22 -0000 Dear Ralph, > On Mar 17, 2015, at 10:58 AM, Ralph Droms wrote: > > Doug - Here is my summary of what I understand to be your concerns with > draft-ietf-dnssd-requirements-05: > > 1) A change from link-scope mDNS SD to a larger scope may result in the > existence and address of a device being made more widely available than > currently expected. Of course. > 2) Some devices and networks are incapable of defending themselves > against unwanted access or other attacks once the address of the device > to be attacked is known. When the _wrong_ address is published within DNS that then permits direct Internet access, this may evade desired protections. Although many mDNS devices report all such options, such reporting is only seen on the local network. > 3) Use of RFC 4193 is a way to protect against attacks enabled by the > increased scope of discovery envisioned by extended DNS-SD. Use of RFC4193 is used to protect Homenet as well as various enterprise environments. It is also used by Apple in their Back-To-My-Mac scheme. > You expressed these concerns during WG development and review of > draft-ietf-dnssd-requirements. Tim and I judged the consensus of the > WG to be in support of advancing the document to the IESG, based in part > on the following analysis: > > Points 1 and 2 are answered by the third paragraph of section 6.1. For > completeness, the last sentence of that paragraph might be extended to > include "and protection against other forms of attack". Address selection preferences represent critical security aspects that MUST BE supported by the protocol. If RFC1918 or RFC4193 addresses are reported via mDNS to the DNS-SD proxy, there MUST be a requirement for these addresses to be used over any Internet routable address. It is important these requirements make it clear mDNS is not suitable for publishing hosts on the Internet. Where safer alternatives exist, such publication MUST REQUIRE administrative intervention. Otherwise organizations making use of such schemes will be placed at great risk. > > Point 3 tries to mandate a solution through a specific deployment > mechanism and is, therefore, out of scope for a requirements document. > It may also be more broadly out of scope of the dnssd charter, which > addresses just DNS-based service discovery and does not include mandating > network deployment requirements as part of a solution. This point offers an example strategy (address preferences) that MUST be supported. Ensuring support is not the same as making this a mandate! It seems clear this group failed to develop schemes to protect devices that normally limit access to that of the local network, as provided by constraints imposed by mDNS. As such, there should have been greater review of those offered by Homenet or even Back-To-My-Mac. > If you do not agree that your concerns have been answered by this > analysis, please state the basis for your continued concern, so that we > can judge rough consensus on support for publication of the document. The requirements document remains critically flawed without justification. Ensuring an ability to offer safe deployment unfortunately does not prevent less safe schemes. Nevertheless, supporting a safe scheme should be a basic requirement. Regards, Douglas Otis From nobody Tue Mar 17 12:58:50 2015 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 1A7151A1B64; Tue, 17 Mar 2015 12:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 AyGRO77m3VyX; Tue, 17 Mar 2015 12:58:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B77B1A88D5; Tue, 17 Mar 2015 12:58:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C2DF5BE56; Tue, 17 Mar 2015 19:58:40 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxb1PbneSaIz; Tue, 17 Mar 2015 19:58:39 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.20.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 82CA5BE54; Tue, 17 Mar 2015 19:58:39 +0000 (GMT) Message-ID: <5508876F.9030904@cs.tcd.ie> Date: Tue, 17 Mar 2015 19:58:39 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ralph Droms References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> In-Reply-To: <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , Chown Tim Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 19:58:46 -0000 Hi Ralph, Those are comments such that I'm fine if you prefer no change. One this one... On 17/03/15 17:51, Ralph Droms wrote: > Kerry pointed out that the difference between the threat from > searching for services as opposed to other forms of name resolution > in arbitrary zones is unclear. While it would be possible to edit > this text to include searching as well as registration, I think the > resulting text would be too restrictive to allow for useful > solutions. Would you be willing to accept the text as it exists or > do you have some other new text to suggest? I don't have text to suggest sorry. The concern here is that client devices will issue searches that, as a result of dnssd, will be broadcast further than previously and perhaps further than the client device maker expected. That could allow for device/user fingerprinting/re-identification in a more widespread domain than was previously the case. For example, a bad actor could install something on a campus network that'd spot and record such details, perhaps in the hope of breaking into the client device (if they can fingerprint it as one with a specific vulnerability). I don't think I saw that noted in the draft but in any case what'll eventually matter is that the eventual protocol does not make such things worse. Noting them here would probably make it more likely we get a good result, but isn't entirely needed. S. From nobody Tue Mar 17 12:58:51 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4C4321A88DA; Tue, 17 Mar 2015 12:58:46 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7151A1B64; Tue, 17 Mar 2015 12:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 AyGRO77m3VyX; Tue, 17 Mar 2015 12:58:45 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B77B1A88D5; Tue, 17 Mar 2015 12:58:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C2DF5BE56; Tue, 17 Mar 2015 19:58:40 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxb1PbneSaIz; Tue, 17 Mar 2015 19:58:39 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.20.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 82CA5BE54; Tue, 17 Mar 2015 19:58:39 +0000 (GMT) Message-ID: <5508876F.9030904@cs.tcd.ie> Date: Tue, 17 Mar 2015 19:58:39 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ralph Droms References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> In-Reply-To: <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, The IESG , Chown Tim Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 19:58:46 -0000 Hi Ralph, Those are comments such that I'm fine if you prefer no change. One this one... On 17/03/15 17:51, Ralph Droms wrote: > Kerry pointed out that the difference between the threat from > searching for services as opposed to other forms of name resolution > in arbitrary zones is unclear. While it would be possible to edit > this text to include searching as well as registration, I think the > resulting text would be too restrictive to allow for useful > solutions. Would you be willing to accept the text as it exists or > do you have some other new text to suggest? I don't have text to suggest sorry. The concern here is that client devices will issue searches that, as a result of dnssd, will be broadcast further than previously and perhaps further than the client device maker expected. That could allow for device/user fingerprinting/re-identification in a more widespread domain than was previously the case. For example, a bad actor could install something on a campus network that'd spot and record such details, perhaps in the hope of breaking into the client device (if they can fingerprint it as one with a specific vulnerability). I don't think I saw that noted in the draft but in any case what'll eventually matter is that the eventual protocol does not make such things worse. Noting them here would probably make it more likely we get a good result, but isn't entirely needed. S. From nobody Tue Mar 17 13:11:32 2015 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 C622E1A8893; Tue, 17 Mar 2015 13:11:31 -0700 (PDT) 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 PM4nmin-B6AQ; Tue, 17 Mar 2015 13:11:29 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6911A1B64; Tue, 17 Mar 2015 13:11:29 -0700 (PDT) Received: by qgfa8 with SMTP id a8so19215081qgf.0; Tue, 17 Mar 2015 13:11:29 -0700 (PDT) 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=C9IlxCChNzu5Yj5oFvHQcjUJbpPq4F6OWsy44HfXKFY=; b=jFeDgsh6GP3Zl/alMO7nw+B7xJYXuiOaO7IpZYPoOGgTtmmvYfvBt4GvmoUIb90emG whqiu+iMS8chsSh0sxgDzrp4iRdkD24nYX+M5Y4SyRCmBuP0oUbYjpPb1JVfaPQjLF6I HiINtbaMxoSaFx7SZWKeusgYXRxCsD+rltCM442MmXkXzK8HW4uQyAAZ51LVM0G96oiE /Sk7Je3vJ920Vx5PwEmQ4uLKPlC4rwkxwecYyXbTB6LBrpEVxKQ5mnaZmdiOHCT+37Om 5gUvn/Nk1j4AaI/KSdys0ruf6V17lxlgI0SZLAshuMr/rMhqsoZUs8NrQlKCxGtH3/+s cItw== X-Received: by 10.140.218.196 with SMTP id o187mr59639285qhb.30.1426623088931; Tue, 17 Mar 2015 13:11:28 -0700 (PDT) Received: from [10.131.118.44] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id 8sm10299746qhr.32.2015.03.17.13.11.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 13:11:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ralph Droms In-Reply-To: <695E3CFA-B385-481E-9333-68BE1862B29F@gmail.com> Date: Tue, 17 Mar 2015 16:11:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> <80E11ACB-1AE9-479E-A36A-1610C0EF307A@gmail.com> <695E3CFA-B385-481E-9333-68BE1862B29F@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Kerry Lynn , dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , The IESG , Tom Pusateri , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 20:11:32 -0000 > On Mar 17, 2015, at 3:32 PM 3/17/15, Douglas Otis = wrote: >=20 > Dear Ralph, >=20 >> On Mar 17, 2015, at 10:58 AM, Ralph Droms = wrote: >>=20 >> Doug - Here is my summary of what I understand to be your concerns = with >> draft-ietf-dnssd-requirements-05: >>=20 >> 1) A change from link-scope mDNS SD to a larger scope may result in = the >> existence and address of a device being made more widely available = than >> currently expected. >=20 > Of course. >=20 >> 2) Some devices and networks are incapable of defending themselves >> against unwanted access or other attacks once the address of the = device >> to be attacked is known. >=20 > When the _wrong_ address is published within DNS that then permits = direct > Internet access, this may evade desired protections. Although many = mDNS > devices report all such options, such reporting is only seen on the = local=20 > network. I need to parse your response carefully so that we can understand each = other. In what sense is an address that permits direct address a = "_wrong_" address? Is this sentence equivalent: "When an address (such = as a globally routable address) is published within DNS that then = permits direct Internet access, [...]" To make sure I understand the second sentence, is this sentence = equivalent: "Although many mDNS implementations advertise all of the = addresses available for a device, those advertisements are restricted to = the local link and, therefore, don't advertise globally routable = addresses to the Internet." >> 3) Use of RFC 4193 is a way to protect against attacks enabled by the >> increased scope of discovery envisioned by extended DNS-SD. >=20 > Use of RFC4193 is used to protect Homenet as well as various = enterprise > environments. It is also used by Apple in their Back-To-My-Mac = scheme. To be clear, you agree with my point 3 and you cite two examples of the = use of RFC 4193. My understanding is that Homenet does not mandate the = use of RFC 4193, perhaps because of the difficulties in mandating such = usage; from section 2.4 of RFC 7368: "Devices in a homenet may be given = only a ULA as a means to restrict reachability from outside the = homenet." My understanding is that RFC 4913 addresses are used in = Back-To-My-Mac as an identifier if no other IPv6 address is available, = rather than to restrict reachability. Back-To-My-Mac uses an array of = other security mechanisms to protect devices using the technology. =20 >=20 >> You expressed these concerns during WG development and review of >> draft-ietf-dnssd-requirements. Tim and I judged the consensus of the >> WG to be in support of advancing the document to the IESG, based in = part >> on the following analysis: >>=20 >> Points 1 and 2 are answered by the third paragraph of section 6.1. = For >> completeness, the last sentence of that paragraph might be extended = to >> include "and protection against other forms of attack". >=20 > Address selection preferences represent critical security aspects that=20= > MUST BE supported by the protocol. Do you mean selection of which among several available addresses are = advertised through DNS-SD? > If RFC1918 or RFC4193 addresses are=20 > reported via mDNS to the DNS-SD proxy, there MUST be a requirement = for=20 > these addresses to be used over any Internet routable address. Used where or by what devices? Where are these restrictions enforced? > It is=20 > important these requirements make it clear mDNS is not suitable for=20 > publishing hosts on the Internet. Where safer alternatives exist, = such=20 > publication MUST REQUIRE administrative intervention. Otherwise=20 > organizations making use of such schemes will be placed at great risk. In my opinion, there is not consensus in the WG to support your concern. = The current text in the document represents WG consensus for the = description of the potential problem. >> Point 3 tries to mandate a solution through a specific deployment >> mechanism and is, therefore, out of scope for a requirements = document. >> It may also be more broadly out of scope of the dnssd charter, which >> addresses just DNS-based service discovery and does not include = mandating >> network deployment requirements as part of a solution. >=20 > This point offers an example strategy (address preferences) that MUST = be=20 > supported. Ensuring support is not the same as making this a mandate! = =20 > It seems clear this group failed to develop schemes to protect devices=20= > that normally limit access to that of the local network, as provided = by=20 > constraints imposed by mDNS. As such, there should have been greater=20= > review of those offered by Homenet or even Back-To-My-Mac. "example strategy [...] that MUST be supported" sounds like a mandate to = me. This is a requirements document, not a final design, and therefore = this document does not need to develop a solution to the problem you are = concerned with. >=20 >> If you do not agree that your concerns have been answered by this >> analysis, please state the basis for your continued concern, so that = we >> can judge rough consensus on support for publication of the document. >=20 > The requirements document remains critically flawed without = justification.=20 > Ensuring an ability to offer safe deployment unfortunately does not = prevent=20 > less safe schemes. Nevertheless, supporting a safe scheme should be a = basic=20 > requirement.=20 Can you give a specific requirement or requirements that could be added = to the document to satisfy your concerns? >=20 > Regards, > Douglas Otis >=20 From nobody Tue Mar 17 13:11:37 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id EA2F51A88DD; Tue, 17 Mar 2015 13:11:31 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C622E1A8893; Tue, 17 Mar 2015 13:11:31 -0700 (PDT) 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 PM4nmin-B6AQ; Tue, 17 Mar 2015 13:11:29 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6911A1B64; Tue, 17 Mar 2015 13:11:29 -0700 (PDT) Received: by qgfa8 with SMTP id a8so19215081qgf.0; Tue, 17 Mar 2015 13:11:29 -0700 (PDT) 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=C9IlxCChNzu5Yj5oFvHQcjUJbpPq4F6OWsy44HfXKFY=; b=jFeDgsh6GP3Zl/alMO7nw+B7xJYXuiOaO7IpZYPoOGgTtmmvYfvBt4GvmoUIb90emG whqiu+iMS8chsSh0sxgDzrp4iRdkD24nYX+M5Y4SyRCmBuP0oUbYjpPb1JVfaPQjLF6I HiINtbaMxoSaFx7SZWKeusgYXRxCsD+rltCM442MmXkXzK8HW4uQyAAZ51LVM0G96oiE /Sk7Je3vJ920Vx5PwEmQ4uLKPlC4rwkxwecYyXbTB6LBrpEVxKQ5mnaZmdiOHCT+37Om 5gUvn/Nk1j4AaI/KSdys0ruf6V17lxlgI0SZLAshuMr/rMhqsoZUs8NrQlKCxGtH3/+s cItw== X-Received: by 10.140.218.196 with SMTP id o187mr59639285qhb.30.1426623088931; Tue, 17 Mar 2015 13:11:28 -0700 (PDT) Received: from [10.131.118.44] (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPSA id 8sm10299746qhr.32.2015.03.17.13.11.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 13:11:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Ralph Droms In-Reply-To: <695E3CFA-B385-481E-9333-68BE1862B29F@gmail.com> Date: Tue, 17 Mar 2015 16:11:26 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> <80E11ACB-1AE9-479E-A36A-1610C0EF307A@gmail.com> <695E3CFA-B385-481E-9333-68BE1862B29F@gmail.com> To: Douglas Otis X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Kerry Lynn , dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , The IESG , Tom Pusateri , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 20:11:32 -0000 > On Mar 17, 2015, at 3:32 PM 3/17/15, Douglas Otis = wrote: >=20 > Dear Ralph, >=20 >> On Mar 17, 2015, at 10:58 AM, Ralph Droms = wrote: >>=20 >> Doug - Here is my summary of what I understand to be your concerns = with >> draft-ietf-dnssd-requirements-05: >>=20 >> 1) A change from link-scope mDNS SD to a larger scope may result in = the >> existence and address of a device being made more widely available = than >> currently expected. >=20 > Of course. >=20 >> 2) Some devices and networks are incapable of defending themselves >> against unwanted access or other attacks once the address of the = device >> to be attacked is known. >=20 > When the _wrong_ address is published within DNS that then permits = direct > Internet access, this may evade desired protections. Although many = mDNS > devices report all such options, such reporting is only seen on the = local=20 > network. I need to parse your response carefully so that we can understand each = other. In what sense is an address that permits direct address a = "_wrong_" address? Is this sentence equivalent: "When an address (such = as a globally routable address) is published within DNS that then = permits direct Internet access, [...]" To make sure I understand the second sentence, is this sentence = equivalent: "Although many mDNS implementations advertise all of the = addresses available for a device, those advertisements are restricted to = the local link and, therefore, don't advertise globally routable = addresses to the Internet." >> 3) Use of RFC 4193 is a way to protect against attacks enabled by the >> increased scope of discovery envisioned by extended DNS-SD. >=20 > Use of RFC4193 is used to protect Homenet as well as various = enterprise > environments. It is also used by Apple in their Back-To-My-Mac = scheme. To be clear, you agree with my point 3 and you cite two examples of the = use of RFC 4193. My understanding is that Homenet does not mandate the = use of RFC 4193, perhaps because of the difficulties in mandating such = usage; from section 2.4 of RFC 7368: "Devices in a homenet may be given = only a ULA as a means to restrict reachability from outside the = homenet." My understanding is that RFC 4913 addresses are used in = Back-To-My-Mac as an identifier if no other IPv6 address is available, = rather than to restrict reachability. Back-To-My-Mac uses an array of = other security mechanisms to protect devices using the technology. =20 >=20 >> You expressed these concerns during WG development and review of >> draft-ietf-dnssd-requirements. Tim and I judged the consensus of the >> WG to be in support of advancing the document to the IESG, based in = part >> on the following analysis: >>=20 >> Points 1 and 2 are answered by the third paragraph of section 6.1. = For >> completeness, the last sentence of that paragraph might be extended = to >> include "and protection against other forms of attack". >=20 > Address selection preferences represent critical security aspects that=20= > MUST BE supported by the protocol. Do you mean selection of which among several available addresses are = advertised through DNS-SD? > If RFC1918 or RFC4193 addresses are=20 > reported via mDNS to the DNS-SD proxy, there MUST be a requirement = for=20 > these addresses to be used over any Internet routable address. Used where or by what devices? Where are these restrictions enforced? > It is=20 > important these requirements make it clear mDNS is not suitable for=20 > publishing hosts on the Internet. Where safer alternatives exist, = such=20 > publication MUST REQUIRE administrative intervention. Otherwise=20 > organizations making use of such schemes will be placed at great risk. In my opinion, there is not consensus in the WG to support your concern. = The current text in the document represents WG consensus for the = description of the potential problem. >> Point 3 tries to mandate a solution through a specific deployment >> mechanism and is, therefore, out of scope for a requirements = document. >> It may also be more broadly out of scope of the dnssd charter, which >> addresses just DNS-based service discovery and does not include = mandating >> network deployment requirements as part of a solution. >=20 > This point offers an example strategy (address preferences) that MUST = be=20 > supported. Ensuring support is not the same as making this a mandate! = =20 > It seems clear this group failed to develop schemes to protect devices=20= > that normally limit access to that of the local network, as provided = by=20 > constraints imposed by mDNS. As such, there should have been greater=20= > review of those offered by Homenet or even Back-To-My-Mac. "example strategy [...] that MUST be supported" sounds like a mandate to = me. This is a requirements document, not a final design, and therefore = this document does not need to develop a solution to the problem you are = concerned with. >=20 >> If you do not agree that your concerns have been answered by this >> analysis, please state the basis for your continued concern, so that = we >> can judge rough consensus on support for publication of the document. >=20 > The requirements document remains critically flawed without = justification.=20 > Ensuring an ability to offer safe deployment unfortunately does not = prevent=20 > less safe schemes. Nevertheless, supporting a safe scheme should be a = basic=20 > requirement.=20 Can you give a specific requirement or requirements that could be added = to the document to satisfy your concerns? >=20 > Regards, > Douglas Otis >=20 From nobody Tue Mar 17 13:25:23 2015 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 4B4461A88E9; Tue, 17 Mar 2015 13:25:21 -0700 (PDT) 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 1j9YRASeY9HM; Tue, 17 Mar 2015 13:25:16 -0700 (PDT) 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 8FAA31A88E7; Tue, 17 Mar 2015 13:25:16 -0700 (PDT) Received: from [172.16.21.162] (cpe-098-122-037-156.sc.res.rr.com [98.122.37.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 1CED6233A; Tue, 17 Mar 2015 16:21:04 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D4D997EE-6010-4915-BCE1-1AA73904AE4F"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Tom Pusateri In-Reply-To: <5508876F.9030904@cs.tcd.ie> Date: Tue, 17 Mar 2015 16:25:11 -0400 Message-Id: References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> <5508876F.9030904@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , Ralph Droms , The IESG Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 20:25:21 -0000 --Apple-Mail=_D4D997EE-6010-4915-BCE1-1AA73904AE4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 17, 2015, at 3:58 PM, Stephen Farrell = wrote: >=20 >=20 > Hi Ralph, >=20 > Those are comments such that I'm fine if you prefer no change. >=20 > One this one... >=20 > On 17/03/15 17:51, Ralph Droms wrote: >> Kerry pointed out that the difference between the threat from >> searching for services as opposed to other forms of name resolution >> in arbitrary zones is unclear. While it would be possible to edit >> this text to include searching as well as registration, I think the >> resulting text would be too restrictive to allow for useful >> solutions. Would you be willing to accept the text as it exists or >> do you have some other new text to suggest? >=20 > I don't have text to suggest sorry. The concern here is that > client devices will issue searches that, as a result of dnssd, > will be broadcast further than previously and perhaps further > than the client device maker expected. That could allow for > device/user fingerprinting/re-identification in a more > widespread domain than was previously the case. For example, > a bad actor could install something on a campus network that'd > spot and record such details, perhaps in the hope of breaking > into the client device (if they can fingerprint it as one > with a specific vulnerability). >=20 > I don't think I saw that noted in the draft but in any case > what'll eventually matter is that the eventual protocol does > not make such things worse. Noting them here would probably > make it more likely we get a good result, but isn't entirely > needed. >=20 > S. I'm not sure I understand your scenario. Clients issue searches in the form of unicast DNS queries to DNS servers = (or proxies). This is the same as with wide-area bonjour. Only now, this = may cause the proxies to issue their own multicast queries on a local = network in order to ensure their cache is current. The original client's = searches are never broadcast further than they were before. A bad actor = would have to intercept the unicast queries from the client (which may = be TLS encoded). To do this, the bad actor must have compromised some = network device to do this. Tom --Apple-Mail=_D4D997EE-6010-4915-BCE1-1AA73904AE4F 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 iQEcBAEBAgAGBQJVCI2nAAoJEPk0GMVmUuYMgowIAK7tRSFIQs9cnvEfpROEjHEZ oGDb9YmfkDeQBTbe+DcfAmemso/yIigJmSgE+ZqOXQFNifrHwrIFSA6/0nzCCQ4s ybo4IUGMSpyTkIMDb7BGw0jCDgz/Bnb0FWptfdFms97Xe/CJ+SAC0ASvOppcJM6F dze58ZEBVWPuszpjXdwUZX8991bCKUMvHGTMlt0oiodscGpRuDRg8fszYwo+cYVR 2sJ4Jt7F77DJ+svD+N0L9R7TS4ObfLJkplgca5cXYjjRHkd/gZwPZNn7ONCl/6wE QNJjtFUL/k8Omw+lBQSGkcdhpgFhrck9/jrDrcN6rV8T0/+yEYCXGGR5zlrGcvw= =cGxG -----END PGP SIGNATURE----- --Apple-Mail=_D4D997EE-6010-4915-BCE1-1AA73904AE4F-- From nobody Tue Mar 17 13:25:27 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7114C1A88EA; Tue, 17 Mar 2015 13:25:21 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4461A88E9; Tue, 17 Mar 2015 13:25:21 -0700 (PDT) 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 1j9YRASeY9HM; Tue, 17 Mar 2015 13:25:16 -0700 (PDT) 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 8FAA31A88E7; Tue, 17 Mar 2015 13:25:16 -0700 (PDT) Received: from [172.16.21.162] (cpe-098-122-037-156.sc.res.rr.com [98.122.37.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 1CED6233A; Tue, 17 Mar 2015 16:21:04 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D4D997EE-6010-4915-BCE1-1AA73904AE4F"; protocol="application/pgp-signature"; micalg=pgp-sha1 X-Pgp-Agent: GPGMail 2.5b5 From: Tom Pusateri In-Reply-To: <5508876F.9030904@cs.tcd.ie> Date: Tue, 17 Mar 2015 16:25:11 -0400 Message-Id: References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> <5508876F.9030904@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , Ralph Droms , The IESG Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 20:25:21 -0000 --Apple-Mail=_D4D997EE-6010-4915-BCE1-1AA73904AE4F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 17, 2015, at 3:58 PM, Stephen Farrell = wrote: >=20 >=20 > Hi Ralph, >=20 > Those are comments such that I'm fine if you prefer no change. >=20 > One this one... >=20 > On 17/03/15 17:51, Ralph Droms wrote: >> Kerry pointed out that the difference between the threat from >> searching for services as opposed to other forms of name resolution >> in arbitrary zones is unclear. While it would be possible to edit >> this text to include searching as well as registration, I think the >> resulting text would be too restrictive to allow for useful >> solutions. Would you be willing to accept the text as it exists or >> do you have some other new text to suggest? >=20 > I don't have text to suggest sorry. The concern here is that > client devices will issue searches that, as a result of dnssd, > will be broadcast further than previously and perhaps further > than the client device maker expected. That could allow for > device/user fingerprinting/re-identification in a more > widespread domain than was previously the case. For example, > a bad actor could install something on a campus network that'd > spot and record such details, perhaps in the hope of breaking > into the client device (if they can fingerprint it as one > with a specific vulnerability). >=20 > I don't think I saw that noted in the draft but in any case > what'll eventually matter is that the eventual protocol does > not make such things worse. Noting them here would probably > make it more likely we get a good result, but isn't entirely > needed. >=20 > S. I'm not sure I understand your scenario. Clients issue searches in the form of unicast DNS queries to DNS servers = (or proxies). This is the same as with wide-area bonjour. Only now, this = may cause the proxies to issue their own multicast queries on a local = network in order to ensure their cache is current. The original client's = searches are never broadcast further than they were before. A bad actor = would have to intercept the unicast queries from the client (which may = be TLS encoded). To do this, the bad actor must have compromised some = network device to do this. Tom --Apple-Mail=_D4D997EE-6010-4915-BCE1-1AA73904AE4F 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 iQEcBAEBAgAGBQJVCI2nAAoJEPk0GMVmUuYMgowIAK7tRSFIQs9cnvEfpROEjHEZ oGDb9YmfkDeQBTbe+DcfAmemso/yIigJmSgE+ZqOXQFNifrHwrIFSA6/0nzCCQ4s ybo4IUGMSpyTkIMDb7BGw0jCDgz/Bnb0FWptfdFms97Xe/CJ+SAC0ASvOppcJM6F dze58ZEBVWPuszpjXdwUZX8991bCKUMvHGTMlt0oiodscGpRuDRg8fszYwo+cYVR 2sJ4Jt7F77DJ+svD+N0L9R7TS4ObfLJkplgca5cXYjjRHkd/gZwPZNn7ONCl/6wE QNJjtFUL/k8Omw+lBQSGkcdhpgFhrck9/jrDrcN6rV8T0/+yEYCXGGR5zlrGcvw= =cGxG -----END PGP SIGNATURE----- --Apple-Mail=_D4D997EE-6010-4915-BCE1-1AA73904AE4F-- From nobody Tue Mar 17 13:28:36 2015 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 80C1F1A8893; Tue, 17 Mar 2015 13:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 anUFpthwjzlw; Tue, 17 Mar 2015 13:28:33 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B101A1B6B; Tue, 17 Mar 2015 13:28:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 09911BE35; Tue, 17 Mar 2015 20:28:32 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5hTY6o6kGmg; Tue, 17 Mar 2015 20:28:30 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.20.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C2DE7BDD8; Tue, 17 Mar 2015 20:28:30 +0000 (GMT) Message-ID: <55088E6E.6010904@cs.tcd.ie> Date: Tue, 17 Mar 2015 20:28:30 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tom Pusateri References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> <5508876F.9030904@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , Ralph Droms , The IESG Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 20:28:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hiya, On 17/03/15 20:25, Tom Pusateri wrote: > I'm not sure I understand your scenario. > > Clients issue searches in the form of unicast DNS queries to DNS > servers (or proxies). This is the same as with wide-area bonjour. > Only now, this may cause the proxies to issue their own multicast > queries on a local network in order to ensure their cache is > current. The original client's searches are never broadcast further > than they were before. A bad actor would have to intercept the > unicast queries from the client (which may be TLS encoded). To do > this, the bad actor must have compromised some network device to do > this. So I don't think the above is clear from the requirements draft, which is all I've so far read. It may be clear later that there's no significant new threat in this respect due to a specific design having been adopted, and if so that's good. S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVCI5uAAoJEC88hzaAX42if+kH/162SKw51bx/T1hp25ey5aQ2 pJm9GRCnVjEuvF4UqOmaybeG6GE/CfI+r3cpH8xpxBbBT64HTw89/Ww1hzYX9suu nEDaOjocCADuPIOYItG0m+LoPWpx4NOVwiu7/MC/8wXBH25SbhNjGm/PwCmTVhrA uI6vQLoQryS+M1IxZIqAYoRM9TEFjrMnOWm6XwsrYzzheRiKFTUO/u33c9W1Ic+B tljQTWQ4sDhVPLHnJ1d4NH1to2RN8WSt1tedgtwfRK9ZCC6YuRTf/Qo33AW5wDJW tWV74yeIMANRR4Lp48KXuUV/AaiQTw5/CNDt1Ug9hNQ3dLJqA25A5zI5oq3nZ+s= =CK7A -----END PGP SIGNATURE----- From nobody Tue Mar 17 13:28:40 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 9DA4E1A88E7; Tue, 17 Mar 2015 13:28:34 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80C1F1A8893; Tue, 17 Mar 2015 13:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 anUFpthwjzlw; Tue, 17 Mar 2015 13:28:33 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B101A1B6B; Tue, 17 Mar 2015 13:28:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 09911BE35; Tue, 17 Mar 2015 20:28:32 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v5hTY6o6kGmg; Tue, 17 Mar 2015 20:28:30 +0000 (GMT) Received: from [10.87.48.73] (unknown [86.46.20.71]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C2DE7BDD8; Tue, 17 Mar 2015 20:28:30 +0000 (GMT) Message-ID: <55088E6E.6010904@cs.tcd.ie> Date: Tue, 17 Mar 2015 20:28:30 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Tom Pusateri References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> <5508876F.9030904@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , Ralph Droms , The IESG Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 20:28:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hiya, On 17/03/15 20:25, Tom Pusateri wrote: > I'm not sure I understand your scenario. > > Clients issue searches in the form of unicast DNS queries to DNS > servers (or proxies). This is the same as with wide-area bonjour. > Only now, this may cause the proxies to issue their own multicast > queries on a local network in order to ensure their cache is > current. The original client's searches are never broadcast further > than they were before. A bad actor would have to intercept the > unicast queries from the client (which may be TLS encoded). To do > this, the bad actor must have compromised some network device to do > this. So I don't think the above is clear from the requirements draft, which is all I've so far read. It may be clear later that there's no significant new threat in this respect due to a specific design having been adopted, and if so that's good. S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVCI5uAAoJEC88hzaAX42if+kH/162SKw51bx/T1hp25ey5aQ2 pJm9GRCnVjEuvF4UqOmaybeG6GE/CfI+r3cpH8xpxBbBT64HTw89/Ww1hzYX9suu nEDaOjocCADuPIOYItG0m+LoPWpx4NOVwiu7/MC/8wXBH25SbhNjGm/PwCmTVhrA uI6vQLoQryS+M1IxZIqAYoRM9TEFjrMnOWm6XwsrYzzheRiKFTUO/u33c9W1Ic+B tljQTWQ4sDhVPLHnJ1d4NH1to2RN8WSt1tedgtwfRK9ZCC6YuRTf/Qo33AW5wDJW tWV74yeIMANRR4Lp48KXuUV/AaiQTw5/CNDt1Ug9hNQ3dLJqA25A5zI5oq3nZ+s= =CK7A -----END PGP SIGNATURE----- From nobody Tue Mar 17 16:04:01 2015 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 BB10B1A1BA9; Tue, 17 Mar 2015 16:03:58 -0700 (PDT) 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 9fXiCJBd-qvI; Tue, 17 Mar 2015 16:03:56 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52941A1B39; Tue, 17 Mar 2015 16:03:55 -0700 (PDT) Received: by qcto4 with SMTP id o4so23802933qct.3; Tue, 17 Mar 2015 16:03:55 -0700 (PDT) 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=mTrFDIoOHnUXODmdPch4WcgruQqyIZQ0JhP+WzUk9M4=; b=NLV++GnoXocrGT6Kry2PgdPuwTTAhWfdt8fLnARFGakLQD1EU2JC80adLmPAJY80eJ I6YYbijJk9oE9Gn9pXTCOfFnn7pX11wysvtrme8kLKRuYgGvVVTQ0ycxt3LrN88uTm0Y 8T45sTJ86c/Qp2Hqvnz5fw2l5H4KUXpFyRQtRGKnE38+r5MsrRTlfHdTYorNzkhnjttc fOpxkrJFblr4P4SCjxpaIt+b0/3I12mSX1iaHmYSAQsViaMX5ssyUW7zG6SU4XwS7U+s T1lj/SFtqlErWsV3ZiF1598ZAXckJGCDHKCV1Pxs3Qpq/k5CqIEi+GR3DcPGAzuQh5aB lHQw== X-Received: by 10.55.31.101 with SMTP id f98mr95782555qkf.34.1426633435056; Tue, 17 Mar 2015 16:03:55 -0700 (PDT) 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 i16sm10627166qkh.5.2015.03.17.16.03.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 16:03:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Douglas Otis In-Reply-To: Date: Tue, 17 Mar 2015 16:03:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0263AD97-E4A9-4DB6-8A44-015652F68413@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> <80E11ACB-1AE9-479E-A36A-1610C0EF307A@gmail.com> <695E3CFA-B385-481E-9333-68BE1862B29F@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Kerry Lynn , dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , The IESG , Tom Pusateri , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 23:03:58 -0000 Dear Ralph, > On Mar 17, 2015, at 1:11 PM, Ralph Droms = wrote: >=20 >> On Mar 17, 2015, at 3:32 PM 3/17/15, Douglas Otis = wrote: >>=20 >> Dear Ralph, >>=20 >>> On Mar 17, 2015, at 10:58 AM, Ralph Droms = wrote: >>>=20 >>> Doug - Here is my summary of what I understand to be your concerns = with >>> draft-ietf-dnssd-requirements-05: >>>=20 >>> 1) A change from link-scope mDNS SD to a larger scope may result in = the >>> existence and address of a device being made more widely available = than >>> currently expected. >>=20 >> Of course. >>=20 >>> 2) Some devices and networks are incapable of defending themselves >>> against unwanted access or other attacks once the address of the = device >>> to be attacked is known. >>=20 >> When the _wrong_ address is published within DNS that then permits = direct >> Internet access, this may evade desired protections. Although many = mDNS >> devices report all such options, such reporting is only seen on the = local=20 >> network. >=20 > I need to parse your response carefully so that we can understand each = other. > In what sense is an address that permits direct address a "_wrong_" = address? > Is this sentence equivalent: "When an address (such as a globally = routable > address) is published within DNS that then permits direct Internet = access, > [...]" Many SOHO routers are unable to selectively block IPv6 session = initiation from=20 the Internet causing an all-or-none situation. Necessary exceptions = become=20 practical when RFC1918 or RFC4193 addressing conventions are used in = conjunction=20 with various protocols or when they are exceptionally permitted between = routers. For example, a user with an Apple Airport Extreme router has the choice = of=20 allowing ALL inbound IPv6 connections, or allowing NO inbound IPv6 = connections. =20 There are no other options. Similar conventions are present on = virtually all=20 low end routers - they simply don=E2=80=99t have the memory, CPU, or = configuration=20 capacity to allow for IPv6 access lists. Further, with the ability for=20= devices to change IPv6 addresses using the privacy extensions RFC4941,=20= filtering at the router becomes impractical. Publishing the IPv6 = globally=20 reachable address in DNS invites trouble, particularly for devices = unsuitable for direct internet connection (such as printers, cameras, scanners, and = other gear). > To make sure I understand the second sentence, is this sentence = equivalent: > "Although many mDNS implementations advertise all of the addresses = available > for a device, those advertisements are restricted to the local link = and, > therefore, don't advertise globally routable addresses to the = Internet." mDNS traffic is not visible beyond the local network. However, when = globally=20 routed addresses are published in DNS, exposure of this addressing might = permit malefactors access due to practical firewall limitations. Exploits for = doing=20 so are many. >>> 3) Use of RFC 4193 is a way to protect against attacks enabled by = the >>> increased scope of discovery envisioned by extended DNS-SD. >>=20 >> Use of RFC4193 is used to protect Homenet as well as various = enterprise >> environments. It is also used by Apple in their Back-To-My-Mac = scheme. >=20 > To be clear, you agree with my point 3 and you cite two examples of = the > use of RFC 4193. My understanding is that Homenet does not mandate = the > use of RFC 4193, perhaps because of the difficulties in mandating such > usage; from section 2.4 of RFC 7368: "Devices in a homenet may be = given > only a ULA as a means to restrict reachability from outside the = homenet." =20 > My understanding is that RFC 4913 addresses are used in Back-To-My-Mac > as an identifier if no other IPv6 address is available, rather than to > restrict reachability. Back-To-My-Mac uses an array of other security > mechanisms to protect devices using the technology. This overview is not correct. ULA is NOT optional with this scheme. = See: https://tools.ietf.org/html/rfc6281 This scheme generates an IPv6 ULA for each host as its identifier. This = allows=20 reuse of existing IPv6 support where end-to-end data security then = depends on IPsec to protect communications and Kerberos for end-to-end = authentication. Similar secure schemes, such as VLANs or VPNs, could also make use of = these=20 conventions. >>> You expressed these concerns during WG development and review of >>> draft-ietf-dnssd-requirements. Tim and I judged the consensus of = the >>> WG to be in support of advancing the document to the IESG, based in = part >>> on the following analysis: >>>=20 >>> Points 1 and 2 are answered by the third paragraph of section 6.1. = For >>> completeness, the last sentence of that paragraph might be extended = to >>> include "and protection against other forms of attack". >>=20 >> Address selection preferences represent critical security aspects = that=20 >> MUST BE supported by the protocol. >=20 > Do you mean selection of which among several available addresses are > advertised through DNS-SD? Yes, when deciding which addresses are published. >> If RFC1918 or RFC4193 addresses are=20 >> reported via mDNS to the DNS-SD proxy, there MUST be a requirement = for=20 >> these addresses to be used over any Internet routable address. >=20 > Used where or by what devices? Where are these restrictions enforced? This REQUIRES mDNS to DNS proxy components to enforce these selections.=20= >> It is=20 >> important these requirements make it clear mDNS is not suitable for=20= >> publishing hosts on the Internet. Where safer alternatives exist, = such=20 >> publication MUST REQUIRE administrative intervention. Otherwise=20 >> organizations making use of such schemes will be placed at great = risk. >=20 > In my opinion, there is not consensus in the WG to support your = concern. Really? mDNS offers a secure basis for publishing RRset data in DNS? It seems = even the requirements document warns against such use. > The current text in the document represents WG consensus for the > description of the potential problem. The current text incorrectly assumes mDNS can safely be used to=20 automatically publish addresses in DNS. This is both wrong and unsafe. >=20 >>> Point 3 tries to mandate a solution through a specific deployment >>> mechanism and is, therefore, out of scope for a requirements = document. >>> It may also be more broadly out of scope of the dnssd charter, which >>> addresses just DNS-based service discovery and does not include = mandating >>> network deployment requirements as part of a solution. >>=20 >> This point offers an example strategy (address preferences) that MUST = be=20 >> supported. Ensuring support is not the same as making this a = mandate! =20 >> It seems clear this group failed to develop schemes to protect = devices=20 >> that normally limit access to that of the local network, as provided = by=20 >> constraints imposed by mDNS. As such, there should have been greater=20= >> review of those offered by Homenet or even Back-To-My-Mac. >=20 > "example strategy [...] that MUST be supported" sounds like a mandate = to me. An ability to prefer one category of addressing over another is not a = mandate for any specific use. It simply ensures support exists for secure = methods for=20 handling otherwise poorly vetted mDNS information. These provisions can = prevent rampant abuse of a scheme based on unqualified UDP multicast = announcements. > This is a requirements document, not a final design, and therefore = this > document does not need to develop a solution to the problem you are > concerned with. It is also important reasonable _minimum_ requirements are established = before too much time and money is been spent heading in unsafe directions. >>> If you do not agree that your concerns have been answered by this >>> analysis, please state the basis for your continued concern, so that = we >>> can judge rough consensus on support for publication of the = document. >>=20 >> The requirements document remains critically flawed without = justification.=20 >> Ensuring an ability to offer safe deployment unfortunately does not = prevent=20 >> less safe schemes. Nevertheless, supporting a safe scheme should be a = basic=20 >> requirement.=20 >=20 > Can you give a specific requirement or requirements that could be = added to > the document to satisfy your concerns? 1) Devices publishing addresses related to mDNS/DNS-SD should support = configurations=20 that prefer use of ULA addressing. Per RFC7084, the role of the router = is to prevent=20 these addresses from going beyond or to have originated from the WAN = interface. =20 Similarly, when an ULA address is not present, similar configurations = should support similar preferences for RFC1918 addressing. 2) The collection of DNS related information should also ensure header = compliance requirements as specified by RA Guard RFC7113. This provision is to = better ensure administrative control of host naming conventions in lieu of IDNA naming = restrictions. Regards, Douglas Otis From nobody Tue Mar 17 16:04:05 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id EF7791A1B39; Tue, 17 Mar 2015 16:03:58 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB10B1A1BA9; Tue, 17 Mar 2015 16:03:58 -0700 (PDT) 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 9fXiCJBd-qvI; Tue, 17 Mar 2015 16:03:56 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B52941A1B39; Tue, 17 Mar 2015 16:03:55 -0700 (PDT) Received: by qcto4 with SMTP id o4so23802933qct.3; Tue, 17 Mar 2015 16:03:55 -0700 (PDT) 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=mTrFDIoOHnUXODmdPch4WcgruQqyIZQ0JhP+WzUk9M4=; b=NLV++GnoXocrGT6Kry2PgdPuwTTAhWfdt8fLnARFGakLQD1EU2JC80adLmPAJY80eJ I6YYbijJk9oE9Gn9pXTCOfFnn7pX11wysvtrme8kLKRuYgGvVVTQ0ycxt3LrN88uTm0Y 8T45sTJ86c/Qp2Hqvnz5fw2l5H4KUXpFyRQtRGKnE38+r5MsrRTlfHdTYorNzkhnjttc fOpxkrJFblr4P4SCjxpaIt+b0/3I12mSX1iaHmYSAQsViaMX5ssyUW7zG6SU4XwS7U+s T1lj/SFtqlErWsV3ZiF1598ZAXckJGCDHKCV1Pxs3Qpq/k5CqIEi+GR3DcPGAzuQh5aB lHQw== X-Received: by 10.55.31.101 with SMTP id f98mr95782555qkf.34.1426633435056; Tue, 17 Mar 2015 16:03:55 -0700 (PDT) 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 i16sm10627166qkh.5.2015.03.17.16.03.53 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 17 Mar 2015 16:03:54 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Douglas Otis In-Reply-To: Date: Tue, 17 Mar 2015 16:03:52 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0263AD97-E4A9-4DB6-8A44-015652F68413@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <83452A4F-D738-43D5-85FD-316B0DC8509F@gmail.com> <9FC464C2-79E9-477D-9AFA-4C247F071677@gmail.com> <80E11ACB-1AE9-479E-A36A-1610C0EF307A@gmail.com> <695E3CFA-B385-481E-9333-68BE1862B29F@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: Kerry Lynn , dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , The IESG , Tom Pusateri , Stephen Farrell Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 17 Mar 2015 23:03:59 -0000 Dear Ralph, > On Mar 17, 2015, at 1:11 PM, Ralph Droms = wrote: >=20 >> On Mar 17, 2015, at 3:32 PM 3/17/15, Douglas Otis = wrote: >>=20 >> Dear Ralph, >>=20 >>> On Mar 17, 2015, at 10:58 AM, Ralph Droms = wrote: >>>=20 >>> Doug - Here is my summary of what I understand to be your concerns = with >>> draft-ietf-dnssd-requirements-05: >>>=20 >>> 1) A change from link-scope mDNS SD to a larger scope may result in = the >>> existence and address of a device being made more widely available = than >>> currently expected. >>=20 >> Of course. >>=20 >>> 2) Some devices and networks are incapable of defending themselves >>> against unwanted access or other attacks once the address of the = device >>> to be attacked is known. >>=20 >> When the _wrong_ address is published within DNS that then permits = direct >> Internet access, this may evade desired protections. Although many = mDNS >> devices report all such options, such reporting is only seen on the = local=20 >> network. >=20 > I need to parse your response carefully so that we can understand each = other. > In what sense is an address that permits direct address a "_wrong_" = address? > Is this sentence equivalent: "When an address (such as a globally = routable > address) is published within DNS that then permits direct Internet = access, > [...]" Many SOHO routers are unable to selectively block IPv6 session = initiation from=20 the Internet causing an all-or-none situation. Necessary exceptions = become=20 practical when RFC1918 or RFC4193 addressing conventions are used in = conjunction=20 with various protocols or when they are exceptionally permitted between = routers. For example, a user with an Apple Airport Extreme router has the choice = of=20 allowing ALL inbound IPv6 connections, or allowing NO inbound IPv6 = connections. =20 There are no other options. Similar conventions are present on = virtually all=20 low end routers - they simply don=E2=80=99t have the memory, CPU, or = configuration=20 capacity to allow for IPv6 access lists. Further, with the ability for=20= devices to change IPv6 addresses using the privacy extensions RFC4941,=20= filtering at the router becomes impractical. Publishing the IPv6 = globally=20 reachable address in DNS invites trouble, particularly for devices = unsuitable for direct internet connection (such as printers, cameras, scanners, and = other gear). > To make sure I understand the second sentence, is this sentence = equivalent: > "Although many mDNS implementations advertise all of the addresses = available > for a device, those advertisements are restricted to the local link = and, > therefore, don't advertise globally routable addresses to the = Internet." mDNS traffic is not visible beyond the local network. However, when = globally=20 routed addresses are published in DNS, exposure of this addressing might = permit malefactors access due to practical firewall limitations. Exploits for = doing=20 so are many. >>> 3) Use of RFC 4193 is a way to protect against attacks enabled by = the >>> increased scope of discovery envisioned by extended DNS-SD. >>=20 >> Use of RFC4193 is used to protect Homenet as well as various = enterprise >> environments. It is also used by Apple in their Back-To-My-Mac = scheme. >=20 > To be clear, you agree with my point 3 and you cite two examples of = the > use of RFC 4193. My understanding is that Homenet does not mandate = the > use of RFC 4193, perhaps because of the difficulties in mandating such > usage; from section 2.4 of RFC 7368: "Devices in a homenet may be = given > only a ULA as a means to restrict reachability from outside the = homenet." =20 > My understanding is that RFC 4913 addresses are used in Back-To-My-Mac > as an identifier if no other IPv6 address is available, rather than to > restrict reachability. Back-To-My-Mac uses an array of other security > mechanisms to protect devices using the technology. This overview is not correct. ULA is NOT optional with this scheme. = See: https://tools.ietf.org/html/rfc6281 This scheme generates an IPv6 ULA for each host as its identifier. This = allows=20 reuse of existing IPv6 support where end-to-end data security then = depends on IPsec to protect communications and Kerberos for end-to-end = authentication. Similar secure schemes, such as VLANs or VPNs, could also make use of = these=20 conventions. >>> You expressed these concerns during WG development and review of >>> draft-ietf-dnssd-requirements. Tim and I judged the consensus of = the >>> WG to be in support of advancing the document to the IESG, based in = part >>> on the following analysis: >>>=20 >>> Points 1 and 2 are answered by the third paragraph of section 6.1. = For >>> completeness, the last sentence of that paragraph might be extended = to >>> include "and protection against other forms of attack". >>=20 >> Address selection preferences represent critical security aspects = that=20 >> MUST BE supported by the protocol. >=20 > Do you mean selection of which among several available addresses are > advertised through DNS-SD? Yes, when deciding which addresses are published. >> If RFC1918 or RFC4193 addresses are=20 >> reported via mDNS to the DNS-SD proxy, there MUST be a requirement = for=20 >> these addresses to be used over any Internet routable address. >=20 > Used where or by what devices? Where are these restrictions enforced? This REQUIRES mDNS to DNS proxy components to enforce these selections.=20= >> It is=20 >> important these requirements make it clear mDNS is not suitable for=20= >> publishing hosts on the Internet. Where safer alternatives exist, = such=20 >> publication MUST REQUIRE administrative intervention. Otherwise=20 >> organizations making use of such schemes will be placed at great = risk. >=20 > In my opinion, there is not consensus in the WG to support your = concern. Really? mDNS offers a secure basis for publishing RRset data in DNS? It seems = even the requirements document warns against such use. > The current text in the document represents WG consensus for the > description of the potential problem. The current text incorrectly assumes mDNS can safely be used to=20 automatically publish addresses in DNS. This is both wrong and unsafe. >=20 >>> Point 3 tries to mandate a solution through a specific deployment >>> mechanism and is, therefore, out of scope for a requirements = document. >>> It may also be more broadly out of scope of the dnssd charter, which >>> addresses just DNS-based service discovery and does not include = mandating >>> network deployment requirements as part of a solution. >>=20 >> This point offers an example strategy (address preferences) that MUST = be=20 >> supported. Ensuring support is not the same as making this a = mandate! =20 >> It seems clear this group failed to develop schemes to protect = devices=20 >> that normally limit access to that of the local network, as provided = by=20 >> constraints imposed by mDNS. As such, there should have been greater=20= >> review of those offered by Homenet or even Back-To-My-Mac. >=20 > "example strategy [...] that MUST be supported" sounds like a mandate = to me. An ability to prefer one category of addressing over another is not a = mandate for any specific use. It simply ensures support exists for secure = methods for=20 handling otherwise poorly vetted mDNS information. These provisions can = prevent rampant abuse of a scheme based on unqualified UDP multicast = announcements. > This is a requirements document, not a final design, and therefore = this > document does not need to develop a solution to the problem you are > concerned with. It is also important reasonable _minimum_ requirements are established = before too much time and money is been spent heading in unsafe directions. >>> If you do not agree that your concerns have been answered by this >>> analysis, please state the basis for your continued concern, so that = we >>> can judge rough consensus on support for publication of the = document. >>=20 >> The requirements document remains critically flawed without = justification.=20 >> Ensuring an ability to offer safe deployment unfortunately does not = prevent=20 >> less safe schemes. Nevertheless, supporting a safe scheme should be a = basic=20 >> requirement.=20 >=20 > Can you give a specific requirement or requirements that could be = added to > the document to satisfy your concerns? 1) Devices publishing addresses related to mDNS/DNS-SD should support = configurations=20 that prefer use of ULA addressing. Per RFC7084, the role of the router = is to prevent=20 these addresses from going beyond or to have originated from the WAN = interface. =20 Similarly, when an ULA address is not present, similar configurations = should support similar preferences for RFC1918 addressing. 2) The collection of DNS related information should also ensure header = compliance requirements as specified by RA Guard RFC7113. This provision is to = better ensure administrative control of host naming conventions in lieu of IDNA naming = restrictions. Regards, Douglas Otis From nobody Wed Mar 18 11:38:43 2015 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 AA9031A900A; Wed, 18 Mar 2015 11:38:41 -0700 (PDT) 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 od-UlXOA6qFT; Wed, 18 Mar 2015 11:38:40 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39ECF1A87EA; Wed, 18 Mar 2015 11:38:40 -0700 (PDT) Received: by pabyw6 with SMTP id yw6so50173456pab.2; Wed, 18 Mar 2015 11:38:39 -0700 (PDT) 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=s2RxNGuOgmV8spkjXDN4QPCNY7dlzMOtr61kGqqWtx4=; b=ToKmeqg9/qTXB/S3qulWjrpaWAN9yJub8ryuQ+TndlfaFJqfvmvbCTlih4WxHl2TcN P3P26dRzDyKskmEGVCruT0dy66n4xcB4K5UYoLrWcI2O6vwEVLVYhDoIaje7zcmRLxFM CV87cVckeYlyFaXMTyIaYqSq5GiCrjhrRlOsZ7kcXVONFEA9x4vv8RhX7jjX/nvhvYOK 8o51ucm4q9c4osowRFBQGt4v4HoiJ2QxTjvCuRz1trGfc3gE5h6KQdfsEDzv8U65Uv8J JT2fdH2oiNNMmZ+CabF8FwcM97fBykHvXZrEBjo9iy0boaxMFvyFLRzxFj4G85h360wZ KSvQ== X-Received: by 10.70.133.97 with SMTP id pb1mr98592825pdb.10.1426703919879; Wed, 18 Mar 2015 11:38:39 -0700 (PDT) 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 x1sm28736775pdr.17.2015.03.18.11.38.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 11:38:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Douglas Otis In-Reply-To: <55088E6E.6010904@cs.tcd.ie> Date: Wed, 18 Mar 2015 11:38:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <89D3FE5D-D6B2-4F5F-8CEE-6B7FD0BC0749@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> <5508876F.9030904@cs.tcd.ie> <55088E6E.6010904@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , Ralph Droms , Tom Pusateri , The IESG Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 18 Mar 2015 18:38:41 -0000 > On Mar 17, 2015, at 1:28 PM, Stephen Farrell = wrote: >=20 > Signed PGP part >=20 > Hiya, >=20 > On 17/03/15 20:25, Tom Pusateri wrote: > > I'm not sure I understand your scenario. > > > > Clients issue searches in the form of unicast DNS queries to DNS > > servers (or proxies). This is the same as with wide-area bonjour. > > Only now, this may cause the proxies to issue their own multicast > > queries on a local network in order to ensure their cache is > > current. The original client's searches are never broadcast further > > than they were before. A bad actor would have to intercept the > > unicast queries from the client (which may be TLS encoded). To do > > this, the bad actor must have compromised some network device to do > > this. >=20 > So I don't think the above is clear from the requirements draft, > which is all I've so far read. It may be clear later that there's > no significant new threat in this respect due to a specific design > having been adopted, and if so that's good. >=20 > S. Dear Stephen, I have seen no consumer-level routers which offer IPv6 filtering, except=20= in an =E2=80=9Call-or-nothing=E2=80=9D fashion, which makes sense given = the practical=20 limitations of memory and configuration. Even high-end routers have no=20= ability to track privacy extension IPv6 addresses, so no practical=20 filtering methods currently exist. That=E2=80=99s why it is so = important to=20 indicate in the draft that no routable address should be published in=20 DNS without the active participation of the administrator. Without this=20= step, mDNS will publish routable addresses to devices which are not safe=20= on the Internet, and can never be made safe. It seems Tom described new infrastructure attempting to leverage mDNS as = a=20 method to update host resources in DNS. There are many avenues = permitting=20 remote clients a means to query DNS information, where DNS-SD will not secure this sensitive information. When DNS contains IPv6 globally=20 accessible addresses not practically blocked, distributing these = addresses=20 will expose devices that could be in a class of being permanently = vulnerable=20 to Internet access i.e. printers, baby monitors, infrastructure = controls, etc. Regards, Douglas Otis From nobody Wed Mar 18 11:38:52 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id CBC381A904D; Wed, 18 Mar 2015 11:38:41 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9031A900A; Wed, 18 Mar 2015 11:38:41 -0700 (PDT) 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 od-UlXOA6qFT; Wed, 18 Mar 2015 11:38:40 -0700 (PDT) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39ECF1A87EA; Wed, 18 Mar 2015 11:38:40 -0700 (PDT) Received: by pabyw6 with SMTP id yw6so50173456pab.2; Wed, 18 Mar 2015 11:38:39 -0700 (PDT) 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=s2RxNGuOgmV8spkjXDN4QPCNY7dlzMOtr61kGqqWtx4=; b=ToKmeqg9/qTXB/S3qulWjrpaWAN9yJub8ryuQ+TndlfaFJqfvmvbCTlih4WxHl2TcN P3P26dRzDyKskmEGVCruT0dy66n4xcB4K5UYoLrWcI2O6vwEVLVYhDoIaje7zcmRLxFM CV87cVckeYlyFaXMTyIaYqSq5GiCrjhrRlOsZ7kcXVONFEA9x4vv8RhX7jjX/nvhvYOK 8o51ucm4q9c4osowRFBQGt4v4HoiJ2QxTjvCuRz1trGfc3gE5h6KQdfsEDzv8U65Uv8J JT2fdH2oiNNMmZ+CabF8FwcM97fBykHvXZrEBjo9iy0boaxMFvyFLRzxFj4G85h360wZ KSvQ== X-Received: by 10.70.133.97 with SMTP id pb1mr98592825pdb.10.1426703919879; Wed, 18 Mar 2015 11:38:39 -0700 (PDT) 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 x1sm28736775pdr.17.2015.03.18.11.38.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 11:38:39 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Douglas Otis In-Reply-To: <55088E6E.6010904@cs.tcd.ie> Date: Wed, 18 Mar 2015 11:38:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <89D3FE5D-D6B2-4F5F-8CEE-6B7FD0BC0749@gmail.com> References: <20150310230433.13239.32024.idtracker@ietfa.amsl.com> <2C1D6897-BE72-4902-97A6-C5C6943B1EF7@gmail.com> <5508876F.9030904@cs.tcd.ie> <55088E6E.6010904@cs.tcd.ie> To: Stephen Farrell X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: dnssd-chairs@ietf.org, draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, Chown Tim , Ralph Droms , Tom Pusateri , The IESG Subject: Re: [dnssd] Stephen Farrell's No Objection on draft-ietf-dnssd-requirements-05: (with COMMENT) 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, 18 Mar 2015 18:38:42 -0000 > On Mar 17, 2015, at 1:28 PM, Stephen Farrell = wrote: >=20 > Signed PGP part >=20 > Hiya, >=20 > On 17/03/15 20:25, Tom Pusateri wrote: > > I'm not sure I understand your scenario. > > > > Clients issue searches in the form of unicast DNS queries to DNS > > servers (or proxies). This is the same as with wide-area bonjour. > > Only now, this may cause the proxies to issue their own multicast > > queries on a local network in order to ensure their cache is > > current. The original client's searches are never broadcast further > > than they were before. A bad actor would have to intercept the > > unicast queries from the client (which may be TLS encoded). To do > > this, the bad actor must have compromised some network device to do > > this. >=20 > So I don't think the above is clear from the requirements draft, > which is all I've so far read. It may be clear later that there's > no significant new threat in this respect due to a specific design > having been adopted, and if so that's good. >=20 > S. Dear Stephen, I have seen no consumer-level routers which offer IPv6 filtering, except=20= in an =E2=80=9Call-or-nothing=E2=80=9D fashion, which makes sense given = the practical=20 limitations of memory and configuration. Even high-end routers have no=20= ability to track privacy extension IPv6 addresses, so no practical=20 filtering methods currently exist. That=E2=80=99s why it is so = important to=20 indicate in the draft that no routable address should be published in=20 DNS without the active participation of the administrator. Without this=20= step, mDNS will publish routable addresses to devices which are not safe=20= on the Internet, and can never be made safe. It seems Tom described new infrastructure attempting to leverage mDNS as = a=20 method to update host resources in DNS. There are many avenues = permitting=20 remote clients a means to query DNS information, where DNS-SD will not secure this sensitive information. When DNS contains IPv6 globally=20 accessible addresses not practically blocked, distributing these = addresses=20 will expose devices that could be in a class of being permanently = vulnerable=20 to Internet access i.e. printers, baby monitors, infrastructure = controls, etc. Regards, Douglas Otis From nobody Wed Mar 18 11:57:03 2015 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 2A20D1A878E for ; Wed, 18 Mar 2015 11:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 ZCMaJ2_2r3kA for ; Wed, 18 Mar 2015 11:57:01 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4A401A0064 for ; Wed, 18 Mar 2015 11:56:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1676; q=dns/txt; s=iport; t=1426705019; x=1427914619; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=wA9oNADeF2SZ6+2qAd+6fmhU6AE0Y9Y8IDXxPqpQJZ0=; b=PR5lMBCwokpLjqSd9I2GCRN6CymiR0gMuoI3GNR9vmz8lGaBzUvLI2Oo DF0jYWmmyHTAefI4IKnkUM3s3EN9NF4+VxwAwIdDUKjc6cag6agoKNbxX NMTPHUnftz8Zcp/4TqHHbsLi9d6uNP4d9fhUoOvjprf9y0MGhoSiOnck3 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AtBQBLyQlV/5RdJa1cgwaBMMk+hChMAQEBAQEBfYQWOlEBGiRCFxAEiEKiJ6sUAQEBAQEFAQEBAQEBAQEBGZMmgRYFhhSKMoltgRuMGIZzIoNugjN/AQEB X-IronPort-AV: E=Sophos;i="5.11,423,1422921600"; d="scan'208";a="133247595" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP; 18 Mar 2015 18:56:59 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t2IIuxcS029062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 18 Mar 2015 18:56:59 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.86]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Wed, 18 Mar 2015 13:56:58 -0500 From: "Ralph Droms (rdroms)" To: "dnssd@ietf.org" Thread-Topic: Updated draft agenda for dins WG meeting Thread-Index: AQHQYa1PCCPdoV+Kdk6TTuxN+0aFcw== Date: Wed, 18 Mar 2015 18:56:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.131.118.43] Content-Type: text/plain; charset="us-ascii" Content-ID: <7B1BAC83DE5640449772B56F15FB14E6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dnssd] Updated draft agenda for dins WG meeting 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, 18 Mar 2015 18:57:03 -0000 dnssd WG Agenda - IETF 92 1300-1500CDT 2015-03-23 (Last revised 2015-03-18 14:55 ET) ---------------------------------- Administrivia Droms/Chown 10 minute= s =20 Introduction and NoteWell Agenda bashing; blue sheets; scribe; Jabber scribe On Interoperation of Labels Between mDNS and DNS Sullivan 10 minute= s draft-ietf-dnssd-mdns-dns-interop-00 Update on WG document; prepare for WG last call DNS Long-Lived Queries Pusateri/Cheshire 30 minute= s draft-ietf-dnssd-push-00 New draft review; discuss adoption as WG document Auto-Configuration of Hybrid Unicast/Multicast DNS-SD Proxies Stenberg 15 minute= s draft-ietf-homenet-hybrid-proxy-zeroconf-00 Technology review of homenet WG I-D Multicast DNS (mDNS) Threat Model and Security Consideration Rafiee 20 minute= s draft-rafiee-dnssd-mdns-threatmodel-01 Review of updates Hybrid Unicast/Multicast DNS-Based Service Discovery Droms 15 minute= s draft-ietf-dnssd-hybrid-00 Review of document against requirements Reflections on extended DNS-SD architecture Droms 15 minute= s =20 ----------= - 115 minute= s From nobody Fri Mar 20 14:22:36 2015 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 DC10C1A9042; Fri, 20 Mar 2015 14:22:32 -0700 (PDT) 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 S1PGQtEtL6lM; Fri, 20 Mar 2015 14:22:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EF91A903D; Fri, 20 Mar 2015 14:22:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150320212231.2167.55855.idtracker@ietfa.amsl.com> Date: Fri, 20 Mar 2015 14:22:31 -0700 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, tjc@ecs.soton.ac.uk Subject: [dnssd] Pete Resnick's No Objection on draft-ietf-dnssd-requirements-06: (with COMMENT) 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: Fri, 20 Mar 2015 21:22:33 -0000 Pete Resnick has entered the following ballot position for draft-ietf-dnssd-requirements-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 5: SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today. SSD must not negatively impact the global DNS namespace or infrastructure. A reference to soon-to-be-RFC-draft-ietf-precis-framework would be nice here. From nobody Fri Mar 20 14:22:37 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 04E101A9044; Fri, 20 Mar 2015 14:22:32 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC10C1A9042; Fri, 20 Mar 2015 14:22:32 -0700 (PDT) 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 S1PGQtEtL6lM; Fri, 20 Mar 2015 14:22:31 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EF91A903D; Fri, 20 Mar 2015 14:22:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Pete Resnick" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150320212231.2167.55855.idtracker@ietfa.amsl.com> Date: Fri, 20 Mar 2015 14:22:31 -0700 Archived-At: Cc: draft-ietf-dnssd-requirements.all@ietf.org, dnssd@ietf.org, dnssd-chairs@ietf.org, tjc@ecs.soton.ac.uk Subject: [dnssd] Pete Resnick's No Objection on draft-ietf-dnssd-requirements-06: (with COMMENT) 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: Fri, 20 Mar 2015 21:22:33 -0000 Pete Resnick has entered the following ballot position for draft-ietf-dnssd-requirements-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 5: SSD should support rich internationalized labels within Service Instance Names, as DNS-SD/mDNS does today. SSD must not negatively impact the global DNS namespace or infrastructure. A reference to soon-to-be-RFC-draft-ietf-precis-framework would be nice here. From nobody Sat Mar 21 08:08:01 2015 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 9863A1B2B25; Sat, 21 Mar 2015 08:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 oyg53-jnturA; Sat, 21 Mar 2015 08:07:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2483F1AC3E3; Sat, 21 Mar 2015 08:07:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150321150757.15752.69004.idtracker@ietfa.amsl.com> Date: Sat, 21 Mar 2015 08:07:57 -0700 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: 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: Sat, 21 Mar 2015 15:08:00 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Sat Mar 21 08:08:03 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B921E1B2B27; Sat, 21 Mar 2015 08:08:00 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9863A1B2B25; Sat, 21 Mar 2015 08:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 oyg53-jnturA; Sat, 21 Mar 2015 08:07:59 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2483F1AC3E3; Sat, 21 Mar 2015 08:07:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150321150757.15752.69004.idtracker@ietfa.amsl.com> Date: Sat, 21 Mar 2015 08:07:57 -0700 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: 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: Sat, 21 Mar 2015 15:08:00 -0000 IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Sat Mar 21 10:43:24 2015 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 D8E871A1B9A; Sat, 21 Mar 2015 10:43:23 -0700 (PDT) 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 9Ralc8EiMCsO; Sat, 21 Mar 2015 10:43:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA321A1B2B; Sat, 21 Mar 2015 10:43:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150321174322.16644.73807.idtracker@ietfa.amsl.com> Date: Sat, 21 Mar 2015 10:43:22 -0700 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: 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: Sat, 21 Mar 2015 17:43:24 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Sat Mar 21 10:43:29 2015 Return-Path: X-Original-To: expand-draft-ietf-dnssd-requirements.all@virtual.ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2DA4C1A1BCD; Sat, 21 Mar 2015 10:43:23 -0700 (PDT) X-Original-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-dnssd-requirements.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8E871A1B9A; Sat, 21 Mar 2015 10:43:23 -0700 (PDT) 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 9Ralc8EiMCsO; Sat, 21 Mar 2015 10:43:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CA321A1B2B; Sat, 21 Mar 2015 10:43:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150321174322.16644.73807.idtracker@ietfa.amsl.com> Date: Sat, 21 Mar 2015 10:43:22 -0700 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: 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: Sat, 21 Mar 2015 17:43:24 -0000 IESG has approved the document and state has been changed to Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Sat Mar 21 10:43:31 2015 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 AF47B1A1B2D; Sat, 21 Mar 2015 10:43:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8i-Yjyk-5N9s; Sat, 21 Mar 2015 10:43:24 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BC82F1A1B47; Sat, 21 Mar 2015 10:43:22 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150321174322.16644.44927.idtracker@ietfa.amsl.com> Date: Sat, 21 Mar 2015 10:43:22 -0700 Archived-At: Cc: dnssd mailing list , dnssd chair , RFC Editor Subject: [dnssd] Document Action: 'Requirements for Scalable DNS-SD/mDNS Extensions' to Informational RFC (draft-ietf-dnssd-requirements-06.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: Sat, 21 Mar 2015 17:43:25 -0000 The IESG has approved the following document: - 'Requirements for Scalable DNS-SD/mDNS Extensions' (draft-ietf-dnssd-requirements-06.txt) as Informational RFC This document is the product of the Extensions for Scalable DNS Service Discovery Working Group. The IESG contact persons are Brian Haberman and Ted Lemon. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ Technical Summary: DNS-SD/mDNS is widely used today for discovery and resolution of services and names on a local link, but there are use cases to extend DNS-SD/mDNS to enable service discovery beyond the local link. This document provides a problem statement and documents a set of requirements against which solutions can be designed and measured. Working Group Summary: The WG generally reached strong consensus on all points, including all requirements, in the document. There was some specific discussion about whether wireless links should be treated differently, but it was agreed that REQ9 should be generalised and say "SSD should operate efficiently on common link layers and link types." The evolution of the other requirements was quite smooth with good consensus. Document Quality: As a requirements document, a number of implementors/vendors have expressed an interest in working towards a common, interoperable solution for service discovery across multiple links. No specialist review was required. A separate threat analysis is being documented through draft-rafiee-dnssd-mdns-threatmodel-01. Personnel: Document shepherd: Tim Chown Responsible AD: Ted Lemon From nobody Sun Mar 22 23:06:15 2015 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 7453A1A88A3; Sun, 22 Mar 2015 23:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 dmGO5KOATeOK; Sun, 22 Mar 2015 23:06:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F391A888C; Sun, 22 Mar 2015 23:06:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150323060608.13923.59162.idtracker@ietfa.amsl.com> Date: Sun, 22 Mar 2015 23:06:08 -0700 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: 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: Mon, 23 Mar 2015 06:06:10 -0000 IANA action state changed to No IC ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/ From nobody Mon Mar 23 07:57:00 2015 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 E35FA1A8AA6 for ; Mon, 23 Mar 2015 07:56:58 -0700 (PDT) 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 aDdNyiAgCu7s for ; Mon, 23 Mar 2015 07:56:57 -0700 (PDT) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D941A8BAF for ; Mon, 23 Mar 2015 07:56:57 -0700 (PDT) Received: by pagv19 with SMTP id v19so18912616pag.2 for ; Mon, 23 Mar 2015 07:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=B3bPWuJcpNZYaqOZob1joR4v3g9nLBljv9KgaRD+G3I=; b=vP5OY1PTtBoox3APweb2XG1/rSso/7o8eoqNbfQj3pdc/00wUSwcaN24AtD7HIgn9U 8gbcCOJrDV+l0VBmDZX9JBbWS5AYXrBN7QNko4sjgV0j2kmCPd0RCgJXKK2Kn6qpuwMD 4MqTe2wD6oXD2tEmpEvl0gQz393991uaQeBuqMY/awn7wdsoDVGYF7acOmUmnbCmAACi MEPe56k4hwboqRf7+3hoVQ0msoiceV71neeAKMBzoAGrA7s2yZsc+qy+BcWyGsMRuQu+ mnbGceGexn+hbhneJDS9+kkG+oPdgUkTobB3OLEL2y1zZW6uizKlPtA9er2MVpPyuv35 j4hw== X-Received: by 10.67.7.195 with SMTP id de3mr106943342pad.79.1427122616044; Mon, 23 Mar 2015 07:56:56 -0700 (PDT) Received: from ?IPv6:2001:420:c0c4:1002::397? ([2001:420:c0c4:1002::397]) by mx.google.com with ESMTPSA id jr15sm1274035pbb.55.2015.03.23.07.56.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Mar 2015 07:56:55 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 23 Mar 2015 09:48:59 -0500 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [dnssd] Pre-meeting administrivia 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, 23 Mar 2015 14:56:59 -0000 The final agenda (modulo in-meeting agenda bashing) and most meeting = materials are available. It would be helpful to review = draft-ietf-dnssd-hybrid against the requirements prior to the meeting. We need volunteers for taking minutes and jabber scribe. Tim will be co-chairing remotely. It might be helpful for me to have an = in-person minion to help with logistics in the meeting, if someone has = an urge to sit at the front table with me. - Ralph From nobody Mon Mar 23 07:57:32 2015 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 2B75B1A8A6E for ; Mon, 23 Mar 2015 07:57:30 -0700 (PDT) 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 4UeFv8n5C1Ah for ; Mon, 23 Mar 2015 07:57:29 -0700 (PDT) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B021A87B9 for ; Mon, 23 Mar 2015 07:57:29 -0700 (PDT) Received: by pabxg6 with SMTP id xg6so181262625pab.0 for ; Mon, 23 Mar 2015 07:57:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=B3bPWuJcpNZYaqOZob1joR4v3g9nLBljv9KgaRD+G3I=; b=x4aw8c/XwJdiMx/6g2vVulcGzf/S+GBJb0mzeKksIjGaaA464Y+8HjMUfFxUVNS3XA KIS/7Bq7Vxd3VbPH3MWf1ZY9DJjwMfSTX2Md6EoQR6xj8sp2neWIqZ4/qla1JGaqDBCe JZ/DQuwik+yrKchePKmxf95FWUto0F5pltSs919Za22tOqtQFH/AdGS9Y+WLG7mqvJ7X fmfNNSWNnCIOfThJFIVEyuf7T+ntiMWfgQ5/ILFv26B1Opy2CHffpGnngMfZ0zPGAFgK kxc1z6iui3bio1HZm58QtjT/0ocJ8Ds/c6XyVGkUWKBHLSD2CCFsIH0stv3CAbYb/fA7 o/lw== X-Received: by 10.68.194.137 with SMTP id hw9mr21997405pbc.162.1427122648888; Mon, 23 Mar 2015 07:57:28 -0700 (PDT) Received: from ?IPv6:2001:420:c0c4:1002::397? ([2001:420:c0c4:1002::397]) by mx.google.com with ESMTPSA id jr15sm1274035pbb.55.2015.03.23.07.57.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 23 Mar 2015 07:57:28 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <773F5ABD-47BD-4FB6-A298-61D25AAEF1F8@gmail.com> Date: Mon, 23 Mar 2015 09:57:28 -0500 To: dnssd@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) X-Mailer: Apple Mail (2.2070.6) Archived-At: Subject: [dnssd] Pre-meeting administrivia 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, 23 Mar 2015 14:57:30 -0000 The final agenda (modulo in-meeting agenda bashing) and most meeting = materials are available. It would be helpful to review = draft-ietf-dnssd-hybrid against the requirements prior to the meeting. We need volunteers for taking minutes and jabber scribe. Tim will be co-chairing remotely. It might be helpful for me to have an = in-person minion to help with logistics in the meeting, if someone has = an urge to sit at the front table with me. - Ralph From nobody Tue Mar 24 08:28:36 2015 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 B730E1A8908; Tue, 24 Mar 2015 08:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=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 xAhqS4SZaASN; Tue, 24 Mar 2015 08:28:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9AB1A893A; Tue, 24 Mar 2015 08:28:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150324152804.26913.94867.idtracker@ietfa.amsl.com> Date: Tue, 24 Mar 2015 08:28:04 -0700 From: IETF Secretariat Archived-At: Subject: [dnssd] ID Tracker State Update Notice: 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: Tue, 24 Mar 2015 15:28:34 -0000 IESG state changed to RFC Ed Queue from Approved-announcement sent ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-dnssd-requirements/