Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5B221F9A70 for ; Fri, 28 Jun 2013 10:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6pK2gPFkLI4I for ; Fri, 28 Jun 2013 10:26:40 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1EC21F9A61 for ; Fri, 28 Jun 2013 10:26:37 -0700 (PDT) Received: by mail-ob0-f177.google.com with SMTP id ta17so2194644obb.8 for ; Fri, 28 Jun 2013 10:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=vnINIKasPMd9IEe130xWSJzGLA2AlIfjR3qDgtmxg54=; b=i4GXTcvlVZ3Amb4e11XL7tcp6NVH2Nqjuk9kULgwzpNNPoa0dvGG2PxHrYu5HHWg2e Ct1Z5t34Z+X2QZFwx7rgmxddl3rD6W0OF6uHEOkVRW4qehxtyJ+z4bRx9/Jw0jkOoe4V mLA4spUIfPPE0zvf1lmdNY8tbVHncWUqRs6rVHVx1CN8lQzGfqYsYdobjxljd/NtHszJ MO/3CeDiYDh3NcPBGPZXZzTRNVCTq3nWoTIyoZ+folyAkYcJoW4BcBc+Flup11ORRMUm YwmImjviwCtB+0mtzlZDjgelW0x1OVWgXyTT2TjgO5fDd+lgstFTArXHciz7ufKlBO7u 7iWg== MIME-Version: 1.0 X-Received: by 10.182.101.131 with SMTP id fg3mr6919284obb.11.1372440396001; Fri, 28 Jun 2013 10:26:36 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.94.239 with HTTP; Fri, 28 Jun 2013 10:26:35 -0700 (PDT) In-Reply-To: <20130628171005.20162.11209.idtracker@ietfa.amsl.com> References: <20130628171005.20162.11209.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2013 13:26:35 -0400 X-Google-Sender-Auth: t1KBPnguAHeLxmv3a7VDiuDPPcc Message-ID: From: Kerry Lynn To: mdnsext@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff2525047792c04e03a2e47 Subject: [mdnsext] Fwd: IPR Disclosure: Apple, Inc.'s Statement about IPR related to draft-lynn-mdnsext-requirements-01 X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 17:26:41 -0000 --e89a8ff2525047792c04e03a2e47 Content-Type: text/plain; charset=ISO-8859-1 Seems like the usual boilerplate... FYI, -K- ---------- Forwarded message ---------- From: IETF Secretariat Date: Fri, Jun 28, 2013 at 1:10 PM Subject: IPR Disclosure: Apple, Inc.'s Statement about IPR related to draft-lynn-mdnsext-requirements-01 To: kerlyn@ieee.org, cheshire@apple.com Cc: jari.arkko@piuha.net, ipr-announce@ietf.org Dear Kerry Lynn, Stuart Cheshire: An IPR disclosure that pertains to your Internet-Draft entitled "Requirements for DNS-SD/mDNS Extensions" (draft-lynn-mdnsext-requirements) was submitted to the IETF Secretariat on 2013-06-28 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2114/). The title of the IPR disclosure is "Apple, Inc.'s Statement about IPR related to draft-lynn-mdnsext- requirements-01.""); The IETF Secretariat --e89a8ff2525047792c04e03a2e47 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Seems like the usual boilerplate...

FYI, -K-

---------- Forwarded message ----------
From: IETF Secretariat <ietf-ipr@ietf.org>
Date: Fri, Jun 28, 2013 at 1:10 PM
Subject: IPR Disclosure: Apple, Inc.&= #39;s Statement about IPR related to draft-lynn-mdnsext-requirements-01
= To: kerlyn@ieee.org, cheshire@apple.com
Cc: jari.arkko@piuha.net, ipr-announce@ietf.org


Dear Kerry Lynn, Stuart Cheshire:

=A0An IPR disclosure that pertains to your Internet-Draft entitled "Re= quirements
for DNS-SD/mDNS Extensions" (draft-lynn-mdnsext-requirements) was subm= itted to
the IETF Secretariat on 2013-06-28 and has been posted on the "IETF Pa= ge of
Intellectual Property Rights Disclosures"
(https= ://datatracker.ietf.org/ipr/2114/). The title of the IPR disclosure is<= br> "Apple, Inc.'s Statement about IPR related to draft-lynn-mdnsext-<= br> requirements-01."");

The IETF Secretariat


--e89a8ff2525047792c04e03a2e47-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A6921F9C68 for ; Mon, 24 Jun 2013 04:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.849 X-Spam-Level: X-Spam-Status: No, score=-9.849 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PM1PlmnbcV94 for ; Mon, 24 Jun 2013 04:19:41 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by ietfa.amsl.com (Postfix) with ESMTP id AF8B221E80DC for ; Mon, 24 Jun 2013 04:19:40 -0700 (PDT) Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.13.6/8.13.6) with ESMTP id r5OBJbkA030769; Mon, 24 Jun 2013 13:19:37 +0200 Received: from DEFTHW99ET9MSX.ww902.siemens.net ([157.163.148.60]) by mail2.sbs.de (8.13.6/8.13.6) with ESMTP id r5OBJaw3014802 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 24 Jun 2013 13:19:37 +0200 Received: from DENBGAT9EREMSX.ww902.siemens.net (139.22.70.81) by DEFTHW99ET9MSX.ww902.siemens.net (157.163.148.60) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 24 Jun 2013 13:19:36 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.134]) by DENBGAT9EREMSX.ww902.siemens.net ([139.22.70.81]) with mapi id 14.02.0342.003; Mon, 24 Jun 2013 13:19:35 +0200 From: "Albrecht, Harald" To: Ralph Droms Thread-Topic: AW: [mdnsext] dnssdext BoF in Berlin Thread-Index: AQHObqgbcd3PBo5JF0KCSwfm6zRJgZlEcyGggAAnYQCAACEakA== Date: Mon, 24 Jun 2013 11:19:34 +0000 Message-ID: References: <20130620183604.563.97531.idtracker@ietfa.amsl.com> <352651CB-88BF-4877-82A2-280CBCDF8AE8@gmail.com> <259C1F60-7C85-47E8-B3F9-41129E7E8F87@gmail.com> In-Reply-To: <259C1F60-7C85-47E8-B3F9-41129E7E8F87@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.31] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] dnssdext BoF in Berlin X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 11:19:47 -0000 UmFscGgsDQoNCnRoYW5rIHlvdTsgSSBvbmx5IG5vdGljZWQgbGF0ZXIgdGhhdCB5b3UgYWxyZWFk eSBhZGRlZCB0aGUgaG9tZW5ldCBkZXBlbmRlbmN5LiBGcm9tIG15IGxpbWl0ZWQgcG9pbnQgb2Yg dmlldywgdGhlIGZpcnN0IHByaW9yaXR5IGRlcGVuZGVuY2llcyBsb29rIGZpbmUgLi4uIHRoZXJl IGFyZSBhbHJlYWR5IGVub3VnaCBkZXBlbmRlbmNpZXMgdG8gZW50YW5nbGUgb3Vyc2VsdmVzIGlu IGEgc3BpZGVyIHdlYi4uLg0KDQotLSBIYXJhbGQNCg0KPiAtLS0tLVVyc3Byw7xuZ2xpY2hlIE5h Y2hyaWNodC0tLS0tDQo+IFZvbjogUmFscGggRHJvbXMgW21haWx0bzpyZHJvbXMuaWV0ZkBnbWFp bC5jb21dDQo+IEdlc2VuZGV0OiBNb250YWcsIDI0LiBKdW5pIDIwMTMgMTM6MTkNCj4gQW46IEFs YnJlY2h0LCBIYXJhbGQNCj4gQ2M6IG1kbnNleHRAaWV0Zi5vcmcNCj4gQmV0cmVmZjogUmU6IEFX OiBbbWRuc2V4dF0gZG5zc2RleHQgQm9GIGluIEJlcmxpbg0KPiANCj4gSGFyYWxkLA0KPiANCj4g DQo+IA0KPiBPbiBKdW4gMjQsIDIwMTMsIGF0IDM6MDEgQU0sICJBbGJyZWNodCwgSGFyYWxkIg0K PiA8aGFyYWxkLmFsYnJlY2h0QHNpZW1lbnMuY29tPiB3cm90ZToNCj4gDQo+ID4gSSB3b3VsZCBs aWtlIHRvIHNlZSAiaG9tZW5ldCIgYWRkZWQgdG8gdGhlIGxpc3Qgb2YgImNvbmZsaWN0cyB0byBh dm9pZCIuDQo+IA0KPiBPay4gIEhlcmUncyB0aGUgbGF0ZXN0IGxpc3Qgb2YgY29uZmxpY3RzIChm cm9tDQo+IGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2JvZi90cmFjL3dpa2kvV2lraVN0YXJ0 KToNCj4gDQo+IEZpcnN0IHByaW9yaXR5OiBkbnNvcCwgdjZvcHMsIGFwcHNhd2csIGhvbWVuZXQs IDZtYW4sIGRoYywgNmxvLCBtYm9uZWQsDQo+IGNvcmUgU2Vjb25kIHByaW9yaXR5OiBJTlQgYXJl YSBXR3MNCj4gDQo+IE90aGVyIHN1Z2dlc3Rpb25zPw0KPiANCj4gLSBSYWxwaA0KPiANCj4gPiBO b3cgdGhhdCBzdHJ1Y3R1cmVkIGhvbWUgbmV0d29ya3Mgc3RhcnQgdG8gcG9wIHVwIGhlcmUgYW5k IHRoZXJlIHRoaXMNCj4gbG9va3Mgc3VzcGljaW91c2x5IHNpbWlsYXIgdG8gd2hhdCBzb21lIHBl b3BsZSBkbyBpbiB0aGUgYXV0b21hdGlvbg0KPiBpbmR1c3RyaWVzIG9uIHRoZSBwbGFudCBmbG9v ciBsZXZlbC4gVGhhdCBpcywgaGllcmFyY2hpY2FsbHkgc2VnbWVudGVkIHBsYW50DQo+IG5ldHdv cmtzLCB3aGVyZSBzZWdtZW50YXRpb24gaGFwcGVucyBhdCB0aGUgY2VsbCBhbmQgZXZlbiBhdCBv ciBpbiB0aGUNCj4gbWFjaGluZSBsZXZlbC4NCj4gPg0KPiA+IC0tIEhhcmFsZA0KPiA+DQo+ID4+ IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gPj4gVm9uOiBtZG5zZXh0LWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzptZG5zZXh0LWJvdW5jZXNAaWV0Zi5vcmddIEltDQo+ID4+ IEF1ZnRyYWcgdm9uIFJhbHBoIERyb21zDQo+ID4+IEdlc2VuZGV0OiBGcmVpdGFnLCAyMS4gSnVu aSAyMDEzIDE5OjUyDQo+ID4+IEFuOiBtZG5zZXh0QGlldGYub3JnDQo+ID4+IEJldHJlZmY6IFtt ZG5zZXh0XSBkbnNzZGV4dCBCb0YgaW4gQmVybGluDQo+ID4+DQo+ID4+IFRoZSByZXF1ZXN0IGZv ciBhIGRuc3NkZXh0IEJvRiBpbiBCZXJsaW4gaGFzIGJlZW4gYXBwcm92ZWQgYnkgdGhlDQo+ID4+ IElFU0cuICBUaGUgQm9GIGxvZ2lzdGljcyBhcmUgaW5jbHVkZWQgYmVsb3cuICBOb3RlIHRoZSBu YW1lIG9mIHRoZQ0KPiA+PiBCb0YgaXMgZG5zc2RleHQsIG5vdCBzZG5zc2QuICBUaGUgQm9GIHdp bGwgYmUgc2NoZWR1bGVkIGluIHRoZQ0KPiA+PiBJRVRGLTg3IGFnZW5kYSBhbG9uZyB3aXRoIG90 aGVyIEJvRnMgYW5kIFdHIG1lZXRpbmdzLCBzbyB3ZSdsbCBrbm93DQo+ID4+IHRoZSBkYXRlIGFu ZCB0aW1lIG9mIHRoZSBtZWV0aW5nIGFzIHNvb24gYXMgdGhlIGFnZW5kYSBpcyBjb21wbGV0ZWQu DQo+ID4+DQo+ID4+IFBsZWFzZSByZXZpZXcgdGhlIGluZm9ybWF0aW9uIGJlbG93IGFuZCByZXBs eSB3aXRoIHF1ZXN0aW9ucyBvcg0KPiA+PiBzdWdnZXN0ZWQgdXBkYXRlcy4gIEluIHBhcnRpY3Vs YXIsIGFyZSB0aGVyZSBhbnkgb3RoZXIgV0cvQm9GDQo+ID4+IHNlc3Npb25zIHRoYXQgc2hvdWxk IGJlIGJlIGxpc3RlZCBhcyAiQ29uZmxpY3RzIHRvIEF2b2lkIj8gIEkndmUNCj4gPj4gYWxyZWFk eSBzZW50IGluIGEgcmVxdWVzdCB0byBkcm9wICJpbnRhcmVhIiBmcm9tIHRoZSBleHBsaWNpdCBs aXN0DQo+ID4+IGFuZCBhZGQgYSBzcGVjaWFsIHJlcXVlc3QgdG8gYXZvaWQgY29uZmxpY3RzIHdp dGggYWxsIElOVCBhcmVhIFdHIHNlc3Npb25zLg0KPiA+Pg0KPiA+PiAtIFJhbHBoDQo+ID4+DQo+ ID4+IEJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KPiA+Pg0KPiA+Pj4gRnJvbTogIlwiSUVURiBN ZWV0aW5nIFNlc3Npb24gUmVxdWVzdCBUb29sXCIiDQo+ID4+IDxzZXNzaW9uX3JlcXVlc3RfZGV2 ZWxvcGVyc0BpZXRmLm9yZz4NCj4gPj4+IFN1YmplY3Q6IGRuc3NkZXh0IC0gTmV3IE1lZXRpbmcg U2Vzc2lvbiBSZXF1ZXN0IGZvciBJRVRGIDg3DQo+ID4+PiBEYXRlOiBKdW5lIDIwLCAyMDEzIDI6 MzY6MDQgUE0gRURUDQo+ID4+PiBUbzogc2Vzc2lvbi1yZXF1ZXN0QGlldGYub3JnDQo+ID4+PiBD YzogZG5zc2RleHQtYWRzQHRvb2xzLmlldGYub3JnLCByZHJvbXMuaWV0ZkBnbWFpbC5jb20sDQo+ ID4+IHRqY0BlY3Muc290b24uYWMudWssIGNtb3JnYW5AYW1zbC5jb20NCj4gPj4+DQo+ID4+Pg0K PiA+Pj4NCj4gPj4+IEEgbmV3IG1lZXRpbmcgc2Vzc2lvbiByZXF1ZXN0IGhhcyBqdXN0IGJlZW4g c3VibWl0dGVkIGJ5IENpbmR5DQo+ID4+PiBNb3JnYW4sDQo+ID4+IG9uIGJlaGFsZiBvZiB0aGUg ZG5zc2RleHQgd29ya2luZyBncm91cC4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+PiBXb3Jr aW5nIEdyb3VwIE5hbWU6IEROUy1TRCBFeHRlbnNpb25zIEFyZWEgTmFtZTogSW50ZXJuZXQgQXJl YQ0KPiA+Pj4gU2Vzc2lvbiBSZXF1ZXN0ZXI6IENpbmR5IE1vcmdhbg0KPiA+Pj4NCj4gPj4+IE51 bWJlciBvZiBTZXNzaW9uczogMQ0KPiA+Pj4gTGVuZ3RoIG9mIFNlc3Npb24ocyk6ICAyIEhvdXJz DQo+ID4+PiBOdW1iZXIgb2YgQXR0ZW5kZWVzOiAxNTANCj4gPj4+IENvbmZsaWN0cyB0byBBdm9p ZDoNCj4gPj4+IEZpcnN0IFByaW9yaXR5OiBpbnRhcmVhLCBkbnNvcCwgdjZvcHMsIGFwcHNhd2cN Cj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBTcGVjaWFsIFJlcXVlc3RzOg0KPiA+ Pj4NCj4gPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPiA+Pj4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPj4gbWRuc2V4dCBtYWlsaW5nIGxpc3QNCj4gPj4gbWRu c2V4dEBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21kbnNleHQNCg== Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A989E21F9C9E for ; Mon, 24 Jun 2013 04:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.302 X-Spam-Level: X-Spam-Status: No, score=-101.302 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pf-afLnnHw0D for ; Mon, 24 Jun 2013 04:16:52 -0700 (PDT) Received: from mail-vb0-x22f.google.com (mail-vb0-x22f.google.com [IPv6:2607:f8b0:400c:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id DE8DD21F8ECB for ; Mon, 24 Jun 2013 04:16:51 -0700 (PDT) Received: by mail-vb0-f47.google.com with SMTP id x14so8038709vbb.34 for ; Mon, 24 Jun 2013 04:16:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=4Pj0kEigz35QVZkjiTA9fuWDJ4aQYigngJroPkJcrIM=; b=hrvscmncg6d4PHJ1Y29BwBpKlM0E/ym7qnLYV5x/3NziT+qzDceFHx6aHgKgJdQlTV 3bJ6bo6gf9M8SeqQxnR2yR9SeUt18gaKJN4xWghHShmJlo4OZvS51SbUGcRyzHoLJ6TQ gTJcOmUfZIKLjFi5i/Zu9+s5h/2+/i1h7t0FFV3+jHFU/Jp2Yx+wEP7GPd7HhuE/0+Tx Much2dFa0ikGH0tmyJHeYKPQjpG5JB85rjZ+65rC8oyQHjtjPHHe8hies3TDVT4t9Dw2 0Hq6jjWmA8kfDJZK1GsjmbIeo5ucgURyoE1vyvGaqQFq4OnhTw3/wjriMBLRQV+Sg8Gl RrCg== X-Received: by 10.58.19.162 with SMTP id g2mr11295782vee.12.1372072610305; Mon, 24 Jun 2013 04:16:50 -0700 (PDT) Received: from [192.168.1.132] (c-24-62-231-127.hsd1.ma.comcast.net. [24.62.231.127]) by mx.google.com with ESMTPSA id sr7sm18254715vdc.2.2013.06.24.04.16.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Jun 2013 04:16:49 -0700 (PDT) References: <20130620183604.563.97531.idtracker@ietfa.amsl.com> <352651CB-88BF-4877-82A2-280CBCDF8AE8@gmail.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <259C1F60-7C85-47E8-B3F9-41129E7E8F87@gmail.com> X-Mailer: iPad Mail (9B206) From: Ralph Droms Date: Mon, 24 Jun 2013 07:19:22 -0400 To: "Albrecht, Harald" Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] dnssdext BoF in Berlin X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 11:16:52 -0000 Harald, On Jun 24, 2013, at 3:01 AM, "Albrecht, Harald" wrote: > I would like to see "homenet" added to the list of "conflicts to avoid". Ok. Here's the latest list of conflicts (from http://trac.tools.ietf.org/bo= f/trac/wiki/WikiStart): First priority: dnsop, v6ops, appsawg, homenet, 6man, dhc, 6lo, mboned, core= Second priority: INT area WGs Other suggestions? - Ralph > Now that structured home networks start to pop up here and there this look= s suspiciously similar to what some people do in the automation industries o= n the plant floor level. That is, hierarchically segmented plant networks, w= here segmentation happens at the cell and even at or in the machine level. >=20 > -- Harald >=20 >> -----Urspr=C3=BCngliche Nachricht----- >> Von: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] Im >> Auftrag von Ralph Droms >> Gesendet: Freitag, 21. Juni 2013 19:52 >> An: mdnsext@ietf.org >> Betreff: [mdnsext] dnssdext BoF in Berlin >>=20 >> The request for a dnssdext BoF in Berlin has been approved by the IESG. T= he >> BoF logistics are included below. Note the name of the BoF is dnssdext, n= ot >> sdnssd. The BoF will be scheduled in the IETF-87 agenda along with other= >> BoFs and WG meetings, so we'll know the date and time of the meeting as >> soon as the agenda is completed. >>=20 >> Please review the information below and reply with questions or suggested= >> updates. In particular, are there any other WG/BoF sessions that should b= e >> be listed as "Conflicts to Avoid"? I've already sent in a request to dro= p >> "intarea" from the explicit list and add a special request to avoid confl= icts with >> all INT area WG sessions. >>=20 >> - Ralph >>=20 >> Begin forwarded message: >>=20 >>> From: "\"IETF Meeting Session Request Tool\"" >> >>> Subject: dnssdext - New Meeting Session Request for IETF 87 >>> Date: June 20, 2013 2:36:04 PM EDT >>> To: session-request@ietf.org >>> Cc: dnssdext-ads@tools.ietf.org, rdroms.ietf@gmail.com, >> tjc@ecs.soton.ac.uk, cmorgan@amsl.com >>>=20 >>>=20 >>>=20 >>> A new meeting session request has just been submitted by Cindy Morgan, >> on behalf of the dnssdext working group. >>>=20 >>>=20 >>> --------------------------------------------------------- >>> Working Group Name: DNS-SD Extensions >>> Area Name: Internet Area >>> Session Requester: Cindy Morgan >>>=20 >>> Number of Sessions: 1 >>> Length of Session(s): 2 Hours >>> Number of Attendees: 150 >>> Conflicts to Avoid: >>> First Priority: intarea, dnsop, v6ops, appsawg >>>=20 >>>=20 >>>=20 >>>=20 >>> Special Requests: >>>=20 >>> --------------------------------------------------------- >>>=20 >>=20 >> _______________________________________________ >> mdnsext mailing list >> mdnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EEF21E808A for ; Mon, 24 Jun 2013 00:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.948 X-Spam-Level: X-Spam-Status: No, score=-9.948 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fpM83KlmASYl for ; Mon, 24 Jun 2013 00:01:14 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by ietfa.amsl.com (Postfix) with ESMTP id F3E0B11E80DC for ; Mon, 24 Jun 2013 00:01:13 -0700 (PDT) Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.13.6/8.13.6) with ESMTP id r5O71AUK012137; Mon, 24 Jun 2013 09:01:11 +0200 Received: from defthw99et6msx.ww902.siemens.net ([157.163.148.61]) by mail2.sbs.de (8.13.6/8.13.6) with ESMTP id r5O71Alc016968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Jun 2013 09:01:10 +0200 Received: from DENBGAT9ERFMSX.ww902.siemens.net (139.22.70.83) by DEFTHW99ET6MSX.ww902.siemens.net (157.163.148.61) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 24 Jun 2013 09:01:10 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.134]) by DENBGAT9ERFMSX.ww902.siemens.net ([139.22.70.83]) with mapi id 14.02.0342.003; Mon, 24 Jun 2013 09:01:10 +0200 From: "Albrecht, Harald" To: Ralph Droms , "mdnsext@ietf.org" Thread-Topic: [mdnsext] dnssdext BoF in Berlin Thread-Index: AQHObqgbcd3PBo5JF0KCSwfm6zRJgZlEcyGg Date: Mon, 24 Jun 2013 07:01:09 +0000 Message-ID: References: <20130620183604.563.97531.idtracker@ietfa.amsl.com> <352651CB-88BF-4877-82A2-280CBCDF8AE8@gmail.com> In-Reply-To: <352651CB-88BF-4877-82A2-280CBCDF8AE8@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.31] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mdnsext] dnssdext BoF in Berlin X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 07:01:20 -0000 I would like to see "homenet" added to the list of "conflicts to avoid". No= w that structured home networks start to pop up here and there this looks s= uspiciously similar to what some people do in the automation industries on = the plant floor level. That is, hierarchically segmented plant networks, wh= ere segmentation happens at the cell and even at or in the machine level. -- Harald > -----Urspr=FCngliche Nachricht----- > Von: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] Im > Auftrag von Ralph Droms > Gesendet: Freitag, 21. Juni 2013 19:52 > An: mdnsext@ietf.org > Betreff: [mdnsext] dnssdext BoF in Berlin >=20 > The request for a dnssdext BoF in Berlin has been approved by the IESG. = The > BoF logistics are included below. Note the name of the BoF is dnssdext, = not > sdnssd. The BoF will be scheduled in the IETF-87 agenda along with other > BoFs and WG meetings, so we'll know the date and time of the meeting as > soon as the agenda is completed. >=20 > Please review the information below and reply with questions or suggested > updates. In particular, are there any other WG/BoF sessions that should = be > be listed as "Conflicts to Avoid"? I've already sent in a request to dro= p > "intarea" from the explicit list and add a special request to avoid confl= icts with > all INT area WG sessions. >=20 > - Ralph >=20 > Begin forwarded message: >=20 > > From: "\"IETF Meeting Session Request Tool\"" > > > Subject: dnssdext - New Meeting Session Request for IETF 87 > > Date: June 20, 2013 2:36:04 PM EDT > > To: session-request@ietf.org > > Cc: dnssdext-ads@tools.ietf.org, rdroms.ietf@gmail.com, > tjc@ecs.soton.ac.uk, cmorgan@amsl.com > > > > > > > > A new meeting session request has just been submitted by Cindy Morgan, > on behalf of the dnssdext working group. > > > > > > --------------------------------------------------------- > > Working Group Name: DNS-SD Extensions > > Area Name: Internet Area > > Session Requester: Cindy Morgan > > > > Number of Sessions: 1 > > Length of Session(s): 2 Hours > > Number of Attendees: 150 > > Conflicts to Avoid: > > First Priority: intarea, dnsop, v6ops, appsawg > > > > > > > > > > Special Requests: > > > > --------------------------------------------------------- > > >=20 > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C5521F8F6E for ; Sun, 23 Jun 2013 04:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.535 X-Spam-Level: X-Spam-Status: No, score=-101.535 tagged_above=-999 required=5 tests=[AWL=-0.932, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-Mz4oiireP2 for ; Sun, 23 Jun 2013 04:01:40 -0700 (PDT) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 3246B21F8E98 for ; Sun, 23 Jun 2013 04:01:40 -0700 (PDT) Received: by mail-ve0-f172.google.com with SMTP id jz10so7876417veb.17 for ; Sun, 23 Jun 2013 04:01:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=BBlUrv8iTGwPgVblP7eUVoOtopSBNQT7/2WzJVMH/ek=; b=pBGdxdFI/t6LvJ+uEwLl1WRe4pCYUjIOM0eEsIosgOE+Y5jLAv5PlSoB5IRMMTd1jh 8KtpqRoTqQCmR5lGOasZE0zDF9Kq+0zburLMxUsJf2tn6cA3L6UfgAwv31m5XJKq9bXB 1MTxjk+ZWlPYVdT8punLGPSgaV7b1xMAWe4sfr/E8jl3SRmg9KEZokq0auZ1PqYcEar8 DmohgxsJMElO8hLxvqASvapeG1azqCVZKTMMwtecgiXuIP7v2Zt68IMeyfhe5MK6qPnv woZB5ENPX7r5g5d7FGkFWbbpf0OT2b7Voxc+Hw7U0mnZ5fX6iZ0QuX9RDadqQiwC5xYY tT8A== X-Received: by 10.58.255.229 with SMTP id at5mr9266356ved.44.1371985299605; Sun, 23 Jun 2013 04:01:39 -0700 (PDT) Received: from [192.168.1.128] (c-24-62-231-127.hsd1.ma.comcast.net. [24.62.231.127]) by mx.google.com with ESMTPSA id zy9sm13793169veb.7.2013.06.23.04.01.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 23 Jun 2013 04:01:38 -0700 (PDT) References: <20130620183604.563.97531.idtracker@ietfa.amsl.com> <352651CB-88BF-4877-82A2-280CBCDF8AE8@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B350) From: Ralph Droms Date: Sun, 23 Jun 2013 07:01:37 -0400 To: "Townsley.net" Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] dnssdext BoF in Berlin X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Jun 2013 11:01:41 -0000 I assumed that the BoF would be scheduled to avoid all INT area WG sessions.= However, it might be better to list specific groups as first priority and I= NT area as a second priority. First priority: dnsop, v6ops, appsawg, homenet, 6man, dhc, 6lo, mboned, core= Second priority: INT area WGs Any suggestions about other first priority conflicts to avoid? - Ralph On Jun 22, 2013, at 3:09 AM, "Townsley.net" wrote: >=20 > Please add homenet to the list of WGs to avoid.=20 >=20 > - Mark >=20 > (Thumbtyped) >=20 > On 21 juin 2013, at 19:52, Ralph Droms wrote: >=20 >> The request for a dnssdext BoF in Berlin has been approved by the IESG. T= he BoF logistics are included below. Note the name of the BoF is dnssdext, n= ot sdnssd. The BoF will be scheduled in the IETF-87 agenda along with other= BoFs and WG meetings, so we'll know the date and time of the meeting as soo= n as the agenda is completed. >>=20 >> Please review the information below and reply with questions or suggested= updates. In particular, are there any other WG/BoF sessions that should be= be listed as "Conflicts to Avoid"? I've already sent in a request to drop "= intarea" from the explicit list and add a special request to avoid conflicts= with all INT area WG sessions. >>=20 >> - Ralph >>=20 >> Begin forwarded message: >>=20 >>> From: "\"IETF Meeting Session Request Tool\"" >>> Subject: dnssdext - New Meeting Session Request for IETF 87 >>> Date: June 20, 2013 2:36:04 PM EDT >>> To: session-request@ietf.org >>> Cc: dnssdext-ads@tools.ietf.org, rdroms.ietf@gmail.com, tjc@ecs.soton.ac= .uk, cmorgan@amsl.com >>>=20 >>>=20 >>>=20 >>> A new meeting session request has just been submitted by Cindy Morgan, o= n behalf of the dnssdext working group. >>>=20 >>>=20 >>> --------------------------------------------------------- >>> Working Group Name: DNS-SD Extensions >>> Area Name: Internet Area >>> Session Requester: Cindy Morgan >>>=20 >>> Number of Sessions: 1 >>> Length of Session(s): 2 Hours >>> Number of Attendees: 150 >>> Conflicts to Avoid:=20 >>> First Priority: intarea, dnsop, v6ops, appsawg=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Special Requests: >>>=20 >>> --------------------------------------------------------- >>=20 >> _______________________________________________ >> mdnsext mailing list >> mdnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C537B21F9DB2 for ; Sat, 22 Jun 2013 00:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=-0.988, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8eN6DIRELwi for ; Sat, 22 Jun 2013 00:09:19 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id F065821F9D9D for ; Sat, 22 Jun 2013 00:09:18 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so6869974wes.40 for ; Sat, 22 Jun 2013 00:09:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=Rk+a10E84GAR8mVJ8eWZLxOKJwm+mSGQGxVan8aN98c=; b=YP0SLoM1J18ivTm2EOP5Gm3bvM80MlHoZG32pPlc4UvnETtPbfv7xaOHh1j2ddX1Q1 4lQ2IZj5jFIgXToMxMQJAp7LrXSwdpqMS8+Gucbalwb+dOVXoBFafQKUafF+c76LINUk RYYO2JSDKbEyFXJRmR9bmV/tZNYUGhump2SkjwIWSBuNcunsJ4krZXZ9gBHnbvxJUQ3K zZJfE0RXgn3i5cuSo8NfFHB472VXn0PIGPDr4FY6DxhqDlxgf5mUQPiNsZnWTGHzBmNU v6GGFKE08mX7jyt2Je6F3z14SKew2TgIGvvT3AP5MgySCXJ3H+3kd+XYPmFc4PNsaOew AgHw== X-Received: by 10.194.104.74 with SMTP id gc10mr11290042wjb.48.1371884957780; Sat, 22 Jun 2013 00:09:17 -0700 (PDT) Received: from [10.55.23.164] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPSA id xn20sm2079329wib.5.2013.06.22.00.09.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 22 Jun 2013 00:09:17 -0700 (PDT) References: <20130620183604.563.97531.idtracker@ietfa.amsl.com> <352651CB-88BF-4877-82A2-280CBCDF8AE8@gmail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <352651CB-88BF-4877-82A2-280CBCDF8AE8@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: "Townsley.net" Date: Sat, 22 Jun 2013 09:09:17 +0200 To: Ralph Droms X-Gm-Message-State: ALoCoQlUXGWOdlS78Wmi4noa2pmsfI6yC9FhzYMpBXIyupi54NHSfD/Wo4o5q6604ivHdsz3G/Qh Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] dnssdext BoF in Berlin X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 07:09:19 -0000 Please add homenet to the list of WGs to avoid.=20 - Mark (Thumbtyped) On 21 juin 2013, at 19:52, Ralph Droms wrote: > The request for a dnssdext BoF in Berlin has been approved by the IESG. T= he BoF logistics are included below. Note the name of the BoF is dnssdext, n= ot sdnssd. The BoF will be scheduled in the IETF-87 agenda along with other= BoFs and WG meetings, so we'll know the date and time of the meeting as soo= n as the agenda is completed. >=20 > Please review the information below and reply with questions or suggested u= pdates. In particular, are there any other WG/BoF sessions that should be b= e listed as "Conflicts to Avoid"? I've already sent in a request to drop "i= ntarea" from the explicit list and add a special request to avoid conflicts w= ith all INT area WG sessions. >=20 > - Ralph >=20 > Begin forwarded message: >=20 >> From: "\"IETF Meeting Session Request Tool\"" >> Subject: dnssdext - New Meeting Session Request for IETF 87 >> Date: June 20, 2013 2:36:04 PM EDT >> To: session-request@ietf.org >> Cc: dnssdext-ads@tools.ietf.org, rdroms.ietf@gmail.com, tjc@ecs.soton.ac.= uk, cmorgan@amsl.com >>=20 >>=20 >>=20 >> A new meeting session request has just been submitted by Cindy Morgan, on= behalf of the dnssdext working group. >>=20 >>=20 >> --------------------------------------------------------- >> Working Group Name: DNS-SD Extensions >> Area Name: Internet Area >> Session Requester: Cindy Morgan >>=20 >> Number of Sessions: 1 >> Length of Session(s): 2 Hours >> Number of Attendees: 150 >> Conflicts to Avoid:=20 >> First Priority: intarea, dnsop, v6ops, appsawg=20 >>=20 >>=20 >>=20 >>=20 >> Special Requests: >>=20 >> --------------------------------------------------------- >=20 > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2693821E80AE for ; Fri, 21 Jun 2013 20:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.82 X-Spam-Level: X-Spam-Status: No, score=-8.82 tagged_above=-999 required=5 tests=[AWL=1.778, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4pxdHH2oWec for ; Fri, 21 Jun 2013 20:48:55 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5B0EB21E804D for ; Fri, 21 Jun 2013 20:48:54 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_hI7gNtzrbqdlNWJT2CPeag)" Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MOR00LZGZXF22K0@mail-out.apple.com> for mdnsext@ietf.org; Fri, 21 Jun 2013 20:48:53 -0700 (PDT) X-AuditID: 11807153-b7f3c6d000007b32-ea-51c51ea4cf1a Received: from [17.153.17.120] (Unknown_Domain [17.153.17.120]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id B5.7B.31538.5AE15C15; Fri, 21 Jun 2013 20:48:53 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Fri, 21 Jun 2013 23:48:59 -0400 Message-id: References: <4A8CEE77-B266-45E7-9D46-1ABB07C82CF0@apple.com> To: Garret Peirce X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsUiOFOwQnep3NFAg67dBhYnl5xisjjyLdZi 14EJjA7MHltP/mDzWLLkJ5PH6V+tzAHMUVw2Kak5mWWpRfp2CVwZfw6oFDSqVXQeX8vWwPhc oYuRk0NCwETiYesDZghbTOLCvfVsXYxcHEICvUwSLRumsoAkhAVUJPbN3cAOYvMK6Eks/TeH EcRmFkiQuNI7C6yZTUBN4vekPlYQm1MgUGLhxmdgcRYBVYnGI5NZIOqVJVZMu8HUxcgBNMdG 4uqyEohde5gkJm5awAgSFwHateNgIYgpISArsfN30gRGvllIFs9CshjC1pZYtvA1lK0n8bLp HTumuK7ExXWTGBcwsq1iFChKzUmsNNZLLCjISdVLzs/dxAgK2IbC4B2Mf5ZZHWIU4GBU4uE9 kHokUIg1say4MvcQowQHs5IIL3sQUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjvhlcHA4UE0hNL UrNTUwtSi2CyTBycUg2MwjO5OTr778zbMuOp81ITL1/X52/sZ3IZLKpOuC2mJ9JZUM0b7Mwn v2iqWnuF+J2C3FtJx6U1nJdbZ735qviSTyv+w12nLSUcIScd3N+3WC84fyabl/X0cgbFb5PE VmhxnlOIrnbq366n/fB49fLWNPOQ8mxty/VC/dfkT4bevc841SVZkU+JpTgj0VCLuag4EQD3 G5WEVAIAAA== Cc: IETF mdnsext Subject: Re: [mdnsext] mdnsext & SLP X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 03:49:02 -0000 --Boundary_(ID_hI7gNtzrbqdlNWJT2CPeag) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Garret, On 2013-06-21, at 11:27 PM, Garret Peirce wrote: > ... > It seems SLP is caches collected service advertisements whereas the mdsnext method demand polls for them. SLP with a DA caches, otherwise you have a similar amount of network traffic as for mDNS+DNS-SD. > At the expense of somewhat less realtime data, caching advertised services would seem easier and more manageable than having proxies present on each subnet to manage the polling. I'd not desire to operate the hybridProxy service on the subnet's router as a potential option it mentions; it'd seem unduly intensive for a router to assume that role (managing and caching queries, suppressing/rewriting others) - some other host would be required to assume this role on each subnet. I don't know about that; based on discussions on the ipv6 list, even consumer routers have sufficient capacity to do some pretty advanced routing and other functions, so I don't think acting as a proxy or caching service is out of the question, particularly if the cache is not persistent or of "infinite" depth. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_hI7gNtzrbqdlNWJT2CPeag) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable peirce@maine.edu> = wrote:
...
It seems SLP is caches collected service = advertisements whereas the mdsnext method demand polls for them. =  

