From nobody Sun Jul 3 09:51:35 2016 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 532CE12D145; Sun, 3 Jul 2016 09:51:33 -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: 6.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160703165133.9328.22022.idtracker@ietfa.amsl.com> Date: Sun, 03 Jul 2016 09:51:33 -0700 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-03.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 16:51:33 -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 of the IETF. Title : On Interoperation of Labels Among Conventional DNS and Other Resolution Systems Author : Andrew Sullivan Filename : draft-ietf-dnssd-mdns-dns-interop-03.txt Pages : 12 Date : 2016-07-03 Abstract: Despite its name, DNS-Based Service Discovery can use naming systems other than the Domain Name System when looking for services. Moreover, when it uses the DNS, DNS-Based Service Discovery uses the full capability of DNS, rather than using a subset of available octets. In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for selection of labels for conventional DNS and other resolution systems 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: https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-mdns-dns-interop-03 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 Sun Jul 3 09:52:12 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C6E12D145 for ; Sun, 3 Jul 2016 09:52:11 -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 autolearn_force=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 thHplQJjVmte for ; Sun, 3 Jul 2016 09:52:09 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id A85DC12D115 for ; Sun, 3 Jul 2016 09:52:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 8EC1B10CD5 for ; Sun, 3 Jul 2016 16:52:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvutQeqcEMES for ; Sun, 3 Jul 2016 16:52:07 +0000 (UTC) Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 9CAF110CC3 for ; Sun, 3 Jul 2016 16:52:07 +0000 (UTC) Date: Sun, 3 Jul 2016 12:52:06 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20160703165206.GF31455@mx2.yitter.info> References: <20160703165133.9328.22022.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160703165133.9328.22022.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-mdns-dns-interop-03.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jul 2016 16:52:12 -0000 This is an attempt to address Dave Thaler's WGLC comments. A On Sun, Jul 03, 2016 at 09:51:33AM -0700, internet-drafts@ietf.org wrote: > > 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 of the IETF. > > Title : On Interoperation of Labels Among Conventional DNS and Other Resolution Systems > Author : Andrew Sullivan > Filename : draft-ietf-dnssd-mdns-dns-interop-03.txt > Pages : 12 > Date : 2016-07-03 > > Abstract: > Despite its name, DNS-Based Service Discovery can use naming systems > other than the Domain Name System when looking for services. > Moreover, when it uses the DNS, DNS-Based Service Discovery uses the > full capability of DNS, rather than using a subset of available > octets. In order for DNS-SD to be used effectively in environments > where multiple different name systems and conventions for their > operation are in use, it is important to attend to differences in the > underlying technology and operational environment. This memo > presents an outline of the requirements for selection of labels for > conventional DNS and other resolution systems 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: > https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-03 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-mdns-dns-interop-03 > > > 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/ > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Mon Jul 4 04:10:51 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D2612B05E for ; Mon, 4 Jul 2016 04:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com 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 K5ECpdgco-d0 for ; Mon, 4 Jul 2016 04:10:47 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E218B12D090 for ; Mon, 4 Jul 2016 04:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=k/WjsBf3l5cs+4QGKmxt0Mhb2ltUwLlyqOUD4lgahtM=; b=X3CnFlS9YYCEMxzwPCibc8pu0WFZyp+Ba9a0nG8kPOyZLeDLjjo52Fk8+heWmWuNeeAWetmDuA4NccSsJ2Op9GPS8TMzGmB4cTW3AAqbOGgSjBfkYaz8A3dqwnAINsx9xG/teYI68fdJLliBb9RJ/ELQmqv7YG+fA88vuEYMoaE= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0184.outbound.protection.outlook.com [213.199.154.184]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-56-lmbxsRV6NuSuiuoZxbnlsw-1; Mon, 04 Jul 2016 12:10:15 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (TLS) id 15.1.534.14; Mon, 4 Jul 2016 11:10:14 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0528.022; Mon, 4 Jul 2016 11:10:13 +0000 From: Tim Chown To: "dnssd@ietf.org" , Dave Thaler Thread-Topic: draft-ietf-dnssd-mdns-dns-interop-03 - about to ship to IESG Thread-Index: AQHR1eSjFpGqX5JxSES9rtsCg7eCLQ== Date: Mon, 4 Jul 2016 11:10:13 +0000 Message-ID: References: <20160703165133.9328.22022.idtracker@ietfa.amsl.com> In-Reply-To: <20160703165133.9328.22022.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:a110:450e:948d:8fca] x-ms-office365-filtering-correlation-id: 7e088a48-0bb9-497f-919a-08d3a3fbc5c6 x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 20:+Zuc2weEdCtY+PRrjs/01TwaGAFLmQWlTInd1A9uYE7w+7rjBeXpzFwlNHP7aGgTCWMYt1BmgChDtvW6XcxIDysLcRWEtM7may7Z3QjAmm4i/ZdJCtew7wKkDESbybqEEHyEJjhMvAbqRfJILgygquc6Gn28ix90FwVCyLPh/vA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 0993689CD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(66654002)(377424004)(189002)(199003)(68736007)(76176999)(2561002)(50986999)(2906002)(19580405001)(82746002)(83716003)(122556002)(19580395003)(107886002)(189998001)(229853001)(15975445007)(2421001)(33656002)(86362001)(106116001)(5001770100001)(77096005)(2501003)(97736004)(106356001)(105586002)(5002640100001)(2950100001)(2900100001)(36756003)(92566002)(87936001)(81156014)(101416001)(102836003)(586003)(7736002)(6116002)(8676002)(230783001)(81166006)(8936002)(57306001)(74482002)(50226002)(7846002)(10400500002)(1511001)(3280700002)(8666005)(3660700001)(305945005)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <291001553AC7464688C2089F32EDBE9D@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2016 11:10:13.8925 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 X-MC-Unique: lmbxsRV6NuSuiuoZxbnlsw-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: [dnssd] draft-ietf-dnssd-mdns-dns-interop-03 - about to ship to IESG X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jul 2016 11:10:50 -0000 SGksDQoNCkZpcnN0LCBtYW55IHRoYW5rcyB0byBBbmRyZXcgZm9yIHN1Ym1pdHRpbmcgdGhpcyB1 cGRhdGUgaW4gYWR2YW5jZSBvZiBGcmlkYXnigJlzIGN1dC1vZmYuDQoNClJhbHBoIGFuZCBJIHBs YW4gdG8gc3VibWl0IHRoaXMgcmV2aXNlZCBkcmFmdCB0byB0aGUgSUVTRyB0aGlzIHdlZWsuIElm IHRoZXJlIGFyZSBhbnkgZnVydGhlciBjb21tZW50cywgdGhlc2Ugd291bGQgYmUgd2VsY29tZWQu DQoNCkZvciB0aG9zZSBpbnRlcmVzdGVkIGluIHRoZSBzcGVjaWZpY3Mgb2YgdGhlIGNsYXJpZmlj YXRpb25zIGFwcGxpZWQgaW4gdGhlIG5ldyB0ZXh0LCBwbGVhc2UgdmlldyB0aGUgZGlmZiBmcm9t IHRoZSBwcmV2aW91cyB2ZXJzaW9uLCBmb3Igd2hpY2ggeW914oCZbGwgc2VlIHRocmVlIHNtYWxs IGFkZGl0aW9uYWwgY2h1bmtzIG9mIHRleHQgYWRkZWQsIGFtb25nc3QgdGhlIG90aGVyIGVkaXRz Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZG5zc2QtbWRu cy1kbnMtaW50ZXJvcC0wMyANCg0KQ29tbWVudHMgcmVpbmZvcmNpbmcgdGhhdCBpdCdzIG5vdyBy ZWFkeSB0byBzaGlwIGFyZSBhbHNvIHdlbGNvbWUuDQoNClRpbSANCg0KPiBPbiAzIEp1bCAyMDE2 LCBhdCAxNzo1MSwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiANCj4gDQo+IEEg TmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0 LURyYWZ0cyBkaXJlY3Rvcmllcy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUg RXh0ZW5zaW9ucyBmb3IgU2NhbGFibGUgRE5TIFNlcnZpY2UgRGlzY292ZXJ5ICBvZiB0aGUgSUVU Ri4NCj4gDQo+ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBPbiBJbnRlcm9wZXJhdGlvbiBvZiBM YWJlbHMgQW1vbmcgQ29udmVudGlvbmFsIEROUyBhbmQgT3RoZXIgUmVzb2x1dGlvbiBTeXN0ZW1z DQo+ICAgICAgICBBdXRob3IgICAgICAgICAgOiBBbmRyZXcgU3VsbGl2YW4NCj4gCUZpbGVuYW1l ICAgICAgICA6IGRyYWZ0LWlldGYtZG5zc2QtbWRucy1kbnMtaW50ZXJvcC0wMy50eHQNCj4gCVBh Z2VzICAgICAgICAgICA6IDEyDQo+IAlEYXRlICAgICAgICAgICAgOiAyMDE2LTA3LTAzDQo+IA0K PiBBYnN0cmFjdDoNCj4gICBEZXNwaXRlIGl0cyBuYW1lLCBETlMtQmFzZWQgU2VydmljZSBEaXNj b3ZlcnkgY2FuIHVzZSBuYW1pbmcgc3lzdGVtcw0KPiAgIG90aGVyIHRoYW4gdGhlIERvbWFpbiBO YW1lIFN5c3RlbSB3aGVuIGxvb2tpbmcgZm9yIHNlcnZpY2VzLg0KPiAgIE1vcmVvdmVyLCB3aGVu IGl0IHVzZXMgdGhlIEROUywgRE5TLUJhc2VkIFNlcnZpY2UgRGlzY292ZXJ5IHVzZXMgdGhlDQo+ ICAgZnVsbCBjYXBhYmlsaXR5IG9mIEROUywgcmF0aGVyIHRoYW4gdXNpbmcgYSBzdWJzZXQgb2Yg YXZhaWxhYmxlDQo+ICAgb2N0ZXRzLiAgSW4gb3JkZXIgZm9yIEROUy1TRCB0byBiZSB1c2VkIGVm ZmVjdGl2ZWx5IGluIGVudmlyb25tZW50cw0KPiAgIHdoZXJlIG11bHRpcGxlIGRpZmZlcmVudCBu YW1lIHN5c3RlbXMgYW5kIGNvbnZlbnRpb25zIGZvciB0aGVpcg0KPiAgIG9wZXJhdGlvbiBhcmUg aW4gdXNlLCBpdCBpcyBpbXBvcnRhbnQgdG8gYXR0ZW5kIHRvIGRpZmZlcmVuY2VzIGluIHRoZQ0K PiAgIHVuZGVybHlpbmcgdGVjaG5vbG9neSBhbmQgb3BlcmF0aW9uYWwgZW52aXJvbm1lbnQuICBU aGlzIG1lbW8NCj4gICBwcmVzZW50cyBhbiBvdXRsaW5lIG9mIHRoZSByZXF1aXJlbWVudHMgZm9y IHNlbGVjdGlvbiBvZiBsYWJlbHMgZm9yDQo+ICAgY29udmVudGlvbmFsIEROUyBhbmQgb3RoZXIg cmVzb2x1dGlvbiBzeXN0ZW1zIHdoZW4gdGhleSBhcmUgZXhwZWN0ZWQNCj4gICB0byBpbnRlcm9w ZXJhdGUgaW4gdGhpcyBtYW5uZXIuDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtZG5zc2QtbWRucy1kbnMtaW50ZXJvcC8NCj4gDQo+IFRoZXJlJ3Mg YWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbnNzZC1tZG5zLWRucy1pbnRlcm9wLTAzDQo+IA0KPiBB IGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+IGh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWRuc3NkLW1kbnMtZG5zLWlu dGVyb3AtMDMNCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAg YXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBJLUQtQW5ub3VuY2Ug bWFpbGluZyBsaXN0DQo+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KPiBJbnRlcm5ldC1EcmFmdCBkaXJl Y3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0KPiBvciBmdHA6Ly9mdHAu aWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KDQo= From nobody Mon Jul 4 21:53:29 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2C5512D091 for ; Mon, 4 Jul 2016 21:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.626 X-Spam-Level: X-Spam-Status: No, score=-5.626 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 HLRPD86qX218 for ; Mon, 4 Jul 2016 21:53:25 -0700 (PDT) Received: from purin.rz.uni-konstanz.de (purin.rz.uni-konstanz.de [134.34.240.45]) (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 F3551126B6D for ; Mon, 4 Jul 2016 21:53:24 -0700 (PDT) Received: from nkongsamba.rz.uni-konstanz.de (HELO smtp.uni-konstanz.de) ([134.34.240.62]) by viribus.rz.uni-konstanz.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Jul 2016 04:53:22 +0000 Received: from [10.51.2.34] (unknown [133.25.247.201]) (Authenticated sender: daniel.kaiser) by smtp.uni-konstanz.de (Postfix) with ESMTPSA id 760C534; Tue, 5 Jul 2016 06:53:21 +0200 (CEST) To: Alf Watt References: <04a901d1ce4e$52e056e0$f8a104a0$@huitema.net> <1674621C-3632-4F32-8552-8625D0BCE1DE@istumbler.net> From: Daniel Kaiser Message-ID: Date: Tue, 5 Jul 2016 06:58:38 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <1674621C-3632-4F32-8552-8625D0BCE1DE@istumbler.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms020200020700060906060800" Archived-At: Cc: Christian Huitema , dnssd@ietf.org, Martin Thomson Subject: Re: [dnssd] dnssd privacy draft X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2016 04:53:28 -0000 This is a cryptographically signed message in MIME format. --------------ms020200020700060906060800 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We already took the SIGMA-protocols, which IKE is based on, into consideration. The method proposed in rfc4322 depends on keys retrievable via DNS and on DNSSEC; I think configuring this would pose to much overhead. Further, rfc4322 proposes means for opportunistic encryption which is not what we want as a means for establishing a pairing. For a pairing, the users should authenticate each other. As of yet, we have mainly discussed means of pairing for users meeting in person; in this scenario, authentication can be easily performed by verifying a fingerprint. Users are already used to this workflow when using chat applications like "Signal". To offer the possibility of zero configuration pairing, we discussed using a pairing service announced via mDNS in trusted networks (e.g. at home). kind regards Daniel On 06/27/2016 06:17 AM, Alf Watt wrote: > Opportunistic Encryption using the Internet Key Exchange (IKE) might be= suitable for the purposes proposed here. >=20 > https://tools.ietf.org/html/rfc4322 >=20 > Best, > Alf >=20 >> On Jun 26, 2016, at 5:32 PM, Martin Thomson = wrote: >> >> On 25 June 2016 at 05:26, Christian Huitema wrot= e: >>> Yes. The point is, do we have the appetite to design a pairing protoc= ol in >>> this group? If we do, my preference would be to describe this pairing= >>> protocol in a separate draft. >> >> Sounds like hard work :) Might be worth doing though. >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd >=20 --------------ms020200020700060906060800 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC D5wwggTVMIIDvaADAgECAghQTsb1PRG0ZDANBgkqhkiG9w0BAQsFADBxMQswCQYDVQQGEwJE RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2VjIFRy dXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENBIDIwHhcNMTQw NzIyMTIwODI2WhcNMTkwNzA5MjM1OTAwWjBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZO LVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xv YmFsIC0gRzAxMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA6ZvDZ4X5Da71jVTD llA1PWLpbkztlNcAW5UidNQg6zSP1uzAMQQLmYHiphTSUqAoI4SLdIkEXlvg4njBeMsWyyg1 OXstkEXQ7aAAeny/Sg4bAMOG6VwrMRF7DPOCJEOMHDiLamgAmu7cT3ir0sYTm3at7t4m6O8B r3QPwQmi9mvOvdPNFDBP9eXjpMhim4IaAycwDQJlYE3t0QkjKpY1WCfTdsZxtpAdxO3/NYZ9 bzOz2w/FEcKKg6GUXUFr2NIQ9Uz9ylGs2b3vkoO72uuLFlZWQ8/h1RM9ph8nMM1JVNvJEzSa cXXFbOqnC5j5IZ0nrz6jOTlIaoytyZn7wxLyvQIDAQABo4IBhjCCAYIwDgYDVR0PAQH/BAQD AgEGMB0GA1UdDgQWBBRJt8bP6D0ff+pEexMp9/EKcD7eZDAfBgNVHSMEGDAWgBQxw3kbuvVT 1xfgiXotF2wKsyudMzASBgNVHRMBAf8ECDAGAQH/AgECMGIGA1UdIARbMFkwEQYPKwYBBAGB rSGCLAEBBAICMBEGDysGAQQBga0hgiwBAQQDADARBg8rBgEEAYGtIYIsAQEEAwEwDwYNKwYB BAGBrSGCLAEBBDANBgsrBgEEAYGtIYIsHjA+BgNVHR8ENzA1MDOgMaAvhi1odHRwOi8vcGtp MDMzNi50ZWxlc2VjLmRlL3JsL0RUX1JPT1RfQ0FfMi5jcmwweAYIKwYBBQUHAQEEbDBqMCwG CCsGAQUFBzABhiBodHRwOi8vb2NzcDAzMzYudGVsZXNlYy5kZS9vY3NwcjA6BggrBgEFBQcw AoYuaHR0cDovL3BraTAzMzYudGVsZXNlYy5kZS9jcnQvRFRfUk9PVF9DQV8yLmNlcjANBgkq hkiG9w0BAQsFAAOCAQEAYyAo/ZwhhnK+OUZZOTIlvKkBmw3Myn1BnIZtCm4ssxNZdbEzkhth Jxb/w7LVNYL7hCoBSb1mu2YvssIGXW4/buMBWlvKQ2NclbbhMacf1QdfTeZlgk4y+cN8ekvN TVx07iHydQLsUj7SyWrTkCNuSWc1vn9NVqTszC/Pt6GXqHI+ybxA1lqkCD3WvILDt7cyjrEs jmpttzUCGc/1OURYY6ckABCwu/xOr24vOLulV0k/2G5QbyyXltwdRpplic+uzPLl2Z9Tsz6h L5Kp2AvGhB8Exuse6J99tXulAvEkxSRjETTMWpMgKnmIOiVCkKllO3yG0xIVIyn8LNrMOVtU FzCCBUIwggQqoAMCAQICBxeQYOCzPaowDQYJKoZIhvcNAQELBQAwWjELMAkGA1UEBhMCREUx EzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNVBAMTG0RGTi1W ZXJlaW4gUENBIEdsb2JhbCAtIEcwMTAeFw0xNDA1MTIxNTA1NTJaFw0xOTA3MDkyMzU5MDBa MGYxCzAJBgNVBAYTAkRFMRUwEwYDVQQKEwxVbmktS29uc3RhbnoxHTAbBgNVBAMTFFVuaS1L b25zdGFueiBDQS1TMDAxMSEwHwYJKoZIhvcNAQkBFhJjYUB1bmkta29uc3RhbnouZGUwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCv07T95IkjXCFklVv9IjNJyK271LN0qNFz hLUFscans64sLOUveaaw0xgQAN4N95WE6KxHUTVmCwM9FzXQVsVQMhP+blWHKkjmjUDSeK3P LDC0A3pbSr6gr5JLsCjvgqPYL/kCmyN90AA3Oms32JLYUUTnMxrRdFsj2FxxI1vwm3HGCW2W GMQMc3vOQ2WQ1cf9gSp2+Gz1n6If3zyoBEreZWEVHXy80I+NTc7MpM0eWi+PNvYNdOpRqvyP qrwpcnoDE0evYRS90ZTv/JOpjSlSZp/hHMPoUK9FjccgAo6Aobukcd7u9vxWm3z2uLTwFMSK M6rA6TdB58bXmimK7N8rAgMBAAGjggH/MIIB+zASBgNVHRMBAf8ECDAGAQH/AgEBMA4GA1Ud DwEB/wQEAwIBBjARBgNVHSAECjAIMAYGBFUdIAAwHQYDVR0OBBYEFNlidIoXi1wWImK8Jw7j 7xqcnLVDMB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB0GA1UdEQQWMBSBEmNh QHVuaS1rb25zdGFuei5kZTCBiAYDVR0fBIGAMH4wPaA7oDmGN2h0dHA6Ly9jZHAxLnBjYS5k Zm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwPaA7oDmGN2h0dHA6Ly9j ZHAyLnBjYS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NybC9jYWNybC5jcmwwgdcGCCsG AQUFBwEBBIHKMIHHMDMGCCsGAQUFBzABhidodHRwOi8vb2NzcC5wY2EuZGZuLmRlL09DU1At U2VydmVyL09DU1AwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZ2xvYmFs LXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MEcGCCsGAQUFBzAChjtodHRwOi8vY2Rw Mi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jYWNlcnQvY2FjZXJ0LmNydDANBgkq hkiG9w0BAQsFAAOCAQEAy2kzMLxthpOp0TwgEkVWvTS9/BhN9kuYW9qiHVywP5UkEDu5ULEI SE1X9Bvl9ZUBwZ1iWBchsSAzzal+rcgE7vYNG7QczeXzn2WcuZRbujkt5wB/QRH1I6f0Iafo nMkTKvPBiprdOvSjjJ3yfSXrcBDMJCKRSMKqfDtqYvTyUITuAnrnKC2VtiTHuw8jibY+ZjMK bmSqxjBBVJoRs6FcnlR/WO7dBIkIhNzZAr6cdzBxV1Kx9Gb+BrN9/xBsKbuPiCFrmi6py5k3 jpdSpfUpeXmd9TmuzRmibFsw9LwaLJtPx3Ewcge/FOl/yixMk/oanYI+EMr4bCQQwUJkfntC cjCCBXkwggRhoAMCAQICBxcz1Ee2Vx8wDQYJKoZIhvcNAQEFBQAwZjELMAkGA1UEBhMCREUx FTATBgNVBAoTDFVuaS1Lb25zdGFuejEdMBsGA1UEAxMUVW5pLUtvbnN0YW56IENBLVMwMDEx ITAfBgkqhkiG9w0BCQEWEmNhQHVuaS1rb25zdGFuei5kZTAeFw0xNDAzMDMxMDE3MjdaFw0x NzAzMDIxMDE3MjdaMGkxCzAJBgNVBAYTAkRFMR4wHAYDVQQKExVVbml2ZXJzaXRhZXQgS29u c3RhbnoxIjAgBgNVBAsTGURpc3RyaWJ1dGVkIFN5c3RlbXMgR3JvdXAxFjAUBgNVBAMTDURh bmllbCBLYWlzZXIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDbg5mYrw+4wXWw PsMeIZTLsN5HjpUUq6W6ab7NzpvJ5Ryl04tJCMpDTBzYgjisy4Zz1QF225ahByjF4dxfjxGE l4kIr8+A1UnlsYB0Pd0OAy7/luxIUCIIG4WkeC83a9NHO1tZIn9l3U4M4DB3fkacumTiEGn4 q2Zm7a+3CDZeye8GazNfUMpjKVPPa9BYX7eBKNx/7k0/OdlIwx+7hr2UC3bU7q7igYxR0Ov7 pfSXgpHKj2uQLQ44SSLBJIsh55n4VA2jU5zszueatxCpSp4uDi0zpYZ/ZCYIjY61I7r+cfo7 3T99kJeAve9s1+7EvbHkeyD4MmJAGm3Q2UHnVWtpAgMBAAGjggInMIICIzAvBgNVHSAEKDAm MBEGDysGAQQBga0hgiwBAQQDATARBg8rBgEEAYGtIYIsAgEEAwEwCQYDVR0TBAIwADALBgNV HQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBSxvU+L AYS39DZ7Tv9NiY3W8aNb3jAfBgNVHSMEGDAWgBTZYnSKF4tcFiJivCcO4+8anJy1QzAoBgNV HREEITAfgR1kYW5pZWwua2Fpc2VyQHVuaS1rb25zdGFuei5kZTCBmQYDVR0fBIGRMIGOMEWg Q6BBhj9odHRwOi8vY2RwMS5wY2EuZGZuLmRlL3VuaS1rb25zdGFuei1zZXJ2ZXItY2EvcHVi L2NybC9jYWNybC5jcmwwRaBDoEGGP2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvdW5pLWtvbnN0 YW56LXNlcnZlci1jYS9wdWIvY3JsL2NhY3JsLmNybDCBsgYIKwYBBQUHAQEEgaUwgaIwTwYI KwYBBQUHMAKGQ2h0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvdW5pLWtvbnN0YW56LXNlcnZlci1j YS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwTwYIKwYBBQUHMAKGQ2h0dHA6Ly9jZHAyLnBjYS5k Zm4uZGUvdW5pLWtvbnN0YW56LXNlcnZlci1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwDQYJ KoZIhvcNAQEFBQADggEBABQ5LCw9IXS3+6j7Xe7AMc14HjmxBE6rca/78qBFb1W1ZlE8EugO V1MxEEQr6ulPZSLtgKIWxxrkH3WQwydufAKhXFAgcXWPZDoYN2BBS+QKLHMfPsmbrt/vAwdT SBS+61M3OT1F7iev2D62xtIjMMwzAlhqzvPX15e3M8POJoZIRIx9RJzVfDNI5zqFdWSCT8j3 84l91vPNzJI6f7CrcahIG0CSsoN9X58hgBcJgp4kiQpGERWhbNTEF0Leu3smMZCTg73JDdu3 8ERZ2L+F3ccG0STvxM4pVDCZxs77usGOZLp16VIMEw3K9uwUC4n7piWNnMon+GY0NOJ4bFiZ 1wMxggN/MIIDewIBATBxMGYxCzAJBgNVBAYTAkRFMRUwEwYDVQQKEwxVbmktS29uc3Rhbnox HTAbBgNVBAMTFFVuaS1Lb25zdGFueiBDQS1TMDAxMSEwHwYJKoZIhvcNAQkBFhJjYUB1bmkt a29uc3RhbnouZGUCBxcz1Ee2Vx8wDQYJYIZIAWUDBAIBBQCgggHfMBgGCSqGSIb3DQEJAzEL BgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE2MDcwNTA0NTgzOFowLwYJKoZIhvcNAQkE MSIEIG1LquPQQcJGTMcxdLsjk1hbeQoYr91WMbPu8DJ80B1UMGwGCSqGSIb3DQEJDzFfMF0w CwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw DQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYAGCSsGAQQBgjcQBDFz MHEwZjELMAkGA1UEBhMCREUxFTATBgNVBAoTDFVuaS1Lb25zdGFuejEdMBsGA1UEAxMUVW5p LUtvbnN0YW56IENBLVMwMDExITAfBgkqhkiG9w0BCQEWEmNhQHVuaS1rb25zdGFuei5kZQIH FzPUR7ZXHzCBggYLKoZIhvcNAQkQAgsxc6BxMGYxCzAJBgNVBAYTAkRFMRUwEwYDVQQKEwxV bmktS29uc3RhbnoxHTAbBgNVBAMTFFVuaS1Lb25zdGFueiBDQS1TMDAxMSEwHwYJKoZIhvcN AQkBFhJjYUB1bmkta29uc3RhbnouZGUCBxcz1Ee2Vx8wDQYJKoZIhvcNAQEBBQAEggEAZ6v0 +G5k2kslLFLzdFIJazhIdM9VS1ZEjV3gZtkMNsFuQJV1VbxbYwUTPOlrcZd5lRNoeGtNrc/P CWrUTHwtqJQAh5OCHimGQCCmJp9D24vFgJJju7beMSEbgW66sL8rDoUq9Ra8wc5s544gQVIf B6TrveG12XlEAQcM7P6JpYgUCIckBrDd6H7LPn59Ewthfn7DuMBm5IiNwRHR/joRdefrqe0w LItKV26hX6n1ViWEegw5tz3ZdIe0NpCMbjhyhmucAK5eBc+ElLXITiF13jVH0KRQvvtm0z6u QXo7bOYuPxQzeLa6j9WrIXJEWE/sD34CxZSti8Ts2qADb9CpCwAAAAAAAA== --------------ms020200020700060906060800-- From nobody Tue Jul 5 22:33:26 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 364EC12D0F3 for ; Tue, 5 Jul 2016 22:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.426 X-Spam-Level: X-Spam-Status: No, score=-3.426 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_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=opendkim.org header.b=iiaEhEOb; dkim=pass (1024-bit key) header.d=elandsys.com header.b=kM8QXszU 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 3yVoNys1V2Zi for ; Tue, 5 Jul 2016 22:33:23 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id E3A1012B02B for ; Tue, 5 Jul 2016 22:33:22 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.226.54.18]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id u665X4PK015702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Jul 2016 22:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1467783195; x=1467869595; bh=N4lWmCwyiAFSHVoS9N73DsdEM2CquEGbAl0BSCBd8Kg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=iiaEhEOb5ysZAoK8OkGT/cH7xwFJNh9JsiSuN0RXpBrRNDJlV6KxYoNxAgI6KgXpe h3w0AbMTxS/WmAtXI4dG1zmBxxni4StIiZTrL7/1CKgjjNlE6GevLtnKNF5fpMQ2OH B7ocnEW7DI5PFROZWB5zTPxRbHwVprE9RrBswZ6Q= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1467783195; x=1467869595; i=@elandsys.com; bh=N4lWmCwyiAFSHVoS9N73DsdEM2CquEGbAl0BSCBd8Kg=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=kM8QXszU89eXXuDgFhi4Q0pbVEk9nRqovsiwQXXvKLzyWQscc4I2Fpvv+b2g9R+iJ LpHw6zwqi3whEMCV9UwH1juWdpMfh1ZimhHUfS5u1SU6FgrZEJ6erTzP043DLEh6qh Bi0zCiiZIHXT2HDWHJySEP+1ER8xFpauYV4rJSrY= Message-Id: <6.2.5.6.2.20160705220136.0afbc258@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 05 Jul 2016 22:32:42 -0700 To: Christian Huitema From: S Moonesamy In-Reply-To: <001501d1cd80$4f885de0$ee9919a0$@huitema.net> References: <6.2.5.6.2.20160623020221.0b6b9df0@resistor.net> <001501d1cd80$4f885de0$ee9919a0$@huitema.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Cc: dnssd@ietf.org Subject: Re: [dnssd] [ietf-privacy] Fwd: draft-huitema-dnssd-privacy-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2016 05:33:24 -0000 Hi Christian, At 11:51 23-06-2016, Christian Huitema wrote: >Section 3 describes an initial design that was then abandoned. I guess that >in the next revision we could just remove that section entirely. > >On the other hand, the proposal was indeed to use different obfuscated names >at different locations. Ok. >The private discovery service relies on pre-existing pairings. The pairing >solutions are only drafted in very vague terms in the draft. I really wonder >whether we should go define a complete pairing protocol. Is that in-charter >for DNS-SD? What about competing with existing solutions over Bluetooth, >Wi-Fi, and certainly many more? I'll leave the in-charter question to the WG Chairs. :-) I assume that the last question in similar to what is in Section 5.2. I haven't looked at the existing solutions to provide a useful answer. Regards, S. Moonesamy From nobody Fri Jul 8 16:56:39 2016 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E9812D14D; Fri, 8 Jul 2016 16:56:34 -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: 6.25.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160708235634.32176.66745.idtracker@ietfa.amsl.com> Date: Fri, 08 Jul 2016 16:56:34 -0700 Archived-At: Cc: dnssd@ietf.org Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-08.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2016 23:56:35 -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 of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-08.txt Pages : 33 Date : 2016-07-08 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently 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: https://tools.ietf.org/html/draft-ietf-dnssd-push-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-08 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 Jul 11 10:05:48 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8959812D58C for ; Mon, 11 Jul 2016 10:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com 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 kQDvG8MqHW0J for ; Mon, 11 Jul 2016 10:05:43 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C9512D096 for ; Mon, 11 Jul 2016 10:05:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WrvJV0s+ZYA+FCoExSp7VScuc4Bj/3JffQ6abHLvGzY=; b=UHXjmAWlukUSDzvmUrDaKra2qQD0MKYAlQqD1F7Wtb6mu72gLEFx1Nk+Td8pm+8lO91vxlZ/ElJtG9/EiTcGtJqd8mvnnKQVq/njWWqZYI2D/TGcHeR8kIr45sXxSZAnYMnNGnRcBvg4c5IgGfit/nagE+FfP2DtwzuHPlO5x+A= Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0178.outbound.protection.outlook.com [213.199.180.178]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-21-Xl-lr6yePdieOLYaHYMMLg-1; Mon, 11 Jul 2016 18:05:35 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Mon, 11 Jul 2016 17:05:34 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.018; Mon, 11 Jul 2016 17:05:34 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: Draft agenda, IETF 96 Thread-Index: AQHR25ZwRfZkAeVNmkSsxniDeYRonQ== Date: Mon, 11 Jul 2016 17:05:34 +0000 Message-ID: <81795688-2AFC-4917-826F-570E694A0845@jisc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:a5de:6888:c656:9c03] x-ms-office365-filtering-correlation-id: a517b04a-c3c8-45d6-9ba8-08d3a9ad92e2 x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 20:9WTPv+niQv3WHug00wjF+AHwy+TayK35oQgbTCHSAcuDeXckta2f3JFy7WR5KrzVsaUdWSEai2bIhkrEUKlBRdbvlvKiSie7yosNGJe4vd26KdOZxFc1h5RRrbLxHCJTNmJeavCOneHL5KDBJzIXxjn6OLeC9perp0mQRZb4n0I= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 00003DBFE7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(199003)(106116001)(92566002)(81166006)(105586002)(106356001)(2900100001)(229853001)(110136002)(107886002)(15975445007)(50226002)(50986999)(33656002)(77096005)(2351001)(122556002)(81156014)(450100001)(11100500001)(83716003)(5640700001)(7906003)(2501003)(10400500002)(1730700003)(6116002)(2906002)(7736002)(102836003)(8676002)(19580395003)(7846002)(3660700001)(19617315012)(82746002)(3280700002)(86362001)(586003)(189998001)(97736004)(36756003)(57306001)(16236675004)(101416001)(8936002)(74482002)(68736007)(5002640100001)(87936001)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2016 17:05:34.6401 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-MC-Unique: Xl-lr6yePdieOLYaHYMMLg-1 Content-Type: multipart/alternative; boundary="_000_817956882AFC4917826F570E694A0845jiscacuk_" Archived-At: Subject: [dnssd] Draft agenda, IETF 96 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2016 17:05:46 -0000 --_000_817956882AFC4917826F570E694A0845jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNClRoZSBkcmFmdCBhZ2VuZGEgZm9yIEJlcmxpbiBoYXMgYmVlbiBwb3N0ZWQuIEJhc2hp bmcgaXMgd2VsY29tZSA6KQ0KDQpUaW0NCg0KLS0tDQoNCkROU1NEIFdHIEFnZW5kYQ0KSUVURjk2 LCBCZXJsaW4NCldlZG5lc2RheSAyMHRoIEp1bHkgMjAxNg0KMi4wMHBtIC0gMy4zMHBtIGxvY2Fs IHRpbWUNCg0KQ2hhaXJz4oCZIEludHJvZHVjdGlvbg0KQ2hhaXJzLCA1IG1pbnMNCg0KVXBkYXRl cyB0byBIeWJyaWQgVW5pY2FzdC9NdWx0aWNhc3QgRE5TLUJhc2VkIFNlcnZpY2UgRGlzY292ZXJ5 DQpTdHVhcnQgQ2hlc2hpcmUsIDEwIG1pbnMNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWRuc3NkLWh5YnJpZC0wMw0KLSBhd2FpdGluZyB1cGRhdGUsIHRoZW4gc2VuZGlu ZyB0byBJRVNHOyBhbnkgbmV3IGNvbW1lbnRzIHNpbmNlIHRoZSBwcmV2aW91cyBtZWV0aW5nPw0K DQpEcmFmdCByZXZpZXc6IEROUyBQdXNoDQotIHdlIGFncmVlZCBhdCB0aGUgbGFzdCBtZWV0aW5n IHRvIHNwbGl0IG91dCB0aGUgc2lnbmFsbGluZyBwYXJ0DQpUb20gUHVzYXRlcmksIDEwIG1pbnMN Cmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRuc3NkLXB1c2gtMDgNCi0g Zm9yIHNpZ25hbGxpbmcgZG9jdW1lbnQsIHNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtYmVsbGlzLWRuc29wLXNlc3Npb24tc2lnbmFsLTAwIChvbiB0aGUgZG5zb3AgV0cgYWdl bmRhKQ0KDQpEaXNjdXNzaW9uOiBETlMgVXBkYXRlIGFuZCBtRE5TL2h5YnJpZCBwcm94eSBjb2V4 aXN0ZW5jZQ0KLSBmb3IgYmFja2dyb3VuZCwgc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1sZW1vbi1ob21lbmV0LW5hbWluZy1hcmNoaXRlY3R1cmUtMDEjc2VjdGlvbi0zLjQN ClRlZCBMZW1vbiwgMTUgbWlucw0KDQpEaXNjdXNzaW9uOiBSZWNvbW1lbmRhdGlvbnMgZm9yIHVz aW5nIHRoZSBoeWJyaWQgcHJveHkNCi0gaG93IGRvIHlvdSBzdGl0Y2ggcHJveGllcyB0b2dldGhl ciBpbiBjbGV2ZXIgd2F5cz8NCi0gd2hhdCBhcmUgdGhlIHRyYWRlb2Zmcz8NCi0gaG93IGRvIHlv dSBtYWtlIGl0IHVzYWJsZT8NClJhbHBoIERyb21zLCAxNSBtaW5zDQoNCkRyYWZ0IHJldmlldzog UHJpdmFjeSBFeHRlbnNpb25zIGZvciBETlMtU0QNCkRhbmllbCBLYWlzZXIsIDE1IG1pbnMNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1odWl0ZW1hLWRuc3NkLXByaXZhY3ktMDEN Ci0gdGFraW5nIGluaXRpYWwgc3RlcHMgaW50byBzb2x1dGlvbiBzcGFjZQ0KDQpEaXNjdXNzaW9u OiBPdGhlciBkcmFmdHMsIGltcGxlbWVudGF0aW9ucywgYW5kIG5leHQgc3RlcHMNCi0gZHJhZnQt b3Rpcy1kbnNzZC1zY2FsYWJsZS1kbnMtc2QtdGhyZWF0cy0wMw0KLSBkcmFmdC1pZXRmLWhvbWVu ZXQtaHlicmlkLXByb3h5LXplcm9jb25mLTAyDQotIGRyYWZ0LWFnZ2Fyd2FsLWRuc3NkLW9wdGlt aXplLXF1ZXJ5LTAwDQpDaGFpcnMsIDE1IG1pbnMNCg0KQ2xvc2UgYW5kIHN1bW1hcnkgb2YgYWN0 aW9ucw0KQ2hhaXJzLCA1IG1pbnMNCg0K --_000_817956882AFC4917826F570E694A0845jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <5E273CC52985CD45BEB71F0C89024322@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgZHJhZnQgYWdlbmRhIGZvciBC ZXJsaW4gaGFzIGJlZW4gcG9zdGVkLiBCYXNoaW5nIGlzIHdlbGNvbWUgOik8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+VGlt Jm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPi0tLTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBtaW4taGVpZ2h0OiAxNHB4OyIgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+PC9zcGFuPjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBu b3JtYWw7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0i Ij5ETlNTRCBXRyBBZ2VuZGE8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6 IG5vbmUiIGNsYXNzPSIiPklFVEY5NiwgQmVybGluPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0i Zm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj5XZWRuZXNkYXkgMjB0aCBKdWx5IDIwMTY8L3Nw YW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsi IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjIuMDBw bSAtIDMuMzBwbSBsb2NhbCB0aW1lPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG1pbi1oZWlnaHQ6IDE0cHg7IiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48L3NwYW4+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsi IGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPkNoYWly c+KAmSBJbnRyb2R1Y3Rpb248L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6 IG5vbmUiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRl LXNwYWNlOnByZSI+PC9zcGFuPkNoYWlycywgNSBtaW5zPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG1pbi1oZWlnaHQ6IDE0cHg7IiBj bGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48L3NwYW4+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWln aHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNs YXNzPSIiPlVwZGF0ZXMgdG8gSHlicmlkIFVuaWNhc3QvTXVsdGljYXN0IEROUy1CYXNlZCBTZXJ2 aWNlIERpc2NvdmVyeTwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5l LWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9u ZSIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3Bh Y2U6cHJlIj48L3NwYW4+U3R1YXJ0IENoZXNoaXJlLCAxMCBtaW5zPC9zcGFuPjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNvbG9yOiByZ2IoNzEs IDEzNSwgMjU1KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjogdW5k ZXJsaW5lIDsgZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbnNzZC1oeWJyaWQtMDMiIGNsYXNzPSIiPmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRuc3NkLWh5YnJpZC0wMzwvYT48 L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPi0g YXdhaXRpbmcgdXBkYXRlLCB0aGVuIHNlbmRpbmcgdG8gSUVTRzsgYW55IG5ldyBjb21tZW50cyBz aW5jZSB0aGUgcHJldmlvdXMgbWVldGluZz88L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgbWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9y bWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+ RHJhZnQgcmV2aWV3OiBETlMgUHVzaDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2Vy bmluZzogbm9uZSIgY2xhc3M9IiI+LSB3ZSBhZ3JlZWQgYXQgdGhlIGxhc3QgbWVldGluZyB0byBz cGxpdCBvdXQgdGhlIHNpZ25hbGxpbmcgcGFydDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBz dHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+VG9tIFB1c2F0ZXJpLCAxMCBtaW5zPC9zcGFu PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGNv bG9yOiByZ2IoNzEsIDEzNSwgMjU1KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9InRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lIDsgZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbnNzZC1wdXNoLTA4IiBj bGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbnNzZC1wdXNo LTA4PC9hPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdo dDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xh c3M9IiI+LSBmb3Igc2lnbmFsbGluZyBkb2N1bWVudCwgc2VlDQo8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVsbGlzLWRuc29wLXNlc3Npb24tc2lnbmFsLTAwIiBj bGFzcz0iIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iZWxsaXMtZG5zb3At c2Vzc2lvbi1zaWduYWwtMDA8L2E+IChvbiB0aGUgZG5zb3AgV0cgYWdlbmRhKTwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBtaW4taGVp Z2h0OiAxNHB4OyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xh c3M9IiI+PC9zcGFuPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJu aW5nOiBub25lIiBjbGFzcz0iIj5EaXNjdXNzaW9uOiBETlMgVXBkYXRlIGFuZCBtRE5TL2h5YnJp ZCBwcm94eSBjb2V4aXN0ZW5jZTwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4 OyBsaW5lLWhlaWdodDogbm9ybWFsOyBjb2xvcjogcmdiKDcxLCAxMzUsIDI1NSk7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmU7IGNvbG9yOiAjMDAwMDAwIiBjbGFz cz0iIj4tIGZvciBiYWNrZ3JvdW5kLCBzZWUgPC9zcGFuPg0KPHNwYW4gc3R5bGU9InRleHQtZGVj b3JhdGlvbjogdW5kZXJsaW5lIDsgZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48YSBocmVm PSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGVtb24taG9tZW5ldC1uYW1pbmct YXJjaGl0ZWN0dXJlLTAxI3NlY3Rpb24tMy40IiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtbGVtb24taG9tZW5ldC1uYW1pbmctYXJjaGl0ZWN0dXJlLTAxI3NlY3Rp b24tMy40PC9hPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhl aWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIg Y2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6 cHJlIj48L3NwYW4+VGVkIExlbW9uLCAxNSBtaW5zPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG1pbi1oZWlnaHQ6IDE0cHg7IiBjbGFz cz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48L3NwYW4+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6 IG5vcm1hbDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNz PSIiPkRpc2N1c3Npb246IFJlY29tbWVuZGF0aW9ucyBmb3IgdXNpbmcgdGhlIGh5YnJpZCBwcm94 eTwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9y bWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+ LSBob3cgZG8geW91IHN0aXRjaCBwcm94aWVzIHRvZ2V0aGVyIGluIGNsZXZlciB3YXlzPzwvc3Bh bj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIg Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+LSB3aGF0 IGFyZSB0aGUgdHJhZGVvZmZzPzwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4 OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQta2Vybmlu Zzogbm9uZSIgY2xhc3M9IiI+LSBob3cgZG8geW91IG1ha2UgaXQgdXNhYmxlPzwvc3Bhbj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9 IkFwcGxlLXRhYi1zcGFuIiBzdHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+UmFscGggRHJv bXMsIDE1IG1pbnM8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgbWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJm b250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjwvc3Bhbj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+ PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+RHJhZnQgcmV2aWV3OiBQ cml2YWN5IEV4dGVuc2lvbnMgZm9yIEROUy1TRDxzcGFuIGNsYXNzPSJBcHBsZS10YWItc3BhbiIg c3R5bGU9IndoaXRlLXNwYWNlOnByZSI+DQo8L3NwYW4+PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj48c3BhbiBzdHls ZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48c3BhbiBjbGFzcz0iQXBwbGUtdGFiLXNw YW4iIHN0eWxlPSJ3aGl0ZS1zcGFjZTpwcmUiPjwvc3Bhbj5EYW5pZWwgS2Fpc2VyLCAxNSBtaW5z PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3Jt YWw7IGNvbG9yOiByZ2IoNzEsIDEzNSwgMjU1KTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9InRl eHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lIDsgZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48 YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVpdGVtYS1kbnNzZC1w cml2YWN5LTAxIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVp dGVtYS1kbnNzZC1wcml2YWN5LTAxPC9hPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQt a2VybmluZzogbm9uZSIgY2xhc3M9IiI+LSB0YWtpbmcgaW5pdGlhbCBzdGVwcyBpbnRvIHNvbHV0 aW9uIHNwYWNlPC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IG1pbi1oZWlnaHQ6IDE0cHg7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9u dC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxz cGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPkRpc2N1c3Npb246IE90aGVy IGRyYWZ0cywgaW1wbGVtZW50YXRpb25zLCBhbmQgbmV4dCBzdGVwczwvc3Bhbj48L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTog J0hlbHZldGljYSBOZXVlJzsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiBu b3JtYWw7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IC13ZWJraXQtZm9udC1rZXJuaW5nOiBub25l OyIgY2xhc3M9IiI+LQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNs YXNzPSIiPmRyYWZ0LW90aXMtZG5zc2Qtc2NhbGFibGUtZG5zLXNkLXRocmVhdHMtMDM8L3NwYW4+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgZm9u dC1mYW1pbHk6ICdIZWx2ZXRpY2EgTmV1ZSc7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250 LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPi0gZHJhZnQtaWV0Zi1ob21lbmV0LWh5YnJpZC1wcm94 eS16ZXJvY29uZi0wMjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5l LWhlaWdodDogbm9ybWFsOyBmb250LWZhbWlseTogJ0hlbHZldGljYSBOZXVlJzsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+LSBkcmFmdC1hZ2dh cndhbC1kbnNzZC1vcHRpbWl6ZS1xdWVyeS0wMDwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZv bnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLXRhYi1zcGFuIiBz dHlsZT0id2hpdGUtc3BhY2U6cHJlIj48L3NwYW4+Q2hhaXJzLCAxNSBtaW5zPC9zcGFuPjwvZGl2 Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG1pbi1oZWln aHQ6IDE0cHg7IiBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFz cz0iIj48L3NwYW4+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBw eDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5p bmc6IG5vbmUiIGNsYXNzPSIiPkNsb3NlIGFuZCBzdW1tYXJ5IG9mIGFjdGlvbnM8L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNz PSIiPjxzcGFuIHN0eWxlPSJmb250LWtlcm5pbmc6IG5vbmUiIGNsYXNzPSIiPjxzcGFuIGNsYXNz PSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+PC9zcGFuPkNoYWlycywg NSBtaW5zPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_817956882AFC4917826F570E694A0845jiscacuk_-- From nobody Mon Jul 11 18:38:29 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17D0012B004 for ; Mon, 11 Jul 2016 18:38:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 H6eY10BSVykA for ; Mon, 11 Jul 2016 18:38:26 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 D9EBA126579 for ; Mon, 11 Jul 2016 18:38:25 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id u25so918340qtb.1 for ; Mon, 11 Jul 2016 18:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DbhG1vCDX89M6W3CFKTEqOir2tRc5C5PBNDgQCF7yRk=; b=yd6P/QufNGLDW47R7X68mDxXHQNaYwh1iqxc60SqK8AsydBH3glhxvIT+iG7/lxt6E iHwlephNJVniRiadjrhM1eUmIZftPrbIa9NR3nBArV6r0XH5QU7zOV1Rv89RIsKvwUK4 0Vqx/34byiJmOOObqMNpHQAVkdxXArFEa6buJwE6sBIci5j2Ak/9cGRWLrmJCHf4wt9K QY51PRVR9jsk7Pf42uZNp4iyo1jZbRnU6XqkSwffM8oCMOk6Uj7ox+vYwqnqXBKl0w4E HIF4Dh2+BUejLJ+3K+0h6GQRb8mOjexywa/2kF2UikwLw/MHFoY9Z4qXc2qYZCHS4QaO MBxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DbhG1vCDX89M6W3CFKTEqOir2tRc5C5PBNDgQCF7yRk=; b=CFYOxk9CjWaA8SV7l+WfcQ2Hhj4E8cRkn3dDDOwUqn1wRMwqBrTL6nbey0xWD1cbNF pMW9Hs69x3oh9XDAsz0U+y8Oyhh+JsK4vOJXA90yU8gEEvq9SJclv0rVoNAloeD2T2Pd sCIyrwO2ujjuaSxDc6fUjwNDEVAb6TrTjxsRrzJP08/jqB2urIRKRLUUllhvZWbjOVMX YPQ6P/U8nOfySNpS3krbGvNK24kL9bTSYCHPC4gNluOEt0P61cnQ+1hbX6r8jsgcxYH6 fsdORNmJF0X3vj28HiRxnubv6lnIFN+jC63NJL57wO9ws8pp/PZJSCDajDi2m2gHAIWD y2+A== X-Gm-Message-State: ALyK8tJkLH/eIlFqYQ6hvQ1HMUwpPDtb53yYwU2F9LG00FRsO+AuZJLszEiR3v+lI5nvsvNRgtv2fR5SasIaOA== X-Received: by 10.200.50.82 with SMTP id y18mr23178814qta.29.1468287505033; Mon, 11 Jul 2016 18:38:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Mon, 11 Jul 2016 18:38:24 -0700 (PDT) In-Reply-To: References: <04a901d1ce4e$52e056e0$f8a104a0$@huitema.net> <1674621C-3632-4F32-8552-8625D0BCE1DE@istumbler.net> From: Martin Thomson Date: Tue, 12 Jul 2016 11:38:24 +1000 Message-ID: To: Daniel Kaiser Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christian Huitema , dnssd@ietf.org Subject: Re: [dnssd] dnssd privacy draft X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 01:38:27 -0000 On 5 July 2016 at 14:58, Daniel Kaiser wrote: > As of yet, we have mainly discussed means of pairing for users meeting > in person; in this scenario, authentication can be easily performed by > verifying a fingerprint. Users are already used to this workflow when > using chat applications like "Signal". Is that really what happens here, or is it more of a leap of faith? From nobody Tue Jul 12 01:41:06 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5756C12D0EA for ; Tue, 12 Jul 2016 01:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com 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 Gj1dJ7g9VGCC for ; Tue, 12 Jul 2016 01:41:02 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7523B12D0C2 for ; Tue, 12 Jul 2016 01:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=i9da5Mn+vhBIDqVXbqVyAulXsHbNuuHVqHeT25DUFQY=; b=UbTIMjygHJcibxTlqvtkaTDXEWFNT4WXD6vnSqFl7xyfnzhLcEsnpNPDKjP+DVs6ihvTSQJtVSF9YykX+Z3XXdwUF0blI5kaJwVokgO5VR5WzGLRZRbQSUjkWWpQebco0rbwYLsTCoOXcMmZ+xEdxO4L1Uyea7cbRbNCCf00JEI= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp0119.outbound.protection.outlook.com [213.199.154.119]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-4-8xlG4I5cOb2dty5-aVSH7g-1; Tue, 12 Jul 2016 09:40:53 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) with Microsoft SMTP Server (TLS) id 15.1.539.14; Tue, 12 Jul 2016 08:40:52 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.018; Tue, 12 Jul 2016 08:40:52 +0000 From: Tim Chown To: Christian Huitema Thread-Topic: [dnssd] dnssd privacy draft Thread-Index: AQHRza6eF/NmO1yR/UaW0hEx/WMy1Z/5AUUAgBuVyAA= Date: Tue, 12 Jul 2016 08:40:51 +0000 Message-ID: <4CC0A3C2-AF06-41E2-9764-59BE77AAA414@jisc.ac.uk> References: <04a901d1ce4e$52e056e0$f8a104a0$@huitema.net> In-Reply-To: <04a901d1ce4e$52e056e0$f8a104a0$@huitema.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:630:50:d019:505:4049:22d7:a27b] x-ms-office365-filtering-correlation-id: 2397d424-8194-40c6-9327-08d3aa303b5f x-microsoft-exchange-diagnostics: 1; AMSPR07MB455; 20:HJwUJgTWfi6mikHGSA0nJg63FQs6gUiUejnN6Dg6wMk3a+sD7L1Mky2HonG2TsMLp0wNG3PGEdha7OZabveKJ6i+1kZugKoTYkzTYolq2bEb5tP7tMnDRL+c5NAv5MInGKqxN3/VKEXYPul2h1W9nVKSUMO5VMte9yLeqFKuOLY= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB455; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB455; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(51444003)(189002)(24454002)(377454003)(81156014)(81166006)(68736007)(50986999)(19580405001)(102836003)(92566002)(4326007)(8666005)(189998001)(2950100001)(2900100001)(97736004)(6116002)(586003)(15975445007)(76176999)(82746002)(8676002)(57306001)(106356001)(50226002)(101416001)(7736002)(105586002)(106116001)(2906002)(33656002)(87936001)(10400500002)(11100500001)(74482002)(5002640100001)(122556002)(8936002)(19580395003)(36756003)(86362001)(83716003)(77096005)(3280700002)(305945005)(7846002)(3660700001)(110136002)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB455; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <72DD5611CC7785409C58FE234AC97E95@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 08:40:51.8501 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB455 X-MC-Unique: 8xlG4I5cOb2dty5-aVSH7g-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Christian Huitema , "dnssd@ietf.org" , Martin Thomson Subject: Re: [dnssd] dnssd privacy draft X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 08:41:05 -0000 Hi, > On 24 Jun 2016, at 20:26, Christian Huitema wrote: >=20 > On Thursday, June 23, 2016 5:23 PM, Martin Thomson wrote: >>=20 >> Interesting work. >=20 > Thanks. >=20 >> I think that a lot of this comes down to the design of the pairing > protocol. >=20 > Yes. The point is, do we have the appetite to design a pairing protocol i= n > this group? If we do, my preference would be to describe this pairing > protocol in a separate draft. On this, that=92s a question to ask of the WG, but also of our AD. I think = it=92s very important that we tackle privacy issues as and when they arise,= and thus this work is very welcome. I hope that we can attract enough interest to progress it; the initial sign= s are encouraging. Our AD is very happy that we have identified and started= this work. It=92s possible he may feel there is a more appropriate WG to w= ork on the problem. This is something we can discuss in Berlin, but for now= let=92s continue the discussion. I sent a pointer to the work to the ietf-privacy list, which Stephen Farrel= l pointed me to - see https://www.ietf.org/mailman/listinfo/ietf-privacy. I= encouraged people there to join dnssd to discuss the draft further. BTW I noticed another draft that treads in similar space: draft-winfaa-inta= rea-broadcast-consider-02; I have emailed the authors to alert them to our = work in dnssd, as it was not cited in their draft.=20 Tim >> The requirement to use base64 isn't going to work very well with DNS. >> Or do you expect this to work anyway? I guess that it could if you use > the URL >> and filename safe variant without padding, but I wouldn't have been that > bold. >=20 > It is already a requirement for DNS SD. There is a long discussion of tha= t > in RFC 6763: >=20 > The portion of the Service Instance Name is a user- > friendly name consisting of arbitrary Net-Unicode text [RFC5198]. It > MUST NOT contain ASCII control characters (byte values 0x00-0x1F and > 0x7F) [RFC20] but otherwise is allowed to contain any characters, > without restriction, including spaces, uppercase, lowercase, > punctuation -- including dots -- accented characters, non-Roman text, > and anything else that may be represented using Net-Unicode. For > discussion of why the name should be a user-visible, user- > friendly name rather than an invisible machine-generated opaque > identifier, see Appendix C, "What You See Is What You Get". >=20 > Base64 guarantees that we will not be using control characters. I actuall= y > checked whether we could get something more compact using a wider range o= f > Unicode character, but those require more bits on the wire and end up not > very efficient. >=20 >> Using base32 reduces the number of pairings you can advertise at once to > 5; >> which isn't great, but I guess that you can use the mitigation you alrea= dy > have. >> But it begs the question: does this really need to be in the name? Did > you >> consider retrieving the proofs using TXT records that are provisioned > against >> the nonce? >=20 > Yes, that's a possibility. But the instance name is obtained directly fro= m > the PTR record. Putting the information in the TXT record implies a longe= r > query process: first get the PTR records, then retrieve the TXT record fo= r > each name in the PTR record.=20 >=20 >> Do you need to include the time in the nonce? We decided against leakin= g >> clock information in TLS 1.3 for a range of reasons, primarily privacy. = I > believe >> that lots of entropy would be OK. It's not like we need to be very > careful with >> space, and 96 bits seems like plenty. >=20 > Are you saying that specifically for the PSK identity encoding? The use o= f > time stamp there provides some level of protection against replay attacks= , > described in section 6.5. Otherwise, servers will have to rely on extende= d > memory of previously used PSK identifiers. >=20 >> Also, you don't have to base64 the psk_identity, it's just octets, which > allows >> you to reclaim some of that space. >=20 > Well, section 5.1. of RFC4279 says: "The PSK identity MUST be first > converted to a character string, and then encoded to octets using UTF-8 > [UTF8]." And I see the character string requirement enforced in some of t= he > TLS API. So base64 is just a way of being cautious. >=20 >> Did you consider using SNI to carry the name? Or did you plan to forbid > SNI? >> You probably don't need to correlate the DNSSD parts with the TLS parts > for >> passive observers. >=20 > Good point. We should probably specify some fixed SNI value, so the SNI d= oes > not leak server identity. >=20 >> Regarding this: "Implementers MAY eventually replace SHA256 with a > stronger >> algorithm", I think that you need a better replacement plan. >> Maybe you can use an attribute in the TXT record that identifies the has= h. > Or >> you could identify the scheme in the psk_identity itself. >> Or you could prefix names with a protocol version identifier. You could > even >> use a different service type name if it came to that. >=20 > Yes, we need to think about versioning. The simplest solution is probably= to > encode a version number in the service type used by DNS SD. But better > suggestions are welcome. >=20 > -- Christian Huitema >=20 >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd >=20 From nobody Tue Jul 12 04:07:59 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8531412D09B for ; Tue, 12 Jul 2016 04:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com 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 JCHbKYQB32em for ; Tue, 12 Jul 2016 04:07:55 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BAB412D0FB for ; Tue, 12 Jul 2016 04:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YSPx94QHvFE446DU4jSs5G19byj3CqnN6IbrW1K9ReA=; b=a4wOXOtbnMlluBprrzB5BtaWS9fQXUD1+Rfn6Vfdq+fhzF8cH8EZUwieRqxJRuuSLUTRmPv9YJY8waOar9CAypFGoN9hbRjBardWU+Tpr8NAWpw6FipJsz4iTMAejkQCG4rFbbTvfMJjR+ZQmLS7pS3sbsHpcszZAVVjlG6n8tw= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0244.outbound.protection.outlook.com [213.199.154.244]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-63-4-PpZtClOkCxw0_MiGjSOg-1; Tue, 12 Jul 2016 12:07:50 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 12 Jul 2016 11:07:46 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.018; Tue, 12 Jul 2016 11:07:46 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: [dnssd] Any review of Threat model? Thread-Index: AQHR3C2eFdrMiUbnXUWiRNpXpmDCPA== Date: Tue, 12 Jul 2016 11:07:46 +0000 Message-ID: References: <56FFE286.9010304@rozanak.com> <20160404191306.GA36990@anvilwalrusden.com> <5702C4D3.5070500@rozanak.com> <20160404200942.GE36990@mx2.yitter.info> <5702D220.2000501@rozanak.com> <20160404215837.GE37449@mx2.yitter.info> In-Reply-To: <20160404215837.GE37449@mx2.yitter.info> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:630:50:d019:c414:da75:a5ad:b8fd] x-ms-office365-filtering-correlation-id: 308d5bf4-be30-4ffb-2f45-08d3aa44c131 x-microsoft-exchange-diagnostics: 1; AMSPR07MB454; 20:srzRQ9SeJszZbQtc5SXp831tuu8WZxGSRRgJ5XOz4i0LKameiFSz9S24D3KbgOgADhxDVs4w3rWeRhZQWDHGWTMEHNdWxDnQY4azkPcgmozpXef/ifLWVYqvVet/yGvLnsJA7+xzEeYuxYFUuqCjkhSoR6IOxXTmCkVkzVh60+w= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB454; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB454; x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(52314003)(24454002)(199003)(189002)(19580405001)(586003)(19580395003)(5002640100001)(77096005)(2501003)(68736007)(7846002)(57306001)(87936001)(11100500001)(76176999)(50986999)(93886004)(97736004)(106116001)(3660700001)(86362001)(450100001)(305945005)(106356001)(83716003)(92566002)(2950100001)(81156014)(74482002)(5640700001)(2906002)(8676002)(1730700003)(7736002)(6116002)(102836003)(122556002)(101416001)(15975445007)(81166006)(189998001)(105586002)(107886002)(110136002)(33656002)(50226002)(8936002)(10400500002)(82746002)(3280700002)(2351001)(36756003)(2900100001)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB454; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2016 11:07:46.3744 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB454 X-MC-Unique: 4-PpZtClOkCxw0_MiGjSOg-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [dnssd] Any review of Threat model? X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jul 2016 11:07:58 -0000 SGksDQoNCldlIGhhdmUgc29tZSB0aW1lIGF0IHRoZSBlbmQgb2YgdGhlIHNlc3Npb24gaW4gQmVy bGluIHRvIGRpc2N1c3MgdGhlIGZ1dHVyZSBvZiB0aGUgRE5TU0QgVGhyZWF0cyBkcmFmdCwgYXMg cGVyIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1vdGlzLWRuc3NkLXNjYWxhYmxl LWRucy1zZC10aHJlYXRzLTAzDQoNCkF0IHByZXNlbnQsIHRoZXJlIGFyZSBvdXRzdGFuZGluZyB1 bnJlc29sdmVkIGNvbW1lbnRzIGF0IGxlYXN0IGZyb20gQW5kcmV3IFN1bGxpdmFuLCBmcm9tIHRo ZSB0aHJlYWQgYmVsb3csIGFuZCBhcyBhcmNoaXZlZCBpbiB0aGUgbWFpbCBsaXN0IGFyY2hpdmUg YXQgaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL3NlYXJjaC8/ZW1haWxfbGlzdD1k bnNzZCZnYnQ9MSZpbmRleD1ILUJSVUpGY2dfYUJMTXRBM2wzUGZoOENZbnMuDQoNCkRvdWcgaXMg Y3VycmVudGx5IG5vdCBhdmFpbGFibGUgdG8gd29yayBvbiB0aGUgZG9jdW1lbnQsIHNvIGlmIGl0 IGlzIHRvIGJlIHByb2dyZXNzZWQgSG9zbmllaCB3aWxsIGJlIGxvb2tpbmcgZm9yIGFkZGl0aW9u YWwgdm9sdW50ZWVycy4NCg0KQ29tbWVudHMgaW4gYWR2YW5jZSBvZiB0aGUgbWVldGluZyBhcmUg d2VsY29tZS4NCg0KVGltIA0KDQoNCg0KPiBPbiA0IEFwciAyMDE2LCBhdCAyMjo1OCwgQW5kcmV3 IFN1bGxpdmFuIDxhanNAYW52aWx3YWxydXNkZW4uY29tPiB3cm90ZToNCj4gDQo+IEhpLA0KPiAN Cj4gT24gTW9uLCBBcHIgMDQsIDIwMTYgYXQgMTA6NDQ6MTZQTSArMDIwMCwgSG9zbmllaCBSYWZp ZWUgd3JvdGU6DQo+IA0KPj4gVGhlIHRocmVhdCBpcyB0aGUgc2NvcGUgb2YgZGlzY292ZXJ5IHdo ZXJlIGNhdXNlcyB0aGUgc2VydmljZXMgdG8gYmUNCj4+IGF2YWlsYWJsZSB0byB1bndhbnRlZCBk b21haW5zIGFuZCBtb3N0IHBhcnQgb2YgdGhpcyBkcmFmdCBlbXBoYXNpcyBvbiB0aGVzZQ0KPj4g a2luZHMgb2YgdGhyZWF0cy4NCj4gDQo+IFNvLCB0aGVuLCB0d28gdGhpbmdzOg0KPiANCj4gICAg MS4gIEROUy1TRCBkb2VzIG5vdCBpbiBmYWN0IGRvIGFueXRoaW5nIGF0IGFsbCB0byBtYWtlIHRo ZQ0KPiAgICBzZXJ2aWNlcyBhdmFpbGFibGUgb24gdGhlIEludGVybmV0LiAgVGhleSdyZSBhbHJl YWR5IGF2YWlsYWJsZS4NCj4gDQo+ICAgIDIuICBJdCBzb3VuZHMgbGlrZSB5b3VyIGRvY3VtZW50 IGlzIGJldHRlciBkZXNjcmliZWQgYXMsDQo+ICAgICJDb25zZXF1ZW5jZXMgb2YgZXhwb3Npbmcg cHJldmlvdXNseS11bmFubm91bmNlZCBzZXJ2aWNlcyB2aWENCj4gICAgRE5TLVNEIi4gIElmIHRo YXQncyB3aGF0IHlvdSdyZSB0cnlpbmcgdG8gZG8sIHRoZW4gbWFraW5nIHRoYXQNCj4gICAgc2Nv cGUgY3J5c3RhbCBjbGVhciBhdCB0aGUgYmVnaW5uaW5nIChsaWtlIGZvciBpbnN0YW5jZSwgaW4g dGhlDQo+ICAgIGFic3RyYWN0KSB3b3VsZCBiZSBnb29kLg0KPiANCj4gSSBzdGlsbCBiZWxpZXZl IHRoZSBkb2N1bWVudCB3b3VsZCBiZW5lZml0IGZyb20gcmVhbGx5IHNpZ25maWNhbnQNCj4gcmVv cmdhbml6YXRpb24sIGJ1dCBhdCBsZWFzdCBtYWtpbmcgaXRzIGdvYWwgd2F5IGNsZWFyZXIgd291 bGQgaGVscC4NCj4gDQo+PiBETlMuIEJ1dCBJIHF1aXRlIGRpc2FncmVlIHdpdGggeW91IGJlY2F1 c2Ugd2hlbiBpdCBpcyBleHBvc2VkIG9uIGdsb2JhbCBETlMNCj4+IHNlcnZlciwgaXQgY2FuIGdv IGJleW9uZCBldmVuIHRoZSB3YW50ZWQgc2NvcGUgdGhhdCBtaWdodCBiZSBkZWZpbmVkIG9uIGVk Z2UNCj4+IHJvdXRlcnMgYmVjYXVzZSBub3JtYWxseSB0aGUgRE5TIHF1ZXJpZXMgYXJlIG5vdCBm aWx0ZXJlZCBvbiB0aGUgbmV0d29yaw0KPj4gZWRnZSBkZXZpY2VzIGJlY2F1c2Ugb2YgZW5hYmxp bmcgY2xpZW50cyB0byB1c2UgRE5TIHNlcnZpY2VzIG9yIGVuYWJsaW5nDQo+PiBvdXRzaWRlcnMg dG8gcXVlcnkgdGhlIG5hbWVzIG9uIGdsb2JhbCBETlMgc2VydmVycyBpbnNpZGUgdGhlaXIgbmV0 d29ya3MgYW5kDQo+PiBtYXAgbmFtZXMuIFRoYXQgbWVhbnMsIGFueSBleHRlcm5hbCBhdHRhY2tl ciBjYW4gYWxzbyBxdWVyeSB0aGlzIGdsb2JhbCBETlMNCj4+IHNlcnZlciBhbmQgY2FuIHJldHJl aXZlIHRoZSBuYW1lIG9mIHNlcnZpY2VzLg0KPiANCj4gU28sIEROUy1TRCBpcyBhYm91dCBzZXJ2 aWNlIGRpc2NvdmVyeS4gIFNvIGl0J3Mgbm90IHRvbyBzdXJwcmlzaW5nDQo+IHRoYXQgc2Vydmlj ZXMgdGhhdCBhcmUgYWxyZWFkeSBhdmFpbGFibGUgYXJlIGVhc2llciB0byBkaXNjb3ZlciB3aGVu DQo+IEROUy1TRCBpcyBpbiB1c2UuICBUaGF0IGFjdHVhbGx5IGRvZXMgc3RyaWtlIG1lIGFzIGEg cG90ZW50aWFsbHkNCj4gdXNlZnVsIHBvaW50IHRvIG1ha2UuDQo+IA0KPj4gT3VyIG1vc3QgZW1w aGFzaXMgd2FzIG9uIGhvbWVuZXQgc2VydmljZXMuIHRoYXQgbWVhbnMgdGhlIGdsb2JhbCBETlMg c2VydmVyDQo+PiBmb3IgaG9tZW5ldCBpcyBzb21ld2hlcmUgb24gSVNQcyBhbmQgbm90IGluc2lk ZSB0aGUgZW50ZXJwcmlzZS4NCj4gDQo+IE9yIGluIHRoZSBob3VzZSwgb3Igd2hhdGV2ZXIuIEFG QUlLLCBIT01FTkVUIGhhc24ndCBldmVuIGVzdGFibGlzaGVkDQo+IHRoZSBhcmNoaXRlY3R1cmUg Zm9yIHRoaXMgeWV0Lg0KPiANCj4+IGFsbCB0aGUgdXNlcnMgb2YgdGhhdCBJU1BzIGNhbiBhY2Nl c3MgdGhlIHNlcnZpY2VzIG9mIG90aGVyIHVzZXJzIGluIHRoYXQNCj4+IElTUHMgYXMgd2VsbCBh cyBleHRlcm5hbCBwZW9wbGUuDQo+IA0KPiBUaGF0IGRvZXNuJ3QgZm9sbG93IGF0IGFsbC4gIFRo ZXJlIGFyZSBfbG90c18gb2YgbmFtZWQgc2VydmljZXMgaW4gbXkNCj4gaG9tZSBuZXQgdGhhdCB5 b3UgY2FuJ3QgYWNjZXNzLCBiZWNhdXNlIGlmIHlvdSB0cnkgSSdsbCBkcm9wIHlvdXINCj4gcGFj a2V0cyBhdCB0aGUgZWRnZSBvZiBteSBuZXR3b3JrLiAgTWVyZWx5IGtub3dpbmcgdGhlIG5hbWUg b2YNCj4gc29tZXRoaW5nIGRvZXMgbm90IGd1YXJhbnRlZSBhY2Nlc3MuDQo+IA0KPiBOb3csIGtu b3dpbmcgdGhlIG5hbWUgb2Ygc29tZXRoaW5nIF9pc18ga25vd2luZyBzb21ldGhpbmcgdGhhdA0K PiBwcmV2aW91c2x5IG9uZSBtaWdodCBub3QgaGF2ZSBrbm93biBhYm91dC4gIEFuZCBpZiB0aGUg dGhpbmcgaXMNCj4gdW5zZWN1cmVkLCBpdCBpcyBvZiBjb3Vyc2UgYWNjZXNzaWJsZSB0b28uICBH aXZlbiB0aGF0IHRoZSB3aG9sZSBwb2ludA0KPiBpcyByZW1vdGUgYWNjZXNzLCBob3dldmVyLCBJ IGNhbid0IHNlZSBob3cgdGhlIHJpZ2h0IGFuc3dlciB0byB0aGF0DQo+IGlzLCAiRG9uJ3QgcGVy bWl0IHNlcnZpY2UgZGlzY292ZXJ5LiIgIFRoZSBfd2hvbGUgcG9pbnRfIGlzIHNlcnZpY2UNCj4g ZGlzY292ZXJ5Lg0KPiANCj4+IEluIG90aGVyIHdvcmQsIGl0IGlzIG5vdCBvbmx5IHlvdXIgZmls ZXNlcnZlciB0aGF0IGlzIGF2YWlsYWJsZQ0KPj4gdG8geW91IG92ZXIgZ2xvYmFsIEROUyBzZXJ2 ZXIgYnV0IGFsc28gdG8gYW55b25lIGVsc2UgaW4gdGhlIHdvcmxkLg0KPiANCj4gV2VsbCwgeWVz LiAgT2YgY291cnNlLiAgUHJlc3VtYWJseSB0aGlzIGlzIHdoYXQgYXV0aGVudGljYXRpb24gYW5k DQo+IGF1dGhvcml6YXRpb24gaXMgZm9yLg0KPiANCj4+IFRoaXMgaXMNCj4+IHdoeSBpbiBkcmFm dCB3ZSBjbGVhcmx5IHNhaWQgdGhhdCAuaG9tZSBkb21haW5zICh0aGF0IGFyZSBvbiBnb2luZw0K Pj4gZGlzY3Vzc2lvbiBpbiBob21lbmV0IGdyb3Vwcykgc2hvdWxkIGJlIHJlc3RyaWN0ZWQgdG8g dXNlIGdsb2JhbCBETlMgc2VydmVyLg0KPiANCj4gVGhpcyBpcyBhIGNvbXBsZXRlbHkgZGlmZmVy ZW50IGlzc3VlLCB1bnJlbGF0ZWQgdG8gYW55IG9mIHRoZSBhYm92ZS4NCj4gKEEgZ2xvYmFsbHkt YW1iaWd1b3VzIG5hbWUgYWtpbiB0byBSRkMgMTkxOCBhZGRyZXNzZXMgaXMgbm90IG9idmlvdXNs eQ0KPiBhIGdvb2QgaWRlYSBhbnl3YXksIGJ1dCByZWdhcmRsZXNzIGl0cyBmdW5jdGlvbmluZyBp biB0aGUgZ2xvYmFsIEROUw0KPiBpcyBib3VuZCB0byBiZSBvYnNjdXJlLikNCj4gDQo+PiBZb3Ug Y2FuLCBvZiBjb3Vyc2UsIGRlZmluZSBpdCBhcyBwb2xpY3kuICBJbiBteSB1bmRlcnN0YW5kaW5n LCB0aGlzIHBvbGljeQ0KPj4gaXMgYSAgcGFydCBvZiB0aGUgcHJvdG9jb2wNCj4gDQo+IEkgdGhp bmsgeW91ciB1bmRlcnN0YW5kaW5nIGlzIHF1aXRlIG1pc3Rha2VuLiAgVGhlcmUgaXMgbm90aGlu ZyBpbg0KPiBJRE5BIHRvIHByZXZlbnQgYSBzaW5nbGUgbGFiZWwgaGF2aW5nIGluIGl0ICJhIiAo VSswMDYxKSBhbmQgItCwIg0KPiAoVSswNDMwKS4gIFRoZXkncmUgYm90aCBQVkFMRC4gIEkga25v dyBvZiBubyBjb25zdW1lci1ncmFkZSBzb2Z0d2FyZQ0KPiBpbiB0aGUgd29ybGQgdGhhdCBkb2Vz bid0IHVzZSB0aGUgdmVyeSBzYW1lIGJpdHMgb24gdGhlIHNjcmVlbiB0bw0KPiByZW5kZXIgdGhv c2UgdHdvIGNoYXJhY3RlcnMuICBUaGV5J3JlIGFzIGNvbmZ1c2FibGUgYXMgY2FuIHBvc3NpYmx5 DQo+IGJlLCBhbmQgdGhlcmUgaXMgbm90aGluZyB3aGF0c29ldmVyIGluIGFueSBwcm90b2NvbCB0 byBwcmV2ZW50IHRoZW0NCj4gYmVpbmcgdXNlZCBpbiBhIHdheSB0aGF0IGlzIHBvc3NpYmx5IGNv bmZ1c2luZyB0byB1c2Vycy4NCj4gDQo+PiBkZWZpbml0aW9uIG9mIHVzaW5nIHN1Y2ggY2FwYWNp dHkgZm9yIEROU1NEIHByb3RvY29sLiBJbiBvdGhlciB3b3JkLCB0aGUNCj4+IHBvc3NpYmxlIHBy b2JsZW1zIGFyaXNlcyBvbiBETlNTRCBzZXJ2aWNlcyBieSB1c2luZyB2YXJpZXR5IG9mIGxvb2sg YWxpa2UNCj4+IG5hbWVzIHRoYXQgbmVlZCB0byBiZSB0YWtlIGludG8gY29uc2lkZXJhdGlvbiB0 aGF0IGF0IHRoZSBtb21lbnQgaXQgaXMgbm90Lg0KPiANCj4gU28sIGFuZHJld3MtbGFwdG9wLmxv Y2FsLiBhbmQg0LBuZHJld3MtbGFwdG9wLmxvY2FsIGV4aGliaXQgdGhpcw0KPiBwcm9ibGVtLCBJ IGFncmVlLiAgKFRoZSBzZWNvbmQgb2YgdGhvc2UgaGFzIHRoZSBDeXJpbGxpYyAiYSIgaW4gaXQu KQ0KPiANCj4gQ2VydGFpbmx5LCBhbnZpbHdhbHJ1c2Rlbi5jb20gYW5kINCwbnZpbHdhbHJ1c2Rl bi5jb20gaGF2ZSB0aGUgc2FtZQ0KPiBwcm9ibGVtLiAgKEFnYWluLCBzZWNvbmQgb25lIGlzIEN5 cmlsbGljIC0tDQo+IHhuLS1udmlsd2FscnVzZGVuLXYxay5jb20pLiAgRm9ydHVuYXRlbHkgZm9y IHVzLCBWZXJpc2lnbiBkb2Vzbid0DQo+IHBlcm1pdCBkb21haW4gbmFtZXMgb2YgdGhlIHNlY29u ZCBmb3JtIChiZWNhdXNlIHRoZSBVLWxhYmVsDQo+ICLQsG52aWx3YWxydXNkZW4iIGlzIG5vdCBh bGwgaW4gb25lIHNjcmlwdCkuICBUaGlzIGlzIGEgcG9saWN5IHRoYXQgVmVyaXNpZ24gaGFzLg0K PiANCj4gVGhlcmUgaXMsIGhvd2V2ZXIsIG5vdGhpbmcgYXQgYWxsIGluIFZlcmlzaWduJ3MgcG9s aWN5IHRvIHByZXZlbnQgbWUNCj4gZnJvbSBjcmVhdGluZyDQsG5kcmV3cy1sYXB0b3AuYW52aWx3 YWxydXNkZW4uY29tDQo+ICh4bi0tbmRyZXdzLWxhcHRvcC12MWsuYW52aWx3YWxydXNkZW4uY29t KS4gIEFuZCB0aGVyZSdzIG5vdGhpbmcgaW4NCj4gdGhlIHByb3RvY29sIHRvIHByZXZlbnQgaXQu ICBJZiB5b3Ugd2FudCB0byBzYXksICJNaXhlZCBzY3JpcHQgbGFiZWxzDQo+IGFyZSBub3QgYWxs b3dlZCBhbnl3aGVyZSBpbiB0aGUgRE5TLCIgSSB0aGluayB5b3UncmUgZ29pbmcgdG8gaGF2ZQ0K PiBzb21lIHB1c2gtYmFjay4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gDQo+IEENCj4gDQo+IC0t IA0KPiBBbmRyZXcgU3VsbGl2YW4NCj4gYWpzQGFudmlsd2FscnVzZGVuLmNvbQ0KPiANCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZG5zc2QgbWFp bGluZyBsaXN0DQo+IGRuc3NkQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vZG5zc2QNCg0K From nobody Wed Jul 13 08:38:21 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E5B912D198 for ; Wed, 13 Jul 2016 08:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com 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 aGK_y-YmwNWp for ; Wed, 13 Jul 2016 08:38:17 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44CAD12D0A4 for ; Wed, 13 Jul 2016 08:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GPlyOkRFce2pcJ4YDLv5rT1AdtejoNhHLSOK5IeK8X0=; b=G+JL7C4zc+1cobu58ECo2CWtFau2BQE+8vweUyuvLZnW7aESPQIPNNPYoc/qVO102RAnM0srSY177aaJY4ErNzqlnBpi3D15T5pBErSm4OIMlALRuvRPeEDCxlrEZQQpg1VIWmVSiZda8qTXVsqmVzdayCnYrq0I5wG/1IRaICg= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0245.outbound.protection.outlook.com [213.199.154.245]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-66-2syqLwCXOhyiqSQJZW6iiQ-1; Wed, 13 Jul 2016 16:38:10 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) with Microsoft SMTP Server (TLS) id 15.1.534.14; Wed, 13 Jul 2016 15:38:09 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.019; Wed, 13 Jul 2016 15:38:09 +0000 From: Tim Chown To: S Moonesamy Thread-Topic: [dnssd] [ietf-privacy] Fwd: draft-huitema-dnssd-privacy-01.txt Thread-Index: AQHRzIBAoMNfpY+lJEaMq17yQ9FD5Z/20ReAgACWhACAE48GAIALqbgA Date: Wed, 13 Jul 2016 15:38:09 +0000 Message-ID: <8175785E-C12F-4FD8-A0FD-D1960B45FDA2@jisc.ac.uk> References: <6.2.5.6.2.20160623020221.0b6b9df0@resistor.net> <001501d1cd80$4f885de0$ee9919a0$@huitema.net> <6.2.5.6.2.20160705220136.0afbc258@resistor.net> In-Reply-To: <6.2.5.6.2.20160705220136.0afbc258@resistor.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: 2f7ad92e-6eec-4677-6df0-08d3ab33b11f x-microsoft-exchange-diagnostics: 1; AMSPR07MB454; 20:gv5Qy+05AVF5wn0WPgBEJGjJsNoBV2ylDnbZaGDIAvUucoXWwbeBShBOXhb9KUpMglDlcha+OmWQZDl4CNreT4Rj9FgKTWuPOd3OTbgZ2XtX1m6z1HJ5JRKkzc+QRPMavkq1TX1/5kRsXafgUe1qcY441d3Lqs50tqI71UQJC1g= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB454; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB454; x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(377424004)(52164004)(199003)(189002)(2473001)(5002640100001)(2900100001)(82746002)(81166006)(11100500001)(105586002)(7736002)(74482002)(97736004)(19580405001)(189998001)(2950100001)(8676002)(110136002)(2906002)(81156014)(10400500002)(7846002)(305945005)(101416001)(106356001)(68736007)(106116001)(3280700002)(87936001)(3846002)(92566002)(8936002)(50226002)(86362001)(3660700001)(6116002)(77096005)(230783001)(83716003)(102836003)(36756003)(586003)(4326007)(76176999)(561944003)(122556002)(19580395003)(66066001)(50986999)(33656002)(57306001)(93886004)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB454; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 15:38:09.2020 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB454 X-MC-Unique: 2syqLwCXOhyiqSQJZW6iiQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dnssd@ietf.org" , Christian Huitema Subject: Re: [dnssd] [ietf-privacy] Fwd: draft-huitema-dnssd-privacy-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 15:38:19 -0000 Hi, > On 6 Jul 2016, at 06:32, S Moonesamy wrote: >=20 > Hi Christian, > At 11:51 23-06-2016, Christian Huitema wrote: >> Section 3 describes an initial design that was then abandoned. I guess t= hat >> in the next revision we could just remove that section entirely. >>=20 >> On the other hand, the proposal was indeed to use different obfuscated n= ames >> at different locations. >=20 > Ok. >=20 >> The private discovery service relies on pre-existing pairings. The pairi= ng >> solutions are only drafted in very vague terms in the draft. I really wo= nder >> whether we should go define a complete pairing protocol. Is that in-char= ter >> for DNS-SD? What about competing with existing solutions over Bluetooth, >> Wi-Fi, and certainly many more? >=20 > I'll leave the in-charter question to the WG Chairs. :-) I assume that t= he last question in similar to what is in Section 5.2. I haven't looked at= the existing solutions to provide a useful answer. I may have said this already, but we=92ll discuss this at the dnssd WG sess= ion next Wednesday. Our AD has explicitly said that privacy considerations= are in scope (and should be in all WGs :) but we will need to have the con= versation with the WG and the AD about the best place to proceed with the w= ork, and about getting critical mass to ensure it completes (I=92d assume C= hristian and Daniel would welcome all help=85). Best wishes, Tim From nobody Wed Jul 13 08:42:40 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF74712D125 for ; Wed, 13 Jul 2016 08:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com 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 ZFjqep8KkI2f for ; Wed, 13 Jul 2016 08:42:36 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A74C12B011 for ; Wed, 13 Jul 2016 08:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sqxvU8AuEW/Whe4quPJaIFRJnjhYgIjfiSfRkJS+B1A=; b=c9fnGdSBHDJF7X9yAU+EClU9g/NrKnHoIYAvKatrZj2n/gH4dnB0Rb25ovZC1Td2qgXACUMulJJcvWYEi4wWV2RBmvhhPWwJQ/lOLE3TB1mXb8JtJ5XOVpOIoaKhiBmc+Rn/UoAClUIQ6Iwsu7ecaqNIK57FCGrgGBu8cVZkWBI= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0175.outbound.protection.outlook.com [213.199.154.175]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-21-r3PI7gkYPWmasFfjgmru9w-1; Wed, 13 Jul 2016 16:42:32 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Wed, 13 Jul 2016 15:42:31 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.019; Wed, 13 Jul 2016 15:42:31 +0000 From: Tim Chown To: "dnssd@ietf.org" , Dave Thaler Thread-Topic: [dnssd] draft-ietf-dnssd-mdns-dns-interop-03 - about to ship to IESG Thread-Index: AQHR1eSjvIxJbaZZSUK4iB/1ZZ+fyaAWjseA Date: Wed, 13 Jul 2016 15:42:31 +0000 Message-ID: References: <20160703165133.9328.22022.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: 20dab0fd-49c4-40c1-cc87-08d3ab344d3e x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 20:96rnQoho+qW84hJSkqBFJ9wfT8RIcDlZDQbjS/1twmVFtmP48s/Oa1Xw1mg2eCiKXkCg2I71JsV2jNmlg1Y1slNS95wCOE1ctgHZU3QAlotAGOay5l+LgntKAN7kISAhyxAPHQnQ42vr99SjXTS5YNWmkuf4qTEs1d/9jhZT9e4= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(7916002)(377424004)(66654002)(24454002)(199003)(189002)(2950100001)(2900100001)(5002640100001)(15975445007)(86362001)(68736007)(106356001)(106116001)(5001770100001)(76176999)(122556002)(50986999)(105586002)(83716003)(97736004)(3660700001)(74482002)(8666005)(57306001)(2561002)(87936001)(10400500002)(7846002)(189998001)(66066001)(36756003)(7736002)(82746002)(81156014)(2421001)(77096005)(11100500001)(305945005)(230783001)(8676002)(3280700002)(1511001)(50226002)(107886002)(19580405001)(586003)(33656002)(81166006)(3846002)(6116002)(2501003)(92566002)(8936002)(102836003)(2906002)(19580395003)(101416001)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2016 15:42:31.0681 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-MC-Unique: r3PI7gkYPWmasFfjgmru9w-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [dnssd] draft-ietf-dnssd-mdns-dns-interop-03 - about to ship to IESG X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jul 2016 15:42:39 -0000 SGksDQoNCkJ5IHdheSBvZiB1cGRhdGUsIFN1emFubmUgV29vbGYgaGFzIGtpbmRseSBhZ3JlZWQg dG8gd3JpdGUgdGhlIGRvY3VtZW50IHNoZXBoZXJkIHJlcG9ydCBmb3IgdGhpcywgd2hpY2ggd2Ug d2lsbCB0aGVuIHBhc3MgdXAgdG8gdGhlIElFU0cuDQoNCkJlc3Qgd2lzaGVzLA0KVGltIA0KDQo+ IE9uIDQgSnVsIDIwMTYsIGF0IDEyOjEwLCBUaW0gQ2hvd24gPFRpbS5DaG93bkBqaXNjLmFjLnVr PiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gRmlyc3QsIG1hbnkgdGhhbmtzIHRvIEFuZHJldyBm b3Igc3VibWl0dGluZyB0aGlzIHVwZGF0ZSBpbiBhZHZhbmNlIG9mIEZyaWRheeKAmXMgY3V0LW9m Zi4NCj4gDQo+IFJhbHBoIGFuZCBJIHBsYW4gdG8gc3VibWl0IHRoaXMgcmV2aXNlZCBkcmFmdCB0 byB0aGUgSUVTRyB0aGlzIHdlZWsuIElmIHRoZXJlIGFyZSBhbnkgZnVydGhlciBjb21tZW50cywg dGhlc2Ugd291bGQgYmUgd2VsY29tZWQuDQo+IA0KPiBGb3IgdGhvc2UgaW50ZXJlc3RlZCBpbiB0 aGUgc3BlY2lmaWNzIG9mIHRoZSBjbGFyaWZpY2F0aW9ucyBhcHBsaWVkIGluIHRoZSBuZXcgdGV4 dCwgcGxlYXNlIHZpZXcgdGhlIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiwgZm9yIHdo aWNoIHlvdeKAmWxsIHNlZSB0aHJlZSBzbWFsbCBhZGRpdGlvbmFsIGNodW5rcyBvZiB0ZXh0IGFk ZGVkLCBhbW9uZ3N0IHRoZSBvdGhlciBlZGl0czoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtZG5zc2QtbWRucy1kbnMtaW50ZXJvcC0wMyANCj4gDQo+IENv bW1lbnRzIHJlaW5mb3JjaW5nIHRoYXQgaXQncyBub3cgcmVhZHkgdG8gc2hpcCBhcmUgYWxzbyB3 ZWxjb21lLg0KPiANCj4gVGltIA0KPiANCj4+IE9uIDMgSnVsIDIwMTYsIGF0IDE3OjUxLCBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+PiANCj4+IA0KPj4gQSBOZXcgSW50ZXJuZXQt RHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVj dG9yaWVzLg0KPj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgRXh0ZW5zaW9ucyBm b3IgU2NhbGFibGUgRE5TIFNlcnZpY2UgRGlzY292ZXJ5ICBvZiB0aGUgSUVURi4NCj4+IA0KPj4g ICAgICAgVGl0bGUgICAgICAgICAgIDogT24gSW50ZXJvcGVyYXRpb24gb2YgTGFiZWxzIEFtb25n IENvbnZlbnRpb25hbCBETlMgYW5kIE90aGVyIFJlc29sdXRpb24gU3lzdGVtcw0KPj4gICAgICAg QXV0aG9yICAgICAgICAgIDogQW5kcmV3IFN1bGxpdmFuDQo+PiAJRmlsZW5hbWUgICAgICAgIDog ZHJhZnQtaWV0Zi1kbnNzZC1tZG5zLWRucy1pbnRlcm9wLTAzLnR4dA0KPj4gCVBhZ2VzICAgICAg ICAgICA6IDEyDQo+PiAJRGF0ZSAgICAgICAgICAgIDogMjAxNi0wNy0wMw0KPj4gDQo+PiBBYnN0 cmFjdDoNCj4+ICBEZXNwaXRlIGl0cyBuYW1lLCBETlMtQmFzZWQgU2VydmljZSBEaXNjb3Zlcnkg Y2FuIHVzZSBuYW1pbmcgc3lzdGVtcw0KPj4gIG90aGVyIHRoYW4gdGhlIERvbWFpbiBOYW1lIFN5 c3RlbSB3aGVuIGxvb2tpbmcgZm9yIHNlcnZpY2VzLg0KPj4gIE1vcmVvdmVyLCB3aGVuIGl0IHVz ZXMgdGhlIEROUywgRE5TLUJhc2VkIFNlcnZpY2UgRGlzY292ZXJ5IHVzZXMgdGhlDQo+PiAgZnVs bCBjYXBhYmlsaXR5IG9mIEROUywgcmF0aGVyIHRoYW4gdXNpbmcgYSBzdWJzZXQgb2YgYXZhaWxh YmxlDQo+PiAgb2N0ZXRzLiAgSW4gb3JkZXIgZm9yIEROUy1TRCB0byBiZSB1c2VkIGVmZmVjdGl2 ZWx5IGluIGVudmlyb25tZW50cw0KPj4gIHdoZXJlIG11bHRpcGxlIGRpZmZlcmVudCBuYW1lIHN5 c3RlbXMgYW5kIGNvbnZlbnRpb25zIGZvciB0aGVpcg0KPj4gIG9wZXJhdGlvbiBhcmUgaW4gdXNl LCBpdCBpcyBpbXBvcnRhbnQgdG8gYXR0ZW5kIHRvIGRpZmZlcmVuY2VzIGluIHRoZQ0KPj4gIHVu ZGVybHlpbmcgdGVjaG5vbG9neSBhbmQgb3BlcmF0aW9uYWwgZW52aXJvbm1lbnQuICBUaGlzIG1l bW8NCj4+ICBwcmVzZW50cyBhbiBvdXRsaW5lIG9mIHRoZSByZXF1aXJlbWVudHMgZm9yIHNlbGVj dGlvbiBvZiBsYWJlbHMgZm9yDQo+PiAgY29udmVudGlvbmFsIEROUyBhbmQgb3RoZXIgcmVzb2x1 dGlvbiBzeXN0ZW1zIHdoZW4gdGhleSBhcmUgZXhwZWN0ZWQNCj4+ICB0byBpbnRlcm9wZXJhdGUg aW4gdGhpcyBtYW5uZXIuDQo+PiANCj4+IA0KPj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVz IHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1pZXRmLWRuc3NkLW1kbnMtZG5zLWludGVyb3AvDQo+PiANCj4+IFRoZXJlJ3Mg YWxzbyBhIGh0bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KPj4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG5zc2QtbWRucy1kbnMtaW50ZXJvcC0wMw0KPj4gDQo+ PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+PiBo dHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1kbnNzZC1tZG5zLWRu cy1pbnRlcm9wLTAzDQo+PiANCj4+IA0KPj4gUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KPj4gdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCj4+IA0KPj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Og0KPj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4+ IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4+IEktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KPj4g aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCj4+IElu dGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s DQo+PiBvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KPiANCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZG5zc2Qg bWFpbGluZyBsaXN0DQo+IGRuc3NkQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vZG5zc2QNCg0K From nobody Thu Jul 14 09:04:55 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96AE12D155 for ; Thu, 14 Jul 2016 09:04:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com 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 kxzdlPhcVGiX for ; Thu, 14 Jul 2016 09:04:51 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4215412D14B for ; Thu, 14 Jul 2016 09:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Mf4lrk5pHBTdAxM6ubtbApnhDRAxDGtzhLmAZwmnq88=; b=NOh2W1cabmux6mmCui4gY9YfVCZQyPysES9D9K1jHx9JfM12Ez4JkzkAUloEIrzCMpWbGE/JT3FPxU6ozxo9Hr97ishVmeuEkK1CFbJWc1mSa7UQTxWVbJNtEXG17ubFnXeLcLy3trR+XALU2OH32zlt93N+x/JzQzz4cuq21GU= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0243.outbound.protection.outlook.com [213.199.154.243]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-61-7XWeGVBKMDKd8SClw0kkXQ-1; Thu, 14 Jul 2016 17:04:47 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) with Microsoft SMTP Server (TLS) id 15.1.539.14; Thu, 14 Jul 2016 16:04:46 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.019; Thu, 14 Jul 2016 16:04:46 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: DNS Push work Thread-Index: AQHR3elwbMMJgwW7hkWvPNPzOMXepQ== Date: Thu, 14 Jul 2016 16:04:46 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:d122:9300:34b9:b8c7] x-ms-office365-filtering-correlation-id: a4b7bfb7-84a2-4d89-e288-08d3ac00936a x-microsoft-exchange-diagnostics: 1; AMSPR07MB455; 20:I37G9QwuyDTWGK3PJF4cKOgUffn8kna6WT7vq3OxzQLLisFI71gIWpRxxOTVUo2+Vk9tsLkv8bKFtUxxkVooS0/h0xuHXx7ME5HLPyBtLP/taMOTD5Lc5XArF7khOFOtWLlsrA6CNOHPlA7ZPU5k+ZAsv30K9rdacW/Vs/CevVs= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB455; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB455; x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(305945005)(82746002)(189998001)(105586002)(68736007)(36756003)(2501003)(7846002)(8936002)(3480700004)(3660700001)(106116001)(106356001)(50226002)(92566002)(57306001)(122556002)(81156014)(7736002)(81166006)(450100001)(229853001)(33656002)(77096005)(74482002)(87936001)(110136002)(2900100001)(8676002)(1730700003)(2351001)(5002640100001)(5640700001)(86362001)(50986999)(107886002)(586003)(101416001)(6116002)(102836003)(11100500001)(2906002)(10400500002)(3280700002)(97736004)(83716003)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB455; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <236FC694B1395E40ADD60086732A6262@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jul 2016 16:04:46.1173 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB455 X-MC-Unique: 7XWeGVBKMDKd8SClw0kkXQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [dnssd] DNS Push work X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jul 2016 16:04:53 -0000 Hi, As previously mentioned, and agreed at IETF95, the DNS Push work is being s= plit into two parts, the subscription part, and the signalling part. A firs= t version of the signalling part has been published as draft-bellis-dnsop-s= ession-signal-00, and will be discussed in the dnsop WG at Berlin on Monday= , given we agreed that dnsop will be responsible for the document. Comments may be relayed in the dnsop session or posted to the dnsop WG list= . I would expect the authors will also field comments here, if necessary. Best wishes, Tim=20 From nobody Wed Jul 20 06:22:39 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964AB12D5F8 for ; Wed, 20 Jul 2016 06:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 a4X33-_kPz7v for ; Wed, 20 Jul 2016 06:22:29 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 3D28412D66E for ; Wed, 20 Jul 2016 06:22:28 -0700 (PDT) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u6KDJVhj014609 for ; Wed, 20 Jul 2016 09:22:27 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049463.ppops.net-00191d01. with ESMTP id 24a96777hn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 20 Jul 2016 09:22:27 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u6KDMRXT000769 for ; Wed, 20 Jul 2016 09:22:27 -0400 Received: from alpi131.aldc.att.com (alpi131.aldc.att.com [130.8.218.69]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u6KDMLoR000646 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 20 Jul 2016 09:22:22 -0400 Received: from GAALPA1MSGHUBAB.ITServices.sbc.com (GAALPA1MSGHUBAB.itservices.sbc.com [130.8.218.151]) by alpi131.aldc.att.com (RSA Interceptor) for ; Wed, 20 Jul 2016 13:22:07 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.74]) by GAALPA1MSGHUBAB.ITServices.sbc.com ([130.8.218.151]) with mapi id 14.03.0294.000; Wed, 20 Jul 2016 09:22:07 -0400 From: "STARK, BARBARA H" To: "dnssd@ietf.org" Thread-Topic: Setting device friendly names Thread-Index: AdHiibYrxB4vZWkMQdmCvDMGAtoHug== Date: Wed, 20 Jul 2016 13:22:06 +0000 Message-ID: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-ID: <38174CA541F4BF4892A25E8D4FDCFB5E@LOCAL> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-20_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=4 spamscore=4 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607200153 Archived-At: Subject: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 13:22:37 -0000 In my experience, many devices already support mechanisms for friendly name= acquisition. Many devices, including PCs, ask for names during setup. Othe= rs support UPnP friendly name service. Others have UIs to allow naming. Wha= t I really want (as a user) is for the device to have the same name in all = contexts. So if it's been named, through whatever means, use that name. Whi= ch to me says we don't need a new standard for remote naming that all devic= es must support.=20 Barbara= From nobody Wed Jul 20 06:32:13 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB2212D626 for ; Wed, 20 Jul 2016 06:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 owKXiBumsugg for ; Wed, 20 Jul 2016 06:32:09 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 1571D12D643 for ; Wed, 20 Jul 2016 06:32:09 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id f93so38419953lfi.2 for ; Wed, 20 Jul 2016 06:32:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JSvrLmaqFS0ItnPPYxYdZfOGQsQkzUm+YtsA0pgBo68=; b=V7sU0JogwaahwpljtoNgoU2JM9lbHxdek5yLJQ0e3uiQyLdwe1WQIkEIyfbcjW1SLc L3jujRNq/fcwgF6EBJ9ejqqyb1/ohuVV7dMXatO8AaHiVeU8x+LfQHv/pghCvec2TX91 lSh4sIU+OvUfNUfcvadROvMnhoZUi2iTai6PPAH4fmdNBHeB2Q3mi5ZXoemKqo1iqTey iAVY8NT5jXHqlkMBa9xuKZfxOBs1xWH+9RoDjBXuMZMzCG6ai3ueW7CtqdXSIUSMc0LV lNDoHkhuLzZ9k/y+/3WiybDwsP+I/CpjOxLHrcDCHJWIlN92DTupAnun8kWWWjGIiaGD D/kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JSvrLmaqFS0ItnPPYxYdZfOGQsQkzUm+YtsA0pgBo68=; b=XOTM4HAWuDIFJwx6GSs+fc5ow8BFUiXPBm0iy/Z3QYG4cPCIaPUQ0Erlfw/eDgThBB gec+eCdOfqOIxg+7qoZ6Z2oXm58JYJbPjwWNFpenw+j8pwEJmTjXrSwIyq4yyu788oQm GIG/OIVo6NqJ2Lv4nMxyfBacP0+8HANPPuPwLnn1XHzXW1MUCkjPal/XJkBfg5MbPKC6 Vt9FM9tEyl0YzYtyiKaoIqsT6hKsc5Mbw35StrNEfKINCm6OxjB9hqqfMagqXbl114br 7RuQ9Yn/Sh9uYDGC5eKiUGKSIUK6rYN7phm1wC7SVLrMwlu5/MkgFPmIZoPWtd7ZTF7l sUYA== X-Gm-Message-State: ALyK8tJMv12cL+cMZ3Wbob0Ki9WQ7HgPLVSyQHwcbpQrryXYeZyUZYBUZMPWoq6CyuicwndT9/fVeK0Juzbw1w== X-Received: by 10.25.159.10 with SMTP id i10mr9679173lfe.131.1469021527248; Wed, 20 Jul 2016 06:32:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.219 with HTTP; Wed, 20 Jul 2016 06:31:27 -0700 (PDT) In-Reply-To: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> From: Ted Lemon Date: Wed, 20 Jul 2016 15:31:27 +0200 Message-ID: To: "STARK, BARBARA H" Content-Type: multipart/alternative; boundary=001a11411c424caacd0538113a4e Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 13:32:11 -0000 --001a11411c424caacd0538113a4e Content-Type: text/plain; charset=UTF-8 Can you talk more about this UPnP thing? Bear in mind that UPnP is not a standard, AFAIK, although its follow-on, PCP, is. I don't know that PCP has this feature. The fact that some devices have UIs that users may or may not be able to find does not mean that there needn't be a standard way to do it. Maybe we don't need it, but if we don't, that's not the reason. On Wed, Jul 20, 2016 at 3:22 PM, STARK, BARBARA H wrote: > In my experience, many devices already support mechanisms for friendly > name acquisition. Many devices, including PCs, ask for names during setup. > Others support UPnP friendly name service. Others have UIs to allow naming. > What I really want (as a user) is for the device to have the same name in > all contexts. So if it's been named, through whatever means, use that name. > Which to me says we don't need a new standard for remote naming that all > devices must support. > Barbara > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --001a11411c424caacd0538113a4e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you talk more about this UPnP thing? =C2=A0 Bear in mi= nd that UPnP is not a standard, AFAIK, although its follow-on, PCP, is. =C2= =A0 I don't know that PCP has this feature.

The fact= that some devices have UIs that users may or may not be able to find does = not mean that there needn't be a standard way to do it. =C2=A0 Maybe we= don't need it, but if we don't, that's not the reason.

On Wed, Jul 20, 2016 = at 3:22 PM, STARK, BARBARA H <bs7652@att.com> wrote:
In my experience, many devices already support mech= anisms for friendly name acquisition. Many devices, including PCs, ask for = names during setup. Others support UPnP friendly name service. Others have = UIs to allow naming. What I really want (as a user) is for the device to ha= ve the same name in all contexts. So if it's been named, through whatev= er means, use that name. Which to me says we don't need a new standard = for remote naming that all devices must support.
Barbara
_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

--001a11411c424caacd0538113a4e-- From nobody Wed Jul 20 08:38:12 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00BCF12D7C6 for ; Wed, 20 Jul 2016 08:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=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 fLP6xI3QKx3F for ; Wed, 20 Jul 2016 08:38:09 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0095.outbound.protection.outlook.com [104.47.33.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2DA12D78A for ; Wed, 20 Jul 2016 08:38:07 -0700 (PDT) Received: from DF4PR84MB0284.NAMPRD84.PROD.OUTLOOK.COM (10.162.193.22) by DF4PR84MB0282.NAMPRD84.PROD.OUTLOOK.COM (10.162.193.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Wed, 20 Jul 2016 15:38:04 +0000 Received: from DF4PR84MB0284.NAMPRD84.PROD.OUTLOOK.COM ([10.162.193.22]) by DF4PR84MB0284.NAMPRD84.PROD.OUTLOOK.COM ([10.162.193.22]) with mapi id 15.01.0544.014; Wed, 20 Jul 2016 15:38:06 +0000 From: "Kennedy, Smith (Wireless Architect)" To: "dnssd@ietf.org" Thread-Topic: [dnssd] Setting device friendly names Thread-Index: AdHiibYrxB4vZWkMQdmCvDMGAtoHugAEv9sA Date: Wed, 20 Jul 2016 15:38:06 +0000 Message-ID: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> In-Reply-To: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=smith.kennedy@hp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [107.77.231.166] x-ms-office365-filtering-correlation-id: bda26de2-4700-45ec-9fbe-08d3b0b3d876 x-microsoft-exchange-diagnostics: 1; DF4PR84MB0282; 6:8rOWJeVEXcKT7dPeVB8RDImNq65DbJg8JWeJR6NPKIw8f2kF+ygqgsahXL0ckxdqTkT1G16ag6kuTU7xt4Pcl+vUNCYcmbnQPRl0RZgoG0Io00/Mw2I9jWGaevx6HYUCLYEP5e4LXftLaeSJ5eDZwblTskqMFNo9Zr3U+b2XeBMJoJeyzFqQaaZR35vYrISd7WXxX/9HfN58EjnPcOa8PjKo3zQLEQCZBvLc607dAkM3HakWpUxbgrjInaAc5ApdtR3xHGjoh9tMsMgbkyVKgq3RoMGm8xWURlLeIHzv+Xg=; 5:VNSrOQyN28vNEAiQJQ6hXG4RIIbuDPuoQ5my+Yk2le+1ONecobhj1m7Sk5cVp8zjqeODt7AMB8qTAwcbGKkOT97K5OQ38Bg6DPuBuISvbJYMeCDNn1RVJNtbKR6BBfuMtjII7oegAxpAyR9/9D4qvQ==; 24:Q2p1x+O9eGvz0yirDHbdKyONrTaliiRIpyVP0QnN2CL4I7aripm9KYB0UNExyXJpuNyBnFi0bPq6Kkq4i/rvoI23wEYobDSZBOXh4TNeWGQ=; 7:xI5Mi878qvnKeWNAjFP7EVt8sfAcK9G0z56FItKRtkXN8QeVe+ZTJsJlsIaC3kKkArqjZ43Lgkurg3qLFFkevyHvTk+Pc/mUTZhtM2Z5mDqpFGi9PR3L1mS7/s6RcevSK8grctWO3M8bHKDhvRhIj8y/Eu2Edyi3Cjv10yLAk9PAa8D+8QoYDk0+lvpOh+7tBrwS0+0rcYKsGUxjuwyPKCL1SZ1lhN6L8Ur0uhniIRmvXftrC5X27niNjwl4Sxt0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DF4PR84MB0282; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(97927398514766); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DF4PR84MB0282; BCL:0; PCL:0; RULEID:; SRVR:DF4PR84MB0282; x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(24454002)(199003)(377424004)(6602003)(377454003)(2906002)(8676002)(92566002)(8936002)(50986999)(3280700002)(2900100001)(2950100001)(99286002)(15975445007)(54356999)(76176999)(77096005)(106356001)(101416001)(305945005)(33656002)(66066001)(3846002)(2501003)(5640700001)(6116002)(102836003)(1730700003)(81156014)(81166006)(7736002)(7846002)(2351001)(87936001)(36756003)(83716003)(586003)(122556002)(3660700001)(68736007)(82746002)(19580405001)(107886002)(110136002)(10400500002)(19580395003)(99936001)(189998001)(450100001)(105586002)(97736004)(86362001)(5002640100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DF4PR84MB0282; H:DF4PR84MB0284.NAMPRD84.PROD.OUTLOOK.COM; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: hp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_450DF4B8-A843-4707-B29D-25D9DD53F26C"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginatorOrg: hp.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2016 15:38:06.4947 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ca7981a2-785a-463d-b82a-3db87dfc3ce6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR84MB0282 Archived-At: Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 15:38:11 -0000 --Apple-Mail=_450DF4B8-A843-4707-B29D-25D9DD53F26C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 Smith /** Smith Kennedy Wireless Architect - Client Software - IPG-PPS Standards - IEEE ISTO PWG / Bluetooth SIG / Wi-Fi Alliance / NFC = Forum / USB IF Chair, IEEE ISTO Printer Working Group HP Inc. */ > On 2016-07-20, at 7:22 AM, STARK, BARBARA H wrote: >=20 > In my experience, many devices already support mechanisms for friendly = name acquisition. Many devices, including PCs, ask for names during = setup. Others support UPnP friendly name service. Others have UIs to = allow naming. What I really want (as a user) is for the device to have = the same name in all contexts. So if it's been named, through whatever = means, use that name. Which to me says we don't need a new standard for = remote naming that all devices must support.=20 > Barbara > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail=_450DF4B8-A843-4707-B29D-25D9DD53F26C Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOQDCCBmEw ggVJoAMCAQICEDtXE7awITX7XkZ1ymyyxOEwDQYJKoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ug b25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0 aW9uIEF1dGhvcml0eSAtIEczMB4XDTA5MDkwMjAwMDAwMFoXDTE5MDkwMTIzNTk1OVowgfcxCzAJ BgNVBAYTAlVTMSAwHgYDVQQKExdIZXdsZXR0LVBhY2thcmQgQ29tcGFueTEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3 LnZlcmlzaWduLmNvbS9ycGEgKGMpMDkxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5k aXZpZHVhbCBTdWJzY3JpYmVyIENBMTEwLwYDVQQDEyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRp b24gQXV0aG9yaXR5IEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAp2FraNquqoVk DEvLUMsw6HMhjon+yi1v/kajA27jIrdyhRMj4g+PBveBTHrtA7w97Rx1UKPP6CvOaAE5xUtoW9aj YZtO5kdiUFyzWHsbUgSjKy+yNO4QoHeEzaQi/JWUOYev/AV5YYJoEDIysosEELS1/M64iE2Utzr+ LxiWhdaqSRE4jigbm4Dy4ayLzqAv5f7oILrJNZ6ShqLiGGCpP+7relTyRgFXmEX/SKN/a39JwZoK SNUdIkYyr7wmNI9+zylheDJghuk+kZDAD3NXv4EGVMUfOg5UEdhAJ0Lw40D4pqKa2ej1H0UipK1E EdRTm94RzfE8z8vDP8+dcgOqCwIDAQABo4ICEjCCAg4wEgYDVR0TAQH/BAgwBgEB/wIBADBwBgNV HSAEaTBnMGUGC2CGSAGG+EUBBxcCMFYwKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWdu LmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTA0BgNV HR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2EyLWczLmNybDAOBgNVHQ8B Af8EBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJlbDQtMjA0OC0xNDIw HQYDVR0OBBYEFCJ906SrV6xWf6l/QUQalbxb+KvuMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9y aXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczghBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAA4IBAQB2ipl40XCFoyzXr0j1PpZXw6C7TJfEhhEFSSLFCs/Bb061fKaANRvy4o8cOGJx8zy+ ACVKHqEQyZY7TXusJmijnulZo3jGR5s/jjCWyqjWKDlVx83tyeuykOSVMD60/e/xp8nG4TZsKGBU J563oHE6vau80HUi11PzspxbFXUI6kmrNC5Tw3wGFHug8RSIJG1ekWt+ZOth7CXXGbVtmTdwCn0I qMNgKVUkTBkiAPrsN7OZZAr5UGT6h8RUC/0I0H9MXCtSlXuKcqtJt/sWqQghvDO8hHUh/XU1bEOa 2KjJCygWc7n/nAtBNKw7XtgFguhugtUsbdGBjttfnbzwdTZYMIIH1zCCBr+gAwIBAgIQD2YmaFoP rtv/7EFJwcWKSjANBgkqhkiG9w0BAQUFADCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xl dHQtUGFja2FyZCBDb21wYW55MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYD VQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1 MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAv BgNVBAMTKENvbGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTQxMTIx MDAwMDAwWhcNMTYxMTIwMjM1OTU5WjCBmDEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBh bnkxJjAkBgNVBAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01J TUUxFjAUBgNVBAMTDVNtaXRoIEtlbm5lZHkxIzAhBgkqhkiG9w0BCQEWFHNtaXRoLmtlbm5lZHlA aHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv9/62wcQqoi8ybgcLkzawuys YWyJFJE/h7vnUc0rDcaFMysQZnGt8zuUJtfGVgve+0Y+/C71KqhhuScAkBlISIMA1MCb5SpyMS+i RU8rOcSfm6E/tMYbCQAOc7wPHP3beIPFFbeP9LY3PDA6EtFV6TFV1bfdDeUEY9z6HpXXY84/IZPP dG5zYmWLxi3MxJAWKHSK/ZcvBsVLEaouG7vnLg/DUJUSYyVpzKWzI4pHaLgOkBe7lt/RYA+uoYNi a7jdiS/oJfaBaiZjdGNpLgqPTZ20aDKu+4OKHpjDltcxxmJIdO9rBmxgSagODG1ktAGwzVWLUqhf ysojHpWDN//ZFQIDAQABo4IDujCCA7YwHwYDVR0RBBgwFoEUc21pdGgua2VubmVkeUBocC5jb20w DAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBaAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29u c2l0ZWNybC52ZXJpc2lnbi5jb20vSGV3bGV0dFBhY2thcmRDb21wYW55U01JTUVHMi9MYXRlc3RD UkwuY3JsMB8GA1UdIwQYMBaAFCJ906SrV6xWf6l/QUQalbxb+KvuMB0GA1UdDgQWBBQojp1sWj1X Dn3FJ5AQ7USZWp7SzjCCATIGCCsGAQUFBwEBBIIBJDCCASAwJwYIKwYBBQUHMAGGG2h0dHA6Ly9o cC1vY3NwLnZlcmlzaWduLmNvbTCB9AYIKwYBBQUHMAKkgecwgeQxMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIxMDAuBgNVBAsTJ0NsYXNzIDIgT25TaXRl IEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTE6MDgGA1UECxMxVGVybXMgb2YgdXNlIGF0IGh0dHBz Oi8vd3d3LnZlcmlzaWduLmNvbS9ycGEoYykwOTEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0 d29yazEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkwggE9BgNVHSAEggE0MIIBMDCC ASwGC2CGSAGG+EUBBxcCMIIBGzAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t L3JwYTCB7gYIKwYBBQUHAgIwgeEwHhYXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkwAwIBAhqBvkF1 dGhvcml0eSB0byBiaW5kIEhQIGRvZXMgbm90IGNvcnJlc3BvbmQgd2l0aCB1c2Ugb3IgcG9zc2Vz c2lvbiBvZiB0aGlzIGNlcnRpZmljYXRlLiBJc3N1ZWQgdG8gZmFjaWxpdGF0ZSBjb21tdW5pY2F0 aW9uIHdpdGggSFAuIFZlcmlTaWduJ3MgQ1BTIGluY29ycC4gQnkgcmVmZXJlbmNlIGxpYWIuIGx0 ZC4gKGMpOTcgVmVyaVNpZ24wFgYDVR0lAQH/BAwwCgYIKwYBBQUHAwQwSwYJKoZIhvcNAQkPBD4w PDAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwICAgBAMA4GCCqGSIb3DQMEAgIAgDAKBggqhkiG 9w0DBzANBgkqhkiG9w0BAQUFAAOCAQEAGFPFralTmI3j+0lRN5ZgT1MP6MuFoIWUaLQCdtLdmuWi N4GVcfuVFr2kmCCIbEytJwrso6PphQQ2AhWvKKtGh57CQHtszmG6gTQpDnDhRLg9D29FzdIq9iRm cA8ZB4yUxP2ytQEngUFAQ2PERJboditj+qb3d86bwvENdrxGCUPj1/ybAxvFIVeVh6rh3WkTGLwu 72cn3QEhtMlKeNGjV4iw1fDnNSlmm2YRwf04r6VPeZuJK8nnHIW3UEQwuxy4iv8aTEJ5yhy2E1n1 619oUAX8737oyM88ITM1CUM36+U+Vvj7dScwtY69HwYUczr5a2ZsVzakK+xlnlpyRTo/xzGCBN4w ggTaAgEBMIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3Mg MiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEA9mJmhaD67b/+xBScHFikowCQYFKw4D AhoFAKCCAqUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwNzIw MTUzODA3WjAjBgkqhkiG9w0BCQQxFgQU2lLDFL6WqpCFnvJYyKDcqZMHkSEwggEfBgkrBgEEAYI3 EAQxggEQMIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3Mg MiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEA9mJmhaD67b/+xBScHFikowggEhBgsq hkiG9w0BCRACCzGCARCgggEMMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNr YXJkIENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYDVQQL EyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8GA1UEAxMo Q29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMgIQD2YmaFoPrtv/7EFJwcWK SjANBgkqhkiG9w0BAQEFAASCAQCnNFV/b42TPrZjaqtoAIntDafEv6L7+QNNfJgva2fg5hs7BfHq qMGHo83VLtykDepjnXBpwdOLuxHjLkwd45NNXevucD2WAPZgWxWhyI6aQ4LwRoRjSW1JadP/N5/g MsN6qSfMGuRGwZi0PjbK492sW538tyH9kDlwGcg++lCH813Wcy6O1A/cQ69VTyTjE2bGg7HxhRBx W8rOxVomNaq/ZW8I82U1KCwu2y41433NSJVSS2wYR6M/RntDq1tsM/lJYStlJyjIe6zV2FuWWu0N dmhF6uvxbDqM1ZmYx7mMpa532zKwK4ZrEdrKwu4Li5XY6e6oJzQFr+tBtkBF2PuQAAAAAAAA --Apple-Mail=_450DF4B8-A843-4707-B29D-25D9DD53F26C-- From nobody Wed Jul 20 09:45:25 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE9B12D8B8 for ; Wed, 20 Jul 2016 09:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.021 X-Spam-Level: X-Spam-Status: No, score=-102.021 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 UN5usUqNqDWS for ; Wed, 20 Jul 2016 09:45:10 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0090.outbound.protection.outlook.com [104.47.38.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D32B12D7AF for ; Wed, 20 Jul 2016 09:44:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5VXYYaP/67UlDwk0weA4R16bWaKgDzMAkg/h/OhIwDk=; b=oenV1/RQj2TyN7IQQYqESZLzSgeMNzYF7OB+DBpUr105fdqK+ZrLal5FngBmtjN7rMueq3A0FWX3f4Qsb+zQVr84fE2znmyddnrStPlJHsuQV9bCrhDEKm5Qfdt2QyTAXzed4Eb5deg7YPC6+u9VD8uLpitBu+HBMg+Exv7FQig= Received: from DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) by DM2PR0301MB0718.namprd03.prod.outlook.com (10.160.97.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Wed, 20 Jul 2016 16:44:32 +0000 Received: from DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) by DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) with mapi id 15.01.0534.025; Wed, 20 Jul 2016 16:44:32 +0000 From: Dave Thaler To: Ted Lemon , "STARK, BARBARA H" Thread-Topic: [dnssd] Setting device friendly names Thread-Index: AdHiibYrxB4vZWkMQdmCvDMGAtoHugAAU4SAAAad77A= Date: Wed, 20 Jul 2016 16:44:32 +0000 Message-ID: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [2001:67c:370:160:ddbf:b2ce:c0f4:e325] x-ms-office365-filtering-correlation-id: 3a77df7a-8496-4fcc-9e46-08d3b0bd201c x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0718; 6:JWwUFjlG3YM38X654th1HVtpqJSDP/UfZV6wQDkSWj2cjQAyK6SYMpw+UpYaNYOKGXxOqWHHA5OIPeTQPA0Kgh2910R+vcCMad4gYsiazVsVXCxta8P318a7QkkSxUVyjIOjGt/TbjwKDu3X9xtITA+7i8Cz1wJO2ZftfrzJkj3J+QlmXsKv9Oa0aMdh6O/xqFPsiYqa7/JG9zOjiek43UO0cZXxbwXBizhenZAOQxwCIQeneSTUQCGWcx9Md05qrQVZB+BvvE2GriehC0AsP6rcjXQqubUah31cf9jYcpzDCThkN6t7l2U2CxYPyTgPOn2j5VthxIxMOfCLYzQdMw==; 5:VLlFKK+r48XiExH8Fuz1Ef0v0CU8Z0ceoS/UM2SRJFX7QaRYXqbq5skIrHZuOIHJPJY23Y7PI2u2NYbOKbe7jMavR6vHIu/4QKP7j7ivVU5IVS2EXNjziryA5h08V6+1cgTEtD9aeY2BcMOjCI5a/g==; 24:pHjdculwAv811hi43ojIi3kYO41SM+QMgf8HAPzyeIt6Z+h5JLvr7pe2Fo7GYW7on3YCBPR3gXKVftbEROIf7ZFezKv3NWC6SXk6y/6T9hE=; 7:ycgkRzVZ5hpAsNRFzic3wNGFVJGcKq59yk1M13pGo2Eo0zZvPqjNVcYTVJqqK8LceX37pDnSngEWB+sMfMH9xRO30hWQ2oIHxtF8SyOVBx7K6gpf2se/t4rwTHr8BtEU6TKjhzHLSSP98+6qoao5N+cZTA/anXyo+9/9GHwZQ3fgQeiCO+ELERrc4egttQYzzIiwI4m/rKOj0OgXkRI1AvnBDRlbN1GSJNv7EqWIMCn1MawdF5hNwdwk/S03HL3O x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0718; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(97927398514766)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0718; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0718; x-forefront-prvs: 000947967F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(24454002)(199003)(377454003)(81166006)(74316002)(81156014)(5002640100001)(8676002)(10290500002)(10400500002)(5005710100001)(8990500004)(189998001)(2906002)(101416001)(3660700001)(19625215002)(102836003)(19300405004)(68736007)(586003)(97736004)(33656002)(790700001)(86612001)(7846002)(4326007)(2900100001)(8936002)(7696003)(2950100001)(5003600100003)(7736002)(10090500001)(7906003)(87936001)(6116002)(15975445007)(99286002)(86362001)(122556002)(19580395003)(105586002)(3280700002)(19609705001)(76576001)(92566002)(19580405001)(106356001)(19617315012)(76176999)(50986999)(16236675004)(77096005)(11100500001)(5001770100001)(9686002)(54356999)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0718; H:DM2PR0301MB0717.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR0301MB0717F6F5E5F74852E625C1B7A3080DM2PR0301MB0717_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2016 16:44:32.1594 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0718 Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 16:45:17 -0000 --_000_DM2PR0301MB0717F6F5E5F74852E625C1B7A3080DM2PR0301MB0717_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3YXNu4oCZdCBhd2FyZSBvZiB0aGlzIGJlZm9yZSBlaXRoZXIgc28gSSBqdXN0IGRpZCBhIHdl YiBzZWFyY2jigKYNCg0KaHR0cDovL3d3dy51cG5wLm9yZy9kb3dubG9hZC91cG5wX3ZlbmRvcl9p bXBsZW1lbnRhdGlvbl9ndWlkZV9qYW4yMDAxLmh0bQ0KaXMgd2hhdCBJIGZvdW5kLCB3aGljaCBk aXNjdXNzZXMgaXQgaW4gc29tZXdoYXQgZWFzeSB0byByZWFkIHRlcm1zLg0KDQpodHRwczovL29w ZW5jb25uZWN0aXZpdHkub3JnL3VwbnAvc3BlY2lmaWNhdGlvbnMgc2F5cyBVUG5QIGlzIGEgc3Rh bmRhcmQsIGFuZA0KSSBmb3VuZCB3aGF0IEkgdGhpbmsgaXMgdGhlIGZyaWVuZGx5bmFtZSByZWZl cnJlZCB0bywgaW4gdGhlIOKAnEJhc2ljIERldmljZTox4oCdIHNwZWMuDQoNCkRhdmUNCg0KRnJv bTogZG5zc2QgW21haWx0bzpkbnNzZC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgVGVk IExlbW9uDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjAsIDIwMTYgMzozMSBQTQ0KVG86IFNUQVJL LCBCQVJCQVJBIEggPGJzNzY1MkBhdHQuY29tPg0KQ2M6IGRuc3NkQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW2Ruc3NkXSBTZXR0aW5nIGRldmljZSBmcmllbmRseSBuYW1lcw0KDQpDYW4geW91IHRh bGsgbW9yZSBhYm91dCB0aGlzIFVQblAgdGhpbmc/ICAgQmVhciBpbiBtaW5kIHRoYXQgVVBuUCBp cyBub3QgYSBzdGFuZGFyZCwgQUZBSUssIGFsdGhvdWdoIGl0cyBmb2xsb3ctb24sIFBDUCwgaXMu ICAgSSBkb24ndCBrbm93IHRoYXQgUENQIGhhcyB0aGlzIGZlYXR1cmUuDQoNClRoZSBmYWN0IHRo YXQgc29tZSBkZXZpY2VzIGhhdmUgVUlzIHRoYXQgdXNlcnMgbWF5IG9yIG1heSBub3QgYmUgYWJs ZSB0byBmaW5kIGRvZXMgbm90IG1lYW4gdGhhdCB0aGVyZSBuZWVkbid0IGJlIGEgc3RhbmRhcmQg d2F5IHRvIGRvIGl0LiAgIE1heWJlIHdlIGRvbid0IG5lZWQgaXQsIGJ1dCBpZiB3ZSBkb24ndCwg dGhhdCdzIG5vdCB0aGUgcmVhc29uLg0KDQpPbiBXZWQsIEp1bCAyMCwgMjAxNiBhdCAzOjIyIFBN LCBTVEFSSywgQkFSQkFSQSBIIDxiczc2NTJAYXR0LmNvbTxtYWlsdG86YnM3NjUyQGF0dC5jb20+ PiB3cm90ZToNCkluIG15IGV4cGVyaWVuY2UsIG1hbnkgZGV2aWNlcyBhbHJlYWR5IHN1cHBvcnQg bWVjaGFuaXNtcyBmb3IgZnJpZW5kbHkgbmFtZSBhY3F1aXNpdGlvbi4gTWFueSBkZXZpY2VzLCBp bmNsdWRpbmcgUENzLCBhc2sgZm9yIG5hbWVzIGR1cmluZyBzZXR1cC4gT3RoZXJzIHN1cHBvcnQg VVBuUCBmcmllbmRseSBuYW1lIHNlcnZpY2UuIE90aGVycyBoYXZlIFVJcyB0byBhbGxvdyBuYW1p bmcuIFdoYXQgSSByZWFsbHkgd2FudCAoYXMgYSB1c2VyKSBpcyBmb3IgdGhlIGRldmljZSB0byBo YXZlIHRoZSBzYW1lIG5hbWUgaW4gYWxsIGNvbnRleHRzLiBTbyBpZiBpdCdzIGJlZW4gbmFtZWQs IHRocm91Z2ggd2hhdGV2ZXIgbWVhbnMsIHVzZSB0aGF0IG5hbWUuIFdoaWNoIHRvIG1lIHNheXMg d2UgZG9uJ3QgbmVlZCBhIG5ldyBzdGFuZGFyZCBmb3IgcmVtb3RlIG5hbWluZyB0aGF0IGFsbCBk ZXZpY2VzIG11c3Qgc3VwcG9ydC4NCkJhcmJhcmENCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpkbnNzZCBtYWlsaW5nIGxpc3QNCmRuc3NkQGlldGYub3Jn PG1haWx0bzpkbnNzZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZG5zc2QNCg0K --_000_DM2PR0301MB0717F6F5E5F74852E625C1B7A3080DM2PR0301MB0717_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgd2FzbuKAmXQgYXdhcmUgb2YgdGhpcyBi ZWZvcmUgZWl0aGVyIHNvIEkganVzdCBkaWQgYSB3ZWIgc2VhcmNo4oCmPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8vd3d3LnVwbnAub3Jn L2Rvd25sb2FkL3VwbnBfdmVuZG9yX2ltcGxlbWVudGF0aW9uX2d1aWRlX2phbjIwMDEuaHRtIj5o dHRwOi8vd3d3LnVwbnAub3JnL2Rvd25sb2FkL3VwbnBfdmVuZG9yX2ltcGxlbWVudGF0aW9uX2d1 aWRlX2phbjIwMDEuaHRtPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5pcyB3aGF0IEkgZm91bmQsIHdo aWNoIGRpc2N1c3NlcyBpdCBpbiBzb21ld2hhdCBlYXN5IHRvIHJlYWQgdGVybXMuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwczovL29wZW5j b25uZWN0aXZpdHkub3JnL3VwbnAvc3BlY2lmaWNhdGlvbnMiPmh0dHBzOi8vb3BlbmNvbm5lY3Rp dml0eS5vcmcvdXBucC9zcGVjaWZpY2F0aW9uczwvYT4gc2F5cyBVUG5QIGlzIGEgc3RhbmRhcmQs IGFuZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGZvdW5kIHdoYXQgSSB0aGluayBpcyB0aGUgZnJpZW5k bHluYW1lIHJlZmVycmVkIHRvLCBpbiB0aGUg4oCcQmFzaWMgRGV2aWNlOjHigJ0gc3BlYy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkRhdmU8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2Ui PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2E+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBkbnNzZCBbbWFpbHRvOmRuc3NkLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlRlZCBMZW1vbjxicj4NCjxiPlNlbnQ6PC9i PiBXZWRuZXNkYXksIEp1bHkgMjAsIDIwMTYgMzozMSBQTTxicj4NCjxiPlRvOjwvYj4gU1RBUkss IEJBUkJBUkEgSCAmbHQ7YnM3NjUyQGF0dC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBkbnNzZEBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2Ruc3NkXSBTZXR0aW5nIGRldmljZSBm cmllbmRseSBuYW1lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DYW4geW91IHRhbGsgbW9yZSBhYm91dCB0aGlzIFVQblAgdGhpbmc/ICZuYnNw OyBCZWFyIGluIG1pbmQgdGhhdCBVUG5QIGlzIG5vdCBhIHN0YW5kYXJkLCBBRkFJSywgYWx0aG91 Z2ggaXRzIGZvbGxvdy1vbiwgUENQLCBpcy4gJm5ic3A7IEkgZG9uJ3Qga25vdyB0aGF0IFBDUCBo YXMgdGhpcyBmZWF0dXJlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIGZhY3QgdGhhdCBzb21lIGRldmljZXMgaGF2ZSBVSXMgdGhhdCB1c2VycyBtYXkg b3IgbWF5IG5vdCBiZSBhYmxlIHRvIGZpbmQgZG9lcyBub3QgbWVhbiB0aGF0IHRoZXJlIG5lZWRu J3QgYmUgYSBzdGFuZGFyZCB3YXkgdG8gZG8gaXQuICZuYnNwOyBNYXliZSB3ZSBkb24ndCBuZWVk IGl0LCBidXQgaWYgd2UgZG9uJ3QsIHRoYXQncyBub3QgdGhlIHJlYXNvbi48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEp1bCAyMCwgMjAxNiBhdCAzOjIyIFBN LCBTVEFSSywgQkFSQkFSQSBIICZsdDs8YSBocmVmPSJtYWlsdG86YnM3NjUyQGF0dC5jb20iIHRh cmdldD0iX2JsYW5rIj5iczc2NTJAYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIG15IGV4cGVyaWVuY2UsIG1h bnkgZGV2aWNlcyBhbHJlYWR5IHN1cHBvcnQgbWVjaGFuaXNtcyBmb3IgZnJpZW5kbHkgbmFtZSBh Y3F1aXNpdGlvbi4gTWFueSBkZXZpY2VzLCBpbmNsdWRpbmcgUENzLCBhc2sgZm9yIG5hbWVzIGR1 cmluZyBzZXR1cC4gT3RoZXJzIHN1cHBvcnQgVVBuUCBmcmllbmRseSBuYW1lIHNlcnZpY2UuIE90 aGVycyBoYXZlIFVJcyB0byBhbGxvdyBuYW1pbmcuIFdoYXQgSSByZWFsbHkNCiB3YW50IChhcyBh IHVzZXIpIGlzIGZvciB0aGUgZGV2aWNlIHRvIGhhdmUgdGhlIHNhbWUgbmFtZSBpbiBhbGwgY29u dGV4dHMuIFNvIGlmIGl0J3MgYmVlbiBuYW1lZCwgdGhyb3VnaCB3aGF0ZXZlciBtZWFucywgdXNl IHRoYXQgbmFtZS4gV2hpY2ggdG8gbWUgc2F5cyB3ZSBkb24ndCBuZWVkIGEgbmV3IHN0YW5kYXJk IGZvciByZW1vdGUgbmFtaW5nIHRoYXQgYWxsIGRldmljZXMgbXVzdCBzdXBwb3J0Ljxicj4NCkJh cmJhcmE8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCmRuc3NkIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpkbnNzZEBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRuc3NkQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zc2QiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ruc3NkPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DM2PR0301MB0717F6F5E5F74852E625C1B7A3080DM2PR0301MB0717_-- From nobody Wed Jul 20 09:51:34 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB76112B006 for ; Wed, 20 Jul 2016 09:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 RGpa2U-2AVob for ; Wed, 20 Jul 2016 09:51:17 -0700 (PDT) Received: from julia1.inet.fi (mta-out1.inet.fi [62.71.2.230]) by ietfa.amsl.com (Postfix) with ESMTP id A55C212D8DE for ; Wed, 20 Jul 2016 09:51:16 -0700 (PDT) Received: from [10.59.1.17] (128.65.114.46) by julia1.inet.fi (9.0.002.03-2-gbe5d057) (authenticated as stenma-47) id 5782991C0048EA26; Wed, 20 Jul 2016 19:50:34 +0300 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Markus Stenberg X-Mailer: iPhone Mail (13F69) In-Reply-To: Date: Wed, 20 Jul 2016 18:51:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <708E84AD-C7A3-4663-8BDE-959520379A6F@pp.inet.fi> References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> To: Ted Lemon Archived-At: Cc: "dnssd@ietf.org" , "STARK, BARBARA H" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 16:51:32 -0000 Pcp is just a firewall hole plugging protocol. Upnp as a whole is much more t= han that. The service discovery part of it is somewhat analogous to mdns on d= rugs.=20 Udp? Check. Http + xml? If you must. Multiple urls in small udp packets? ...= -Markus (on the road, via iPhone)= From nobody Wed Jul 20 09:56:38 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 425A212D81D for ; Wed, 20 Jul 2016 09:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.608 X-Spam-Level: X-Spam-Status: No, score=-105.608 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 Mt6g1M8LPeuc for ; Wed, 20 Jul 2016 09:56:33 -0700 (PDT) Received: from mail-in3.euro.apple.com (mail-in.euro.apple.com [17.72.148.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBCAD12D104 for ; Wed, 20 Jul 2016 09:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1469033790; x=2332947390; 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=5K+gxh/vyb3VbgcoGCYp1u3xcrdxNS63JXur4Ia6svs=; b=BKUUc7Ty0XslWu4j4hnEjAW7y6irWK9+CU0kbaHO1s2iwpYKXMKNqnopRX62SSWT w7aWH+G7zLZhmm/b0QlgawBeNGCNoLPGKOSc1spRPykHRamYv0bgQhdnAKGNRLYg tqRpVV3RSlJINsHiXlpZ8kPQO6Z4i/XqnteBrFvPxCtAsCAkvkMC+Y8kaLsvXSCt 5V0FXBz8CEqoqpkb+UXFif5jAplrjVw1U3B8DhwbQF4YDuOYukf8w+5RatY3Y4wK wVHbJKyuoBgvtpazzVpBBQWdDTQXz8J6aNB3v/ZL6+/GaUKTMmmBpWf/e0G5tQEd Sc3C+dP/JcRx5JlmBpkyvg==; Received: from relay2.euro.apple.com ( [17.66.55.12]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail-in3.euro.apple.com (Symantec Mail Security) with SMTP id 45.9F.16926.E3DAF875; Wed, 20 Jul 2016 17:56:30 +0100 (BST) X-AuditID: 1148940d-f791b6d00000421e-0f-578fad3e8d0a Received: from phonehome1 ( [17.72.133.81]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id 00.1A.22244.E3DAF875; Wed, 20 Jul 2016 17:56:30 +0100 (BST) Received: from nlams2-asavpn-l2tp-17-78-244-117.euro.apple.com (nlams2-asavpn-l2tp-17-78-244-117.euro.apple.com [17.78.244.117]) by phonehome1.euro.apple.com (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Nov 11 2015)) with ESMTPSA id <0OAM001M0HQ4YL20@phonehome1.euro.apple.com> for dnssd@ietf.org; Wed, 20 Jul 2016 17:56:30 +0100 (IST) Sender: cheshire@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Stuart Cheshire In-reply-to: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> Date: Wed, 20 Jul 2016 09:56:28 -0700 Content-transfer-encoding: quoted-printable Message-id: <2481EADD-0C7B-49C7-BABD-12E90D80A2EC@apple.com> References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUi6GTOo2u3tj/cYFKLscX7pbMYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcbHjI1PBfeaKnW8vsTYwNjN3MXJySAiYSPxqX8ACYYtJXLi3 nq2LkYtDSGAmk8StBwuZYIqm3TzPDJHoZZL4d+EelPOGSeLatStgo4QFpCRerfwMZHNwMAuo S0yZkgsS5hXQk5h8tIENosRIYsX/A2Db2AS0JF58vgIW5xSwluha+AxsGYuAqsT8r0/ARjID 2VeP9bFA2NoST95dYIWYaSNxdd19sF4hASuJbQdbwWwRoLWrpk1nhThaVuLJyUUsIHdKCPxl lThytpNlAqPILITzZiE5bxaSFQsYmVcxiucmZuboZuYZ66WWFuXrJRYU5KTqJefnbmIEBbrH FN4djNcPGh5iFOBgVOLhfby0P1yINbGsuDL3EKMEB7OSCO/N5UAh3pTEyqrUovz4otKc1OJD jNIcLErivA2HisKFBNITS1KzU1MLUotgskwcnFINjGWTXmbezTDr8uORzdjIUvBO+cEJ456P orx/Dvw6xnEs7tcuxaBD3NLtnNdP6TtzPDRcvp5HSui2QxfL7kOnNfdVnNf9YdxyKZ7HcPMc ed8r6W1H1FnXb+GfciHkafKJ+Iv8Rsdmb/r6nHEeT5GJ2/24Fj+RyyqVqZd2cM6VZtlnoFla xsj4QomlOCPRUIu5qDgRACcJP3dwAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUi6NEaqGu3tj/cYPU2TYv3S2cxOjB6LFny kymAMYrLJiU1J7MstUjfLoEr42LHR6aC+8wVO99eYm1gbGbuYuTkkBAwkZh28zyULSZx4d56 ti5GLg4hgV4miX8X7jFDOG+YJK5duwJWJSwgJfFq5Wcgm4ODWUBdYsqUXJAwr4CexOSjDWwQ JUYSK/4fYAGx2QS0JF58vgIW5xSwluha+IwJxGYRUJWY//UJ2EhmIPvqsT4WCFtb4sm7C6wQ M20krq67D9YrJGAlse1gK5gtArR21bTprBBHy0o8ObmIZQKj4CyEi2YhuWgWkqkLGJlXMYoW peYkVhrppZYW5eslFhTkpOol5+duYgQFppM5zw7GVwcNDzEKcDAq8fCGLOsPF2JNLCuuzD3E KMHBrCTC27MGKMSbklhZlVqUH19UmpNafIhRmoNFSZzX74B2uJBAemJJanZqakFqEUyWiYNT qoFRsmJlaujlLa+OLe2/KFkqnrJbc4+k585Q6ZoC+ZYSD7OwZs6U1Wu0piazRpxdpHRUfdrF 90tLBW+aZa1ZPb3eb9YcR9dfnYxRizW+ntnvkLeGgaf23UkbgWtT2HMrzq3TWtTy8l+C4i/e f1ysc5efU56gIOI0/6/Ajy/c8SdsmetLvScf/f9UiaU4I9FQi7moOBEAQusEykgCAAA= Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2016 16:56:37 -0000 On 20 Jul 2016, at 06:22, STARK, BARBARA H wrote: > In my experience, many devices already support mechanisms for friendly = name acquisition. Many devices, including PCs, ask for names during = setup. Others support UPnP friendly name service. For the benefit of those of us less familiar with this, can you send = some screen shots showing the process of setting a device=E2=80=99s name = using this UPnP friendly name service? Stuart Cheshire From nobody Thu Jul 21 02:54:50 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E895312DC25 for ; Thu, 21 Jul 2016 02:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 WnE2uXTUTFDp for ; Thu, 21 Jul 2016 02:54:46 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 8B23C12D9CE for ; Thu, 21 Jul 2016 02:54:46 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u6L9sLip021571; Thu, 21 Jul 2016 05:54:44 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049458.ppops.net-00191d01. with ESMTP id 24auc08txq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jul 2016 05:54:43 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u6L9shXt014062; Thu, 21 Jul 2016 05:54:43 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u6L9sWnO013974 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Jul 2016 05:54:35 -0400 Received: from GAALPA1MSGHUBAG.ITServices.sbc.com (GAALPA1MSGHUBAG.itservices.sbc.com [130.8.218.156]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 21 Jul 2016 09:54:17 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.74]) by GAALPA1MSGHUBAG.ITServices.sbc.com ([130.8.218.156]) with mapi id 14.03.0294.000; Thu, 21 Jul 2016 05:54:16 -0400 From: "STARK, BARBARA H" To: Ted Lemon Thread-Topic: [dnssd] Setting device friendly names Thread-Index: AdHiibYrxB4vZWkMQdmCvDMGAtoHugAItUmAACJTDvI= Date: Thu, 21 Jul 2016 09:54:16 +0000 Message-ID: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_AD1ED14737F04276BC3BE70072F97EBDattcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-21_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607210114 Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 09:54:49 -0000 --_000_AD1ED14737F04276BC3BE70072F97EBDattcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable UPnP SSDP announcements include a friendly name in the SSDP header. To me, = this is comparable to the instance name in DNS-SD / mDNS. And comparable to= a NetBIOS name. When I ask my router for a list of hosts on the network, and when I ask my = BluRay player to show me a list of content sources (UPnP), the lists use th= e same names for devices (because these devices use the same name across pr= otocols). This is a good thing. I haven't checked whether printers have the= same name in a host list and a list of printers (DNS-SD), but I would defi= nitely want that to be true. My iPhone also has the same name when appearin= g in host lists and UPnP lists. And now there is a suggestion for a device name to be used in site-wide, fl= at DNS. We must not confuse users by having different names for a device used in di= fferent protocols. Devices must not allow the name to be trivially changed, once set. That too= creates confusion. Preferably, whatever method was used to first set a dev= ice name (by a user) should also be the way to change it (allowing another = method must have very stringent authentication/authorization in place to ma= ke sure the change is allowed). There are some devices that don't have an easy way to set a device name (by= the user). Yes, it would be fine to recommend something for those. But acc= ept that those device manufacturers may choose to ignore that recommendatio= n and either use a different method or just go with a default name. This mu= st not break site-wide, flat DNS. We must not build a dependency on the abi= lity of the user to name devices. And don't expect devices that do already have a naming mechanism to support= a different naming mechanism. I named my laptop when I first set it up. My= laptop advertises various services into my home network, and it always app= ears with that name. I do not want my laptop to change its name because som= e message came along telling it to. My personal requirement for my laptop i= s that it MUST NOT allow its name to be changed by a remote message. About UPnP naming... The key point I was trying to make is that the UPnP ar= chitecture has a "friendly name" that must be included in SSDP advertising.= Yes, there is also a UPnP Service defined that allows for remotely changin= g the friendly name. https://openconnectivity.org/upnp/specifications/frien= dlyinfoupdate1. But this service was only published in 2014 (long, long aft= er the UPnP Device Architecture required "friendly name" in SSDP advertisem= ents), it is not widely implemented (not mandatory to implement), and it ca= n be implemented in a manner that requires authentication/authorization to = allow invocation of the "SetFriendlyName()" action. The reason this service= isn't seen as particularly necessary is because devices tend to already ha= ve some sort of device name (default or user defined through a UI) that UPn= P can use. FWIW, UPnP is an ISO/IEC standard. On Jul 20, 2016, at 3:32 PM, Ted Lemon > wrote: Can you talk more about this UPnP thing? Bear in mind that UPnP is not a = standard, AFAIK, although its follow-on, PCP, is. I don't know that PCP h= as this feature. The fact that some devices have UIs that users may or may not be able to fi= nd does not mean that there needn't be a standard way to do it. Maybe we = don't need it, but if we don't, that's not the reason. On Wed, Jul 20, 2016 at 3:22 PM, STARK, BARBARA H > wrote: In my experience, many devices already support mechanisms for friendly name= acquisition. Many devices, including PCs, ask for names during setup. Othe= rs support UPnP friendly name service. Others have UIs to allow naming. Wha= t I really want (as a user) is for the device to have the same name in all = contexts. So if it's been named, through whatever means, use that name. Whi= ch to me says we don't need a new standard for remote naming that all devic= es must support. Barbara _______________________________________________ dnssd mailing list dnssd@ietf.org https://www.ietf.org/mailman/listinfo/dnssd --_000_AD1ED14737F04276BC3BE70072F97EBDattcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
UPnP SSDP an= nouncements include a friendly name in the SSDP header. To me, this is comp= arable to the instance name in DNS-SD / mDNS. And comparable to a NetBIOS n= ame.

When I ask my router for a list of hosts on the network, and when I ask my = BluRay player to show me a list of content sources (UPnP), the lists use th= e same names for devices (because these devices use the same name across pr= otocols). This is a good thing. I haven't checked whether printers have the same name in a host list and a= list of printers (DNS-SD), but I would definitely want that to be true. My= iPhone also has the same name when appearing in host lists and UPnP lists.=

And now there is a suggestion for a device name to be used in site-wide, fl= at DNS.

We must not confuse users by having different names for a device used in di= fferent protocols.

Devices must not allow the name to be trivially changed, once set. That too= creates confusion. Preferably, whatever method was used to first set a dev= ice name (by a user) should also be the way to change it (allowing another = method must have very stringent authentication/authorization in place to make sure the change is allowed).=

There are some devices that don't have an easy way to set a device name (by= the user). Yes, it would be fine to recommend something for those. But acc= ept that those device manufacturers may choose to ignore that recommendatio= n and either use a different method or just go with a default name. This must not break site-wide, flat DNS. W= e must not build a dependency on the ability of the user to name devices.
And don't expect devices that do already have a naming mechanism to support= a different naming mechanism. I named my laptop when I first set it up. My= laptop advertises various services into my home network, and it always app= ears with that name. I do not want my laptop to change its name because some message came along telling it to= . My personal requirement for my laptop is that it MUST NOT allow its name = to be changed by a remote message.

About UPnP naming... The key point I was trying to make is that the UPnP ar= chitecture has a "friendly name" that must be included in SSDP ad= vertising. Yes, there is also a UPnP Service defined that allows for remote= ly changing the friendly name. https://openconnectivity.org/upnp/specifications/friendlyinfoupdat= e1. But this service was only published in 2014 (long, long after the UPnP Dev= ice Architecture required "friendly name" in SSDP advertisements)= , it is not widely implemented (not mandatory to implement), and it can be = implemented in a manner that requires authentication/authorization to allow invocation of the "SetFriendlyName()" action. The reaso= n this service isn't seen as particularly necessary is because devices tend= to already have some sort of device name (default or user defined through = a UI) that UPnP can use.
FWIW, UPnP i= s an ISO/IEC standard. 

On Jul 20, 2016, at 3:32 PM, Ted Lemon <mellon@fugue.com> wrote:

Can you talk more about this UPnP thing?   Bear in mi= nd that UPnP is not a standard, AFAIK, although its follow-on, PCP, is. &nb= sp; I don't know that PCP has this feature.

The fact that some devices have UIs that users may or may not be able = to find does not mean that there needn't be a standard way to do it.  = Maybe we don't need it, but if we don't, that's not the reason.

On Wed, Jul 20, 2016 at 3:22 PM, STARK, BARBARA = H <bs7652@att.com&= gt; wrote:
In my experience, many devices already support mechanisms for friendly name= acquisition. Many devices, including PCs, ask for names during setup. Othe= rs support UPnP friendly name service. Others have UIs to allow naming. Wha= t I really want (as a user) is for the device to have the same name in all contexts. So if it's been named, t= hrough whatever means, use that name. Which to me says we don't need a new = standard for remote naming that all devices must support.
Barbara
_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

--_000_AD1ED14737F04276BC3BE70072F97EBDattcom_-- From nobody Thu Jul 21 03:05:59 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3AA12DC8D for ; Thu, 21 Jul 2016 03:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 ZyMxMGMAT7Wm for ; Thu, 21 Jul 2016 03:05:56 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 9B90312DC86 for ; Thu, 21 Jul 2016 03:05:38 -0700 (PDT) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u6LA5aHX013832; Thu, 21 Jul 2016 06:05:36 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049459.ppops.net-00191d01. with ESMTP id 24arvpmuma-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jul 2016 06:05:35 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u6LA4VmK026032; Thu, 21 Jul 2016 06:04:31 -0400 Received: from alpi132.aldc.att.com (alpi132.aldc.att.com [130.8.217.2]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u6LA4P5D026016 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Jul 2016 06:04:27 -0400 Received: from GAALPA1MSGHUBAA.ITServices.sbc.com (GAALPA1MSGHUBAA.itservices.sbc.com [130.8.218.150]) by alpi132.aldc.att.com (RSA Interceptor); Thu, 21 Jul 2016 10:04:18 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.74]) by GAALPA1MSGHUBAA.ITServices.sbc.com ([130.8.218.150]) with mapi id 14.03.0294.000; Thu, 21 Jul 2016 06:04:18 -0400 From: "STARK, BARBARA H" To: Stuart Cheshire Thread-Topic: [dnssd] Setting device friendly names Thread-Index: AdHiibYrxB4vZWkMQdmCvDMGAtoHugAP3kcAABuDqhg= Date: Thu, 21 Jul 2016 10:04:17 +0000 Message-ID: <8D5FE884-5FD5-4E37-8D44-BA5C7C90D3EF@att.com> References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com>, <2481EADD-0C7B-49C7-BABD-12E90D80A2EC@apple.com> In-Reply-To: <2481EADD-0C7B-49C7-BABD-12E90D80A2EC@apple.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-21_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607210116 Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 10:05:58 -0000 Most UPnP devices use a device name they find laying around elsewhere in th= e OS config or firmware. I know that implementations of the UPnP friendly n= ame service exist, but don't have examples on hand of either a device with = the service or a control point that can make use of the service.=20 Barbara > On Jul 20, 2016, at 6:56 PM, Stuart Cheshire wrote: >=20 >> On 20 Jul 2016, at 06:22, STARK, BARBARA H wrote: >>=20 >> In my experience, many devices already support mechanisms for friendly n= ame acquisition. Many devices, including PCs, ask for names during setup. O= thers support UPnP friendly name service. >=20 > For the benefit of those of us less familiar with this, can you send some= screen shots showing the process of setting a device=92s name using this U= PnP friendly name service? >=20 > Stuart Cheshire >=20 From nobody Thu Jul 21 03:32:03 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EBB12DD10 for ; Thu, 21 Jul 2016 03:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.608 X-Spam-Level: X-Spam-Status: No, score=-105.608 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 u0TacstK-eEc for ; Thu, 21 Jul 2016 03:32:00 -0700 (PDT) Received: from mail-in2.euro.apple.com (mail-in.euro.apple.com [17.72.148.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DFDD12DCA9 for ; Thu, 21 Jul 2016 03:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1469097064; x=2333010664; 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=lb9LYLpfhUIUDxLRmu2sTi1S2a2va+ooKeyv0OYuuD0=; b=GRBthnldVCTKH9p36P8jgnarOaJ3dJEXxaaqzGFQiHkQs5yMj4CitCvZnShT1tzg UCbdwPe7+9EZ6I0KsKCQvimmqPsMzY5j45xeuWuBLtFJVDdWLZKS03D54aEOK4cR pRh9DXi9RcrWy6BWloMqcz0l+gA5USS0zOc7xaorT4ccdP9R7gYQ9/oZn7lwdpcW FpWAGAUZx+oTWczGVBdYfAGkGAxu0IoC04XMjvy9Jg5om3ikvBcOIzdJyoKSxzED QtFSwjNk7z+YdMzV3o63j0JTRqPWQZ9tQMJPBV7rLiuMjoW9OCJOJl67TM+vPhIt y4MaukJ+zZHq3+Ijp44CPA==; Received: from relay2.euro.apple.com (relay2.euro.apple.com [17.66.55.12]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail-in2.euro.apple.com (Symantec Mail Security) with SMTP id 53.44.09044.864A0975; Thu, 21 Jul 2016 11:31:04 +0100 (BST) X-AuditID: 1148940c-f798c6d000002354-9b-5790a46854d7 Received: from phonehome1 ( [17.72.133.81]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id 5E.57.22244.864A0975; Thu, 21 Jul 2016 11:31:04 +0100 (BST) Received: from dhcp-b2af.meeting.ietf.org (dhcp-b2af.meeting.ietf.org [31.133.178.175]) by phonehome1.euro.apple.com (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Nov 11 2015)) with ESMTPSA id <0OAN00CYPUJRKW70@phonehome1.euro.apple.com> for dnssd@ietf.org; Thu, 21 Jul 2016 11:31:03 +0100 (IST) Sender: cheshire@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Stuart Cheshire In-reply-to: Date: Thu, 21 Jul 2016 03:31:04 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUi6GTOo5uxZEK4wYlOAYv3S2cxOjB6LFny kymAMYrLJiU1J7MstUjfLoEr497z1cwFb/gqthyOamCcxtPFyMkhIWAisbW1kx3CFpO4cG89 WxcjF4eQwDomiaY5fawwRQvPTWSFSPQySdy7OZUJwjnIJLF46j6wKmEBKYlXKz8zdzFycDAL qEtMmZILEuYV0JOYfLSBDaLESGLF/wMsIDabgJbEi89XwOKcAtYScxbsZgdpZRFQlZj9sxQk zCzgLDFt+W8WCFtb4sm7C6wgJbwCNhKX5+pAXLCJUWL3gh1gF4gAbV01bTrUzbIST04uYgEp khBoZJNY8OAn+wRGkVkI181Cct0sJCsWMDKvYhTPTczM0c3MM9JLLS3K10ssKMhJ1UvOz93E CApyjyk8OxgvHjQ8xCjAwajEw3tz0oRwIdbEsuLK3EOMEhzMSiK8dguBQrwpiZVVqUX58UWl OanFhxilOViUxHkbDhWFCwmkJ5akZqemFqQWwWSZODilGhilflpNOfOTYfFsvo83FI/+iDix ZUOZ6NuUPu03//nW29/cFZV9fOqqM4Yyz+x0s6717GoNn+tiOrPvz/+JBR9V/Hb++9Z4TMQ5 rbjevCpgzSlF20evDhfFnhJaNpfnVoB++WT1e0XM14Nu1Qa9qPohbTMlXyJ8ot+XB3ZmGuan 66Kzj2zfvEdaiaU4I9FQi7moOBEAz4e0224CAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUi6NEaqJuxZEK4wel/7Bbvl85idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr3nq5kL3vBVbDkc1cA4jaeLkZNDQsBEYuG5iawQtpjEhXvr 2boYuTiEBHqZJO7dnMoE4Rxkklg8dR9YlbCAlMSrlZ+Zuxg5OJgF1CWmTMkFCfMK6ElMPtrA BlFiJLHi/wEWEJtNQEvixecrYHFOAWuJOQt2s4O0sgioSsz+WQoSZhZwlpi2/DcLhK0t8eTd BVaQEl4BG4nLc3UgLtjEKLF7wQ6wC0SAtq6aNh3qZlmJJycXsUxgFJyFcNAsJAfNQjJ1ASPz KkbRotScxEojvdTSony9xIKCnFS95PzcTYygoHQy59nB+Oqg4SFGAQ5GJR7eh30TwoVYE8uK K3MPMUpwMCuJ8NotBArxpiRWVqUW5ccXleakFh9ilOZgURLn9TugHS4kkJ5YkpqdmlqQWgST ZeLglGpgdHuhq2v1h5VXKn+hKueBiasWyzlo1Zr3+N7LkvhSxiz0NplN/qrA0td/9uv2Mr84 6lGSxGOpftezhW2hyZJv1cf3+ho/Yzv3WISP/ezqhAtZaxfIByyRunBaSuvypLLTtU1uhmcy l200mlgjEv+uTu1tp3wGQ0tAYN7/utTNBsLa2vMWCU1UYinOSDTUYi4qTgQANcQ9G0YCAAA= Archived-At: Cc: "dnssd@ietf.org" , Ted Lemon Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 10:32:02 -0000 On 21 Jul 2016, at 02:54, STARK, BARBARA H wrote: > UPnP SSDP announcements include a friendly name in the SSDP header. To = me, this is comparable to the instance name in DNS-SD / mDNS. And = comparable to a NetBIOS name. Yes. I don=E2=80=99t know any service discovery protocol that = *doesn=E2=80=99t* have =E2=80=9Cfriendly names=E2=80=9D. The question was about a ubiquitous protocol for *setting* the = =E2=80=9Cfriendly name=E2=80=9D that=E2=80=99s universally supported on = (virtually) all devices. > When I ask my router for a list of hosts on the network, and when I = ask my BluRay player to show me a list of content sources (UPnP), the = lists use the same names for devices (because these devices use the same = name across protocols). If one computer shares two USB printers on the network, do both shared = printers have to appear with the same name (the same as the name of the = computer that=E2=80=99s sharing them)? Restricting services to = one-instance-per-host is quite limiting. Address Services, Not = Hardware > Yes, there is also a UPnP Service defined that allows for remotely = changing the friendly name. = https://openconnectivity.org/upnp/specifications/friendlyinfoupdate1. = But this service was only published in 2014 (long, long after the UPnP = Device Architecture required "friendly name" in SSDP advertisements), it = is not widely implemented (not mandatory to implement) Do you personally own *any* device that supports this? I know the = =E2=80=9Cstandard=E2=80=9D exists. My question was how many products = actually implement it. The world is full of so-called =E2=80=9Cofficial = standards=E2=80=9D that no real-world products implement. > FWIW, UPnP is an ISO/IEC standard. Yes, a great example: OSI networking. Stuart Cheshire From nobody Thu Jul 21 03:53:30 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F29112DCF7 for ; Thu, 21 Jul 2016 03:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 sQZdieKOmQRn for ; Thu, 21 Jul 2016 03:53:27 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::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 67FC312DD7C for ; Thu, 21 Jul 2016 03:51:51 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id b199so58382364lfe.0 for ; Thu, 21 Jul 2016 03:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=n0njfVB9kE+W5rGmm/zd13Sxyu2ZCPSUw2/Qvg4Sius=; b=Ok6mrUFjssqN4jtz/5TbAlck75aP9BxMyueFDT7bxijk99Rve/WB4d+5mDw1zE9mUn nqHUuDG8Jp/y8ySE0pDIKMa8ddfAW7jhH1ITT4rzIcnFqWVzALp6O9KqhP6Dos2fRK8o xy0pgy1UT1Y2BmjhVURoG1+ehmfLGlFf/NaOqeRlZOotmgPF2EOrG2PrU/wLti1afI5L svOU4Ju9TqCLSjqA8iNDUQE/A1+5GlXvv46mG0igX3fSC9wWTWgLc4JGduIZorq5Ef7G voHmgR+0sneWK2UPNFIUjli5flfEXR73W8sOUFR4kX1Mn7mFhP5qLv5XKkXjg4ZJKQmg KznQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=n0njfVB9kE+W5rGmm/zd13Sxyu2ZCPSUw2/Qvg4Sius=; b=eGSZt5nqhVwlAesBGUyaRtZecQMvo7x5Z6/5z2nmNTls+SuNQzNV5/stFGL1WBNFoy 4+9IvbTYxttXWvbxfK3XS2rP2gKvad0b7ZxTrwgfnbX+pBcTEG2YxFEsrHI4aZOV/16t xKClrIVC4iwCnWgz2RHWl5u3hWqgUGkxdqSVz+8wCFPxWdu39fCEH3tdkvq1aUMbrEgL 7btN/dg5c6Fi2pLPusT38FV9aHX9tfExs+zFYTCgOwNNwXO7IPYJK2UzgCmQ/vxKZ8zP zkUEBcV+EWMCOXa8e3dkY0E0cnZLXMzxJUqnTMJdwmEvxQwbD4CzyJPhj7uB6y1Bzwct W56Q== X-Gm-Message-State: ALyK8tKTZCu+0Pf3LgBZNMaynNS3MTVFW3oGxJHqwRygpLiGBy7cSWSgHOCjv/Ay1qwFl8dn/bwySXYUJn5plg== MIME-Version: 1.0 X-Received: by 10.25.152.135 with SMTP id a129mr20628985lfe.226.1469098309475; Thu, 21 Jul 2016 03:51:49 -0700 (PDT) Received: by 10.25.217.93 with HTTP; Thu, 21 Jul 2016 03:51:49 -0700 (PDT) Received: by 10.25.217.93 with HTTP; Thu, 21 Jul 2016 03:51:49 -0700 (PDT) In-Reply-To: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> Date: Thu, 21 Jul 2016 12:51:49 +0200 Message-ID: From: Ted Lemon To: Stuart Cheshire Content-Type: multipart/alternative; boundary=001a114035e2e074d10538231ad5 Archived-At: Cc: dnssd@ietf.org, "STARK, BARBARA H" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 10:53:30 -0000 --001a114035e2e074d10538231ad5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think the point Barbara is making about consistency is right, and that we may be in violent agreement. :) In general there are devices that you'd like to be able to configure using the network, and devices that you definitely do not want configured by the network. On Jul 21, 2016 12:31, "Stuart Cheshire" wrote: > On 21 Jul 2016, at 02:54, STARK, BARBARA H wrote: > > > UPnP SSDP announcements include a friendly name in the SSDP header. To > me, this is comparable to the instance name in DNS-SD / mDNS. And > comparable to a NetBIOS name. > > Yes. I don=E2=80=99t know any service discovery protocol that *doesn=E2= =80=99t* have > =E2=80=9Cfriendly names=E2=80=9D. > > The question was about a ubiquitous protocol for *setting* the =E2=80=9Cf= riendly > name=E2=80=9D that=E2=80=99s universally supported on (virtually) all dev= ices. > > > When I ask my router for a list of hosts on the network, and when I ask > my BluRay player to show me a list of content sources (UPnP), the lists u= se > the same names for devices (because these devices use the same name acros= s > protocols). > > If one computer shares two USB printers on the network, do both shared > printers have to appear with the same name (the same as the name of the > computer that=E2=80=99s sharing them)? Restricting services to > one-instance-per-host is quite limiting. > > Address Services, Not > Hardware > > > Yes, there is also a UPnP Service defined that allows for remotely > changing the friendly name. > https://openconnectivity.org/upnp/specifications/friendlyinfoupdate1. But > this service was only published in 2014 (long, long after the UPnP Device > Architecture required "friendly name" in SSDP advertisements), it is not > widely implemented (not mandatory to implement) > > Do you personally own *any* device that supports this? I know the > =E2=80=9Cstandard=E2=80=9D exists. My question was how many products actu= ally implement it. > The world is full of so-called =E2=80=9Cofficial standards=E2=80=9D that = no real-world > products implement. > > > FWIW, UPnP is an ISO/IEC standard. > > > Yes, a great example: OSI networking. > > Stuart Cheshire > > --001a114035e2e074d10538231ad5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think the point Barbara is making about consistency is rig= ht, and that we may be in violent agreement. :)

In general there are devices that you'd like to be able = to configure using the network, and devices that you definitely do not want= configured by the network.


On Jul 21, 2016 1= 2:31, "Stuart Cheshire" <cheshire@apple.com> wrote:
On 21 Jul 2016, at 02:54, STARK, BARBARA H <bs7652@att.com> wrote:

> UPnP SSDP announcements include a friendly name in the SSDP header. To= me, this is comparable to the instance name in DNS-SD / mDNS. And comparab= le to a NetBIOS name.

Yes. I don=E2=80=99t know any service discovery protocol that *doesn=E2=80= =99t* have =E2=80=9Cfriendly names=E2=80=9D.

The question was about a ubiquitous protocol for *setting* the =E2=80=9Cfri= endly name=E2=80=9D that=E2=80=99s universally supported on (virtually) all= devices.

> When I ask my router for a list of hosts on the network, and when I as= k my BluRay player to show me a list of content sources (UPnP), the lists u= se the same names for devices (because these devices use the same name acro= ss protocols).

If one computer shares two USB printers on the network, do both shared prin= ters have to appear with the same name (the same as the name of the compute= r that=E2=80=99s sharing them)? Restricting services to one-instance-per-ho= st is quite limiting.

<https://tools.ietf.org/html/rfc6760#section-3.3> Address Services, Not Hardware

> Yes, there is also a UPnP Service defined that allows for remotely cha= nging the friendly name. https:/= /openconnectivity.org/upnp/specifications/friendlyinfoupdate1. But this= service was only published in 2014 (long, long after the UPnP Device Archi= tecture required "friendly name" in SSDP advertisements), it is n= ot widely implemented (not mandatory to implement)

Do you personally own *any* device that supports this? I know the =E2=80=9C= standard=E2=80=9D exists. My question was how many products actually implem= ent it. The world is full of so-called =E2=80=9Cofficial standards=E2=80=9D= that no real-world products implement.

> FWIW, UPnP is an ISO/IEC standard.


Yes, a great example: OSI networking.

Stuart Cheshire

--001a114035e2e074d10538231ad5-- From nobody Thu Jul 21 06:10:56 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8391012DA8F for ; Thu, 21 Jul 2016 06:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 g8DbAw6QYn0w for ; Thu, 21 Jul 2016 06:10:51 -0700 (PDT) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4E7D12D187 for ; Thu, 21 Jul 2016 06:10:48 -0700 (PDT) Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1bQDkS-0001Mt-H3; Thu, 21 Jul 2016 15:10:44 +0200 Received: from c-24-5-43-153.hsd1.ca.comcast.net ([24.5.43.153] helo=[192.168.29.206]) by mailfront12.runbox.com with esmtpsa (uid:871115 ) (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1bQDkE-0001Ue-Fh; Thu, 21 Jul 2016 15:10:30 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-1E502186-E026-42EE-93C1-5151729BFC30 Mime-Version: 1.0 (1.0) From: Alf Watt X-Mailer: iPhone Mail (13G34) In-Reply-To: Date: Thu, 21 Jul 2016 06:10:27 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> To: Ted Lemon Archived-At: Cc: Stuart Cheshire , dnssd@ietf.org, "STARK, BARBARA H" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:10:55 -0000 --Apple-Mail-1E502186-E026-42EE-93C1-5151729BFC30 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Don't forget, good ol DHCPv4 provides option 12 for setting host names by th= e server:=20 https://tools.ietf.org/html/rfc2132 Support will depend on the client respecting the option, which at least some= Linux distributions don't seem to out of the box. The option wasn't included (even for the more common case of the client requ= esting a name from the server) in DHCPv6, which suggests using DDNS for allo= wing the host to update the name after auto-configuration.=20 http://www.ietf.org/rfc/rfc3315.txt Best, Alf > On Jul 21, 2016, at 3:51 AM, Ted Lemon wrote: >=20 > I think the point Barbara is making about consistency is right, and that w= e may be in violent agreement. :) >=20 > In general there are devices that you'd like to be able to configure using= the network, and devices that you definitely do not want configured by the n= etwork. >=20 >=20 >> On Jul 21, 2016 12:31, "Stuart Cheshire" wrote: >> On 21 Jul 2016, at 02:54, STARK, BARBARA H wrote: >>=20 >> > UPnP SSDP announcements include a friendly name in the SSDP header. To m= e, this is comparable to the instance name in DNS-SD / mDNS. And comparable t= o a NetBIOS name. >>=20 >> Yes. I don=E2=80=99t know any service discovery protocol that *doesn=E2=80= =99t* have =E2=80=9Cfriendly names=E2=80=9D. >>=20 >> The question was about a ubiquitous protocol for *setting* the =E2=80=9Cf= riendly name=E2=80=9D that=E2=80=99s universally supported on (virtually) al= l devices. >>=20 >> > When I ask my router for a list of hosts on the network, and when I ask= my BluRay player to show me a list of content sources (UPnP), the lists use= the same names for devices (because these devices use the same name across p= rotocols). >>=20 >> If one computer shares two USB printers on the network, do both shared pr= inters have to appear with the same name (the same as the name of the comput= er that=E2=80=99s sharing them)? Restricting services to one-instance-per-ho= st is quite limiting. >>=20 >> Address Services, Not H= ardware >>=20 >> > Yes, there is also a UPnP Service defined that allows for remotely chan= ging the friendly name. https://openconnectivity.org/upnp/specifications/fri= endlyinfoupdate1. But this service was only published in 2014 (long, long af= ter the UPnP Device Architecture required "friendly name" in SSDP advertisem= ents), it is not widely implemented (not mandatory to implement) >>=20 >> Do you personally own *any* device that supports this? I know the =E2=80=9C= standard=E2=80=9D exists. My question was how many products actually impleme= nt it. The world is full of so-called =E2=80=9Cofficial standards=E2=80=9D t= hat no real-world products implement. >>=20 >> > FWIW, UPnP is an ISO/IEC standard. >>=20 >>=20 >> Yes, a great example: OSI networking. >>=20 >> Stuart Cheshire > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --Apple-Mail-1E502186-E026-42EE-93C1-5151729BFC30 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Don't forget, good ol DHCPv4 provides o= ption 12 for setting host names by the server: 

https://tools.ietf.org/htm= l/rfc2132

Support will depend on the client res= pecting the option, which at least some Linux distributions don't seem to ou= t of the box.

The option wasn't included (even for t= he more common case of the client requesting a name from the server) in DHCP= v6, which suggests using DDNS for allowing the host to update the name after= auto-configuration. 

Best,
Alf

On Jul 21, 2016, at 3:51 AM, T= ed Lemon <mellon@fugue.com> wr= ote:

I think the p= oint Barbara is making about consistency is right, and that we may be in vio= lent agreement. :)

In general there are devices that you'd like to be able to co= nfigure using the network, and devices that you definitely do not want confi= gured by the network.


On Jul 21, 2016 12= :31, "Stuart Cheshire" <cheshire@ap= ple.com> wrote:
On 21 Jul 2016, at 02:54, STARK, BARBARA H <bs7652@att.com> wrote:

> UPnP SSDP announcements include a friendly name in the SSDP header. To m= e, this is comparable to the instance name in DNS-SD / mDNS. And comparable t= o a NetBIOS name.

Yes. I don=E2=80=99t know any service discovery protocol that *doesn=E2=80=99= t* have =E2=80=9Cfriendly names=E2=80=9D.

The question was about a ubiquitous protocol for *setting* the =E2=80=9Cfrie= ndly name=E2=80=9D that=E2=80=99s universally supported on (virtually) all d= evices.

> When I ask my router for a list of hosts on the network, and when I ask= my BluRay player to show me a list of content sources (UPnP), the lists use= the same names for devices (because these devices use the same name across p= rotocols).

If one computer shares two USB printers on the network, do both shared print= ers have to appear with the same name (the same as the name of the computer t= hat=E2=80=99s sharing them)? Restricting services to one-instance-per-host i= s quite limiting.

<https://tools.ietf.org/html/rfc6760#section-3.3= > Address Services, Not Hardware

> Yes, there is also a UPnP Service defined that allows for remotely chan= ging the friendly name. https://op= enconnectivity.org/upnp/specifications/friendlyinfoupdate1. But this ser= vice was only published in 2014 (long, long after the UPnP Device Architectu= re required "friendly name" in SSDP advertisements), it is not widely implem= ented (not mandatory to implement)

Do you personally own *any* device that supports this? I know the =E2=80=9Cs= tandard=E2=80=9D exists. My question was how many products actually implemen= t it. The world is full of so-called =E2=80=9Cofficial standards=E2=80=9D th= at no real-world products implement.

> FWIW, UPnP is an ISO/IEC standard.


Yes, a great example: OSI networking.

Stuart Cheshire

____________________= ___________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mai= lman/listinfo/dnssd
= --Apple-Mail-1E502186-E026-42EE-93C1-5151729BFC30-- From nobody Thu Jul 21 06:14:32 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B43C12D1A3 for ; Thu, 21 Jul 2016 06:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 o4icQgzuHr-M for ; Thu, 21 Jul 2016 06:14:29 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 6FFFD12D113 for ; Thu, 21 Jul 2016 06:14:28 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id b199so61716605lfe.0 for ; Thu, 21 Jul 2016 06:14:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hj6peaedHibUdhP7K44WIXjH/RQVqEcdhZjbOg6dUeE=; b=1MZ9lzPomQ2bTLhRqnT0D94hOHNJR//azsaUmMobGHaFtPFKUvAcGwkIf5fnNbXlub CrcM1S5CEh9Oj7Sz0yuTQwuWUnGm5GhfzGWV23rbdRVEu5FXcioN/27gAuaYrD2cQfbk dcPLn53zIT2D8QMkk+WO2mA3GCIq2i33QkrVjJS8BmlXlAr28kFIHyzEE3pzFIC3/3HH LZd/Vrkdt/VElw1n/sfYHutTLfvYyOrS+gDKocyRBNjmetcWN2KW7lZ7Ttle+dd+glfQ uBcuPdMmR+849EYZaJ4DzPEiuUL8SSHNJlV5nWnYZh6sZanrK3vC3qsyjLQHzRArKTt/ MBLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hj6peaedHibUdhP7K44WIXjH/RQVqEcdhZjbOg6dUeE=; b=Dp5H6slYuhfw2wY0DN0RHQ3yLW1kmXHmLHbm2jezpVlyiAI9KRbrWLuI2c/FfBzyId DrVuCgvWUepjJC0YVsjXYXJZwhrss/KRfD3Wzcu6VYJ3auCv2rwmmpfm9E+/7vYNmvxW LozAjn24II39W654O7QJDRr+2J1ETFZULLZXObT75McevD0TbjR+SXJpO3qdCCqEjb42 xbLzqw+a6WLNnGrCxfYZvfmwC2jVO7ZNjio/RbPp6RwUozP6GdQ/Y8XYmZeOmkUwGSeL K/oGaZzxbAQqUUFa54BYQ3hQsT01ui62wrWY5bQp0+0DUzzYLa1fogn887+8c7dEqYdc fFPA== X-Gm-Message-State: ALyK8tJ1QaOIOsALrbiV0bfdzXr5Lm7J4wOHP3J+T3jK6+AEL5FyZRsYAJyvQIl6H0z0msElCZzvgsd9EPDP4w== X-Received: by 10.25.131.150 with SMTP id f144mr20387434lfd.53.1469106866608; Thu, 21 Jul 2016 06:14:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 21 Jul 2016 06:13:46 -0700 (PDT) In-Reply-To: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> From: Ted Lemon Date: Thu, 21 Jul 2016 15:13:46 +0200 Message-ID: To: Alf Watt Content-Type: multipart/alternative; boundary=001a113f20b8ebf703053825184f Archived-At: Cc: Stuart Cheshire , dnssd@ietf.org, "STARK, BARBARA H" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:14:31 -0000 --001a113f20b8ebf703053825184f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I have never seen a host that would accept an unauthenticated hostname update from a DHCP server. On Thu, Jul 21, 2016 at 3:10 PM, Alf Watt wrote: > Don't forget, good ol DHCPv4 provides option 12 for setting host names by > the server: > > https://tools.ietf.org/html/rfc2132 > > Support will depend on the client respecting the option, which at least > some Linux distributions don't seem to out of the box. > > The option wasn't included (even for the more common case of the client > requesting a name from the server) in DHCPv6, which suggests using DDNS f= or > allowing the host to update the name after auto-configuration. > > http://www.ietf.org/rfc/rfc3315.txt > > Best, > Alf > > On Jul 21, 2016, at 3:51 AM, Ted Lemon wrote: > > I think the point Barbara is making about consistency is right, and that > we may be in violent agreement. :) > > In general there are devices that you'd like to be able to configure usin= g > the network, and devices that you definitely do not want configured by th= e > network. > > On Jul 21, 2016 12:31, "Stuart Cheshire" wrote: > >> On 21 Jul 2016, at 02:54, STARK, BARBARA H wrote: >> >> > UPnP SSDP announcements include a friendly name in the SSDP header. To >> me, this is comparable to the instance name in DNS-SD / mDNS. And >> comparable to a NetBIOS name. >> >> Yes. I don=E2=80=99t know any service discovery protocol that *doesn=E2= =80=99t* have >> =E2=80=9Cfriendly names=E2=80=9D. >> >> The question was about a ubiquitous protocol for *setting* the =E2=80=9C= friendly >> name=E2=80=9D that=E2=80=99s universally supported on (virtually) all de= vices. >> >> > When I ask my router for a list of hosts on the network, and when I as= k >> my BluRay player to show me a list of content sources (UPnP), the lists = use >> the same names for devices (because these devices use the same name acro= ss >> protocols). >> >> If one computer shares two USB printers on the network, do both shared >> printers have to appear with the same name (the same as the name of the >> computer that=E2=80=99s sharing them)? Restricting services to >> one-instance-per-host is quite limiting. >> >> Address Services, Not >> Hardware >> >> > Yes, there is also a UPnP Service defined that allows for remotely >> changing the friendly name. >> https://openconnectivity.org/upnp/specifications/friendlyinfoupdate1. >> But this service was only published in 2014 (long, long after the UPnP >> Device Architecture required "friendly name" in SSDP advertisements), it= is >> not widely implemented (not mandatory to implement) >> >> Do you personally own *any* device that supports this? I know the >> =E2=80=9Cstandard=E2=80=9D exists. My question was how many products act= ually implement it. >> The world is full of so-called =E2=80=9Cofficial standards=E2=80=9D that= no real-world >> products implement. >> >> > FWIW, UPnP is an ISO/IEC standard. >> >> >> Yes, a great example: OSI networking. >> >> Stuart Cheshire >> >> _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > --001a113f20b8ebf703053825184f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have never seen a host that would accept an unauthentica= ted hostname update from a DHCP server.
On Thu, Jul 21, 2016 at 3:10 PM, Alf Watt <alf= @istumbler.net> wrote:
Don't forget, good ol DHCPv4 provides option 12 for = setting host names by the server:=C2=A0


Support will depend on the cl= ient respecting the option, which at least some Linux distributions don'= ;t seem to out of the box.

The option wasn't i= ncluded (even for the more common case of the client requesting a name from= the server) in DHCPv6, which suggests using DDNS for allowing the host to = update the name after auto-configuration.=C2=A0

http://www.= ietf.org/rfc/rfc3315.txt

Best,
Alf

On Jul 21, 2016, at 3:51 AM, Ted Lemon = <mellon@fugue.com<= /a>> wrote:

I= think the point Barbara is making about consistency is right, and that we = may be in violent agreement. :)

In general there are devices that you'd like to be able = to configure using the network, and devices that you definitely do not want= configured by the network.


On Jul 21, 2016 1= 2:31, "Stuart Cheshire" <cheshire@apple.com> wrote:
On 21 Jul 2016, at 02:54, STARK, BARBARA H= <bs7652@att.com= > wrote:

> UPnP SSDP announcements include a friendly name in the SSDP header. To= me, this is comparable to the instance name in DNS-SD / mDNS. And comparab= le to a NetBIOS name.

Yes. I don=E2=80=99t know any service discovery protocol that *doesn=E2=80= =99t* have =E2=80=9Cfriendly names=E2=80=9D.

The question was about a ubiquitous protocol for *setting* the =E2=80=9Cfri= endly name=E2=80=9D that=E2=80=99s universally supported on (virtually) all= devices.

> When I ask my router for a list of hosts on the network, and when I as= k my BluRay player to show me a list of content sources (UPnP), the lists u= se the same names for devices (because these devices use the same name acro= ss protocols).

If one computer shares two USB printers on the network, do both shared prin= ters have to appear with the same name (the same as the name of the compute= r that=E2=80=99s sharing them)? Restricting services to one-instance-per-ho= st is quite limiting.

<https://tools.ietf.org/html/rfc6760#section-3.3> Address Services, Not Hardware

> Yes, there is also a UPnP Service defined that allows for remotely cha= nging the friendly name. https:/= /openconnectivity.org/upnp/specifications/friendlyinfoupdate1. But this= service was only published in 2014 (long, long after the UPnP Device Archi= tecture required "friendly name" in SSDP advertisements), it is n= ot widely implemented (not mandatory to implement)

Do you personally own *any* device that supports this? I know the =E2=80=9C= standard=E2=80=9D exists. My question was how many products actually implem= ent it. The world is full of so-called =E2=80=9Cofficial standards=E2=80=9D= that no real-world products implement.

> FWIW, UPnP is an ISO/IEC standard.


Yes, a great example: OSI networking.

Stuart Cheshire

<= div>_______________________________________________
d= nssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/= listinfo/dnssd
<= /div>
--001a113f20b8ebf703053825184f-- From nobody Thu Jul 21 06:22:33 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBC912D616 for ; Thu, 21 Jul 2016 06:22:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 Evld2-ZqwEyv for ; Thu, 21 Jul 2016 06:22:30 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 C4EC212D60B for ; Thu, 21 Jul 2016 06:22:30 -0700 (PDT) Received: from pps.filterd (m0049287.ppops.net [127.0.0.1]) by m0049287.ppops.net-00191d01. (8.16.0.11/8.16.0.11) with SMTP id u6LDDlAw006536; Thu, 21 Jul 2016 09:22:29 -0400 Received: from alpi154.enaf.aldc.att.com (sbcsmtp6.sbc.com [144.160.229.23]) by m0049287.ppops.net-00191d01. with ESMTP id 24axxv8h3h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 21 Jul 2016 09:22:29 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u6LDMRJu019640; Thu, 21 Jul 2016 09:22:28 -0400 Received: from alpi133.aldc.att.com (alpi133.aldc.att.com [130.8.217.3]) by alpi154.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u6LDMIb9019529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Jul 2016 09:22:19 -0400 Received: from GAALPA1MSGHUBAE.ITServices.sbc.com (GAALPA1MSGHUBAE.itservices.sbc.com [130.8.218.154]) by alpi133.aldc.att.com (RSA Interceptor); Thu, 21 Jul 2016 13:22:07 GMT Received: from GAALPA1MSGUSRBF.ITServices.sbc.com ([169.254.5.74]) by GAALPA1MSGHUBAE.ITServices.sbc.com ([130.8.218.154]) with mapi id 14.03.0294.000; Thu, 21 Jul 2016 09:22:06 -0400 From: "STARK, BARBARA H" To: Ted Lemon Thread-Topic: [dnssd] Setting device friendly names Thread-Index: AdHiibYrxB4vZWkMQdmCvDMGAtoHugAItUmAACJTDvIACarMAAAAuYWA///m7rQ= Date: Thu, 21 Jul 2016 13:22:05 +0000 Message-ID: <8F6598B8-BBE0-4496-B850-51686E63A527@att.com> References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_8F6598B8BBE04496B85051686E63A527attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-07-21_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1607210148 Archived-At: Cc: Stuart Cheshire , "dnssd@ietf.org" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:22:32 -0000 --_000_8F6598B8BBE04496B85051686E63A527attcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 Thx. You said that so much better than I did. :) And even where network configuration is desirable, a one-size-fits all ubiq= uitous solution is not the right answer. We should not design an architect= ure with such a dependency. Barbara On Jul 21, 2016, at 12:51 PM, Ted Lemon > wrote: I think the point Barbara is making about consistency is right, and that we= may be in violent agreement. :) In general there are devices that you'd like to be able to configure using = the network, and devices that you definitely do not want configured by the = network. On Jul 21, 2016 12:31, "Stuart Cheshire" > wrote: On 21 Jul 2016, at 02:54, STARK, BARBARA H > wrote: > UPnP SSDP announcements include a friendly name in the SSDP header. To me= , this is comparable to the instance name in DNS-SD / mDNS. And comparable = to a NetBIOS name. Yes. I don=92t know any service discovery protocol that *doesn=92t* have = =93friendly names=94. The question was about a ubiquitous protocol for *setting* the =93friendly = name=94 that=92s universally supported on (virtually) all devices. > When I ask my router for a list of hosts on the network, and when I ask m= y BluRay player to show me a list of content sources (UPnP), the lists use = the same names for devices (because these devices use the same name across = protocols). If one computer shares two USB printers on the network, do both shared prin= ters have to appear with the same name (the same as the name of the compute= r that=92s sharing them)? Restricting services to one-instance-per-host is = quite limiting. Address Services, Not Har= dware > Yes, there is also a UPnP Service defined that allows for remotely changi= ng the friendly name. https://openconnectivity.org/upnp/specifications/frie= ndlyinfoupdate1. But this service was only published in 2014 (long, long af= ter the UPnP Device Architecture required "friendly name" in SSDP advertise= ments), it is not widely implemented (not mandatory to implement) Do you personally own *any* device that supports this? I know the =93standa= rd=94 exists. My question was how many products actually implement it. The = world is full of so-called =93official standards=94 that no real-world prod= ucts implement. > FWIW, UPnP is an ISO/IEC standard. Yes, a great example: OSI networking. Stuart Cheshire --_000_8F6598B8BBE04496B85051686E63A527attcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1
Thx. You said that so much better than I did. :)
And even where network configuration is desirable, a one-size-fits all= ubiquitous solution is  not the right answer. We should not design an= architecture with such a dependency. 
Barbara

On Jul 21, 2016, at 12:51 PM, Ted Lemon <mellon@fugue.com> wrote:

I think the point Barbara is making about consistency is rig= ht, and that we may be in violent agreement. :)

In general there are devices that you'd like to be able to c= onfigure using the network, and devices that you definitely do not want con= figured by the network.


On Jul 21, 2016 12:31, "Stuart Cheshire&quo= t; <cheshire@apple.com> wro= te:
On 21 Jul 2016, at 02:54, STARK, BARBARA H <bs7652@att.com> wrote:

> UPnP SSDP announcements include a friendly name in the SSDP header. To= me, this is comparable to the instance name in DNS-SD / mDNS. And comparab= le to a NetBIOS name.

Yes. I don=92t know any service discovery protocol that *doesn=92t* have = =93friendly names=94.

The question was about a ubiquitous protocol for *setting* the =93friendly = name=94 that=92s universally supported on (virtually) all devices.

> When I ask my router for a list of hosts on the network, and when I as= k my BluRay player to show me a list of content sources (UPnP), the lists u= se the same names for devices (because these devices use the same name acro= ss protocols).

If one computer shares two USB printers on the network, do both shared prin= ters have to appear with the same name (the same as the name of the compute= r that=92s sharing them)? Restricting services to one-instance-per-host is = quite limiting.

<https://tools.ietf.org/html/rfc6760#section-3.3> Address Services, Not Hardware

> Yes, there is also a UPnP Service defined that allows for remotely cha= nging the friendly name. https://openconnectivity.org/upnp/specifications/friendlyinfoupdate1. B= ut this service was only published in 2014 (long, long after the UPnP Devic= e Architecture required "friendly name" in SSDP advertisements), = it is not widely implemented (not mandatory to implement)

Do you personally own *any* device that supports this? I know the =93standa= rd=94 exists. My question was how many products actually implement it. The = world is full of so-called =93official standards=94 that no real-world prod= ucts implement.

> FWIW, UPnP is an ISO/IEC standard.


Yes, a great example: OSI networking.

Stuart Cheshire

--_000_8F6598B8BBE04496B85051686E63A527attcom_-- From nobody Thu Jul 21 06:48:32 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C8512D5F0 for ; Thu, 21 Jul 2016 06:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=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 k6vOHyG3zksB for ; Thu, 21 Jul 2016 06:48:29 -0700 (PDT) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A9112D587 for ; Thu, 21 Jul 2016 06:48:26 -0700 (PDT) Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1bQEKt-0003qN-3j; Thu, 21 Jul 2016 15:48:23 +0200 Received: from c-24-5-43-153.hsd1.ca.comcast.net ([24.5.43.153] helo=[192.168.29.206]) by mailfront12.runbox.com with esmtpsa (uid:871115 ) (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1bQEKi-0002Hu-BT; Thu, 21 Jul 2016 15:48:12 +0200 Content-Type: multipart/alternative; boundary=Apple-Mail-51A03A90-03C7-41C4-AFBC-7293FBF76331 Mime-Version: 1.0 (1.0) From: Alf Watt X-Mailer: iPhone Mail (13G34) In-Reply-To: Date: Thu, 21 Jul 2016 06:48:09 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> To: Ted Lemon Archived-At: Cc: Stuart Cheshire , dnssd@ietf.org, "STARK, BARBARA H" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:48:31 -0000 --Apple-Mail-51A03A90-03C7-41C4-AFBC-7293FBF76331 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Not have I, which seems suggestive: the feature has at least two proposed me= thods (UPnP and DHCPv4) and neither has been widely implemented in clients. It appears that clients which the IT staff doesn't already control do not wa= nt the network to be able to choose their name. I expect for the usability r= easons already discussed: if the name is changed the user will have to learn= the new name somehow. One other common method of host name configuration which hasn't come up is c= onfiguration profiles, which can automate away having (or allowing) the user= to set the host name (or have one generated for them in setup).=20 Best, Alf > On Jul 21, 2016, at 6:13 AM, Ted Lemon wrote: >=20 > I have never seen a host that would accept an unauthenticated hostname upd= ate from a DHCP server. >=20 >> On Thu, Jul 21, 2016 at 3:10 PM, Alf Watt wrote: >> Don't forget, good ol DHCPv4 provides option 12 for setting host names by= the server:=20 >>=20 >> https://tools.ietf.org/html/rfc2132 >>=20 >> Support will depend on the client respecting the option, which at least s= ome Linux distributions don't seem to out of the box. >>=20 >> The option wasn't included (even for the more common case of the client r= equesting a name from the server) in DHCPv6, which suggests using DDNS for a= llowing the host to update the name after auto-configuration.=20 >>=20 >> http://www.ietf.org/rfc/rfc3315.txt >>=20 >> Best, >> Alf >>=20 >>> On Jul 21, 2016, at 3:51 AM, Ted Lemon wrote: >>>=20 >>> I think the point Barbara is making about consistency is right, and that= we may be in violent agreement. :) >>>=20 >>> In general there are devices that you'd like to be able to configure usi= ng the network, and devices that you definitely do not want configured by th= e network. >>>=20 >>>=20 >>>> On Jul 21, 2016 12:31, "Stuart Cheshire" wrote: >>>> On 21 Jul 2016, at 02:54, STARK, BARBARA H wrote: >>>>=20 >>>> > UPnP SSDP announcements include a friendly name in the SSDP header. T= o me, this is comparable to the instance name in DNS-SD / mDNS. And comparab= le to a NetBIOS name. >>>>=20 >>>> Yes. I don=E2=80=99t know any service discovery protocol that *doesn=E2= =80=99t* have =E2=80=9Cfriendly names=E2=80=9D. >>>>=20 >>>> The question was about a ubiquitous protocol for *setting* the =E2=80=9C= friendly name=E2=80=9D that=E2=80=99s universally supported on (virtually) a= ll devices. >>>>=20 >>>> > When I ask my router for a list of hosts on the network, and when I a= sk my BluRay player to show me a list of content sources (UPnP), the lists u= se the same names for devices (because these devices use the same name acros= s protocols). >>>>=20 >>>> If one computer shares two USB printers on the network, do both shared p= rinters have to appear with the same name (the same as the name of the compu= ter that=E2=80=99s sharing them)? Restricting services to one-instance-per-h= ost is quite limiting. >>>>=20 >>>> Address Services, Not= Hardware >>>>=20 >>>> > Yes, there is also a UPnP Service defined that allows for remotely ch= anging the friendly name. https://openconnectivity.org/upnp/specifications/f= riendlyinfoupdate1. But this service was only published in 2014 (long, long a= fter the UPnP Device Architecture required "friendly name" in SSDP advertise= ments), it is not widely implemented (not mandatory to implement) >>>>=20 >>>> Do you personally own *any* device that supports this? I know the =E2=80= =9Cstandard=E2=80=9D exists. My question was how many products actually impl= ement it. The world is full of so-called =E2=80=9Cofficial standards=E2=80=9D= that no real-world products implement. >>>>=20 >>>> > FWIW, UPnP is an ISO/IEC standard. >>>>=20 >>>>=20 >>>> Yes, a great example: OSI networking. >>>>=20 >>>> Stuart Cheshire >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >=20 --Apple-Mail-51A03A90-03C7-41C4-AFBC-7293FBF76331 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Not have I, which seems suggestive: th= e feature has at least two proposed methods (UPnP and DHCPv4) and neither ha= s been widely implemented in clients.
It appears that clients which the IT s= taff doesn't already control do not want the network to be able to choose th= eir name. I expect for the usability reasons already discussed: if the name i= s changed the user will have to learn the new name somehow.

One other= common method of host name configuration which hasn't come up is configurat= ion profiles, which can automate away having (or allowing) the user to set t= he host name (or have one generated for them in setup). 

Best,Alf

On Jul 21, 2016, at 6:13 AM, Ted Lemon <mellon@fugue.com> wrote:

<= blockquote type=3D"cite">
I have never seen a host that= would accept an unauthenticated hostname update from a DHCP server.

On Thu, Jul 21, 2016= at 3:10 PM, Alf Watt <alf@istumbler.net> wrote:
Don't forget, good ol DHCPv4 prov= ides option 12 for setting host names by the server: 


Support will d= epend on the client respecting the option, which at least some Linux distrib= utions don't seem to out of the box.

The option was= n't included (even for the more common case of the client requesting a name f= rom the server) in DHCPv6, which suggests using DDNS for allowing the host t= o update the name after auto-configuration. 

<= a href=3D"http://www.ietf.org/rfc/rfc3315.txt" target=3D"_blank">http://www.= ietf.org/rfc/rfc3315.txt

Best,
Alf

On Jul 21, 2016, at 3:51 AM, Ted Lemon &l= t;mellon@fugue.com= > wrote:

I thi= nk the point Barbara is making about consistency is right, and that we may b= e in violent agreement. :)

In general there are devices that you'd like to be able to co= nfigure using the network, and devices that you definitely do not want confi= gured by the network.


On Jul 21, 2016 12= :31, "Stuart Cheshire" <cheshire@apple.com> wrote:
On 21 Jul 2016, at 02:54, STARK, BARBARA H <bs7652@att.com> wrote:

> UPnP SSDP announcements include a friendly name in the SSDP header. To m= e, this is comparable to the instance name in DNS-SD / mDNS. And comparable t= o a NetBIOS name.

Yes. I don=E2=80=99t know any service discovery protocol that *doesn=E2=80=99= t* have =E2=80=9Cfriendly names=E2=80=9D.

The question was about a ubiquitous protocol for *setting* the =E2=80=9Cfrie= ndly name=E2=80=9D that=E2=80=99s universally supported on (virtually) all d= evices.

> When I ask my router for a list of hosts on the network, and when I ask= my BluRay player to show me a list of content sources (UPnP), the lists use= the same names for devices (because these devices use the same name across p= rotocols).

If one computer shares two USB printers on the network, do both shared print= ers have to appear with the same name (the same as the name of the computer t= hat=E2=80=99s sharing them)? Restricting services to one-instance-per-host i= s quite limiting.

<https://tools.ietf.org/html/rfc6760#section-3.3= > Address Services, Not Hardware

> Yes, there is also a UPnP Service defined that allows for remotely chan= ging the friendly name. https://op= enconnectivity.org/upnp/specifications/friendlyinfoupdate1. But this ser= vice was only published in 2014 (long, long after the UPnP Device Architectu= re required "friendly name" in SSDP advertisements), it is not widely implem= ented (not mandatory to implement)

Do you personally own *any* device that supports this? I know the =E2=80=9Cs= tandard=E2=80=9D exists. My question was how many products actually implemen= t it. The world is full of so-called =E2=80=9Cofficial standards=E2=80=9D th= at no real-world products implement.

> FWIW, UPnP is an ISO/IEC standard.


Yes, a great example: OSI networking.

Stuart Cheshire

_______________________________________________
dns= sd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listin= fo/dnssd
= --Apple-Mail-51A03A90-03C7-41C4-AFBC-7293FBF76331-- From nobody Thu Jul 21 06:51:19 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CB812D614 for ; Thu, 21 Jul 2016 06:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 UT8MMK9gTfKB for ; Thu, 21 Jul 2016 06:51:15 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 A46DD12D5FC for ; Thu, 21 Jul 2016 06:51:14 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id g62so62520913lfe.3 for ; Thu, 21 Jul 2016 06:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=U9igN1UQx1nO4mhEWIhG1BY1bbX7iE34cLyd/vBZgws=; b=sSuYIj4iyJplVwABQv96v3NqaHGSXxCjZmZyh+kX38yBCLmAgs1o2TzOgaHUK50tQt aN7kV1wVWDGjpIvYyQtM2HIuFVQN13zIh4EfmzDWKJCkDT88yrojoSKVk3FuNbRMaz9V Tc0Z3TuzMXDJJ5m5pGm2KGAfNbpz/NIX3LCZYG1WjnKfoZ+7Bp/jnozBzV9QQWqXPh7c 9kmhg2g5UH/EgqSyL6oQyQ+0EVm50EIQmYZJsEm/nmLuYMRA6PL+Zx7IXy19RWqVqcrM 2PbbZFHKPTzOPl+qnXcZrNMoo/fULKPI6GP5l0CKS6ExxFEOA25KjhFCKAF/WLIAUxHz MUhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=U9igN1UQx1nO4mhEWIhG1BY1bbX7iE34cLyd/vBZgws=; b=EZbQ39LigNofVKN7LImC6+BkvLNcpRaDwECa6mGUwA/8jBXhsil+3rEYUDZhrKS411 +zBttC1z7dSbSanXrTnBrKTt18EzsWhpRATcPs0ti9bDjpNoUQWQjEIcYBrSjYbtimgp gvYbR6l9YMjttE33OXADHAPXhhGkSFbZb1Lv0IEGj1hwGryqdzHTr7ZP4MeO/Jh4sDYY 4tNiu9s1bBJ26BcMD5R+HsStP4URHdjxtULfiWymLeCspYUj80hACTNwZONDXU2QTGJc /0Vx7TsdFoV4d1o4jXqj+2+ffMTL7eayVdRHsGr8TrD6zF/IRqob4QH9f7KHlR+eqIzs MvNQ== X-Gm-Message-State: ALyK8tLEVELzO9lLII2vZjpn7wQONXHo34fAFpgXwkSVxLx7el7gODNpCCog81254hEJ89XOXASoog3Yc7AdMQ== X-Received: by 10.25.159.10 with SMTP id i10mr12211534lfe.131.1469109072811; Thu, 21 Jul 2016 06:51:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 21 Jul 2016 06:50:32 -0700 (PDT) In-Reply-To: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> From: Ted Lemon Date: Thu, 21 Jul 2016 15:50:32 +0200 Message-ID: To: Alf Watt Content-Type: multipart/alternative; boundary=001a11411c426bea4a0538259c20 Archived-At: Cc: Stuart Cheshire , dnssd@ietf.org, "STARK, BARBARA H" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:51:18 -0000 --001a11411c426bea4a0538259c20 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right, the security model for having "the network" change the device's name is wrong. That doesn't mean it's not a problem that needs to be solved. It may indeed be that there is no point in trying to address it in homenet; I would certainly agree that it's not a high priority. The main reason it's of interest at all is for resolving name collisions. In that sense, we _do_ have a way of making the device change its name--we just don't get the opportunity to suggest a new name for it. On Thu, Jul 21, 2016 at 3:48 PM, Alf Watt wrote: > Not have I, which seems suggestive: the feature has at least two proposed > methods (UPnP and DHCPv4) and neither has been widely implemented in > clients. > > It appears that clients which the IT staff doesn't already control do not > want the network to be able to choose their name. I expect for the > usability reasons already discussed: if the name is changed the user will > have to learn the new name somehow. > > One other common method of host name configuration which hasn't come up i= s > configuration profiles, which can automate away having (or allowing) the > user to set the host name (or have one generated for them in setup). > > Best, > Alf > > On Jul 21, 2016, at 6:13 AM, Ted Lemon wrote: > > I have never seen a host that would accept an unauthenticated hostname > update from a DHCP server. > > On Thu, Jul 21, 2016 at 3:10 PM, Alf Watt wrote: > >> Don't forget, good ol DHCPv4 provides option 12 for setting host names b= y >> the server: >> >> https://tools.ietf.org/html/rfc2132 >> >> Support will depend on the client respecting the option, which at least >> some Linux distributions don't seem to out of the box. >> >> The option wasn't included (even for the more common case of the client >> requesting a name from the server) in DHCPv6, which suggests using DDNS = for >> allowing the host to update the name after auto-configuration. >> >> http://www.ietf.org/rfc/rfc3315.txt >> >> Best, >> Alf >> >> On Jul 21, 2016, at 3:51 AM, Ted Lemon wrote: >> >> I think the point Barbara is making about consistency is right, and that >> we may be in violent agreement. :) >> >> In general there are devices that you'd like to be able to configure >> using the network, and devices that you definitely do not want configure= d >> by the network. >> >> On Jul 21, 2016 12:31, "Stuart Cheshire" wrote: >> >>> On 21 Jul 2016, at 02:54, STARK, BARBARA H wrote: >>> >>> > UPnP SSDP announcements include a friendly name in the SSDP header. T= o >>> me, this is comparable to the instance name in DNS-SD / mDNS. And >>> comparable to a NetBIOS name. >>> >>> Yes. I don=E2=80=99t know any service discovery protocol that *doesn=E2= =80=99t* have >>> =E2=80=9Cfriendly names=E2=80=9D. >>> >>> The question was about a ubiquitous protocol for *setting* the =E2=80= =9Cfriendly >>> name=E2=80=9D that=E2=80=99s universally supported on (virtually) all d= evices. >>> >>> > When I ask my router for a list of hosts on the network, and when I >>> ask my BluRay player to show me a list of content sources (UPnP), the l= ists >>> use the same names for devices (because these devices use the same name >>> across protocols). >>> >>> If one computer shares two USB printers on the network, do both shared >>> printers have to appear with the same name (the same as the name of the >>> computer that=E2=80=99s sharing them)? Restricting services to >>> one-instance-per-host is quite limiting. >>> >>> Address Services, Not >>> Hardware >>> >>> > Yes, there is also a UPnP Service defined that allows for remotely >>> changing the friendly name. >>> https://openconnectivity.org/upnp/specifications/friendlyinfoupdate1. >>> But this service was only published in 2014 (long, long after the UPnP >>> Device Architecture required "friendly name" in SSDP advertisements), i= t is >>> not widely implemented (not mandatory to implement) >>> >>> Do you personally own *any* device that supports this? I know the >>> =E2=80=9Cstandard=E2=80=9D exists. My question was how many products ac= tually implement it. >>> The world is full of so-called =E2=80=9Cofficial standards=E2=80=9D tha= t no real-world >>> products implement. >>> >>> > FWIW, UPnP is an ISO/IEC standard. >>> >>> >>> Yes, a great example: OSI networking. >>> >>> Stuart Cheshire >>> >>> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> >> > --001a11411c426bea4a0538259c20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right, the security model for having "the network&quo= t; change the device's name is wrong. =C2=A0 That doesn't mean it&#= 39;s not a problem that needs to be solved. =C2=A0 It may indeed be that th= ere is no point in trying to address it in homenet; I would certainly agree= that it's not a high priority. =C2=A0 The main reason it's of inte= rest at all is for resolving name collisions.

In that se= nse, we _do_ have a way of making the device change its name--we just don&#= 39;t get the opportunity to suggest a new name for it.

On Thu, Jul 21, 2016 at 3:= 48 PM, Alf Watt <alf@istumbler.net> wrote:
Not have I, which seems suggestive:= the feature has at least two proposed methods (UPnP and DHCPv4) and neithe= r has been widely implemented in clients.

It appea= rs that clients which the IT staff doesn't already control do not want = the network to be able to choose their name. I expect for the usability rea= sons already discussed: if the name is changed the user will have to learn = the new name somehow.

One other common method of host name configura= tion which hasn't come up is configuration profiles, which can automate= away having (or allowing) the user to set the host name (or have one gener= ated for them in setup).=C2=A0

Best,
Alf

On Jul 21, 2016, at 6:13 AM, Ted Lemon <mellon@fugue.com> wrote:
I have never se= en a host that would accept an unauthenticated hostname update from a DHCP = server.

On T= hu, Jul 21, 2016 at 3:10 PM, Alf Watt <alf@istumbler.net> wr= ote:
Don't for= get, good ol DHCPv4 provides option 12 for setting host names by the server= :=C2=A0

<= br>
Support will depend on the client respecting the option, whic= h at least some Linux distributions don't seem to out of the box.
=

The option wasn't included (even for the more commo= n case of the client requesting a name from the server) in DHCPv6, which su= ggests using DDNS for allowing the host to update the name after auto-confi= guration.=C2=A0

http://www.ietf.org/rfc/rfc3315.txt

Best,
Alf

On Jul 21= , 2016, at 3:51 AM, Ted Lemon <mellon@fugue.com> wrote:

I think the point Barbara is making about con= sistency is right, and that we may be in violent agreement. :)

In general there are devices that you'd like to be able = to configure using the network, and devices that you definitely do not want= configured by the network.


On Jul 21, 2016 1= 2:31, "Stuart Cheshire" <cheshire@apple.com> wrote:
On 21 Jul 2016, at 02:54, STARK, BARBARA H= <bs7652@att.com= > wrote:

> UPnP SSDP announcements include a friendly name in the SSDP header. To= me, this is comparable to the instance name in DNS-SD / mDNS. And comparab= le to a NetBIOS name.

Yes. I don=E2=80=99t know any service discovery protocol that *doesn=E2=80= =99t* have =E2=80=9Cfriendly names=E2=80=9D.

The question was about a ubiquitous protocol for *setting* the =E2=80=9Cfri= endly name=E2=80=9D that=E2=80=99s universally supported on (virtually) all= devices.

> When I ask my router for a list of hosts on the network, and when I as= k my BluRay player to show me a list of content sources (UPnP), the lists u= se the same names for devices (because these devices use the same name acro= ss protocols).

If one computer shares two USB printers on the network, do both shared prin= ters have to appear with the same name (the same as the name of the compute= r that=E2=80=99s sharing them)? Restricting services to one-instance-per-ho= st is quite limiting.

<https://tools.ietf.org/html/rfc6760#section-3.3> Address Services, Not Hardware

> Yes, there is also a UPnP Service defined that allows for remotely cha= nging the friendly name. https:/= /openconnectivity.org/upnp/specifications/friendlyinfoupdate1. But this= service was only published in 2014 (long, long after the UPnP Device Archi= tecture required "friendly name" in SSDP advertisements), it is n= ot widely implemented (not mandatory to implement)

Do you personally own *any* device that supports this? I know the =E2=80=9C= standard=E2=80=9D exists. My question was how many products actually implem= ent it. The world is full of so-called =E2=80=9Cofficial standards=E2=80=9D= that no real-world products implement.

> FWIW, UPnP is an ISO/IEC standard.


Yes, a great example: OSI networking.

Stuart Cheshire

_= ______________________________________________
dnssd mailin= g list
= dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dns= sd


--001a11411c426bea4a0538259c20-- From nobody Thu Jul 21 06:52:07 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB58012D533 for ; Thu, 21 Jul 2016 06:52:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 igZWiFlnTuyI for ; Thu, 21 Jul 2016 06:52:03 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 84C3612D516 for ; Thu, 21 Jul 2016 06:52:02 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id g62so62542427lfe.3 for ; Thu, 21 Jul 2016 06:52:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jKa9LL5NABvSoPoF+jcRNCE8inG9UjUxGbZs0SxWyjM=; b=s0Ti9livRmY8dEcOv+nUCGUjZuflktSuPS8mL5mbQlQvBEsXsxk912z6N2X9A9dAy8 fZs+LJey1YyPwd9uOpTBCsNpyf5dmDqFwxsYmbceTUb03B8wtV7rhVK1Eq85vStCUcu8 3bGqmHI5i+7EQHhb1PqublYgBIEEiaZ5OOdkw9/csOG3hgYtDER3aQEczFu9u5XvuOBa JZ0C9ikOK80CC63fy/wRsMnc9OVf3KiskZ/xx4nQav7byg9Mr2WEg6Nn8nGqZpviu79q ZTU412PEl0h4rpyPrxV23ESnP8PXdppgcijl7LL+nWRUzbvutuLRrVCXqRWsyc/mx7TM Shuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jKa9LL5NABvSoPoF+jcRNCE8inG9UjUxGbZs0SxWyjM=; b=Qcejw2EC3shGtWrbQEHitHIH1YhR5rcrgM+szO/fH1rD3FZgP7BblW+yA2gXNXV8ZU 0CVAnL8c1noybEh0UBhKHWVi5YNKAPCsgvBX0RB7OhVNfTmuj+qnER3hLC1ubdCkY1SR M592wlUQfRmnkpVHYnF+7hev+/q7rttkxT+EFbH1pvgSrwrO3UjzTV96C8O/0k+CCI8n D0gkyquXwzNKcH7ACcEiFJkgbczrMkeAKD88hxAajoY3MpSgEineTh3aeE/JoQPDKkfU qvIWnlR/DwwtiQvR9bqxdT9WYJAc7LOEPiq1B1oFUWwzjka7jXoVoVT//FLSxlUwdErf BoYg== X-Gm-Message-State: ALyK8tIdbNbRMPUaShbZAJ7Yr2t8eV4f1MgmfXNcoVcCOEPlq+0cns2shMcTocXLX+W9qp6Na7VQK4+ODlJlBQ== X-Received: by 10.25.42.207 with SMTP id q198mr21462866lfq.181.1469109120636; Thu, 21 Jul 2016 06:52:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 21 Jul 2016 06:51:20 -0700 (PDT) In-Reply-To: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> From: Ted Lemon Date: Thu, 21 Jul 2016 15:51:20 +0200 Message-ID: To: Alf Watt Content-Type: multipart/alternative; boundary=001a11411dba45afdd0538259f2c Archived-At: Cc: Stuart Cheshire , dnssd@ietf.org, "STARK, BARBARA H" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 13:52:06 -0000 --001a11411dba45afdd0538259f2c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One option, by the way, would be to simply pop up some kind of warning if a two devices come on the network with the same name, and leave it to the user to fix it (or not). On Thu, Jul 21, 2016 at 3:50 PM, Ted Lemon wrote: > Right, the security model for having "the network" change the device's > name is wrong. That doesn't mean it's not a problem that needs to be > solved. It may indeed be that there is no point in trying to address it > in homenet; I would certainly agree that it's not a high priority. The > main reason it's of interest at all is for resolving name collisions. > > In that sense, we _do_ have a way of making the device change its name--w= e > just don't get the opportunity to suggest a new name for it. > > On Thu, Jul 21, 2016 at 3:48 PM, Alf Watt wrote: > >> Not have I, which seems suggestive: the feature has at least two propose= d >> methods (UPnP and DHCPv4) and neither has been widely implemented in >> clients. >> >> It appears that clients which the IT staff doesn't already control do no= t >> want the network to be able to choose their name. I expect for the >> usability reasons already discussed: if the name is changed the user wil= l >> have to learn the new name somehow. >> >> One other common method of host name configuration which hasn't come up >> is configuration profiles, which can automate away having (or allowing) = the >> user to set the host name (or have one generated for them in setup). >> >> Best, >> Alf >> >> On Jul 21, 2016, at 6:13 AM, Ted Lemon wrote: >> >> I have never seen a host that would accept an unauthenticated hostname >> update from a DHCP server. >> >> On Thu, Jul 21, 2016 at 3:10 PM, Alf Watt wrote: >> >>> Don't forget, good ol DHCPv4 provides option 12 for setting host names >>> by the server: >>> >>> https://tools.ietf.org/html/rfc2132 >>> >>> Support will depend on the client respecting the option, which at least >>> some Linux distributions don't seem to out of the box. >>> >>> The option wasn't included (even for the more common case of the client >>> requesting a name from the server) in DHCPv6, which suggests using DDNS= for >>> allowing the host to update the name after auto-configuration. >>> >>> http://www.ietf.org/rfc/rfc3315.txt >>> >>> Best, >>> Alf >>> >>> On Jul 21, 2016, at 3:51 AM, Ted Lemon wrote: >>> >>> I think the point Barbara is making about consistency is right, and tha= t >>> we may be in violent agreement. :) >>> >>> In general there are devices that you'd like to be able to configure >>> using the network, and devices that you definitely do not want configur= ed >>> by the network. >>> >>> On Jul 21, 2016 12:31, "Stuart Cheshire" wrote: >>> >>>> On 21 Jul 2016, at 02:54, STARK, BARBARA H wrote: >>>> >>>> > UPnP SSDP announcements include a friendly name in the SSDP header. >>>> To me, this is comparable to the instance name in DNS-SD / mDNS. And >>>> comparable to a NetBIOS name. >>>> >>>> Yes. I don=E2=80=99t know any service discovery protocol that *doesn= =E2=80=99t* have >>>> =E2=80=9Cfriendly names=E2=80=9D. >>>> >>>> The question was about a ubiquitous protocol for *setting* the >>>> =E2=80=9Cfriendly name=E2=80=9D that=E2=80=99s universally supported o= n (virtually) all devices. >>>> >>>> > When I ask my router for a list of hosts on the network, and when I >>>> ask my BluRay player to show me a list of content sources (UPnP), the = lists >>>> use the same names for devices (because these devices use the same nam= e >>>> across protocols). >>>> >>>> If one computer shares two USB printers on the network, do both shared >>>> printers have to appear with the same name (the same as the name of th= e >>>> computer that=E2=80=99s sharing them)? Restricting services to >>>> one-instance-per-host is quite limiting. >>>> >>>> Address Services, >>>> Not Hardware >>>> >>>> > Yes, there is also a UPnP Service defined that allows for remotely >>>> changing the friendly name. >>>> https://openconnectivity.org/upnp/specifications/friendlyinfoupdate1. >>>> But this service was only published in 2014 (long, long after the UPnP >>>> Device Architecture required "friendly name" in SSDP advertisements), = it is >>>> not widely implemented (not mandatory to implement) >>>> >>>> Do you personally own *any* device that supports this? I know the >>>> =E2=80=9Cstandard=E2=80=9D exists. My question was how many products a= ctually implement it. >>>> The world is full of so-called =E2=80=9Cofficial standards=E2=80=9D th= at no real-world >>>> products implement. >>>> >>>> > FWIW, UPnP is an ISO/IEC standard. >>>> >>>> >>>> Yes, a great example: OSI networking. >>>> >>>> Stuart Cheshire >>>> >>>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>> >>> >> > --001a11411dba45afdd0538259f2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One option, by the way, would be to simply pop up some kin= d of warning if a two devices come on the network with the same name, and l= eave it to the user to fix it (or not).
On Thu, Jul 21, 2016 at 3:50 PM, Ted Lemon <mel= lon@fugue.com> wrote:
Right, the security model for having "the network" ch= ange the device's name is wrong. =C2=A0 That doesn't mean it's = not a problem that needs to be solved. =C2=A0 It may indeed be that there i= s no point in trying to address it in homenet; I would certainly agree that= it's not a high priority. =C2=A0 The main reason it's of interest = at all is for resolving name collisions.

In that sense, = we _do_ have a way of making the device change its name--we just don't = get the opportunity to suggest a new name for it.

On Thu, Jul 21, 2016 at 3:48 PM, Alf Watt <alf@istumbler.net&= gt; wrote:
= Not have I, which seems suggestive: the feature has at least two proposed m= ethods (UPnP and DHCPv4) and neither has been widely implemented in clients= .

It appears that clients which the IT staff doesn= 't already control do not want the network to be able to choose their n= ame. I expect for the usability reasons already discussed: if the name is c= hanged the user will have to learn the new name somehow.

One other c= ommon method of host name configuration which hasn't come up is configu= ration profiles, which can automate away having (or allowing) the user to s= et the host name (or have one generated for them in setup).=C2=A0

Be= st,
Alf

On Jul 21, 2016, at 6:13 AM, Ted = Lemon <mellon@fugu= e.com> wrote:

I have never seen a host that would accept an unauthenticated host= name update from a DHCP server.

On Thu, Jul 21, 2016 at 3:10 PM, Alf Watt <alf@istumbl= er.net> wrote:
Don't forget, good ol DHCPv4 provides option 12 for setting = host names by the server:=C2=A0


Support will depend on the client res= pecting the option, which at least some Linux distributions don't seem = to out of the box.

The option wasn't included = (even for the more common case of the client requesting a name from the ser= ver) in DHCPv6, which suggests using DDNS for allowing the host to update t= he name after auto-configuration.=C2=A0


Best,
Alf

On Jul 21, 2016, at 3:51 AM, Ted Lemon <mellon@fugue.com> wrote:

I think the point Barb= ara is making about consistency is right, and that we may be in violent agr= eement. :)

In general there are devices that you'd like to be able = to configure using the network, and devices that you definitely do not want= configured by the network.


On Jul 21, 2016 1= 2:31, "Stuart Cheshire" <cheshire@apple.com> wrote:
On 21 Jul 2016, at 02:54, STARK, BARBARA H= <bs7652@att.com= > wrote:

> UPnP SSDP announcements include a friendly name in the SSDP header. To= me, this is comparable to the instance name in DNS-SD / mDNS. And comparab= le to a NetBIOS name.

Yes. I don=E2=80=99t know any service discovery protocol that *doesn=E2=80= =99t* have =E2=80=9Cfriendly names=E2=80=9D.

The question was about a ubiquitous protocol for *setting* the =E2=80=9Cfri= endly name=E2=80=9D that=E2=80=99s universally supported on (virtually) all= devices.

> When I ask my router for a list of hosts on the network, and when I as= k my BluRay player to show me a list of content sources (UPnP), the lists u= se the same names for devices (because these devices use the same name acro= ss protocols).

If one computer shares two USB printers on the network, do both shared prin= ters have to appear with the same name (the same as the name of the compute= r that=E2=80=99s sharing them)? Restricting services to one-instance-per-ho= st is quite limiting.

<https://tools.ietf.org/html/rfc6760#section-3.3> Address Services, Not Hardware

> Yes, there is also a UPnP Service defined that allows for remotely cha= nging the friendly name. https:/= /openconnectivity.org/upnp/specifications/friendlyinfoupdate1. But this= service was only published in 2014 (long, long after the UPnP Device Archi= tecture required "friendly name" in SSDP advertisements), it is n= ot widely implemented (not mandatory to implement)

Do you personally own *any* device that supports this? I know the =E2=80=9C= standard=E2=80=9D exists. My question was how many products actually implem= ent it. The world is full of so-called =E2=80=9Cofficial standards=E2=80=9D= that no real-world products implement.

> FWIW, UPnP is an ISO/IEC standard.


Yes, a great example: OSI networking.

Stuart Cheshire

_= ______________________________________________
dnssd mailin= g list
= dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dns= sd



--001a11411dba45afdd0538259f2c-- From nobody Thu Jul 21 08:34:44 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4136412D0B4 for ; Thu, 21 Jul 2016 08:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.608 X-Spam-Level: X-Spam-Status: No, score=-105.608 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 vOmXFb0ALmRZ for ; Thu, 21 Jul 2016 08:34:40 -0700 (PDT) Received: from mail-in2.euro.apple.com (mail-in.euro.apple.com [17.72.148.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211E012B032 for ; Thu, 21 Jul 2016 08:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1469115276; x=2333028876; 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=4eVYNPE7NuddiQScYhPyiex1RWI2ZncScdoBlKv98qg=; b=b5o63QpFZuIJ43lkQW1i6pBSQuMHmhCpd+JzlX67YCryktXVXqF8alRZd667DuZw 94Abwx3LecR4bRtCuVmDafRlHi+Vn+eGGQQVJG1LEukPL8bg5m2eSkc43WbdqTJ/ 5isUPJhtxJxVXtou1lr9LpzNwYaI+Vg+aFeBuZ1FCexkNRmdt8ZeZjUBszeJ6gA1 iyoMNSepkXrsC4092TTU1e7DavEMtK8BHipXAkuIc0/3dSlpKWEClxk6o4AdVapz doXSq/6/cr3I6WM+bhCbmHNC0e6j7p4FteNAlUqeOwpq6wjvmWmzKALEW2bhva4A nMl7zOFIW7V3GDbzDGGJhQ==; Received: from relay2.euro.apple.com (relay2.euro.apple.com [17.66.55.12]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail-in2.euro.apple.com (Symantec Mail Security) with SMTP id C4.2B.09044.C8BE0975; Thu, 21 Jul 2016 16:34:36 +0100 (BST) X-AuditID: 1148940c-f798c6d000002354-15-5790eb8cdfbe Received: from phonehome1 ( [17.72.133.81]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id 01.D8.22244.C8BE0975; Thu, 21 Jul 2016 16:34:36 +0100 (BST) Received: from [IPv6:2001:67c:1231:998:c533:4264:e602:7da1] (nat64-47.meeting.ietf.org [31.130.238.71]) by phonehome1.euro.apple.com (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Nov 11 2015)) with ESMTPSA id <0OAO0002E8LN9S40@phonehome1.euro.apple.com> for dnssd@ietf.org; Thu, 21 Jul 2016 16:34:36 +0100 (IST) Sender: cheshire@apple.com Content-type: text/plain; charset=windows-1252 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Stuart Cheshire In-reply-to: <8F6598B8-BBE0-4496-B850-51686E63A527@att.com> Date: Thu, 21 Jul 2016 08:34:33 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> <8F6598B8-BBE0-4496-B850-51686E63A527@att.com> To: "STARK, BARBARA H" X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUi6GTOo9vzekK4wYWXqhbvl85idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvl2w4JbXBXbl/5mbmA8y9HFyMkhIWAisXXhCVYIW0ziwr31 bF2MXBxCAuuYJM4+vsMMU3Rj6UJGiEQvk0RL82RWCOcik8Ttl3/YQaqEBaQkXq38DNTBwcEs oCdx/6IWSJgXyJx8tIENosRIYsX/AywgNpuAlsSLz1fA4pwC1hK/fnwAi7MIqEo82noQbDGz gLPEtOW/WSBsbYkn7y6wQsy0kZjZOAfqhrtMEnO2bAIbJCKgLrFq2nSod2QlnpxcxAJSJCHQ yCZxff905gmMIrMQ7puF5L5ZSHYsYGRexSiem5iZo5uZZ6SXWlqUr5dYUJCTqpecn7uJERTo HlN4djBePGh4iFGAg1GJh9f26oRwIdbEsuLK3EOMEhzMSiK8zx4BhXhTEiurUovy44tKc1KL DzFKc7AoifM2HCoKFxJITyxJzU5NLUgtgskycXBKNTAKJBc3SMm78D1NK9dZtkZVWEvQWKDL Yodk7rT8n6f8hc+o3Z5k9ndyzlGvw4rTLsszMkvGGvK5HOZ+9cgtd6r17tPxNzIUbXdG6D0+ ufSbY3u207qtqT6vvx8pP/acrSp0V+Cp16f5WUtubirr/3ZO6bLVi4Bwv6j6d216d+ZISUzr Pvx+m5kSS3FGoqEWc1FxIgAgMoLrcAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUi6NEaqNvzekK4wZtWFYv3S2cxOjB6LFny kymAMYrLJiU1J7MstUjfLoEr43y7YcEtrortS38zNzCe5ehi5OSQEDCRuLF0ISOELSZx4d56 ti5GLg4hgV4miZbmyawQzkUmidsv/7CDVAkLSEm8WvmZuYuRg4NZQE/i/kUtkDAvkDn5aAMb RImRxIr/B1hAbDYBLYkXn6+AxTkFrCV+/fgAFmcRUJV4tPUgM4jNLOAsMW35bxYIW1viybsL rBAzbSRmNs6BuuEuk8ScLZvABokIqEusmjadFeJqWYknJxexTGAUnIVw0iwkJ81CMnYBI/Mq RtGi1JzESiO91NKifL3EgoKcVL3k/NxNjKDAdDLn2cH46qDhIUYBDkYlHt6EqxPChVgTy4or cw8xSnAwK4nwPnsEFOJNSaysSi3Kjy8qzUktPsQozcGiJM7rd0A7XEggPbEkNTs1tSC1CCbL xMEp1cC40ikh4PaBT/XdG0tf3jBYIv+gQuRxk+f6E4e4xKNrLj0+tPTGvm+Pdbcf+Rv+9aN2 yw6/D0XOk76YdV3QvzHh+u/lvy7UiTctfPTV3v4B19W30q27N09RXG/zUzGPT0dY40Pv9pOB vmd8G+ff/nlYKTpKgHvrkysKtYU3jzEVHzyrvElwybX2u0osxRmJhlrMRcWJAPu5InJIAgAA Archived-At: Cc: "dnssd@ietf.org" , Ted Lemon Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 15:34:42 -0000 On 21 Jul 2016, at 06:22, STARK, BARBARA H wrote: > +1 > Thx. You said that so much better than I did. :) > And even where network configuration is desirable, a one-size-fits all = ubiquitous solution is not the right answer. We should not design an = architecture with such a dependency.=20 > Barbara Sorry, I=92m getting confused by this discussion. The discussion in the meeting was that pretty much all network devices = (apart from my SMA solar inverters) can have their name set today over = the network, but not using a one-size-fits-all ubiquitous solution. It=92s= ad hoc. Many devices have their name set via web UI. Some devices have = their name set via some proprietary app. Others have their name set = using some non-web protocol like Apple=92s HomeKit. Some have their name = set via physical controls on the device itself. The assertion in the = meeting was that this is no good and we need a one-size-fits-all = ubiquitous solution. UPnP was offered as that one-size-fits-all = ubiquitous solution. Now we=92re saying that a one-size-fits-all = ubiquitous solution is *not* the right answer. I=92m confused. It sounds like we=92re back to saying what we have = already today is just fine (apart from my SMA solar inverters -- I need = to find out how to file a bug report for that). Stuart Cheshire From nobody Thu Jul 21 09:07:09 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAD012D79F for ; Thu, 21 Jul 2016 09:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 asaMvdoJfg6P for ; Thu, 21 Jul 2016 09:07:06 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 CD40B12D799 for ; Thu, 21 Jul 2016 09:06:54 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id b199so66141027lfe.0 for ; Thu, 21 Jul 2016 09:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z5ZD85t7VdKrKejagtx3yBqqFIj4oaXqeEg6J4Rv8CQ=; b=xgZVzr3Lpw8K1fucTprAIEt3uvSlGC3kcPdBmLeswlXix2oIyfAQwNBgyP5WA1tSK/ evxKJgM3bW5eRM68gp0+uMIKo83A72t9fYR2QlkAFjhz3OqT1aDXB1jDyWV2xjkD59gf tXr06aZrKLzwyml8LQ0V6Ba0QLnUMCIn7fZUTNOYmY7v34RcIrOv64ubEevIRXOHwTed nE5k36uvMZSWlDF+1PzPimkRvsn0EDgdlFHEywZ1TQ5GGi+efdjTg1XkZJSotcRRzLac hO1YGuNPJ7558x2CutwA9fw0vDxIs3DZJmKZJcxL+9tZCxSK8wy2vO/+I/sMHLFDSYA4 neiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z5ZD85t7VdKrKejagtx3yBqqFIj4oaXqeEg6J4Rv8CQ=; b=eLnJiG7f7Bv8QU9yIGtiTkGGSlaBMM6LO8himeEcKf9ewxLSe/pZ6Mf8khiVESdOD3 DiR1oKvk86JBx7egjdv/QU/rqjvTqGANZz25gmuYC1MdEWyx+bGjGYxbVWysgJbJUKP+ ZiuALzaziykNwLh99KwFDRAwackgmKxga/gcvVVzId+bHv3QkdO1NtxPNbVkksRQjaCs v+sRcaynSpT14SVaEqZTp6DSHppPkLWvm7eOZbH39otDruCVYXjmVL9FHQKQEgvxWpKZ ZjBnS7QAvrzDrR81F3dLCHuO6hZF57qLfr4374pFoZLdOLTpT+G92B8hnGAKKLbKwBbE gqcA== X-Gm-Message-State: ALyK8tI8LPFCLtZGm/3FRdN/Unr3PW6V0w3tlGl0HOlyL915pi7PuvFqRtItiONFPkuuEpwAZk/1DG/UlJJiPA== X-Received: by 10.25.26.194 with SMTP id a185mr26122816lfa.167.1469117213010; Thu, 21 Jul 2016 09:06:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 21 Jul 2016 09:06:13 -0700 (PDT) In-Reply-To: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> <8F6598B8-BBE0-4496-B850-51686E63A527@att.com> From: Ted Lemon Date: Thu, 21 Jul 2016 18:06:13 +0200 Message-ID: To: Stuart Cheshire Content-Type: multipart/alternative; boundary=001a11403bd89d7e470538278114 Archived-At: Cc: "dnssd@ietf.org" , "STARK, BARBARA H" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 16:07:08 -0000 --001a11403bd89d7e470538278114 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hm. That's not what I'm saying. The point Barbara made that I agree with and restated was that the device should report the same name no matter who asks or how. IOW, we can't just change its name in the homenet naming infrastructure: it needs to know and accept the new name. In some cases, we don't want to trust the network infrastructure to set our name--e.g., it used to bug the hell out of me when my Mac would take its name from the PTR record and wind up with something nonsensical; fortunately my Chromebook doesn't do this, nor does my Android phone. For these cases, the only alternative we have at present is a UI on the device, or on a web page provided by the device. It might be nice to have a trustworthy mechanism for doing this, but we don't have a security architecture that would support that. However, for other devices, being able to assign the name using the network infrastructure is perfectly fine. I think the main distinction is "infrastructure/IoT devices" versus personal devices that roam with the user. On Thu, Jul 21, 2016 at 5:34 PM, Stuart Cheshire wrote= : > On 21 Jul 2016, at 06:22, STARK, BARBARA H wrote: > > > +1 > > Thx. You said that so much better than I did. :) > > And even where network configuration is desirable, a one-size-fits all > ubiquitous solution is not the right answer. We should not design an > architecture with such a dependency. > > Barbara > > Sorry, I=E2=80=99m getting confused by this discussion. > > The discussion in the meeting was that pretty much all network devices > (apart from my SMA solar inverters) can have their name set today over th= e > network, but not using a one-size-fits-all ubiquitous solution. It=E2=80= =99s ad > hoc. Many devices have their name set via web UI. Some devices have their > name set via some proprietary app. Others have their name set using some > non-web protocol like Apple=E2=80=99s HomeKit. Some have their name set v= ia > physical controls on the device itself. The assertion in the meeting was > that this is no good and we need a one-size-fits-all ubiquitous solution. > UPnP was offered as that one-size-fits-all ubiquitous solution. Now we=E2= =80=99re > saying that a one-size-fits-all ubiquitous solution is *not* the right > answer. > > I=E2=80=99m confused. It sounds like we=E2=80=99re back to saying what we= have already > today is just fine (apart from my SMA solar inverters -- I need to find o= ut > how to file a bug report for that). > > Stuart Cheshire > > --001a11403bd89d7e470538278114 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hm. =C2=A0 That's not what I'm saying.=C2=A0 The p= oint Barbara made that I agree with and restated was that the device should= report the same name no matter who asks or how. =C2=A0 IOW, we can't j= ust change its name in the homenet naming infrastructure: it needs to know = and accept the new name.

In some cases, we don't wan= t to trust the network infrastructure to set our name--e.g., it used to bug= the hell out of me when my Mac would take its name from the PTR record and= wind up with something nonsensical; fortunately my Chromebook doesn't = do this, nor does my Android phone.

For these case= s, the only alternative we have at present is a UI on the device, or on a w= eb page provided by the device. =C2=A0 It might be nice to have a trustwort= hy mechanism for doing this, but we don't have a security architecture = that would support that.

However, for other device= s, being able to assign the name using the network infrastructure is perfec= tly fine. =C2=A0 I think the main distinction is "infrastructure/IoT d= evices" versus personal devices that roam with the user.

On T= hu, Jul 21, 2016 at 5:34 PM, Stuart Cheshire <cheshire@apple.com>= wrote:
On 21 Jul= 2016, at 06:22, STARK, BARBARA H <bs7= 652@att.com> wrote:

> +1
> Thx. You said that so much better than I did. :)
> And even where network configuration is desirable, a one-size-fits all= ubiquitous solution is not the right answer. We should not design an archi= tecture with such a dependency.
> Barbara

Sorry, I=E2=80=99m getting confused by this discussion.

The discussion in the meeting was that pretty much all network devices (apa= rt from my SMA solar inverters) can have their name set today over the netw= ork, but not using a one-size-fits-all ubiquitous solution. It=E2=80=99s ad= hoc. Many devices have their name set via web UI. Some devices have their = name set via some proprietary app. Others have their name set using some no= n-web protocol like Apple=E2=80=99s HomeKit. Some have their name set via p= hysical controls on the device itself. The assertion in the meeting was tha= t this is no good and we need a one-size-fits-all ubiquitous solution. UPnP= was offered as that one-size-fits-all ubiquitous solution. Now we=E2=80=99= re saying that a one-size-fits-all ubiquitous solution is *not* the right a= nswer.

I=E2=80=99m confused. It sounds like we=E2=80=99re back to saying what we h= ave already today is just fine (apart from my SMA solar inverters -- I need= to find out how to file a bug report for that).

Stuart Cheshire


--001a11403bd89d7e470538278114-- From nobody Thu Jul 21 10:07:51 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA2E512D7AA for ; Thu, 21 Jul 2016 10:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.398 X-Spam-Level: X-Spam-Status: No, score=-105.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=apple.com 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 tvRmMZZIlz95 for ; Thu, 21 Jul 2016 10:07:49 -0700 (PDT) Received: from mail-in2.euro.apple.com (mail-in2.euro.apple.com [17.72.148.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E54D412D56E for ; Thu, 21 Jul 2016 10:07:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1469120867; x=2333034467; 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=leXsYzc8zxtzo/r2VBFWZlxYgVHIXrbTcafaHV9Pu0I=; b=jUzDVIhkf2wAMU8bn2glW6+BRat83DTuQ6Fquprm7iifwiwxdjsqqmY4EW75sex+ 4MqL/h3r3Lw4qR4wDSf58z7WdOCTCYQ+bJOlAANrFLsEzpkawuySFGQEuaViD5dF Foi4dGtVUZnHkN0OUh9gdxUTlhmlcZb2g/3B2NPOSU1jws/hn45sz1jf1H8Sk/oh kRCqDsCcnxB3T4dleOsZfih1qAoZErQcaze4bXOg3QTxboQXlwV1L7gkLxD27G6V picKN+WF35sGs8PxSYDasO9nwd5ahdTL6s99FLO7pZzXPTr412qFgmWcKBeeacnD LtRr0zDnmK7/heGsE52PJA==; Received: from relay2.euro.apple.com (relay2.euro.apple.com [17.66.55.12]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail-in2.euro.apple.com (Symantec Mail Security) with SMTP id 90.8C.09044.36101975; Thu, 21 Jul 2016 18:07:47 +0100 (BST) X-AuditID: 1148940c-f798c6d000002354-39-57910163e3b7 Received: from phonehome2 ( [17.72.133.82]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id 38.BE.22244.26101975; Thu, 21 Jul 2016 18:07:47 +0100 (BST) Received: from [IPv6:2001:67c:1231:998:a844:ec00:f33b:a4eb] (nat64-a0.meeting.ietf.org [31.130.238.160]) by phonehome2.euro.apple.com (Oracle Communications Messaging Server 7.0.5.37.0 64bit (built Nov 11 2015)) with ESMTPSA id <0OAO00A7YCWYGJ40@phonehome2.euro.apple.com> for dnssd@ietf.org; Thu, 21 Jul 2016 18:07:46 +0100 (IST) Sender: cheshire@apple.com Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Stuart Cheshire In-reply-to: Date: Thu, 21 Jul 2016 10:07:45 -0700 Content-transfer-encoding: quoted-printable Message-id: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> <8F6598B8-BBE0-4496-B850-51686E63A527@att.com> To: Ted Lemon X-Mailer: Apple Mail (2.3124) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUi6GTOo5vMODHcYO16Zov3S2cxOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4+b8LpaCa6wV0yZ/YGtg3MXSxcjJISFgIvGs5QcjhC0mceHe ejYQW0hgHZPEjFkeMDXN7XNYuxi5gOK9TBLnWnrYIZxLTBK3F/1hBqkSFpCSeLXyM5DNwcEs oC4xZUouSJhXQE9i8tEGNogSI4kV/w+ALWYT0JJ48fkKWJxTIFjiz/0b7CA2i4CqxLVTd8Hi zAJeEnOanrND2NoST95dYIWYaSPRu7udCeKG68wSSy59AEuICChIzD2zhgnialmJJycXsYAU SQh0sEk8/PyeZQKjyCyE+2YhuW8Wkh0LGJlXMYrnJmbm6GbmGemllhbl6yUWFOSk6iXn525i BAW6xxSeHYwXDxoeYhTgYFTi4TV4NyFciDWxrLgy9xCjBAezkghvzS+gEG9KYmVValF+fFFp TmrxIUZpDhYlcd6GQ0XhQgLpiSWp2ampBalFMFkmDk6pBsaZPK1TbpiHTbwgt/2aVEqxU+Wu qxxTw+Zsy7zpkB92gk0ncOXWFo6lXAJT5mrfPa8g4av/cYbqhqKVCe3XlzWV/l/9kvv1khUx a5VNDC7vVHb5ekbBZ9WM8FTpk80Jli16azv++qlH1j7cFtKesKrqpKlDxUuda0pyc9tagexT a2eVObobKrEUZyQaajEXFScCAJ+fSMtwAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUi6NEapJvMODHcYMUTRov3S2cxOjB6LFny kymAMYrLJiU1J7MstUjfLoEr4+b8LpaCa6wV0yZ/YGtg3MXSxcjJISFgItHcPocVwhaTuHBv PVsXIxeHkEAvk8S5lh52COcSk8TtRX+YQaqEBaQkXq38DGRzcDALqEtMmZILEuYV0JOYfLSB DaLESGLF/wNgC9gEtCRefL4CFucUCJb4c/8GO4jNIqAqce3UXbA4s4CXxJym5+wQtrbEk3cX WCFm2kj07m5ngrjhOrPEkksfwBIiAgoSc8+sYYK4WlbiyclFLBMYBWchnDQLyUmzkIxdwMi8 ilG0KDUnsdJIL7W0KF8vsaAgJ1UvOT93EyMoNJ3MeXYwvjpoeIhRgINRiYfX4v2EcCHWxLLi ytxDjBIczEoivDW/gEK8KYmVValF+fFFpTmpxYcYpTlYlMR5/Q5ohwsJpCeWpGanphakFsFk mTg4pRoYryx+c/K2wcWlOi/S5x044/nm4UUbzbinp/Z13X4qXvpvdpOMh2nu3OWSdcd7f81f rHxa2+dymvtd7bit8feOd5056XJmXbE7x/anP3PubEifmRsYIvs2ad++ubtqb+uuqPrLzGkk uJRF4F/pH2mT47EHk/K5zpq+VFObN0H/k17lqzmz5BoexSqxFGckGmoxFxUnAgDS8WYaSQIA AA== Archived-At: Cc: "dnssd@ietf.org" , "STARK, BARBARA H" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 17:07:51 -0000 On 21 Jul 2016, at 09:06, Ted Lemon wrote: > Hm. That's not what I'm saying. The point Barbara made that I agree = with and restated was that the device should report the same name no = matter who asks or how. For the most part, this is universally true today. Of all the devices = I=E2=80=99ve seen that support both UPnP and Bonjour DNS-SD/mDNS, = virtually have a single place in the web UI to set the name, which is = then used for both discovery protocols. I have seen a few some rare exceptions where they allow you to set two = different names if you want, but I=E2=80=99ve never seen any case where = the user didn=E2=80=99t set them both to the same thing. Stuart Cheshire From nobody Thu Jul 21 10:24:50 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D32C12D799 for ; Thu, 21 Jul 2016 10:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 sstJzGxSvoVU for ; Thu, 21 Jul 2016 10:24:47 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 234EF12D619 for ; Thu, 21 Jul 2016 10:24:47 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id b199so67735791lfe.0 for ; Thu, 21 Jul 2016 10:24:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NR4WaT+iqmv9TRqYcprBXSZzLvERPz/HkPeMp4LGJJ0=; b=laZPzBaSogb+pRb5McDLH0v6qzz4Zj9ubQnsvXkI64YUltysttQp61zcASwpyyS96D pvpQlhSBjEGhHJGlfDcotDb2D8khIhNBhGnyarwktOWVBbfDATdK2fA5uDNefBNMA3yg tGfp7zsW2U+BIaNtF6OjUWZO6UFKo8BzRzfYiBSwYWQKSgTEl4riz26l609ejv5VGDM+ cLGs/1JQ/l+crUXq56PgoZu9Y/xkTGfH7k+VXaFG0CNt4CsBnPiH8I4Ya0S6eZFijg7x h9w3Vc3PrrKwona/mJ/UaoY5R/2NzG83PtWTHksHxqzc3ersT0WcaMGFWb2BsEi0svdJ Xb4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NR4WaT+iqmv9TRqYcprBXSZzLvERPz/HkPeMp4LGJJ0=; b=Y+dMVnF+qymmKroJe4ciW6rmEsCHhUf4J+nf782W+D+rzrmjo1g//9wtFsh2FrzR3B LZK5f22JjUaz3gy9xO6LbGT7EtHZHkI0lmvkcmzXSuAjD7OYXMuqjBjRvhsVdBbHSShM Ffxwu/MqGWc1mHOthmjp1N6HW1cmDrguGBO9Xe5UCbhfmq5H0meGnd0sk8FJw2srYuYP ROksQxgf7ZnNqNzaOaqo+l4NKML/QvsYj3kjfW4mee2F5/UMGGfqH/yaDarlhWoNj4hj cpCMlzhoB/OVQAKJ4ua8evBIZ3gLyzy8LmZ8dP7jFh44yhTjbMW5S8vXOv+9gq2a4vAk 7Yvg== X-Gm-Message-State: ALyK8tIzFdAT4c2Puwlau96iWd7YE+Ua1QzyPeWMM/59VLPey3wUmmaKca5IguQYHKenDY1b1ON58zTjZnF6aQ== X-Received: by 10.25.42.207 with SMTP id q198mr22469646lfq.181.1469121885298; Thu, 21 Jul 2016 10:24:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Thu, 21 Jul 2016 10:24:05 -0700 (PDT) In-Reply-To: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> <8F6598B8-BBE0-4496-B850-51686E63A527@att.com> From: Ted Lemon Date: Thu, 21 Jul 2016 19:24:05 +0200 Message-ID: To: Stuart Cheshire Content-Type: multipart/alternative; boundary=001a11411dba1aea3805382898e3 Archived-At: Cc: "dnssd@ietf.org" , "STARK, BARBARA H" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2016 17:24:49 -0000 --001a11411dba1aea3805382898e3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Right, the issue would be if we changed it in the database operated by the homenet, and didn't tell the host. On Thu, Jul 21, 2016 at 7:07 PM, Stuart Cheshire wrote= : > On 21 Jul 2016, at 09:06, Ted Lemon wrote: > > > Hm. That's not what I'm saying. The point Barbara made that I agree > with and restated was that the device should report the same name no matt= er > who asks or how. > > For the most part, this is universally true today. Of all the devices I= =E2=80=99ve > seen that support both UPnP and Bonjour DNS-SD/mDNS, virtually have a > single place in the web UI to set the name, which is then used for both > discovery protocols. > > I have seen a few some rare exceptions where they allow you to set two > different names if you want, but I=E2=80=99ve never seen any case where t= he user > didn=E2=80=99t set them both to the same thing. > > Stuart Cheshire > > --001a11411dba1aea3805382898e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Right, the issue would be if we changed it in the database= operated by the homenet, and didn't tell the host.

On Thu, Jul 21, 2016 at 7:07 PM= , Stuart Cheshire <cheshire@apple.com> wrote:
On 21 Jul 2016, at 09:06, Ted Lemon &= lt;mellon@fugue.com> wrote:

> Hm.=C2=A0 =C2=A0That's not what I'm saying.=C2=A0 The point Ba= rbara made that I agree with and restated was that the device should report= the same name no matter who asks or how.

For the most part, this is universally true today. Of all the device= s I=E2=80=99ve seen that support both UPnP and Bonjour DNS-SD/mDNS, virtual= ly have a single place in the web UI to set the name, which is then used fo= r both discovery protocols.

I have seen a few some rare exceptions where they allow you to set two diff= erent names if you want, but I=E2=80=99ve never seen any case where the use= r didn=E2=80=99t set them both to the same thing.

Stuart Cheshire


--001a11411dba1aea3805382898e3-- From nobody Sun Jul 24 02:05:33 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8550D12D115 for ; Sun, 24 Jul 2016 02:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 yW2iX-GWKocq for ; Sun, 24 Jul 2016 02:05:31 -0700 (PDT) Received: from xsmtp01.mail2web.com (xsmtp01.mail2web.com [168.144.250.230]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C85B12B01B for ; Sun, 24 Jul 2016 02:05:31 -0700 (PDT) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bRFIr-0004cv-Au for dnssd@ietf.org; Sun, 24 Jul 2016 05:05:30 -0400 Received: (qmail 13533 invoked from network); 24 Jul 2016 09:02:28 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[90.54.87.84]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 24 Jul 2016 09:02:27 -0000 From: "Christian Huitema" To: "'Ted Lemon'" , "'Stuart Cheshire'" References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> <8F6598B8-BBE0-4496-B850-51686E63A527@att.com> In-Reply-To: Date: Sun, 24 Jul 2016 11:02:26 +0200 Message-ID: <009d01d1e58a$1cdd7ca0$569875e0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKfnuZIyEEmc88/z8GE+crHEvfQPwGQVMAYAiJJWUYB3nkQBwHA3mAnAsoukakBZtKyvAJc+ds/Apy89lgCLrmw6p32eMHQ Content-Language: en-us Archived-At: Cc: dnssd@ietf.org, "'STARK, BARBARA H'" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 09:05:32 -0000 On Thursday, July 21, 2016 7:24 PM, Ted Lemon wrote: > Right, the issue would be if we changed it in the database operated by = > the homenet, and didn't tell the host. > > On Thu, Jul 21, 2016 at 7:07 PM, Stuart Cheshire = wrote: >> On 21 Jul 2016, at 09:06, Ted Lemon wrote: >> >>> Hm. That's not what I'm saying. The point Barbara made that I = agree with and restated was that the device should report the same name = no matter who asks or how. >> >> For the most part, this is universally true today. Of all the devices = I=E2=80=99ve seen that support both UPnP and Bonjour DNS-SD/mDNS, = virtually have a single place in the web UI to set the name, which is = then used for both discovery protocols. Please let's not forget the privacy issues for mobile devices. There is = an intarea draft about that, "hostname practices considered harmful." In = short, volunteering a name to the network allows tracking; volunteering = a user friendly name like "Ted Lemon's laptop" allows for even better = tracking. For DHCP, the "privacy" recommendation is to not volunteer a name at all = to the DHCP server, or to use a one-time random name.=20 Now, I can understand that these one-time random names should be more = user friendly than "F78AC123", maybe using something like = "correct-horse-battery-staple" in the tradition of = https://www.xkcd.com/936/.=20 -- Christian Huitema From nobody Sun Jul 24 02:09:17 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CFA412D115 for ; Sun, 24 Jul 2016 02:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=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 YgwKARRnJcrE for ; Sun, 24 Jul 2016 02:09:15 -0700 (PDT) Received: from xsmtp04.mail2web.com (xsmtp24.mail2web.com [168.144.250.190]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468BE12B01B for ; Sun, 24 Jul 2016 02:09:15 -0700 (PDT) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bRFPK-00037A-41 for dnssd@ietf.org; Sun, 24 Jul 2016 05:09:14 -0400 Received: (qmail 13533 invoked from network); 24 Jul 2016 09:02:28 -0000 Received: from unknown (HELO huitema1) (Authenticated-user:_huitema@huitema.net@[90.54.87.84]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 24 Jul 2016 09:02:27 -0000 From: "Christian Huitema" To: "'Ted Lemon'" , "'Stuart Cheshire'" References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> <8F6598B8-BBE0-4496-B850-51686E63A527@att.com> In-Reply-To: Date: Sun, 24 Jul 2016 11:02:26 +0200 Message-ID: <009d01d1e58a$1cdd7ca0$569875e0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKfnuZIyEEmc88/z8GE+crHEvfQPwGQVMAYAiJJWUYB3nkQBwHA3mAnAsoukakBZtKyvAJc+ds/Apy89lgCLrmw6p32eMHQ Content-Language: en-us Archived-At: Cc: dnssd@ietf.org, "'STARK, BARBARA H'" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 09:09:16 -0000 On Thursday, July 21, 2016 7:24 PM, Ted Lemon wrote: > Right, the issue would be if we changed it in the database operated by = > the homenet, and didn't tell the host. > > On Thu, Jul 21, 2016 at 7:07 PM, Stuart Cheshire = wrote: >> On 21 Jul 2016, at 09:06, Ted Lemon wrote: >> >>> Hm. That's not what I'm saying. The point Barbara made that I = agree with and restated was that the device should report the same name = no matter who asks or how. >> >> For the most part, this is universally true today. Of all the devices = I=E2=80=99ve seen that support both UPnP and Bonjour DNS-SD/mDNS, = virtually have a single place in the web UI to set the name, which is = then used for both discovery protocols. Please let's not forget the privacy issues for mobile devices. There is = an intarea draft about that, "hostname practices considered harmful." In = short, volunteering a name to the network allows tracking; volunteering = a user friendly name like "Ted Lemon's laptop" allows for even better = tracking. For DHCP, the "privacy" recommendation is to not volunteer a name at all = to the DHCP server, or to use a one-time random name.=20 Now, I can understand that these one-time random names should be more = user friendly than "F78AC123", maybe using something like = "correct-horse-battery-staple" in the tradition of = https://www.xkcd.com/936/.=20 -- Christian Huitema From nobody Sun Jul 24 03:14:44 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2644312D133 for ; Sun, 24 Jul 2016 03:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 g-4VkBCTrz7y for ; Sun, 24 Jul 2016 03:14:41 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 EDD3C12D846 for ; Sun, 24 Jul 2016 03:14:40 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id l69so111135381lfg.1 for ; Sun, 24 Jul 2016 03:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=fZc+50EU9QJdbl3op5J+sBp+zuDPknEtuaLnUfVXW6E=; b=rNNI0JTZDM4wl2eLTFJXHmbtJ69iqIQy3FGpzjUdQVstphGMKNr6kYyhmdc7V5WeiZ pCRI9nAsXSFZr9lR2QFghGBNqht/1XckX0dUVWmfc2V33qlXv0cBTHFRcsH0Tyic2xkl xiV5WwAaMRaldTd+59sEu9EB0/MsamfPrgUfYiyVaAj55PClqK6CpvgLQy2iZ4vkkw6/ wlPH638RvTCtDm62fVyc+9M2Rl5RJJRCBDC1W9Vb9f8NRQJD7fDc3gvirnlfKdNG6E2m NBL6Fl76Xe9pGzSr6w6DpxaNrTpzsKt/uR1hX6wOaI8X3bUNRcIiVd74YknK9Bzn94NU 5XoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fZc+50EU9QJdbl3op5J+sBp+zuDPknEtuaLnUfVXW6E=; b=TOZnenrg8FO/CduTCC1hh5dCQ44lOQdm6M1QrhZEZBI+NKecsrVGo09c7SQeEao4E0 UR3jZdA5Ysnu3QkltvPBV2ytLByEQAlTD7X3nW80eHMfammVgleuxsm6hXNkhWEFoWz7 fKavXk6OEjJG6qzECG/RSyn2rcWW4AVitKjC61qmoJraUkMOxKhWBnV45+9ffYFTJGSu ULW3ayU3McqKV61dzexm8xWxAiL5SJGoQh24YBMtYNYQD4VOWAJyMYYYsrXfynvmlg0H T2qduLQsDKVjVq/QaFC8PReQrUFqD0YEOo1SrccEKNNljTxYaPiGXIkSg/P9aWxm6NHn yQZg== X-Gm-Message-State: AEkooutAsrxxkYgixbJZ52z1P6X1w+prqHtVuFU/3JninQ4RKlkhM1FJg0A9ZqVMkkd7W7L15j3b8VQq7HfNyQ== MIME-Version: 1.0 X-Received: by 10.25.131.150 with SMTP id f144mr5193787lfd.53.1469355278861; Sun, 24 Jul 2016 03:14:38 -0700 (PDT) Received: by 10.25.217.93 with HTTP; Sun, 24 Jul 2016 03:14:38 -0700 (PDT) Received: by 10.25.217.93 with HTTP; Sun, 24 Jul 2016 03:14:38 -0700 (PDT) In-Reply-To: <009d01d1e58a$1cdd7ca0$569875e0$@huitema.net> References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> <8F6598B8-BBE0-4496-B850-51686E63A527@att.com> <009d01d1e58a$1cdd7ca0$569875e0$@huitema.net> Date: Sun, 24 Jul 2016 12:14:38 +0200 Message-ID: From: Ted Lemon To: Christian Huitema Content-Type: multipart/alternative; boundary=001a113f20b8721d4705385eefb9 Archived-At: Cc: Stuart Cheshire , dnssd@ietf.org, "STARK, BARBARA H" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2016 10:14:43 -0000 --001a113f20b8721d4705385eefb9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes. There are two separate problems here: how to name services that are being advertised, for which presumably we do not want privacy, and how to deal with devices whose identification should be private, but with which there might still be a need to rendezvous. The reason I was so enthusiastic about your presentation in dnssd is that it very nicely solves this second problem. But we still have the first problem. On Jul 24, 2016 11:02 AM, "Christian Huitema" wrote: > On Thursday, July 21, 2016 7:24 PM, Ted Lemon wrote: > > > Right, the issue would be if we changed it in the database operated by > > the homenet, and didn't tell the host. > > > > On Thu, Jul 21, 2016 at 7:07 PM, Stuart Cheshire cheshire@apple.com> wrote: > >> On 21 Jul 2016, at 09:06, Ted Lemon wrote: > >> > >>> Hm. That's not what I'm saying. The point Barbara made that I agre= e > with and restated was that the device should report the same name no matt= er > who asks or how. > >> > >> For the most part, this is universally true today. Of all the devices > I=E2=80=99ve seen that support both UPnP and Bonjour DNS-SD/mDNS, virtual= ly have a > single place in the web UI to set the name, which is then used for both > discovery protocols. > > Please let's not forget the privacy issues for mobile devices. There is a= n > intarea draft about that, "hostname practices considered harmful." In > short, volunteering a name to the network allows tracking; volunteering a > user friendly name like "Ted Lemon's laptop" allows for even better > tracking. > > For DHCP, the "privacy" recommendation is to not volunteer a name at all > to the DHCP server, or to use a one-time random name. > > Now, I can understand that these one-time random names should be more use= r > friendly than "F78AC123", maybe using something like > "correct-horse-battery-staple" in the tradition of > https://www.xkcd.com/936/. > > -- Christian Huitema > > > > --001a113f20b8721d4705385eefb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes. There are two separate problems here: how to name servi= ces that are being advertised, for which presumably we do not want privacy,= and how to deal with devices whose identification should be private, but w= ith which there might still be a need to rendezvous.

The reason I was so enthusiastic about your presentation in = dnssd is that it very nicely solves this second=C2=A0 problem.=C2=A0 But we= still have the first problem.


On Jul 24, 2016 1= 1:02 AM, "Christian Huitema" <huitema@huitema.net> wrote:
On Thursday, July 21, 2016 7:24 PM, Ted Lemon wrote:<= br>
> Right, the issue would be if we changed it in the database operated by=
> the homenet, and didn't tell the host.
>
> On Thu, Jul 21, 2016 at 7:07 PM, Stuart Cheshire <mailto:cheshire@apple.com> wrote:
>> On 21 Jul 2016, at 09:06, Ted Lemon <mailto:mellon@fugue.com> wrote:
>>
>>> Hm.=C2=A0 =C2=A0That's not what I'm saying.=C2=A0 The = point Barbara made that I agree with and restated was that the device shoul= d report the same name no matter who asks or how.
>>
>> For the most part, this is universally true today. Of all the devi= ces I=E2=80=99ve seen that support both UPnP and Bonjour DNS-SD/mDNS, virtu= ally have a single place in the web UI to set the name, which is then used = for both discovery protocols.

Please let's not forget the privacy issues for mobile devices. There is= an intarea draft about that, "hostname practices considered harmful.&= quot; In short, volunteering a name to the network allows tracking; volunte= ering a user friendly name like "Ted Lemon's laptop" allows f= or even better tracking.

For DHCP, the "privacy" recommendation is to not volunteer a name= at all to the DHCP server, or to use a one-time random name.

Now, I can understand that these one-time random names should be more user = friendly than "F78AC123", maybe using something like "correc= t-horse-battery-staple" in the tradition of https://www.xkcd.com/936/<= /a>.

-- Christian Huitema



--001a113f20b8721d4705385eefb9-- From nobody Mon Jul 25 07:03:51 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6768912D8A3 for ; Mon, 25 Jul 2016 07:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com 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 sPHrsMYyz-p6 for ; Mon, 25 Jul 2016 07:03:47 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FD612D0DD for ; Mon, 25 Jul 2016 07:03:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=aZ7oNAtQWrfwVms+3hAHXrmoqNbo/bEvQrEWrTF/904=; b=Az7ch/nMrZEEkM+ah8PK1JYPgiuD3MR2FpsUW1a+AsA0j07oc6PP0ss3nWmRurWa12nrO09+q/WuDOUiX+ZOldMXLpLWzM/ywMfFhJuSuDEOHmSUNsPQXZ3W00TGbRQNJ1Xpl+POaZrTWJkwnCy4vPHlagoHGd9XElSFGx1y9pM= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0214.outbound.protection.outlook.com [213.199.154.214]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-37-41M1HnaVOXOddRkMWtSpWQ-1; Mon, 25 Jul 2016 15:03:35 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Mon, 25 Jul 2016 14:03:32 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Mon, 25 Jul 2016 14:03:33 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: IETF96 meeting summary Thread-Index: AQHR5n1UGoxgF+Ec9E6wyuShBFXlHw== Date: Mon, 25 Jul 2016 14:03:32 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:e562:f526:a39d:e3a0] x-ms-office365-filtering-correlation-id: 296fe7f2-e71e-4e79-41a4-08d3b49476d3 x-microsoft-exchange-diagnostics: 1; AMSPR07MB454; 20:uTSBse35ATsg6RNQB+ZQ8kW2mZh584u1GdmjxKif7JOCSzMYJIofOMZYnSYIG5DMrSj3SYX9gTTtv9NQeIuZQshwUYMiInzD45MKF3BDkpsASedF6o3Laj4WnBr6Yk61FzEyE/9cJikPTV1YJeoBGVdvGtxg+b2n/BKq7UguKP8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB454; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB454; x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(199003)(7846002)(92566002)(122556002)(81156014)(1730700003)(7906003)(105586002)(8936002)(36756003)(10400500002)(68736007)(16236675004)(50226002)(3660700001)(102836003)(6116002)(33656002)(19617315012)(3280700002)(586003)(101416001)(31430400001)(7736002)(81166006)(5640700001)(8676002)(74482002)(50986999)(77096005)(15975445007)(19580395003)(86362001)(2900100001)(107886002)(110136002)(106116001)(82746002)(97736004)(87936001)(450100001)(2906002)(57306001)(5890100001)(106356001)(189998001)(5002640100001)(83716003)(229853001)(2351001)(2501003)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB454; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2016 14:03:32.9976 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB454 X-MC-Unique: 41M1HnaVOXOddRkMWtSpWQ-1 Content-Type: multipart/alternative; boundary="_000_F62E4C9353F349BDA152762145BC2305jiscacuk_" Archived-At: Subject: [dnssd] IETF96 meeting summary X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 14:03:50 -0000 --_000_F62E4C9353F349BDA152762145BC2305jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNClJhbHBoIGFuZCBJIHByb2R1Y2VkIGEgc2hvcnQgc3VtbWFyeSBmb3Igb3VyIEFELCB3 aGljaCBpcyBhdHRhY2hlZCBiZWxvdy4NCg0KVGhpcyBhbmQgb3RoZXIgSW50IEFyZWEgc3VtbWFy aWVzIGNhbiBhbHNvIGJlIGZvdW5kIGF0IGh0dHBzOi8vdHJhYy50b29scy5pZXRmLm9yZy9hcmVh L2ludC90cmFjL3dpa2kvSUVURjk2Lg0KDQpUaW0NCg0K4oCUDQoNCkROU1NEIFdHIE1lZXRpbmcg U3VtbWFyeSBJRVRGLTk2DQoNCkRpc2N1c3Npb246IFVwZGF0ZXMgdG8gRE5TLVNEIGh5YnJpZCBw cm94eQ0KV2FpdGluZyBvbiBTdHVhcnQgQ2hlc2hpcmUgdG8gZWRpdCAiSHlicmlkIFVuaWNhc3Qv TXVsdGljYXN0IEROUy1CYXNlZCBTZXJ2aWNlIERpc2NvdmVyeSIgZHJhZnQtaWV0Zi1kbnNzZC1o eWJyaWQtMDM8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kbnNzZC1oeWJy aWQtMDM+LCBiYXNlZCBvbiBpbnB1dCByZWNlaXZlZCBkdXJpbmcgV0cgbGFzdCBjYWxsICh3aGlj aCBjb21wbGV0ZWQgYmVmb3JlIElFVEYtOTUpLiBTdHVhcnQgcHJvbWlzZWQgcmV2aXNpb24gd2ls bCBiZSBwdWJsaXNoZWQgaW4gQXVndXN0LiBPbmNlIHJldmlzaW9uIGlzIHB1Ymxpc2hlZCwgV0cg d2lsbCBjb25maXJtIHRoYXQgdGhlIGVkaXRzIHNhdGlzZnkgV0cgbGFzdCBjYWxsIGlucHV0IGFu ZCB0aGVuIHRoZSBkb2N1bWVudCB3aWxsIGJlIHNlbnQgdG8gdGhlIElFU0cuDQoNCkRpc2N1c3Np b246IEROUyBQdXNoIE5vdGlmaWNhdGlvbnMNCldHIGFncmVlZCBhdCBJRVRGLTk1IHRvIHNwbGl0 IG91dCB0aGUgc2lnbmFsbGluZyBwYXJ0IGZyb20gdGhlIGNvbm5lY3Rpb24gbWFuYWdlbWVudCBw YXJ0LiBUaGlzIGRldGFpbHMgb2YgdGhpcyBzcGxpdCBoYXMgYmVlbiBhZ3JlZWQuIFRoZSBkbnNv cCBXRyBoYXMgdGhlIHJlc3BvbnNpYmlsaXR5IGZvciAiRE5TIFNlc3Npb24gU2lnbmFsaW5nIiwg ZHJhZnQtYmVsbGlzLWRuc29wLXNlc3Npb24tc2lnbmFsLTAwPGh0dHA6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWJlbGxpcy1kbnNvcC1zZXNzaW9uLXNpZ25hbC0wMD4gYW5kIHRoZSBkbnNz ZCBXRyBoYXMgdGhlIHJlc3BvbnNpYmlsaXR5IGZvciAiRE5TIFB1c2ggTm90aWZpY2F0aW9ucyIg ZHJhZnQtaWV0Zi1kbnNzZC1wdXNoLTA4PGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWlldGYtZG5zc2QtcHVzaC0wOD4uIFRoZSBpbml0aWFsIGZvY3VzIHdpbGwgYmUgZ2V0dGluZyB0 aGUgc2lnbmFsbGluZyBkcmFmdCBjb21wbGV0ZSwgd2hpY2ggc2hvdWxkIGhhcHBlbiBxdWlja2x5 LCBhbmQgdGhlbiB0aGUgRE5TIFB1c2ggZHJhZnQgd2lsbCBiZSByZXZpc2VkIGJhc2VkIG9uIHRo ZSBzaWduYWxpbmcgZHJhZnQgdXBkYXRlLiBUaGUgc2lnbmFsbGluZyBkcmFmdCBhdXRob3JzIHBy b21pc2VkIGEgLTAxIHVwZGF0ZSBieSB0aGUgZW5kIG9mIHRoZSBJRVRGIHdlZWssIGFuZCB0aGUg ZG5zb3AgY2hhaXJzIHdpbGwgdGhlbiBhc2sgZm9yIGRuc29wIFdHIGFkb3B0aW9uLg0KDQpEaXNj dXNzaW9uOiBETlMgVXBkYXRlIGFuZCBtRE5TL2h5YnJpZCBwcm94eSBjb2V4aXN0ZW5jZQ0KVGVk IExlbW9uIGhhcyB3cml0dGVuICJIb21lbmV0IE5hbWluZyBhbmQgU2VydmljZSBEaXNjb3Zlcnkg QXJjaGl0ZWN0dXJlIiBkcmFmdC1sZW1vbi1ob21lbmV0LW5hbWluZy1hcmNoaXRlY3R1cmUtMDE8 aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGVtb24taG9tZW5ldC1uYW1pbmctYXJj aGl0ZWN0dXJlLTAxPiB3aGljaCBkaXNjdXNzZXMgZHluYW1pYyBETlMgdXBkYXRlIGFuZCBETlMg aHlicmlkIHByb3h5IHNlcnZpY2VzIGFuZCBuYW1pbmcgcmVxdWlyZW1lbnRzIGluIHRoZSBjb250 ZXh0IG9mIHRoZSBob21lbmV0IFdHLiBJbiB0aGUgZG5zc2QgbWVldGluZywgaXQgd2FzIGFncmVl ZCB0aGF0IFRlZCB3b3VsZCBwcm9ncmVzcyBhIG5ldyAiZmxhdCBob21lbmV0IiBkcmFmdCB3aGlj aCB3b3VsZCBkZXNjcmliZSBob3cgRE5TLVNEIGNvdWxkIHdvcmsgaW4gYSBob21lbmV0IHdpdGgg YSBmbGF0IG5hbWUgc3BhY2UuIFRoZSB1c2Ugb2YgRE5TIFVwZGF0ZSBhbG9uZ3NpZGUgYSBjb25m aWd1cmVkIGh5YnJpZCBwcm94eSBhbHNvIG5lZWRzIHRvIGJlIGRpc2N1c3NlZCBmb3IgdGhlIG1h bmFnZWQgZW50ZXJwcmlzZS9jYW1wdXMgY2FzZS4NCg0KRGlzY3Vzc2lvbjogUmVjb21tZW5kYXRp b25zIGZvciB1c2luZyB0aGUgaHlicmlkIHByb3h5DQpSYWxwaCBEcm9tcyBnYXZlIGEgc2hvcnQg cHJlc2VudGF0aW9uIG91dGxpbmluZyB0aGUgY29tcG9uZW50cyBvZiB1bmljYXN0IEROUy1TRCB0 aGF0IGNhbiBiZSBjb21iaW5lZCBpbiBkaWZmZXJlbnQgd2F5cyB0byBtZWV0IGRpZmZlcmVudCBk ZXBsb3ltZW50IHJlcXVpcmVtZW50cy4gVGhlIGNvbnRlbnQgaW4gdGhlIHByZXNlbnRhdGlvbiB3 aWxsIGJlIGluY29ycG9yYXRlZCBpbnRvIGEgbmV3IGRyYWZ0IGRlc2NyaWJpbmcgQkNQIGZvciB1 bmljYXN0IEROUy1TRCBkZXBsb3ltZW50LiBPdGhlciBhc3BlY3RzIG1heSBiZSBjb3ZlcmVkLCBz dWNoIGFzIHVzZXIgaW50ZXJmYWNlIGNvbnNpZGVyYXRpb25zLCB0aG91Z2ggVUkgZGVzaWduIGlz IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBXRy4gVG9tIFB1c2F0ZXJpIGhhcyBhIGNhbmRpZGF0 ZSBkcmFmdCBkZXNjcmliaW5nIGV4YW1wbGVzIG9mIEROUy1TRCBjb25maWd1cmF0aW9ucywgd2hp Y2ggd2lsbCBhbHNvIGZlZWQgaW50byB0aGlzIHByb2Nlc3MuDQoNCkRyYWZ0IHJldmlldzogUHJp dmFjeSBFeHRlbnNpb25zIGZvciBETlMtU0QNCkRhbmllbCBLYWlzZXIgZGlzY3Vzc2VkIHVwZGF0 ZXMgdG8gIlByaXZhY3kgRXh0ZW5zaW9ucyBmb3IgRE5TLVNEIiBkcmFmdC1odWl0ZW1hLWRuc3Nk LXByaXZhY3ktMDE8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVpdGVtYS1kbnNz ZC1wcml2YWN5LTAxPi4gVGhlIG5ldyByZXZpc2lvbiBkZXNjcmliZXMgYSBwb3RlbnRpYWwgc29s dXRpb24gYmFzZWQgb24gc2FtZS1vd25lciBhbmQgZGlmZmVyZW50LW93bmVyIHBhaXJpbmcuIFRo ZSBXRyBleHByZXNzZWQgaW50ZXJlc3QgaW4gdGhlIHJvb20gaW4gYWRvcHRpbmcgdGhlIGRvY3Vt ZW50IGFzIGEgV0cgd29yayBpdGVtLiBUaGUgY2hhaXJzIHdpbGwgY29uZmlybSB0aGlzIGNvbnNl bnN1cyBvbiB0aGUgbWFpbGluZyBsaXN0LiBUaGUgQURzIHdpbGwgZGlzY3VzcyB3aGVyZSB0aGUg ZGVzY3JpYmVkIHBhaXJpbmcgcHJvdG9jb2wgc2hvdWxkIGJlIHByb2dyZXNzZWQuDQoNCg== --_000_F62E4C9353F349BDA152762145BC2305jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <0E40DEC31C99F54593A1706356D4A0E0@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5SYWxwaCBhbmQgSSBwcm9kdWNlZCBh IHNob3J0IHN1bW1hcnkgZm9yIG91ciBBRCwgd2hpY2ggaXMgYXR0YWNoZWQgYmVsb3cuPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlz IGFuZCBvdGhlciBJbnQgQXJlYSBzdW1tYXJpZXMgY2FuIGFsc28gYmUgZm91bmQgYXQmbmJzcDs8 YSBocmVmPSJodHRwczovL3RyYWMudG9vbHMuaWV0Zi5vcmcvYXJlYS9pbnQvdHJhYy93aWtpL0lF VEY5NiIgY2xhc3M9IiI+aHR0cHM6Ly90cmFjLnRvb2xzLmlldGYub3JnL2FyZWEvaW50L3RyYWMv d2lraS9JRVRGOTY8L2E+LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5UaW0mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IndlYmtpdC1ibG9jay1wbGFjZWhvbGRlciI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+4oCUPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDog bm9ybWFsOyIgY2xhc3M9IiI+RE5TU0QgV0cgTWVldGluZyBTdW1tYXJ5IElFVEYtOTY8L2Rpdj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyBtaW4taGVpZ2h0 OiAxNHB4OyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsiIGNsYXNzPSIiPkRpc2N1c3Npb246IFVwZGF0 ZXMgdG8gRE5TLVNEIGh5YnJpZCBwcm94eTwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj5XYWl0aW5nIG9uIFN0dWFydCBDaGVzaGly ZSB0byBlZGl0ICZxdW90O0h5YnJpZCBVbmljYXN0L011bHRpY2FzdCBETlMtQmFzZWQgU2Vydmlj ZSBEaXNjb3ZlcnkmcXVvdDsNCjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtZG5zc2QtaHlicmlkLTAzIiBjbGFzcz0iIj5kcmFmdC1pZXRmLWRuc3NkLWh5YnJp ZC0wMzwvYT4sIGJhc2VkIG9uIGlucHV0IHJlY2VpdmVkIGR1cmluZyBXRyBsYXN0IGNhbGwgKHdo aWNoIGNvbXBsZXRlZCBiZWZvcmUgSUVURi05NSkuIFN0dWFydCBwcm9taXNlZCByZXZpc2lvbiB3 aWxsIGJlIHB1Ymxpc2hlZCBpbiBBdWd1c3QuIE9uY2UgcmV2aXNpb24gaXMgcHVibGlzaGVkLA0K IFdHIHdpbGwgY29uZmlybSB0aGF0IHRoZSBlZGl0cyBzYXRpc2Z5IFdHIGxhc3QgY2FsbCBpbnB1 dCBhbmQgdGhlbiB0aGUgZG9jdW1lbnQgd2lsbCBiZSBzZW50IHRvIHRoZSBJRVNHLjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG1pbi1oZWlnaHQ6 IDE0cHg7IiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9IiI+RGlzY3Vzc2lvbjogRE5TIFB1 c2ggTm90aWZpY2F0aW9uczwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IiBjbGFzcz0iIj5XRyBhZ3JlZWQgYXQgSUVURi05NSB0byBzcGxpdCBvdXQg dGhlIHNpZ25hbGxpbmcgcGFydCBmcm9tIHRoZSBjb25uZWN0aW9uIG1hbmFnZW1lbnQgcGFydC4g VGhpcyBkZXRhaWxzIG9mIHRoaXMgc3BsaXQgaGFzIGJlZW4gYWdyZWVkLiBUaGUgZG5zb3AgV0cg aGFzIHRoZSByZXNwb25zaWJpbGl0eSBmb3IgJnF1b3Q7RE5TIFNlc3Npb24gU2lnbmFsaW5nJnF1 b3Q7LA0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmVsbGlzLWRu c29wLXNlc3Npb24tc2lnbmFsLTAwIiBjbGFzcz0iIj4NCmRyYWZ0LWJlbGxpcy1kbnNvcC1zZXNz aW9uLXNpZ25hbC0wMDwvYT4gYW5kIHRoZSBkbnNzZCBXRyBoYXMgdGhlIHJlc3BvbnNpYmlsaXR5 IGZvciAmcXVvdDtETlMgUHVzaCBOb3RpZmljYXRpb25zJnF1b3Q7DQo8YSBocmVmPSJodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWRuc3NkLXB1c2gtMDgiIGNsYXNzPSIiPmRy YWZ0LWlldGYtZG5zc2QtcHVzaC0wODwvYT4uIFRoZSBpbml0aWFsIGZvY3VzIHdpbGwgYmUgZ2V0 dGluZyB0aGUgc2lnbmFsbGluZyBkcmFmdCBjb21wbGV0ZSwgd2hpY2ggc2hvdWxkIGhhcHBlbiBx dWlja2x5LCBhbmQgdGhlbiB0aGUgRE5TIFB1c2ggZHJhZnQgd2lsbCBiZSByZXZpc2VkIGJhc2Vk IG9uIHRoZSBzaWduYWxpbmcNCiBkcmFmdCB1cGRhdGUuIFRoZSBzaWduYWxsaW5nIGRyYWZ0IGF1 dGhvcnMgcHJvbWlzZWQgYSAtMDEgdXBkYXRlIGJ5IHRoZSBlbmQgb2YgdGhlIElFVEYgd2Vlaywg YW5kIHRoZSBkbnNvcCBjaGFpcnMgd2lsbCB0aGVuIGFzayBmb3IgZG5zb3AgV0cgYWRvcHRpb24u PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgbWlu LWhlaWdodDogMTRweDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj5EaXNjdXNzaW9u OiBETlMgVXBkYXRlIGFuZCBtRE5TL2h5YnJpZCBwcm94eSBjb2V4aXN0ZW5jZTwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj5UZWQg TGVtb24gaGFzIHdyaXR0ZW4gJnF1b3Q7SG9tZW5ldCBOYW1pbmcgYW5kIFNlcnZpY2UgRGlzY292 ZXJ5IEFyY2hpdGVjdHVyZSZxdW90Ow0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtbGVtb24taG9tZW5ldC1uYW1pbmctYXJjaGl0ZWN0dXJlLTAxIiBjbGFzcz0iIj4N CmRyYWZ0LWxlbW9uLWhvbWVuZXQtbmFtaW5nLWFyY2hpdGVjdHVyZS0wMTwvYT4gd2hpY2ggZGlz Y3Vzc2VzIGR5bmFtaWMgRE5TIHVwZGF0ZSBhbmQgRE5TIGh5YnJpZCBwcm94eSBzZXJ2aWNlcyBh bmQgbmFtaW5nIHJlcXVpcmVtZW50cyBpbiB0aGUgY29udGV4dCBvZiB0aGUgaG9tZW5ldCBXRy4g SW4gdGhlIGRuc3NkIG1lZXRpbmcsIGl0IHdhcyBhZ3JlZWQgdGhhdCBUZWQgd291bGQgcHJvZ3Jl c3MgYSBuZXcgJnF1b3Q7ZmxhdCBob21lbmV0JnF1b3Q7IGRyYWZ0DQogd2hpY2ggd291bGQgZGVz Y3JpYmUgaG93IEROUy1TRCBjb3VsZCB3b3JrIGluIGEgaG9tZW5ldCB3aXRoIGEgZmxhdCBuYW1l IHNwYWNlLiBUaGUgdXNlIG9mIEROUyBVcGRhdGUgYWxvbmdzaWRlIGEgY29uZmlndXJlZCBoeWJy aWQgcHJveHkgYWxzbyBuZWVkcyB0byBiZSBkaXNjdXNzZWQgZm9yIHRoZSBtYW5hZ2VkIGVudGVy cHJpc2UvY2FtcHVzIGNhc2UuPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1o ZWlnaHQ6IG5vcm1hbDsgbWluLWhlaWdodDogMTRweDsiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBj bGFzcz0iIj5EaXNjdXNzaW9uOiBSZWNvbW1lbmRhdGlvbnMgZm9yIHVzaW5nIHRoZSBoeWJyaWQg cHJveHk8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFs OyIgY2xhc3M9IiI+UmFscGggRHJvbXMgZ2F2ZSBhIHNob3J0IHByZXNlbnRhdGlvbiBvdXRsaW5p bmcgdGhlIGNvbXBvbmVudHMgb2YgdW5pY2FzdCBETlMtU0QgdGhhdCBjYW4gYmUgY29tYmluZWQg aW4gZGlmZmVyZW50IHdheXMgdG8gbWVldCBkaWZmZXJlbnQgZGVwbG95bWVudCByZXF1aXJlbWVu dHMuIFRoZSBjb250ZW50IGluIHRoZSBwcmVzZW50YXRpb24gd2lsbCBiZQ0KIGluY29ycG9yYXRl ZCBpbnRvIGEgbmV3IGRyYWZ0IGRlc2NyaWJpbmcgQkNQIGZvciB1bmljYXN0IEROUy1TRCBkZXBs b3ltZW50LiBPdGhlciBhc3BlY3RzIG1heSBiZSBjb3ZlcmVkLCBzdWNoIGFzIHVzZXIgaW50ZXJm YWNlIGNvbnNpZGVyYXRpb25zLCB0aG91Z2ggVUkgZGVzaWduIGlzIG91dHNpZGUgdGhlIHNjb3Bl IG9mIHRoZSBXRy4gVG9tIFB1c2F0ZXJpIGhhcyBhIGNhbmRpZGF0ZSBkcmFmdCBkZXNjcmliaW5n IGV4YW1wbGVzIG9mIEROUy1TRA0KIGNvbmZpZ3VyYXRpb25zLCB3aGljaCB3aWxsIGFsc28gZmVl ZCBpbnRvIHRoaXMgcHJvY2Vzcy48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5l LWhlaWdodDogbm9ybWFsOyBtaW4taGVpZ2h0OiAxNHB4OyIgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsi IGNsYXNzPSIiPkRyYWZ0IHJldmlldzogUHJpdmFjeSBFeHRlbnNpb25zIGZvciBETlMtU0Q8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9 IiI+RGFuaWVsIEthaXNlciBkaXNjdXNzZWQgdXBkYXRlcyB0byAmcXVvdDtQcml2YWN5IEV4dGVu c2lvbnMgZm9yIEROUy1TRCZxdW90Ow0KPGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaHVpdGVtYS1kbnNzZC1wcml2YWN5LTAxIiBjbGFzcz0iIj5kcmFmdC1odWl0ZW1h LWRuc3NkLXByaXZhY3ktMDE8L2E+LiBUaGUgbmV3IHJldmlzaW9uIGRlc2NyaWJlcyBhIHBvdGVu dGlhbCBzb2x1dGlvbiBiYXNlZCBvbiBzYW1lLW93bmVyIGFuZCBkaWZmZXJlbnQtb3duZXIgcGFp cmluZy4gVGhlIFdHIGV4cHJlc3NlZCBpbnRlcmVzdCBpbiB0aGUgcm9vbSBpbiBhZG9wdGluZw0K IHRoZSBkb2N1bWVudCBhcyBhIFdHIHdvcmsgaXRlbS4gVGhlIGNoYWlycyB3aWxsIGNvbmZpcm0g dGhpcyBjb25zZW5zdXMgb24gdGhlIG1haWxpbmcgbGlzdC4gVGhlIEFEcyB3aWxsIGRpc2N1c3Mg d2hlcmUgdGhlIGRlc2NyaWJlZCBwYWlyaW5nIHByb3RvY29sIHNob3VsZCBiZSBwcm9ncmVzc2Vk LjwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_F62E4C9353F349BDA152762145BC2305jiscacuk_-- From nobody Mon Jul 25 07:12:23 2016 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B65DC12D8B4; Mon, 25 Jul 2016 07:12:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.29.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160725141221.11433.43358.idtracker@ietfa.amsl.com> Date: Mon, 25 Jul 2016 07:12:21 -0700 Archived-At: Subject: [dnssd] The DNSSD WG has placed draft-huitema-dnssd-privacy in state "Call For Adoption By WG Issued" X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 14:12:22 -0000 The DNSSD WG has placed draft-huitema-dnssd-privacy in state Call For Adoption By WG Issued (entered by Tim Chown) The document is available at https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/ From nobody Mon Jul 25 07:16:41 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4783612D8B9 for ; Mon, 25 Jul 2016 07:16:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com 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 iYGzV6TPaE5Z for ; Mon, 25 Jul 2016 07:16:38 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6AF512D8B0 for ; Mon, 25 Jul 2016 07:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5uku6yZn/zzDeMlj896ttwyyK5EG7nxlNzqRDRWqDFI=; b=aMW162v7ibT/V+hR+dW31FNqLcZVkySwJyIWvWgiIk1R81LVw5bqyTJaFWo4e/BYDMTKkg3+JjnAuZ5ZoUB7bA4Uy69BUqHXIUYw8/wrJX5M/uCZ0YdL8LAcBe6e8QSQNiT/F+d5shiWz+0d+uZ4lPCrGr5SZVNO8d60u6/BlZw= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0243.outbound.protection.outlook.com [213.199.154.243]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-38-IUaPfyrDMd6ijLsXIt-cCw-1; Mon, 25 Jul 2016 15:16:29 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Mon, 25 Jul 2016 14:16:26 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Mon, 25 Jul 2016 14:16:27 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: Call for WG Adoption: draft-huitema-dnssd-privacy-01 Thread-Index: AQHR5n8h77w/q2pT+k6oPIkttErysw== Date: Mon, 25 Jul 2016 14:16:27 +0000 Message-ID: <3D43CEAD-3D12-4E32-AA01-8A1E4ABD8D86@jisc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:e562:f526:a39d:e3a0] x-ms-office365-filtering-correlation-id: 01acddef-12af-446e-eedd-08d3b496442c x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 20:sxhsRVHT+/iOOBzZPrW1h4OBqNqU6GlEDurnn7XaTGZzSf8IZdSMUMThpZ9XecvszlKOKrW9xz1P4/5/8Xa2bDo7SDQZTH9iqynv6f5PlukYijoiLq3JlaArHyWJIvXC/wu6tsEqCi08FqM25C0slf0N2M8/7HmfN6r/9Gei2sE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(52044002)(189002)(199003)(2900100001)(77096005)(110136002)(87936001)(19617315012)(57306001)(189998001)(3280700002)(68736007)(74482002)(3660700001)(33656002)(92566002)(36756003)(86362001)(15975445007)(101416001)(5640700001)(10400500002)(5002640100001)(97736004)(105586002)(106116001)(106356001)(122556002)(50226002)(229853001)(81166006)(1730700003)(2501003)(16236675004)(81156014)(8676002)(50986999)(8936002)(6116002)(586003)(102836003)(4326007)(82746002)(7846002)(7736002)(83716003)(19580395003)(7906003)(2351001)(2906002)(230783001)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2016 14:16:27.0180 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-MC-Unique: IUaPfyrDMd6ijLsXIt-cCw-1 Content-Type: multipart/alternative; boundary="_000_3D43CEAD3D124E32AA018A1E4ABD8D86jiscacuk_" Archived-At: Cc: Terry Manderson Subject: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 14:16:40 -0000 --_000_3D43CEAD3D124E32AA018A1E4ABD8D86jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNCkF0IHRoZSBtZWV0aW5nIGluIEJlcmxpbiwgdGhlcmUgd2FzIGEgcG9zaXRpdmUgcmVh Y3Rpb24gdG8gdGhlICJQcml2YWN5IEV4dGVuc2lvbnMgZm9yIEROUy1TROKAnSBkcmFmdCwgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWh1aXRlbWEtZG5zc2QtcHJpdmFjeS0wMS4N Cg0KV2hpbGUgb25seSBhIHNtYWxsIG51bWJlciBvZiBwZW9wbGUgaGFkIHJlYWQgaXQgaW4gZGV0 YWlsLCB0aG9zZSB3aG8gaGFkIHJlYWQgaXQgZXhwcmVzc2VkIGEgZGVzaXJlIGZvciB0aGUgV0cg dG8gYWRvcHQgdGhlIGRyYWZ0Lg0KDQpUaGlzIGVtYWlsIHRoZXJlZm9yZSBiZWdpbnMgYSB0d28t d2VlayBmb3JtYWwgZG5zc2QgbWFpbCBsaXN0IGNhbGwgZm9yIGFkb3B0aW9uIG9mIHRoZSBkcmFm dCBieSB0aGUgV0cuIFBsZWFzZSBzZW5kIGFueSBjb21tZW50cywgZm9yIG9yIGFnYWluc3QsIHRv IHRoZSBkbnNzZCBXRyBsaXN0LiBJZiB5b3UgaW5kaWNhdGVkIHN1cHBvcnQgaW4gdGhlIG1lZXRp bmcsIGZlZWwgZnJlZSB0byByZWFmZmlybSB0aGlzLCBhbmQgYWRkIGFueSBjb21tZW50cy4NCg0K VGhlIGNhbGwgZW5kcyBvbiBNb25kYXkgOHRoIEF1Z3VzdC4NCg0KVGhlIGRvY3VtZW50IHN0YXR1 cyBpbiB0aGUgZGF0YSB0cmFja2VyIGNhbiBiZSBmb3VuZCBhdCBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1odWl0ZW1hLWRuc3NkLXByaXZhY3kvLg0KDQpOb3RlIHRoYXQg dGhlIFdHIGluIHdoaWNoIHRoZSBzcGVjaWZpY3Mgb2YgdGhlIHBhaXJpbmcgcHJvdG9jb2wgd2ls bCBiZSBkZXZlbG9wZWQgd2lsbCBiZSByZXZpZXdlZCBieSBvdXIgQUQuIE9uIHRoZSBvbmUgaGFk IGl0IGlzIGEgZ2VuZXJpYyBtZWNoYW5pc20gdGhhdCBtYXkgYmUgYmV0dGVyIGRlZmluZWQgaW4g YSBzZWN1cml0eSBXRywgb24gdGhlIG90aGVyIHdlIHNob3VsZCBoYXZlIGEgY3JpdGljYWwgbWFz cyBvZiBwZW9wbGUgdG8gZ2V0IHRoZSB3b3JrIGRvbmUgaGVyZSwgaWYgdGhlIGRyYWZ0IGlzIGFk b3B0ZWQuDQoNClRpbQ0KDQoNCg0K --_000_3D43CEAD3D124E32AA018A1E4ABD8D86jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5BdCB0aGUgbWVldGluZyBpbiBCZXJs aW4sIHRoZXJlIHdhcyBhIHBvc2l0aXZlIHJlYWN0aW9uIHRvIHRoZSAmcXVvdDtQcml2YWN5IEV4 dGVuc2lvbnMgZm9yIEROUy1TROKAnSBkcmFmdCwmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaHVpdGVtYS1kbnNzZC1wcml2YWN5LTAxIiBjbGFzcz0iIj5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVpdGVtYS1kbnNzZC1wcml2YWN5LTAx PC9hPi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPldoaWxlIG9ubHkgYSBzbWFsbCBudW1iZXIgb2YgcGVvcGxlIGhhZCByZWFkIGl0IGlu IGRldGFpbCwgdGhvc2Ugd2hvIGhhZCByZWFkIGl0IGV4cHJlc3NlZCBhIGRlc2lyZSBmb3IgdGhl IFdHIHRvIGFkb3B0IHRoZSBkcmFmdC4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoaXMgZW1haWwgdGhlcmVmb3JlIGJlZ2lu cyBhIHR3by13ZWVrIGZvcm1hbCBkbnNzZCBtYWlsIGxpc3QgY2FsbCBmb3IgYWRvcHRpb24gb2Yg dGhlIGRyYWZ0IGJ5IHRoZSBXRy4gUGxlYXNlIHNlbmQgYW55IGNvbW1lbnRzLCBmb3Igb3IgYWdh aW5zdCwgdG8gdGhlIGRuc3NkIFdHIGxpc3QuIElmIHlvdSBpbmRpY2F0ZWQgc3VwcG9ydCBpbiB0 aGUgbWVldGluZywgZmVlbCBmcmVlIHRvIHJlYWZmaXJtIHRoaXMsIGFuZCBhZGQNCiBhbnkgY29t bWVudHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5UaGUgY2FsbCBlbmRzIG9uIE1vbmRheSA4dGggQXVndXN0LjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIGRvY3VtZW50 IHN0YXR1cyBpbiB0aGUgZGF0YSB0cmFja2VyIGNhbiBiZSBmb3VuZCBhdCZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1aXRlbWEtZG5zc2QtcHJp dmFjeS8iIGNsYXNzPSIiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1 aXRlbWEtZG5zc2QtcHJpdmFjeS88L2E+LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Tm90ZSB0aGF0IHRoZSBXRyBpbiB3aGljaCB0aGUg c3BlY2lmaWNzIG9mIHRoZSBwYWlyaW5nIHByb3RvY29sIHdpbGwgYmUgZGV2ZWxvcGVkIHdpbGwg YmUgcmV2aWV3ZWQgYnkgb3VyIEFELiBPbiB0aGUgb25lIGhhZCBpdCBpcyBhIGdlbmVyaWMgbWVj aGFuaXNtIHRoYXQgbWF5IGJlIGJldHRlciBkZWZpbmVkIGluIGEgc2VjdXJpdHkgV0csIG9uIHRo ZSBvdGhlciB3ZSBzaG91bGQgaGF2ZSBhIGNyaXRpY2FsIG1hc3Mgb2YNCiBwZW9wbGUgdG8gZ2V0 IHRoZSB3b3JrIGRvbmUgaGVyZSwgaWYgdGhlIGRyYWZ0IGlzIGFkb3B0ZWQuPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlRpbSZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIg Y2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+ DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3D43CEAD3D124E32AA018A1E4ABD8D86jiscacuk_-- From nobody Mon Jul 25 07:20:28 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77EB412D8C0 for ; Mon, 25 Jul 2016 07:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com 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 ug4zOxLWOKoC for ; Mon, 25 Jul 2016 07:20:26 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994EA12D8BE for ; Mon, 25 Jul 2016 07:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wfKgtKdAvGYsBAzkACJVgO5VYiWJHvs93vc3IkfywDA=; b=naZTsbUkqg2uwNCDgKllzju9knUKDHGhUeXP/Vm9FPe0TnPiibvjYOnGlVsszqMXJf/LiWE/QgLDwTyeLOVibds6IVhd7HPp0Wphlvxblli7dmmt5oLXhetWYF0QifULO+v4T2Vh17lNUWYijXQt1yHq9eA5FKcXdAC0J7gSweo= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0248.outbound.protection.outlook.com [213.199.154.248]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-57-sC1ibzTsPjm_sCaF6Y5ncA-1; Mon, 25 Jul 2016 15:20:19 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Mon, 25 Jul 2016 14:20:16 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Mon, 25 Jul 2016 14:20:17 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: [DNSOP] Call for Adoption: draft-bellis-dnsop-session-signal Thread-Index: AQHR5n9o83u8v1WA1UiB8FTCpr6mIw== Date: Mon, 25 Jul 2016 14:20:16 +0000 Message-ID: References: <2c1a39bc-88eb-3952-d06d-f52f7ea56e2c@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:e562:f526:a39d:e3a0] x-ms-office365-filtering-correlation-id: 79290736-e1de-493d-59f4-08d3b496cd53 x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 20:sDtunlmSEc+haADBXISQIMPkD/XTeBclocc20IEPMzJ17LGmRKZi5UnsQRX0yoE0etRG8IhjLPKOd5M4+SSiJcPYeIkn7bhlVB0W+NUvNz6Y5pXp2laqsn9G9e1ZUwoVudT5Ky4BJ80G9mZBGfVz2qtrMdrRUOIi9Hyd45Mvmlk= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(2473001)(199003)(189002)(81156014)(8676002)(2501003)(16236675004)(81166006)(1730700003)(50986999)(8936002)(76176999)(106356001)(97736004)(106116001)(105586002)(50226002)(122556002)(7906003)(83716003)(19580395003)(2351001)(19580405001)(7736002)(230783001)(2906002)(102836003)(586003)(6116002)(82746002)(7846002)(189998001)(3660700001)(74482002)(33656002)(3280700002)(68736007)(110136002)(2900100001)(77096005)(107886002)(19617315012)(57306001)(87936001)(5640700001)(5002640100001)(10400500002)(92566002)(450100001)(101416001)(36756003)(86362001)(15975445007)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2016 14:20:16.9875 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-MC-Unique: sC1ibzTsPjm_sCaF6Y5ncA-1 Content-Type: multipart/alternative; boundary="_000_D3FA84BA0059454285BC47B083DEE261jiscacuk_" Archived-At: Subject: [dnssd] Fwd: [DNSOP] Call for Adoption: draft-bellis-dnsop-session-signal X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 14:20:27 -0000 --_000_D3FA84BA0059454285BC47B083DEE261jiscacuk_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable The authors of draft-bellis-dnsop-session-signal have published a -01 versi= on in quick time, as promised. There is now a WG call of adoption in dnsop, which dnssd WG participants ar= e welcome to contribute to. Please post comments to the dnsop list. Best wishes, Tim Begin forwarded message: From: Tim Wicinski > Subject: [DNSOP] Call for Adoption: draft-bellis-dnsop-session-signal Date: 23 July 2016 at 02:39:41 BST To: dnsop > I know we've just started talking about this, and the authors are still sor= ting out a few things, but the sense of the room we received was to adopt i= t, work on it, etc. It appears they have simplified it in the -01 version. This starts a Call for Adoption for draft-bellis-dnsop-session-signal The draft is available here: https://datatracker.ietf.org/doc/draft-bellis-dnsop-session-signal/ Please review this draft to see if you think it is suitable for adoption by= DNSOP, and comments to the list, clearly stating your view. Please also indicate if you are willing to contribute text, review, etc. With this being the summer, we're going to run a 3 week call for adoption. This call for adoption ends: Thursday, 12 August 2016 Thanks, tim wicinski DNSOP co-chair _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop --_000_D3FA84BA0059454285BC47B083DEE261jiscacuk_ Content-Type: text/html; charset=WINDOWS-1252 Content-ID: Content-Transfer-Encoding: quoted-printable The authors of draft-bellis-dnsop-session-signal have published a -01 = version in quick time, as promised.

There is now a WG call of adoption in dnsop, which dnssd WG= participants are welcome to contribute to.  Please post comments to t= he dnsop list.

Best wishes,
Tim 

Begin forwarded message:

From: Tim Wicinski <tjw.ietf@gmail.com>
Subject: [DNSOP] Call for Adoption= : draft-bellis-dnsop-session-signal
Date: 23 July 2016 at 02:39:41 BST
To: dnsop <dnsop@ietf.org>

I know we've just started talking about this, and the autho= rs are still sorting out a few things, but the sense of the room we receive= d was to adopt it, work on it, etc.

It appears they have simplified it in the -01 version.


This starts a Call for Adoption for draft-bellis-dnsop-session-signal

The draft is available here:
https://datatracker.ietf.org/doc/draft-bellis-dnsop-session= -signal/

Please review this draft to see if you think it is suitable for adoption by= DNSOP, and comments to the list, clearly stating your view.

Please also indicate if you are willing to contribute text, review, etc.
With this being the summer, we're going to run a 3 week call for adoption.<= br class=3D"">
This call for adoption ends: Thursday, 12 August 2016

Thanks,
tim wicinski
DNSOP co-chair

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

--_000_D3FA84BA0059454285BC47B083DEE261jiscacuk_-- From nobody Mon Jul 25 12:37:08 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC9812D5C0 for ; Mon, 25 Jul 2016 12:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com 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 1OvhZd58CZm6 for ; Mon, 25 Jul 2016 12:37:04 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1063412D5B5 for ; Mon, 25 Jul 2016 12:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YDyxgNPItDeXgIrkYPbDD0C69bY/7OH8XPUXBobPdVo=; b=J+8KS4qgXbhssfWU1d9utHig2Btl4a730hBtpq52sO92Dc177appb+O6G4SqF+mshSv2x/2uGF5zaPCsveL1jsTiNritnmRRDpJQtQfXrGUAm9YV9qwzl/1gE/tjjo1z9gOv2OBOuPLl4CbscWnOQpphbM86FCsyWeokGPwlvZE= Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0177.outbound.protection.outlook.com [213.199.180.177]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-11-7yeZ0bLJOX2PEp_CmESNAg-1; Mon, 25 Jul 2016 20:36:58 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) with Microsoft SMTP Server (TLS) id 15.1.539.14; Mon, 25 Jul 2016 19:36:55 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Mon, 25 Jul 2016 19:36:55 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: [dnssd] Setting device friendly names Thread-Index: AdHiibYrxB4vZWkMQdmCvDMGAtoHugAAU4SAACq01gAAAUkEAAAAuYWAAAU/fYAABKBYgAABGyCAAAImJoAAAJIIgACFWrYAAAKFhQAARfqfgA== Date: Mon, 25 Jul 2016 19:36:55 +0000 Message-ID: References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> <8F6598B8-BBE0-4496-B850-51686E63A527@att.com> <009d01d1e58a$1cdd7ca0$569875e0$@huitema.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:829:f3ee:fc02:77e0] x-ms-office365-filtering-correlation-id: 1325ff06-968c-4a6b-89b0-08d3b4c3092a x-microsoft-exchange-diagnostics: 1; AMSPR07MB455; 20:/Z0C0+Z9bwHdh71NgWCdVtkltupFXd5YsUMSrtrhMbMm31R//QUXqFaubMj5zgnMfB7IrFkvOC2unk2ZCXhHSyftuyRELKjdaYaeCbPUL+CUFzqzk4Bx0HjAZek/GicaktHjMcPxkw9XyNOIhQcN5+QXpV8nLsIeyUGvWrMdswQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB455; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(150554046322364)(144208319314845)(31960201722614); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB455; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB455; x-forefront-prvs: 0014E2CF50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(199003)(377454003)(24454002)(86362001)(3280700002)(10400500002)(36756003)(50226002)(97736004)(122556002)(57306001)(2900100001)(2950100001)(15975445007)(189998001)(7846002)(3660700001)(81156014)(106356001)(74482002)(7906003)(8936002)(101416001)(81166006)(5640700001)(1730700003)(8676002)(7736002)(5002640100001)(2351001)(19580405001)(586003)(93886004)(6116002)(2906002)(19580395003)(83716003)(105586002)(2501003)(76176999)(11100500001)(450100001)(107886002)(92566002)(82746002)(33656002)(16236675004)(77096005)(19617315012)(68736007)(50986999)(87936001)(102836003)(110136002)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB455; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2016 19:36:55.2345 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB455 X-MC-Unique: 7yeZ0bLJOX2PEp_CmESNAg-1 Content-Type: multipart/alternative; boundary="_000_E775B3669E6E420EB1D840A208049271jiscacuk_" Archived-At: Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 19:37:07 -0000 --_000_E775B3669E6E420EB1D840A208049271jiscacuk_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi, On 24 Jul 2016, at 11:14, Ted Lemon > wrote: Yes. There are two separate problems here: how to name services that are be= ing advertised, for which presumably we do not want privacy, and how to dea= l with devices whose identification should be private, but with which there= might still be a need to rendezvous. The reason I was so enthusiastic about your presentation in dnssd is that i= t very nicely solves this second problem. But we still have the first pro= blem. Indeed :) Well, the hosts have names, and those are coupled with service information,= where the service names are well-known. For example, I see "Living Room Ap= ple TV._airplay._tcp.local.=94 advertised while sat here in my lounge, for = a device with name living-room-apple-tv.local, and the airplay service for = screen sharing. As an example of default names that are far from ideal in a =93coffee shop= =94 environment, an iPhone will have default name like freds-iphone.local, = an iPad will have sarahs-ipad.local. A 30-minute harvest of multicast DNS i= n a recent event harvested me the names (first, or full) of over half of th= e attendees. I note my employer very thoughtfully gave my Mac a name of the form JNTXX00= 12345. That=92s obfuscated in a sense, but also quite likely to be a global= ly unique name, and one I could therefore be tracked by. So as Christian s= ays we definitely want privacy support when we expose names via service dis= covery protocols. On name clashes, my own Mac is simply =93Tims-MacBook-Pro=94, which is a mo= re friendly name, but I=92ve been at meetings big enough before that such f= riendly names will clash, and thus my device then appears on the network as= Tims-MacBook-Pro-2=94. That=92s not the network renaming me, it=92s my ow= n host picking a new name. But if we flatten a multi-link homenet, we will = need this capability unless we embed link names, which as we discussed at t= he meeting is not desirable. Ted suggested some ideas on this front. How you change the name will depend on the device; it might be via a GUI, c= ommand line, or web interface. Seeking a new common standard for this seems= , well, optimistic. But I=92d expect to be able to change my device=92s nam= e whenever I chose, if I had appropriate privileges on it, and then DNS-SD = protocols would propagate the change. So I=92d disagree with an assertion t= hat devices must not allow the name to be trivially changed, once set. I think the requirements will become clearer once Ted and whoever offers to= help can formulate a -00 of what I think we=92re now calling the =93flat h= omenet=94 model. Tim On Jul 24, 2016 11:02 AM, "Christian Huitema" > wrote: On Thursday, July 21, 2016 7:24 PM, Ted Lemon wrote: > Right, the issue would be if we changed it in the database operated by > the homenet, and didn't tell the host. > > On Thu, Jul 21, 2016 at 7:07 PM, Stuart Cheshire > wrote: >> On 21 Jul 2016, at 09:06, Ted Lemon > wrote: >> >>> Hm. That's not what I'm saying. The point Barbara made that I agree = with and restated was that the device should report the same name no matter= who asks or how. >> >> For the most part, this is universally true today. Of all the devices I= =92ve seen that support both UPnP and Bonjour DNS-SD/mDNS, virtually have a= single place in the web UI to set the name, which is then used for both di= scovery protocols. Please let's not forget the privacy issues for mobile devices. There is an = intarea draft about that, "hostname practices considered harmful." In short= , volunteering a name to the network allows tracking; volunteering a user f= riendly name like "Ted Lemon's laptop" allows for even better tracking. For DHCP, the "privacy" recommendation is to not volunteer a name at all to= the DHCP server, or to use a one-time random name. Now, I can understand that these one-time random names should be more user = friendly than "F78AC123", maybe using something like "correct-horse-battery= -staple" in the tradition of https://www.xkcd.com/936/. -- Christian Huitema _______________________________________________ dnssd mailing list dnssd@ietf.org https://www.ietf.org/mailman/listinfo/dnssd --_000_E775B3669E6E420EB1D840A208049271jiscacuk_ Content-Type: text/html; charset=WINDOWS-1252 Content-ID: Content-Transfer-Encoding: quoted-printable Hi,

On 24 Jul 2016, at 11:14, Ted Lemon <mellon@fugue.com> wrote:

Yes. There are two separate problems here: how to= name services that are being advertised, for which presumably we do not wa= nt privacy, and how to deal with devices whose identification should be pri= vate, but with which there might still be a need to rendezvous.

The reason I was so enthusiastic about your prese= ntation in dnssd is that it very nicely solves this second  problem.&n= bsp; But we still have the first problem.

Indeed :) 

Well, the hosts have names, and those are coupled with service informa= tion, where the service names are well-known. For example, I see "Livi= ng Room Apple TV._airplay._tcp.local.=94 advertised while sat here in my lo= unge, for a device with name living-room-apple-tv.local, and the airplay service for screen sharing.

As an example of default names that are far from ideal in a =93coffee = shop=94 environment, an iPhone will have default name like freds-iphone.loc= al, an iPad will have sarahs-ipad.local. A 30-minute harvest of multicast D= NS in a recent event harvested me the names (first, or full) of over half of the attendees.

I note my employer very thoughtfully gave my Mac a name of the form&nb= sp;JNTXX0012345. That=92s obfuscated in a sense, but also quite likely to b= e a globally unique name, and one I could therefore be tracked by.  So= as Christian says we definitely want privacy support when we expose names via service discovery protocols.

On name clashes, my own Mac is simply =93Tims-MacBook-Pro=94, whi= ch is a more friendly name, but I=92ve been at meetings big enough before t= hat such friendly names will clash, and thus my device then appears on the = network as Tims-MacBook-Pro-2=94.  That=92s not the network renaming me, it=92s my own host picking a new name. But if we = flatten a multi-link homenet, we will need this capability unless we embed = link names, which as we discussed at the meeting is not desirable. Ted sugg= ested some ideas on this front.

How you change the name will depend on the device; it might be via a G= UI, command line, or web interface. Seeking a new common standard for this = seems, well, optimistic. But I=92d expect to be able to change my device=92= s name whenever I chose, if I had appropriate privileges on it, and then DNS-SD protocols would propagate the change. So= I=92d disagree with an assertion that devices must not allow the name to b= e trivially changed, once set.

I think the requirements will become clearer once Ted and whoever offe= rs to help can formulate a -00 of what I think we=92re now calling the =93f= lat homenet=94 model.

Tim


On Jul 24, 2016 11:02 AM, "Christian Huitem= a" <huitema@huite= ma.net> wrote:
On Thursday, July 21, 2016 7:24 PM, Ted Lemon wrote:

> Right, the issue would be if we changed it in the database operated by=
> the homenet, and didn't tell the host.
>
> On Thu, Jul 21, 2016 at 7:07 PM, Stuart Cheshire <mailto:cheshire@apple.com> wrote: >> On 21 Jul 2016, at 09:06, Ted Lemon <mailto:mellon@fugue.com> wrote:
>>
>>> Hm.   That's not what I'm saying.  The point Ba= rbara made that I agree with and restated was that the device should report= the same name no matter who asks or how.
>>
>> For the most part, this is universally true today. Of all the devi= ces I=92ve seen that support both UPnP and Bonjour DNS-SD/mDNS, virtually h= ave a single place in the web UI to set the name, which is then used for bo= th discovery protocols.

Please let's not forget the privacy issues for mobile devices. There is an = intarea draft about that, "hostname practices considered harmful."= ; In short, volunteering a name to the network allows tracking; volunteerin= g a user friendly name like "Ted Lemon's laptop" allows for even better tracking.

For DHCP, the "privacy" recommendation is to not volunteer a name= at all to the DHCP server, or to use a one-time random name.

Now, I can understand that these one-time random names should be more user = friendly than "F78AC123", maybe using something like "correc= t-horse-battery-staple" in the tradition of https://www.xkcd.com/936/.

-- Christian Huitema



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

--_000_E775B3669E6E420EB1D840A208049271jiscacuk_-- From nobody Tue Jul 26 01:28:40 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A93B512D748 for ; Tue, 26 Jul 2016 01:28:38 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FQSeGn5MHBg7 for ; Tue, 26 Jul 2016 01:28:37 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (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 EED8712D699 for ; Tue, 26 Jul 2016 01:28:36 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id s63so185897942qkb.2 for ; Tue, 26 Jul 2016 01:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=/IUstZm3fRvjx15s34+cLg0sTuLEYixi19IzJmzjkpc=; b=vLggbViy+goyPAXNH38Lv/N40RjVenSQHoUfAwouIFUUWGhxQ+i6RxzNghUMY2m6Yl XOzLgJ/BFfKZiKyDwTmHRRHVl0mhC1xJtAjMPK25x8xMtEXMZeDi0O3yr/BTc+9Aaiyf D7Pl/nFbBDRKYi4vfVGUFS1Szd7QauTBHo76sN0ApGmdb0FnRb2IIsjqASZihuQTCaQ2 71BfnTQwiv4a8nXk8ElUsQLzc+9RedsVM5MdRJxttHTuYg5tej8AtJ05TU3yElb6tgVJ fBk4MpCNZllgESVSictATIvLNLMMsa68UgIE3OpcnSl7FjyMqNeEmLylbACsfQn9Jx4J twpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/IUstZm3fRvjx15s34+cLg0sTuLEYixi19IzJmzjkpc=; b=c14mxI3QRIk364rdBiL+7wKSDzVVbvpc1bqGGLGpu16xwYXD2CJXXtiYmZhWXFokT5 lv2BpzyjGGtj4k26gF+ZQjk8zvySUzvjw46CLOkyOgx33qIuet/BOq4rOzVYaAe04Oea GNUYtMc0ejm9q7RNanLgPG11joLAt5dGs7K0nJ2wGXqT3KF/D2FCVAuwy43x9PDVlNSG cYpkDc+/dXW56s44UNeghJFOB5UjmN+4fCjIhuSeT5zwjlMdyVKAebZE6Z2jpcMdM199 XhTpzUQcBP+DUE1YOQtEcF8ks+pl73sro21fmu7Z55NZycZBdPyRTd27BfXMFYbixJj2 /rGw== X-Gm-Message-State: AEkoouvkbSVH0zVsKf/rjRbsC1EHBy9cIr3LHCvdFTQp2yJD+C0jD8DiDO79jvRAuOVrSpFe0DYT5iEMZF8UCg== X-Received: by 10.55.147.70 with SMTP id v67mr26775920qkd.32.1469521716133; Tue, 26 Jul 2016 01:28:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.146 with HTTP; Tue, 26 Jul 2016 01:28:35 -0700 (PDT) In-Reply-To: <3D43CEAD-3D12-4E32-AA01-8A1E4ABD8D86@jisc.ac.uk> References: <3D43CEAD-3D12-4E32-AA01-8A1E4ABD8D86@jisc.ac.uk> From: Martin Thomson Date: Tue, 26 Jul 2016 10:28:35 +0200 Message-ID: To: Tim Chown Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dnssd@ietf.org" , Terry Manderson Subject: Re: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 08:28:39 -0000 What is the status of the pairing piece of this work? None of this can work without addressing that portion. The document contains some ideas, but these are quite nebulous and certainly not sufficient to deploy an interoperable solution for this. (I'm generally supportive of this work, but I want to make sure that everyone understands the scope and magnitude of the work involved here.) On 25 July 2016 at 16:16, Tim Chown wrote: > Hi, > > At the meeting in Berlin, there was a positive reaction to the "Privacy > Extensions for DNS-SD=E2=80=9D draft, > https://tools.ietf.org/html/draft-huitema-dnssd-privacy-01. > > While only a small number of people had read it in detail, those who had > read it expressed a desire for the WG to adopt the draft. > > This email therefore begins a two-week formal dnssd mail list call for > adoption of the draft by the WG. Please send any comments, for or against= , > to the dnssd WG list. If you indicated support in the meeting, feel free = to > reaffirm this, and add any comments. > > The call ends on Monday 8th August. > > The document status in the data tracker can be found at > https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/. > > Note that the WG in which the specifics of the pairing protocol will be > developed will be reviewed by our AD. On the one had it is a generic > mechanism that may be better defined in a security WG, on the other we > should have a critical mass of people to get the work done here, if the > draft is adopted. > > Tim > > > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > From nobody Tue Jul 26 02:34:48 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D7512B077 for ; Tue, 26 Jul 2016 02:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com 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 VQyB_ixF-gtB for ; Tue, 26 Jul 2016 02:34:44 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F1512B03D for ; Tue, 26 Jul 2016 02:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4alULKrtKPtdGq86JquePaV18DHi8OwtnNZV95k1uUc=; b=bjsEXbhcwlCDNBPfGADwtf6mBwhalQmXNLZmQWu3R3eiIxH193BSiCQkNTrNKmzMOWqm3EuZVDWIKjOoJZlbw5mlVvRzfV4REIFNhB/w/buateUF8sgu0XDsOCpQaRRaIoRGJU+FG7NkCCBKj21tBYHqDr69bC6pMZR+1cMX2LY= Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp0145.outbound.protection.outlook.com [213.199.154.145]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-59-BJWI2xuQO5KaeKcOXDJeRA-1; Tue, 26 Jul 2016 10:34:33 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 26 Jul 2016 09:34:31 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Tue, 26 Jul 2016 09:34:31 +0000 From: Tim Chown To: Martin Thomson Thread-Topic: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01 Thread-Index: AQHR5n8hnYAn/D72PE2+MNNmSAm3kqAqYmiAgAAS1YA= Date: Tue, 26 Jul 2016 09:34:31 +0000 Message-ID: <8DF671C1-CB48-4282-93DF-3CF4D5D8506A@jisc.ac.uk> References: <3D43CEAD-3D12-4E32-AA01-8A1E4ABD8D86@jisc.ac.uk> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:829:f3ee:fc02:77e0] x-ms-office365-filtering-correlation-id: 4bb3fc66-fba6-4c43-71bb-08d3b5380c18 x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 20:WzRtNrBFLymaj6m8Df9aRfuLD7AUUmhgVq6htBFjJTYJ2xXkT6eigVTDiBgm8COOOdeIgjP42X0LpSHs25F7QpsGyTaqMAOy87anCVyTk3Ue/jSicNAMRI/l3MtHfiSkUmKY7pOwVXAOrcjzE0pjiMTXj18q/EkqjLlV427OsFE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672)(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(7916002)(24454002)(52044002)(199003)(189002)(77096005)(2900100001)(10400500002)(110136002)(57306001)(189998001)(3280700002)(74482002)(68736007)(33656002)(3660700001)(11100500001)(92566002)(86362001)(87936001)(36756003)(15975445007)(101416001)(5002640100001)(97736004)(105586002)(106116001)(106356001)(50226002)(122556002)(76176999)(8676002)(81156014)(2906002)(50986999)(2950100001)(586003)(102836003)(82746002)(4326007)(7846002)(19580405001)(83716003)(6116002)(19580395003)(7736002)(305945005)(8936002)(230783001)(81166006)(3826002)(104396002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 09:34:31.4195 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-MC-Unique: BJWI2xuQO5KaeKcOXDJeRA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Cc: "dnssd@ietf.org" , Terry Manderson Subject: Re: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 09:34:47 -0000 SGksDQoNCj4gT24gMjYgSnVsIDIwMTYsIGF0IDA5OjI4LCBNYXJ0aW4gVGhvbXNvbiA8bWFydGlu LnRob21zb25AZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IFdoYXQgaXMgdGhlIHN0YXR1cyBvZiB0 aGUgcGFpcmluZyBwaWVjZSBvZiB0aGlzIHdvcms/ICBOb25lIG9mIHRoaXMNCj4gY2FuIHdvcmsg d2l0aG91dCBhZGRyZXNzaW5nIHRoYXQgcG9ydGlvbi4gIFRoZSBkb2N1bWVudCBjb250YWlucyBz b21lDQo+IGlkZWFzLCBidXQgdGhlc2UgYXJlIHF1aXRlIG5lYnVsb3VzIGFuZCBjZXJ0YWlubHkg bm90IHN1ZmZpY2llbnQgdG8NCj4gZGVwbG95IGFuIGludGVyb3BlcmFibGUgc29sdXRpb24gZm9y IHRoaXMuDQo+IA0KPiAoSSdtIGdlbmVyYWxseSBzdXBwb3J0aXZlIG9mIHRoaXMgd29yaywgYnV0 IEkgd2FudCB0byBtYWtlIHN1cmUgdGhhdA0KPiBldmVyeW9uZSB1bmRlcnN0YW5kcyB0aGUgc2Nv cGUgYW5kIG1hZ25pdHVkZSBvZiB0aGUgd29yayBpbnZvbHZlZA0KPiBoZXJlLikNCg0KSW5kZWVk LCBpdCBpcyBpbiBpdHMgaW5mYW5jeS4gVGhlIC0wMCB3YXMgcHJldHR5IG11Y2gganVzdCBhIHBy b2JsZW0gc3RhdGVtZW50LCBhbmQgdGhlIC0wMSB0b29rIHRoZSBmaXJzdCBzdGVwcyBpbnRvIHNv bHV0aW9uIHNwYWNlLiANCg0KTm90ZSB0aGF0IGFuIEktRCB5ZXMgbm90IGhhdmUgdG8gYmUgY2xv c2UgdG8gaXRzIGZpbmFsIHNoYXBlIHRvIGJlIGFkb3B0ZWQgYnkgdGhlIFdHLCBpbmRlZWQgeW91 IGNhbiB2b3RlIHRvIGFkb3B0IGV2ZW4gaWYgdGhlcmUgYXJlIHBhcnRzIHlvdSBjdXJyZW50bHkg ZGlzYWdyZWUgd2l0aCwgYnV0IGJlbGlldmUgaXQgaXMgaW1wb3J0YW50IHdvcmsgZm9yIHRoZSBX Ry4NCg0KSeKAmW0gZXhwZWN0aW5nIHRoYXQgd2XigJlsbCBnZXQgYSB2aWV3IGZyb20gb3VyIEFE IChUZXJyeSkgb24gd2hldGhlciB0aGUgcGFpcmluZyB3b3JrIGlzIHRvIGJlIGRvbmUgaW4gZG5z c2Qgb3IgZWxzZXdoZXJlIGJ5IHRoZSB0aW1lIHRoZSBjYWxsIGZvciBhZG9wdGlvbiBwZXJpb2Qg Y29tcGxldGVzLCBhbmQgdGhhdCwgYWxvbmdzaWRlIG90aGVyIGNvbW1lbnRzIGFib3V0IHRoZSBt YWduaXR1ZGUgb2YgdGhlIHdvcmsgYW5kIHdoZXRoZXIgc3VmZmljaWVudCBjcml0aWNhbCBtYXNz IGV4aXN0cyB0byBleGVjdXRlIGl0LCB3aWxsIGluZm9ybSBSYWxwaCBhbmQgSSB0byBtYWtlIGEg ZGVjaXNpb24uIFRoZSAobGltaXRlZCkgdmlld3MgaW4gdGhlIHJvb20gaW4gQmVybGluIHdlcmUg dmVyeSBwb3NpdGl2ZSwgYnV0IHlvdXIgcG9pbnRzIGFyZSB3ZWxsIG1hZGUuDQoNClRpbSANCg0K PiBPbiAyNSBKdWx5IDIwMTYgYXQgMTY6MTYsIFRpbSBDaG93biA8VGltLkNob3duQGppc2MuYWMu dWs+IHdyb3RlOg0KPj4gSGksDQo+PiANCj4+IEF0IHRoZSBtZWV0aW5nIGluIEJlcmxpbiwgdGhl cmUgd2FzIGEgcG9zaXRpdmUgcmVhY3Rpb24gdG8gdGhlICJQcml2YWN5DQo+PiBFeHRlbnNpb25z IGZvciBETlMtU0TigJ0gZHJhZnQsDQo+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaHVpdGVtYS1kbnNzZC1wcml2YWN5LTAxLg0KPj4gDQo+PiBXaGlsZSBvbmx5IGEgc21hbGwg bnVtYmVyIG9mIHBlb3BsZSBoYWQgcmVhZCBpdCBpbiBkZXRhaWwsIHRob3NlIHdobyBoYWQNCj4+ IHJlYWQgaXQgZXhwcmVzc2VkIGEgZGVzaXJlIGZvciB0aGUgV0cgdG8gYWRvcHQgdGhlIGRyYWZ0 Lg0KPj4gDQo+PiBUaGlzIGVtYWlsIHRoZXJlZm9yZSBiZWdpbnMgYSB0d28td2VlayBmb3JtYWwg ZG5zc2QgbWFpbCBsaXN0IGNhbGwgZm9yDQo+PiBhZG9wdGlvbiBvZiB0aGUgZHJhZnQgYnkgdGhl IFdHLiBQbGVhc2Ugc2VuZCBhbnkgY29tbWVudHMsIGZvciBvciBhZ2FpbnN0LA0KPj4gdG8gdGhl IGRuc3NkIFdHIGxpc3QuIElmIHlvdSBpbmRpY2F0ZWQgc3VwcG9ydCBpbiB0aGUgbWVldGluZywg ZmVlbCBmcmVlIHRvDQo+PiByZWFmZmlybSB0aGlzLCBhbmQgYWRkIGFueSBjb21tZW50cy4NCj4+ IA0KPj4gVGhlIGNhbGwgZW5kcyBvbiBNb25kYXkgOHRoIEF1Z3VzdC4NCj4+IA0KPj4gVGhlIGRv Y3VtZW50IHN0YXR1cyBpbiB0aGUgZGF0YSB0cmFja2VyIGNhbiBiZSBmb3VuZCBhdA0KPj4gaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaHVpdGVtYS1kbnNzZC1wcml2YWN5 Ly4NCj4+IA0KPj4gTm90ZSB0aGF0IHRoZSBXRyBpbiB3aGljaCB0aGUgc3BlY2lmaWNzIG9mIHRo ZSBwYWlyaW5nIHByb3RvY29sIHdpbGwgYmUNCj4+IGRldmVsb3BlZCB3aWxsIGJlIHJldmlld2Vk IGJ5IG91ciBBRC4gT24gdGhlIG9uZSBoYWQgaXQgaXMgYSBnZW5lcmljDQo+PiBtZWNoYW5pc20g dGhhdCBtYXkgYmUgYmV0dGVyIGRlZmluZWQgaW4gYSBzZWN1cml0eSBXRywgb24gdGhlIG90aGVy IHdlDQo+PiBzaG91bGQgaGF2ZSBhIGNyaXRpY2FsIG1hc3Mgb2YgcGVvcGxlIHRvIGdldCB0aGUg d29yayBkb25lIGhlcmUsIGlmIHRoZQ0KPj4gZHJhZnQgaXMgYWRvcHRlZC4NCj4+IA0KPj4gVGlt DQo+PiANCj4+IA0KPj4gDQo+PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+PiBkbnNzZCBtYWlsaW5nIGxpc3QNCj4+IGRuc3NkQGlldGYub3Jn DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ruc3NkDQo+PiANCj4g DQoNCg== From nobody Tue Jul 26 02:50:50 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC6F12D09C for ; Tue, 26 Jul 2016 02:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.486 X-Spam-Level: X-Spam-Status: No, score=-5.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 HVdsvyR-gEKl for ; Tue, 26 Jul 2016 02:50:46 -0700 (PDT) Received: from purin.rz.uni-konstanz.de (purin.rz.uni-konstanz.de [134.34.240.45]) (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 9FEC512D0CF for ; Tue, 26 Jul 2016 02:50:45 -0700 (PDT) Received: from nkongsamba.rz.uni-konstanz.de (HELO smtp.uni-konstanz.de) ([134.34.240.62]) by viribus.rz.uni-konstanz.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2016 09:50:43 +0000 Received: from [192.168.1.12] (unknown [5.158.128.23]) (Authenticated sender: daniel.kaiser) by smtp.uni-konstanz.de (Postfix) with ESMTPSA id 9467725A for ; Tue, 26 Jul 2016 11:50:43 +0200 (CEST) To: dnssd@ietf.org References: <3D43CEAD-3D12-4E32-AA01-8A1E4ABD8D86@jisc.ac.uk> From: Daniel Kaiser Message-ID: <95946360-5699-4a88-1d2c-18ef684a7a35@uni-konstanz.de> Date: Tue, 26 Jul 2016 11:50:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DA4B718128CC12F61F199DD6" Archived-At: Subject: Re: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 09:50:48 -0000 This is a multi-part message in MIME format. --------------DA4B718128CC12F61F199DD6 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit We started working on a new document on pairing. A reference to this new pairing document will be substituted for the pairing part in the privacy document. Further, we will remove the part on the simple design from the privacy document making it more concise. On 07/26/2016 10:28 AM, Martin Thomson wrote: > What is the status of the pairing piece of this work? None of this > can work without addressing that portion. The document contains some > ideas, but these are quite nebulous and certainly not sufficient to > deploy an interoperable solution for this. > > (I'm generally supportive of this work, but I want to make sure that > everyone understands the scope and magnitude of the work involved > here.) > > On 25 July 2016 at 16:16, Tim Chown wrote: >> Hi, >> >> At the meeting in Berlin, there was a positive reaction to the "Privacy >> Extensions for DNS-SD†draft, >> https://tools.ietf.org/html/draft-huitema-dnssd-privacy-01. >> >> While only a small number of people had read it in detail, those who had >> read it expressed a desire for the WG to adopt the draft. >> >> This email therefore begins a two-week formal dnssd mail list call for >> adoption of the draft by the WG. Please send any comments, for or against, >> to the dnssd WG list. If you indicated support in the meeting, feel free to >> reaffirm this, and add any comments. >> >> The call ends on Monday 8th August. >> >> The document status in the data tracker can be found at >> https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/. >> >> Note that the WG in which the specifics of the pairing protocol will be >> developed will be reviewed by our AD. On the one had it is a generic >> mechanism that may be better defined in a security WG, on the other we >> should have a critical mass of people to get the work done here, if the >> draft is adopted. >> >> Tim >> >> >> >> >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd >> > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --------------DA4B718128CC12F61F199DD6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit We started working on a new document on pairing.
A reference to this new pairing document will be substituted for
the pairing part in the privacy document.

Further, we will remove the part on the simple design from the
privacy document making it more concise.



On 07/26/2016 10:28 AM, Martin Thomson wrote:
What is the status of the pairing piece of this work?  None of this
can work without addressing that portion.  The document contains some
ideas, but these are quite nebulous and certainly not sufficient to
deploy an interoperable solution for this.

(I'm generally supportive of this work, but I want to make sure that
everyone understands the scope and magnitude of the work involved
here.)

On 25 July 2016 at 16:16, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

Hi,

At the meeting in Berlin, there was a positive reaction to the "Privacy
Extensions for DNS-SD†draft,
https://tools.ietf.org/html/draft-huitema-dnssd-privacy-01.

While only a small number of people had read it in detail, those who had
read it expressed a desire for the WG to adopt the draft.

This email therefore begins a two-week formal dnssd mail list call for
adoption of the draft by the WG. Please send any comments, for or against,
to the dnssd WG list. If you indicated support in the meeting, feel free to
reaffirm this, and add any comments.

The call ends on Monday 8th August.

The document status in the data tracker can be found at
https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/.

Note that the WG in which the specifics of the pairing protocol will be
developed will be reviewed by our AD. On the one had it is a generic
mechanism that may be better defined in a security WG, on the other we
should have a critical mass of people to get the work done here, if the
draft is adopted.

Tim




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


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

--------------DA4B718128CC12F61F199DD6-- From nobody Tue Jul 26 02:56:34 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D7612D0B7 for ; Tue, 26 Jul 2016 02:56:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com 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 opp2ZHCDRxuA for ; Tue, 26 Jul 2016 02:56:30 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D854C12D0D3 for ; Tue, 26 Jul 2016 02:56:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p8Egjr5P7C1OH8rwAiGP/F1hej3hAbuSWuHp8ON4I/A=; b=Uroxpxn2craHElFt3cJmoyNdfJl8sFWee+znTuNCe/bJIH5S525D8AjWmP1N+ys9UXayespwGwLpZirVM9FLsZj5y95d7ZPvXIzsygpdVsdqgSuG5R6m/kKxsMSLOuo4/yzxCCHZujkxe0fjntl22t1VsyPmgkeoHDhcs5h1uWc= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp0178.outbound.protection.outlook.com [213.199.154.178]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-55-hHFA1FsMMtqCyWPBXkyJjA-1; Tue, 26 Jul 2016 10:56:21 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Tue, 26 Jul 2016 09:56:18 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Tue, 26 Jul 2016 09:56:19 +0000 From: Tim Chown To: Daniel Kaiser Thread-Topic: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01 Thread-Index: AQHR5n8hnYAn/D72PE2+MNNmSAm3kqAqYmiAgAAW84CAAAH5gA== Date: Tue, 26 Jul 2016 09:56:19 +0000 Message-ID: References: <3D43CEAD-3D12-4E32-AA01-8A1E4ABD8D86@jisc.ac.uk> <95946360-5699-4a88-1d2c-18ef684a7a35@uni-konstanz.de> In-Reply-To: <95946360-5699-4a88-1d2c-18ef684a7a35@uni-konstanz.de> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:829:f3ee:fc02:77e0] x-ms-office365-filtering-correlation-id: 1d90eb32-b2b7-4254-5014-08d3b53b1796 x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 20:/mfHFeRpjmNGlDT6Ymq8pU8qkIWMnyoNntG3s3Sn6t8Ig2y/GhDtf/plJajKTupymQlip2aPvM8SU3eoBji3R2lqLQcLSKq0zeg4HlLB+ciZ3iyOPohm7CSJT4ZOwnWiLw+RZA33EtWao+tjN1tlNviU1/2sav0ra9xUX124jm0= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672)(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(52044002)(377454003)(199003)(189002)(24454002)(16236675004)(81156014)(76176999)(8676002)(2906002)(50986999)(106356001)(97736004)(106116001)(105586002)(122556002)(50226002)(83716003)(6116002)(19580395003)(7736002)(19580405001)(8936002)(81166006)(230783001)(586003)(102836003)(2950100001)(7906003)(82746002)(4326007)(7846002)(189998001)(33656002)(68736007)(74482002)(3660700001)(3280700002)(2900100001)(77096005)(19617315012)(57306001)(10400500002)(110136002)(5002640100001)(92566002)(36756003)(101416001)(15975445007)(86362001)(87936001)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 09:56:19.0815 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-MC-Unique: hHFA1FsMMtqCyWPBXkyJjA-1 Content-Type: multipart/alternative; boundary="_000_E75CFEC5F32B42838784AF3EF922C4ACjiscacuk_" Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 09:56:34 -0000 --_000_E75CFEC5F32B42838784AF3EF922C4ACjiscacuk_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Daniel, On 26 Jul 2016, at 10:50, Daniel Kaiser > wrote: We started working on a new document on pairing. A reference to this new pairing document will be substituted for the pairing part in the privacy document. Further, we will remove the part on the simple design from the privacy document making it more concise. I don=92t think a strong view was expressed either way in Berlin as to whet= her the work should be in one document or two. But if our AD does recommend= taking the pairing work to a different WG, then abstracting the work to a = separate doc will of course be useful. The adoption call for the main document will still need to take into accoun= t that the pairing work needs to be done. Tim On 07/26/2016 10:28 AM, Martin Thomson wrote: What is the status of the pairing piece of this work? None of this can work without addressing that portion. The document contains some ideas, but these are quite nebulous and certainly not sufficient to deploy an interoperable solution for this. (I'm generally supportive of this work, but I want to make sure that everyone understands the scope and magnitude of the work involved here.) On 25 July 2016 at 16:16, Tim Chown wrote: Hi, At the meeting in Berlin, there was a positive reaction to the "Privacy Extensions for DNS-SD=94 draft, https://tools.ietf.org/html/draft-huitema-dnssd-privacy-01. While only a small number of people had read it in detail, those who had read it expressed a desire for the WG to adopt the draft. This email therefore begins a two-week formal dnssd mail list call for adoption of the draft by the WG. Please send any comments, for or against, to the dnssd WG list. If you indicated support in the meeting, feel free to reaffirm this, and add any comments. The call ends on Monday 8th August. The document status in the data tracker can be found at https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/. Note that the WG in which the specifics of the pairing protocol will be developed will be reviewed by our AD. On the one had it is a generic mechanism that may be better defined in a security WG, on the other we should have a critical mass of people to get the work done here, if the draft is adopted. Tim _______________________________________________ dnssd mailing list dnssd@ietf.org https://www.ietf.org/mailman/listinfo/dnssd _______________________________________________ dnssd mailing list dnssd@ietf.org https://www.ietf.org/mailman/listinfo/dnssd _______________________________________________ dnssd mailing list dnssd@ietf.org https://www.ietf.org/mailman/listinfo/dnssd --_000_E75CFEC5F32B42838784AF3EF922C4ACjiscacuk_ Content-Type: text/html; charset=WINDOWS-1252 Content-ID: Content-Transfer-Encoding: quoted-printable Hi Daniel,


On 07/26/2016 10:28 AM, Martin Thomson wrote= :
What is the status of the pairing piece of this w=
ork?  None of this
can work without addressing that portion.  The document contains some
ideas, but these are quite nebulous and certainly not sufficient to
deploy an interoperable solution for this.

(I'm generally supportive of this work, but I want to make sure that
everyone understands the scope and magnitude of the work involved
here.)

On 25 July 2016 at 16:16, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:

Hi,

At the meeting in Berlin, there was a positive reaction to the "Privac=
y
Extensions for DNS-SD=94 draft,
https://tools.ietf.org/html/draft-huitema-dnssd=
-privacy-01.

While only a small number of people had read it in detail, those who had
read it expressed a desire for the WG to adopt the draft.

This email therefore begins a two-week formal dnssd mail list call for
adoption of the draft by the WG. Please send any comments, for or against,
to the dnssd WG list. If you indicated support in the meeting, feel free to
reaffirm this, and add any comments.

The call ends on Monday 8th August.

The document status in the data tracker can be found at
https://datatracker.ietf.org/doc/draft-huite=
ma-dnssd-privacy/.

Note that the WG in which the specifics of the pairing protocol will be
developed will be reviewed by our AD. On the one had it is a generic
mechanism that may be better defined in a security WG, on the other we
should have a critical mass of people to get the work done here, if the
draft is adopted.

Tim




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


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

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

--_000_E75CFEC5F32B42838784AF3EF922C4ACjiscacuk_-- From nobody Tue Jul 26 05:49:53 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E48C12D811 for ; Tue, 26 Jul 2016 05:49:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.486 X-Spam-Level: X-Spam-Status: No, score=-5.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=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 d5vv2P9Rd8jY for ; Tue, 26 Jul 2016 05:49:48 -0700 (PDT) Received: from purin.rz.uni-konstanz.de (purin.rz.uni-konstanz.de [134.34.240.45]) (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 C1B6412D8EF for ; Tue, 26 Jul 2016 05:49:46 -0700 (PDT) Received: from nkongsamba.rz.uni-konstanz.de (HELO smtp.uni-konstanz.de) ([134.34.240.62]) by viribus.rz.uni-konstanz.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jul 2016 12:49:44 +0000 Received: from [192.168.1.12] (unknown [5.158.128.23]) (Authenticated sender: daniel.kaiser) by smtp.uni-konstanz.de (Postfix) with ESMTPSA id 71983106; Tue, 26 Jul 2016 14:49:44 +0200 (CEST) To: Tim Chown References: <3D43CEAD-3D12-4E32-AA01-8A1E4ABD8D86@jisc.ac.uk> <95946360-5699-4a88-1d2c-18ef684a7a35@uni-konstanz.de> From: Daniel Kaiser Message-ID: Date: Tue, 26 Jul 2016 14:49:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------755741DA7E1F2942F6C03A0F" Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 12:49:51 -0000 This is a multi-part message in MIME format. --------------755741DA7E1F2942F6C03A0F Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Tim, we could write a 00 draft on pairing which might help the AD and the WG to decide whether pairing should be 1) integrated in the existing privacy draft, 2) addressed in a separate draft within the dnssd group, or 3) addressed in another working group. As there is consensus that we should address pairing, I will definitely continue working on that :). "The adoption call for the main document will still need to take into account that the pairing work needs to be done." Is there something I should do? kind regards Daniel On 07/26/2016 11:56 AM, Tim Chown wrote: > Hi Daniel, > > On 26 Jul 2016, at 10:50, Daniel Kaiser > wrote: > > We started working on a new document on pairing. > A reference to this new pairing document will be substituted for > the pairing part in the privacy document. > > Further, we will remove the part on the simple design from the > privacy document making it more concise. > > I don’t think a strong view was expressed either way in Berlin as to whether the work should be in one document or two. But if our AD does recommend taking the pairing work to a different WG, then abstracting the work to a separate doc will of course be useful. > > The adoption call for the main document will still need to take into account that the pairing work needs to be done. > > Tim > > On 07/26/2016 10:28 AM, Martin Thomson wrote: > > What is the status of the pairing piece of this work? None of this > can work without addressing that portion. The document contains some > ideas, but these are quite nebulous and certainly not sufficient to > deploy an interoperable solution for this. > > (I'm generally supportive of this work, but I want to make sure that > everyone understands the scope and magnitude of the work involved > here.) > > On 25 July 2016 at 16:16, Tim Chown wrote: > > > Hi, > > At the meeting in Berlin, there was a positive reaction to the "Privacy > Extensions for DNS-SD” draft, > https://tools.ietf.org/html/draft-huitema-dnssd-privacy-01. > > While only a small number of people had read it in detail, those who had > read it expressed a desire for the WG to adopt the draft. > > This email therefore begins a two-week formal dnssd mail list call for > adoption of the draft by the WG. Please send any comments, for or against, > to the dnssd WG list. If you indicated support in the meeting, feel free to > reaffirm this, and add any comments. > > The call ends on Monday 8th August. > > The document status in the data tracker can be found at > https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/. > > Note that the WG in which the specifics of the pairing protocol will be > developed will be reviewed by our AD. On the one had it is a generic > mechanism that may be better defined in a security WG, on the other we > should have a critical mass of people to get the work done here, if the > draft is adopted. > > Tim > > > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > > --------------755741DA7E1F2942F6C03A0F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Tim,

we could write a 00 draft on pairing which might help
the AD and the WG to decide whether pairing should be

1) integrated in the existing privacy draft,
2) addressed in a separate draft within the dnssd group, or
3) addressed in another working group.

As there is consensus that we should address pairing,
I will definitely continue working on that :).

"The adoption call for the main document will still need to take into account that the pairing work needs to be done."

Is there something I should do?


kind regards
Daniel
On 07/26/2016 11:56 AM, Tim Chown wrote:
Hi Daniel,

On 26 Jul 2016, at 10:50, Daniel Kaiser <daniel.kaiser@uni-konstanz.de<mailto:daniel.kaiser@uni-konstanz.de>> wrote:

We started working on a new document on pairing.
A reference to this new pairing document will be substituted for
the pairing part in the privacy document.

Further, we will remove the part on the simple design from the
privacy document making it more concise.

I don’t think a strong view was expressed either way in Berlin as to whether the work should be in one document or two. But if our AD does recommend taking the pairing work to a different WG, then abstracting the work to a separate doc will of course be useful.

The adoption call for the main document will still need to take into account that the pairing work needs to be done.

Tim

On 07/26/2016 10:28 AM, Martin Thomson wrote:

What is the status of the pairing piece of this work?  None of this
can work without addressing that portion.  The document contains some
ideas, but these are quite nebulous and certainly not sufficient to
deploy an interoperable solution for this.

(I'm generally supportive of this work, but I want to make sure that
everyone understands the scope and magnitude of the work involved
here.)

On 25 July 2016 at 16:16, Tim Chown <Tim.Chown@jisc.ac.uk><mailto:Tim.Chown@jisc.ac.uk> wrote:


Hi,

At the meeting in Berlin, there was a positive reaction to the "Privacy
Extensions for DNS-SD” draft,
https://tools.ietf.org/html/draft-huitema-dnssd-privacy-01.

While only a small number of people had read it in detail, those who had
read it expressed a desire for the WG to adopt the draft.

This email therefore begins a two-week formal dnssd mail list call for
adoption of the draft by the WG. Please send any comments, for or against,
to the dnssd WG list. If you indicated support in the meeting, feel free to
reaffirm this, and add any comments.

The call ends on Monday 8th August.

The document status in the data tracker can be found at
https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/.

Note that the WG in which the specifics of the pairing protocol will be
developed will be reviewed by our AD. On the one had it is a generic
mechanism that may be better defined in a security WG, on the other we
should have a critical mass of people to get the work done here, if the
draft is adopted.

Tim




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



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


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

--------------755741DA7E1F2942F6C03A0F-- From nobody Tue Jul 26 05:55:34 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3E4812D7E8 for ; Tue, 26 Jul 2016 05:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com 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 nI4neb43hrXL for ; Tue, 26 Jul 2016 05:55:28 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CBCB12D776 for ; Tue, 26 Jul 2016 05:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rbvnLO5a9ua8qhq//LMCYCa6SwhU6Hh65LgWUoWu2Hg=; b=lOH9vhXbqzkYr9EBjPMqkvpby8bSVWUKk38iflwNP1sqRZVcY08E2E2BSAajkwBC7HTcN8kktsSFMwbvfiDbPCmBE7cjFy/PnpTr5LBkImpZI+M4m2kukrCj8M6jAPx5zRe3Y3M35p4RowkGut2LUdI2OAqGrI45SFaUCE2sL7k= Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp0179.outbound.protection.outlook.com [213.199.180.179]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-12-6cI_aqWfNESUAMDAbvUa8g-1; Tue, 26 Jul 2016 13:55:18 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB454.eurprd07.prod.outlook.com (10.242.106.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Tue, 26 Jul 2016 12:55:15 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Tue, 26 Jul 2016 12:55:15 +0000 From: Tim Chown To: Daniel Kaiser Thread-Topic: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01 Thread-Index: AQHR5n8hnYAn/D72PE2+MNNmSAm3kqAqYmiAgAAW84CAAAH5gIAAMAsAgAAB9QA= Date: Tue, 26 Jul 2016 12:55:15 +0000 Message-ID: <0FF1F49E-DE54-4074-987B-C65799599EF3@jisc.ac.uk> References: <3D43CEAD-3D12-4E32-AA01-8A1E4ABD8D86@jisc.ac.uk> <95946360-5699-4a88-1d2c-18ef684a7a35@uni-konstanz.de> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:829:f3ee:fc02:77e0] x-ms-office365-filtering-correlation-id: a13bceae-e58d-4886-ba2c-08d3b55416e7 x-microsoft-exchange-diagnostics: 1; AMSPR07MB454; 20:t7J36Fp0mxEZpuxv5hqoIF4BnOmyyvMma7R7sxqCNK/KtKkDq7pbZQqcAvtUdeNAkPPDFuGEL53Ri9z/uEdJsO3w5Zm7Ix4bYdhF9++QghM6YjUJGWlzxVFnrQjD3/l9/qsWCRCHWJMj4MNUMvmNADdberkePXn1qrkf3yuHNSc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672)(120809045254105)(192374486261705)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB454; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB454; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(189002)(377454003)(71364002)(52044002)(24454002)(199003)(33656002)(68736007)(2900100001)(15975445007)(102836003)(2950100001)(19617315012)(110136002)(16236675004)(83716003)(74482002)(87936001)(105586002)(6116002)(3660700001)(11100500001)(586003)(86362001)(5002640100001)(3280700002)(36756003)(10400500002)(81156014)(81166006)(122556002)(57306001)(8936002)(50226002)(19580405001)(101416001)(19580395003)(82746002)(50986999)(7846002)(93886004)(77096005)(4326007)(106116001)(8676002)(92566002)(7906003)(106356001)(76176999)(7736002)(97736004)(2906002)(230783001)(189998001)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB454; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 12:55:15.3245 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB454 X-MC-Unique: 6cI_aqWfNESUAMDAbvUa8g-1 Content-Type: multipart/alternative; boundary="_000_0FF1F49EDE544074987BC65799599EF3jiscacuk_" Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 12:55:33 -0000 --_000_0FF1F49EDE544074987BC65799599EF3jiscacuk_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi Daniel, I=92ve popped an email directly to Terry to ask about the pairing work. At the moment, keep working on it; it shouldn=92t be a big deal to merge/sp= lit drafts if/when necessary :) Do feel free to ask open questions you hav= e to the WG list, so they can give opinions and advice. Tim On 26 Jul 2016, at 13:49, Daniel Kaiser > wrote: Hi Tim, we could write a 00 draft on pairing which might help the AD and the WG to decide whether pairing should be 1) integrated in the existing privacy draft, 2) addressed in a separate draft within the dnssd group, or 3) addressed in another working group. As there is consensus that we should address pairing, I will definitely continue working on that :). "The adoption call for the main document will still need to take into accou= nt that the pairing work needs to be done." Is there something I should do? kind regards Daniel On 07/26/2016 11:56 AM, Tim Chown wrote: Hi Daniel, On 26 Jul 2016, at 10:50, Daniel Kaiser > wrote: We started working on a new document on pairing. A reference to this new pairing document will be substituted for the pairing part in the privacy document. Further, we will remove the part on the simple design from the privacy document making it more concise. I don=92t think a strong view was expressed either way in Berlin as to whet= her the work should be in one document or two. But if our AD does recommend= taking the pairing work to a different WG, then abstracting the work to a = separate doc will of course be useful. The adoption call for the main document will still need to take into accoun= t that the pairing work needs to be done. Tim On 07/26/2016 10:28 AM, Martin Thomson wrote: What is the status of the pairing piece of this work? None of this can work without addressing that portion. The document contains some ideas, but these are quite nebulous and certainly not sufficient to deploy an interoperable solution for this. (I'm generally supportive of this work, but I want to make sure that everyone understands the scope and magnitude of the work involved here.) On 25 July 2016 at 16:16, Tim Chown wrot= e: Hi, At the meeting in Berlin, there was a positive reaction to the "Privacy Extensions for DNS-SD=94 draft, https://tools.ietf.org/html/draft-huitema-dnssd-privacy-01. While only a small number of people had read it in detail, those who had read it expressed a desire for the WG to adopt the draft. This email therefore begins a two-week formal dnssd mail list call for adoption of the draft by the WG. Please send any comments, for or against, to the dnssd WG list. If you indicated support in the meeting, feel free to reaffirm this, and add any comments. The call ends on Monday 8th August. The document status in the data tracker can be found at https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/. Note that the WG in which the specifics of the pairing protocol will be developed will be reviewed by our AD. On the one had it is a generic mechanism that may be better defined in a security WG, on the other we should have a critical mass of people to get the work done here, if the draft is adopted. Tim _______________________________________________ dnssd mailing list dnssd@ietf.org https://www.ietf.org/mailman/listinfo/dnssd _______________________________________________ dnssd mailing list dnssd@ietf.org https://www.ietf.org/mailman/listinfo/dnssd _______________________________________________ dnssd mailing list dnssd@ietf.org https://www.ietf.org/mailman/listinfo/dnssd --_000_0FF1F49EDE544074987BC65799599EF3jiscacuk_ Content-Type: text/html; charset=WINDOWS-1252 Content-ID: Content-Transfer-Encoding: quoted-printable Hi Daniel,

I=92ve popped an email directly to Terry to ask about the p= airing work. 

At the moment, keep working on it; it shouldn=92t be a big = deal to merge/split drafts if/when necessary :)  Do feel free to ask o= pen questions you have to the WG list, so they can give opinions and advice= . 

Tim

On 26 Jul 2016, at 13:49, Daniel Kaiser <daniel.kaiser@uni-konstanz.de<= /a>> wrote:

Hi Tim,

we could write a 00 draft on pairing which might help
the AD and the WG to decide whether pairing should be

1) integrated in the existing privacy draft,
2) addressed in a separate draft within the dnssd group, or
3) addressed in another working group.

As there is consensus that we should address pairing,
I will definitely continue working on that :).

"The adoption call for the main document wil=
l still need to take into account that the pairing work needs to be done.&q=
uot;
Is there something I should do?


kind regards
Daniel
On 07/26/2016 11:56 AM, Tim Chown wrote:
Hi Daniel,

On 26 Jul 2016, at 10:50, Daniel Kaiser <daniel.kaiser@uni-kons=
tanz.de<mailto:daniel.kaiser@uni-konstanz.de>> wrote=
:

We started working on a new document on pairing.
A reference to this new pairing document will be substituted for
the pairing part in the privacy document.

Further, we will remove the part on the simple design from the
privacy document making it more concise.

I don=92t think a strong view was expressed either way in Berlin as to whet=
her the work should be in one document or two. But if our AD does recommend=
 taking the pairing work to a different WG, then abstracting the work to a =
separate doc will of course be useful.

The adoption call for the main document will still need to take into accoun=
t that the pairing work needs to be done.

Tim

On 07/26/2016 10:28 AM, Martin Thomson wrote:

What is the status of the pairing piece of this work?  None of this
can work without addressing that portion.  The document contains some
ideas, but these are quite nebulous and certainly not sufficient to
deploy an interoperable solution for this.

(I'm generally supportive of this work, but I want to make sure that
everyone understands the scope and magnitude of the work involved
here.)

On 25 July 2016 at 16:16, Tim Chown <Tim.Chown@jisc.ac.uk><mailto:=
Tim.Chown@jisc.ac.uk> wrote:


Hi,

At the meeting in Berlin, there was a positive reaction to the "Privac=
y
Extensions for DNS-SD=94 draft,
https://tools.ietf.org/html/draft-huitema-dnssd=
-privacy-01.

While only a small number of people had read it in detail, those who had
read it expressed a desire for the WG to adopt the draft.

This email therefore begins a two-week formal dnssd mail list call for
adoption of the draft by the WG. Please send any comments, for or against,
to the dnssd WG list. If you indicated support in the meeting, feel free to
reaffirm this, and add any comments.

The call ends on Monday 8th August.

The document status in the data tracker can be found at
https://datatracker.ietf.org/doc/draft-huite=
ma-dnssd-privacy/.

Note that the WG in which the specifics of the pairing protocol will be
developed will be reviewed by our AD. On the one had it is a generic
mechanism that may be better defined in a security WG, on the other we
should have a critical mass of people to get the work done here, if the
draft is adopted.

Tim




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



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


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


--_000_0FF1F49EDE544074987BC65799599EF3jiscacuk_-- From nobody Tue Jul 26 08:15:57 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81EB412DEF0 for ; Tue, 26 Jul 2016 08:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.022 X-Spam-Level: X-Spam-Status: No, score=-102.022 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com 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 ATGS0rAOI8Aw for ; Tue, 26 Jul 2016 08:15:51 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0133.outbound.protection.outlook.com [104.47.38.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B429912DFF0 for ; Tue, 26 Jul 2016 07:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=+NwhoMqJJ1gGeJAGXMR4/i4BXHP93mPpPE6Zkchd7Es=; b=nws0foUUrdH24OJ33m/oaiPstRKNrPE9yBNnNGPtQNYoMm3aMjjiO/+b/pLUmbDSup1Y4cdVJQLcoCQX36+zTzwQ3FPf+VGHbwaD2RIml67mobCU9Md98owVulQD2t57/i6oceX5ompqWVi8Ned9caX0e4rTvEO7mZb1ej5C3Os= Received: from DM2PR0301MB0717.namprd03.prod.outlook.com (10.160.97.13) by DM2PR0301MB0719.namprd03.prod.outlook.com (10.160.97.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.544.10; Tue, 26 Jul 2016 14:41:12 +0000 Received: from DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) by DM2PR0301MB0717.namprd03.prod.outlook.com ([10.160.97.13]) with mapi id 15.01.0544.019; Tue, 26 Jul 2016 14:41:13 +0000 From: Dave Thaler To: Martin Thomson , Tim Chown Thread-Topic: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01 Thread-Index: AQHR5n8h77w/q2pT+k6oPIkttErys6AqYmiAgABnx8A= Date: Tue, 26 Jul 2016 14:41:13 +0000 Message-ID: References: <3D43CEAD-3D12-4E32-AA01-8A1E4ABD8D86@jisc.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [73.193.101.106] x-ms-office365-filtering-correlation-id: 521477a8-b406-4aad-3fb6-08d3b562e4b0 x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0719; 6:YSIAq+rWLQ61/z0t/NyrLiUiHK1Q+RGBCzP9YN3NZrwOcmg651UJey4X2YywIanFF89Am/cwVoRB1Tbu6JFOmpdFPMObluTrajDMgWlsKh7TXzZXOpilbzQ5DbgbcJ4lywdUXaoV6NRyYTk2mjhksrlfoYyXyKVZH5JM29Gkwpqq12ByL05jPRDqpo2y4eh4NWuNBJof4a6armsjLkw0INFGcw/M+pEAVQ53Wf+o8jHphFJKYskkLI8QhClBT07qcKGo5DmucNFC6L5jO7WiNxxz6HTypUOx12BQlWTRUUkL3J4zGn/ycXEXkIR65U8/+B7wKrG6Beyfqat0Af6hnw==; 5:4eftIreMAzFkrXyoEwNaIltzaRXlZ5VhNk7QHXCgI16yfegNDnYA6B9CwV8aQRN01UIXziiVEl2ekSL174Aif+9x5CwtK2fPcxfGRHDIGiOlV6qg1scUAofA46j1y6crvXQJOwxz6uQjefPX+BROuw==; 24:M3jDVxBcN5WuLpRr5vjYOjxNl9JdOFxTInVDiMi710gSm96tSn4xPZ8K+rYHGx5BcYoMWJoACQieNk6Kyw4Zmf5vpMj4m0rXMYbUtpGpL1I=; 7:UQhvNS421JXNDr8Rog2JMioPWn+jqktoeJGKLdZ/1rOs0XMARQjb5o/hyzs4a6B4U2SlkDK8/E5Vnijp9nkWlnNkstrcmpGA1tUR7rr2ZBuouWJZYmGuhrPpQRBeWFK7fnuqJ0+um7uw0UEIIWlYIkrB3u3uKkb7cy+c0aZq52KJLDJtHbekdgl8JMShHdNRnlCVFJH6LK7PbgNR7JQXkmLjFJs1GtZXVozQftSJYUxjO5hIADqju5yzHVUSJsgv x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0719; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(274715658323672)(120809045254105)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0719; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0719; x-forefront-prvs: 00159D1518 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(24454002)(13464003)(199003)(377454003)(52044002)(8936002)(77096005)(15975445007)(2950100001)(2900100001)(81156014)(81166006)(99286002)(10090500001)(66066001)(2906002)(101416001)(105586002)(4326007)(106356001)(3846002)(76176999)(586003)(102836003)(74316002)(6116002)(54356999)(50986999)(106116001)(230783001)(97736004)(5001770100001)(189998001)(9686002)(19580405001)(7696003)(7736002)(86612001)(76576001)(8990500004)(10400500002)(5002640100001)(8676002)(3280700002)(7846002)(5003600100003)(68736007)(3660700001)(5005710100001)(19580395003)(305945005)(33656002)(92566002)(122556002)(10290500002)(87936001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0719; H:DM2PR0301MB0717.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 14:41:13.5698 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0719 Archived-At: Cc: "dnssd@ietf.org" , Terry Manderson Subject: Re: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jul 2016 15:15:55 -0000 SnVzdCByZWFmZmlybWluaW5nIHdoYXQgSSBzYWlkIGF0IHRoZSBtaWMuDQoNCkkgc3VwcG9ydCBh ZG9wdGluZyB0aGlzIGRyYWZ0LCB3aGlsZSB0aGUgcGFpcmluZyBwb3J0aW9uIEkgd291bGQgcHJl ZmVyIGJlIGluIGEgc2VwYXJhdGUNCmRyYWZ0IGluIGEgZGlmZmVyZW50IGdyb3VwIChlLmcuIGlu dGFyZWEgd2l0aCBqb2ludCByZXZpZXcgYnkgc2FhZyksIHNpbmNlIHRoZSBwYWlyaW5nIHBhcnQN CnNob3VsZCBub3QgYmUgc3BlY2lmaWMgdG8gZG5zc2QuDQoNCkRhdmUNCg0KPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkbnNzZCBbbWFpbHRvOmRuc3NkLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gVGhvbXNvbg0KPiBTZW50OiBUdWVzZGF5LCBKdWx5 IDI2LCAyMDE2IDE6MjkgQU0NCj4gVG86IFRpbSBDaG93biA8VGltLkNob3duQGppc2MuYWMudWs+ DQo+IENjOiBkbnNzZEBpZXRmLm9yZzsgVGVycnkgTWFuZGVyc29uIDx0ZXJyeS5tYW5kZXJzb25A aWNhbm4ub3JnPg0KPiBTdWJqZWN0OiBSZTogW2Ruc3NkXSBDYWxsIGZvciBXRyBBZG9wdGlvbjog ZHJhZnQtaHVpdGVtYS1kbnNzZC1wcml2YWN5LTAxDQo+IA0KPiBXaGF0IGlzIHRoZSBzdGF0dXMg b2YgdGhlIHBhaXJpbmcgcGllY2Ugb2YgdGhpcyB3b3JrPyAgTm9uZSBvZiB0aGlzIGNhbiB3b3Jr DQo+IHdpdGhvdXQgYWRkcmVzc2luZyB0aGF0IHBvcnRpb24uICBUaGUgZG9jdW1lbnQgY29udGFp bnMgc29tZSBpZGVhcywgYnV0DQo+IHRoZXNlIGFyZSBxdWl0ZSBuZWJ1bG91cyBhbmQgY2VydGFp bmx5IG5vdCBzdWZmaWNpZW50IHRvIGRlcGxveSBhbg0KPiBpbnRlcm9wZXJhYmxlIHNvbHV0aW9u IGZvciB0aGlzLg0KPiANCj4gKEknbSBnZW5lcmFsbHkgc3VwcG9ydGl2ZSBvZiB0aGlzIHdvcmss IGJ1dCBJIHdhbnQgdG8gbWFrZSBzdXJlIHRoYXQgZXZlcnlvbmUNCj4gdW5kZXJzdGFuZHMgdGhl IHNjb3BlIGFuZCBtYWduaXR1ZGUgb2YgdGhlIHdvcmsgaW52b2x2ZWQNCj4gaGVyZS4pDQo+IA0K PiBPbiAyNSBKdWx5IDIwMTYgYXQgMTY6MTYsIFRpbSBDaG93biA8VGltLkNob3duQGppc2MuYWMu dWs+IHdyb3RlOg0KPiA+IEhpLA0KPiA+DQo+ID4gQXQgdGhlIG1lZXRpbmcgaW4gQmVybGluLCB0 aGVyZSB3YXMgYSBwb3NpdGl2ZSByZWFjdGlvbiB0byB0aGUNCj4gPiAiUHJpdmFjeSBFeHRlbnNp b25zIGZvciBETlMtU0TigJ0gZHJhZnQsDQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWh1aXRlbWEtZG5zc2QtcHJpdmFjeS0wMS4NCj4gPg0KPiA+IFdoaWxlIG9ubHkgYSBz bWFsbCBudW1iZXIgb2YgcGVvcGxlIGhhZCByZWFkIGl0IGluIGRldGFpbCwgdGhvc2Ugd2hvDQo+ ID4gaGFkIHJlYWQgaXQgZXhwcmVzc2VkIGEgZGVzaXJlIGZvciB0aGUgV0cgdG8gYWRvcHQgdGhl IGRyYWZ0Lg0KPiA+DQo+ID4gVGhpcyBlbWFpbCB0aGVyZWZvcmUgYmVnaW5zIGEgdHdvLXdlZWsg Zm9ybWFsIGRuc3NkIG1haWwgbGlzdCBjYWxsIGZvcg0KPiA+IGFkb3B0aW9uIG9mIHRoZSBkcmFm dCBieSB0aGUgV0cuIFBsZWFzZSBzZW5kIGFueSBjb21tZW50cywgZm9yIG9yDQo+ID4gYWdhaW5z dCwgdG8gdGhlIGRuc3NkIFdHIGxpc3QuIElmIHlvdSBpbmRpY2F0ZWQgc3VwcG9ydCBpbiB0aGUN Cj4gPiBtZWV0aW5nLCBmZWVsIGZyZWUgdG8gcmVhZmZpcm0gdGhpcywgYW5kIGFkZCBhbnkgY29t bWVudHMuDQo+ID4NCj4gPiBUaGUgY2FsbCBlbmRzIG9uIE1vbmRheSA4dGggQXVndXN0Lg0KPiA+ DQo+ID4gVGhlIGRvY3VtZW50IHN0YXR1cyBpbiB0aGUgZGF0YSB0cmFja2VyIGNhbiBiZSBmb3Vu ZCBhdA0KPiA+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1aXRlbWEt ZG5zc2QtcHJpdmFjeS8uDQo+ID4NCj4gPiBOb3RlIHRoYXQgdGhlIFdHIGluIHdoaWNoIHRoZSBz cGVjaWZpY3Mgb2YgdGhlIHBhaXJpbmcgcHJvdG9jb2wgd2lsbA0KPiA+IGJlIGRldmVsb3BlZCB3 aWxsIGJlIHJldmlld2VkIGJ5IG91ciBBRC4gT24gdGhlIG9uZSBoYWQgaXQgaXMgYQ0KPiA+IGdl bmVyaWMgbWVjaGFuaXNtIHRoYXQgbWF5IGJlIGJldHRlciBkZWZpbmVkIGluIGEgc2VjdXJpdHkg V0csIG9uIHRoZQ0KPiA+IG90aGVyIHdlIHNob3VsZCBoYXZlIGEgY3JpdGljYWwgbWFzcyBvZiBw ZW9wbGUgdG8gZ2V0IHRoZSB3b3JrIGRvbmUNCj4gPiBoZXJlLCBpZiB0aGUgZHJhZnQgaXMgYWRv cHRlZC4NCj4gPg0KPiA+IFRpbQ0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBkbnNzZCBtYWlsaW5nIGxp c3QNCj4gPiBkbnNzZEBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vZG5zc2QNCj4gPg0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gZG5zc2QgbWFpbGluZyBsaXN0DQo+IGRuc3NkQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zc2QNCg== From nobody Wed Jul 27 08:35:15 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2D712DB25 for ; Wed, 27 Jul 2016 08:35:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.109 X-Spam-Level: X-Spam-Status: No, score=-4.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com 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 pcMnfu2Izs7J for ; Wed, 27 Jul 2016 08:35:11 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D8B812D848 for ; Wed, 27 Jul 2016 08:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qKO/+4m5LoWnRmJ7vJpbW6nosqdf3VQFZNKwyYrYY8c=; b=VSHIDsGL+JYygW3K3Xgszua5NRGl7feA3+7YjzjDj2ptFc1ROytRIC8TbbQEYCNmR47YEadQqSmXjyxGTa4wlCuQMaZIxggxbEwn5QePUNEcnwDUrb3qr8MF6pNF0BRfkx3JarTnTo4B1Dxnl9Ci4Q++d4Taoren5Moq8Gn8/3Y= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0214.outbound.protection.outlook.com [213.199.154.214]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-49-ucvhNPA4Mj2eJry9UQfrag-1; Wed, 27 Jul 2016 16:35:04 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.534.14; Wed, 27 Jul 2016 15:35:02 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0539.023; Wed, 27 Jul 2016 15:35:02 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: IETF96 draft meeting minutes Thread-Index: AQHR6BxwfOK776l100OyKOi/dgoHxA== Date: Wed, 27 Jul 2016 15:35:02 +0000 Message-ID: <13162256-02BA-4982-9AEB-B6B536B50732@jisc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: 85272607-914f-4cd3-00ea-08d3b6339374 x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 20:UPre1bVVEwNMD4WROhMohhQWvFcFlVQ7JwB2oyJ/yaJ2rQO+xRUSAds+rJg8mYxzLHx7vvz+tqHlijpezAyW7sBQApa+4Kvvh3vSpQ/GmdIKIp8PUHMVPlM8Yqtue3tLYlgoMZZzSJrUEhv6OI0poHQOBIJZZ4hJi3s2FgubkXQ= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(209352067349851); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 0016DEFF96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(279900001)(52044002)(66654002)(199003)(189002)(10400500002)(77096005)(2900100001)(110136002)(11100500001)(107886002)(101416001)(19617315012)(57306001)(66066001)(189998001)(3280700002)(19625305001)(5640700001)(33656002)(3846002)(68736007)(450100001)(36756003)(87936001)(74482002)(92566002)(15975445007)(86362001)(3660700001)(97736004)(105586002)(106116001)(106356001)(122556002)(5002640100001)(229853001)(2501003)(16236675004)(81156014)(8676002)(2906002)(50986999)(6116002)(7906003)(102836003)(7846002)(82746002)(586003)(83716003)(19580395003)(2351001)(7736002)(8936002)(81166006)(1730700003)(50226002)(5003080100003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2016 15:35:02.1291 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-MC-Unique: ucvhNPA4Mj2eJry9UQfrag-1 Content-Type: multipart/alternative; boundary="_000_1316225602BA49829AEBB6B536B50732jiscacuk_" Archived-At: Subject: [dnssd] IETF96 draft meeting minutes X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jul 2016 15:35:13 -0000 --_000_1316225602BA49829AEBB6B536B50732jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNClRoZSBkcmFmdCBtaW51dGVzIGFyZSBvbmxpbmUgYXQgdGhlIFdHIGV0aGVycGFkIGF0 DQoNCmh0dHA6Ly9ldGhlcnBhZC50b29scy5pZXRmLm9yZzo5MDAwL3Avbm90ZXMtaWV0Zi05Ni1k bnNzZD91c2VNb25vc3BhY2VGb250PXRydWUNCg0KUGxlYXNlIGZlZWwgZnJlZSB0byBjaGVjayB0 aGVzZSwgZXNwZWNpYWxseSB3aGVyZSB5b3VyIG93biBjb21tZW50cyBhcmUgY2FwdHVyZWQuDQoN CkEgY291cGxlIG9mIG5hbWVzIHdlcmUgbm90IGNhdWdodC4NCg0KV2XigJlsbCBjbG9zZSB0aGUg ZXRoZXJwYWQgb24gRnJpZGF5IGFuZCBzdWJtaXQgdGhlIGZpbmFsIG1pbnV0ZXMgZnJvbSB0aGlz Lg0KDQpNYW55IHRoYW5rcywNClRpbQ0KDQoNCg0K --_000_1316225602BA49829AEBB6B536B50732jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <38712A7CDF51BB4AB6D4A834C46B2E76@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgZHJhZnQgbWludXRlcyBhcmUg b25saW5lIGF0IHRoZSBXRyBldGhlcnBhZCBhdCZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cDovL2V0aGVy cGFkLnRvb2xzLmlldGYub3JnOjkwMDAvcC9ub3Rlcy1pZXRmLTk2LWRuc3NkP3VzZU1vbm9zcGFj ZUZvbnQ9dHJ1ZSIgY2xhc3M9IiI+aHR0cDovL2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkwMDAv cC9ub3Rlcy1pZXRmLTk2LWRuc3NkP3VzZU1vbm9zcGFjZUZvbnQ9dHJ1ZTwvYT48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlBsZWFzZSBm ZWVsIGZyZWUgdG8gY2hlY2sgdGhlc2UsIGVzcGVjaWFsbHkgd2hlcmUgeW91ciBvd24gY29tbWVu dHMgYXJlIGNhcHR1cmVkLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+QSBjb3VwbGUgb2YgbmFtZXMgd2VyZSBub3QgY2F1Z2h0LjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2Xi gJlsbCBjbG9zZSB0aGUgZXRoZXJwYWQgb24gRnJpZGF5IGFuZCBzdWJtaXQgdGhlIGZpbmFsIG1p bnV0ZXMgZnJvbSB0aGlzLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+TWFueSB0aGFua3MsPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+VGltJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjwv ZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1316225602BA49829AEBB6B536B50732jiscacuk_-- From nobody Thu Jul 28 04:27:27 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBBC12D65F for ; Thu, 28 Jul 2016 04:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DIbvqGx2sS72 for ; Thu, 28 Jul 2016 04:27:24 -0700 (PDT) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 2C32912D5F7 for ; Thu, 28 Jul 2016 04:27:24 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id f6so26193335ith.0 for ; Thu, 28 Jul 2016 04:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uXkgj3sv+1U7wdIdWC/kM2U9RkX68gO+g6C7MNB9Y3s=; b=o4KyqnNFIxOn3JFM394Grlx3epgJSzw49SQmslg9AXkHxHqyRs/RN9kvx/xskpXmhQ V7hYntKyksAFLO5UC9hEtYRD7FYSjEhT+A4sYNiZ3lJp3M5WZLvhdT58mxI0d/wlO+xI RKSdUda52W1vSPN0Zw6O45UBL1T+/9Dm0zgZVCVDI5zqZ3QjSmNI8tvU22jWnkbqARAU qXaiLpNHKSlSnlycIzuev1/8ZJCoc5Q9ErxXjqpTxab5Xqybye41hFb5NzVvjfd4jzYg MKnl74OYPih41N4pppcXYOKCisBb3tqgdliBtF9Aqr4lH0L+vSUet51w9ao4acQNklyh ihHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uXkgj3sv+1U7wdIdWC/kM2U9RkX68gO+g6C7MNB9Y3s=; b=aK5ODus1GfHXpGT4YTlXw3wK4gsShI+aKLsrCbcW/+/YAz8Xk3EARzRTud/mRyi4rk evVsYpPGBTlcTeORB2S/bC6ffaKdS+5VORiwa6377uDbpAhZFx3gIDZIxcxIiL47gfUg U5SG3QVMQEwpLDRpSypeyJI0cW+i6uXJgAQ8r7Ty2bcIEy0KF4a8fvbG6mtfbFi0KNrh NZ73gQE2Ru5SEHs1hvbeXjqnzAdFNQVnRTtP7Jhf3vQC6jY5kQC5e6djAYuBvr6O1ptT 9g4ywR31K/TmQNkbjwiAxRelE0I61AMF0WOQ10yDIluHKZdqonKqoHWJ55jJiC8ev7aF glPw== X-Gm-Message-State: AEkoouu0bk7liMI94gWGwhgqD+b1QiOi7/42WUd2OfZOX52HSN6xRYNJpeInLDg2nvgN25Kzqq3uuTw64nGkQg== X-Received: by 10.36.101.195 with SMTP id u186mr36149980itb.80.1469705243487; Thu, 28 Jul 2016 04:27:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.5.207 with HTTP; Thu, 28 Jul 2016 04:27:22 -0700 (PDT) In-Reply-To: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> References: <2040EE15-81F8-47EB-BF8D-DA544564C304@att.com> From: william manning Date: Thu, 28 Jul 2016 04:27:22 -0700 Message-ID: To: "STARK, BARBARA H" Content-Type: multipart/alternative; boundary=001a1143ce1af6b8470538b06af0 Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] Setting device friendly names X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2016 11:27:26 -0000 --001a1143ce1af6b8470538b06af0 Content-Type: text/plain; charset=UTF-8 i've been in this neighborhood before. Not sure there exists a clearly defined meaning for "friendly". That said, there exists a canonical name. Others (governments, DNS admins, DHCP, UPnP, et.al.) are external, third parties and often set their own rules as to the "name" of an entity in their own context. Thirdly, a name often consists of several facets or attributes. The construct that was used for the Client Based Naming system was tripart; a) a string of unicode labels, b) a cryptographic certificate for the string of unicode labels, and c) a locality reference where the string and the certificate were first bound. All non-canonical names were derived from one or more facets or fragments of facets of the canonical name. A shorter name most of the time, On Wed, Jul 20, 2016 at 6:22 AM, STARK, BARBARA H wrote: > In my experience, many devices already support mechanisms for friendly > name acquisition. Many devices, including PCs, ask for names during setup. > Others support UPnP friendly name service. Others have UIs to allow naming. > What I really want (as a user) is for the device to have the same name in > all contexts. So if it's been named, through whatever means, use that name. > Which to me says we don't need a new standard for remote naming that all > devices must support. > Barbara > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --001a1143ce1af6b8470538b06af0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
i've been in this neighborhood before.=C2=A0 Not sure = there exists a clearly defined meaning for "friendly".=C2=A0 That= said, there exists a canonical name.=C2=A0 Others (governments, DNS admins= , DHCP, UPnP, et.al.) are external, third part= ies and often set their own rules as to the "name" of an entity i= n their own context.=C2=A0 Thirdly, a name often consists of several facets= or attributes.=C2=A0 The construct that was used for the Client Based Nami= ng system was tripart; =C2=A0a) a string of unicode labels, =C2=A0b) a cryp= tographic certificate for the string of unicode labels, =C2=A0and =C2=A0c) = a locality reference where the string and the certificate were first bound.= =C2=A0=C2=A0
All non-canonical names were derived from one or more fac= ets or fragments of facets of the canonical name.=C2=A0 A shorter name most= of the time,=C2=A0

On Wed, Jul 20, 2016 at 6:22 AM, STARK, BARBAR= A H <bs7652@att.com> wrote:
I= n my experience, many devices already support mechanisms for friendly name = acquisition. Many devices, including PCs, ask for names during setup. Other= s support UPnP friendly name service. Others have UIs to allow naming. What= I really want (as a user) is for the device to have the same name in all c= ontexts. So if it's been named, through whatever means, use that name. = Which to me says we don't need a new standard for remote naming that al= l devices must support.
Barbara
_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd

--001a1143ce1af6b8470538b06af0-- From nobody Sun Jul 31 12:18:24 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8A112D5B4 for ; Sun, 31 Jul 2016 12:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 3rfb3s3Xve3H for ; Sun, 31 Jul 2016 12:18:22 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::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 D413E12B008 for ; Sun, 31 Jul 2016 12:18:21 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id x1so129616978qkb.3 for ; Sun, 31 Jul 2016 12:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TIOIHyMPoRx3GVRVWsZl+xpEKVP5A/4eABw/sVNXSgw=; b=EE+DPGCA2QMWurkZBqXXUGfJS/gLCQYkf8NyKyIu3lEj49XwU4oXI/zZPlpXfdr/pf nACM/NEa81Ymi+N0De68gfdZ7FADHTO2KbfT9XE7SN+fTyqmSQ7jWYYXytQyR8YnbX87 XTwYrbrhRaVDMrUQrUjQpDYFXmzqxWiLzvxbuBKGqg0ABOLylea8KALkn6X5qUwUO2nS xj2lvc0hOm6DqtV4zEp6g1SnsEbPPeHA4MZ+P8pHmY6hVjYLMAyoFwUekCE2Q4Gu2MfV qLlYlT+aR5X4qQftvwrvcZ43tAWfacNUvkFQwM+SEcAvOIFBM7xrXRg+3UPxkYzGtZiB v7lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TIOIHyMPoRx3GVRVWsZl+xpEKVP5A/4eABw/sVNXSgw=; b=lnJFslkTRswcxWcP29Sq4Dte+QQ+saXp5BhLz0m7SvE5LnTPAXY7Qb+RQabRRxmdjv jYYoZBwQ3SQRsTkXOeFZCjVDrSP980jTtXFiHwh2rAJHzIlcuQtaeZL6XusWhmMSKpBi FNjYUfuflvfAP+MMgPFIfr1VCoMaD78FiEq12OAHnfF2QXpktmMfXOVSH7gn/tksHT+C /ZRWWYTun7BxdQWoYe/eOji8yIG0XVo0vXuAB7u9MlMJcfIZnyuNxKUdgxGC8d+Tm/U2 iXNylrgmfTwBFewL0wthK1vPo/ip1FGplicoJnpvpwE1NZFCBFe1XIsdJZY4nwxtuXca 2oow== X-Gm-Message-State: AEkoouv1miV8i0wb6cPkj7a8Q4l8wMrLOZFPeR/UI2eQHE830cv30lxl0oBqBV3YDMK7Vg== X-Received: by 10.55.80.68 with SMTP id e65mr61467622qkb.156.1469992701035; Sun, 31 Jul 2016 12:18:21 -0700 (PDT) Received: from [172.16.1.93] (barracuda.baseballhall.org. [64.246.131.210]) by smtp.gmail.com with ESMTPSA id g3sm9164919qkf.35.2016.07.31.12.18.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 31 Jul 2016 12:18:20 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Tim Wicinski X-Mailer: iPhone Mail (13G34) In-Reply-To: Date: Sun, 31 Jul 2016 15:18:17 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3912E2F7-C270-4016-A0A4-38E965227DB0@gmail.com> References: <3D43CEAD-3D12-4E32-AA01-8A1E4ABD8D86@jisc.ac.uk> To: Dave Thaler Archived-At: Cc: Tim Chown , "dnssd@ietf.org" , Martin Thomson , Terry Manderson Subject: Re: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 19:18:23 -0000 I support adoption , and I'd like to second Dave's point on the pairing.=20 =46rom my high tech gadget > On Jul 26, 2016, at 10:41, Dave Thaler wrote: >=20 > Just reaffirmining what I said at the mic. >=20 > I support adopting this draft, while the pairing portion I would prefer be= in a separate > draft in a different group (e.g. intarea with joint review by saag), since= the pairing part > should not be specific to dnssd. >=20 > Dave >=20 >> -----Original Message----- >> From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Martin Thomson >> Sent: Tuesday, July 26, 2016 1:29 AM >> To: Tim Chown >> Cc: dnssd@ietf.org; Terry Manderson >> Subject: Re: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01= >>=20 >> What is the status of the pairing piece of this work? None of this can w= ork >> without addressing that portion. The document contains some ideas, but >> these are quite nebulous and certainly not sufficient to deploy an >> interoperable solution for this. >>=20 >> (I'm generally supportive of this work, but I want to make sure that ever= yone >> understands the scope and magnitude of the work involved >> here.) >>=20 >>> On 25 July 2016 at 16:16, Tim Chown wrote: >>> Hi, >>>=20 >>> At the meeting in Berlin, there was a positive reaction to the >>> "Privacy Extensions for DNS-SD=E2=80=9D draft, >>> https://tools.ietf.org/html/draft-huitema-dnssd-privacy-01. >>>=20 >>> While only a small number of people had read it in detail, those who >>> had read it expressed a desire for the WG to adopt the draft. >>>=20 >>> This email therefore begins a two-week formal dnssd mail list call for >>> adoption of the draft by the WG. Please send any comments, for or >>> against, to the dnssd WG list. If you indicated support in the >>> meeting, feel free to reaffirm this, and add any comments. >>>=20 >>> The call ends on Monday 8th August. >>>=20 >>> The document status in the data tracker can be found at >>> https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/. >>>=20 >>> Note that the WG in which the specifics of the pairing protocol will >>> be developed will be reviewed by our AD. On the one had it is a >>> generic mechanism that may be better defined in a security WG, on the >>> other we should have a critical mass of people to get the work done >>> here, if the draft is adopted. >>>=20 >>> Tim >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Sun Jul 31 12:26:45 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83FC412D5B4 for ; Sun, 31 Jul 2016 12:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com 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 CdwiFo90NirI for ; Sun, 31 Jul 2016 12:26:42 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 BDAF112D0E6 for ; Sun, 31 Jul 2016 12:26:41 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id b199so102395809lfe.0 for ; Sun, 31 Jul 2016 12:26:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Uxw2ig2UL0uJD+haIW9zTrVb3JL6XuY9hWErQDOymAU=; b=Yc9nezyvf9rj0aSp9TapFWNW+wJDHdz7rkHdDLvs6SxWtuSGeDUwpTfw4PbvnhHmal hosUE2BiVfTiqYbjFsSoVE2YG7rR7SCBGBsHk9ECJMShm8+BTnXH2bfmWioKGUyDh483 M14sDx+xMFilSFhojZzIzr4sLtETfhvCqQNk3InVTryuXxXmItIx7K1qRFShlY8axbte W4qfmdOU72TZzRUpLeYYAoZ18G5Ckunb6LXd4t/SSukq/KwQf/t77LkYdADqBw5lwtng Jm7AUViDIggKmqaHijzcPrm7r7HbGZUzm3RZ7XD9boytn/Xk9N74wILeoo3pyMnRvbvU izoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Uxw2ig2UL0uJD+haIW9zTrVb3JL6XuY9hWErQDOymAU=; b=k/PBxYM2kaSK1TeCkwrrx5E32u+Zoe4pNcrXxP9NEvwjfM8ZnTk31BMaUF1Fpado7+ hVnUGL+N6YjEYU1LQSgSxk6Gw3ZQzBBAM7Cap/XbLfOMJuY0XcpkkyTARRpPqHcKC3HH 4d/tKwtqAXed0K6OS0G2iRPziEJBpN+FHUR1AMmbqKjfYrYr7LmYUmS+Y92i87vDJaGV gtcWul7XgMfGraQo/4nyVJFIffzW+oGK7CbCbh8xQF6LTFSF1puy6RPjM0+GFy0MdOFy 62be/C+2xsUw2g3A3qX+d1I/UoFHlyNQ7+T6A8HZso/c2i39hkZ+JiP5fu3Grq3eMxRc XHtA== X-Gm-Message-State: AEkooutHTsYNFKIKyvgrT2p6xcuLW6d/17RVlJIEdG2/3BK+aPpAjfKyuTCqKUPd+ZO9DYYppzZk4q6aFv6eiQ== X-Received: by 10.25.210.80 with SMTP id j77mr16036576lfg.139.1469993199671; Sun, 31 Jul 2016 12:26:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.217.93 with HTTP; Sun, 31 Jul 2016 12:26:38 -0700 (PDT) Received: by 10.25.217.93 with HTTP; Sun, 31 Jul 2016 12:26:38 -0700 (PDT) In-Reply-To: <3912E2F7-C270-4016-A0A4-38E965227DB0@gmail.com> References: <3D43CEAD-3D12-4E32-AA01-8A1E4ABD8D86@jisc.ac.uk> <3912E2F7-C270-4016-A0A4-38E965227DB0@gmail.com> From: Ted Lemon Date: Sun, 31 Jul 2016 15:26:38 -0400 Message-ID: To: Tim Wicinski Content-Type: multipart/alternative; boundary=001a11400ee67d2d7c0538f37650 Archived-At: Cc: Tim Chown , dnssd@ietf.org, Martin Thomson , Dave Thaler , Terry Manderson Subject: Re: [dnssd] Call for WG Adoption: draft-huitema-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jul 2016 19:26:44 -0000 --001a11400ee67d2d7c0538f37650 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I also support adoption of this work. I don't have a problem with putting pairing in a separate document, but let's not get to caught up in process. We need to do the work where there are people who want to do the work. On Jul 31, 2016 3:18 PM, "Tim Wicinski" wrote: > I support adoption , and I'd like to second Dave's point on the pairing. > > From my high tech gadget > > > On Jul 26, 2016, at 10:41, Dave Thaler wrote: > > > > Just reaffirmining what I said at the mic. > > > > I support adopting this draft, while the pairing portion I would prefer > be in a separate > > draft in a different group (e.g. intarea with joint review by saag), > since the pairing part > > should not be specific to dnssd. > > > > Dave > > > >> -----Original Message----- > >> From: dnssd [mailto:dnssd-bounces@ietf.org] On Behalf Of Martin Thomso= n > >> Sent: Tuesday, July 26, 2016 1:29 AM > >> To: Tim Chown > >> Cc: dnssd@ietf.org; Terry Manderson > >> Subject: Re: [dnssd] Call for WG Adoption: > draft-huitema-dnssd-privacy-01 > >> > >> What is the status of the pairing piece of this work? None of this ca= n > work > >> without addressing that portion. The document contains some ideas, bu= t > >> these are quite nebulous and certainly not sufficient to deploy an > >> interoperable solution for this. > >> > >> (I'm generally supportive of this work, but I want to make sure that > everyone > >> understands the scope and magnitude of the work involved > >> here.) > >> > >>> On 25 July 2016 at 16:16, Tim Chown wrote: > >>> Hi, > >>> > >>> At the meeting in Berlin, there was a positive reaction to the > >>> "Privacy Extensions for DNS-SD=E2=80=9D draft, > >>> https://tools.ietf.org/html/draft-huitema-dnssd-privacy-01. > >>> > >>> While only a small number of people had read it in detail, those who > >>> had read it expressed a desire for the WG to adopt the draft. > >>> > >>> This email therefore begins a two-week formal dnssd mail list call fo= r > >>> adoption of the draft by the WG. Please send any comments, for or > >>> against, to the dnssd WG list. If you indicated support in the > >>> meeting, feel free to reaffirm this, and add any comments. > >>> > >>> The call ends on Monday 8th August. > >>> > >>> The document status in the data tracker can be found at > >>> https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/. > >>> > >>> Note that the WG in which the specifics of the pairing protocol will > >>> be developed will be reviewed by our AD. On the one had it is a > >>> generic mechanism that may be better defined in a security WG, on the > >>> other we should have a critical mass of people to get the work done > >>> here, if the draft is adopted. > >>> > >>> Tim > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> dnssd mailing list > >>> dnssd@ietf.org > >>> https://www.ietf.org/mailman/listinfo/dnssd > >> > >> _______________________________________________ > >> dnssd mailing list > >> dnssd@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnssd > > _______________________________________________ > > dnssd mailing list > > dnssd@ietf.org > > https://www.ietf.org/mailman/listinfo/dnssd > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd > --001a11400ee67d2d7c0538f37650 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I also support adoption of this work. I don't have a pro= blem with putting pairing in a separate document, but let's not get to = caught up in process. We need to do the work where there are people who wan= t to do the work.


On Jul 31, 2016 3= :18 PM, "Tim Wicinski" <= tjw.ietf@gmail.com> wrote:
I support adoption , and I'd like to second Dave's po= int on the pairing.

>From my high tech gadget

> On Jul 26, 2016, at 10:41, Dave Thaler <dthaler@microsoft.com> wrote:
>
> Just reaffirmining what I said at the mic.
>
> I support adopting this draft, while the pairing portion I would prefe= r be in a separate
> draft in a different group (e.g. intarea with joint review by saag), s= ince the pairing part
> should not be specific to dnssd.
>
> Dave
>
>> -----Original Message-----
>> From: dnssd [mailto:dnss= d-bounces@ietf.org] On Behalf Of Martin Thomson
>> Sent: Tuesday, July 26, 2016 1:29 AM
>> To: Tim Chown <Tim.Chow= n@jisc.ac.uk>
>> Cc: dnssd@ietf.org; Terry Ma= nderson <terry.manderson@ic= ann.org>
>> Subject: Re: [dnssd] Call for WG Adoption: draft-huitema-dnssd-pri= vacy-01
>>
>> What is the status of the pairing piece of this work?=C2=A0 None o= f this can work
>> without addressing that portion.=C2=A0 The document contains some = ideas, but
>> these are quite nebulous and certainly not sufficient to deploy an=
>> interoperable solution for this.
>>
>> (I'm generally supportive of this work, but I want to make sur= e that everyone
>> understands the scope and magnitude of the work involved
>> here.)
>>
>>> On 25 July 2016 at 16:16, Tim Chown <Tim.Chown@jisc.ac.uk> wrote:
>>> Hi,
>>>
>>> At the meeting in Berlin, there was a positive reaction to the=
>>> "Privacy Extensions for DNS-SD=E2=80=9D draft,
>>> https://tools.ietf.org/html/d= raft-huitema-dnssd-privacy-01.
>>>
>>> While only a small number of people had read it in detail, tho= se who
>>> had read it expressed a desire for the WG to adopt the draft.<= br> >>>
>>> This email therefore begins a two-week formal dnssd mail list = call for
>>> adoption of the draft by the WG. Please send any comments, for= or
>>> against, to the dnssd WG list. If you indicated support in the=
>>> meeting, feel free to reaffirm this, and add any comments.
>>>
>>> The call ends on Monday 8th August.
>>>
>>> The document status in the data tracker can be found at
>>> https://datatracker.ietf.o= rg/doc/draft-huitema-dnssd-privacy/.
>>>
>>> Note that the WG in which the specifics of the pairing protoco= l will
>>> be developed will be reviewed by our AD. On the one had it is = a
>>> generic mechanism that may be better defined in a security WG,= on the
>>> other we should have a critical mass of people to get the work= done
>>> here, if the draft is adopted.
>>>
>>> Tim
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> dnssd mailing list
>>> dnssd@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnssd<= /a>
>>
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd<= br> > _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd

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