SLP with a DA caches, otherwise = you have a similar amount of network traffic as for = mDNS+DNS-SD.

At the expense of somewhat less realtime data, caching = advertised services would seem easier and more manageable than having = proxies present on each subnet to manage the polling.  I'd not = desire to operate the hybridProxy service on the subnet's router as a = potential option it mentions; it'd seem unduly intensive for a router to = assume that role (managing and caching queries, suppressing/rewriting = others) - some other host would be required to assume this role on each = subnet.

I don't know about = that; based on discussions on the ipv6 list, even consumer routers have = sufficient capacity to do some pretty advanced routing and other = functions, so I don't think acting as a proxy or caching service is out = of the question, particularly if the cache is not persistent or of = "infinite" depth.

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_hI7gNtzrbqdlNWJT2CPeag)-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459C311E80F5 for ; Fri, 21 Jun 2013 20:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1NKCPKGLPwr for ; Fri, 21 Jun 2013 20:27:38 -0700 (PDT) Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [IPv6:2607:f8b0:400c:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6F39721F9951 for ; Fri, 21 Jun 2013 20:27:37 -0700 (PDT) Received: by mail-vb0-f42.google.com with SMTP id i3so6568428vbh.15 for ; Fri, 21 Jun 2013 20:27:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=PcOo11ewi/Fn2DWU98WMf5zvrUJD0GeOCI/w4IwugbY=; b=CTG7g+TsQd2slbIWQz9xRAbESELh5+u4FhbQIxCYqCbu5m4+XNtyS+zLZGb1vE69ec qb9oDHGpGh2fgoMibRtfFedYYu7hNkwMw9udIxU14Q9i2rfDdNEXSHCwVWld/haYEu3z osjz5wWNSeoM4dE00kDrW0rcoJBTdoT5KhxSRLIA2osVfR7skorJflfWB1XdzkHLwGwf h9iB71lqBYl/cUbLZTUl4VZJzBF9efJo0XiBNfmfoQla2sRExSkv+DnvaggryYOp4vpt /0m/IPytINQusFgAfwxj1ghcdAj0Qa0/dPIhU3D3/A+C3IpR7Yy/F2jaXNfQvujOVouB WKug== MIME-Version: 1.0 X-Received: by 10.52.103.99 with SMTP id fv3mr6062607vdb.11.1371871657146; Fri, 21 Jun 2013 20:27:37 -0700 (PDT) Received: by 10.220.50.131 with HTTP; Fri, 21 Jun 2013 20:27:37 -0700 (PDT) In-Reply-To: <4A8CEE77-B266-45E7-9D46-1ABB07C82CF0@apple.com> References: <4A8CEE77-B266-45E7-9D46-1ABB07C82CF0@apple.com> Date: Fri, 21 Jun 2013 23:27:37 -0400 Message-ID: From: Garret Peirce To: Michael Sweet Content-Type: multipart/alternative; boundary=047d7bacb840cd495104dfb5c2db X-Gm-Message-State: ALoCoQkeezoIO4EUkD7bCPs5cD+Iu9QaITM0WJjiB00Il+/bdS20Kjpn7JAaKkzM66UfSSQxdOBq Cc: IETF mdnsext Subject: Re: [mdnsext] mdnsext & SLP X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 03:27:39 -0000 --047d7bacb840cd495104dfb5c2db Content-Type: text/plain; charset=ISO-8859-1 > And you still have the issue of resolving hostnames and/or routing addresses for the services > for example, a printer might advertise its printer service with any of the following: >service:printer:ipp://192.168.0.100/ipp/print >service:printer:ipp://10.0.1.100/ipp/print >service:printer:ipp://[fe80::0100]/ipp/print >service:printer:ipp://hostname.local./ipp/print >service:printer:ipp://17.1.2.100/ipp/print >service:printer:ipp://hostname.apple.com/ipp/print >The only ones that are likely to be directly usable are the last two.. I see your point about the variety of advertised service types, but I might look at that as built-in filtering. In my environment, I'd say if a device doesn't have an FQDN or a globalAddr, I'd not want the service known (outside the subnet). If the other types were desired, I'd think namespace collisions would have to be dealt with. It seems SLP is caches collected service advertisements whereas the mdsnext method demand polls for them. At the expense of somewhat less realtime data, caching advertised services would seem easier and more manageable than having proxies present on each subnet to manage the polling. I'd not desire to operate the hybridProxy service on the subnet's router as a potential option it mentions; it'd seem unduly intensive for a router to assume that role (managing and caching queries, suppressing/rewriting others) - some other host would be required to assume this role on each subnet. If I read it correctly, each client query results in an mcast poll by the subdelegated proxy. This could setup the overall system to be chattier than desired. If 5 clients are looking for the a service on the same remote link, the target subnet will be subject to 5 different mDNS requests by the proxy. With that, and I believe sharing David's thought, what about a model where clients use DNS-SD, but instead of DNS using the hybridProxy model, the SLP DA model of learning services is used. ex. Using a snooping 'helper' to unicast forward link-local (ACLd) mDNS service advertisements (~UAs) to populate centralized DA(s). If snooping is done at L2, perhaps other data could be inserted (location info) in the advertisement ('local', becomes 'Building1') here. DAs accept/deny advertisements via policy. DAs meshed and may share data via policy (~mSLP). DHCP option(s) could supply a host with a specific DA to use and/or a DNS-SD browse domain if desired. Similar to the draft, a client DNS-SD request would be sent to it's DNS server which ,if necessary, would be delegated to the appropriate DAs which would then service the dynamic service request and respond to the client. -- Garry Peirce Networkmaine, University of Maine SystemSystem --047d7bacb840cd495104dfb5c2db Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> And you still have the issue of resolv= ing hostnames and/or routing addresses for the services
> for example, a printer might advertise its printer service with any of= the following:
=A0 =A0 >service:printer:ipp://192.168.0.100/ipp/print
=A0 =A0 >service:printer:ipp://10.0.1.100/ipp/print
=A0 =A0 >service:printer:ipp://[fe80::0100]/ipp/print
=A0 =A0 >service:printer:ipp://hostname.local./ipp/print
=A0 =A0 >service:printer:ipp://17.1.2.100/ipp/print
=A0 =A0 >service:printer:ipp://hostname.apple.com/ipp/print
>The only ones that are likely to be directly usable are the last two..<= /p>

I see your point about the variety of advertised service typ= es, but I might look at that as built-in filtering. =A0In my environment, I= 'd say if a device doesn't have an FQDN or a globalAddr, I'd no= t want the service known (outside the subnet). =A0If the other types were d= esired, I'd think namespace collisions would have to be dealt with.

It seems SLP is caches collected service advertisements whereas the mdsnext= method demand polls for them. =A0
At the expense of somewhat less real= time data, caching advertised services would seem easier and more manageabl= e than having proxies present on each subnet to manage the polling. =A0I= 9;d not desire to operate the hybridProxy service on the subnet's route= r as a potential option it mentions; it'd seem unduly intensive for a r= outer to assume that role (managing and caching queries, suppressing/rewrit= ing others) - some other host would be required to assume this role on each= subnet.

If I read it correctly, each client query results = in an mcast poll by the subdelegated proxy. This could setup the overall sy= stem to be chattier than desired. If 5 clients are looking for the a servic= e on the same remote link, the target subnet will be subject to 5 different= mDNS requests by the proxy.

With that, and I believe sharing David's thought, w= hat about a model where clients use DNS-SD, but instead of DNS using the hy= bridProxy model, the SLP DA model of learning services is used.
ex. Using a snooping 'helper' to unicast forward link-local (A= CLd) mDNS service advertisements (~UAs) to populate centralized DA(s).
I= f snooping is done at L2, perhaps other data could be inserted (location in= fo) in the advertisement ('local', becomes 'Building1') her= e.
DAs accept/deny advertisements via policy.
DAs meshed and may share data via policy (~mSLP).
DHCP option(s) could s= upply a host with a specific DA to use and/or a DNS-SD browse domain if des= ired.
Similar to the draft, a client DNS-SD request would be sent to it&= #39;s DNS server which ,if necessary, would be delegated to the appropriate= DAs which would then service the dynamic service request and respond to th= e client.

--=A0
Garry Peirce
Networkmaine, University of Maine SystemSystem

--047d7bacb840cd495104dfb5c2db-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C705C21F9F36 for ; Fri, 21 Jun 2013 10:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.129 X-Spam-Level: X-Spam-Status: No, score=-102.129 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+QHoEFiJpEi for ; Fri, 21 Jun 2013 10:52:13 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 429AA21F9E76 for ; Fri, 21 Jun 2013 10:52:13 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so4889177qcz.0 for ; Fri, 21 Jun 2013 10:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=tjZifYMxnRpY12fCbg+xE/NDmelzxEUV1QeYzahegY8=; b=Mdoh+qZzuuOvRhNbMIi4q4/fBy3TZQK0FyJ2b3+2RG36AN7n+CkJcq1w5WL9O8sMXf jsZNORlveI5SL2Q5tQngSjQw+UaBPLMGOBYKYrvSiWHBn3lCIammmewyADXGm6EJVmee eWVlz9eVsv2fOPpO9QGw1o6ATcgw0F6K4vASBe/gDbh9IK6tt6l6Up9QjryftOf8Doxm 1lwqDlgnsc8O5sAXmLbLR+KJSPi1b7HluIxk6kGRiD/G/GnynVmgVsl/KZVZlayk/qp1 JZLQb6Pn3TVkCpRLs++ZXdlng8i8jG4VEtYx4vLo+nAeN/zz1XmHRqSOujR0mVb8pVRA pp+w== X-Received: by 10.229.17.211 with SMTP id t19mr1463280qca.50.1371837132389; Fri, 21 Jun 2013 10:52:12 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:a5b3:82af:610c:36b4? ([2001:420:2481:20:a5b3:82af:610c:36b4]) by mx.google.com with ESMTPSA id ng3sm7231436qeb.0.2013.06.21.10.52.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 10:52:10 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 21 Jun 2013 13:52:09 -0400 References: <20130620183604.563.97531.idtracker@ietfa.amsl.com> To: "mdnsext@ietf.org" Message-Id: <352651CB-88BF-4877-82A2-280CBCDF8AE8@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [mdnsext] dnssdext BoF in Berlin X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:52:13 -0000 The request for a dnssdext BoF in Berlin has been approved by the IESG. = The BoF logistics are included below. Note the name of the BoF is = dnssdext, not sdnssd. The BoF will be scheduled in the IETF-87 agenda = along with other BoFs and WG meetings, so we'll know the date and time = of the meeting as soon as the agenda is completed. Please review the information below and reply with questions or = suggested updates. In particular, are there any other WG/BoF sessions = that should be be listed as "Conflicts to Avoid"? I've already sent in = a request to drop "intarea" from the explicit list and add a special = request to avoid conflicts with all INT area WG sessions. - Ralph Begin forwarded message: > From: "\"IETF Meeting Session Request Tool\"" = > Subject: dnssdext - New Meeting Session Request for IETF 87 > Date: June 20, 2013 2:36:04 PM EDT > To: session-request@ietf.org > Cc: dnssdext-ads@tools.ietf.org, rdroms.ietf@gmail.com, = tjc@ecs.soton.ac.uk, cmorgan@amsl.com >=20 >=20 >=20 > A new meeting session request has just been submitted by Cindy Morgan, = on behalf of the dnssdext working group. >=20 >=20 > --------------------------------------------------------- > Working Group Name: DNS-SD Extensions > Area Name: Internet Area > Session Requester: Cindy Morgan >=20 > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 150 > Conflicts to Avoid:=20 > First Priority: intarea, dnsop, v6ops, appsawg=20 >=20 >=20 >=20 >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5172211E81A8 for ; Fri, 21 Jun 2013 10:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82dFHWpffYSX for ; Fri, 21 Jun 2013 10:40:08 -0700 (PDT) Received: from mail-out.apple.com (bramley.apple.com [17.151.62.49]) by ietfa.amsl.com (Postfix) with ESMTP id 6DC6F11E81A5 for ; Fri, 21 Jun 2013 10:40:05 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MOR002997NW3QN0@mail-out.apple.com> for mdnsext@ietf.org; Fri, 21 Jun 2013 10:40:04 -0700 (PDT) X-AuditID: 11807157-b7f706d0000006c6-1d-51c48ff3421a Received: from [17.153.16.152] (Unknown_Domain [17.153.16.152]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 81.6F.01734.4FF84C15; Fri, 21 Jun 2013 10:40:04 -0700 (PDT) From: Michael Sweet In-reply-to: <51C48994.4050703@umn.edu> Date: Fri, 21 Jun 2013 13:40:08 -0400 Message-id: References: <4A8CEE77-B266-45E7-9D46-1ABB07C82CF0@apple.com> <51C48994.4050703@umn.edu> To: David Farmer X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUiOFNghu6X/iOBBhd2m1q0/l7ObHFyySkm iyPfYi12HZjA6MDisfXkDzaPJUt+Mnmc/tXK7HF1YRN7AEsUl01Kak5mWWqRvl0CV8aMy50s BdM5K/r+N7A0MG5j72Lk5JAQMJG42HGWFcIWk7hwbz1bFyMXh5BAL5PEgsZ/YAlhARWJfXM3 gDXwCuhJLP03hxHEZhbQkdi59Q4biM0moCbxe1IfWD2ngLrEtcZFzCA2i4CqxL37/5kh6t0l DnxoYYOwtSWWLXzNDDHTRuLSrY2MEIsnMUns+neKBSQhIqAo8f54K1CCA+g6WYmdv5MmMPLP QnLGLCRnzEIydgEj8ypGgaLUnMRKE73EgoKcVL3k/NxNjKDQbCgM38H4b5nVIUYBDkYlHt4D qUcChVgTy4orcw8xSnAwK4nwsgcBhXhTEiurUovy44tKc1KLDzFKc7AoifNufHUwUEggPbEk NTs1tSC1CCbLxMEp1cC4VbjQuOP00ZsfS3l2HNd9s1Kh9SVL1t+DhU/kf7PIHp78KOyPCku7 n0+nWsDBjqblt1Ja45QDmt7+/mdsEfnP/dGqfdJXxI5xdf47KzdD14hL+tvyKw8/Mv0+eYhP 7uTBU+tNFbq+bjv6xK/6Q5VYxP15ZlO+7dsdOYHHw82E96vLw+kPrj6RVGIpzkg01GIuKk4E AFsMrPdJAgAA Cc: IETF mdnsext , Garret Peirce Subject: Re: [mdnsext] mdnsext & SLP X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:40:14 -0000 David, On 2013-06-21, at 1:12 PM, David Farmer wrote: > ... > I have experience running SLP in a large scale Campus/Enterprise environment, many of the things you say are a disadvantage are actually an advantage in such environments. I don't recall saying any of this was a disadvantage, merely that it was an incomplete solution. > I'm not sure compatibility or interpenetration with SLP is a good idea or not, but something similar to the DA architecture and the ability to tell unicast isolated client where the DA is with a DHCP option are concepts I think should be considered for the dnssdext solution space. Absolutely. My only points are these: 1. SLP needs a DA for scalability/performance 2. SLP needs DHCP to support arbitrary subnets 3. SLP doesn't solve the name/address resolution issues called out in the charter for home networks, although DNS can fill the gap for larger/managed networks. 4. The issues with deploying SLP look similar to those faced by mDNS + DNS-SD. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA2221F9FA5 for ; Fri, 21 Jun 2013 10:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgIN4HqQdDhb for ; Fri, 21 Jun 2013 10:12:53 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id CCD5621F9F97 for ; Fri, 21 Jun 2013 10:12:53 -0700 (PDT) Received: from mail-yh0-f49.google.com (mail-yh0-f49.google.com [209.85.213.49]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Fri, 21 Jun 2013 12:12:52 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-yh0-f49.google.com [209.85.213.49] #+LO+TR X-Umn-Classification: local Received: by mail-yh0-f49.google.com with SMTP id v1so3267899yhn.8 for ; Fri, 21 Jun 2013 10:12:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=lffhTMWH7X0h4+ms+juQCnKulgoN6hQ09rkXwksEg5s=; b=Qnw7m+IH6RaknRT0PvMQe/hO0TcV7Rp90tssPGqnTsMzQL7q/2sKABlPUwY/bZN2kY QewdDagv6ksk7P8gPMqS0XKSL1eoLd+FU6YtwC5ITzYB4h6Eme28g3wSQD5H1iA4g7hN 9jsqMSaYCe5inpA7dEyQaDJLhhjg9I7FqWYchTBd5z+rHrZMo9LtX3dxmA6dJIIVqrMA MHlFvu9TdcwHuspAJx02xZonAeVHWs5K28y09qA2VbGxHyKZtyiFz1y97PtFqpTrOBqY x/GOWuAa0cZ+vKbiIWyBpyVDU2OMJeh6GyFVPl1eLuMKd5UxErkob5fH6duBVGqgKvgo Rtvw== X-Received: by 10.236.60.134 with SMTP id u6mr8180274yhc.40.1371834772637; Fri, 21 Jun 2013 10:12:52 -0700 (PDT) X-Received: by 10.236.60.134 with SMTP id u6mr8180266yhc.40.1371834772525; Fri, 21 Jun 2013 10:12:52 -0700 (PDT) Received: from x-128-101-233-51.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:bd7b:7200:9906:ccd5]) by mx.google.com with ESMTPSA id s65sm9682734yhs.14.2013.06.21.10.12.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 10:12:51 -0700 (PDT) Message-ID: <51C48994.4050703@umn.edu> Date: Fri, 21 Jun 2013 12:12:52 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Sweet References: <4A8CEE77-B266-45E7-9D46-1ABB07C82CF0@apple.com> In-Reply-To: <4A8CEE77-B266-45E7-9D46-1ABB07C82CF0@apple.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQliaBL4E3wwSVjrG2FJKLTFuGQXatqbrZSoVK8a+RatjBV27m/JUdglgOOmQ6mMBbQ4MG4370bpXzEpQ/bZqkWCg7QyszH+U/S/Ur9iat7Nc8TKvNDAf31ocinvGcjGV2pPp+xv Cc: IETF mdnsext , Garret Peirce , David Farmer Subject: Re: [mdnsext] mdnsext & SLP X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 17:12:59 -0000 On 6/21/13 11:43 , Michael Sweet wrote: > Garret, > > On Jun 21, 2013, at 12:15 PM, Garret Peirce > wrote: >> Michael, >> >> I had thought the purpose of an SLP DA was to enable SD across subnet >> boundaries. >> The idea being there could be a number of them setup for different >> reasons (ex. organizational/serviced scoped). >> ref: RFC2608 section 12. > > *If* the DA spans the subnets, a single DA could service all of them and > still be auto-detected by the UA's. But that really only works for > simple topologies where you have a common gateway or router joining the > subnets. > > If you use DHCP to set the DA for the UA's on each subnet, then you have > to configure each of the DHCP servers to do that... And you still have > the issue of resolving hostnames and/or routing addresses for the > services - for example, a printer might advertise its printer service > with any of the following: > > service:printer:ipp://192.168.0.100/ipp/print > service:printer:ipp://10.0.1.100/ipp/print > service:printer:ipp://[fe80::0100]/ipp/print > service:printer:ipp://hostname.local./ipp/print > service:printer:ipp://17.1.2.100/ipp/print > service:printer:ipp://hostname.apple.com/ipp/print > I have experience running SLP in a large scale Campus/Enterprise environment, many of the things you say are a disadvantage are actually an advantage in such environments. I'm not sure compatibility or interpenetration with SLP is a good idea or not, but something similar to the DA architecture and the ability to tell unicast isolated client where the DA is with a DHCP option are concepts I think should be considered for the dnssdext solution space. Thanks. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBFB21F9E97 for ; Fri, 21 Jun 2013 09:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.312 X-Spam-Level: X-Spam-Status: No, score=-8.312 tagged_above=-999 required=5 tests=[AWL=2.286, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yzQciuKhIF4 for ; Fri, 21 Jun 2013 09:43:52 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id B2E6F21F9EB2 for ; Fri, 21 Jun 2013 09:43:48 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_pnMlK6470zeJgThr0dYd1Q)" Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MOR001PY53YU6I1@mail-out.apple.com> for mdnsext@ietf.org; Fri, 21 Jun 2013 09:43:38 -0700 (PDT) X-AuditID: 11807157-b7f706d0000006c6-a4-51c482b72031 Received: from [17.153.35.213] (Unknown_Domain [17.153.35.213]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 37.83.01734.8B284C15; Fri, 21 Jun 2013 09:43:37 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Fri, 21 Jun 2013 12:43:34 -0400 Message-id: <4A8CEE77-B266-45E7-9D46-1ABB07C82CF0@apple.com> References: To: Garret Peirce X-Mailer: Apple Mail (2.1764) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUiOFP5qu7OpiOBBlsv6lmcXHKKyeLIt1iL XQcmMDowe2w9+YPNY8mSn0wep3+1MgcwR3HZpKTmZJalFunbJXBlPD67jrXgjWrF5RtHGRsY Xyh0MXJySAiYSEw/94AVwhaTuHBvPVsXIxeHkEAvk8S1xitgCWEBFYl9czewg9i8AnoS2xYe ALOZBRIkGqYdYgOx2QTUJH5P6gOr5xQIlPhw5hsLiM0ioCpxef0tJoh6ZYkV024wQcyxkTh2 6BozxLJjjBKb5ywBaubgEAFatuNgIcRBshIT+64xTmDkm4Vk9SwkqyFsbYllC18zQ9h6Ei+b 3rFjiutKXFw3iXEBI9sqRoGi1JzEShO9xIKCnFS95PzcTYygsG0oDN/B+G+Z1SFGAQ5GJR7e A6lHAoVYE8uKK3MPMUpwMCuJ8LIHAYV4UxIrq1KL8uOLSnNSiw8xSnOwKInzbnx1MFBIID2x JDU7NbUgtQgmy8TBKdXA2J3SZ63pZuVQ/6Lu+rbl95ac5/sTxXQstn/tN9uTP1h4+IUTnBRv Svft/bpE68yZn//DexP/5JXN8blsO32C1LqPQJYii2Bxqfy6PXfO746qEO5nTD3zUytpyq7r pbrLW89WbN8cpyWTvafZWlTYW1NoytyF7tOb1xzIlxdM3C+832ZZc68SS3FGoqEWc1FxIgB9 vjyvVwIAAA== Cc: IETF mdnsext Subject: Re: [mdnsext] mdnsext & SLP X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 16:43:58 -0000 --Boundary_(ID_pnMlK6470zeJgThr0dYd1Q) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Garret, On Jun 21, 2013, at 12:15 PM, Garret Peirce wrote: > Michael, > > I had thought the purpose of an SLP DA was to enable SD across subnet boundaries. > The idea being there could be a number of them setup for different reasons (ex. organizational/serviced scoped). > ref: RFC2608 section 12. *If* the DA spans the subnets, a single DA could service all of them and still be auto-detected by the UA's. But that really only works for simple topologies where you have a common gateway or router joining the subnets. If you use DHCP to set the DA for the UA's on each subnet, then you have to configure each of the DHCP servers to do that... And you still have the issue of resolving hostnames and/or routing addresses for the services - for example, a printer might advertise its printer service with any of the following: service:printer:ipp://192.168.0.100/ipp/print service:printer:ipp://10.0.1.100/ipp/print service:printer:ipp://[fe80::0100]/ipp/print service:printer:ipp://hostname.local./ipp/print service:printer:ipp://17.1.2.100/ipp/print service:printer:ipp://hostname.apple.com/ipp/print The only ones that are likely to be directly usable are the last two... _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_pnMlK6470zeJgThr0dYd1Q) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Garret,

On Jun 21, 2013, at 12:15 = PM, Garret Peirce <peirce@maine.edu> = wrote:
Michael,

I had thought the = purpose of an SLP DA was to enable SD across subnet = boundaries.
The idea being there could be a = number of them setup for different reasons (ex. organizational/serviced = scoped).
ref: RFC2608 section = 12.

*If* the DA spans = the subnets, a single DA could service all of them and still be = auto-detected by the UA's.  But that really only works for simple = topologies where you have a common gateway or router joining the = subnets.

If you use DHCP to set the DA for the = UA's on each subnet, then you have to configure each of the DHCP servers = to do that...  And you still have the issue of resolving hostnames = and/or routing addresses for the services - for example, a printer might = advertise its printer service with any of the = following:

    = service:printer:ipp://192.168.0.100/ipp/print
  =   = service:printer:ipp://10.0.1.100/ipp/print
  =   = service:printer:ipp://[fe80::0100]/ipp/print
  =   = service:printer:ipp://hostname.local./ipp/print
 = ;   = service:printer:ipp://17.1.2.100/ipp/print
  =   service:printer:ipp://hostname.apple.com/ipp/print<= /a>



= --Boundary_(ID_pnMlK6470zeJgThr0dYd1Q)-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7915021F9EA7 for ; Fri, 21 Jun 2013 09:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfGWGcLxENVl for ; Fri, 21 Jun 2013 09:15:31 -0700 (PDT) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by ietfa.amsl.com (Postfix) with ESMTP id 1464221F9E84 for ; Fri, 21 Jun 2013 09:15:28 -0700 (PDT) Received: by mail-vb0-f51.google.com with SMTP id x17so6084902vbf.10 for ; Fri, 21 Jun 2013 09:15:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=cJW4ygIDKQSiwgzlpnqAn2uhD8wZZeFI23FrcGzL1ek=; b=L9oBIRagh1Nvg4rtRdUMJpz9XOaczGA+zyMJNlYA5wsAUnm+M9vNGqZG0EG4JqRHOZ QlS6aAKwP6sYxy8oiVjoWoj6oiXapypMKeYWGwMD1d23K0WNviEPpGq7lo9o4A2pCMY4 JYlGXphXotE/KVYsm8d2iOe+c+6MbJwXc/BlVTZwuHYDoRaJfRKAv0PXlIVAxdX6/X1S fnzSOncI/+tH6ixpyKp9kRQUnPIcZgYPmE2pHP2nybFT2/HzdmYqfxY/Zs6SbhA3EfpA N6leRlXlSm7doCEAM6rQIIktn01c7YL0d8ulfed9sklat4oZpwONe10Td87BYnWBnMJu 4u0Q== MIME-Version: 1.0 X-Received: by 10.58.233.47 with SMTP id tt15mr6057219vec.56.1371831327737; Fri, 21 Jun 2013 09:15:27 -0700 (PDT) Received: by 10.220.50.131 with HTTP; Fri, 21 Jun 2013 09:15:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Jun 2013 12:15:27 -0400 Message-ID: From: Garret Peirce To: Michael Sweet Content-Type: multipart/alternative; boundary=089e0115fc1afb557d04dfac5ee3 X-Gm-Message-State: ALoCoQmL2TfWFD9g3B5OJRaAnNmvN5uUuCdtlGTuvS6nB07dQPPlgYUp2esHW/raPvLtALCfizsc Cc: IETF mdnsext Subject: Re: [mdnsext] mdnsext & SLP X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 16:15:31 -0000 --089e0115fc1afb557d04dfac5ee3 Content-Type: text/plain; charset=ISO-8859-1 Michael, I had thought the purpose of an SLP DA was to enable SD across subnet boundaries. The idea being there could be a number of them setup for different reasons (ex. organizational/serviced scoped). ref: RFC2608 section 12. On Fri, Jun 21, 2013 at 11:26 AM, Michael Sweet wrote: > Garret, > > On Jun 21, 2013, at 11:05 AM, Garret Peirce wrote: > > I'm curious why SLP is not a potential solution to the hurdle of 'service > discovery beyond the local link'. > > > Speaking from experience, SLP is painful without a DA, and you need an > accessible DA on every network segment. > > Ignoring client support for the moment, SLP seems like an existing, > defined mechanism for scalable SD. > > > AFAIK, SLP does not solve the multiple-network problem. > > It seems this draft aims to develop an alternate method to do so. > > > Well, I think the goal is to come up with a solution to the > multiple-network problem that scales while retaining dynamic > registration/advertising of services. The focus may be on mDNS and DNS-SD > (because that drove the petition to fix things...) but I suspect that > solutions for DNS-SD and mDNS would also work for extending SLP. > > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > > -- Garry Peirce Network Architect Networkmaine, University of Maine System 1-207-561-3539 --089e0115fc1afb557d04dfac5ee3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Michael,

I had thought the purpos= e of an SLP DA was to enable SD across subnet boundaries.
The idea being there could be a number of them setup for different reaso= ns (ex. organizational/serviced scoped).
ref: RFC2608 section 12.





On Fri, Jun 21, 2013 at 11:26 AM,= Michael Sweet <msweet@apple.com> wrote:
Garret,

On Jun 21, 2013, at 11= :05 AM, Garret Peirce <peirce@maine.edu> wrote:
I'm curious why SLP is not a= potential solution to the hurdle of 'service discovery beyond the loca= l link'.

Speaking from experienc= e, SLP is painful without a DA, and you need an accessible DA on every netw= ork segment.

Ignoring client support for the moment, SLP se= ems like an existing, defined mechanism for scalable SD.

AFAIK, SLP does not solv= e the multiple-network problem.

It seems this draft aims to develop an a= lternate method to do so.
Well, I think the goal is to come up with a solution to the mu= ltiple-network problem that scales while retaining dynamic registration/adv= ertising of services. =A0The focus may be on mDNS and DNS-SD (because that = drove the petition to fix things...) but I suspect that solutions for DNS-S= D and mDNS would also work for extending SLP.

_________________________________________________________
Michael Sweet,= Senior Printing System=A0Engineer, PWG Chair




--
Ga= rry Peirce
Network Architect
Networkmaine, University of Maine System=
1-207-561-3539 --089e0115fc1afb557d04dfac5ee3-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8DC521F9BF4 for ; Fri, 21 Jun 2013 08:26:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.931 X-Spam-Level: X-Spam-Status: No, score=-7.931 tagged_above=-999 required=5 tests=[AWL=2.667, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s0-lkrdPVshr for ; Fri, 21 Jun 2013 08:26:33 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA0C21F9AF1 for ; Fri, 21 Jun 2013 08:26:26 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_US15KYs4UyBBuQ0ZuU8YlA)" Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MOR007TE1IYOLL0@mail-out.apple.com> for mdnsext@ietf.org; Fri, 21 Jun 2013 08:26:25 -0700 (PDT) X-AuditID: 11807157-b7f706d0000006c6-56-51c4709e6ea4 Received: from [17.153.35.213] (Unknown_Domain [17.153.35.213]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id C9.F2.01734.0A074C15; Fri, 21 Jun 2013 08:26:25 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Fri, 21 Jun 2013 11:26:22 -0400 Message-id: References: To: Garret Peirce X-Mailer: Apple Mail (2.1764) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrELMWRmVeSWpSXmKPExsUiOFP5qu7CgiOBBg1npC1OLjnFZHHkW6zF rgMTGB2YPbae/MHmsWTJTyaP079amQOYo7hsUlJzMstSi/TtErgyzk9pYC9YIV9xb34XYwNj v3QXIyeHhICJxLylU9ghbDGJC/fWs3UxcnEICfQySRxb3cIIkhAWUJHYN3cDWBGvgJ7EtoUH wGxmgQSJvp6rYDVsAmoSvyf1sYLYnAKBEvcv/2EDsVkEVCWmHL3DClGvLLFi2g0miDk2El+m 7WLuYuQAWhYgcfIgF4gpArRqx8FCiHNkJSb2XWOcwMg3C8niWUgWQ9jaEssWvmaGsPUkXja9 Y8cU15W4uG4S4wJGtlWMAkWpOYmVJnqJBQU5qXrJ+bmbGEEh21AYvoPx3zKrQ4wCHIxKPLwH Uo8ECrEmlhVX5h5ilOBgVhLhZQ8CCvGmJFZWpRblxxeV5qQWH2KU5mBREufd+OpgoJBAemJJ anZqakFqEUyWiYNTqoFxt/H24pj4neue3lgV3/bzhRN35zPl26umXdbsnTC5kHvWgWqxtQfv fFztFLQzIPPHtmItLnm/ZwdtRf81eh/+eFNxXvvc1vA/ZwP/9L6b4ie0efaTjk4necN+W+FD Nq/1l/DU/TDeN/nuFn+FuT4NC/I0guaptLl/NdNLVBc0PTw3/ohD35bFSizFGYmGWsxFxYkA tOUSvFUCAAA= Cc: IETF mdnsext Subject: Re: [mdnsext] mdnsext & SLP X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:26:39 -0000 --Boundary_(ID_US15KYs4UyBBuQ0ZuU8YlA) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Garret, On Jun 21, 2013, at 11:05 AM, Garret Peirce wrote: > I'm curious why SLP is not a potential solution to the hurdle of 'service discovery beyond the local link'. Speaking from experience, SLP is painful without a DA, and you need an accessible DA on every network segment. > Ignoring client support for the moment, SLP seems like an existing, defined mechanism for scalable SD. AFAIK, SLP does not solve the multiple-network problem. > It seems this draft aims to develop an alternate method to do so. Well, I think the goal is to come up with a solution to the multiple-network problem that scales while retaining dynamic registration/advertising of services. The focus may be on mDNS and DNS-SD (because that drove the petition to fix things...) but I suspect that solutions for DNS-SD and mDNS would also work for extending SLP. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_US15KYs4UyBBuQ0ZuU8YlA) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable
Garret,

On Jun = 21, 2013, at 11:05 AM, Garret Peirce <peirce@maine.edu> = wrote:
I'm curious why = SLP is not a potential solution to the hurdle of 'service discovery = beyond the local link'.

Speaking from = experience, SLP is painful without a DA, and you need an accessible DA = on every network segment.

Ignoring client support for the moment, SLP seems = like an existing, defined mechanism for scalable SD.

AFAIK, = SLP does not solve the multiple-network problem.

It seems this draft aims to develop = an alternate method to do = so.

Well, I = think the goal is to come up with a solution to the multiple-network = problem that scales while retaining dynamic registration/advertising of = services.  The focus may be on mDNS and DNS-SD (because that drove = the petition to fix things...) but I suspect that solutions for DNS-SD = and mDNS would also work for extending SLP.

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_US15KYs4UyBBuQ0ZuU8YlA)-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AFB21E8101 for ; Fri, 21 Jun 2013 08:05:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCtNTr2j83oJ for ; Fri, 21 Jun 2013 08:05:43 -0700 (PDT) Received: from mail-vb0-x232.google.com (mail-vb0-x232.google.com [IPv6:2607:f8b0:400c:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id 3137A21E8112 for ; Fri, 21 Jun 2013 08:05:42 -0700 (PDT) Received: by mail-vb0-f50.google.com with SMTP id w16so6049261vbb.9 for ; Fri, 21 Jun 2013 08:05:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=buModr3zhJFf5RsTkEqshZb1ZTJctMiozOXQCONMtH4=; b=P4bY4fQ5m40FkjCNIbW0gr80FljyYWPZ5M8WtxQBiukV4kLQ6CwlaRYA5YOD9jzGt7 d99pgReAZ2UpyPbj7fq0zfgKZyJPZU5ZKohQZx86OXsXRQIXIubRvZ9Upt9SufOLcakk e3SSnwKZDB62DWiNzDhlaDp5z1m8PoMPgeXT/ghJxmkxTRiHwlUvxtulX7ipaMbi8XfW HRd5tzoNZAxfC3QxGO36C3DWega9AQow84K6FGOGU7dcFNqMnUglV87iDlq8bEiPtEfY RmXNwplvThOrb561GQLOiHVpVhpS/jF5xb59dOUpdq3spjXANYSruc7GXZI7VG/kKN// h/bw== MIME-Version: 1.0 X-Received: by 10.58.207.195 with SMTP id ly3mr5889137vec.77.1371827141640; Fri, 21 Jun 2013 08:05:41 -0700 (PDT) Received: by 10.220.50.131 with HTTP; Fri, 21 Jun 2013 08:05:41 -0700 (PDT) Date: Fri, 21 Jun 2013 11:05:41 -0400 Message-ID: From: Garret Peirce To: mdnsext@ietf.org Content-Type: multipart/alternative; boundary=047d7b6d8d7c7890fb04dfab6518 X-Gm-Message-State: ALoCoQn4TI+h67WGu6RHwBmftWEE/x6Gx7Pdgvs+NoUi9KNr7+C4mvCytKDCIolC3gZVLmLF8VSo Subject: [mdnsext] mdnsext & SLP X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:05:44 -0000 --047d7b6d8d7c7890fb04dfab6518 Content-Type: text/plain; charset=ISO-8859-1 I'm curious why SLP is not a potential solution to the hurdle of 'service discovery beyond the local link'. Ignoring client support for the moment, SLP seems like an existing, defined mechanism for scalable SD. It seems this draft aims to develop an alternate method to do so. Finding some history in older IETF zeroconf archives( http://osdir.com/ml/ietf.zeroconf/2002-07), I'm wondering if the thoughts to the question from a decade ago would be different today? >So it seems to me that either DNS-SD has to scale gracefully all >the way up to huge, or that I will have to bite the bullet and >build in something tougher like SLP anyway. And then why would I want to do DNS-SD as well? As anything else, both this DNS-SD hybrid extension and SLP have their levels of complexity and choreography. SLP has hosts advertise their services to a central depository, and the client must use this depository (SA/DA) to locate known services. Whereas in the DNS-SD extension method, the clients use the hybridProxy to actively search for services. I wonder if the latter might become chatty , the need for suppression of certain responses and use of LLQ potentially tricky (are LLQ responses supported by all common clients?) Perhaps a current discussion/comparison of DNS-SD/SLP would be a worthwhile exploration for SD beyond the local link. I could envision room for both depending on one's environment, ex. DNS-SD (as it exists) used for manually controlled entries and SLP for dynamic ones. Seeing OpenSLP 2.0 was recently released, there is an interesting note mentioning future mDNS integration - 'Version 2.1 is slated to include features like mdns integration'. http://openslp.org/ Appreciate any thoughts as I try to understand the differences of each approach. -- Garry Peirce Networkmaine, University of Maine System --047d7b6d8d7c7890fb04dfab6518 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I'm curious why SLP is not a potential solution to the= hurdle of 'service discovery beyond the local link'.

Ignoring client support for the moment, SLP seems like an existi= ng, defined mechanism for scalable SD.
It seems this draft aim= s to develop an alternate method to do so.


>So it seems to me that either DNS-SD has to sc= ale gracefully all
>the way up to huge, or that I will have to bite t= he bullet and
>build in something tougher like SLP anyway. And then w= hy would I want to do DNS-SD as well?

As anything else, both this DNS-SD hyb= rid extension and SLP have their levels of complexity and choreography.
SLP has hosts advertise their services to a central depository, and = the client must use this depository (SA/DA) to locate known services. =A0 W= hereas in the DNS-SD extension method, the clients use the hybridProxy to a= ctively search for services. I wonder if the latter might become chatty , t= he need for suppression of certain responses and use of LLQ potentially tri= cky (are LLQ responses =A0supported by all common clients?)

Perhaps a current discussion/comparison of DNS-SD/SLP w= ould be a worthwhile exploration for SD beyond the local link. =A0I could e= nvision room for both depending on one's environment, ex. DNS-SD (as it= exists) used for manually controlled entries and SLP for dynamic ones.

Garry Peirce
Networkmaine, Universi= ty of Maine System

--047d7b6d8d7c7890fb04dfab6518-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1AA921F9BF2 for ; Wed, 19 Jun 2013 05:16:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VFnPPX0GrS9 for ; Wed, 19 Jun 2013 05:16:42 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [IPv6:2001:630:d0:f102::25e]) by ietfa.amsl.com (Postfix) with ESMTP id E5AA621F9BF4 for ; Wed, 19 Jun 2013 05:16:40 -0700 (PDT) Received: from falcon.ecs.soton.ac.uk (localhost [127.0.0.1]) by falcon.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r5JCGXmI032002 for ; Wed, 19 Jun 2013 13:16:33 +0100 X-DKIM: Sendmail DKIM Filter v2.8.2 falcon.ecs.soton.ac.uk r5JCGXmI032002 DKIM-Signature: v=1; a=rsa-sha1; c=simple/simple; d=ecs.soton.ac.uk; s=201304; t=1371644194; bh=BuRpjb2OokmYzOneBnlZMww6DXk=; h=Mime-Version:Subject:From:In-Reply-To:Date:References:To; b=pWAqKeXZvofMk5QVDgE0QBNUdwOtaWhv9O+O0LBJzllatCsYXHLGE3lCuOQBfAF1S oO0JZ6xh7UbeLeAMriu6GEO/XoVorssVwpxENReTe9U0Lv0zps5q9fweVcp/0imY2u x1cX+5jatgkBhfJMeW/b1lccH/z9by7SRZzF74RY= Received: from gander.ecs.soton.ac.uk ([2001:630:d0:f102:250:56ff:fea0:401]) by falcon.ecs.soton.ac.uk (falcon.ecs.soton.ac.uk [2001:630:d0:f102:250:56ff:fea0:68da]) envelope-from with ESMTP (valid=N/A) id p5IDGX04306594093g ret-id none; Wed, 19 Jun 2013 13:16:33 +0100 Received: from dhcp-205-24.wireless.soton.ac.uk (dhcp-205-24.wireless.soton.ac.uk [152.78.205.24]) (authenticated bits=0) by gander.ecs.soton.ac.uk (8.13.8/8.13.8) with ESMTP id r5JCGVk5014356 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 19 Jun 2013 13:16:31 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Tim Chown In-Reply-To: Date: Wed, 19 Jun 2013 13:16:36 +0100 Content-Transfer-Encoding: quoted-printable Message-ID: References: <68B28F2E-5BAA-423A-B95C-55EC141A2BDF@ecs.soton.ac.uk> To: mdnsext@ietf.org X-Mailer: Apple Mail (2.1508) X-ECS-MailScanner: Found to be clean, Found to be clean X-smtpf-Report: sid=p5IDGX043065940900; tid=p5IDGX04306594093g; client=relay,forged,no_ptr,ipv6; mail=; rcpt=; nrcpt=1:0; fails=0 X-ECS-MailScanner-Information: Please contact the ISP for more information X-ECS-MailScanner-ID: r5JCGXmI032002 X-ECS-MailScanner-From: tjc@ecs.soton.ac.uk Subject: Re: [mdnsext] BoF request posted X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 12:16:43 -0000 Yep. The only comments I have received have been about point 3, but part of = the BoF agenda can be used to nail that one down. Tim On 19 Jun 2013, at 02:42, "Brzozowski, John" = wrote: > Looks good Ralph, thanks. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > John Jason Brzozowski > Comcast Cable > m) 484-962-0060 > o) 609-377-6594 > w) www.comcast6.net > e) john_brzozowski@cable.comcast.com > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 >=20 >=20 >=20 >=20 > -----Original Message----- > From: Ralph Droms > Date: Monday, June 10, 2013 3:33 PM > To: "mdnsext@ietf.org" > Subject: [mdnsext] BoF request posted >=20 >> I've posted the sdnssd BoF request here: >> http://trac.tools.ietf.org/bof/trac/wiki/WikiStart >>=20 >> Review and comments (even as simple as "looks OK") encouraged. >>=20 >> - Ralph >>=20 >> _______________________________________________ >> mdnsext mailing list >> mdnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/mdnsext >=20 > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3F3821F9B16 for ; Tue, 18 Jun 2013 18:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.376 X-Spam-Level: X-Spam-Status: No, score=-101.376 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTTW6m5qmgL0 for ; Tue, 18 Jun 2013 18:42:22 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 9010E21F9B1C for ; Tue, 18 Jun 2013 18:42:21 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.55921356; Tue, 18 Jun 2013 21:41:13 -0400 Received: from PACDCEXHUB04.cable.comcast.com (24.40.56.121) by pacdcexhub03.cable.comcast.com (24.40.56.116) with Microsoft SMTP Server (TLS) id 14.2.318.1; Tue, 18 Jun 2013 21:42:16 -0400 Received: from PACDCEXMB02.cable.comcast.com ([169.254.2.54]) by pacdcexhub04.cable.comcast.com ([fe80::1532:d330:f9a5:c8a1%18]) with mapi id 14.02.0318.001; Tue, 18 Jun 2013 21:42:15 -0400 From: "Brzozowski, John" To: "Ralph Droms (rdroms)" , "mdnsext@ietf.org" Thread-Topic: [mdnsext] BoF request posted Thread-Index: AQHOZhFUterGGPYebU+Sgp5NujsNqZk8UJQA Date: Wed, 19 Jun 2013 01:42:15 +0000 Message-ID: In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA36EC431@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [68.87.16.249] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mdnsext] BoF request posted X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 01:42:40 -0000 Looks good Ralph, thanks. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 o) 609-377-6594 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Ralph Droms Date: Monday, June 10, 2013 3:33 PM To: "mdnsext@ietf.org" Subject: [mdnsext] BoF request posted >I've posted the sdnssd BoF request here: >http://trac.tools.ietf.org/bof/trac/wiki/WikiStart > >Review and comments (even as simple as "looks OK") encouraged. > >- Ralph > >_______________________________________________ >mdnsext mailing list >mdnsext@ietf.org >https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1570921F9A3E for ; Thu, 13 Jun 2013 21:05:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5T+2MbB+Slf for ; Thu, 13 Jun 2013 21:05:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 6795021F8D90 for ; Thu, 13 Jun 2013 21:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=466; q=dns/txt; s=iport; t=1371182702; x=1372392302; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QrPGcfi7Y/ZaTvpMoI+0h8BND4ipoR1VuV82d8WPbAI=; b=TGUVc2HiY1RgJvKx0muzG9KGNsI4ZI2fVYWs2aIBzJttyWWebtBjvAtv L3ed3tgfxCQGEyJzna3pHsGND+jnRJcBZgrFwsroqkiiIURpUJB0/r1eN Jl8bJOS8Fs90VBtzyTzdnUDVwPL2OoVEvntIEsMcN3fF8oYpU31mR+bsy Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFANCVulGtJXG//2dsb2JhbABagwm/SIEGFnSCIwEBAQMBOj8QAgEINQEQMiUCBA4FiAgGum+PFDMHgn9hA5dBkUKDDw X-IronPort-AV: E=Sophos;i="4.87,863,1363132800"; d="scan'208";a="222632995" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 14 Jun 2013 04:04:58 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5E44wc8021362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Jun 2013 04:04:58 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.232]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Thu, 13 Jun 2013 23:04:57 -0500 From: "Ralph Droms (rdroms)" To: Michael Richardson Thread-Topic: [mdnsext] BoF request posted Thread-Index: AQHOZhFUterGGPYebU+Sgp5NujsNqZkv9ZMAgASm80w= Date: Fri, 14 Jun 2013 04:04:56 +0000 Message-ID: <4A1F6E1A-8DA2-4DAB-A117-DD42B6CA83A7@cisco.com> References: <4518F39EB578034D8C99A9B7776CDBA36EC431@xmb-aln-x04.cisco.com>, <17991.1370908942@sandelman.ca> In-Reply-To: <17991.1370908942@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] BoF request posted X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 04:05:08 -0000 On Jun 10, 2013, at 8:03 PM, "Michael Richardson" w= rote: >=20 > Why the name change? After reviewing the discussion during the previous BoF and the target deplo= yment scenarios, DNS-SD is the service of interest to be revised for scalab= ility. mDNS might be one component of achieving that scalability. - Ralph =20 >=20 > --=20 > Michael Richardson , Sandelman Software Works=20 >=20 >=20 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABDB11E80CC for ; Thu, 13 Jun 2013 20:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJiVgZd6E7Ds for ; Thu, 13 Jun 2013 20:26:03 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id D23D321E8050 for ; Thu, 13 Jun 2013 20:26:02 -0700 (PDT) Received: from mail177-db9-R.bigfish.com (10.174.16.246) by DB9EHSOBE036.bigfish.com (10.174.14.99) with Microsoft SMTP Server id 14.1.225.23; Fri, 14 Jun 2013 03:26:01 +0000 Received: from mail177-db9 (localhost [127.0.0.1]) by mail177-db9-R.bigfish.com (Postfix) with ESMTP id 54BFA440098; Fri, 14 Jun 2013 03:26:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.245.85; KIP:(null); UIP:(null); IPV:NLI; H:CH1PRD0811HT005.namprd08.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: PS-24(zzbb2dI98dI9371I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dhz2fh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail177-db9: domain of ruckuswireless.com designates 157.56.245.85 as permitted sender) client-ip=157.56.245.85; envelope-from=alf.watt@ruckuswireless.com; helo=CH1PRD0811HT005.namprd08.prod.outlook.com ; .outlook.com ; Received: from mail177-db9 (localhost.localdomain [127.0.0.1]) by mail177-db9 (MessageSwitch) id 1371180359668143_1695; Fri, 14 Jun 2013 03:25:59 +0000 (UTC) Received: from DB9EHSMHS021.bigfish.com (unknown [10.174.16.245]) by mail177-db9.bigfish.com (Postfix) with ESMTP id 946E140238; Fri, 14 Jun 2013 03:25:59 +0000 (UTC) Received: from CH1PRD0811HT005.namprd08.prod.outlook.com (157.56.245.85) by DB9EHSMHS021.bigfish.com (10.174.14.31) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 14 Jun 2013 03:25:59 +0000 Received: from CH1PRD0811MB407.namprd08.prod.outlook.com ([169.254.8.97]) by CH1PRD0811HT005.namprd08.prod.outlook.com ([10.255.155.40]) with mapi id 14.16.0324.000; Fri, 14 Jun 2013 03:25:46 +0000 From: Alf Watt To: "Ralph Droms (rdroms)" , "mdnsext@ietf.org" Thread-Topic: [mdnsext] BoF request posted Thread-Index: AQHOaK7bsVo1XNy4a0+DY6ZabLd8FA== Date: Fri, 14 Jun 2013 03:25:46 +0000 Message-ID: In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA36EC431@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 x-originating-ip: [10.255.155.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ruckuswireless.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [mdnsext] BoF request posted X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Jun 2013 03:26:08 -0000 "looks OK" looking forward to seeing everyone in Berlin. On 6/10/13 12:33 PM, "Ralph Droms (rdroms)" wrote: >I've posted the sdnssd BoF request here: >http://trac.tools.ietf.org/bof/trac/wiki/WikiStart > >Review and comments (even as simple as "looks OK") encouraged. > >- Ralph > > Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14CB821F8904 for ; Tue, 11 Jun 2013 13:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcZ75BfTMztz for ; Tue, 11 Jun 2013 13:44:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 7D64F21F8D79 for ; Tue, 11 Jun 2013 13:44:21 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id D861F2017C for ; Tue, 11 Jun 2013 16:57:35 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 663FF63A8C; Tue, 11 Jun 2013 16:43:24 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 57A1B639DF for ; Tue, 11 Jun 2013 16:43:24 -0400 (EDT) From: Michael Richardson To: "mdnsext@ietf.org" In-Reply-To: References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <22635.1370439768@sandelman.ca> <51B63B07.5070802@umn.edu> <19621.1370909460@sandelman.ca> <51B71517.4080700@umn.edu> <13345.1370971891@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 20:44:27 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Kerry" =3D=3D Kerry Lynn writes: >> Kerry, many **enterprises** do *not* have any mDNS traffic, because = they >> won't let any non-IT person plug ANYTHING in. >>=20 Kerry> How does an IT person disable intrinsic mDNS probing/announcing/= responding Kerry> behavior in a commercial printer? I guess those same enterprise= s also ban Kerry> OS X Kerry> entirely? Yes, and mDNS would be an excuse for them to continue to do so. WINS resolution can be turned off by group policy, I'm told. Kerry> It seems to me that to carry this conversation forward we need t= o a) define Kerry> sdnssd requirements for Enterprise, which I think we've already = hinted we're Kerry> not well qualified to do, and b) rank those requirements against= those of Kerry> homenet and higher ed, which we arguably know much better. *my* original point was that I was glad that we split off Enterprise as a separate use case, ask if we really a clue what it might mean, and point one at least one knob that we may need to include. I don't think the enterprise IT-clueless people care (or even understand) about multicast traffic. What they care about is controlling the namespace(s) that can be seen by internal devices. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUbeL7IqHRg3pndX9AQK3qgQA3up+4qTq63bXNtmte4HHci5+F2NCS9VA BJJWhTVzKa9MHSjCLka/EFDHhVdmELXN3vOghIuvuA/N7SrFkM0ZnNfRRJLp3OrO yx5An1IsUZzqB6ahaV8T+uq0rbBs90AWY863SiRk/7TcwsP76m6O4WuyduhPj12G ldyPrOVtfM4= =6XRU -----END PGP SIGNATURE----- --=-=-=-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A90821F99B3 for ; Tue, 11 Jun 2013 12:39:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDLfefw6A-as for ; Tue, 11 Jun 2013 12:39:54 -0700 (PDT) Received: from mail-oa0-x235.google.com (mail-oa0-x235.google.com [IPv6:2607:f8b0:4003:c02::235]) by ietfa.amsl.com (Postfix) with ESMTP id 1528321F99AE for ; Tue, 11 Jun 2013 12:39:54 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id k18so3577851oag.12 for ; Tue, 11 Jun 2013 12:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=1BTzxl6Kwa/l5uFqOcPLYJ3sUB/VZQyb9qSsOUFXBMI=; b=n/T9Mf1v58k0nphNFq1PiHnp4sJDX7g2et4mh34XOcNZ8sNpbPDvlbbNNexbdrF0wD cXwb/HE0z+KcDxIBi50DfLeYCSvNDYvipnzBaOxYrDH0vG7d38cqVhFPgoka4umYIHpA sv+CFvSr4YBWyYyBbilB4KbT0CfO+QAV2GMAr+hhpw3Z+zh55eeszlBgPUocj/32pTxK HTy9p3X5pSCr4BzuC7KI6bbsD2JEMTgWd1JnJRS+2m+I/xpK2AuV/UWVVMAkiFvsj2kN 7p4rIYTh5DvXiumKZqUX9Me5CWZNRkwFXJH1YWtYndv0cZcKsh55HEd1a95Id0DBxaSy FNNw== MIME-Version: 1.0 X-Received: by 10.60.164.70 with SMTP id yo6mr13451775oeb.78.1370979593578; Tue, 11 Jun 2013 12:39:53 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.148.197 with HTTP; Tue, 11 Jun 2013 12:39:53 -0700 (PDT) In-Reply-To: <13345.1370971891@sandelman.ca> References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <22635.1370439768@sandelman.ca> <51B63B07.5070802@umn.edu> <19621.1370909460@sandelman.ca> <51B71517.4080700@umn.edu> <13345.1370971891@sandelman.ca> Date: Tue, 11 Jun 2013 15:39:53 -0400 X-Google-Sender-Auth: KkPB-cEdZMQ7okklEp4smcSzDUI Message-ID: From: Kerry Lynn To: Michael Richardson Content-Type: multipart/alternative; boundary=047d7b3a7f84abb9fe04dee60f41 Cc: David Farmer , "mdnsext@ietf.org" Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 19:39:55 -0000 --047d7b3a7f84abb9fe04dee60f41 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jun 11, 2013 at 1:31 PM, Michael Richardson wrote: > > >>>>> "David" == David Farmer writes: > David> If you are saying the only solution a network operator has to > controlling > David> current mDNS traffic is black-holing it; Then we have to make > what ever the > David> new solution is work in the presence of black-holing of > David> current mDNS traffic, > David> including both registration and query of services. One of > David> the use case > > What David said +5. > > Kerry, many **enterprises** do *not* have any mDNS traffic, because they > won't let any non-IT person plug ANYTHING in. > > How does an IT person disable intrinsic mDNS probing/announcing/responding behavior in a commercial printer? I guess those same enterprises also ban OS X entirely? It seems to me that to carry this conversation forward we need to a) define sdnssd requirements for Enterprise, which I think we've already hinted we're not well qualified to do, and b) rank those requirements against those of homenet and higher ed, which we arguably know much better. I just may have gotten off on the wrong foot with this discussion, misunderstanding the original point. If it was that enterprise customers do not like excessive link- local multicast, then I agree that one major objective of this work is to decrease reliance on it by e.g. introducing name caches and client libraries that unicast queries to them when possible. We can't eliminate all link-local multicasting in general, or a number of things stop working. > Those enterprises/IT-divisions are either gonna change (and we can help > them), > or they will go the way of the mainframe operators. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > --047d7b3a7f84abb9fe04dee60f41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jun 11, 2013 at 1:31 PM, Michael Richardson <<= a href=3D"mailto:mcr+ietf@sandelman.ca" target=3D"_blank">mcr+ietf@sandelma= n.ca> wrote:

>>>>> "David" =3D=3D David Farmer <farmer@umn.edu> writes:
=A0 =A0 David> If you are saying the only solution a network opera= tor has to controlling
=A0 =A0 David> current mDNS traffic is black-holing it; Then we have to = make what ever the
=A0 =A0 David> new solution is work in the presence of black-holing of =A0 =A0 David> current mDNS traffic,
=A0 =A0 David> including both registration and query of services. =A0One= of
=A0 =A0 David> the use case

What David said +5.

Kerry, many **enterprises** do *not* have any mDNS traffic, because they won't let any non-IT person plug ANYTHING in.

How does an IT person disable intrinsic mDNS probing/= announcing/responding
behavior in a commercial printer?=A0 I guess those= same enterprises also ban OS X
entirely?

It seems to me that to = carry this conversation forward we need to a) define
sdnssd requirements for Enterprise, which I think we've already hinted = we're
not well qualified to do, and b) rank those requirements again= st those of
homenet and higher ed, which we arguably know much better.
I just may have gotten off on the wrong foot with this discussion, misu= nderstanding
the original point.=A0 If it was that enterprise customers = do not like excessive link-
local multicast, then I agree that one major= objective of this work is to decrease
reliance on it by e.g. introducing name caches and client libraries that un= icast
queries to them when possible.=A0 We can't eliminate all link-= local multicasting in
general, or a number of things stop working.
=A0
Those enterprises/IT-divisions are either gonna change (and we can help the= m),
or they will go the way of the mainframe operators.

--
] =A0 =A0 =A0 =A0 =A0 =A0 =A0 Never tell me the odds! =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | ipv6 mesh networks [
] =A0 Michael Richardson, Sandelman Software Works =A0 =A0 =A0 =A0| network= architect =A0[
] =A0 =A0 mcr@sandelman.ca =A0http://www.sandelman.ca/<= /a> =A0 =A0 =A0 =A0| =A0 ruby on rails =A0 =A0[


--047d7b3a7f84abb9fe04dee60f41-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CF821F96DF for ; Tue, 11 Jun 2013 10:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OzTjcJqCFWcZ for ; Tue, 11 Jun 2013 10:32:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 383DC21F962A for ; Tue, 11 Jun 2013 10:32:26 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B370820191; Tue, 11 Jun 2013 13:45:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 46C8963A8C; Tue, 11 Jun 2013 13:31:31 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 35123639DF; Tue, 11 Jun 2013 13:31:31 -0400 (EDT) From: Michael Richardson To: David Farmer In-Reply-To: <51B71517.4080700@umn.edu> References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <22635.1370439768@sandelman.ca> <51B63B07.5070802@umn.edu> <19621.1370909460@sandelman.ca> <51B71517.4080700@umn.edu> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "mdnsext@ietf.org" , Kerry Lynn Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 17:32:27 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "David" =3D=3D David Farmer writes: David> If you are saying the only solution a network operator has to co= ntrolling David> current mDNS traffic is black-holing it; Then we have to make wh= at ever the David> new solution is work in the presence of black-holing of David> current mDNS traffic,=20 David> including both registration and query of services. One of David> the use case What David said +5. Kerry, many **enterprises** do *not* have any mDNS traffic, because they won't let any non-IT person plug ANYTHING in.=20=20=20 Those enterprises/IT-divisions are either gonna change (and we can help the= m), or they will go the way of the mainframe operators. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUbde84qHRg3pndX9AQKcNAQAqFVutUAS9ahTUHuIxOtwvL+ITx+/W86j J2XhAuqtDlOaVDBbpzBATt6rCWsQazfy5bDNTAO60NRVGMCVUMuzFVU9jEKJCRnY tVWX1aUk12tEE/HDJk3px1T4C6WNJYD0q67B6wFhzjSxHq4dl+ZKWmaVl9pK5qNe WI7dZEuzL8k= =R6Ar -----END PGP SIGNATURE----- --=-=-=-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D5A21F9607 for ; Tue, 11 Jun 2013 08:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.598 X-Spam-Level: X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[AWL=3.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YLMdZ1m2kS7v for ; Tue, 11 Jun 2013 08:04:24 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.51]) by ietfa.amsl.com (Postfix) with ESMTP id 60F8C21F86FB for ; Tue, 11 Jun 2013 08:04:24 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_y9IfC11NyMSsmEgNipPWtg)" Received: from relay3.apple.com ([17.128.113.83]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MO800AOZHURSTE0@mail-out.apple.com> for mdnsext@ietf.org; Tue, 11 Jun 2013 08:04:03 -0700 (PDT) X-AuditID: 11807153-b7f3c6d000007b32-86-51b73c60e688 Received: from [17.153.48.156] (Unknown_Domain [17.153.48.156]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 08.6F.31538.16C37B15; Tue, 11 Jun 2013 08:04:02 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Tue, 11 Jun 2013 11:04:05 -0400 Message-id: References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <22635.1370439768@sandelman.ca> <7EDAF229-930C-428D-B7F7-F9C52E854033@apple.com> To: "Albrecht, Harald" X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUiONNgjm6SzfZAg66HEhZfT/5htzi55BST xZFvsQ7MHltP/mDzWLLkJ5PH9pOTmAKYo7hsUlJzMstSi/TtErgyVvW8Yio4vICx4tDExewN jHu7GLsYOTkkBEwktt3ZwgZhi0lcuLceyObiEBLoZZL49XMzWJGwgLXEyuMfwWxeAT2Jpf/m ANkcHMwCCRLrZ4SAhNkE1CR+T+pjBbE5BcIkdq24xw5iswioSvy/d4kFxGYW0JRY+n8t1Bgb iTmL9jJC7Gpkkfi3sAfsCBGQgy4/YAGZLyEgK7Hzd9IERr5ZSDbPQtg8C2yqtsSyha+ZIWwD iaedr1gxxfUl3rybw7SAkW0Vo0BRak5ipbFeYkFBTqpecn7uJkZQ2DYUBu9g/LPM6hCjAAej Eg/vAbPtgUKsiWXFlbmHGCU4mJVEeN9YAYV4UxIrq1KL8uOLSnNSiw8xSnOwKInzBldvCxQS SE8sSc1OTS1ILYLJMnFwSjUwiqjOX2dYnn0kI3wmq/ZP218WPv/YGdKao3tYF0pFrxPee/ex 4yUP5uP9ComSS4JZq4+kvFuy3Oipl9ivxOc/rI4+/NAx/ajoxItTspk3fmk9uIrtwpYfN7eL XFcynDHxZE7OageviIWCbFPNT/THGay+yyr4XuLWl6ur5nd9FEs52zB9WUXFZiWW4oxEQy3m ouJEAFxM3YlXAgAA Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 15:04:33 -0000 --Boundary_(ID_y9IfC11NyMSsmEgNipPWtg) Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: quoted-printable Albrecht, On 2013-06-11, at 8:08 AM, "Albrecht, Harald" = wrote: > Michael, > =20 > thank you very much for the clarification. What I see as a big = stumbling block in service discovery usage are such architectural issues = that can basically make a good idea unworkable, at least in some = environments. Do you have more information as to what Microsoft does? = =46rom reading their MSDN pages I could not get a clear picture whether = they are tripping into the same pit as the glibc does and I = unfortunately lack some knowledge in order to fully understand what=92s = going on in the mDNS resolver DLL. Can you provide some insight? =46rom MSDN [2]: On Windows 8 and Windows Server 2012, the getaddrinfo function provides = support for IRI or Internationalized Domain Name (IDN) parsing applied = to the name passed in the pNodeName parameter. Winsock performs = Punycode/IDN encoding and conversion. This behavior can be disabled = using the AI_DISABLE_IDN_ENCODING flag discussed below. On Windows 7 and Windows Server 2008 R2 or earlier, the getaddrinfo = function does not currently provide support for IRI or Internationalized = Domain Name (IDN) parsing applied to the name passed in thepNodeName = parameter. Winsock does not perform any Punycode/IDN conversion. The = wide character version of the GetAddrInfo function does not convert a = Unicode name to Punycode format as per RFC 3490. The wide character = version of the GetAddrInfo function when querying DNS encodes the = Unicode name in UTF-8 format, the format used by Microsoft DNS servers = in an enterprise environment. So for current Windows, applications automatically get the encoding = applied for traditional DNS unless they specify otherwise - basically = the "opt out" approach for applications that are written specifically to = do their own "DNS thing". And if I fully understand the Windows = namespace provider interface :) the mDNS provider will likely just get = the original, unencoded name and will be able to Do The Right Thing... = But I have to admit that I haven't tested this myself to see whether it = works for real on Windows 8 (it does on Windows 7 but then IDN isn't = supported directly on Windows 7...) ........ [2] = http://msdn.microsoft.com/en-us/library/windows/desktop/ms738520(v=3Dvs.85= ).aspx > =20 > My impression is that the face-to-face meeting in Berlin will surely = have some very interesting topics to discuss =96 or rather, where I hope = to learn more about so I don=92t put forward too many dumb questions. > =20 > -- Harald >=20 > Siemens AG > Industry Sector > Industry Automation Division > Industrial Automation Systems > I IA AS CTO DH 1 > Gleiwitzer Str. 555 > 90475 N=FCrnberg, Deutschland > Tel: +49 911 895-3847 > Fax: +49 911 895-2105 > mailto:harald.albrecht@siemens.com >=20 > Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard = Cromme; Vorstand: Peter L=F6scher, Vorsitzender; Roland Busch, Brigitte = Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, = Siegfried Russwurm, Peter Y. Solmssen, Michael S=FC=DF; Sitz der = Gesellschaft: Berlin und M=FCnchen, Deutschland; Registergericht: Berlin = Charlottenburg, HRB 12300, M=FCnchen, HRB 6684; WEEE-Reg.-Nr. DE = 23691322 > =20 > =20 > =20 > Von: Michael Sweet [mailto:msweet@apple.com]=20 > Gesendet: Dienstag, 11. Juni 2013 13:56 > An: Albrecht, Harald > Cc: mdnsext@ietf.org > Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF > =20 > Albrecht, > =20 > On 2013-06-11, at 5:08 AM, "Albrecht, Harald" = wrote: > ...=20 > My analysis bases on the GNU libc as one example, other = implementations may differ very well (and most probably will). Code base = is glib 2.17 as available from the FSF ftp servers. I tried to make sure = that I did not make any (gross) mistakes in my analysis. However, caveat = emptor, and if you find errors in my analysis please explain them to us = so I (and maybe others) can learn. > =20 > As a user of getaddrinfo, I know for sure that the AI_IDN flag is a = non-standard glibc extension. And IMHO it is a poorly thought-out = addition to the API - such decisions need to be made in the underlying = resolvers (all those plugins you can specify in /etc/nsswitch.conf for = "hosts") and not in the application which then needs to have a much = greater understanding of which DNS is being used, etc. The original = proposal [1] gives some background on the addition, but I personally = would not rely on the application asking the system to Do The Right = Thing (tm). > =20 > ........ > [1] http://www.gnu.org/software/libidn/getaddrinfo-idn.txt > =20 > _________________________________________________________ > Michael Sweet, Senior Printing System Engineer, PWG Chair > =20 > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_y9IfC11NyMSsmEgNipPWtg) Content-type: text/html; charset=windows-1252 Content-transfer-encoding: quoted-printable Albrecht,


So for = current Windows, applications automatically get the encoding applied for = traditional DNS unless they specify otherwise - basically the "opt out" = approach for applications that are written specifically to do their own = "DNS thing".  And if I fully understand the Windows namespace = provider interface :) the mDNS provider will likely just get the = original, unencoded name and will be able to Do The Right Thing... =  But I have to admit that I haven't tested this myself to see = whether it works for real on Windows 8 (it does on Windows 7 but then = IDN isn't supported directly on Windows = 7...)

........


My impression is that the face-to-face meeting in = Berlin will surely have some very interesting topics to discuss =96 or = rather, where I hope to learn more about so I don=92t put forward too = many dumb questions.
 
-- = Harald
... 
My analysis = bases on the GNU libc as one example, other implementations may differ = very well (and most probably will). Code base is glib 2.17 as available = from the FSF ftp servers. I tried to make sure that I did not make any = (gross) mistakes in my analysis. However, caveat emptor, and if you find = errors in my analysis please explain them to us so I (and maybe others) = can learn.
 
As a user of getaddrinfo, I know for sure that the = AI_IDN flag is a non-standard glibc extension.  And IMHO it is a = poorly thought-out addition to the API - such decisions need to be made = in the underlying resolvers (all those plugins you can specify in = /etc/nsswitch.conf for "hosts") and not in the application which then = needs to have a much greater understanding of which DNS is being used, = etc.  The original proposal [1] gives some background on the = addition, but I personally would not rely on the application asking the = system to Do The Right Thing (tm).
 
........
= --Boundary_(ID_y9IfC11NyMSsmEgNipPWtg)-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D72221F9926 for ; Tue, 11 Jun 2013 05:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k5ngmmvvGF7 for ; Tue, 11 Jun 2013 05:16:59 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 4822C21F9965 for ; Tue, 11 Jun 2013 05:16:27 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Tue, 11 Jun 2013 07:16:26 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-qc0-f174.google.com [209.85.216.174] #+LO+TR X-Umn-Classification: local Received: by mail-qc0-f174.google.com with SMTP id m15so3055903qcq.19 for ; Tue, 11 Jun 2013 05:16:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=MO2SfQ6aOZTi9eAwvVhcN20bvRlGU8KkTd4vb/H3wu4=; b=CKqTtPMiYqP7ENkQCI/kKPepjaTKTn79VTq6C1pEzg3t1aX1PXHg33lq3O/Gy6TP7G xUWMnfrLykLphHDBv+LYfFiauRYOoekvEn3KOO82aG87en4OVDyQvnR+4lg8Btx8KVNX L/2g1bo3gFcla/kanbqedXPOuOJ9EsM19Sf9DIqEVby1UmjbKL8TU5ECHs2br2UZlRNZ jS3G+4NDpuEj+pZ1TLkOjo0AjLbfcrwVR4/eF4JdiJnRwDpDPhHcafn1id1eQfjXbO36 /aC+lq1PXKN5MeJ3YOLJFi36lW1UJntTblsQxwC6a8mTGrr+vmQfAcytspz9YJZowb5V Ksuw== X-Received: by 10.229.168.70 with SMTP id t6mr5624276qcy.83.1370952986276; Tue, 11 Jun 2013 05:16:26 -0700 (PDT) X-Received: by 10.229.168.70 with SMTP id t6mr5624270qcy.83.1370952986198; Tue, 11 Jun 2013 05:16:26 -0700 (PDT) Received: from oit201651646.local ([2001:470:1f11:821:10f6:5d0e:e9ea:e87d]) by mx.google.com with ESMTPSA id c10sm19193255qag.2.2013.06.11.05.16.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Jun 2013 05:16:25 -0700 (PDT) Message-ID: <51B71517.4080700@umn.edu> Date: Tue, 11 Jun 2013 07:16:23 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kerry Lynn References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <22635.1370439768@sandelman.ca> <51B63B07.5070802@umn.edu> <19621.1370909460@sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm0rfuUi22wtv1sBsy6OnSOXUE5E455Ptehl+dv0vv5mNDPtCUk/pty6WfwKPhCDsG7I9jX+tjIPAHQTFQMgFZcqigyYqsQ+K9DxBxfB3AoKNcpZelxUn9fYN/pcm8JAD6pEs57 Cc: Michael Richardson , David Farmer , "mdnsext@ietf.org" Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 12:17:05 -0000 On 6/10/13 21:38 , Kerry Lynn wrote: > On Mon, Jun 10, 2013 at 8:11 PM, Michael Richardson > > wrote: .... > I'd put disabling existing functionality pretty far down the list of > priorities, since > the main problem seems to be how to make it work over a wider area, in more > cases. I think the list of use cases previously mentioned run the > spectrum from > no management/no external servers to (potentially) fully managed DNS. There > is also a spectrum of security concerns, and I will crank up a new > thread on that > topic tomorrow unless someone beats me to it. If you are saying the only solution a network operator has to controlling current mDNS traffic is black-holing it; Then we have to make what ever the new solution is work in the presence of black-holing of current mDNS traffic, including both registration and query of services. One of the use case requirements from the educause petition is a non-multicast solution or at least a greatly reduced multicast solution, for heavily congested Wifi networks as mentioned below. This is not the vision I would prefer, but I'm more interested in a workable solution than getting my way. > -K- > > There may also be situations where multicast is harmful (heavily > congested wifi, LLNs which do not implement whatever LLN friendly mDNS > we make). > > Blackholing multicast traffic may result in timeouts. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D7621F96C2 for ; Tue, 11 Jun 2013 05:08:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGtxnXwt01UV for ; Tue, 11 Jun 2013 05:08:22 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by ietfa.amsl.com (Postfix) with ESMTP id 5886621F96F7 for ; Tue, 11 Jun 2013 05:08:14 -0700 (PDT) Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.13.6/8.13.6) with ESMTP id r5BC8CIL003156 for ; Tue, 11 Jun 2013 14:08:12 +0200 Received: from DEFTHW99ET8MSX.ww902.siemens.net ([157.163.148.59]) by mail2.sbs.de (8.13.6/8.13.6) with ESMTP id r5BC8BBD001420 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 11 Jun 2013 14:08:12 +0200 Received: from DEFTHW99ERLMSX.ww902.siemens.net (139.22.70.136) by DEFTHW99ET8MSX.ww902.siemens.net (157.163.148.59) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 11 Jun 2013 14:08:11 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.134]) by DEFTHW99ERLMSX.ww902.siemens.net ([139.22.70.136]) with mapi id 14.02.0342.003; Tue, 11 Jun 2013 14:08:11 +0200 From: "Albrecht, Harald" To: "mdnsext@ietf.org" Thread-Topic: [mdnsext] Discussion of BoF during Berlin IETF Thread-Index: AQHOYSnHoLNfrYhO9UyyRiqKaj691Jkmr/9wgAnC/jCAAAG3AA== Date: Tue, 11 Jun 2013 12:08:10 +0000 Message-ID: References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <22635.1370439768@sandelman.ca> <7EDAF229-930C-428D-B7F7-F9C52E854033@apple.com> In-Reply-To: <7EDAF229-930C-428D-B7F7-F9C52E854033@apple.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.55] Content-Type: multipart/alternative; boundary="_000_E36F274013087B4EA05E08EB50375039020533DEFTHW99EK5MSXww9_" MIME-Version: 1.0 Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 12:08:28 -0000 --_000_E36F274013087B4EA05E08EB50375039020533DEFTHW99EK5MSXww9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Michael, thank you very much for the clarification. What I see as a big stumbling bl= ock in service discovery usage are such architectural issues that can basic= ally make a good idea unworkable, at least in some environments. Do you hav= e more information as to what Microsoft does? From reading their MSDN pages= I could not get a clear picture whether they are tripping into the same pi= t as the glibc does and I unfortunately lack some knowledge in order to ful= ly understand what's going on in the mDNS resolver DLL. Can you provide som= e insight? My impression is that the face-to-face meeting in Berlin will surely have s= ome very interesting topics to discuss - or rather, where I hope to learn m= ore about so I don't put forward too many dumb questions. -- Harald Siemens AG Industry Sector Industry Automation Division Industrial Automation Systems I IA AS CTO DH 1 Gleiwitzer Str. 555 90475 N=FCrnberg, Deutschland Tel: +49 911 895-3847 Fax: +49 911 895-2105 mailto:harald.albrecht@siemens.com Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme;= Vorstand: Peter L=F6scher, Vorsitzender; Roland Busch, Brigitte Ederer, Kl= aus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm= , Peter Y. Solmssen, Michael S=FC=DF; Sitz der Gesellschaft: Berlin und M= =FCnchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, M= =FCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322 Von: Michael Sweet [mailto:msweet@apple.com] Gesendet: Dienstag, 11. Juni 2013 13:56 An: Albrecht, Harald Cc: mdnsext@ietf.org Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF Albrecht, On 2013-06-11, at 5:08 AM, "Albrecht, Harald" > wrote: ... My analysis bases on the GNU libc as one example, other implementations may= differ very well (and most probably will). Code base is glib 2.17 as avail= able from the FSF ftp servers. I tried to make sure that I did not make any= (gross) mistakes in my analysis. However, caveat emptor, and if you find e= rrors in my analysis please explain them to us so I (and maybe others) can = learn. As a user of getaddrinfo, I know for sure that the AI_IDN flag is a non-sta= ndard glibc extension. And IMHO it is a poorly thought-out addition to the= API - such decisions need to be made in the underlying resolvers (all thos= e plugins you can specify in /etc/nsswitch.conf for "hosts") and not in the= application which then needs to have a much greater understanding of which= DNS is being used, etc. The original proposal [1] gives some background o= n the addition, but I personally would not rely on the application asking t= he system to Do The Right Thing (tm). ........ [1] http://www.gnu.org/software/libidn/getaddrinfo-idn.txt _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --_000_E36F274013087B4EA05E08EB50375039020533DEFTHW99EK5MSXww9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Michael,

 <= /p>

thank you = very much for the clarification. What I see as a big stumbling block in ser= vice discovery usage are such architectural issues that can basically make a good idea unworkable, at least in some environments. Do y= ou have more information as to what Microsoft does? From reading their MSDN= pages I could not get a clear picture whether they are tripping into the s= ame pit as the glibc does and I unfortunately lack some knowledge in order to fully understand what’= s going on in the mDNS resolver DLL. Can you provide some insight?

 = ;

My impress= ion is that the face-to-face meeting in Berlin will surely have some very i= nteresting topics to discuss – or rather, where I hope to learn more about so I don’t put forward too many dumb questions.

 = ;

-- Harald<= o:p>


Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
I IA AS CTO DH 1
Gleiwitzer Str. 555
90475 N=FCrnberg, Deutschland
Tel: +49 911 895-3847
Fax: +49 911 895-2105
mailto:harald.albrecht@sieme= ns.com

Siemens Aktiengesellschaft: Vorsitzender d= es Aufsichtsrats: Gerhard Cromme; Vorstand: Peter L=F6scher, Vorsitzender; = Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Mich= ael S=FC=DF; Sitz der Gesellschaft: Berlin und M=FCnchen, Deutschland; Regi= stergericht: Berlin Charlottenburg, HRB 12300, M=FCnchen, HRB 6684; WEEE-Re= g.-Nr. DE 23691322

 <= /p>

 <= /p>

 

Von: Michael S= weet [mailto:msweet@apple.com]
Gesendet: Dienstag, 11. Juni 2013 13:56
An: Albrecht, Harald
Cc: mdnsext@ietf.org
Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF

 

Albrecht,

 

On 2013-06-11, at 5:08 AM, "Albrecht, Harald&qu= ot; <harald.albrecht@siem= ens.com> wrote:

... 

My analysi= s bases on the GNU libc as one example, other implementations may differ ve= ry well (and most probably will). Code base is glib 2.17 as available from the FSF ftp servers. I tried to make sure that I did not ma= ke any (gross) mistakes in my analysis. However, caveat emptor, and if you = find errors in my analysis please explain them to us so I (and maybe others= ) can learn.

 

As a user of getaddrinfo, I know for sure that the A= I_IDN flag is a non-standard glibc extension.  And IMHO it is a poorly= thought-out addition to the API - such decisions need to be made in the un= derlying resolvers (all those plugins you can specify in /etc/nsswitch.conf for "hosts") and not in the ap= plication which then needs to have a much greater understanding of which DN= S is being used, etc.  The original proposal [1] gives some background= on the addition, but I personally would not rely on the application asking the system to Do The Right Thing (tm).

 

........

 

_____________________________________________= ____________
Michael Sweet, Senior Printing System Engineer, PWG Chair

 

--_000_E36F274013087B4EA05E08EB50375039020533DEFTHW99EK5MSXww9_-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1F421F9607 for ; Tue, 11 Jun 2013 04:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=4.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLgLG8ZbhBeL for ; Tue, 11 Jun 2013 04:56:13 -0700 (PDT) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 109A021F8EFE for ; Tue, 11 Jun 2013 04:56:12 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_criQg+O3ib9x9j4J3Mclcg)" Received: from relay6.apple.com ([17.128.113.90]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MO8002EW950VOS1@mail-out.apple.com> for mdnsext@ietf.org; Tue, 11 Jun 2013 04:55:55 -0700 (PDT) X-AuditID: 1180715a-b7f506d000007d18-65-51b71049c5c8 Received: from [17.153.48.48] (Unknown_Domain [17.153.48.48]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 57.BF.32024.A4017B15; Tue, 11 Jun 2013 04:55:55 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Tue, 11 Jun 2013 07:55:53 -0400 Message-id: <7EDAF229-930C-428D-B7F7-F9C52E854033@apple.com> References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <22635.1370439768@sandelman.ca> To: "Albrecht, Harald" X-Mailer: Apple Mail (2.1508) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUiONPAQNdbYHugwe8/YhZfT/5htzi55BST xZFvsQ7MHltP/mDzWLLkJ5PH9pOTmAKYo7hsUlJzMstSi/TtErgyNq/4wFJwUKdi59ndLA2M u9W6GDk5JARMJD4dmcIEYYtJXLi3nq2LkYtDSKCbSaL53mp2kISwgLXEyuMfGUFsXgE9iaX/ 5oDZzAIJEufu3mIBsdkE1CR+T+pjBbE5BcIktr25zgxiswioSkxoecsCUa8psfT/Wqg5NhJL G+4wQyxrY5bY+HQdWJEI0EXbLj8AsjmALpKV2Pk7aQIj3ywkq2chWQ1ha0ssW/iaGcLWk3jZ 9I4dU1xX4uK6SYwLGNlWMQoUpeYkVprpJRYU5KTqJefnbmIEhW1DYdQOxoblVocYBTgYlXh4 Of5vDRRiTSwrrsw9xCjBwawkwivJuD1QiDclsbIqtSg/vqg0J7X4EKM0B4uSOG9I9bZAIYH0 xJLU7NTUgtQimCwTB6dUA+O0P/8Oc32OOHZUSbNGQFmCj6P/SapnwEqZ3EBu01ea/S8jXAor vxxT+HFWttuq8b78V40IcbFO50rr+Va3/Djrnp/852nutOByUu5vrf6gSxPnuhkd0dw/oeX2 3JWvJB416ghIHPi1ZKpi2TIhpf+eBSq3eZLPLWJ0+aShYqJ66pJA053ln5VYijMSDbWYi4oT ARWl9e1XAgAA Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 11:56:20 -0000 --Boundary_(ID_criQg+O3ib9x9j4J3Mclcg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Albrecht, On 2013-06-11, at 5:08 AM, "Albrecht, Harald" wrote: > ... > My analysis bases on the GNU libc as one example, other implementations may differ very well (and most probably will). Code base is glib 2.17 as available from the FSF ftp servers. I tried to make sure that I did not make any (gross) mistakes in my analysis. However, caveat emptor, and if you find errors in my analysis please explain them to us so I (and maybe others) can learn. As a user of getaddrinfo, I know for sure that the AI_IDN flag is a non-standard glibc extension. And IMHO it is a poorly thought-out addition to the API - such decisions need to be made in the underlying resolvers (all those plugins you can specify in /etc/nsswitch.conf for "hosts") and not in the application which then needs to have a much greater understanding of which DNS is being used, etc. The original proposal [1] gives some background on the addition, but I personally would not rely on the application asking the system to Do The Right Thing (tm). ........ [1] http://www.gnu.org/software/libidn/getaddrinfo-idn.txt _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_criQg+O3ib9x9j4J3Mclcg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable Albrecht,



=
_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_criQg+O3ib9x9j4J3Mclcg)-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7051121F8481 for ; Tue, 11 Jun 2013 02:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZH0FNSEh6YW for ; Tue, 11 Jun 2013 02:09:00 -0700 (PDT) Received: from gecko.sbs.de (gecko.sbs.de [194.138.37.40]) by ietfa.amsl.com (Postfix) with ESMTP id 20CC521F89EB for ; Tue, 11 Jun 2013 02:08:53 -0700 (PDT) Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.13.6/8.13.6) with ESMTP id r5B98mVn012917 for ; Tue, 11 Jun 2013 11:08:49 +0200 Received: from DEFTHW99ET7MSX.ww902.siemens.net ([157.163.145.4]) by mail2.sbs.de (8.13.6/8.13.6) with ESMTP id r5B98mSV005517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 11 Jun 2013 11:08:48 +0200 Received: from DEFTHW99ER5MSX.ww902.siemens.net (139.22.70.77) by DEFTHW99ET7MSX.ww902.siemens.net (157.163.145.4) with Microsoft SMTP Server (TLS) id 8.3.298.1; Tue, 11 Jun 2013 11:08:47 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.134]) by DEFTHW99ER5MSX.ww902.siemens.net ([139.22.70.77]) with mapi id 14.02.0342.003; Tue, 11 Jun 2013 11:08:47 +0200 From: "Albrecht, Harald" To: "mdnsext@ietf.org" Thread-Topic: [mdnsext] Discussion of BoF during Berlin IETF Thread-Index: AQHOYSnHoLNfrYhO9UyyRiqKaj691Jkmr/9wgABRSACAA0/1AIAESRgA Date: Tue, 11 Jun 2013 09:08:47 +0000 Message-ID: References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <22635.1370439768@sandelman.ca> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.55] Content-Type: multipart/alternative; boundary="_000_E36F274013087B4EA05E08EB5037503901F483DEFTHW99EK5MSXww9_" MIME-Version: 1.0 Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 09:09:07 -0000 --_000_E36F274013087B4EA05E08EB5037503901F483DEFTHW99EK5MSXww9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Kerry, thank you for the clarification. Von: kerlyn2001@gmail.com [mailto:kerlyn2001@gmail.com] Im Auftrag von Kerr= y Lynn Gesendet: Freitag, 7. Juni 2013 18:18 An: Michael Richardson; Albrecht, Harald Cc: mdnsext@ietf.org Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF Albrecht> How true, that's where the devil is in the details. mDNS Albrecht> uses UTF-8 encoding on the wire and DNS uses (at least for Albrecht> host domain names) ASCII/IDNA-2008. Throw in different Albrecht> resolver libs and IDNA support and you are ready for an Albrecht> instant recipe disaster. I will still like someone to generate a very simple example that illustrate= s the difficulty so I can include it in the requirements draft. It is my underst= anding that the part of a DNS-SD name (i.e. the name of the SRV and TXT records) can be arbitrary Net-Unicode text [RFC5198] excluding the control = chars 0x00-0x1F and 0x7F. It is silent, so far as I can tell, on host names. It= may be that OS X allows UTF-8 host names, which subsequently occur in mDNS packets.. No problem ... at least I hope this example to be sufficient simple enough.= I'm illustrating the issue for name-address resolution and not service dis= covery, but the underlying issue is the same. It is just that name-address = resolution is more basic as we always need it and most people are more inte= rested in it as they see immediate use. My analysis bases on the GNU libc as one example, other implementations may= differ very well (and most probably will). Code base is glib 2.17 as avail= able from the FSF ftp servers. I tried to make sure that I did not make any= (gross) mistakes in my analysis. However, caveat emptor, and if you find e= rrors in my analysis please explain them to us so I (and maybe others) can = learn. The IDNA "theory" (at least to my understanding from reading the IDNA 2008 = RFCs, which are in my opinion very well written) is as follows: 1. a user enters some internationalized domain name, for instance through a= UI. Say, she enters "ship.fl=F8ts=E4m" (with a nod to Peter Gabriel). We d= on't care about the concrete encoding here, it may be UTF-16 for instance. 2. Feed this into getaddrinfo() - now, we need to use the AI_IDN flag here.= So what will happen inside getaddrinfo()? 3. We don't know at this point which specific resolver will resolve the giv= en "ship.fl=F8ts=E4m", but we have this AI_IDN flag! With glibc, getaddrinf= o() (in systeps/posix/getaddrinfo.c) somehow ends up in gaih_inet(), where = AI_IDN gets checked for. If it is set and a name present, then IDNA convers= ion takes place, where the given name in the current locale encoding gets t= ranslated into ACE: "ship.xn--fltsm-jra1l". 4. Only later comes the "hosts" lookup, that is, the call to __nss_database= _lookup ("hosts",...) where the dispatch to the DNS or mDNS resolver(s) ste= ps in. Unfortunately, we already have IDN invoked. So what has happened here? ACE (ASCII compatible encoding) gets always invo= ked if the caller specifies AI_IDN. However, if mDNS is later used for reso= lving this is not what should have been done: mDNS specifies immediate UTF-= 8 encoding and not ACE. However, for DNS we need ACE. So we end up in the u= nfortunate situation that the application has to know in advance what resol= ver will be used ... but it cannot, as the domain name given may be relativ= e. And yes, the RFCs also say that the DNS server search list is to be appl= ied only to DNS and not mDNS. But this still doesn't help us with the probl= em that the application has to know whether a domain name belongs to mDNS o= r not. At least according to my current (limited) understanding, something seems t= o be borked here... ;) Any enlightment is highly appreciated! With best regards, Harald Harald Albrecht Siemens AG Industry Sector Industry Automation Division Industrial Automation Systems I IA AS CTO DH 1 Gleiwitzer Str. 555 90475 N=FCrnberg, Deutschland Tel: +49 911 895-3847 Fax: +49 911 895-2105 mailto:harald.albrecht@siemens.com Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme;= Vorstand: Peter L=F6scher, Vorsitzender; Roland Busch, Brigitte Ederer, Kl= aus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm= , Peter Y. Solmssen, Michael S=FC=DF; Sitz der Gesellschaft: Berlin und M= =FCnchen, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, M= =FCnchen, HRB 6684; WEEE-Reg.-Nr. DE 23691322 --_000_E36F274013087B4EA05E08EB5037503901F483DEFTHW99EK5MSXww9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Kerry,<= /p>

 <= /p>

thank you = for the clarification.

 

Von: kerlyn200= 1@gmail.com [mailto:kerlyn2001@gmail.com] Im Auftrag von Kerry Lynn
Gesendet: Freitag, 7. Juni 2013 18:18
An: Michael Richardson; Albrecht, Harald
Cc: mdnsext@ietf.org
Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF

=     Albrecht> How true, that's where the devil is in the detai= ls. mDNS
    Albrecht> uses UTF-8 encoding on the wire and DNS uses (at= least for
    Albrecht> host domain names) ASCII/IDNA-2008. Throw= in different
    Albrecht> resolver libs and IDNA support and you are ready= for an
    Albrecht> instant recipe disaster.

I will still like someone to generate a very simple example that illustrate= s the
difficulty so I can include it in the requirements draft.  It is my un= derstanding
that the <Instance> part of a DNS-SD name (i.e. the name of the SRV a= nd TXT
records) can be arbitrary Net-Unicode text [RFC5198] excluding the control = chars
0x00-0x1F and 0x7F.  It is silent, so far as I can tell, on host names= .  It may be
that OS X allows UTF-8 host names, which subsequently occur in mDNS
packets..

 = ;

No problem= … at least I hope this example to be sufficient simple enough. IR= 17;m illustrating the issue for name-address resolution and not service discovery, but the underlying issue is the same. It is just that name-addr= ess resolution is more basic as we always need it and most people are more = interested in it as they see immediate use.

 = ;

My analysi= s bases on the GNU libc as one example, other implementations may differ ve= ry well (and most probably will). Code base is glib 2.17 as available from the FSF ftp servers. I tried to make sure that I did not ma= ke any (gross) mistakes in my analysis. However, caveat emptor, and if you = find errors in my analysis please explain them to us so I (and maybe others= ) can learn.

 = ;

The IDNA &= #8220;theory” (at least to my understanding from reading the IDNA 200= 8 RFCs, which are in my opinion very well written) is as follows:

1. a user = enters some internationalized domain name, for instance through a UI. Say, = she enters “ship.fl=F8ts=E4m“ (with a nod to Peter Gabriel). We don’t care about the concrete encoding here, it may be UTF-16 for in= stance.

2. Feed th= is into getaddrinfo() – now, we need to use the AI_IDN flag here. So = what will happen inside getaddrinfo()?

3. We don&= #8217;t know at this point which specific resolver will resolve the given &= #8220;ship.fl=F8ts=E4m“, but we have this AI_IDN flag! With glibc, ge= taddrinfo() (in systeps/posix/getaddrinfo.c) somehow ends up in gaih_inet(), where AI_= IDN gets checked for. If it is set and a name present, then IDNA conversion= takes place, where the given name in the current locale encoding gets tran= slated into ACE: “ship.xn--fltsm-jra1l”.

4. Only la= ter comes the “hosts” lookup, that is, the call to __nss_databa= se_lookup ("hosts",…) where the dispatch to the DNS or mDNS= resolver(s) steps in. Unfortunately, we already have IDN invoked.

 = ;

So what ha= s happened here? ACE (ASCII compatible encoding) gets always invoked if the= caller specifies AI_IDN. However, if mDNS is later used for resolving this is not what should have been done: mDNS specifies immediate= UTF-8 encoding and not ACE. However, for DNS we need ACE. So we end up in = the unfortunate situation that the application has to know in advance what = resolver will be used … but it cannot, as the domain name given may be relative. And yes, the RFCs also say that = the DNS server search list is to be applied only to DNS and not mDNS. But t= his still doesn’t help us with the problem that the application has t= o know whether a domain name belongs to mDNS or not.

 = ;

At least a= ccording to my current (limited) understanding, something seems to be borke= d here… ;) Any enlightment is highly appreciated!

 = ;

With best = regards,

Harald

 <= /p>

Harald Albrecht

Siemens AG
Industry Sector
Industry Automation Division
Industrial Automation Systems
I IA AS CTO DH 1
Gleiwitzer Str. 555
90475 N=FCrnberg, Deutschland
Tel: +49 911 895-3847
Fax: +49 911 895-2105
mailto:harald.albrecht@sieme= ns.com

Siemens Aktiengesellschaft: Vorsitzender d= es Aufsichtsrats: Gerhard Cromme; Vorstand: Peter L=F6scher, Vorsitzender; = Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Mich= ael S=FC=DF; Sitz der Gesellschaft: Berlin und M=FCnchen, Deutschland; Regi= stergericht: Berlin Charlottenburg, HRB 12300, M=FCnchen, HRB 6684; WEEE-Re= g.-Nr. DE 23691322

 <= /p>

 <= /p>

 <= /p>

--_000_E36F274013087B4EA05E08EB5037503901F483DEFTHW99EK5MSXww9_-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A461E21F8B51 for ; Mon, 10 Jun 2013 19:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.542 X-Spam-Level: X-Spam-Status: No, score=-1.542 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZpkC-GU2U0BW for ; Mon, 10 Jun 2013 19:38:57 -0700 (PDT) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4DACF21F8BC0 for ; Mon, 10 Jun 2013 19:38:57 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id wo10so11163234obc.3 for ; Mon, 10 Jun 2013 19:38:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=+5IYu+/eFU8FOyt0RHUEc/zFDQvYaadSqQc3CDXOCxY=; b=bcqmFfuYT54UOqibJquXmK/3Jphn6D7LN/mtc/+cM8SwjEvJyFS7WBt6qMe8xba15/ JpcWPQGnZ4q6aKHjToEvhoRh4CdF8bO6o4DSLW11n1OMRgNiE8uhTteRGfoPgxH4n5f+ SePifY4JlYkc6RFrak/nxvZxwJX3cJtYKG2cJazjjh7OgzCW+Mt/D09dk3H57nZ+pPaK dpKlhqXRIIazF95L5Gmta/8fa34JNNIDPCByFV6gYuf2nQnBq5k+aqZUfLYBEdGQkgUi hQXIwCiMmtijvlG2Ahbkb3ukUSNXVpmoQaPIkCWjR7meGGfoSJA/cMEpTjv12rgoe/qW qw6A== MIME-Version: 1.0 X-Received: by 10.60.141.2 with SMTP id rk2mr6162672oeb.69.1370918336046; Mon, 10 Jun 2013 19:38:56 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.148.197 with HTTP; Mon, 10 Jun 2013 19:38:55 -0700 (PDT) In-Reply-To: <19621.1370909460@sandelman.ca> References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <22635.1370439768@sandelman.ca> <51B63B07.5070802@umn.edu> <19621.1370909460@sandelman.ca> Date: Mon, 10 Jun 2013 22:38:55 -0400 X-Google-Sender-Auth: 8QusJaZW0zyS1W0J1QJq87E_-t0 Message-ID: From: Kerry Lynn To: Michael Richardson Content-Type: multipart/alternative; boundary=047d7b33c83a6ffdf304ded7cc3b Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 02:38:58 -0000 --047d7b33c83a6ffdf304ded7cc3b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 10, 2013 at 8:11 PM, Michael Richardson wrote: > > >>>>> "David" == David Farmer writes: > >> But, that doesn't prevent or clearly signal, that mDNS may be > >> *unwelcome* on a particular network. Enterprise folks might want > to do > >> that. I'm not claiming that they will, or should, succeed, btw. I'm > >> pointing out that we don't know what they want, because they don't > tend > >> to participate. > > David> While I wouldn't recommend general use of such a mode of > David> operation I do see > David> some special situations where I think it could be necessary, > David> even on my own > David> network, especially in networks or subnets with high security > David> requirements. > > Exactly (we are in violent agreement). > Or where having nodes "find" each other automatically is undesireable. > > The train has left the station. There are probably millions of deployed devices that already exhibit DNS-SD/mDNS behavior. How is Enterprise IT to thwart this existing behavior (e.g. probe and announce) except by black-holing mDNS traffic *at L2*? I guess you could hobble the OS somehow, but you're not going to selectively disable firmware in a printer. > Do you feel you can represent the Enterprise administrator? > Do we need to reach out some other place? > > I'd put disabling existing functionality pretty far down the list of priorities, since the main problem seems to be how to make it work over a wider area, in more cases. I think the list of use cases previously mentioned run the spectrum from no management/no external servers to (potentially) fully managed DNS. There is also a spectrum of security concerns, and I will crank up a new thread on that topic tomorrow unless someone beats me to it. -K- There may also be situations where multicast is harmful (heavily > congested wifi, LLNs which do not implement whatever LLN friendly mDNS > we make). > > Blackholing multicast traffic may result in timeouts. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > > > > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext > > --047d7b33c83a6ffdf304ded7cc3b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jun 10, 2013 at 8:11 PM, Michael Richardson <<= a href=3D"mailto:mcr+ietf@sandelman.ca" target=3D"_blank">mcr+ietf@sandelma= n.ca> wrote:

>>>>> "David" =3D=3D David Farmer <farmer@umn.edu> writes:
=A0 =A0 >> But, that doesn't prevent or clearly signal, that mDNS= may be
=A0 =A0 >> *unwelcome* on a particular network. =A0 Enterprise folks = might want to do
=A0 =A0 >> that. I'm not claiming that they will, or should, succ= eed, btw. =A0I'm
=A0 =A0 >> pointing out that we don't know what they want, becaus= e they don't tend
=A0 =A0 >> to participate.

=A0 =A0 David> While I wouldn't recommend general use of such = a mode of
=A0 =A0 David> operation I do see
=A0 =A0 David> some special situations where I think it could be necessa= ry,
=A0 =A0 David> even on my own
=A0 =A0 David> network, especially in networks or subnets with high secu= rity
=A0 =A0 David> requirements.

Exactly (we are in violent agreement).
Or where having nodes "find" each other automatically is undesire= able.

The train has left the station.=A0 There are probably= millions of deployed devices
that already exhibit DNS-SD/mDNS behavior.= =A0 How is Enterprise IT to thwart
this existing behavior (e.g. probe an= d announce) except by black-holing mDNS
traffic *at L2*?=A0 I guess you could hobble the OS somehow, but you're= not
going to selectively disable firmware in a printer.
=A0
Do you feel you can represent the Enterprise administrator?
Do we need to reach out some other place?

I'd put disabling existing functionality pretty f= ar down the list of priorities, since
the main problem seems to be how t= o make it work over a wider area, in more
cases.=A0 I think the list of = use cases previously mentioned run the spectrum from
no management/no external servers to (potentially) fully managed DNS.=A0 Th= ere
is also a spectrum of security concerns, and I will crank up a new t= hread on that
topic tomorrow unless someone beats me to it.

-K-
There may also be situations where multicast is harmful (heavily
congested wifi, LLNs which do not implement whatever LLN friendly mDNS
we make).

Blackholing multicast traffic may result in timeouts.

--
] =A0 =A0 =A0 =A0 =A0 =A0 =A0 Never tell me the odds! =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | ipv6 mesh networks [
] =A0 Michael Richardson, Sandelman Software Works =A0 =A0 =A0 =A0| network= architect =A0[
] =A0 =A0 mcr@sandelman.ca =A0http://www.sandelman.ca/<= /a> =A0 =A0 =A0 =A0| =A0 ruby on rails =A0 =A0[




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


--047d7b33c83a6ffdf304ded7cc3b-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CB621F9921 for ; Mon, 10 Jun 2013 17:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfAvPRIwi7s5 for ; Mon, 10 Jun 2013 17:11:56 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 24C3B21F98AD for ; Mon, 10 Jun 2013 17:11:55 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 904F12017A for ; Mon, 10 Jun 2013 20:25:08 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 01B7663A8C; Mon, 10 Jun 2013 20:11:00 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C89B9639DF for ; Mon, 10 Jun 2013 20:11:00 -0400 (EDT) From: Michael Richardson To: "mdnsext@ietf.org" In-Reply-To: <51B63B07.5070802@umn.edu> References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <22635.1370439768@sandelman.ca> <51B63B07.5070802@umn.edu> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 00:12:01 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "David" =3D=3D David Farmer writes: >> But, that doesn't prevent or clearly signal, that mDNS may be >> *unwelcome* on a particular network. Enterprise folks might want t= o do >> that. I'm not claiming that they will, or should, succeed, btw. I'm >> pointing out that we don't know what they want, because they don't t= end >> to participate. David> While I wouldn't recommend general use of such a mode of David> operation I do see=20 David> some special situations where I think it could be necessary, David> even on my own=20 David> network, especially in networks or subnets with high security David> requirements.=20 Exactly (we are in violent agreement). Or where having nodes "find" each other automatically is undesireable. Do you feel you can represent the Enterprise administrator? Do we need to reach out some other place?=20 There may also be situations where multicast is harmful (heavily congested wifi, LLNs which do not implement whatever LLN friendly mDNS we make). Blackholing multicast traffic may result in timeouts. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUbZrFIqHRg3pndX9AQKCqQP+PsLYzsS/DZSpUkfgy2J0EKz3NsSvx9c5 ZDR5RrSW8+0SxvZh3VopaSrimXchdmTmFdMlLjW91b9D34SZSalScBvVVDanAJV8 MjZDPg6/fRzOVpfug5mLO0JJmlW5Ke2Gb/+waeA186UDOZoaR1v3TSmjpUg/s/CF 56oqvtjHP9M= =FceE -----END PGP SIGNATURE----- --=-=-=-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D4E321F9408 for ; Mon, 10 Jun 2013 17:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vTG-Zr4CdSYa for ; Mon, 10 Jun 2013 17:03:21 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id E52E421F9A10 for ; Mon, 10 Jun 2013 17:03:19 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id A65D42017A; Mon, 10 Jun 2013 20:16:29 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 21CC063A8C; Mon, 10 Jun 2013 20:02:22 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 12DB7639DF; Mon, 10 Jun 2013 20:02:22 -0400 (EDT) From: Michael Richardson To: "Ralph Droms (rdroms)" In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA36EC431@xmb-aln-x04.cisco.com> References: <4518F39EB578034D8C99A9B7776CDBA36EC431@xmb-aln-x04.cisco.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] BoF request posted X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 00:03:27 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Why the name change? =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUbZpDYqHRg3pndX9AQLR2wP+JgonnLNJRHQuEu02RMZoQJkaxt7zcgoU sWVkOL3l2KKh1Tp4CC4RrBeLyGd0CGmdNVo6Xa+ixYuZI6XjL81yBPfEpGeQ76I1 WguzGK1Lt3D+a08V2p/I1oXoIQo6Dwe36Fhg6XkrpjBkqdEKtuD4nfeY9KFUm4gO IEx6tRyOHsY= =ZU3B -----END PGP SIGNATURE----- --=-=-=-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D39B21F9619 for ; Mon, 10 Jun 2013 16:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2Bvvg51NnH1 for ; Mon, 10 Jun 2013 16:24:34 -0700 (PDT) Received: from vs-a.tc.umn.edu (vs-a.tc.umn.edu [134.84.135.107]) by ietfa.amsl.com (Postfix) with ESMTP id 2791421F91BF for ; Mon, 10 Jun 2013 16:24:33 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by vs-a.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 10 Jun 2013 18:24:33 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ob0-f171.google.com [209.85.214.171] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f171.google.com with SMTP id dn14so10909222obc.2 for ; Mon, 10 Jun 2013 16:24:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=0rKqp9PgxAOZFjdvvnzOwhE1CQHCQVnSCdZ8FsA7IJg=; b=f7JUax06frzLKKUL5bG7t8h111gopAui8kvgqSzmrpzvNnzzLCM+V/4SFbOyoZjYF5 +qo2gAOifIE56TElOQAFq5bbQT40hX7L61/LUPwjjt01o9PZ9n81s1VHmLkLivVSWVaL gbz/YyPcNz4DGoys7BwrOz0Xtz9qCqaUtMvOqLX1gSpbZqKE16GnttMdX9BmJXStdyil uvtJv9SoQHAA2KUqehecJ4k4joAONLFW2d6UMb6NfNwQmweAszxHrndI5ce60i4DMAVY HInQ0+SnJbSkXhPhjdk7JS8I6naymViP0l2eR6AjDSBtGd1+KA+rZfet+Vk1FXfdKOpa 7SWQ== X-Received: by 10.60.92.230 with SMTP id cp6mr10113309oeb.91.1370906672792; Mon, 10 Jun 2013 16:24:32 -0700 (PDT) X-Received: by 10.60.92.230 with SMTP id cp6mr10113298oeb.91.1370906672709; Mon, 10 Jun 2013 16:24:32 -0700 (PDT) Received: from x-128-101-234-182.uofm-secure.wireless.umn.edu (x-128-101-234-182.uofm-secure.wireless.umn.edu. [128.101.234.182]) by mx.google.com with ESMTPSA id h4sm25591644oel.2.2013.06.10.16.24.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 16:24:32 -0700 (PDT) Message-ID: <51B6602E.3030203@umn.edu> Date: Mon, 10 Jun 2013 18:24:30 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Kerry Lynn References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <22635.1370439768@sandelman.ca> <51B63B07.5070802@umn.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk8N0qDSdZgSMyg6BUEPdR/4j0Q1UjMi5MZOA4de2aItp+iu8emsO2AmIsNcEOzTgUX4R3WBcDFgi1Hyp/m9lb979xhKjSESHkX4Qofm/EQPFaWYbPetIHdEb0Q+N5+zLS/0MJj Cc: David Farmer , "mdnsext@ietf.org" , "Albrecht, Harald" , Michael Richardson Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 23:24:40 -0000 On 6/10/13 17:28 , Kerry Lynn wrote: > On Mon, Jun 10, 2013 at 4:45 PM, David Farmer > wrote: > > On 6/5/13 08:42 , Michael Richardson wrote: > > But, that doesn't prevent or clearly signal, that mDNS may be > *unwelcome* on a particular network. Enterprise folks might > want to do > that. I'm not claiming that they will, or should, succeed, btw. I'm > pointing out that we don't know what they want, because they > don't tend > to participate. > > > While I wouldn't recommend general use of such a mode of operation I > do see some special situations where I think it could be necessary, > even on my own network, especially in networks or subnets with high > security requirements. > > More fundamentally, I would prefer to see a graceful mechanism to > achieve this policy, rather than requiring traffic filtering or > another blunt force mechanism to achieve such a policy. If someone > feels they need such a policy they will find a way. I believe it is > far better for the protocol to give them a way to achieve their > policy goals then to force them to use other possibly more drastic > mechanisms to achieve their policy goal. > > The policy goal being "black hole all FF02::FB traffic"? I would put it slightly differently, "not allowing multicast service discovery." One option could be to "black hole all FF02::FB" and 224.0.0.251 traffic. However, a mechanism designed into the protocol could be more graceful, allowing an appropriate error message to be returned to an application or user. Whereas, black holing all FF02::FB and 224.0.0.251 traffic wouldn't generally provide a useful error message, other than maybe a ICMP administratively not allowed. And, only if the filtering device is so kind as to actually return an ICMP message, which is kind of rare these days unfortunately. Most things that filter just black hole things these days, because "that is more secure", BAH!! Also, a mechanism designed into the protocol could allow more subtle policies like "allowing service discovery without allowing service registration" with something like the hybrid draft Stuart proposed, or "only allowing registration of certain type of services". -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A9D21F8443 for ; Mon, 10 Jun 2013 15:28:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODE8-3LH5-Pu for ; Mon, 10 Jun 2013 15:28:52 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 8E17521F842A for ; Mon, 10 Jun 2013 15:28:46 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id xk17so10856539obc.10 for ; Mon, 10 Jun 2013 15:28:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Y0/ntBfGUYsTjOGXEral1qPoI9V1yp97H8/9KOJqrpw=; b=eiS1dhiq5PeorrtyvN+NHdD0MwGKZhMZzBtrt7kle1sCuZZ6NWfn/lNTRRyUSBLuoR ykKO2NGqfveTZYHexXyo+zrPfP8UPB1ZPbWTu1RebIcAnH+Wwvz7xCsWgQieaGdWD1ji TqNc6zULxju2QVLD74YpzC8AEC9MWUQsKJgf3j3udlI+4WH9h9fOFNTtctpFNPN6hJJL K4Jd8iNlRcPLA3Mp5VBN3fUNNNu+4T5eRO9y8vXNE/SWcM8sUDcDiIHgrijF6QB00ZPJ nPtx3irRP8qhhY+DUVBI7WixBNwpVMkZ4EfVX9Hdz6h1hqtQL9wNrTtGkeVYTrDgBy6Y JFhw== MIME-Version: 1.0 X-Received: by 10.182.28.98 with SMTP id a2mr2952785obh.36.1370903326107; Mon, 10 Jun 2013 15:28:46 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.148.197 with HTTP; Mon, 10 Jun 2013 15:28:45 -0700 (PDT) In-Reply-To: <51B63B07.5070802@umn.edu> References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <22635.1370439768@sandelman.ca> <51B63B07.5070802@umn.edu> Date: Mon, 10 Jun 2013 18:28:45 -0400 X-Google-Sender-Auth: cChFk_NWDU91jYh0fBNwDT1-wR0 Message-ID: From: Kerry Lynn To: David Farmer Content-Type: multipart/alternative; boundary=089e0158adfec67b8604ded44d77 Cc: Michael Richardson , "Albrecht, Harald" , "mdnsext@ietf.org" Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 22:28:53 -0000 --089e0158adfec67b8604ded44d77 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 10, 2013 at 4:45 PM, David Farmer wrote: > On 6/5/13 08:42 , Michael Richardson wrote: > > But, that doesn't prevent or clearly signal, that mDNS may be >> *unwelcome* on a particular network. Enterprise folks might want to do >> that. I'm not claiming that they will, or should, succeed, btw. I'm >> pointing out that we don't know what they want, because they don't tend >> to participate. >> > > While I wouldn't recommend general use of such a mode of operation I do > see some special situations where I think it could be necessary, even on my > own network, especially in networks or subnets with high security > requirements. > > More fundamentally, I would prefer to see a graceful mechanism to achieve > this policy, rather than requiring traffic filtering or another blunt force > mechanism to achieve such a policy. If someone feels they need such a > policy they will find a way. I believe it is far better for the protocol > to give them a way to achieve their policy goals then to force them to use > other possibly more drastic mechanisms to achieve their policy goal. > > The policy goal being "black hole all FF02::FB traffic"? -K- > > -- > ==============================**================== > David Farmer Email: farmer@umn.edu > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 1-612-626-0815 > Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 > ==============================**================== > > ______________________________**_________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/**listinfo/mdnsext > --089e0158adfec67b8604ded44d77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jun 10, 2013 at 4:45 PM, David Farmer <farmer@umn.edu> = wrote:
On 6/5/13 08:42 , Michael Richardson wrote:

But, that doesn't prevent or clearly signal, that mDNS may be
*unwelcome* on a particular network. =A0 Enterprise folks might want to do<= br> that. I'm not claiming that they will, or should, succeed, btw. =A0I= 9;m
pointing out that we don't know what they want, because they don't = tend
to participate.

While I wouldn't recommend general use of such a mode of operation I do= see some special situations where I think it could be necessary, even on m= y own network, especially in networks or subnets with high security require= ments.

More fundamentally, I would prefer to see a graceful mechanism to achieve t= his policy, rather than requiring traffic filtering or another blunt force = mechanism to achieve such a policy. =A0If someone feels they need such a po= licy they will find a way. =A0I believe it is far better for the protocol t= o give them a way to achieve their policy goals then to force them to use o= ther possibly more drastic mechanisms to achieve their policy goal.

The policy goal being "black hole = all FF02::FB traffic"?

-K-

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D
David Farmer =A0 =A0 =A0 =A0 =A0 =A0 =A0 Email: farmer@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE =A0 =A0 Phone: 1-612-626-0815
Minneapolis, MN 55414-3029 =A0Cell: 1-612-812-9952
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D

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

--089e0158adfec67b8604ded44d77-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0837C21F922A for ; Mon, 10 Jun 2013 13:46:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KaYkJVmxIvCU for ; Mon, 10 Jun 2013 13:46:02 -0700 (PDT) Received: from vs-w.tc.umn.edu (vs-w.tc.umn.edu [134.84.135.88]) by ietfa.amsl.com (Postfix) with ESMTP id 20DEE21F9A3B for ; Mon, 10 Jun 2013 13:46:02 -0700 (PDT) Received: from mail-ob0-f178.google.com (mail-ob0-f178.google.com [209.85.214.178]) by vs-w.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 10 Jun 2013 15:45:57 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ob0-f178.google.com [209.85.214.178] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f178.google.com with SMTP id fb19so10797860obc.9 for ; Mon, 10 Jun 2013 13:45:57 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=WQ1/lcYt+Zmb60CA8torNqOH8NSWqFK42UnI8LJDJ0I=; b=cWCLcr7IGH0eDq8nt8HjgdPpVxRpxzrszqxhuvCC/iqjQh2WjuJ65J5DGY5lqkBCDg AWPim2HSMlDi0nf2qm5SVbp2lYPxvSVQ6GeyDpnCV1MTfr7tIrEVDwfOU9Rd1RQr6ixi JFBdcePdbPZmnc1tBGQ5GviFlI8UY4PtPrgdH0mjG0BJsWHGAHUrHbMdPh1PjVxzS6Je IXckTZFgXtAzfAKuU72legEe9sz2hozjpMLOphK7Mszj9k9xvYIIBMTCQeB2exWoR1+J xRAlPME8e3rOYhXwnczbMF0R1s4Zm7s9rhr2TEsla5cz4gzrxrvrCHVrMWaPMigangyj ljJQ== X-Received: by 10.182.129.101 with SMTP id nv5mr9414608obb.56.1370897157173; Mon, 10 Jun 2013 13:45:57 -0700 (PDT) X-Received: by 10.182.129.101 with SMTP id nv5mr9414600obb.56.1370897157088; Mon, 10 Jun 2013 13:45:57 -0700 (PDT) Received: from x-128-101-234-182.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:50cf:17d3:c8d9:efee]) by mx.google.com with ESMTPSA id w7sm24230952obx.9.2013.06.10.13.45.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 13:45:56 -0700 (PDT) Message-ID: <51B63B07.5070802@umn.edu> Date: Mon, 10 Jun 2013 15:45:59 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Michael Richardson References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <22635.1370439768@sandelman.ca> In-Reply-To: <22635.1370439768@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk0B6QkJ0zcP8SLdm+QTOgSBECPupR9u/odHISThL+Q0ULYbwAnDiRMZe4fdLoMRZxIp2cGSSIttSPzfX+A3/LhWWXuHERWuiFhb6ZuawLDO2t/itX8m48++CHXxG1siWZT7d6S Cc: "mdnsext@ietf.org" , "Albrecht, Harald" , David Farmer Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:46:08 -0000 On 6/5/13 08:42 , Michael Richardson wrote: > But, that doesn't prevent or clearly signal, that mDNS may be > *unwelcome* on a particular network. Enterprise folks might want to do > that. I'm not claiming that they will, or should, succeed, btw. I'm > pointing out that we don't know what they want, because they don't tend > to participate. While I wouldn't recommend general use of such a mode of operation I do see some special situations where I think it could be necessary, even on my own network, especially in networks or subnets with high security requirements. More fundamentally, I would prefer to see a graceful mechanism to achieve this policy, rather than requiring traffic filtering or another blunt force mechanism to achieve such a policy. If someone feels they need such a policy they will find a way. I believe it is far better for the protocol to give them a way to achieve their policy goals then to force them to use other possibly more drastic mechanisms to achieve their policy goal. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB45A21F9A47 for ; Mon, 10 Jun 2013 13:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMpnEoIXwbNr for ; Mon, 10 Jun 2013 13:31:51 -0700 (PDT) Received: from vs-m.tc.umn.edu (vs-m.tc.umn.edu [134.84.135.97]) by ietfa.amsl.com (Postfix) with ESMTP id EB61921F826B for ; Mon, 10 Jun 2013 13:31:50 -0700 (PDT) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by vs-m.tc.umn.edu (UMN smtpd) with ESMTP for ; Mon, 10 Jun 2013 15:31:50 -0500 (CDT) X-Umn-Remote-Mta: [N] mail-ob0-f177.google.com [209.85.214.177] #+LO+TR X-Umn-Classification: local Received: by mail-ob0-f177.google.com with SMTP id ta17so10523541obb.22 for ; Mon, 10 Jun 2013 13:31:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=zFQu8o4GoTkF7ZGnjUvTbagcCRa08tNWdO/Kxr0Xdq0=; b=law7546Y05w4eHZFUgy13KQV3Qio8GJn4zRBKs5OcGqihv/mqna6wzWLGSrMsrZYeE bbMzW4FF6/36VShuZh2jRi1nJaRvffirjkgsw6aS59jESSkev6gFP+OHoAZNeFfbxu38 0tLe1Hihql/iwSMUDmpVxPYnjxB8rJPEggaC0TWiDLrl+ngaXDBTVf6QpoNAzx/3UICX MefVqQ6WlWFJvgONceePYyouKmvbVnfNI+FSaQBWp6aNwxDnAd7SX41ym+qv5JUMO2Py 7Xn9BPTsYkEUVNRazqAxe/T+6zVqCit3THHr1VPtyByuO4Cf4zCG69MvuLF3Sz9CRd6U QI9w== X-Received: by 10.60.94.70 with SMTP id da6mr9596344oeb.63.1370896309769; Mon, 10 Jun 2013 13:31:49 -0700 (PDT) X-Received: by 10.60.94.70 with SMTP id da6mr9596340oeb.63.1370896309681; Mon, 10 Jun 2013 13:31:49 -0700 (PDT) Received: from x-128-101-234-182.uofm-secure.wireless.umn.edu ([2607:ea00:104:2000:50cf:17d3:c8d9:efee]) by mx.google.com with ESMTPSA id c10sm24605316oej.1.2013.06.10.13.31.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Jun 2013 13:31:49 -0700 (PDT) Message-ID: <51B637B8.8000808@umn.edu> Date: Mon, 10 Jun 2013 15:31:52 -0500 From: David Farmer Organization: University of Minnesota User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Ralph Droms (rdroms)" References: <4518F39EB578034D8C99A9B7776CDBA36EC431@xmb-aln-x04.cisco.com> In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA36EC431@xmb-aln-x04.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl//CD1v4VICRdiNciojdmiPoEdXw7VOQ2/DhlREXj9/M00suU/ETJQJlqHeYdpwUinTuVD0JE1gG2JoYcfw5xrL8nPZKgHkPzy9iSJx6W58eSe4h3uqNaNmBuH699oKZtoVVmO Cc: "mdnsext@ietf.org" , David Farmer Subject: Re: [mdnsext] BoF request posted X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: David Farmer List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 20:31:55 -0000 On 6/10/13 14:33 , Ralph Droms (rdroms) wrote: > I've posted the sdnssd BoF request here: http://trac.tools.ietf.org/bof/trac/wiki/WikiStart > > Review and comments (even as simple as "looks OK") encouraged. > > - Ralph > > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext > Minor nit; Substute "sdnssd WG" for "mdsnext WG" toward the end of the following paragraph; It is important that the sdnssd WG takes input from stakeholders in the scenarios it is considering. For example, the homenet WG is currently evaluating its own requirements for naming and service discovery; it is up to the homenet WG as to whether it wishes to recommend adoption of the solution developed in the mdsnext WG, and thus coordination between the WGs is desirable. More substantial; Should there be any consideration of promoting inter-operation of the "early solutions" you refer to, in the goals or milestones, maybe as an operational BCP on the subject. I'm more than a little worried about a mdns/sd-dns loop, or some kind of registration race condition causing duplicate names, being created by use of multiple of these "early solutions" in the same network. -- ================================================ David Farmer Email: farmer@umn.edu Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 1-612-626-0815 Minneapolis, MN 55414-3029 Cell: 1-612-812-9952 ================================================ Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D566621F93D4 for ; Mon, 10 Jun 2013 12:43:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMh3Co5t+tzx for ; Mon, 10 Jun 2013 12:43:38 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 5FB0321F93D2 for ; Mon, 10 Jun 2013 12:43:38 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id ef5so10730474obb.15 for ; Mon, 10 Jun 2013 12:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=sNuSRRwkUHwaxxVabl+YZLeLtaTLtBi/8789z6XvS10=; b=ChGv0sWdmqAs6DTYiCky6mOE5wJm9RTGrSfFQKMOWy/6qCQYwxA/6cghiEq43w/IGs QEu6BQtdNeWuM/AWEnjhq4LF9E/JSbmqtW5s46qwGbY+YjRuxx4yibQvK19adeKGxZQ3 mAOXrQafp+eiOOo6LoET6oyyoHEB439qdjV6N4Ffc5LolPDWmacThGp25hsIi5EzQzLl In0VYKzxGTz9CgtXA9sN0E/K9Cq0IYoKs5wc97C2wxJq2pQJMO0N1gYOkA8eCarJGruC fPtEIVcdd0WTaT44uqR9WnOTw1b7K9+5PamDayWGWg92lvs/qYvhmPw8WZtZ59pqtE8D VO/w== MIME-Version: 1.0 X-Received: by 10.60.145.143 with SMTP id su15mr9314343oeb.65.1370893417817; Mon, 10 Jun 2013 12:43:37 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.148.197 with HTTP; Mon, 10 Jun 2013 12:43:37 -0700 (PDT) In-Reply-To: <4518F39EB578034D8C99A9B7776CDBA36EC431@xmb-aln-x04.cisco.com> References: <4518F39EB578034D8C99A9B7776CDBA36EC431@xmb-aln-x04.cisco.com> Date: Mon, 10 Jun 2013 15:43:37 -0400 X-Google-Sender-Auth: 1xJhzFZznZ6kusY8SaHOPost9xo Message-ID: From: Kerry Lynn To: "Ralph Droms (rdroms)" Content-Type: multipart/alternative; boundary=047d7b5d488231fa6604ded1ff51 Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] BoF request posted X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 19:43:38 -0000 --047d7b5d488231fa6604ded1ff51 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 10, 2013 at 3:33 PM, Ralph Droms (rdroms) wrote: > I've posted the sdnssd BoF request here: > http://trac.tools.ietf.org/bof/trac/wiki/WikiStart > > Review and comments (even as simple as "looks OK") encouraged. > > Looks good to me. -K- > - Ralph > > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext > --047d7b5d488231fa6604ded1ff51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jun 10, 2013 at 3:33 PM, Ralph Droms (rdroms) <= ;rdroms@cisco.com= > wrote:
I've posted the sdnssd BoF request here: http://trac.tools.ietf.o= rg/bof/trac/wiki/WikiStart

Review and comments (even as simple as "looks OK") encouraged.
Looks good to me.

-K-
=A0
- Ralph

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

--047d7b5d488231fa6604ded1ff51-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3430621F9AD2 for ; Mon, 10 Jun 2013 12:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EPENmnFgDUnr for ; Mon, 10 Jun 2013 12:33:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC5121F9AD3 for ; Mon, 10 Jun 2013 12:33:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=173; q=dns/txt; s=iport; t=1370892787; x=1372102387; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=NTm/dETO6rK/QbKHn4jWCrr9kZywkHDQySHB7kBBG+w=; b=QO+8gaknrj89ZKdx0ZDHu5yEjoAoLW2//Pdvj/nFT/NF88PQYFLxwdU9 6cyAzM+/q/t5eJ1yMwevBrW7nJpyrGPybBxHoS3WD2pe4802EiOnoUzke JhS/+NjH+dWkKoASmVHzcrVPWFaiXDCtGMsg2usrFlLUm8E//I+q/5j5i s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoMAOwotlGtJXG//2dsb2JhbABZgwkwSYItvBIEAYEFFm0HgiUBBDpRASoUQicEG4gFDJkEoE+OJmGDN2EDmGmQGYMPgic X-IronPort-AV: E=Sophos;i="4.87,839,1363132800"; d="scan'208";a="221016114" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 10 Jun 2013 19:33:07 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5AJX6m5004930 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 10 Jun 2013 19:33:06 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.232]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Mon, 10 Jun 2013 14:33:06 -0500 From: "Ralph Droms (rdroms)" To: "mdnsext@ietf.org" Thread-Topic: BoF request posted Thread-Index: AQHOZhFUterGGPYebU+Sgp5NujsNqQ== Date: Mon, 10 Jun 2013 19:33:05 +0000 Message-ID: <4518F39EB578034D8C99A9B7776CDBA36EC431@xmb-aln-x04.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.164.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 10 Jun 2013 12:39:49 -0700 Subject: [mdnsext] BoF request posted X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 19:33:12 -0000 I've posted the sdnssd BoF request here: http://trac.tools.ietf.org/bof/tra= c/wiki/WikiStart Review and comments (even as simple as "looks OK") encouraged. - Ralph Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA91821F86D5 for ; Fri, 7 Jun 2013 09:17:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ilSmr5CPbQl for ; Fri, 7 Jun 2013 09:17:50 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3ED21F92B7 for ; Fri, 7 Jun 2013 09:17:47 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so6773751obc.20 for ; Fri, 07 Jun 2013 09:17:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VDd/zWhB35l+yJUjYwPwRUQp3kJYUCfDyF7KSq2GcCI=; b=oJkLuiUBlzM/D7dY4nPZzRWFhQwTa+pnpzcM6PNW83NLFfrfiwL/AswPggSso/3XWO hbYde8oHCl2Uu+UyzcvkgM8VBwiuUSXcMo6U9oXNRO47LTmXGlafi00sZb0czPCLQsZU JLMFDjISqZ2usVdX4TsBSKxKbTp+A4qbWBsiEmQs4meqVGdeefyU52EArvBWGXAtNyru KlddeT277x0B45e3IRSTwpSh4ULQyniQZVjFw5l5vfVj8iXQNx96XEwwAcruYC46LVpy AGEzCc/oeHUldA/sqzsyYgqYySTfYdDQrhDPBJOp8cr1E/Df83DOsJbo9ysca2VFtr6r n/Rg== MIME-Version: 1.0 X-Received: by 10.182.148.100 with SMTP id tr4mr2335272obb.53.1370621866938; Fri, 07 Jun 2013 09:17:46 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.148.197 with HTTP; Fri, 7 Jun 2013 09:17:46 -0700 (PDT) In-Reply-To: <22635.1370439768@sandelman.ca> References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> <22635.1370439768@sandelman.ca> Date: Fri, 7 Jun 2013 12:17:46 -0400 X-Google-Sender-Auth: TzElPe34fP_LGkm-5jr1DPEjndc Message-ID: From: Kerry Lynn To: Michael Richardson , "Albrecht, Harald" Content-Type: multipart/alternative; boundary=089e0122ac808065ba04de92c53b Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 16:17:52 -0000 --089e0122ac808065ba04de92c53b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 5, 2013 at 9:42 AM, Michael Richardson w= rote: > > >>>>> "Albrecht," =3D=3D Albrecht, Harald > writes: > >> -----Urspr=FCngliche Nachricht----- > >> Von: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] Im > >> Auftrag von Michael Richardson > >> Gesendet: Dienstag, 4. Juni 2013 15:46 > >> An: mdnsext@ietf.org > >> Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF > > >> I think that they are very different, and I think that we need to > leave the > >> door open to that commercial enterprise networks might be ruled ou= t > of > >> bounds for mDNS. That is, it might be that all that we wind up > with is a way > >> to signal that mDNS is *not* to be used on a particular > >> network. I do not believe that we have many operators of such > networks > >> at IETF meetings to represent their point of view. (I think about > the > >> operators of the government networks near me... they have many > >> conflicting requirements, but few clues as to how to put them > together) > > Albrecht> My understanding of the ongoing discussion so far is, that > Albrecht> the charter is not focusing solely on mDNS as the > Albrecht> underlying technology only, but with a somewhat broader > Albrecht> scope of service discovery; thus, also including DNS for > Albrecht> those scenarios (use cases) where an IT infrastructure is > Albrecht> present. At least to some extent. My impression was that > Albrecht> the (pending?) renaming of the upcoming WG reflects this > Albrecht> situation. Or did I misunderstand this? > > Your understanding is correct. > Yes, it's true that going to infrastructure DNS is useful. > > But, that doesn't prevent or clearly signal, that mDNS may be > *unwelcome* on a particular network. Enterprise folks might want to do > that. I'm not claiming that they will, or should, succeed, btw. I'm > pointing out that we don't know what they want, because they don't tend > to participate. > > One critical idea that I want to interject is that the list of use cases presented in the requirements draft (which Michael transcribed in an earlier message on this thread) was a *delta* beyond what is currently provided by mDNS. The next version will point out that the base case for mDNS is still valid. (I refer to the limiting case as the "one laptop, on printer" scenario. Substitute "one bulb, one switch" or whatever you like.) The point is that mDNS functionality as described in RFCs 6763/6762 isn't going away anytime soon (if ever) and is therefore available to be leveraged by sdnssd work. We will certainly try to limit the multicast traffic in some of the more advanced use cases - e.g= . perhaps to locate a DNS-SD server. On naming the WG, I think "sdnssd" contains the critical ideas of the proposed charter, that we're focused on a) using DNS for service discovery - not uPNP, HTTP, or other method, and b) that we're interested in a relatively scalabl= e user experience from the one laptop, one printer scenario through fully managed DNS. With respect to adding "autonomous" to the mix, to me that implies "without user intervention". I think this might be possible for some use cases, e.g. multi-link residential deployments with no externally visible services. But as we get into the more advanced use cases (e.g. university networks) these will require policy or security administration. We can certainly strive to limit the amount of admin necessary, but I think having "autonomous" in the WG name is potentially as confusing as having "multicast" there. >> It's not that mDNS and global > >> DNS *services* or even protocols have difficulties co-existing. > They do > >> that just fine. It is a question of them *interacting*. The pla= ce > >> where they interact is on the *host*. > > Albrecht> How true, that's where the devil is in the details. mDNS > Albrecht> uses UTF-8 encoding on the wire and DNS uses (at least for > Albrecht> host domain names) ASCII/IDNA-2008. Throw in different > Albrecht> resolver libs and IDNA support and you are ready for an > Albrecht> instant recipe disaster. > > I will still like someone to generate a very simple example that illustrates the difficulty so I can include it in the requirements draft. It is my understanding that the part of a DNS-SD name (i.e. the name of the SRV and TXT records) can be arbitrary Net-Unicode text [RFC5198] excluding the control chars 0x00-0x1F and 0x7F. It is silent, so far as I can tell, on host names. It may be that OS X allows UTF-8 host names, which subsequently occur in mDNS packets... -K- It might be that some vendor find they have to greenfield things. > My preference would be to stub out the libc stub resolver, and force all > resolution to 127.0.0.1 (::1), and do all the rest. That's already the > case for some systems, but it has failed to become an architectural norm. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext > > --089e0122ac808065ba04de92c53b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 5, 2013 at 9:42 AM, Michael Richardson <mcr+ietf@sandelman= .ca> wrote:

>>>>> "Albrecht," =3D=3D Albrecht, Harald <harald.albrecht@siemens.com&= gt; writes:
=A0 =A0 >> -----Urspr=FCngliche Nachricht-----
=A0 =A0 >> Von: mdnsext-b= ounces@ietf.org [mailto:mdn= sext-bounces@ietf.org] Im
=A0 =A0 >> Auftrag von Michael Richardson
=A0 =A0 >> Gesendet: Dienstag, 4. Juni 2013 15:46
=A0 =A0 >> An: mdnsext@ietf.org
=A0 =A0 >> Betreff: Re: [mdnsext] Discussion of BoF during Berlin IET= F

=A0 =A0 >> I think that they are very different, and I think that we = need to leave the
=A0 =A0 >> door open to that commercial enterprise networks might be = ruled out of
=A0 =A0 >> bounds for mDNS. =A0That is, it might be that all that we = wind up with is a way
=A0 =A0 >> to signal that mDNS is *not* to be used on a particular =A0 =A0 >> network. =A0 I do not believe that we have many operators = of such networks
=A0 =A0 >> at IETF meetings to represent their point of view. =A0(I t= hink about the
=A0 =A0 >> operators of the government networks near me... they have = many
=A0 =A0 >> conflicting requirements, but few clues as to how to put t= hem together)

=A0 =A0 Albrecht> My understanding of the ongoing discussion so fa= r is, that
=A0 =A0 Albrecht> the charter is not focusing solely on mDNS as the
=A0 =A0 Albrecht> underlying technology only, but with a somewhat broade= r
=A0 =A0 Albrecht> scope of service discovery; thus, also including DNS f= or
=A0 =A0 Albrecht> those scenarios (use cases) where an IT infrastructure= is
=A0 =A0 Albrecht> present. At least to some extent. My impression was th= at
=A0 =A0 Albrecht> the (pending?) renaming of the upcoming WG reflects th= is
=A0 =A0 Albrecht> situation. Or did I misunderstand this?

Yes, it's true that going to infrastructure DNS is useful.

But, that doesn't prevent or clearly signal, that mDNS may be
*unwelcome* on a particular network. =A0 Enterprise folks might want to do<= br> that. I'm not claiming that they will, or should, succeed, btw. =A0I= 9;m
pointing out that we don't know what they want, because they don't = tend
to participate.

One critical idea that I want= to interject is that the list of use cases presented
in the requirement= s draft (which Michael transcribed in an earlier message on
this thread)= was a *delta* beyond what is currently provided by mDNS.=A0 The
next version will point out that the base case for mDNS is still valid.=A0 = (I refer
to the limiting case as the "one laptop, on printer" = scenario.=A0 Substitute "one
bulb, one switch" or whatever you= like.)=A0 The point is that mDNS functionality
as described in RFCs 6763/6762 isn't going away anytime soon (if ever) = and
is therefore available to be leveraged by sdnssd work.=A0 We will ce= rtainly try
to limit the multicast traffic in some of the more advanced = use cases - e.g.
perhaps to locate a DNS-SD server.

On naming the WG, I think "s= dnssd" contains the critical ideas of the proposed
charter, that we= 're focused on a) using DNS for service discovery - not uPNP,
HTTP, = or other method, and b) that we're interested in a relatively scalable<= br> user experience from the one laptop, one printer scenario through fully man= aged
DNS.=A0 With respect to adding "autonomous" to the mix, t= o me that implies
"without user intervention".=A0 I think this= might be possible for some use cases,
e.g. multi-link residential deployments with no externally visible services= .=A0 But
as we get into the more advanced use cases (e.g. university net= works) these
will require policy or security administration.=A0 We can c= ertainly strive to limit
the amount of admin necessary, but I think having "autonomous" in= the WG
name is potentially as confusing as having "multicast"= there.

=A0 =A0 >> It's not that mDNS and global
=A0 =A0 >> DNS *services* or even protocols have difficulties co-exis= ting. =A0They do
=A0 =A0 >> that just fine. =A0 It is a question of them *interacting*= . =A0The place
=A0 =A0 >> where they interact is on the *host*.

=A0 =A0 Albrecht> How true, that's where the devil is in the d= etails. mDNS
=A0 =A0 Albrecht> uses UTF-8 encoding on the wire and DNS uses (at least= for
=A0 =A0 Albrecht> host domain names) ASCII/IDNA-2008. Throw in different=
=A0 =A0 Albrecht> resolver libs and IDNA support and you are ready for a= n
=A0 =A0 Albrecht> instant recipe disaster.

I will still like someone to generate a very simple e= xample that illustrates the
difficulty so I can include it in the requir= ements draft.=A0 It is my understanding
that the <Instance> part o= f a DNS-SD name (i.e. the name of the SRV and TXT
records) can be arbitrary Net-Unicode text [RFC5198] excluding the control = chars
0x00-0x1F and 0x7F.=A0 It is silent, so far as I can tell, on host= names.=A0 It may be
that OS X allows UTF-8 host names, which subsequent= ly occur in mDNS
packets...

-K-

It might be that some vendor find they have to greenfield things.
My preference would be to stub out the libc stub resolver, and force all resolution to 127.0.0.1 (::1), and do all the rest. =A0That's already t= he
case for some systems, but it has failed to become an architectural norm.

--
] =A0 =A0 =A0 =A0 =A0 =A0 =A0 Never tell me the odds! =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 | ipv6 mesh networks [
] =A0 Michael Richardson, Sandelman Software Works =A0 =A0 =A0 =A0| network= architect =A0[
] =A0 =A0 mcr@sandelman.ca =A0http://www.sandelman.ca/<= /a> =A0 =A0 =A0 =A0| =A0 ruby on rails =A0 =A0[


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


--089e0122ac808065ba04de92c53b-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A2321F9B14 for ; Wed, 5 Jun 2013 06:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1QlzMZSuFGj0 for ; Wed, 5 Jun 2013 06:43:40 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3::184]) by ietfa.amsl.com (Postfix) with ESMTP id 057F221F9AFE for ; Wed, 5 Jun 2013 06:43:40 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 904992017F; Wed, 5 Jun 2013 09:56:34 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E686B63A8C; Wed, 5 Jun 2013 09:42:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D53BE63A5E; Wed, 5 Jun 2013 09:42:48 -0400 (EDT) From: Michael Richardson To: "Albrecht, Harald" In-Reply-To: References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 13:43:41 -0000 --=-=-= Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable >>>>> "Albrecht," =3D=3D Albrecht, Harald wri= tes: >> -----Urspr=FCngliche Nachricht----- >> Von: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] Im >> Auftrag von Michael Richardson >> Gesendet: Dienstag, 4. Juni 2013 15:46 >> An: mdnsext@ietf.org >> Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF >> I think that they are very different, and I think that we need to le= ave the >> door open to that commercial enterprise networks might be ruled out = of >> bounds for mDNS. That is, it might be that all that we wind up with= is a way >> to signal that mDNS is *not* to be used on a particular >> network. I do not believe that we have many operators of such netw= orks >> at IETF meetings to represent their point of view. (I think about t= he >> operators of the government networks near me... they have many >> conflicting requirements, but few clues as to how to put them togeth= er) Albrecht> My understanding of the ongoing discussion so far is, that Albrecht> the charter is not focusing solely on mDNS as the Albrecht> underlying technology only, but with a somewhat broader Albrecht> scope of service discovery; thus, also including DNS for Albrecht> those scenarios (use cases) where an IT infrastructure is Albrecht> present. At least to some extent. My impression was that Albrecht> the (pending?) renaming of the upcoming WG reflects this Albrecht> situation. Or did I misunderstand this?=20 Yes, it's true that going to infrastructure DNS is useful. But, that doesn't prevent or clearly signal, that mDNS may be *unwelcome* on a particular network. Enterprise folks might want to do that. I'm not claiming that they will, or should, succeed, btw. I'm pointing out that we don't know what they want, because they don't tend to participate. >> It's not that mDNS and global >> DNS *services* or even protocols have difficulties co-existing. The= y do >> that just fine. It is a question of them *interacting*. The place >> where they interact is on the *host*. Albrecht> How true, that's where the devil is in the details. mDNS Albrecht> uses UTF-8 encoding on the wire and DNS uses (at least for Albrecht> host domain names) ASCII/IDNA-2008. Throw in different Albrecht> resolver libs and IDNA support and you are ready for an Albrecht> instant recipe disaster.=20 It might be that some vendor find they have to greenfield things. My preference would be to stub out the libc stub resolver, and force all resolution to 127.0.0.1 (::1), and do all the rest. That's already the case for some systems, but it has failed to become an architectural norm. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUa9AWIqHRg3pndX9AQIKqAQA7ktzoBMrW78XGgVgIVWMrPI++/rGlC9O PgRt6o7DSxkzOS+vORJaOAQqxsMIiV58sptUGTK9lF7AgLznpUYPKTo+qAUCv32g yH1Ns0mwKK0z7kt2oqYSM/SLcPk5tJrQ6oONJfAjZ4fDm5VsSQtv5VRKiYRtJlLg cEhAg92tf28= =Wt/Z -----END PGP SIGNATURE----- --=-=-=-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EDE121F992A for ; Wed, 5 Jun 2013 00:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mdr-87HQ7u2z for ; Wed, 5 Jun 2013 00:05:47 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by ietfa.amsl.com (Postfix) with ESMTP id CA1D021F991E for ; Wed, 5 Jun 2013 00:05:42 -0700 (PDT) Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.13.6/8.13.6) with ESMTP id r5575esP029783 for ; Wed, 5 Jun 2013 09:05:40 +0200 Received: from DEFTHW99ET7MSX.ww902.siemens.net ([157.163.145.4]) by mail1.sbs.de (8.13.6/8.13.6) with ESMTP id r5575eac028844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 5 Jun 2013 09:05:40 +0200 Received: from DEFTHW99ER2MSX.ww902.siemens.net (139.22.70.75) by DEFTHW99ET7MSX.ww902.siemens.net (157.163.145.4) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 5 Jun 2013 09:05:40 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.137]) by DEFTHW99ER2MSX.ww902.siemens.net ([139.22.70.75]) with mapi id 14.02.0342.003; Wed, 5 Jun 2013 09:05:39 +0200 From: "Albrecht, Harald" To: "mdnsext@ietf.org" Thread-Topic: [mdnsext] Discussion of BoF during Berlin IETF Thread-Index: AQHOYSnHoLNfrYhO9UyyRiqKaj691Jkmr/9w Date: Wed, 5 Jun 2013 07:05:39 +0000 Message-ID: References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <19956.1370353531@sandelman.ca> In-Reply-To: <19956.1370353531@sandelman.ca> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 07:05:53 -0000 > -----Urspr=FCngliche Nachricht----- > Von: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] Im > Auftrag von Michael Richardson > Gesendet: Dienstag, 4. Juni 2013 15:46 > An: mdnsext@ietf.org > Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF > I think that they are very different, and I think that we need to leave t= he > door open to that commercial enterprise networks might be ruled out of > bounds for mDNS. That is, it might be that all that we wind up with is a= way > to signal that mDNS is *not* to be used on a particular > network. I do not believe that we have many operators of such networks > at IETF meetings to represent their point of view. (I think about the > operators of the government networks near me... they have many > conflicting requirements, but few clues as to how to put them together) My understanding of the ongoing discussion so far is, that the charter is n= ot focusing solely on mDNS as the underlying technology only, but with a so= mewhat broader scope of service discovery; thus, also including DNS for tho= se scenarios (use cases) where an IT infrastructure is present. At least to= some extent. My impression was that the (pending?) renaming of the upcomin= g WG reflects this situation. Or did I misunderstand this? If we talk about the scenario a), we are most probably talking about what i= s also termed "IT networks", right? That is, a network for office IT? At le= ast with respect to network policies, I know that there are quite some diff= erences compared to networks used in production plants (manufacturing) or c= ontrol networks. > It's not that mDNS and global > DNS *services* or even protocols have difficulties co-existing. They do > that just fine. It is a question of them *interacting*. The place > where they interact is on the *host*. How true, that's where the devil is in the details. mDNS uses UTF-8 encodin= g on the wire and DNS uses (at least for host domain names) ASCII/IDNA-2008= . Throw in different resolver libs and IDNA support and you are ready for a= n instant recipe disaster. -- Harald > -----Urspr=FCngliche Nachricht----- > Von: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] Im > Auftrag von Michael Richardson > Gesendet: Dienstag, 4. Juni 2013 15:46 > An: mdnsext@ietf.org > Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF > I think that they are very different, and I think that we need to leave t= he > door open to that commercial enterprise networks might be ruled out of > bounds for mDNS. That is, it might be that all that we wind up with is a= way > to signal that mDNS is *not* to be used on a particular > network. I do not believe that we have many operators of such networks > at IETF meetings to represent their point of view. (I think about the > operators of the government networks near me... they have many > conflicting requirements, but few clues as to how to put them together) >=20 > I am unconvinced that (c)HOMENET and (d)LLNs are in the same problem > space, but I also have no evidence that they aren't. I think that there = is a > scaling of complexity problem that we need to deal with here. >=20 > I am very much sure that (a)Fortune500 and (b)R&E do not share very much > in common with (c)/(d), except that the things being plugged into these > networks are from the same vendors, and that some of the devices that get > plugged in tend to travel among all these various places. >=20 > I think that >=20 > 3. To develop a BCP for the coexistence of zeroconf (mDNS) and > unicast (global DNS) name services in such multi-link networks, which > should include consideration of both the name resolution mechanism > and the namespace. >=20 > may be incomplete or even mis-guided. It's not that mDNS and global > DNS *services* or even protocols have difficulties co-existing. They do > that just fine. It is a question of them *interacting*. The place > where they interact is on the *host*. >=20 > We are not writing a network protocol! > We are creating a clear state machine that a host implements that takes > inputs ("replies"/"responses") from existing network protocols and acts i= n > deterministic and user-useful ways. >=20 > Our documents should not have time-sequence diagrams in it, assuming that > we are god and can control the other hosts. Rather, it should have input= s > and state changes for a host, and yes, even messages to users and/or > applications about what is available. >=20 >=20 > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ >=20 Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81FAB21F9B56 for ; Tue, 4 Jun 2013 08:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4O-1fmpCf2uz for ; Tue, 4 Jun 2013 08:45:43 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.252.184]) by ietfa.amsl.com (Postfix) with ESMTP id 5B38121F8FB3 for ; Tue, 4 Jun 2013 06:46:56 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2166820171 for ; Tue, 4 Jun 2013 09:59:46 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 411E463A8C; Tue, 4 Jun 2013 09:45:31 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2F31663A5E for ; Tue, 4 Jun 2013 09:45:31 -0400 (EDT) From: Michael Richardson To: "mdnsext@ietf.org" In-Reply-To: <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 15:45:57 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable {I have no travel budget to be in Berlin} I think that the BOF proposal is very sane and very well thought out. I question the need for a BOF at this point. I think our set of requirements and goals is very well understood: I think that there is enough material there to charter a WG already.=20 I am pleased that the commercial enterprise networks and the R&E campus network scenarios are broken out. To repeat: a) Commercial enterprise networks ("Fortune500") b) Academic/educational/university campus networks (R&E) c) Multi-link home networks, such as those envisaged by the HOMENET WG=20 d) Multi-link/single subnet (mesh) networks, such as those described by the ZigBee Alliance Z-IP specification (LLN/LWIG) I think that they are very different, and I think that we need to leave the door open to that commercial enterprise networks might be ruled out of bounds for mDNS. That is, it might be that all that we wind up with is a way to signal that mDNS is *not* to be used on a particular network. I do not believe that we have many operators of such networks at IETF meetings to represent their point of view. (I think about the operators of the government networks near me... they have many conflicting requirements, but few clues as to how to put them together) I am unconvinced that (c)HOMENET and (d)LLNs are in the same problem space, but I also have no evidence that they aren't. I think that there is a scaling of complexity problem that we need to deal with here. I am very much sure that (a)Fortune500 and (b)R&E do not share very much in common with (c)/(d), except that the things being plugged into these networks are from the same vendors, and that some of the devices that get plugged in tend to travel among all these various places. I think that=20 3. To develop a BCP for the coexistence of zeroconf (mDNS) and unicast (global DNS) name services in such multi-link networks, which should include consideration of both the name resolution mechanism and the namespace. may be incomplete or even mis-guided. It's not that mDNS and global DNS *services* or even protocols have difficulties co-existing. They do that just fine. It is a question of them *interacting*. The place=20 where they interact is on the *host*. We are not writing a network protocol! We are creating a clear state machine that a host implements that takes inputs ("replies"/"responses") from existing network protocols and acts in deterministic and user-useful ways. Our documents should not have time-sequence diagrams in it, assuming that we are god and can control the other hosts. Rather, it should have inputs and state changes for a host, and yes, even messages to users and/or applications about what is available. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUa3veoqHRg3pndX9AQKj4wQAw9tXhiZn4jPaZM3r+fP6KAZZEfX/TzDt 0RRRN6gzLs3JUd+vgZ7+QElXmI3Gq1ZfsOxN/Ikvizwyyonpa8v8mLKYcm5PRQjr oaRG4qgVUg+xyBu9po2uhb+wLs+4llZ7z7hVC0iRcNTEfiaR4ELbaEx2daBtvfRv eGemjnjXXVo= =aSaA -----END PGP SIGNATURE----- --=-=-=-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F009921F997E for ; Mon, 3 Jun 2013 18:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.572 X-Spam-Level: X-Spam-Status: No, score=-101.572 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqHRspOFt6lL for ; Mon, 3 Jun 2013 18:30:07 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4BF21E80C5 for ; Mon, 3 Jun 2013 17:47:59 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.54380651; Mon, 03 Jun 2013 20:45:34 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.173]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Mon, 3 Jun 2013 20:47:51 -0400 From: "Brzozowski, John" To: Kerry Lynn , "consultancy@vanderstok.org" Thread-Topic: [mdnsext] Discussion of BoF during Berlin IETF Thread-Index: AQHOYDN5ldFGvOVfHUCwamdaDY33MZkkMmaAgACHoAA= Date: Tue, 4 Jun 2013 00:47:51 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: <70529389F79E1C4A9A820E239DD75602@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 01:30:22 -0000 Kerry, See below. John -----Original Message----- From: Kerry Lynn Date: Monday, June 3, 2013 8:42 AM To: "consultancy@vanderstok.org" Cc: "mdnsext@ietf.org" Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF > > > >On Mon, Jun 3, 2013 at 4:20 AM, peter van der Stok >wrote: > >Hi John, > >Very few, naive wishes about autonomous SD data access. > > > >IMO, "autonomous" is a worthy goal but probably not attainable. >Nevertheless, any >required configuration MUST be kept to a minimum. [jjmb] definitely agree to keeping configuration to a minimum. I am not sure I follow why autonomous is not attainable, I can envision how within a premise data can be learned and collected while separating how the same is made available upstream. Am I over simplifying? > >As an example, under DNS-SD/mDNS the user has always had the option of >choosing >a meaningful label for a given service. If the scope in which >this label must >be unique is too large, the task of name conflict resolution becomes more >complex. This >may be mitigated by autonomously choosing names with a very low >probability of collision, >but these are user unfriendly. We need to strike a balance. >=20 > > >The home, and also the buiding control installation, can and will be >separated temporarily from the internet connection provided by Internet >providers. >Having autonomous access to SD data in the home (building), with a >painless (dis)connection to(from) the Internet provider, is one of my >prime concerns for joining this wg. >Scalability of the SD data access inside the autonomous network (using a >server) is equally important. > >Naming inside and outside home should be consistent. > > > >Do you mean that the label must be unique both locally and >within some >global DNS hierarchy? >=20 > > >My examples: >Inside names: like mydevice.a-local-domain, where a-local-domain can be >empty > > > >Certainly the issue of local TLDs must be addressed by the WG. IMO, >every server >that is deployed today MUST continue to work under the "new" rules, which >means >that "local." is not going away anytime soon. We can be sure beyond >doubt that this >TLD will never be assigned, but we should work with ICANN to assign a new >local >TLD for future growth. >=20 > > >Outside names like mydevice.a-local-domain.xs4all-given-domain. >or myhost.mydomain.my-outside-domain-name. > > > >Can we stick with conventions like "example.com ." >for domain names? > > > >Possibly, the dot for specifying FQDN can be used to distinguish >autonomous SD data from fully qualified outside data. >If local. suffix is needed, a special layer to filter out the local. to >the application would be welcome. > > > >I don't think we can alter domain name semantics (i.e. the meaning of the >final dot '.') >without triggering a severe immune response from the DNS police. OTOH, >it seems >as though defining new resource record types should be possible. I've >been thinking >along the lines of a user-visible "alias" for domain names, e.g. >"foo.local." might be >made to appear in a SD browser as "Living Room". Here it seems that >mobile devices >would need a mechanism to discover when they're on "known" networks and >probably >tailor their SD display and advertisement behavior accordingly. > > > >Separating the work such that parts of the work are moved forward >independently, but in mutual agreement, sounds great. > > > >Yes, we definitely need to prioritize the requirements in order to >produce the initial >proposed standard, but also need a clear vision of future work so that we >don't limit >our options. [jjmb] I think it would be good to arrive at some consensus on this prioritized list. > >I am not yet certain I'll be in Berlin (lacking corporate sponsorship for >this work) but I'll >do what I can to advance the base documents and write up a -00 proposal. > >Regards, -K- >=20 > > >Peter > >Brzozowski, John schreef op 2013-06-01 16:07: > > >I just took a quick look at the proposal as well, seems to cover most >essential areas. I see that Zigbee was called out, it might be good to >ensure that it is clear that the home is called out as a key use case. > >Peter, > >Regarding your comment below what are your thought around separately >internal and external access to SD data. Specifically I am thinking SD >within the home as alluded below can and perhaps should be autonomous. I >think it may be useful to split up how SD is performed in a premise from >how it may be made available northbound either by a service provider or >other third party. Separating the work can help to ensure that we move >parts of this work forward independently. > >John >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >John Jason Brzozowski >Comcast Cable >m) 484-962-0060 >o) 609-377-6594 >w) www.comcast6.net >e) john_brzozowski@cable.comcast.com >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > >-----Original Message----- >From: peter van der Stok >Organization: vanderstok consultancy >Reply-To: "consultancy@vanderstok.org" >Date: Friday, May 31, 2013 2:24 AM >To: "mdnsext@ietf.org" >Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF > >Ralph, > >I am certainly interested in this work and agree with the charter, >which has improved with respect to the former version. >From the point of view of building control, it is essential to do >disovery on a multilink stand-alone network, and not needing to change >the applications when the network is connected to a backbone with access >to DNS. From the outside the resources on the now connected network >should be visible with the same names, possibly suffixed with additional >domain name information. > >In the past I have commented on the requirements and I am looking >forward to a new version. > >Peter van der Stok. > >Ralph Droms schreef op 2013-05-31 05:24: >REMINDER!!!! > >I'm looking for review and discussion of the BoF proposal and draft >charter here: >http://www.ietf.org/mail-archive/web/mdnsext/current/msg00149.html > >The mailing list has been quiet (0 responses so far). Is there still >interest in taking on this work? > >- Ralph > >_______________________________________________ >mdnsext mailing list >mdnsext@ietf.org >https://www.ietf.org/mailman/listinfo/mdnsext > > >_______________________________________________ >mdnsext mailing list >mdnsext@ietf.org >https://www.ietf.org/mailman/listinfo/mdnsext > > > >_______________________________________________ >mdnsext mailing list >mdnsext@ietf.org >https://www.ietf.org/mailman/listinfo/mdnsext > > >_______________________________________________ >mdnsext mailing list >mdnsext@ietf.org >https://www.ietf.org/mailman/listinfo/mdnsext > > > > > > Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5350121F9774 for ; Mon, 3 Jun 2013 18:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.707 X-Spam-Level: X-Spam-Status: No, score=-101.707 tagged_above=-999 required=5 tests=[AWL=-0.810, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9liQ3whnpAf for ; Mon, 3 Jun 2013 18:23:43 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 1779721F94BA for ; Mon, 3 Jun 2013 17:41:54 -0700 (PDT) Received: from ([24.40.56.116]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.54380333; Mon, 03 Jun 2013 20:39:20 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.173]) by pacdcexhub03.cable.comcast.com ([fe80::5527:6d6b:29a7:f414%13]) with mapi id 14.02.0318.001; Mon, 3 Jun 2013 20:41:37 -0400 From: "Brzozowski, John" To: "consultancy@vanderstok.org" , "mdnsext@ietf.org" Thread-Topic: [mdnsext] Discussion of BoF during Berlin IETF Thread-Index: AQHOYDN5ldFGvOVfHUCwamdaDY33MZkkuEeA Date: Tue, 4 Jun 2013 00:41:37 +0000 Message-ID: In-Reply-To: <3f9e642cbdc6f8bb1a996f786bc61b09@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [24.40.55.71] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 01:23:59 -0000 I think we are on the same page, thanks Peter. I agree with the below and do not disagree with the items you enumerated in your reply. John >Separating the work such that parts of the work are moved forward >independently, but in mutual agreement, sounds great. Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AFB21F9952 for ; Mon, 3 Jun 2013 06:44:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id An3L11evgZKi for ; Mon, 3 Jun 2013 06:44:31 -0700 (PDT) Received: from smtp-vbr19.xs4all.nl (smtp-vbr19.xs4all.nl [194.109.24.39]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7A021F9811 for ; Mon, 3 Jun 2013 06:44:30 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube7.xs4all.net [194.109.20.205]) by smtp-vbr19.xs4all.nl (8.13.8/8.13.8) with ESMTP id r53DiK5s085842; Mon, 3 Jun 2013 15:44:20 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-76-97.w90-0.abo.wanadoo.fr ([90.0.171.97]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 03 Jun 2013 15:44:19 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_1bf89b030b61509cc133cbd129a8c7e7" Date: Mon, 03 Jun 2013 15:44:19 +0200 From: peter van der Stok To: , kerry lynn Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: <3f9e642cbdc6f8bb1a996f786bc61b09@xs4all.nl> Message-ID: X-Sender: stokcons@xs4all.nl (3NpoYe7FLKjxuagD16cRMHmirCGEWnbX) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:44:37 -0000 --=_1bf89b030b61509cc133cbd129a8c7e7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Hi Kerry, reacting to: > under DNS-SD/mDNS the user has always had the option of choosing > a meaningful label for a given service. If the scope in > which this label must > be unique is too large, the task of name conflict resolution becomes > more complex. being unique within the autonomous network and .example.com being globally unique is enough for me. Reacting to: >I've been thinking along the lines of a user-visible "alias" for domain names, e.g. "foo.local." might be made to appear in a SD browser as "Living Room". or even may look like: "foo.". Peter --=_1bf89b030b61509cc133cbd129a8c7e7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8 
Hi Kerry,

reacting to:

> under DNS-SD/mDNS th=
e user has always had the option of choosing

> a meaningful &=
lt;Instance> label for a given service.  If the scope in

> which this label must

> be unique is too large, the tas=
k of name conflict resolution becomes

> more complex. 

<Instance> being unique within the autonomous network=
 and <Instance>.example.com being globally unique is enough for me.&n=
bsp;

Reacting to:

>I've been thinking 
along =
the lines of a user-visible "alias" for domain names, e.g. "foo.local." mig=
ht be 
made to appear in a SD browser as "Living Room". 
or even may look like: "foo.".

Peter
--=_1bf89b030b61509cc133cbd129a8c7e7-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ACF721F9811 for ; Mon, 3 Jun 2013 06:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.109 X-Spam-Level: X-Spam-Status: No, score=-9.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+yuSZri3F+Q for ; Mon, 3 Jun 2013 06:40:25 -0700 (PDT) Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7CB21F8B21 for ; Mon, 3 Jun 2013 06:40:25 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_06Pvn+asLqtbrLKfBHyPJg)" Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7u4-23.01 (7.0.4.23.0) 64bit (built Aug 10 2011)) with ESMTP id <0MNT00HPMKN8JML1@mail-out.apple.com> for mdnsext@ietf.org; Mon, 03 Jun 2013 06:40:24 -0700 (PDT) X-AuditID: 11807157-b7f706d0000006c6-ad-51ac9cc62578 Received: from [17.153.103.39] (Unknown_Domain [17.153.103.39]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id D2.2E.01734.7CC9CA15; Mon, 03 Jun 2013 06:40:24 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Mon, 03 Jun 2013 09:40:28 -0400 Message-id: <3140166B-9D64-4E52-81F7-AE5A14101766@apple.com> References: <3f9e642cbdc6f8bb1a996f786bc61b09@xs4all.nl> To: Kerry Lynn X-Mailer: Apple Mail (2.1503) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUiODNdXffEnDWBBic7BS0e7V/FZnF5/Spm i5NLTjFZHPkW68DisfXkDzaPpxMOMnksWfKTyeNEw3b2AJYoLpuU1JzMstQifbsEroyPE/0L /jhXTHi1j6mB8ZJFFyMnh4SAicT7O8cYIWwxiQv31rN1MXJxCAn0Mkn0N89hAUkIC1hLrDz+ EayIV0BP4tq3r+wgNrNAgsS0uyuZQGw2ATWJ35P6WEFsToFAiY3XjoD1sgioSFxqbmKBqDeS mHr6OdQcG4nvj2YwQSw7xijxrP872CARAQWJT4v2MEFcJCvx+vkblgmMfLOQ7J6FZDeErS2x bOFrZghbT+Jl0zt2THFdiYvrJjEuYGRbxShQlJqTWGmil1hQkJOql5yfu4kRFMoNheE7GP8t szrEKMDBqMTD+8N1TaAQa2JZcWXuIUYJDmYlEd4rgUAh3pTEyqrUovz4otKc1OJDjNIcLEri vEY2SwOFBNITS1KzU1MLUotgskwcnFINjFYP1r9xLlr+XCvm8P2bcqkNHUqPd1RtStLyWvFt WVNYg97E9buWFDk7q5f/YtPvLJ4Y+/+I0rWJxtLPCx7l/DWdaXGIaf9u8+mdevM1Pk9V595n skVwLsu/laGq338fuWr2fE7Pa69/b3/8vhwSnnB7+va/3/2OLj/0nf95wwvu3I2p19atyl+i xFKckWioxVxUnAgAjfXCHmECAAA= Cc: mdnsext@ietf.org, consultancy@vanderstok.org Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 13:40:38 -0000 --Boundary_(ID_06Pvn+asLqtbrLKfBHyPJg) Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Kerry, On 2013-06-03, at 8:42 AM, Kerry Lynn wrote: > On Mon, Jun 3, 2013 at 4:20 AM, peter van der Stok wrote: > Hi John, > > Very few, naive wishes about autonomous SD data access. > > IMO, "autonomous" is a worthy goal but probably not attainable. Nevertheless, any > required configuration MUST be kept to a minimum. > > As an example, under DNS-SD/mDNS the user has always had the option of choosing > a meaningful label for a given service. If the scope in which this label must > be unique is too large, the task of name conflict resolution becomes more complex. This > may be mitigated by autonomously choosing names with a very low probability of collision, > but these are user unfriendly. We need to strike a balance. One of the things we did for the latest Bonjour Printing specification (and I'm hoping that will actually get published to developer.apple.com soon) is to clarify the default instance naming for printers - by default, use a "make and model" string, e.g., "Acme Laser Printer", and if there is a collision either do the normal numbering stuff ("Acme Laser Printer N") or just add a unique identifier that is affixed to the printer - typically a serial number or the last 6 digits of the MAC address, e.g., "Acme Laser Printer (12:34:56)". Not super user-friendly, but at least something a customer can look for on the printer should they actually own two of the same printer. In addition to showing the printer name in our UI, we also show the location (if set) or serial number (if we have it) under the name - something like the following feeble ASCII art: +-----------------------+ | ACME LASER PRINTER | (actual name is "Acme Laser Printer (12:34:56)") | (12;34:56) | (no location string, so we show the serial number) +-----------------------+ | ACME LASER PRINTER | (actual name is "Acme Laser Printer (78:9A:BC)") | (78:9A:BC) | (no location string, so we show the serial number) +-----------------------+ | ACME LASER PRINTER | (actual name is "Acme Laser Printer (FE:DC:BA)") | coffee mess | (location string set) +-----------------------+ | ACME INKJET PRINTER | (actual name, no location or serial) +-----------------------+ | ACME INKJET PRINTER 2 | (actual name using numbered method) | mike's desk | (location string set) +-----------------------+ And of course the customer can change the name and location strings if they wish, typically through the printer's web interface. (Perhaps including a location key in TXT record should be encouraged/required for usability?) _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair --Boundary_(ID_06Pvn+asLqtbrLKfBHyPJg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: quoted-printable kerlyn@ieee.org> = wrote:
On Mon, Jun 3, 2013 at 4:20 AM, = peter van der Stok <stokcons@xs4all.nl> wrote:
Hi John,

Very few, naive wishes about autonomous SD data = access.

IMO, "autonomous" is a worthy goal but = probably not attainable.  Nevertheless, any
required = configuration MUST be kept to a minimum.

As an example, under DNS-SD/mDNS the user has always had the option = of choosing
a meaningful <Instance> label for a given = service.  If the scope in which this label must
be unique is too = large, the task of name conflict resolution becomes more complex.  = This
may be mitigated by autonomously choosing names with a very low = probability of collision,
but these are user unfriendly.  We = need to strike a = balance.

One of the = things we did for the latest Bonjour Printing specification (and I'm = hoping that will actually get published to developer.apple.com soon) is to = clarify the default instance naming for printers - by default, use a = "make and model" string, e.g., "Acme Laser Printer", and if there is a = collision either do the normal numbering stuff ("Acme Laser Printer N") = or just add a unique identifier that is affixed to the printer - = typically a serial number or the last 6 digits of the MAC address, e.g., = "Acme Laser Printer (12:34:56)". Not super user-friendly, but at least = something a customer can look for on the printer should they actually = own two of the same printer.

In addition to = showing the printer name in our UI, we also show the location (if set) = or serial number (if we have it) under the name - something like the = following feeble ASCII art:

    = +-----------------------+
    | ACME LASER PRINTER =    |     (actual name is "Acme Laser Printer = (12:34:56)")
    |   (12;34:56)     =      |     (no location string, so we show the = serial number)
    = +-----------------------+
    | ACME LASER PRINTER =    |     (actual name is "Acme Laser Printer = (78:9A:BC)")
    |   (78:9A:BC)     =      |     (no location string, so we show = the serial number)
    = +-----------------------+
    | ACME LASER PRINTER =    |     (actual name is "Acme Laser Printer = (FE:DC:BA)")
    |   coffee mess     =     |     (location string = set)
    = +-----------------------+
    | ACME INKJET PRINTER =   |     (actual name, no location or = serial)
    = +-----------------------+
    | ACME = INKJET PRINTER 2 |     (actual name using numbered = method)
    |   mike's desk     =     |     (location string = set)
    = +-----------------------+

And of course = the customer can change the name and location strings if they wish, = typically through the printer's web = interface.

(Perhaps including a location key in = TXT record should be encouraged/required for = usability?)

_________________________________________________________
Michael = Sweet, Senior Printing System Engineer, PWG = Chair

= --Boundary_(ID_06Pvn+asLqtbrLKfBHyPJg)-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE8E21F96F2 for ; Mon, 3 Jun 2013 05:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQICN5++Wnq3 for ; Mon, 3 Jun 2013 05:43:01 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 35E7521F9643 for ; Mon, 3 Jun 2013 05:42:58 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id xn12so7160030obc.34 for ; Mon, 03 Jun 2013 05:42:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aR8gWEIBXmWJpTeQ0ZYqEIQe16T9uBOWBpgPz63Of0E=; b=x7BS3GFgKzW8L4dRhPOfgQJ94fhOmK1W3sme5OcG8jHqemnT+80cN6R20KMk2Jbmuk Wj123hPoIIqGMhxZ/HoOKME8zdFKAN16iQvTI9rtdNfhSiRb9sZro08ELCSVMt/IUKw8 aDgRB6gSt71DvkGBt2Sfh/bJyJHkmybstEHivEwkXKzGFb1W5RoUX/O6LiBOTVNoWAiw 3N3ncrIINMAbtAdFncsqrrb5PBVq8wlOBN/0UdqbAPannzPKDPOp9YXjegp6qMp+ddfh 38urr2VUOuy3YaZjr371Y6pPFz/r1fiYBy57ME0BtUXdshVMhUez3fLE0DLw4nYVIxON /3yg== MIME-Version: 1.0 X-Received: by 10.60.47.77 with SMTP id b13mr10203178oen.134.1370263377665; Mon, 03 Jun 2013 05:42:57 -0700 (PDT) Sender: kerlyn2001@gmail.com Received: by 10.60.148.197 with HTTP; Mon, 3 Jun 2013 05:42:57 -0700 (PDT) In-Reply-To: <3f9e642cbdc6f8bb1a996f786bc61b09@xs4all.nl> References: <3f9e642cbdc6f8bb1a996f786bc61b09@xs4all.nl> Date: Mon, 3 Jun 2013 08:42:57 -0400 X-Google-Sender-Auth: ajfO9dVU49dHd1k9fu8EGsZNf84 Message-ID: From: Kerry Lynn To: consultancy@vanderstok.org Content-Type: multipart/alternative; boundary=001a11c21116dfe36004de3f4d6b Cc: mdnsext@ietf.org Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 12:43:03 -0000 --001a11c21116dfe36004de3f4d6b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 3, 2013 at 4:20 AM, peter van der Stok wrote: > Hi John, > > Very few, naive wishes about autonomous SD data access. > IMO, "autonomous" is a worthy goal but probably not attainable. Nevertheless, any required configuration MUST be kept to a minimum. As an example, under DNS-SD/mDNS the user has always had the option of choosing a meaningful label for a given service. If the scope in which this label must be unique is too large, the task of name conflict resolution becomes more complex. This may be mitigated by autonomously choosing names with a very low probability of collision, but these are user unfriendly. We need to strike a balance. > The home, and also the buiding control installation, can and will be > separated temporarily from the internet connection provided by Internet > providers. > Having autonomous access to SD data in the home (building), with a > painless (dis)connection to(from) the Internet provider, is one of my prime > concerns for joining this wg. > Scalability of the SD data access inside the autonomous network (using a > server) is equally important. > > Naming inside and outside home should be consistent. > > Do you mean that the label must be unique both locally and within some global DNS hierarchy? > My examples: > Inside names: like mydevice.a-local-domain, where a-local-domain can be > empty > Certainly the issue of local TLDs must be addressed by the WG. IMO, every server that is deployed today MUST continue to work under the "new" rules, which means that "local." is not going away anytime soon. We can be sure beyond doubt that this TLD will never be assigned, but we should work with ICANN to assign a new local TLD for future growth. > Outside names like mydevice.a-local-domain.**xs4all-given-domain. > or myhost.mydomain.my-outside-**domain-name. > Can we stick with conventions like "example.com." for domain names? Possibly, the dot for specifying FQDN can be used to distinguish autonomous > SD data from fully qualified outside data. > If local. suffix is needed, a special layer to filter out the local. to > the application would be welcome. > > I don't think we can alter domain name semantics (i.e. the meaning of the final dot '.') without triggering a severe immune response from the DNS police. OTOH, it seems as though defining new resource record types should be possible. I've been thinking along the lines of a user-visible "alias" for domain names, e.g. "foo.local." might be made to appear in a SD browser as "Living Room". Here it seems that mobile devices would need a mechanism to discover when they're on "known" networks and probably tailor their SD display and advertisement behavior accordingly. Separating the work such that parts of the work are moved forward > independently, but in mutual agreement, sounds great. > > Yes, we definitely need to prioritize the requirements in order to produce the initial proposed standard, but also need a clear vision of future work so that we don't limit our options. I am not yet certain I'll be in Berlin (lacking corporate sponsorship for this work) but I'll do what I can to advance the base documents and write up a -00 proposal. Regards, -K- > Peter > > Brzozowski, John schreef op 2013-06-01 16:07: > > I just took a quick look at the proposal as well, seems to cover most >> essential areas. I see that Zigbee was called out, it might be good to >> ensure that it is clear that the home is called out as a key use case. >> >> Peter, >> >> Regarding your comment below what are your thought around separately >> internal and external access to SD data. Specifically I am thinking SD >> within the home as alluded below can and perhaps should be autonomous. I >> think it may be useful to split up how SD is performed in a premise from >> how it may be made available northbound either by a service provider or >> other third party. Separating the work can help to ensure that we move >> parts of this work forward independently. >> >> John >> ==============================**=========== >> John Jason Brzozowski >> Comcast Cable >> m) 484-962-0060 >> o) 609-377-6594 >> w) www.comcast6.net >> e) john_brzozowski@cable.comcast.**com >> ==============================**=========== >> >> >> >> >> >> >> -----Original Message----- >> From: peter van der Stok >> Organization: vanderstok consultancy >> Reply-To: "consultancy@vanderstok.org" >> Date: Friday, May 31, 2013 2:24 AM >> To: "mdnsext@ietf.org" >> Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF >> >> Ralph, >>> >>> I am certainly interested in this work and agree with the charter, >>> which has improved with respect to the former version. >>> From the point of view of building control, it is essential to do >>> disovery on a multilink stand-alone network, and not needing to change >>> the applications when the network is connected to a backbone with access >>> to DNS. From the outside the resources on the now connected network >>> should be visible with the same names, possibly suffixed with additional >>> domain name information. >>> >>> In the past I have commented on the requirements and I am looking >>> forward to a new version. >>> >>> Peter van der Stok. >>> >>> Ralph Droms schreef op 2013-05-31 05:24: >>> >>>> REMINDER!!!! >>>> >>>> I'm looking for review and discussion of the BoF proposal and draft >>>> charter here: >>>> http://www.ietf.org/mail-**archive/web/mdnsext/current/**msg00149.html >>>> >>>> The mailing list has been quiet (0 responses so far). Is there still >>>> interest in taking on this work? >>>> >>>> - Ralph >>>> >>>> ______________________________**_________________ >>>> mdnsext mailing list >>>> mdnsext@ietf.org >>>> https://www.ietf.org/mailman/**listinfo/mdnsext >>>> >>> ______________________________**_________________ >>> mdnsext mailing list >>> mdnsext@ietf.org >>> https://www.ietf.org/mailman/**listinfo/mdnsext >>> >> >> ______________________________**_________________ >> mdnsext mailing list >> mdnsext@ietf.org >> https://www.ietf.org/mailman/**listinfo/mdnsext >> > ______________________________**_________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/**listinfo/mdnsext > --001a11c21116dfe36004de3f4d6b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Jun 3, 2013 at 4:20 AM, peter van der Stok <stokcons@xs4all.nl> wrote:
Hi John,

Very few, naive wishes about autonomous SD data access.

IMO, "autonomous" is a worthy goal but probably not attaina= ble.=A0 Nevertheless, any
required configuration MUST be kept to a minim= um.

As an example, under DNS-SD/mDNS the user has always had the option of = choosing
a meaningful <Instance> label for a given service.=A0 If = the scope in which this label must
be unique is too large, the task of n= ame conflict resolution becomes more complex.=A0 This
may be mitigated by autonomously choosing names with a very low probability= of collision,
but these are user unfriendly.=A0 We need to strike a bal= ance.
=A0
The home, and also the buiding control installation, can and will be separa= ted temporarily from the internet connection provided by Internet providers= .
Having autonomous access to SD data in the home (building), with a painless= (dis)connection to(from) the Internet provider, is one of my prime concern= s for joining this wg.
Scalability of the SD data access inside the autonomous network (using a se= rver) is equally important.

Naming inside and outside home should be consistent.

Do you mean that the <Instance> label must be u= nique both locally and within some
global DNS hierarchy?
=A0
My examples:
Inside names: like mydevice.a-local-domain, where a-local-domain can be emp= ty

Certainly the issue of local TLDs must be addre= ssed by the WG.=A0 IMO, every server
that is deployed today MUST continu= e to work under the "new" rules, which means
that "local." is not going away anytime soon.=A0 We can be sure b= eyond doubt that this
TLD will never be assigned, but we should work wit= h ICANN to assign a new local
TLD for future growth.
=A0
Outside names like mydevice.a-local-domain.xs4all-given-domain.
or myhost.mydomain.my-outside-domain-name.

= Can we stick with conventions like "exa= mple.com." for domain names?

Possibly, the dot for specifying FQDN can be used to distinguish autonomous= SD data from fully qualified outside data.
If local. suffix is needed, a special layer to filter out the local. to the= application would be welcome.

I don't think we can alter domain name semantics = (i.e. the meaning of the final dot '.')
without triggering a sev= ere immune response from the DNS police.=A0 OTOH, it seems
as though def= ining new resource record types should be possible.=A0 I've been thinki= ng
along the lines of a user-visible "alias" for domain names, e.g. = "foo.local." might be
made to appear in a SD browser as "= Living Room".=A0 Here it seems that mobile devices
would need a mec= hanism to discover when they're on "known" networks and proba= bly
tailor their SD display and advertisement behavior accordingly.

Separating the work such that parts of the work are moved forward independe= ntly, but in mutual agreement, sounds great.

Yes, we definitely need to prioritize the requirement= s in order to produce the initial
proposed standard, but also need a cle= ar vision of future work so that we don't limit
our options.

I am not yet certain I'll be in Berlin (lacking corporate sponsorsh= ip for this work) but I'll
do what I can to advance the base documen= ts and write up a -00 proposal.

Regards, -K-
=A0
Peter

Brzozowski, John schreef op 2013-06-01 16:07:

I just took a quick look at the proposal as well, seems to cover most
essential areas. =A0I see that Zigbee was called out, it might be good to ensure that it is clear that the home is called out as a key use case.

Peter,

Regarding your comment below what are your thought around separately
internal and external access to SD data. =A0Specifically I am thinking SD within the home as alluded below can and perhaps should be autonomous. I think it may be useful to split up how SD is performed in a premise from how it may be made available northbound either by a service provider or
other third party. =A0Separating the work can help to ensure that we move parts of this work forward independently.

John
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
John Jason Brzozowski
Comcast Cable
m) 48= 4-962-0060
o) 60= 9-377-6594
w) www.comcast6.net
e) j= ohn_brzozowski@cable.comcast.com
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D






-----Original Message-----
From: peter van der Stok <stokcons@xs4all.nl>
Organization: vanderstok consultancy
Reply-To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>
Date: Friday, May 31, 2013 2:24 AM
To: "mdnsext@iet= f.org" <m= dnsext@ietf.org>
Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF

Ralph,

I am certainly interested in this work and agree with the charter,
which has improved with respect to the former version.
>From the point of view of building control, it is essential to do
disovery on a multilink stand-alone network, and not needing to change
the applications when the network is connected to a backbone with access to DNS. From the outside the resources on the now connected network
should be visible with the same names, possibly suffixed with additional domain name information.

In the past I have commented on the requirements and I am looking
forward to a new version.

Peter van der Stok.

Ralph Droms schreef op 2013-05-31 05:24:
REMINDER!!!!

I'm looking for review and discussion of the BoF proposal and draft
charter here:
http://www.ietf.org/mail-archive/web/mdnsext/c= urrent/msg00149.html

The mailing list has been quiet (0 responses so far). =A0Is there still
interest in taking on this work?

- Ralph

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

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

--001a11c21116dfe36004de3f4d6b-- Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979F621F9619 for ; Mon, 3 Jun 2013 04:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZ3rD2vOc18t for ; Mon, 3 Jun 2013 04:41:52 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8141F21F9399 for ; Mon, 3 Jun 2013 04:41:51 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id hi5so2555188wib.8 for ; Mon, 03 Jun 2013 04:41:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=qDgiM6BOWetF7hVhtCNwe3/zF7VcgEcpB9+17vrQxB0=; b=BWj3RdAIpIYC/J86+hLFKgKCVAlyLbrvU8jPR3avUqeVeMyU/pJVDIhmMtgfoK70lc R7Yv5JvFg4EXlVhb/8TZtrcsv0X6TpCIYAG9A45uM8liG2utLAbY3xITOQFCan+mvrp5 EdNStSLEFtW/WhJ/XkLlcPcdLo3Mi31N4nF+cl8FxVL+XUaPFZcpKVI8BAk8jTSPeeXX 10Cr65FqeVdnbRvN4QDGZNSkY2QoR73xKaheP15vJXUIpZe8cvmq8w42DujBB1sX1j3f Ak7reAW1uGefLZI5MrXVtmDnrdyUwpfJY4mc+ZTyGT+I9DGudmf+odpmHcfZZMA/h8WZ zyvQ== X-Received: by 10.180.14.199 with SMTP id r7mr12235229wic.6.1370259710562; Mon, 03 Jun 2013 04:41:50 -0700 (PDT) Received: from marks-mac-mini.home (AMontsouris-653-1-75-220.w86-212.abo.wanadoo.fr. [86.212.122.220]) by mx.google.com with ESMTPSA id h8sm22826044wiz.9.2013.06.03.04.41.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 04:41:47 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Mark Townsley In-Reply-To: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> Date: Mon, 3 Jun 2013 13:41:45 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6CA247D1-74F1-4AF4-BE34-975F1521AD01@townsley.net> References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQlFuQX81eJW48kpIUR38aHE9/Abj85M5ct1+9EMnwk8DnnRAgS3YB2+pboP4BZCMTF6Lu4E Cc: mdnsext@ietf.org, homenet-chairs@tools.ietf.org Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 11:41:52 -0000 With my co-chair hat on, I would like to reinforce that this topic is of = great importance to the homenet WG (i.e., we are chartered to solve it = whether this WG exists or not). If this WG exists, there is perhaps a = better chance that the homenet solution ends up with common components, = usable outside of a residential solution. That would be a good thing. - Mark On May 22, 2013, at 7:58 PM, Ralph Droms wrote: > After a pretty good discussion of requirements and related = considerations, traffic on the mailing list has been pretty quiet. = Looking ahead to a request for a BoF in Berlin, I've updated the draft = request and charter (only a little) and included them below. >=20 > What we need now is careful review and discussion of the text below, = and explicit expressions of interest in the topic and support for the = specific direction laid out in the BoF request and charter. >=20 > Perhaps the most obvious change I suggest is to change the name from = mdnsext to sadnssd (scalable, autonomous DNS-SD). This change follows = the direction of the earlier mailing list discussion away from = extensions to mDNS to higher level consideration of scalable DNS-SD. >=20 > - Ralph >=20 > BoF scheduling information: >=20 > a. Scalable, Autonomous DNS-Based Service Discovery (sadnssd) >=20 > b. Internet Area >=20 > c. Conflicts: 6man homenet dhc apparea appsawg intarea sdnrg v6ops = dnsop and dnsext >=20 > d. Expected Attendance: 200 (at least 164 attended at IETF85) >=20 > e. Special requests: None >=20 > f. Number of sessions: 1 >=20 > g. Length of session: 2 hours=20 >=20 >=20 > Draft agenda: > -------------------- >=20 > 1. Administravia (Chairs, 5 mins) =20 > Note Well and agenda bashing >=20 > 2. Goals of the BoF (Chairs, 15 mins) > Review of IETF 85 mdsnext BoF and progress since then >=20 > 3. Requirements (Kerry Lynn, 30 mins) > draft-lynn-sadnssd-requirements-01 >=20 > 4. Open discussion (Chairs, 40 mins) > Open mic; includes draft charter and deliverables >=20 > 5. Key questions (Chairs, 30 mins) > Are we ready to form a WG with the agreed charter, subject to mail > list confirmation? =20 > Note RFC5434 section 1. >=20 >=20 > Draft charter: > ------------------- >=20 > Currently, zeroconf networking protocols are generally used to > discover services within the scope of a single link. In particular, > the Bonjour protocols suite, comprising mDNS (RFC 6762) and DNS-SD > (RFC 6763), are widely used for discovery and resolution of services > and names on a single link. >=20 > The Bonjour protocol suite is commonly used in many scenarios, > including home networks, commercial and campus enterprise networks, > and may be of use in certain mesh networks. However, the multicast > Bonjour protocols are constrained to link-local scope, so can only be > used to discover services on the same link. In a typical current home > network, which is a single link, users should experience the desired > discovery behavior. However, in future multi-link home networks (as > envisaged by the homenet WG) and in routed campus or enterprise > networks, devices and thus users can only discover services on the > same link, which is a significant limitation. Such limitations have > led to calls, such as those by the Educause petition, to develop an > appropriate solution to span multiple links, or to perform discovery > across a wide area (not necessarily on directly connected links). >=20 > In addition, the ZigBee Alliance Smart Energy Profile 2.0 commercial > standard currently under development has specified the Bonjour > protocols as its method of zero configuration discovery. However, its > use of wireless mesh multi-link subnets and its use across traditional > routed networks will require extensions to the Bonjour protocols to > allow operation across multiple links. >=20 > As demand for service discovery across wider area routed networks > grows, some vendors are beginning to ship their own early > solutions. It is thus both timely and important that efforts to > develop improved, scalable, autonomous service discovery solutions for > routed networks are coordinated towards producing a single, standards- > based solution. >=20 > Goals >=20 > To that end, the primary goals of the sadnssd WG are as follows: >=20 > 1. To document a set of requirements for scalable, autonomous > DNS-based service discovery in routed, multi-link networks in the > following four scenarios: >=20 > a) Commercial enterprise networks > b) Academic/educational/university campus networks > c) Multi-link home networks, such as those envisaged by the > HOMENET WG=20 > d) Multi-link/single subnet (mesh) networks, such as those > described by the ZigBee Alliance Z-IP specification >=20 > 2. To develop an improved, scalable solution for wide-area service > discovery that can operate in multi-link networks, applicable to > the scenarios above. >=20 > 3. To develop a BCP for the coexistence of zeroconf (mDNS) and unicast > (global DNS) name services in such multi-link networks, which > should include consideration of both the name resolution mechanism > and the namespace. >=20 > It is important that the sadnssd WG takes input from stakeholders in > the scenarios it is considering. For example, the homenet WG is > currently evaluating its own requirements for naming and service > discovery; it is up to the homenet WG as to whether it wishes to > recommend adoption of the solution developed in the mdsnext WG, and > thus coordination between the WGs is desirable. >=20 > Deliverables >=20 > The WG will produce three documents: an Informational RFC on the > requirements for wide-area service discovery protocols; a Standards > Track RFC documenting a wide-area service discovery solution that is > applicable to those scenarios; and a BCP document describing the most > effective method to integrate mDNS and global DNS name services. >=20 > Milestones >=20 > Sep 2013 Formation of the WG > Oct 2013 Adopt requirements draft as WG document > Nov 2013 Submit requirements draft to the IESG as an Informational RFC > Mar 2014 Adopt wide-area service discovery solution draft as WG > document=20 > Mar 2014 Adopt zeroconf and unicast DNS integration BCP draft as WG > document=20 > Sep 2014 Submit wide-area service discovery solution draft to the IESG > as Standards Track RFC=20 > Sep 2014 Submit zeroconf and unicast DNS integration solution draft to > the IESG as BCP=20 >=20 > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FE521F8EF2 for ; Mon, 3 Jun 2013 03:15:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZNiNlEPbQHY for ; Mon, 3 Jun 2013 03:15:44 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) by ietfa.amsl.com (Postfix) with ESMTP id 1118421F86EC for ; Mon, 3 Jun 2013 03:15:42 -0700 (PDT) Received: from mail2.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.13.6/8.13.6) with ESMTP id r53AFZTf032586 for ; Mon, 3 Jun 2013 12:15:36 +0200 Received: from DEFTHW99ET9MSX.ww902.siemens.net ([157.163.148.60]) by mail2.sbs.de (8.13.6/8.13.6) with ESMTP id r53AFZMV007671 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 3 Jun 2013 12:15:35 +0200 Received: from DEFTHW99ERBMSX.ww902.siemens.net (139.22.70.76) by DEFTHW99ET9MSX.ww902.siemens.net (157.163.148.60) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 3 Jun 2013 12:15:35 +0200 Received: from DEFTHW99EK5MSX.ww902.siemens.net ([169.254.6.137]) by DEFTHW99ERBMSX.ww902.siemens.net ([139.22.70.76]) with mapi id 14.02.0342.003; Mon, 3 Jun 2013 12:15:35 +0200 From: "Albrecht, Harald" To: "mdnsext@ietf.org" Thread-Topic: [mdnsext] Discussion of BoF during Berlin IETF Thread-Index: AQHOVxYCoLNfrYhO9UyyRiqKaj691JkejPwAgAAyUgCABRcrcA== Date: Mon, 3 Jun 2013 10:15:34 +0000 Message-ID: References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> <5c24b7358f8e4adb71187a17df9fc6bb@xs4all.nl> In-Reply-To: <5c24b7358f8e4adb71187a17df9fc6bb@xs4all.nl> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.32] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 10:15:50 -0000 Ralph, Peter, now coming forward as I have been a lurker on this mailing list for some ti= me. Multi-link networks without DNS infrastructure are a topic I'm also int= erested in; and also optionally handling hierarchical mDNS domains. I'll mo= st probably attend the IETF 87 meeting in Berlin. -- Harald Siemens AG Industry Sector Industry Automation Division Industrial Automation Systems I IA AS CTO DH 1 Gleiwitzer Str. 555 90475 Nuernberg, Germany Tel: +49 911 895-3847 Fax: +49 911 895-2105 Mobile: +49 16093785110 mailto:harald.albrecht@siemens.com Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Crom= me; Managing Board: Peter Loescher, Chairman, President and Chief Executive= Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbar= a Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Sue= ss; Registered offices: Berlin and Munich, Germany; Commercial registries: = Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 236913= 22 > -----Urspr=FCngliche Nachricht----- > Von: mdnsext-bounces@ietf.org [mailto:mdnsext-bounces@ietf.org] Im > Auftrag von peter van der Stok > Gesendet: Freitag, 31. Mai 2013 08:24 > An: mdnsext@ietf.org > Betreff: Re: [mdnsext] Discussion of BoF during Berlin IETF >=20 > Ralph, >=20 > I am certainly interested in this work and agree with the charter, which = has > improved with respect to the former version. > From the point of view of building control, it is essential to do disove= ry on a > multilink stand-alone network, and not needing to change the applications > when the network is connected to a backbone with access to DNS. From the > outside the resources on the now connected network should be visible with > the same names, possibly suffixed with additional domain name information= . >=20 > In the past I have commented on the requirements and I am looking forward > to a new version. >=20 > Peter van der Stok. >=20 > Ralph Droms schreef op 2013-05-31 05:24: > > REMINDER!!!! > > > > I'm looking for review and discussion of the BoF proposal and draft > > charter here: > > http://www.ietf.org/mail-archive/web/mdnsext/current/msg00149.html > > > > The mailing list has been quiet (0 responses so far). Is there still > > interest in taking on this work? > > > > - Ralph Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1061B21F8624 for ; Mon, 3 Jun 2013 01:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qVNmEaq4FdeT for ; Mon, 3 Jun 2013 01:21:14 -0700 (PDT) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by ietfa.amsl.com (Postfix) with ESMTP id C283521F8EB3 for ; Mon, 3 Jun 2013 01:20:47 -0700 (PDT) Received: from roundcube.xs4all.nl (roundcube6.xs4all.net [194.109.20.204]) by smtp-vbr9.xs4all.nl (8.13.8/8.13.8) with ESMTP id r538K6lv074315 for ; Mon, 3 Jun 2013 10:20:07 +0200 (CEST) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-76-97.w90-0.abo.wanadoo.fr ([90.0.171.97]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 03 Jun 2013 10:20:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 03 Jun 2013 10:20:06 +0200 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: Message-ID: <3f9e642cbdc6f8bb1a996f786bc61b09@xs4all.nl> X-Sender: stokcons@xs4all.nl (JxnD6FTgE2CuYP14A4Lp8ss4HicyBBRB) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.org List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2013 08:21:26 -0000 Hi John, Very few, naive wishes about autonomous SD data access. The home, and also the buiding control installation, can and will be separated temporarily from the internet connection provided by Internet providers. Having autonomous access to SD data in the home (building), with a painless (dis)connection to(from) the Internet provider, is one of my prime concerns for joining this wg. Scalability of the SD data access inside the autonomous network (using a server) is equally important. Naming inside and outside home should be consistent. My examples: Inside names: like mydevice.a-local-domain, where a-local-domain can be empty Outside names like mydevice.a-local-domain.xs4all-given-domain. or myhost.mydomain.my-outside-domain-name. Possibly, the dot for specifying FQDN can be used to distinguish autonomous SD data from fully qualified outside data. If local. suffix is needed, a special layer to filter out the local. to the application would be welcome. Separating the work such that parts of the work are moved forward independently, but in mutual agreement, sounds great. Peter Brzozowski, John schreef op 2013-06-01 16:07: > I just took a quick look at the proposal as well, seems to cover most > essential areas. I see that Zigbee was called out, it might be good > to > ensure that it is clear that the home is called out as a key use case. > > Peter, > > Regarding your comment below what are your thought around separately > internal and external access to SD data. Specifically I am thinking > SD > within the home as alluded below can and perhaps should be autonomous. > I > think it may be useful to split up how SD is performed in a premise > from > how it may be made available northbound either by a service provider > or > other third party. Separating the work can help to ensure that we > move > parts of this work forward independently. > > John > ========================================= > John Jason Brzozowski > Comcast Cable > m) 484-962-0060 > o) 609-377-6594 > w) www.comcast6.net > e) john_brzozowski@cable.comcast.com > ========================================= > > > > > > > -----Original Message----- > From: peter van der Stok > Organization: vanderstok consultancy > Reply-To: "consultancy@vanderstok.org" > Date: Friday, May 31, 2013 2:24 AM > To: "mdnsext@ietf.org" > Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF > >> Ralph, >> >> I am certainly interested in this work and agree with the charter, >> which has improved with respect to the former version. >> From the point of view of building control, it is essential to do >> disovery on a multilink stand-alone network, and not needing to >> change >> the applications when the network is connected to a backbone with >> access >> to DNS. From the outside the resources on the now connected network >> should be visible with the same names, possibly suffixed with >> additional >> domain name information. >> >> In the past I have commented on the requirements and I am looking >> forward to a new version. >> >> Peter van der Stok. >> >> Ralph Droms schreef op 2013-05-31 05:24: >>> REMINDER!!!! >>> >>> I'm looking for review and discussion of the BoF proposal and draft >>> charter here: >>> http://www.ietf.org/mail-archive/web/mdnsext/current/msg00149.html >>> >>> The mailing list has been quiet (0 responses so far). Is there >>> still >>> interest in taking on this work? >>> >>> - Ralph >>> >>> _______________________________________________ >>> mdnsext mailing list >>> mdnsext@ietf.org >>> https://www.ietf.org/mailman/listinfo/mdnsext >> _______________________________________________ >> mdnsext mailing list >> mdnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/mdnsext > > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8441521F91CA for ; Sun, 2 Jun 2013 14:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzvFN2aQKkj8 for ; Sun, 2 Jun 2013 14:06:38 -0700 (PDT) Received: from mail.porchdog.net (mail.porchdog.net [208.64.57.120]) by ietfa.amsl.com (Postfix) with ESMTP id 6EEC021F86CA for ; Sun, 2 Jun 2013 14:06:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.porchdog.net (Postfix) with ESMTP id 992E11807B9E for ; Sun, 2 Jun 2013 14:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at local Received: from mail.porchdog.net ([127.0.0.1]) by localhost (mail.collobos.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dzdh2X0f1aMv for ; Sun, 2 Jun 2013 14:06:35 -0700 (PDT) Received: from [192.168.175.96] (c-67-169-85-232.hsd1.ca.comcast.net [67.169.85.232]) by mail.porchdog.net (Postfix) with ESMTPSA id EA7851807B90 for ; Sun, 2 Jun 2013 14:06:34 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Scott Herscher In-Reply-To: <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> Date: Sun, 2 Jun 2013 14:06:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <306C0211-4DEA-449A-8092-ED39527773D6@collobos.com> References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> To: mdnsext@ietf.org X-Mailer: Apple Mail (2.1503) Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Jun 2013 21:06:48 -0000 We're very interested in this work. Collobos Software is currently in = beta with an AirPrint print server product that has an embedded dns = server in it for handling unicast dns-sd queries. We are planning to = build on our work to create a separate standalone product that realizes = the ideas laid out in this proposal. Scott On May 30, 2013, at 8:24 PM, Ralph Droms wrote: > REMINDER!!!! >=20 > I'm looking for review and discussion of the BoF proposal and draft = charter here: = http://www.ietf.org/mail-archive/web/mdnsext/current/msg00149.html >=20 > The mailing list has been quiet (0 responses so far). Is there still = interest in taking on this work? >=20 > - Ralph >=20 > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713D721F9ED2 for ; Sat, 1 Jun 2013 07:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8yotanGsb6i for ; Sat, 1 Jun 2013 07:07:55 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 8033F21F9ED5 for ; Sat, 1 Jun 2013 07:07:55 -0700 (PDT) Received: from ([24.40.56.114]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.74687699; Sat, 01 Jun 2013 08:06:00 -0600 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.173]) by PACDCEXHUB01.cable.comcast.com ([fe80::84e8:95f3:f13b:169e%12]) with mapi id 14.02.0318.001; Sat, 1 Jun 2013 10:07:52 -0400 From: "Brzozowski, John" To: "consultancy@vanderstok.org" , "mdnsext@ietf.org" Thread-Topic: [mdnsext] Discussion of BoF during Berlin IETF Thread-Index: AQHOXa6cpLNXm10H/UO639ARcA9srpkfFrIAgAHQ1wA= Date: Sat, 1 Jun 2013 14:07:50 +0000 Message-ID: In-Reply-To: <5c24b7358f8e4adb71187a17df9fc6bb@xs4all.nl> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [24.40.55.73] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 14:08:00 -0000 I just took a quick look at the proposal as well, seems to cover most essential areas. I see that Zigbee was called out, it might be good to ensure that it is clear that the home is called out as a key use case. Peter, Regarding your comment below what are your thought around separately internal and external access to SD data. Specifically I am thinking SD within the home as alluded below can and perhaps should be autonomous. I think it may be useful to split up how SD is performed in a premise from how it may be made available northbound either by a service provider or other third party. Separating the work can help to ensure that we move parts of this work forward independently. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 o) 609-377-6594 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: peter van der Stok Organization: vanderstok consultancy Reply-To: "consultancy@vanderstok.org" Date: Friday, May 31, 2013 2:24 AM To: "mdnsext@ietf.org" Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF >Ralph, > >I am certainly interested in this work and agree with the charter, >which has improved with respect to the former version. > From the point of view of building control, it is essential to do >disovery on a multilink stand-alone network, and not needing to change >the applications when the network is connected to a backbone with access >to DNS. From the outside the resources on the now connected network >should be visible with the same names, possibly suffixed with additional >domain name information. > >In the past I have commented on the requirements and I am looking >forward to a new version. > >Peter van der Stok. > >Ralph Droms schreef op 2013-05-31 05:24: >> REMINDER!!!! >>=20 >> I'm looking for review and discussion of the BoF proposal and draft >> charter here: >> http://www.ietf.org/mail-archive/web/mdnsext/current/msg00149.html >>=20 >> The mailing list has been quiet (0 responses so far). Is there still >> interest in taking on this work? >>=20 >> - Ralph >>=20 >> _______________________________________________ >> mdnsext mailing list >> mdnsext@ietf.org >> https://www.ietf.org/mailman/listinfo/mdnsext >_______________________________________________ >mdnsext mailing list >mdnsext@ietf.org >https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE1E21F9C89 for ; Sat, 1 Jun 2013 06:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.231 X-Spam-Level: X-Spam-Status: No, score=-105.231 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hr4QomtnRYMc for ; Sat, 1 Jun 2013 06:58:08 -0700 (PDT) Received: from cable.comcast.com (copdcavout01.cable.comcast.com [76.96.32.253]) by ietfa.amsl.com (Postfix) with ESMTP id 12DBB21F99A9 for ; Sat, 1 Jun 2013 06:58:07 -0700 (PDT) Received: from ([24.40.56.115]) by copdcavout01.cable.comcast.com with ESMTP id C7WM3M1.74686690; Sat, 01 Jun 2013 07:56:11 -0600 Received: from PACDCEXCAS20.cable.comcast.com (24.40.56.118) by PACDCEXHUB02.cable.comcast.com (24.40.56.115) with Microsoft SMTP Server (TLS) id 14.2.318.1; Sat, 1 Jun 2013 09:58:02 -0400 Received: from PACDCEXMB01.cable.comcast.com ([169.254.1.173]) by pacdcexcas20.cable.comcast.com ([fe80::b919:e44:27e1:1328%18]) with mapi id 14.02.0318.001; Sat, 1 Jun 2013 09:58:02 -0400 From: "Brzozowski, John" To: Ralph Droms , "mdnsext@ietf.org" Thread-Topic: [mdnsext] Discussion of BoF during Berlin IETF Thread-Index: AQHOXa6cpLNXm10H/UO639ARcA9srpkg5MwA Date: Sat, 1 Jun 2013 13:58:00 +0000 Message-ID: In-Reply-To: <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [24.40.55.73] Content-Type: text/plain; charset="us-ascii" Content-ID: <8B4D8DC170E51F4CA6D3547594F633E3@cable.comcast.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 13:58:14 -0000 Ralph, Apologies for the delay, I am interested in this work and will try to read up and send comments. Progress here is important and I fear we are already getting behind. With this said I am looking forward to the meeting in Berlin and hope to send comments shortly. John =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D John Jason Brzozowski Comcast Cable m) 484-962-0060 o) 609-377-6594 w) www.comcast6.net e) john_brzozowski@cable.comcast.com =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D -----Original Message----- From: Ralph Droms Date: Thursday, May 30, 2013 11:24 PM To: "mdnsext@ietf.org" Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF >REMINDER!!!! > >I'm looking for review and discussion of the BoF proposal and draft >charter here:=20 >http://www.ietf.org/mail-archive/web/mdnsext/current/msg00149.html > >The mailing list has been quiet (0 responses so far). Is there still >interest in taking on this work? > >- Ralph > >_______________________________________________ >mdnsext mailing list >mdnsext@ietf.org >https://www.ietf.org/mailman/listinfo/mdnsext Return-Path: X-Original-To: mdnsext@ietfa.amsl.com Delivered-To: mdnsext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B0421F8689 for ; Sat, 1 Jun 2013 04:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.15 X-Spam-Level: X-Spam-Status: No, score=-100.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOt6mYad3r4D for ; Sat, 1 Jun 2013 04:32:42 -0700 (PDT) Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [IPv6:2607:f8b0:400c:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 6152821F867B for ; Sat, 1 Jun 2013 04:32:42 -0700 (PDT) Received: by mail-vb0-f54.google.com with SMTP id f13so1669287vbg.13 for ; Sat, 01 Jun 2013 04:32:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=NLibD0NJV/afw3TgOMG8BdaxfjEFRTxDXe2LOrJOOBY=; b=LjCfQffsxi29OOmUYrWh46/0z84OcU5QOb0RIynjllURJ0RQ5TsrWGbAogNCV4GeR/ AfLQ7CGRZEBP7Y7R7HQOxJrDPC87xilfLRyJCxwf083DkmvJuPpDYxUzkAA3SDQj+J52 cgXyCGmMnrCiGh6r73Mnn7sJtXZR1WJGwfx4X6Vq1jd02POLad7S0sitdDxM17bkHBhb Eprt9jdlzLNHAcR0q8JbYN6HVyW+7XlVm3h5TRNS/ixvab05QP0uH7H2bC0aYJGxQDoT NsPu6PVweWpeMdIRQnXkTmwOQkil3jeLsTBDHbOPA3bG+Xf5uCjd2fcyJoAG7FX5oA3V rzww== X-Received: by 10.59.6.101 with SMTP id ct5mr14010721ved.8.1370086361738; Sat, 01 Jun 2013 04:32:41 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:a08a:ac0b:cffb:2ef0? ([2001:420:2481:20:a08a:ac0b:cffb:2ef0]) by mx.google.com with ESMTPSA id wl4sm39018136vdb.3.2013.06.01.04.32.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 01 Jun 2013 04:32:40 -0700 (PDT) Content-Type: text/plain; charset=euc-kr Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Ralph Droms In-Reply-To: Date: Sat, 1 Jun 2013 07:32:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14CE323C-0BCC-4B7F-976C-10070E156046@gmail.com> <783F7CF8-7FDB-4F93-82C2-4291E329F844@gmail.com> To: Daniel Park X-Mailer: Apple Mail (2.1503) Cc: mdnsext@ietf.org Subject: Re: [mdnsext] Discussion of BoF during Berlin IETF X-BeenThere: mdnsext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Discussion of extensions to Bonjour \(mDNS and DNS-SD\) for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 11:32:43 -0000 On May 31, 2013, at 5:18 AM 5/31/13, Daniel Park = wrote: > Just curious why mDNS was originally developed for a single link? Any = special reasons from the beginning? Scaling - managing the amount of multicast traffic, which otherwise can = become burdensome across a larger scope. - Ralph >=20 > Soohong Daniel Park >=20 > 2013. 5. 31. =BF=C0=C8=C4 12:26=BF=A1 "Ralph Droms" = =B4=D4=C0=CC =C0=DB=BC=BA: > REMINDER!!!! >=20 > I'm looking for review and discussion of the BoF proposal and draft = charter here: = http://www.ietf.org/mail-archive/web/mdnsext/current/msg00149.html >=20 > The mailing list has been quiet (0 responses so far). Is there still = interest in taking on this work? >=20 > - Ralph >=20 > _______________________________________________ > mdnsext mailing list > mdnsext@ietf.org > https://www.ietf.org/mailman/listinfo/mdnsext