From ecrit-bounces@ietf.org Sun Jul 02 17:54:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx9tQ-0002is-P8; Sun, 02 Jul 2006 17:54:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx9tN-0002P7-FS for ecrit@ietf.org; Sun, 02 Jul 2006 17:54:13 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx9kI-0005zc-A5 for ecrit@ietf.org; Sun, 02 Jul 2006 17:44:51 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 02 Jul 2006 14:44:50 -0700 X-IronPort-AV: i="4.06,199,1149490800"; d="scan'208"; a="1834549890:sNHT29295420" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k62LinB1010389 for ; Sun, 2 Jul 2006 14:44:49 -0700 Received: from [192.168.1.2] (sjc-vpn6-311.cisco.com [10.21.121.55]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k62LincL028191 for ; Sun, 2 Jul 2006 14:44:49 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Cullen Jennings Date: Sun, 2 Jul 2006 14:44:47 -0700 X-Mailer: Apple Mail (2.750) DKIM-Signature: a=rsa-sha1; q=dns; l=1531; t=1151876689; x=1152740689; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:Cullen=20Jennings=20 |Subject:draft-ietf-lost-00=20and=20lost=20regions; X=v=3Dcisco.com=3B=20h=3DrudIalW9/ApFZ+lLITtuqZnIyBg=3D; b=UO6mMYMOA8h3FFnUlGwBfb+RhzjmBwzNnxi5hYWkZHweZ6yRpPLw1qZv6F+m9JIdB+dzhCGS Vh6ZQmqm+T2oytelUaienSL/XC5lNaKqhitCQFvT3NhNFJgZ8v1QTBNK; Authentication-Results: sj-dkim-6.cisco.com; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Subject: [Ecrit] draft-ietf-lost-00 and lost regions X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In the responseGeo messages, I'm not sure I understand what the Polygon gets used for. I'm assuming this is so a device like a mobile phone can determine when it moves outside the polygon and needs to redo the query or should not use the service URI provided in that response. I'm a little worried about the geographic size and accuracy of these polygons, the size of the response on the wire, and the complexity on the device of determining if a point is inside the polygon. I realize I may have mistaken assumptions here. If the polygon is defined as a polygon that includes the query location and is guaranteed that the URI work anywhere within the polygon, then the polygon could be a small subset of the overall region where the URIs are valid. This combined with some constraints on how the polygons were generated might help deal with complexity and size issues. Depending on what this data is used for, there might be other ways to solve this too - for example, the response providing a distance from the query location with a guarantee that any place with that distance of the query point was within the region with the same service URI. This approach would have problems near the edge of the PSAP boundary but I'm just tossing out ideas. I also wonder about how much of the GML polygon you really want - for example - do you want to deal with interior holes. Would you allow reference links (i.e. points instead of pos) to define the polygon. Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 02 19:30:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxBO8-0005qx-Fa; Sun, 02 Jul 2006 19:30:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxBO7-0005qp-1v for ecrit@ietf.org; Sun, 02 Jul 2006 19:30:03 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxBO5-0003j7-PK for ecrit@ietf.org; Sun, 02 Jul 2006 19:30:03 -0400 Received: from [192.168.0.41] (pool-138-89-20-244.mad.east.verizon.net [138.89.20.244]) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k62NTxM7025855 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 2 Jul 2006 19:30:00 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] draft-ietf-lost-00 and lost regions Date: Sun, 2 Jul 2006 19:29:56 -0400 To: Cullen Jennings X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jul 2, 2006, at 5:44 PM, Cullen Jennings wrote: > > In the responseGeo messages, I'm not sure I understand what the > Polygon gets used for. I'm assuming this is so a device like a > mobile phone can determine when it moves outside the polygon and > needs to redo the query or should not use the service URI provided > in that response. I'm a little worried about the geographic size > and accuracy of these polygons, the size of the response on the > wire, and the complexity on the device of determining if a point > is inside the polygon. I realize I may have mistaken assumptions here. This probably can be explained better, but the idea is that the polygon does not have to be terribly accurate. For example, you could embed a square or octagon in the county and do reasonably well until you reach the edges. At that point, the system may need to provide a more accurate rendition. Doing a point-in-polygon computation is relatively low cost, even for very large polygons. We have looked at typical county boundaries for the US, as provided by the US Census, and found that they are too large for a UDP packet, but not unreasonably large. In almost all circumstances except cross- country driving, the client would cache these in any event, as these boundaries are unlikely to change. (We took county boundaries as an approximation, realizing that PSAP and county boundaries may or may not coincide, but the properties should be somewhat similar.) > > If the polygon is defined as a polygon that includes the query > location and is guaranteed that the URI work anywhere within the > polygon, then the polygon could be a small subset of the overall > region where the URIs are valid. This combined with some > constraints on how the polygons were generated might help deal > with complexity and size issues. Depending on what this data is > used for, there might be other ways to solve this too - for This sounds similar to the notion discussed above. > example, the response providing a distance from the query location > with a guarantee that any place with that distance of the query > point was within the region with the same service URI. This > approach would have problems near the edge of the PSAP boundary but > I'm just tossing out ideas. The distance computation you mentioned can be done at the client, if desired. You can do other optimizations; for example, if you move along a relatively straight line (common while driving on a highway, say), the distance to the border of the polygon can be computed fairly accurately so that you do not have to do the point-in-polygon computation every few seconds and only have to re-check once you get close to the boundary. > > I also wonder about how much of the GML polygon you really want - > for example - do you want to deal with interior holes. Would you > allow reference links (i.e. points instead of pos) to define the > polygon. I think we have to deal with interior holes. These are not common, but apparently occur; the example I've been given is airports that have their own PSAP, surrounded by the county. > > Cullen > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 02 21:02:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxCpI-0005QG-R1; Sun, 02 Jul 2006 21:02:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxCpI-0005MS-5x for ecrit@ietf.org; Sun, 02 Jul 2006 21:02:12 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxCpH-0003j5-Rk for ecrit@ietf.org; Sun, 02 Jul 2006 21:02:12 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Jul 2006 20:02:09 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Sun, 02 Jul 2006 20:02:09 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Jul 2006 20:02:08 -0500 Message-ID: From: "Thomson, Martin" To: Date: Sun, 2 Jul 2006 20:00:44 -0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 03 Jul 2006 01:02:08.0472 (UTC) FILETIME=[4ED92D80:01C69E3C] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: draft-ietf-lost-00 comments Thread-Index: AcaePByNsaAo+bwhQaOa+4JcA7IV8g== X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [Ecrit] draft-ietf-lost-00 comments X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1579456068==" Errors-To: ecrit-bounces@ietf.org --===============1579456068== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message RWNyaXR0ZXJzLCBMb1NUIGZvbGtzLA0KDQpIZXJlIGFyZSBteSBjb21tZW50cyBvbiB0aGUgTG9T VCBkcmFmdC4gIFRoZXJlIGFyZSBvYnZpb3VzIGdhcHMgdGhhdCBJIGtub3cgeW91IGFyZSBzdGls bCB3b3JraW5nIG9uLCBzbyBJJ2xsIHRyeSB0byBhdm9pZCB0b28gbXVjaCBpbiB0aG9zZSBhcmVh cy4NCg0KDQpJbnRlcmVzdGluZyBjbGFpbToNCiAgIG8gIE1hcHBpbmcgY2FuIGJlIGJhc2VkIG9u IGVpdGhlciBjaXZpYyBvciBnZW9zcGF0aWFsIGxvY2F0aW9uDQogICAgICBpbmZvcm1hdGlvbiwg d2l0aCBubyBwZXJmb3JtYW5jZSBwZW5hbHR5IGZvciBlaXRoZXIuDQoNCi4uLnRoaXMgY291bGQg bG9vayBsaWtlIGEgY2xhaW0gYWJvdXQgYSBMb1NUIGRhdGFiYXNlIGltcGxlbWVudGF0aW9uLCB3 aGljaCB3b3VsZCBiZSBwcmVzdW1wdHVvdXMuICBTdWdnZXN0IHRoYXQgaXQgaXMgbWFkZSBhIGxp dHRsZSBjbGVhcmVyLiAgVGhpcyBsZWFkcyB0byBteSBuZXh0IHBvaW50Li4uDQoNClRoZSBmaW5k TG9TVEJ5R2VvIGFuZCBmaW5kTG9TVEJ5Q2l2aWMgKHRoZSBjYXBpdGFsaXphdGlvbiBtYWtlcyB0 aG9zZSB0b3VnaCB0byB0eXBlLCBCVFcpIGFyZSBmdW5kYW1lbnRhbGx5IGlkZW50aWNhbCwgc28g d2h5IGlzIHRoZXJlIGEgbmVlZCBmb3Igc2VwYXJhdGUgbmFtZXMgZm9yIHRoZXNlIHF1ZXJpZXM/ ICBJIHByZWZlcnJlZCB0aGUgZWFybGllciBpdGVyYXRpb25zIHdoZXJlIHRoZSBsb2NhdGlvbiB3 YXMganVzdCBhIGNob2ljZSBlbGVtZW50LiAgVGhlIGVsZW1lbnQgbmFtZSBpcyB0aGUgbmFtZSBv ZiB0aGUgb3BlcmF0aW9uLCBhbmQsIGluIHRlcm1zIG9mIHNlbWFudGljcywgdGhlcmUgaXMgb25s eSBvbmUgb3BlcmF0aW9uIGhlcmU6ICdmaW5kTG9TVCcuDQoNCkV4YW1wbGVzIGluY2x1ZGUgeHNp IG5hbWVzcGFjZSBwcmVmaXggZGVjbGFyYXRpb25zLg0KDQpZb3UgcmVmZXIgdG8gdGhlIGNpdmlj IGxvY2F0aW9uIGZvcm1hdCBpbiBSRkMgNDExOSByYXRoZXIgdGhhbiB0aGUgZm9ybWF0IGluIGRy YWZ0LWlldGYtZ2VvcHJpdi1yZXZpc2VkLWNpdmljLWxvLiAgVGhlIFJGQyA0MTE5IGZvcm1hdCBk b2Vzbid0IGluY2x1ZGUgYSByYW5nZSBvZiBlbGVtZW50cyB0aGF0IG1pZ2h0IGJlIG5lY2Vzc2Fy eS4gIChZb3UgaGF2ZSBkZWNsYXJlZCBhIE5TIHByZWZpeCBmb3IgdGhlIHJldmlzZWQgY2l2aWMg YWRkcmVzcyBpbiB0aGUgc2NoZW1hLCBidXQgaXQgaXNuJ3QgdXNlZC4pDQoNCi9TZWN0aW9uIDYv ICBJdCBpcyBwcm9iYWJseSB3b3J0aCBub3RpbmcgdGhhdCBvbmx5IG9uZSByZXN1bHQgaXMgcmV0 dXJuZWQuICBNdWx0aXBsZSBVUklzIGFyZSBvbmx5IHByb3ZpZGVkIGFzIGFsdGVybmF0aXZlIG1l YW5zIG9mIGNvbnRhY3QgZm9yIHRoYXQgb25lIGVudGl0eSwgaS5lLiBkaWZmZXJlbnQgc2NoZW1l cy4NCg0KL1NlY3Rpb24gNi4xLyAgUmVsYXRpdmUgVVJJcyBhcmUgbm90ZWQgYXMgYmVpbmcgU0hP VUxEIE5PVC4gIEhvd2V2ZXIsIGlmIGl0IGlzIHBvc3NpYmxlIHRvIHVzZSB0aGVtLCB0aGVyZSBu ZWVkcyB0byBiZSBzb21lIGd1aWRhbmNlIG9uIGhvdyB0byBkZXRlcm1pbmUgdGhlIGJhc2UgVVJJ LiAgVGhlcmUgbWlnaHQgYmUgc29tZSBjb25mdXNpb24gYWJvdXQgd2hldGhlciB0aGUgc2Vydmlj ZSBVUk4gaXMgdGhlIGJhc2UgVVJJIG9yIG5vdCAoYW5kIEkgY2FuJ3Qgc2VlIGhvdyB0aGlzIHdv dWxkIGJlIHBvc3NpYmxlIHVubGVzcyB5b3Ugd2FudCByZWN1cnNpdmUgcmVzb2x1dGlvbi4uLmFu ZCBJJ20gc3VyZSB5b3UgYXJlbid0IGNvbXBsZXRlbHkgaW5zYW5lKS4gIEhlcmUgaXMgdGhlIGxp c3QgeW91IHVzZSBmb3IgYmFzZSBVUkkgcmVzb2x1dGlvbjoNCg0KICAgMS4gVGhlIGJhc2UgVVJJ IGlzIGVtYmVkZGVkIGluIHRoZSBkb2N1bWVudCdzIGNvbnRlbnQuDQogICAyLiBUaGUgYmFzZSBV UkkgaXMgdGhhdCBvZiB0aGUgZW5jYXBzdWxhdGluZyBlbnRpdHkgKG1lc3NhZ2UsIGRvY3VtZW50 LCBvciBub25lKS4NCiAgIDMuIFRoZSBiYXNlIFVSSSBpcyB0aGUgVVJJIHVzZWQgdG8gcmV0cmll dmUgdGhlIGVudGl0eS4NCiAgIDQuIFRoZSBiYXNlIFVSSSBpcyBkZWZpbmVkIGJ5IHRoZSBjb250 ZXh0IG9mIHRoZSBhcHBsaWNhdGlvbi4NCg0KSSBjYW4ndCBzZWUgd2hpY2ggb2YgdGhlc2UgYXJl IHJlYWxpc3RpY2FsbHkgYXBwbGljYWJsZS4gIEkgd291bGQgcHJlZmVyIGlmIHlvdSBwcmV2ZW50 ZWQgcmVsYXRpdmUgVVJJcyBieSB1c2luZyBhIHJlZ2V4Og0KDQogIDx4czpwYXR0ZXJuIHZhbHVl PSJbYS16QS1aXVstYS16QS1aK1wuXSo6LioiLz4NCg0KL1NlY3Rpb24gNi42LyBzL2J5IGJ5L2J5 Lw0KDQogIFRoaXMgc2VjdGlvbiBhbHNvIG5lZWRzIHRvIG1ha2UgaXQgY2xlYXIgdGhhdCAidmFs aWRhdGVkIiBkb2Vzbid0IGFwcGx5IHRvIGdlb2RldGljIGluZm9ybWF0aW9uLg0KDQovU2VjdGlv biA2LjMvIHMvb25lIG9yIG1vcmUgY2l2aWMgbG9jYXRpb24vb25lIG9yIG1vcmUgbG9jYXRpb24v DQoNCiAgSSB3b3VsZCBhbHNvIGxpa2UgdG8gc2VlIHRoZSBQb2x5Z29uIGVsZW1lbnQgd3JhcHBl ZCBpbiBzb21lIG1hbm5lciBjb25zaXN0ZW50IHdpdGggR01MIHByYWN0aWNlOg0KDQogIDxyZXNw b25zZUdlbz4NCiAgICA8cmVnaW9uPg0KICAgICAgPGdtbDpQb2x5Z29uPi4uLjwvZ21sOlBvbHln b24NCiAgICA8L3JlZ2lvbj4NCiAgICAuLi4NCiAgPC9yZXNwb25zZUdlbz4NCg0KQWdhaW4sIHRo ZSByZXNwb25zZUdlbyBhbmQgcmVzcG9uc2VDaXZpYyBlbGVtZW50cyBhcmUgbGFyZ2VseSBpZGVu dGljYWw7IHR3byBkaWZmZXJlbnQgZWxlbWVudHMgZ2l2ZSBhbiBpbXByZXNzaW9uIG9mIGEgc2Vw YXJhdGlvbi4NCg0KVGhlIHNpbWlsYXJpdGllcyBiZXR3ZWVuIHRoZSBkaWZmZXJlbnQgcmVzdWx0 IHR5cGVzIGNvdWxkIGJlIGZ1cnRoZXIgZXhwbG9pdGVkIHdpdGggdGhlIGRlZmluaXRpb24gb2Yg dGhlIGJhc2UgdHlwZSBsb3N0OnJlc3VsdFR5cGUuIA0KDQpJbiBzY2hlbWEsIHRoZSByZXNwb25z ZUNpdmljIGRvZXNuJ3QgaW5jbHVkZSBhIGRlZmluaXRpb24gZm9yIHZhbGlkYXRlZC4gIEJvdGgg cmVzcG9uc2UgdHlwZXMgZG9uJ3QgaW5jbHVkZSB0aGUgInRleHQiIGVsZW1lbnQuDQoNCldoeSBp cyB0aGVyZSBhIGxvd2VyIGxpbWl0IG9mIHplcm8gb24gdGhlIFVSSSBpbiB0aGUgcmVzcG9uc2U/ ICBTaG91bGRuJ3QgdGhlcmUgYmUgYW4gZXJyb3IgY29kZSBmb3IgIndlIGNhbid0IGZpbmQgaXQi LCBvciBpcyB0aGUgYW5zd2VyIGp1c3QgbXlzdGVyaW91c2x5IG1pc3Npbmcgd2hlbiB0aGF0IGhh cHBlbnM/DQoNClRoZSBkaWFsc3RyaW5nIGVsZW1lbnQgc2hvdWxkIGluY2x1ZGUgc3RyaWN0ZXIg cmVzdHJpY3Rpb25zIHRoYW4ganVzdCBub3JtYWxpemVkU3RyaW5nLiAgSXMgdGhpcyBkaWdpdHMg b25seT8gIE9yIGRvIHlvdSB3YW50IHRvIHN1cHBvcnQgMS04MDAtNTU1LUZPT0QgaW4gdGhlIGRp YWxzdHJpbmcgKGFuZCB0aGUgZ2FtdXQgb2YgbG9jYWxpemVkIHZhcmlhdGlvbnMpPw0KDQpUaGUg ZXJyb3IgY29kZXMgc2hvdWxkIG5vdCBiZSByZWZsZWN0ZWQgaW4gZGlmZmVyZW50IGVycm9yIG1l c3NhZ2UgZWxlbWVudHMuICBUaGlzIG1ha2VzIGl0IG1lc3N5IHRvIGRvIHRoaW5ncyBsaWtlIGRl ZmluZSBNSU1FIHR5cGVzIGlmIHRoZSByb290IGVsZW1lbnQgY2hhbmdlcy4gIEVycm9yIGNvZGVz IHRoYXQgYXJlbid0IHVuZGVyc3Rvb2QgYnkgYW4gaW1wbGVtZW50YXRpb24gYXJlIGhhcmRlciB0 byByZWNvZ25pemUgaWYgdGhlIGVsZW1lbnQgY2hhbmdlcy4gIEl0IGFsc28gbWl4ZXMgY29udGVu dCBhbmQgc3RydWN0dXJlIGluIGEgd2F5IHRoYXQgSSBkb24ndCBsaWtlLiAgSSB3b3VsZCBwcmVm ZXIgdG8gc2VlIHNvbWV0aGluZyBsaWtlOg0KDQogICA8ZXJyb3IgY29kZT0iaW52YWxpZGNpdmlj IiB4bWw6bGFuZz0iZW4iPg0KICAgICBUaGF0IHdhcyBuYXVnaHR5Lg0KICAgPC9lcnJvcj4NCg0K SG93IGRvIHlvdSB3YW50IHRvIGRvIGVycm9yIGNvZGVzPyAgV2lsbCB5b3Ugc2V0dXAgYW4gSUFO QSByZWdpc3RyeT8gIFdpbGwgeW91IHBlcm1pdCBleHRlbnNpb25zIHRvIHRoZSBzZXQgb2YgZXJy b3JzPyAgU29ycnksIEkganVzdCBnb3QgaW50byB0aGUgdW5kZWZpbmVkIHRlcnJpdG9yeS4NCg0K Q2hlZXJzLA0KTWFydGluIA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBh bmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJp dmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBs ZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2lu YWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ== --===============1579456068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1579456068==-- From ecrit-bounces@ietf.org Sun Jul 02 21:35:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxDL4-0003GA-K5; Sun, 02 Jul 2006 21:35:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxDL3-0003G3-0d for ecrit@ietf.org; Sun, 02 Jul 2006 21:35:01 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxDL1-0004TK-KN for ecrit@ietf.org; Sun, 02 Jul 2006 21:35:00 -0400 Received: from [10.0.1.104] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Sun, 02 Jul 2006 21:35:15 -0400 id 01588037.44A87453.00007659 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88C489E0-B11C-4C20-988E-ABF113E47C33@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] draft-ietf-lost-00 comments Date: Sun, 2 Jul 2006 21:34:55 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jul 2, 2006, at 9:00 PM, Thomson, Martin wrote: > The findLoSTByGeo and findLoSTByCivic (the capitalization makes > those tough to type, BTW) are fundamentally identical, so why is > there a need for separate names for these queries? I preferred the > earlier iterations where the location was just a choice element. > The element name is the name of the operation, and, in terms of > semantics, there is only one operation here: 'findLoST'. Changing this to a single query is mostly dependent on the outcome of the discussion this working group has had regarding multiple locations in a query. We discussed changing this just before submitting the draft but determined that the true shape of the query will be based on the working groups discussion on this topic, so we left it alone. You are right, it could be converted to a single 'findLoST'. Looking at this query from the standpoint of a recursive resolver, which hierarchy is used in a composite location scenario? The actual specification of byGeo or byCivic might answer that question. I stress "might" as I have not thought long and hard about this particular problem. > Examples include xsi namespace prefix declarations. Harmless, but yes they should be removed. Won't matter when we switch to Relax NG. > The dialstring element should include stricter restrictions than > just normalizedString. Is this digits only? Or do you want to > support 1-800-555-FOOD in the dialstring (and the gamut of > localized variations)? I understand this point, but ultimately if a server wishes to spew crap back to a client there is very little a client can do about it. > The error codes should not be reflected in different error message > elements. This makes it messy to do things like define MIME types > if the root element changes. Error codes that aren't understood by > an implementation are harder to recognize if the element changes. > It also mixes content and structure in a way that I don't like. I > would prefer to see something like: > > > That was naughty. > I really don't care which way this is done, but I'm not sure your reason regarding the MIME type is correct. Otherwise text/xml or application/xml would never be used, which we know not to be the case. With regard to recognition of the element names, that's why there is an XML namespace. > How do you want to do error codes? Will you setup an IANA > registry? Will you permit extensions to the set of errors? Sorry, > I just got into the undefined territory. Versioning of the protocol is how I would prefer to do it, which probably means I lean much more towards keeping the current element names. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 03 02:05:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxHYd-0004WF-3k; Mon, 03 Jul 2006 02:05:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxHXz-0003eu-F9 for ecrit@ietf.org; Mon, 03 Jul 2006 02:04:39 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxHV3-0008R6-1M for ecrit@ietf.org; Mon, 03 Jul 2006 02:01:38 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 01:01:36 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 03 Jul 2006 01:01:35 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 01:01:35 -0500 Message-ID: From: "Thomson, Martin" To: "Andrew Newton" Date: Mon, 3 Jul 2006 01:01:32 -0500 Subject: RE: [Ecrit] draft-ietf-lost-00 comments MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 03 Jul 2006 06:01:35.0566 (UTC) FILETIME=[241226E0:01C69E66] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <88C489E0-B11C-4C20-988E-ABF113E47C33@hxr.us> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] draft-ietf-lost-00 comments Thread-Index: AcaeW5ofU6J8AUWoTzip8XNSBOxBXAAAwGuA X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0121276691==" Errors-To: ecrit-bounces@ietf.org --===============0121276691== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SGkgQW5keSwNCg0KVGhhbmtzIGZvciB0aGUgcmVzcG9uc2U7IEkndmUgcmVwbGllZCBpbmxpbmUu DQoNCkNoZWVycywNCk1hcnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IEFuZHJldyBOZXd0b24gW21haWx0bzphbmR5QGh4ci51c10NCj4gU2VudDogTW9uZGF5LCAz IEp1bHkgMjAwNiAxMTozNSBBTQ0KPiBUbzogVGhvbXNvbiwgTWFydGluDQo+IENjOiBlY3JpdEBp ZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0Vjcml0XSBkcmFmdC1pZXRmLWxvc3QtMDAgY29tbWVu dHMNCj4gDQo+IA0KPiBPbiBKdWwgMiwgMjAwNiwgYXQgOTowMCBQTSwgVGhvbXNvbiwgTWFydGlu IHdyb3RlOg0KPiA+IFRoZSBmaW5kTG9TVEJ5R2VvIGFuZCBmaW5kTG9TVEJ5Q2l2aWMgKHRoZSBj YXBpdGFsaXphdGlvbiBtYWtlcw0KPiA+IHRob3NlIHRvdWdoIHRvIHR5cGUsIEJUVykgYXJlIGZ1 bmRhbWVudGFsbHkgaWRlbnRpY2FsLCBzbyB3aHkgaXMNCj4gPiB0aGVyZSBhIG5lZWQgZm9yIHNl cGFyYXRlIG5hbWVzIGZvciB0aGVzZSBxdWVyaWVzPyAgSSBwcmVmZXJyZWQgdGhlDQo+ID4gZWFy bGllciBpdGVyYXRpb25zIHdoZXJlIHRoZSBsb2NhdGlvbiB3YXMganVzdCBhIGNob2ljZSBlbGVt ZW50Lg0KPiA+IFRoZSBlbGVtZW50IG5hbWUgaXMgdGhlIG5hbWUgb2YgdGhlIG9wZXJhdGlvbiwg YW5kLCBpbiB0ZXJtcyBvZg0KPiA+IHNlbWFudGljcywgdGhlcmUgaXMgb25seSBvbmUgb3BlcmF0 aW9uIGhlcmU6ICdmaW5kTG9TVCcuDQo+IA0KPiBDaGFuZ2luZyB0aGlzIHRvIGEgc2luZ2xlIHF1 ZXJ5IGlzIG1vc3RseSBkZXBlbmRlbnQgb24gdGhlIG91dGNvbWUgb2YNCj4gdGhlIGRpc2N1c3Np b24gdGhpcyB3b3JraW5nIGdyb3VwIGhhcyBoYWQgcmVnYXJkaW5nIG11bHRpcGxlDQo+IGxvY2F0 aW9ucyBpbiBhIHF1ZXJ5LiAgV2UgZGlzY3Vzc2VkIGNoYW5naW5nIHRoaXMganVzdCBiZWZvcmUN Cj4gc3VibWl0dGluZyB0aGUgZHJhZnQgYnV0IGRldGVybWluZWQgdGhhdCB0aGUgdHJ1ZSBzaGFw ZSBvZiB0aGUgcXVlcnkNCj4gd2lsbCBiZSBiYXNlZCBvbiB0aGUgd29ya2luZyBncm91cHMgZGlz Y3Vzc2lvbiBvbiB0aGlzIHRvcGljLCBzbyB3ZQ0KPiBsZWZ0IGl0IGFsb25lLiAgWW91IGFyZSBy aWdodCwgaXQgY291bGQgYmUgY29udmVydGVkIHRvIGEgc2luZ2xlDQo+ICdmaW5kTG9TVCcuDQoN ClRoaXMgY2FuIGJlIHNlcGFyYXRlZCBmcm9tIHRoZSBjb21wb3NpdGUgbG9jYXRpb24gaXNzdWUu ICBJZiB0aGUgY29tcG9zaXRlIGhhcHBlbnMgdGhlbiBpdCBoYXMgdG8gYmUganVzdCBvbmUgcXVl cnksIGVhc3k7IGJ1dCBpZiBjb21wb3NpdGUgZG9lc24ndCBoYXBwZW4sIHRoZW4gSSB0aGluayB0 aGlzIGNvbW1lbnQgc3RpbGwgc3RhbmRzLiAgSSB0aGluayB0aGF0IGEgc2luZ2xlIHJlcXVlc3Qg aXMgZWFzaWVyIHRvIGRlYWwgd2l0aCAtIHRoZSBjaG9pY2UgaXMgaW4gdGhlIHR5cGUgb2YgbG9j YXRpb24gaW5mb3JtYXRpb24gcHJvdmlkZWQuDQoNCj4gTG9va2luZyBhdCB0aGlzIHF1ZXJ5IGZy b20gdGhlIHN0YW5kcG9pbnQgb2YgYSByZWN1cnNpdmUgcmVzb2x2ZXIsDQo+IHdoaWNoIGhpZXJh cmNoeSBpcyB1c2VkIGluIGEgY29tcG9zaXRlIGxvY2F0aW9uIHNjZW5hcmlvPyAgVGhlIGFjdHVh bA0KPiBzcGVjaWZpY2F0aW9uIG9mIGJ5R2VvIG9yIGJ5Q2l2aWMgbWlnaHQgYW5zd2VyIHRoYXQg cXVlc3Rpb24uICBJDQo+IHN0cmVzcyAibWlnaHQiIGFzIEkgaGF2ZSBub3QgdGhvdWdodCBsb25n IGFuZCBoYXJkIGFib3V0IHRoaXMNCj4gcGFydGljdWxhciBwcm9ibGVtLg0KDQpJIHRoaW5rIHRo YXQgaG93IGEgcmVjdXJzaXZlIG9yIGhpZXJhcmNoaWNhbCByZXNvbHZlciBvcGVyYXRlcyBjYW4g YmUgc2VwYXJhdGVkIGZyb20gdGhpcyBhcyB3ZWxsLg0KDQo+ID4gRXhhbXBsZXMgaW5jbHVkZSB4 c2kgbmFtZXNwYWNlIHByZWZpeCBkZWNsYXJhdGlvbnMuDQo+IA0KPiBIYXJtbGVzcywgYnV0IHll cyB0aGV5IHNob3VsZCBiZSByZW1vdmVkLiAgV29uJ3QgbWF0dGVyIHdoZW4gd2UNCj4gc3dpdGNo IHRvIFJlbGF4IE5HLg0KDQoid2hlbiI/ICBJIGd1ZXNzIHRoZSBpc3N1ZSB0cmFja2VyIGlzbid0 IHVwIHRvIGRhdGUuICBUaGF0J3MgY29vbC4NCg0KPiA+IFRoZSBkaWFsc3RyaW5nIGVsZW1lbnQg c2hvdWxkIGluY2x1ZGUgc3RyaWN0ZXIgcmVzdHJpY3Rpb25zIHRoYW4NCj4gPiBqdXN0IG5vcm1h bGl6ZWRTdHJpbmcuICBJcyB0aGlzIGRpZ2l0cyBvbmx5PyAgT3IgZG8geW91IHdhbnQgdG8NCj4g PiBzdXBwb3J0IDEtODAwLTU1NS1GT09EIGluIHRoZSBkaWFsc3RyaW5nIChhbmQgdGhlIGdhbXV0 IG9mDQo+ID4gbG9jYWxpemVkIHZhcmlhdGlvbnMpPw0KPiANCj4gSSB1bmRlcnN0YW5kIHRoaXMg cG9pbnQsIGJ1dCB1bHRpbWF0ZWx5IGlmIGEgc2VydmVyIHdpc2hlcyB0byBzcGV3DQo+IGNyYXAg YmFjayB0byBhIGNsaWVudCB0aGVyZSBpcyB2ZXJ5IGxpdHRsZSBhIGNsaWVudCBjYW4gZG8gYWJv dXQgaXQuDQoNClRydWUgJ251ZmYsIEknbGwgbGV0IHRoZSBkZXNpZ24gdGVhbSBzb3J0IHRoaXMg b25lIG91dC4gIEhlbm5pbmcganVzdCBnYXZlIG1lIGEgcnVuZG93biBvZiB0aGUgYWx0ZXJuYXRp dmVzIGFuZCBJIGNhbiBzZWUgdGhlIHRyYWRlb2ZmIGhlcmUuDQogDQo+ID4gVGhlIGVycm9yIGNv ZGVzIHNob3VsZCBub3QgYmUgcmVmbGVjdGVkIGluIGRpZmZlcmVudCBlcnJvciBtZXNzYWdlDQo+ ID4gZWxlbWVudHMuICBUaGlzIG1ha2VzIGl0IG1lc3N5IHRvIGRvIHRoaW5ncyBsaWtlIGRlZmlu ZSBNSU1FIHR5cGVzDQo+ID4gaWYgdGhlIHJvb3QgZWxlbWVudCBjaGFuZ2VzLiAgRXJyb3IgY29k ZXMgdGhhdCBhcmVuJ3QgdW5kZXJzdG9vZCBieQ0KPiA+IGFuIGltcGxlbWVudGF0aW9uIGFyZSBo YXJkZXIgdG8gcmVjb2duaXplIGlmIHRoZSBlbGVtZW50IGNoYW5nZXMuDQo+ID4gSXQgYWxzbyBt aXhlcyBjb250ZW50IGFuZCBzdHJ1Y3R1cmUgaW4gYSB3YXkgdGhhdCBJIGRvbid0IGxpa2UuICBJ DQo+ID4gd291bGQgcHJlZmVyIHRvIHNlZSBzb21ldGhpbmcgbGlrZToNCj4gPg0KPiA+ICAgIDxl cnJvciBjb2RlPSJpbnZhbGlkY2l2aWMiIHhtbDpsYW5nPSJlbiI+DQo+ID4gICAgICBUaGF0IHdh cyBuYXVnaHR5Lg0KPiA+ICAgIDwvZXJyb3I+DQo+IA0KPiBJIHJlYWxseSBkb24ndCBjYXJlIHdo aWNoIHdheSB0aGlzIGlzIGRvbmUsIGJ1dCBJJ20gbm90IHN1cmUgeW91cg0KPiByZWFzb24gcmVn YXJkaW5nIHRoZSBNSU1FIHR5cGUgaXMgY29ycmVjdC4gIE90aGVyd2lzZSB0ZXh0L3htbCBvcg0K PiBhcHBsaWNhdGlvbi94bWwgd291bGQgbmV2ZXIgYmUgdXNlZCwgd2hpY2ggd2Uga25vdyBub3Qg dG8gYmUgdGhlDQo+IGNhc2UuICBXaXRoIHJlZ2FyZCB0byByZWNvZ25pdGlvbiBvZiB0aGUgZWxl bWVudCBuYW1lcywgdGhhdCdzIHdoeQ0KPiB0aGVyZSBpcyBhbiBYTUwgbmFtZXNwYWNlLg0KDQpU aGlzIGlzIHdoeSBJIGFza2VkIHRoZSBxdWVzdGlvbiBiZWxvdy4gIFlvdXIgZXh0ZW5zaW9uIG1v ZGVsIGRldGVybWluZXMgdGhlIHZhbGlkaXR5IG9mIHRoaXMgYXBwcm9hY2guICBWZXJzaW9uaW5n IGlzIG9ubHkgb25lIGFzcGVjdCBvZiB0aGF0IC0gd2hldGhlciBvciBub3QgeW91IGFsbG93IGV4 dHJhIGNvZGVzIGFmZmVjdHMgdGhlIGRlY2lzaW9uLiAgVGhlIE1JTUUgdHlwZSBjb21tZW50IHdh cyBhIHN0cmF5IHRob3VnaHQgLSB0aGUgb3RoZXJzIGFjdHVhbGx5IGNvbmNlcm4gbWUgbW9yZS4g IENhcnJ5aW5nIHZhbHVlcyBpbiBlbGVtZW50IG5hbWVzIGhhcyBhIGxvbmcgdHJhZGl0aW9uLCBi dXQgaXQgaXNuJ3QgcGFydGljdWxhcmx5IHJvYnVzdCB3aXRoIHJlZ2FyZHMgdG8gbmV3IHZhbHVl cy4NCiANCj4gPiBIb3cgZG8geW91IHdhbnQgdG8gZG8gZXJyb3IgY29kZXM/ICBXaWxsIHlvdSBz ZXR1cCBhbiBJQU5BDQo+ID4gcmVnaXN0cnk/ICBXaWxsIHlvdSBwZXJtaXQgZXh0ZW5zaW9ucyB0 byB0aGUgc2V0IG9mIGVycm9ycz8gIFNvcnJ5LA0KPiA+IEkganVzdCBnb3QgaW50byB0aGUgdW5k ZWZpbmVkIHRlcnJpdG9yeS4NCj4gDQo+IFZlcnNpb25pbmcgb2YgdGhlIHByb3RvY29sIGlzIGhv dyBJIHdvdWxkIHByZWZlciB0byBkbyBpdCwgd2hpY2gNCj4gcHJvYmFibHkgbWVhbnMgSSBsZWFu IG11Y2ggbW9yZSB0b3dhcmRzIGtlZXBpbmcgdGhlIGN1cnJlbnQgZWxlbWVudA0KPiBuYW1lcy4N Cj4gDQo+IC1hbmR5DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBFY3JpdCBtYWlsaW5nIGxpc3QNCj4gRWNyaXRAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZWNyaXQNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNp Z25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJp ZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVs eSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlz IGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClttZjJd --===============0121276691== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0121276691==-- From ecrit-bounces@ietf.org Mon Jul 03 05:35:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxKpy-0000Mo-P1; Mon, 03 Jul 2006 05:35:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxKpx-0000Ma-Cv for ecrit@ietf.org; Mon, 03 Jul 2006 05:35:25 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxKpv-0000Lj-PG for ecrit@ietf.org; Mon, 03 Jul 2006 05:35:25 -0400 Received: (qmail invoked by alias); 03 Jul 2006 09:35:22 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp030) with SMTP; 03 Jul 2006 11:35:22 +0200 X-Authenticated: #29516787 Message-ID: <44A8E4DB.9080602@gmx.net> Date: Mon, 03 Jul 2006 11:35:23 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomson, Martin" Subject: Re: [Ecrit] draft-ietf-lost-00 comments References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Martin, thanks for the review. Let me address a few comments below: Thomson, Martin wrote: > Ecritters, LoST folks, > > Here are my comments on the LoST draft. There are obvious gaps that > I know you are still working on, so I'll try to avoid too much in > those areas. We want to discuss the gaps as well. > > Interesting claim: o Mapping can be based on either civic or > geospatial location information, with no performance penalty for > either. > > ...this could look like a claim about a LoST database implementation, > which would be presumptuous. Suggest that it is made a little > clearer. This leads to my next point... I have that we should rephrase it a bit. Now, it sounds a little bit like a marketing phrase to me. > > The findLoSTByGeo and findLoSTByCivic (the capitalization makes those > tough to type, BTW) are fundamentally identical, so why is there a > need for separate names for these queries? I preferred the earlier > iterations where the location was just a choice element. The element > name is the name of the operation, and, in terms of semantics, there > is only one operation here: 'findLoST'. I agree with Andy that we should deal with this aspect once we reached a conclusion with regard to the multiple/composite location query question. > > Examples include xsi namespace prefix declarations. Will be fixed. > > You refer to the civic location format in RFC 4119 rather than the > format in draft-ietf-geopriv-revised-civic-lo. The RFC 4119 format > doesn't include a range of elements that might be necessary. (You > have declared a NS prefix for the revised civic address in the > schema, but it isn't used.) Could you be more specific about the range of element aspect here? > > /Section 6/ It is probably worth noting that only one result is > returned. Multiple URIs are only provided as alternative means of > contact for that one entity, i.e. different schemes. Fine. > > /Section 6.1/ Relative URIs are noted as being SHOULD NOT. However, > if it is possible to use them, there needs to be some guidance on how > to determine the base URI. There might be some confusion about > whether the service URN is the base URI or not (and I can't see how > this would be possible unless you want recursive resolution...and I'm > sure you aren't completely insane). Here is the list you use for > base URI resolution: > > 1. The base URI is embedded in the document's content. 2. The base > URI is that of the encapsulating entity (message, document, or none). > 3. The base URI is the URI used to retrieve the entity. 4. The base > URI is defined by the context of the application. > > I can't see which of these are realistically applicable. I would > prefer if you prevented relative URIs by using a regex: > > > Hmmm. Sounds too complicated to me. Hence, we shouldn't use them. > /Section 6.6/ s/by by/by/ > > This section also needs to make it clear that "validated" doesn't > apply to geodetic information. You are right. I am still not happy about the term and the usage in Section 5.8 of draft-rosen-ecrit-emergency-framework-00.txt (for both geo and civic) is confusing. > > /Section 6.3/ s/one or more civic location/one or more location/ > > I would also like to see the Polygon element wrapped in some manner > consistent with GML practice: > > ... ... > Ok. > > Again, the responseGeo and responseCivic elements are largely > identical; two different elements give an impression of a separation. > > > The similarities between the different result types could be further > exploited with the definition of the base type lost:resultType. We could do that. > > In schema, the responseCivic doesn't include a definition for > validated. Both response types don't include the "text" element. That's true. It seems that we haven't copied the latest schema from http://www.tschofenig.priv.at/svn/draft-ietf-ecrit-lost/Schema/ to the draft. > > Why is there a lower limit of zero on the URI in the response? > Shouldn't there be an error code for "we can't find it", or is the > answer just mysteriously missing when that happens? Needs to be fixed. > > The dialstring element should include stricter restrictions than just > normalizedString. Is this digits only? Or do you want to support > 1-800-555-FOOD in the dialstring (and the gamut of localized > variations)? In some sense we noted this issue already at: http://www.tschofenig.priv.at:8080/lost/issue8 > > The error codes should not be reflected in different error message > elements. This makes it messy to do things like define MIME types if > the root element changes. Error codes that aren't understood by an > implementation are harder to recognize if the element changes. It > also mixes content and structure in a way that I don't like. I would > prefer to see something like: > > That was naughty. > > How do you want to do error codes? Will you setup an IANA registry? > Will you permit extensions to the set of errors? Sorry, I just got > into the undefined territory. Error codes are certainly an open issue of the current version. http://www.tschofenig.priv.at:8080/lost/issue15 Ciao Hannes > > Cheers, Martin > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. If you > have received it in error, please notify the sender immediately and > delete the original. Any unauthorized use of this email is > prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > > ------------------------------------------------------------------------ > > > _______________________________________________ Ecrit mailing list > Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 03 19:30:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxXsV-0008AP-6r; Mon, 03 Jul 2006 19:30:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxXsT-0008AG-Te for ecrit@ietf.org; Mon, 03 Jul 2006 19:30:53 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxXsS-0000yP-MP for ecrit@ietf.org; Mon, 03 Jul 2006 19:30:53 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 18:30:50 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 03 Jul 2006 18:30:50 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 18:30:49 -0500 Message-ID: From: "Thomson, Martin" To: "Hannes Tschofenig" Date: Mon, 3 Jul 2006 18:30:07 -0500 Subject: RE: [Ecrit] draft-ietf-lost-00 comments MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 03 Jul 2006 23:30:49.0376 (UTC) FILETIME=[B7773A00:01C69EF8] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <44A8E4DB.9080602@gmx.net> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] draft-ietf-lost-00 comments Thread-Index: AcaehAM0EUBwvuiKQ1m/+Y2nUkiLGAAaxTQw X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0113042921==" Errors-To: ecrit-bounces@ietf.org --===============0113042921== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SGkgSGFubmVzLA0KDQo8c25pcD4gDQo+ID4NCj4gPiBUaGUgZmluZExvU1RCeUdlbyBhbmQgZmlu ZExvU1RCeUNpdmljICh0aGUgY2FwaXRhbGl6YXRpb24gbWFrZXMgdGhvc2UNCj4gPiB0b3VnaCB0 byB0eXBlLCBCVFcpIGFyZSBmdW5kYW1lbnRhbGx5IGlkZW50aWNhbCwgc28gd2h5IGlzIHRoZXJl IGENCj4gPiBuZWVkIGZvciBzZXBhcmF0ZSBuYW1lcyBmb3IgdGhlc2UgcXVlcmllcz8gIEkgcHJl ZmVycmVkIHRoZSBlYXJsaWVyDQo+ID4gaXRlcmF0aW9ucyB3aGVyZSB0aGUgbG9jYXRpb24gd2Fz IGp1c3QgYSBjaG9pY2UgZWxlbWVudC4gIFRoZSBlbGVtZW50DQo+ID4gbmFtZSBpcyB0aGUgbmFt ZSBvZiB0aGUgb3BlcmF0aW9uLCBhbmQsIGluIHRlcm1zIG9mIHNlbWFudGljcywgdGhlcmUNCj4g PiBpcyBvbmx5IG9uZSBvcGVyYXRpb24gaGVyZTogJ2ZpbmRMb1NUJy4NCj4gDQo+IEkgYWdyZWUg d2l0aCBBbmR5IHRoYXQgd2Ugc2hvdWxkIGRlYWwgd2l0aCB0aGlzIGFzcGVjdCBvbmNlIHdlIHJl YWNoZWQgYQ0KPiBjb25jbHVzaW9uIHdpdGggcmVnYXJkIHRvIHRoZSBtdWx0aXBsZS9jb21wb3Np dGUgbG9jYXRpb24gcXVlcnkgcXVlc3Rpb24uDQo+IA0KDQpJIHRoaW5rIHRoYXQgYSBzaW5nbGUg cXVlcnkvb3BlcmF0aW9uIGlzIG1vcmUgc3VpdGFibGUsIGV2ZW4gaWYgd2UgZGVjaWRlIG5vdCB0 byBzdXBwb3J0IG11bHRpcGxlL2NvbXBvc2l0ZSBsb2NhdGlvbnMuDQoNCjxzbmlwPg0KPiANCj4g Pg0KPiA+IFlvdSByZWZlciB0byB0aGUgY2l2aWMgbG9jYXRpb24gZm9ybWF0IGluIFJGQyA0MTE5 IHJhdGhlciB0aGFuIHRoZQ0KPiA+IGZvcm1hdCBpbiBkcmFmdC1pZXRmLWdlb3ByaXYtcmV2aXNl ZC1jaXZpYy1sby4gIFRoZSBSRkMgNDExOSBmb3JtYXQNCj4gPiBkb2Vzbid0IGluY2x1ZGUgYSBy YW5nZSBvZiBlbGVtZW50cyB0aGF0IG1pZ2h0IGJlIG5lY2Vzc2FyeS4gIChZb3UNCj4gPiBoYXZl IGRlY2xhcmVkIGEgTlMgcHJlZml4IGZvciB0aGUgcmV2aXNlZCBjaXZpYyBhZGRyZXNzIGluIHRo ZQ0KPiA+IHNjaGVtYSwgYnV0IGl0IGlzbid0IHVzZWQuKQ0KPiANCj4gQ291bGQgeW91IGJlIG1v cmUgc3BlY2lmaWMgYWJvdXQgdGhlIHJhbmdlIG9mIGVsZW1lbnQgYXNwZWN0IGhlcmU/DQoNClRo ZSByZXZpc2VkIGNpdmljIGRyYWZ0IGNvbnRhaW5zIH4xMiBlbGVtZW50cyB0aGF0IDQxMTkgZG9l c24ndC4gIFRoZXNlIGVsZW1lbnRzIGFyZSBhbGwgZGVmaW5lZCBpbiB0aGUgY2l2aWMgZHJhZnQs IGFuZCBtYXkgYmUgbmVjZXNzYXJ5IGZvciByb3V0aW5nIGluIHNvbWUgY291bnRyaWVzLiAgSW4g cGFydGljdWxhciwgdGhlIHJvYWQgc3RydWN0dXJlIGVsZW1lbnRzIGFyZSBuZXcuDQoNCjxzbmlw Pg0KDQpDaGVlcnMsDQpNYXJ0aW4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5 IGFuZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBw cml2YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmln aW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQu DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJd --===============0113042921== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0113042921==-- From ecrit-bounces@ietf.org Tue Jul 04 03:48:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxfdY-0003i9-LH; Tue, 04 Jul 2006 03:48:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fxfcp-0003JC-36 for ecrit@ietf.org; Tue, 04 Jul 2006 03:47:15 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FxfPR-0004Vy-7i for ecrit@ietf.org; Tue, 04 Jul 2006 03:33:26 -0400 Received: (qmail invoked by alias); 04 Jul 2006 07:33:23 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp025) with SMTP; 04 Jul 2006 09:33:23 +0200 X-Authenticated: #29516787 Message-ID: <44AA19C5.8030308@gmx.net> Date: Tue, 04 Jul 2006 09:33:25 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomson, Martin" Subject: Re: [Ecrit] draft-ietf-lost-00 comments References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Martin, Thomson, Martin wrote: > Hi Hannes, > > > >>> The findLoSTByGeo and findLoSTByCivic (the capitalization makes >>> those tough to type, BTW) are fundamentally identical, so why is >>> there a need for separate names for these queries? I preferred >>> the earlier iterations where the location was just a choice >>> element. The element name is the name of the operation, and, in >>> terms of semantics, there is only one operation here: 'findLoST'. >>> >> >> I agree with Andy that we should deal with this aspect once we >> reached a conclusion with regard to the multiple/composite location >> query question. >> > > > I think that a single query/operation is more suitable, even if we > decide not to support multiple/composite locations. I agree. We started with the discussion about sending multiple location information within a single query and the tendency was that this is not a good approach. During the discussion the aspect of composite location showed up. It made some sense to me although we are certainly talking about corner cases. We need to make a decision about it soon. > > > >>> You refer to the civic location format in RFC 4119 rather than >>> the format in draft-ietf-geopriv-revised-civic-lo. The RFC 4119 >>> format doesn't include a range of elements that might be >>> necessary. (You have declared a NS prefix for the revised civic >>> address in the schema, but it isn't used.) >> >> Could you be more specific about the range of element aspect here? > > > The revised civic draft contains ~12 elements that 4119 doesn't. > These elements are all defined in the civic draft, and may be > necessary for routing in some countries. In particular, the road > structure elements are new. Got your point. You are right that the reference to draft-ietf-geopriv-revised-civic-lo would be more appropriate. Ciao Hannes > > > > Cheers, Martin > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may contain > privileged, proprietary, or otherwise private information. If you > have received it in error, please notify the sender immediately and > delete the original. Any unauthorized use of this email is > prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 05 17:48:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyFEk-0001II-OX; Wed, 05 Jul 2006 17:48:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyFEk-0001Eu-8C for Ecrit@ietf.org; Wed, 05 Jul 2006 17:48:46 -0400 Received: from py-out-1112.google.com ([64.233.166.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyFEj-0001g4-SH for Ecrit@ietf.org; Wed, 05 Jul 2006 17:48:46 -0400 Received: by py-out-1112.google.com with SMTP id b36so2206902pyb for ; Wed, 05 Jul 2006 14:48:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=WEzyLboh0Iv3krnyrdydg1TJUtZT0Hz7gWdN2qydUo6dmYrD+h2fSMjBMPQ86Ne2thpeMM0rCNwnndWJc+PzbxNDnYJ1FwSEtbzjnlm2pOjpm2qcrBp8yhHAq3NyGKSk7P+5j9RoTdiSiykMfBaZqN1mA88BSQGBO1bRryKoWpg= Received: by 10.35.57.5 with SMTP id j5mr5562106pyk; Wed, 05 Jul 2006 14:48:45 -0700 (PDT) Received: by 10.35.81.17 with HTTP; Wed, 5 Jul 2006 14:48:45 -0700 (PDT) Message-ID: <953beacc0607051448i101216c4x7cf45fc2e7795c39@mail.gmail.com> Date: Wed, 5 Jul 2006 14:48:45 -0700 From: "Rohan Mahy" To: "peter_blatherwick@mitel.com" Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted) In-Reply-To: MIME-Version: 1.0 References: X-Spam-Score: 0.6 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: "Rosen, Brian" , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0965509759==" Errors-To: ecrit-bounces@ietf.org --===============0965509759== Content-Type: multipart/alternative; boundary="----=_Part_28987_8800330.1152136125280" ------=_Part_28987_8800330.1152136125280 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Peter, One data point below... On 6/30/06, peter_blatherwick@mitel.com wrote: > > > Hi Rohan, > > > > LLDP-MED does not work in an 802.11 wireless LAN environment. The > assumptions > > made in LLDP-MED about link reliability, authentication, bandwidth > availability, timing, > > and lack of mobility are grossly inappropriate in a WLAN environment. > > Actually, LLDP-MED can be used in WLAN scenarios for location, with the > constraint that it can only locate to the AP today. See LLDP-MED spec, > Annex C for discussion of this. At this point in time, there is no solution > in WLAN to resolve closer than the AP. > I am aware of several shipping implementations that do much better than this. All of these can do at least 10m accuracy and one is doing 3m accuracy in well engineered deployments. To your points... If the wireless link becomes unreliable, then all methods > are off. Auth is not really a strong requirement (IMHO) in this scenario, > at least in enterprise. And, bw availability & timing are non-issues due to > the very small size and periodic advertisements inherent in LLDP -- the > other proposed methods use more bw and/or have difficulty getting updates on > the fly. (Don't understand what you mean by "lack of mobility".) Yes, an > imperfect solution, however reasonably practical at this time. > > > I am personally much more interested in location (emergency and > otherwise) for wireless > > LAN devices than for wired devices. The user of a wireless LAN device > is much less > > likely to know their own location than a user of a wired LAN devices. > This is a fast > > growing market segment because people want mobility once the price is > right and the > > quality is good enough. Yes, we need to solve wired location, but lets > not forget the > > wireless communities. > > I both agree and disagree here. Wired ethernet is by far the dominant > case today in enterprise scenarios, therefore this is the biggest interest > for me at this point in time. LLDP-MED is already being supported by > several vendors in enterprise space, and is proving to be pretty easy to > work with, so makes a good choice there IMHO. Of course I do very much > agree we need to fully solve WLAN also, both enterprise and public, however > it is lagging in large part due to lack of a well agreed / standardized > method of doing the actual location (triangulation or otherwise). The work > is ongoing, but will take time. > > Thanks for aiming at the IEEE work. I was aware, but have not been able > to keep up with it in detail. If I understand correctly (may be dubious) it > appears that yet a 4th location method might be required to support this. > (I can hear Brian groaning as I type ;-) > your welcome. thanks for the pointer to LLDP-MED. I seems I keep having to refind it from time to time. thanks, -rohan ------=_Part_28987_8800330.1152136125280 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi Peter,

One data point below...

On 6/30/06, peter_blatherwick@mitel.com < peter_blatherwick@mitel.com> wrote:

Hi Rohan,


> LLDP-MED does not work in an 802.11 wireless LAN environment.  The assumptions
> made in LLDP-MED about link reliability, authentication, bandwidth availability, timing,
> and lack of mobility are grossly inappropriate in a WLAN environment.

Actually, LLDP-MED can be used in WLAN scenarios for location, with the constraint that it can only locate to the AP today.  See LLDP-MED spec, Annex C for discussion of this.  At this point in time, there is no solution in WLAN to resolve closer than the AP.

I am aware of several shipping implementations that do much better than this.  All of these can do at least 10m accuracy and one is doing 3m accuracy in well engineered deployments.


 To your points... If the wireless link becomes unreliable, then all methods are off.  Auth is not really a strong requirement (IMHO) in this scenario, at least in enterprise.  And, bw availability & timing are non-issues due to the very small size and periodic advertisements inherent in LLDP -- the other proposed methods use more bw and/or have difficulty getting updates on the fly.  (Don't understand what you mean by "lack of mobility".)  Yes, an imperfect solution, however reasonably practical at this time. 

> I am personally much more interested in location (emergency and otherwise) for wireless
> LAN devices than for wired devices.  The user of a wireless LAN device is much less
> likely to know their own location than a user of a wired LAN devices.  This is a fast
> growing market segment because people want mobility once the price is right and the
> quality is good enough.  Yes, we need to solve wired location, but lets not forget the
> wireless communities.

I both agree and disagree here.  Wired ethernet is by far the dominant case today in enterprise scenarios, therefore this is the biggest interest for me at this point in time.  LLDP-MED is already being supported by several vendors in enterprise space, and is proving to be pretty easy to work with, so makes a good choice there IMHO.   Of course I do very much agree we need to fully solve WLAN also, both enterprise and public, however it is lagging in large part due to lack of a well agreed / standardized method of doing the actual location (triangulation or otherwise).  The work is ongoing, but will take time.  

Thanks for aiming at the IEEE work.  I was aware, but have not been able to keep up with it in detail.  If I understand correctly (may be dubious) it appears that yet a 4th location method might be required to support this.  (I can hear Brian groaning as I type ;-)

your welcome.  thanks for the pointer to LLDP-MED. I seems I keep having to refind it from time to time.

thanks,
-rohan
 

------=_Part_28987_8800330.1152136125280-- --===============0965509759== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0965509759==-- From ecrit-bounces@ietf.org Thu Jul 06 07:20:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyRu8-0003yO-UN; Thu, 06 Jul 2006 07:20:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyRu7-0003yJ-MF for ecrit@ietf.org; Thu, 06 Jul 2006 07:20:19 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FyRu4-0005GO-8p for ecrit@ietf.org; Thu, 06 Jul 2006 07:20:19 -0400 Received: (qmail invoked by alias); 06 Jul 2006 11:20:13 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp017) with SMTP; 06 Jul 2006 13:20:13 +0200 X-Authenticated: #29516787 Message-ID: <44ACF1E5.2050200@gmx.net> Date: Thu, 06 Jul 2006 13:20:05 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] Reading List for 3GPP CT - IETF ECRIT joint meeting on SIP emergency call X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, if you plan to attend the 3GPP CT - IETF ECRIT joint meeting on SIP emergency call then you might want to read into the relevant 3GPP specifications. The following document is important: http://www.3gpp.org/ftp/Specs/html-info/23167.htm (covers only IMS) Additionally, the following TR might be interesting: http://www.3gpp.org/ftp/Specs/html-info/23867.htm (it also contains non-IMS parts) Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 06 07:53:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySQM-0001f3-6J; Thu, 06 Jul 2006 07:53:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySQL-0001ey-CN for ecrit@ietf.org; Thu, 06 Jul 2006 07:53:37 -0400 Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FySQK-0008KM-46 for ecrit@ietf.org; Thu, 06 Jul 2006 07:53:37 -0400 Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k66BrXe7023341; Thu, 6 Jul 2006 06:53:33 -0500 (CDT) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <3KJ9TL5Q>; Thu, 6 Jul 2006 12:53:32 +0100 Message-ID: <475FF955A05DD411980D00508B6D5FB01369D448@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: Hannes Tschofenig , ecrit@ietf.org Subject: RE: [Ecrit] Reading List for 3GPP CT - IETF ECRIT joint meeting o n SIP emergency call Date: Thu, 6 Jul 2006 12:53:30 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Just a note for IETF folks. The second document (23.867) is work that led to the preparation of 23.167, but it is no longer maintained. Comparing it to IETF procedures, it is probably like the final version of the author draft before the WG adopts it as a charter item. It may well contain discussion of solutions that is absent from the later WG charter draft (and is therefore useful), but the details of the solutions proposed may no longer be one and the same. Section 10 (I think - it is headed "emergency" whereever it is) of http://www.3gpp.org/ftp/Specs/html-info/22101.htm which is fairly short, may also be useful. regards Keith > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: 06 July 2006 12:20 > To: ecrit@ietf.org > Subject: [Ecrit] Reading List for 3GPP CT - IETF ECRIT joint > meeting on > SIP emergency call > > > Hi all, > > if you plan to attend the 3GPP CT - IETF ECRIT joint meeting on SIP > emergency call then you might want to read into the relevant 3GPP > specifications. > > The following document is important: > http://www.3gpp.org/ftp/Specs/html-info/23167.htm > (covers only IMS) > > Additionally, the following TR might be interesting: > http://www.3gpp.org/ftp/Specs/html-info/23867.htm > (it also contains non-IMS parts) > > Ciao > Hannes > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 06 07:56:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySSf-0001nu-9W; Thu, 06 Jul 2006 07:56:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySSe-0001np-EG for ecrit@ietf.org; Thu, 06 Jul 2006 07:56:00 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FySSd-0008Nl-0K for ecrit@ietf.org; Thu, 06 Jul 2006 07:56:00 -0400 Received: (qmail invoked by alias); 06 Jul 2006 11:55:58 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp041) with SMTP; 06 Jul 2006 13:55:58 +0200 X-Authenticated: #29516787 Message-ID: <44ACFA42.5070809@gmx.net> Date: Thu, 06 Jul 2006 13:55:46 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Drage, Keith (Keith)" Subject: Re: [Ecrit] Reading List for 3GPP CT - IETF ECRIT joint meeting o n SIP emergency call References: <475FF955A05DD411980D00508B6D5FB01369D448@en0033exch001u.uk.lucent.com> In-Reply-To: <475FF955A05DD411980D00508B6D5FB01369D448@en0033exch001u.uk.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Keith, thanks for the info. I wonder whether 3GPP meeting participants know what IETF documents they should read..... Ciao Hannes Drage, Keith (Keith) wrote: > Just a note for IETF folks. > > The second document (23.867) is work that led to the preparation of 23.167, but it is no longer maintained. Comparing it to IETF procedures, it is probably like the final version of the author draft before the WG adopts it as a charter item. It may well contain discussion of solutions that is absent from the later WG charter draft (and is therefore useful), but the details of the solutions proposed may no longer be one and the same. > > Section 10 (I think - it is headed "emergency" whereever it is) of http://www.3gpp.org/ftp/Specs/html-info/22101.htm > > which is fairly short, may also be useful. > > regards > > Keith > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: 06 July 2006 12:20 >>To: ecrit@ietf.org >>Subject: [Ecrit] Reading List for 3GPP CT - IETF ECRIT joint >>meeting on >>SIP emergency call >> >> >>Hi all, >> >>if you plan to attend the 3GPP CT - IETF ECRIT joint meeting on SIP >>emergency call then you might want to read into the relevant 3GPP >>specifications. >> >>The following document is important: >>http://www.3gpp.org/ftp/Specs/html-info/23167.htm >>(covers only IMS) >> >>Additionally, the following TR might be interesting: >>http://www.3gpp.org/ftp/Specs/html-info/23867.htm >>(it also contains non-IMS parts) >> >>Ciao >>Hannes >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 06 08:11:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyShB-00057e-IZ; Thu, 06 Jul 2006 08:11:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FySh9-00057T-MI for ecrit@ietf.org; Thu, 06 Jul 2006 08:10:59 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FySh8-0001Dp-7O for ecrit@ietf.org; Thu, 06 Jul 2006 08:10:59 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Reading List for 3GPP CT - IETF ECRIT joint meeting on SIP emergency call Date: Thu, 6 Jul 2006 14:14:24 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B02@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Reading List for 3GPP CT - IETF ECRIT joint meeting on SIP emergency call Thread-Index: Acag870qmrTllTW3TIiVpUM803aWNAAAfrEH References: <475FF955A05DD411980D00508B6D5FB01369D448@en0033exch001u.uk.lucent.com> <44ACFA42.5070809@gmx.net> From: "Stastny Richard" To: "Hannes Tschofenig" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Just in case, could you post them? =20 Richard ________________________________ Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Gesendet: Do 06.07.2006 13:55 An: Drage, Keith (Keith) Cc: ecrit@ietf.org Betreff: Re: [Ecrit] Reading List for 3GPP CT - IETF ECRIT joint meeting = on SIP emergency call Hi Keith, thanks for the info. I wonder whether 3GPP meeting participants know what IETF documents they should read..... Ciao Hannes Drage, Keith (Keith) wrote: > Just a note for IETF folks. > > The second document (23.867) is work that led to the preparation of = 23.167, but it is no longer maintained. Comparing it to IETF procedures, = it is probably like the final version of the author draft before the WG = adopts it as a charter item. It may well contain discussion of solutions = that is absent from the later WG charter draft (and is therefore = useful), but the details of the solutions proposed may no longer be one = and the same. > > Section 10 (I think - it is headed "emergency" whereever it is) of = http://www.3gpp.org/ftp/Specs/html-info/22101.htm > > which is fairly short, may also be useful. > > regards > > Keith > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: 06 July 2006 12:20 >>To: ecrit@ietf.org >>Subject: [Ecrit] Reading List for 3GPP CT - IETF ECRIT joint >>meeting on >>SIP emergency call >> >> >>Hi all, >> >>if you plan to attend the 3GPP CT - IETF ECRIT joint meeting on SIP >>emergency call then you might want to read into the relevant 3GPP >>specifications. >> >>The following document is important: >>http://www.3gpp.org/ftp/Specs/html-info/23167.htm >>(covers only IMS) >> >>Additionally, the following TR might be interesting: >>http://www.3gpp.org/ftp/Specs/html-info/23867.htm >>(it also contains non-IMS parts) >> >>Ciao >>Hannes >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit >> > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 06 08:40:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyT9D-00040l-RY; Thu, 06 Jul 2006 08:39:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyT9C-00040g-LY for Ecrit@ietf.org; Thu, 06 Jul 2006 08:39:58 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyT9B-00047R-9k for Ecrit@ietf.org; Thu, 06 Jul 2006 08:39:58 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 06AA420057; Thu, 6 Jul 2006 08:39:57 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22763-01; Thu, 6 Jul 2006 08:39:54 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id D720D20055; Thu, 6 Jul 2006 08:39:54 -0400 (EDT) To: "Rohan Mahy" Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: peter_blatherwick@mitel.com Date: Thu, 6 Jul 2006 08:39:52 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 07/06/2006 08:39:54 AM, Serialize complete at 07/06/2006 08:39:54 AM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.3 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: "Rosen, Brian" , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0406197956==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0406197956== Content-Type: multipart/alternative; boundary="=_alternative 0045A920852571A3_=" This is a multipart message in MIME format. --=_alternative 0045A920852571A3_= Content-Type: text/plain; charset="us-ascii" Hi Rohan, all, >>> LLDP-MED does not work in an 802.11 wireless LAN environment. The >>> assumptions made in LLDP-MED about link reliability, authentication, >>> bandwidth availability, timing, and lack of mobility are grossly >>> inappropriate in a WLAN environment. >> >> Actually, LLDP-MED can be used in WLAN scenarios for location, with >> the constraint that it can only locate to the AP today. See >> LLDP-MED spec, Annex C for discussion of this. At this point in >> time, there is no solution in WLAN to resolve closer than the AP. > > I am aware of several shipping implementations that do much better > than this. All of these can do at least 10m accuracy and one is > doing 3m accuracy in well engineered deployments. Yup. Oops, should have thrown the word "standardized" in there. For ECS purposes, I believe it absolutely needs to be a fully open standards-based solution. WLANs i think will always be somewhat problematic, just due to the laws of physics and large number of variables which can affect accuracy. 10m is not there yet for an enterprise setting, especially vertically (oops, wrong floor!), 3m only barely. And "well engineered" tends to mean "hard to get right" in practice. Anyhow, this is now well off track relative to original intent of this thread. I'll stop typing now, unless someone cares to throw in something related to what location methods should be included in the Phone BCP. See y'all in Montreal, -- Peter [snip] --=_alternative 0045A920852571A3_= Content-Type: text/html; charset="us-ascii"
Hi Rohan, all,

>>> LLDP-MED does not work in an 802.11 wireless LAN environment.  The
>>> assumptions made in LLDP-MED about link reliability, authentication,
>>> bandwidth availability, timing, and lack of mobility are grossly
>>> inappropriate in a WLAN environment.
>>
>> Actually, LLDP-MED can be used in WLAN scenarios for location, with
>> the constraint that it can only locate to the AP today.  See
>> LLDP-MED spec, Annex C for discussion of this.  At this point in
>> time, there is no solution in WLAN to resolve closer than the AP.
>
> I am aware of several shipping implementations that do much better
> than this.  All of these can do at least 10m accuracy and one is
> doing 3m accuracy in well engineered deployments.

Yup.  Oops, should have thrown the word "standardized" in there.  For
ECS purposes, I believe it absolutely needs to be a fully open
standards-based solution.  WLANs i think will always be somewhat
problematic, just due to the laws of physics and large number of
variables which can affect accuracy.  10m is not there yet for an
enterprise setting, especially vertically (oops, wrong floor!), 3m only
barely.  And "well engineered" tends to mean "hard to get right" in
practice.  

Anyhow, this is now well off track relative to original intent of this
thread.  I'll stop typing now, unless someone cares to throw in
something related to what location methods should be included in the
Phone BCP.  

See y'all in Montreal,

-- Peter

[snip]
--=_alternative 0045A920852571A3_=-- --===============0406197956== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0406197956==-- From ecrit-bounces@ietf.org Thu Jul 06 08:45:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTEV-0004Rp-AI; Thu, 06 Jul 2006 08:45:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTEU-0004Qu-KI for ecrit@ietf.org; Thu, 06 Jul 2006 08:45:26 -0400 Received: from lizzard.sbs.de ([194.138.37.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyTEQ-0005TJ-4s for ecrit@ietf.org; Thu, 06 Jul 2006 08:45:26 -0400 Received: from mail1.sbs.de (localhost [127.0.0.1]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k66CjLv1022512 for ; Thu, 6 Jul 2006 14:45:21 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k66CjK7C031119 for ; Thu, 6 Jul 2006 14:45:21 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 14:44:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Jul 2006 14:44:25 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF Reading List for 3GPP CT - IETF ECRIT joint meeting onSIP emergency call thread-index: Acag870qmrTllTW3TIiVpUM803aWNAAAfrEHAADrJyAAAAfugA== From: "Tschofenig, Hannes" To: X-OriginalArrivalTime: 06 Jul 2006 12:44:30.0355 (UTC) FILETIME=[EC9B7630:01C6A0F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ecrit] IETF Reading List for 3GPP CT - IETF ECRIT joint meeting onSIP emergency call X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all,=20 here is the IETF ECRIT reading list:=20 Requirements for Emergency Context Resolution with Internet Technologies http://www.ietf.org/internet-drafts/draft-ietf-ecrit-requirements-10.txt A Uniform Resource Name (URN) for Services http://www.ietf.org/internet-drafts/draft-ietf-ecrit-service-urn-03.txt Security Threats and Requirements for Emergency Call Marking and Mapping http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-02 .txt Framework for Emergency Calling in Internet Multimedia http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-emergency-framework-00 .txt LoST: A Location-to-Service Translation Protocol http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-00.txt One could certainly mention also some related documents (e.g., GEOPRIV drafts) but that's a good start.=20 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 06 08:45:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTET-0004QW-TS; Thu, 06 Jul 2006 08:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTES-0004QO-3f for ecrit@ietf.org; Thu, 06 Jul 2006 08:45:24 -0400 Received: from gecko.sbs.de ([194.138.37.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyTEQ-0005TK-KN for ecrit@ietf.org; Thu, 06 Jul 2006 08:45:24 -0400 Received: from mail2.sbs.de (localhost [127.0.0.1]) by gecko.sbs.de (8.12.6/8.12.6) with ESMTP id k66CjLrI007867; Thu, 6 Jul 2006 14:45:21 +0200 Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net [157.163.133.222]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k66CjKOr001643; Thu, 6 Jul 2006 14:45:20 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 14:44:30 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [Ecrit] Reading List for 3GPP CT - IETF ECRIT joint meeting onSIP emergency call Date: Thu, 6 Jul 2006 14:40:40 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Reading List for 3GPP CT - IETF ECRIT joint meeting onSIP emergency call thread-index: Acag870qmrTllTW3TIiVpUM803aWNAAAfrEHAADmTjA= From: "Tschofenig, Hannes" To: "Stastny Richard" , "Hannes Tschofenig" X-OriginalArrivalTime: 06 Jul 2006 12:44:30.0651 (UTC) FILETIME=[ECC8A0B0:01C6A0F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Richard, sure. I am just not sure whether 3GPP folks are actually on the list.=20 Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: Stastny Richard [mailto:Richard.Stastny@oefeg.at]=20 > Gesendet: Donnerstag, 6. Juli 2006 14:14 > An: Hannes Tschofenig > Cc: ecrit@ietf.org > Betreff: Re: [Ecrit] Reading List for 3GPP CT - IETF ECRIT=20 > joint meeting onSIP emergency call >=20 > Just in case, could you post them? > =20 > Richard >=20 > ________________________________ >=20 > Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Gesendet: Do 06.07.2006 13:55 > An: Drage, Keith (Keith) > Cc: ecrit@ietf.org > Betreff: Re: [Ecrit] Reading List for 3GPP CT - IETF ECRIT=20 > joint meeting on SIP emergency call >=20 >=20 >=20 > Hi Keith, >=20 > thanks for the info. >=20 > I wonder whether 3GPP meeting participants know what IETF=20 > documents they > should read..... >=20 > Ciao > Hannes >=20 >=20 > Drage, Keith (Keith) wrote: > > Just a note for IETF folks. > > > > The second document (23.867) is work that led to the=20 > preparation of 23.167, but it is no longer maintained.=20 > Comparing it to IETF procedures, it is probably like the=20 > final version of the author draft before the WG adopts it as=20 > a charter item. It may well contain discussion of solutions=20 > that is absent from the later WG charter draft (and is=20 > therefore useful), but the details of the solutions proposed=20 > may no longer be one and the same. > > > > Section 10 (I think - it is headed "emergency" whereever it=20 > is) of http://www.3gpp.org/ftp/Specs/html-info/22101.htm > > > > which is fairly short, may also be useful. > > > > regards > > > > Keith > > > > > >>-----Original Message----- > >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > >>Sent: 06 July 2006 12:20 > >>To: ecrit@ietf.org > >>Subject: [Ecrit] Reading List for 3GPP CT - IETF ECRIT joint > >>meeting on > >>SIP emergency call > >> > >> > >>Hi all, > >> > >>if you plan to attend the 3GPP CT - IETF ECRIT joint meeting on SIP > >>emergency call then you might want to read into the relevant 3GPP > >>specifications. > >> > >>The following document is important: > >>http://www.3gpp.org/ftp/Specs/html-info/23167.htm > >>(covers only IMS) > >> > >>Additionally, the following TR might be interesting: > >>http://www.3gpp.org/ftp/Specs/html-info/23867.htm > >>(it also contains non-IMS parts) > >> > >>Ciao > >>Hannes > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ecrit > >> > > > > > > >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 07 14:26:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyv1j-0007LL-1i; Fri, 07 Jul 2006 14:26:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyv1i-0007LG-El for ecrit@ietf.org; Fri, 07 Jul 2006 14:26:06 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyv1g-0005Zj-QE for ecrit@ietf.org; Fri, 07 Jul 2006 14:26:06 -0400 Received: from ([90.152.52.46]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.148162969; Fri, 07 Jul 2006 14:25:48 -0400 Received: from 01AL10015010621.AD.BLS.COM ([90.152.44.174]) by 01al10015010118.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 7 Jul 2006 13:25:48 -0500 Importance: normal Priority: normal Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Fri, 7 Jul 2006 13:25:47 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 7 Jul 2006 13:25:44 -0500 Message-ID: <9888E1AA13C3A1459D122996A58C0E1107CA35A2@bre2k61p-55> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-rosen-sos-phonebcp-01 Thread-Index: Acah8r2vrY5aZVd/RO+LunVk8BGl+w== From: "Stark, Barbara" To: X-OriginalArrivalTime: 07 Jul 2006 18:25:47.0804 (UTC) FILETIME=[C487F5C0:01C6A1F2] X-Spam-Score: 0.7 (/) X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd Subject: [Ecrit] Comments on draft-rosen-sos-phonebcp-01 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1441846091==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1441846091== Content-Transfer-Encoding: 7bit Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A1F2.C2D3805A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A1F2.C2D3805A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've sort of gone through the document and have comments mostly centered = around sections 3 and 4 on "Which devices and services should support = emergency calls" and "Determining location". Brian, if you want me to = try to turn any of these comments into sample text, please let me know. Section 3 only discusses endpoints that can initiate calls. But the = other sections go on to provide requirements for DHCP servers, proxies, = and other devices, in addition to just endpoints. If this document is = intended to provide recommendations for all these devices, then I'd like = to see all of these categories of devices described as having a role. I think it might be useful to have a section (or subsection) on (1) = devices that should be involved in location determination, (2) devices = that should be involved in determining an emergency call, and (3) = devices that should actively participate in emergency call signaling. = This would match the sections 4-6, so that requirements can be called = out in each of these sections for the various device types. In the "Determining Location" section, there seem to be requirements for = endpoints, "network attachment" devices, devices with DHCP servers in = them, and un-named intermediate devices which need to support some = method of providing more accurate location (where DHCP Relay is one such = method).=20 And then there's a requirement for networks that don't control the = specification of endpoint devices. This says that all such networks must = support DHCP. I'm not sure what all sorts of networks this is supposed = to refer to, but I was wondering if it would be better to describe the = devices that would be used in such networks, and put requirements on = them, instead of the network as a whole. So, if I were to translate some of the paragraphs to be listed = requirements for devices, I think it might be like: The following requirements apply to devices that are intended to be = operated on a network where the network operator does not control the = specification of every device connected to the network. Endpoint device 1. If the device has a DHCP client, the client MUST support RFC 3825 = and . [Are both a must? Is it ok to support one and not the = other in certain types of devices? If both are a must, is there an = expectation that the responding DHCP server has the intelligence to = respond to only one or the other?] a. If the device is configured to use DHCP for bootstrapping, it MUST = include both options in its DHCP REQUEST. b. When this device initiates an emergency call (see section on = requirements for recognizing emeregency calls), it MUST send a DHCP = INFORM message to refresh the location information. [Should it only use = the option that was previously successful?] 2. If the device supports LLDP-MED, it MUST support the "Location = Identification TLV" as defined in . [Note this = doesn't require support of LLDP-MED; I believe that if LLDP-MED is going = to be put in devices and deployed in networks, it has to be for more = reasons that just location determination; therefore, I don't think it's = appropriate to require LLDP-MED in this BCP.] 3. The device MUST support whatever L7 mechanism we come up with. 4. The device MUST support certain discovery mechanisms for finding = that L7 server. a. Server discovery MUST be done before any VPNs are initiated. 5. If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP = INFORM message with options as described in RFC 3825 and , = when it is configured to use one of these alternate bootstrap methods = (e.g., PPPoE, PPPoA, static IP address). a. If the device is configured to request location through = DHCPINFORM, then it MUST include both options in a DHCP INFORM message = sent shortly after bootstrap, and before any VPN sessions are initiated. b. When this device initiates an emergency call (see section on = requirements for recognizing emeregency calls), it MUST send a DHCP = INFORM message to refresh the location information. [Should it only use = the option that was previously successful?] 6. Interactions of the various methods a. If a device receives location information from both LLDP-MED and = DHCP which takes precedence? b. If a device successfully receives location information through = either DHCP or LLDP-MED, it MUST NOT request a location through the L7 = mechanism. 7. I'd also like to see recommendations on interactions of the various = L7 server discovery mechanisms Devices with DHCP servers 1. The DHCP server MUST support RFC 3825 and . The device = MUST be configurable to respond to either 0 (zero) or 1 of these = options. The device MUST NOT allow both options to be enabled = simultaneously. 2. If the device supports LLDP-MED, it MUST meet the requirements of an = LLDP-MED Network Connectivity Device, as defined in . [Again, this does not mean LLDP-MED is required -- only that = if it is implemented, it needs to be implemented per the spec.] 3. We might want to require this device to participate in some of the = L7 server discovery mechanisms 4. If the device has a WAN interface, it MUST meet requirements 1, 3, = 5, 6, and 7 of the Endpoint device, over that WAN interface. 5. A different set of L7 server discover mechanisms will probably need = to be recommended. 6. Do we want to require the device to be able to translate an L7 = response on the WAN side to a DHCP response to LAN devices? Should this = occur automatically? 7. If the device receives location information via DHCP on its WAN = interface, it MUST automatically configure itself to pass this = information on to LAN-side devices that request it. Un-named intermediate devices which need to support some method of = providing more accurate location (where DHCP Relay is one such method) 1. I'm really not sure what these devices are, or what the requirements = are. Barbara ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 118 ------_=_NextPart_001_01C6A1F2.C2D3805A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Comments on draft-rosen-sos-phonebcp-01

I've sort of gone through the document = and have comments mostly centered around sections 3 and 4 on "Which = devices and services should support emergency calls" and = "Determining location". Brian, if you want me to try to turn = any of these comments into sample text, please let me know.

Section 3 only discusses endpoints that = can initiate calls. But the other sections go on to provide requirements = for DHCP servers, proxies, and other devices, in addition to just = endpoints. If this document is intended to provide recommendations for = all these devices, then I'd like to see all of these categories of = devices described as having a role.

I think it might be useful to have a = section (or subsection) on (1) devices that should be involved in = location determination, (2) devices that should be involved in = determining an emergency call, and (3) devices that should actively = participate in emergency call signaling. This would match the sections = 4-6, so that requirements can be called out in each of these sections = for the various device types.

In the "Determining Location" = section, there seem to be requirements for endpoints, "network = attachment" devices, devices with DHCP servers in them, and = un-named intermediate devices which need to support some method of = providing more accurate location (where DHCP Relay is one such method). =

And then there's a requirement for = networks that don't control the specification of endpoint devices. This = says that all such networks must support DHCP. I'm not sure what all = sorts of networks this is supposed to refer to, but I was wondering if = it would be better to describe the devices that would be used in such = networks, and put requirements on them, instead of the network as a = whole.

So, if I were to translate some of the = paragraphs to be listed requirements for devices, I think it might be = like:

The following requirements apply to = devices that are intended to be operated on a network where the network = operator does not control the specification of every device connected to = the network.

Endpoint device
 1. If the device has a DHCP = client, the client MUST support RFC 3825 and <dhcp-civil>. [Are = both a must? Is it ok to support one and not the other in certain types = of devices? If both are a must, is there an expectation that the = responding DHCP server has the intelligence to respond to only one or = the other?]

   a. If the device is = configured to use DHCP for bootstrapping, it MUST include both options = in its DHCP REQUEST.
   b. When this device = initiates an emergency call (see section on requirements for recognizing = emeregency calls), it MUST send a DHCP INFORM message to refresh the = location information. [Should it only use the option that was previously = successful?]

 2. If the device supports = LLDP-MED, it MUST support the “Location Identification TLV” = as defined in <LLDP-MED reference>. [Note this doesn’t = require support of LLDP-MED; I believe that if LLDP-MED is going to be = put in devices and deployed in networks, it has to be for more reasons = that just location determination; therefore, I don’t think = it’s appropriate to require LLDP-MED in this BCP.]

 3. The device MUST support = whatever L7 mechanism we come up with.
 4. The device MUST support = certain discovery mechanisms for finding that L7 server.
    a. Server discovery = MUST be done before any VPNs are initiated.
 5. If the device allows for = bootstrapping methods other than DHCP, it SHOULD support being = configured to request location through a DHCP INFORM message with = options as described in RFC 3825 and <dhcp-civil>, when it is = configured to use one of these alternate bootstrap methods (e.g., PPPoE, = PPPoA, static IP address).

   a. If the device is = configured to request location through DHCPINFORM, then it MUST include = both options in a DHCP INFORM message sent shortly after bootstrap, and = before any VPN sessions are initiated.

   b. When this device = initiates an emergency call (see section on requirements for recognizing = emeregency calls), it MUST send a DHCP INFORM message to refresh the = location information. [Should it only use the option that was previously = successful?]

 6. Interactions of the various = methods
   a. If a device receives = location information from both LLDP-MED and DHCP which takes = precedence?
   b. If a device = successfully receives location information through either DHCP or = LLDP-MED, it MUST NOT request a location through the L7 = mechanism.

 7. I’d also like to see = recommendations on interactions of the various L7 server discovery = mechanisms

Devices with DHCP servers
 1. The DHCP server MUST support = RFC 3825 and <dhcp-civil>. The device MUST be configurable to = respond to either 0 (zero) or 1 of these options. The device MUST NOT = allow both options to be enabled simultaneously.

 2. If the device supports = LLDP-MED, it MUST meet the requirements of an LLDP-MED Network = Connectivity Device, as defined in <LLDP-MED reference>. [Again, = this does not mean LLDP-MED is required -- only that if it is = implemented, it needs to be implemented per the spec.]

 3. We might want to require this = device to participate in some of the L7 server discovery = mechanisms
 4. If the device has a WAN = interface, it MUST meet requirements 1, 3, 5, 6, and 7 of the Endpoint = device, over that WAN interface.

 5. A different set of L7 server = discover mechanisms will probably need to be recommended.
 6. Do we want to require the = device to be able to translate an L7 response on the WAN side to a DHCP = response to LAN devices? Should this occur automatically?

 7. If the device receives = location information via DHCP on its WAN interface, it MUST = automatically configure itself to pass this information on to LAN-side = devices that request it.

Un-named intermediate devices which = need to support some method of providing more accurate location (where = DHCP Relay is one such method)

 1. I’m really not sure what = these devices are, or what the requirements are.

Barbara

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. 118

 ------_=_NextPart_001_01C6A1F2.C2D3805A-- --===============1441846091== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1441846091==-- From ecrit-bounces@ietf.org Fri Jul 07 14:41:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyvH3-0000Nz-GP; Fri, 07 Jul 2006 14:41:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyvH2-0000Nm-4F for ecrit@ietf.org; Fri, 07 Jul 2006 14:41:56 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyvGz-0007kd-Fv for ecrit@ietf.org; Fri, 07 Jul 2006 14:41:56 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 07 Jul 2006 11:41:53 -0700 X-IronPort-AV: i="4.06,218,1149490800"; d="scan'208"; a="1836219000:sNHT35935520" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id k67IfrQK025041; Fri, 7 Jul 2006 11:41:53 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k67Ifq46027604; Fri, 7 Jul 2006 11:41:52 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 11:41:52 -0700 Received: from jmpolk-wxp.cisco.com ([10.21.120.207]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 7 Jul 2006 11:41:52 -0700 Message-Id: <4.3.2.7.2.20060707133700.03682c28@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 07 Jul 2006 13:41:51 -0500 To: "Stark, Barbara" From: "James M. Polk" Subject: Re: [Ecrit] Comments on draft-rosen-sos-phonebcp-01 In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1107CA35A2@bre2k61p-55> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 07 Jul 2006 18:41:52.0234 (UTC) FILETIME=[03604CA0:01C6A1F5] DKIM-Signature: a=rsa-sha1; q=dns; l=7431; t=1152297713; x=1153161713; c=relaxed/simple; s=sjdkim6001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Ecrit]=20Comments=20on=20draft-rosen-sos-phonebcp-01; X=v=3Dcisco.com=3B=20h=3DD7omLrNfmfdqB7ukgY4Lq/2oSoo=3D; b=d2npFp8Am9Qm/CvwZQD+yUs+xIHdh5gDhnE3ZbiY5CFvw9AMMWbSXrZuahLVBkKth/I8jd1A 0pMkxQWUCbQ5VMt/2InQRtR2aby9Gj7hHc99oHe9IlWUVViM+xM6Aqg1; Authentication-Results: sj-dkim-6.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Barbara I think most of your comments below are good comments - from a peeling back the layers of the onion pov - and should be interleaved into this doc. As this happens, more gaps will be discovered. Thank you for taking the time to do this analysis. At 01:25 PM 7/7/2006 -0500, Stark, Barbara wrote: >Content-Transfer-Encoding: 7bit >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C6A1F2.C2D3805A" > >I've sort of gone through the document and have comments mostly centered >around sections 3 and 4 on "Which devices and services should support >emergency calls" and "Determining location". Brian, if you want me to try >to turn any of these comments into sample text, please let me know. > >Section 3 only discusses endpoints that can initiate calls. But the other >sections go on to provide requirements for DHCP servers, proxies, and >other devices, in addition to just endpoints. If this document is intended >to provide recommendations for all these devices, then I'd like to see all >of these categories of devices described as having a role. > >I think it might be useful to have a section (or subsection) on (1) >devices that should be involved in location determination, (2) devices >that should be involved in determining an emergency call, and (3) devices >that should actively participate in emergency call signaling. This would >match the sections 4-6, so that requirements can be called out in each of >these sections for the various device types. > >In the "Determining Location" section, there seem to be requirements for >endpoints, "network attachment" devices, devices with DHCP servers in >them, and un-named intermediate devices which need to support some method >of providing more accurate location (where DHCP Relay is one such method). > >And then there's a requirement for networks that don't control the >specification of endpoint devices. This says that all such networks must >support DHCP. I'm not sure what all sorts of networks this is supposed to >refer to, but I was wondering if it would be better to describe the >devices that would be used in such networks, and put requirements on them, >instead of the network as a whole. > >So, if I were to translate some of the paragraphs to be listed >requirements for devices, I think it might be like: > >The following requirements apply to devices that are intended to be >operated on a network where the network operator does not control the >specification of every device connected to the network. > >Endpoint device > 1. If the device has a DHCP client, the client MUST support RFC 3825 and > . [Are both a must? Is it ok to support one and not the other > in certain types of devices? If both are a must, is there an expectation > that the responding DHCP server has the intelligence to respond to only > one or the other?] > > a. If the device is configured to use DHCP for bootstrapping, it MUST > include both options in its DHCP REQUEST. > b. When this device initiates an emergency call (see section on > requirements for recognizing emeregency calls), it MUST send a DHCP > INFORM message to refresh the location information. [Should it only use > the option that was previously successful?] > > 2. If the device supports LLDP-MED, it MUST support the Location > Identification TLV as defined in . [Note this doesn t > require support of LLDP-MED; I believe that if LLDP-MED is going to be > put in devices and deployed in networks, it has to be for more reasons > that just location determination; therefore, I don t think it s > appropriate to require LLDP-MED in this BCP.] > > 3. The device MUST support whatever L7 mechanism we come up with. > 4. The device MUST support certain discovery mechanisms for finding that > L7 server. > a. Server discovery MUST be done before any VPNs are initiated. > 5. If the device allows for bootstrapping methods other than DHCP, it > SHOULD support being configured to request location through a DHCP INFORM > message with options as described in RFC 3825 and , when it > is configured to use one of these alternate bootstrap methods (e.g., > PPPoE, PPPoA, static IP address). > > a. If the device is configured to request location through DHCPINFORM, > then it MUST include both options in a DHCP INFORM message sent shortly > after bootstrap, and before any VPN sessions are initiated. > > b. When this device initiates an emergency call (see section on > requirements for recognizing emeregency calls), it MUST send a DHCP > INFORM message to refresh the location information. [Should it only use > the option that was previously successful?] > > 6. Interactions of the various methods > a. If a device receives location information from both LLDP-MED and > DHCP which takes precedence? > b. If a device successfully receives location information through > either DHCP or LLDP-MED, it MUST NOT request a location through the L7 > mechanism. > > 7. I d also like to see recommendations on interactions of the various > L7 server discovery mechanisms > >Devices with DHCP servers > 1. The DHCP server MUST support RFC 3825 and . The device > MUST be configurable to respond to either 0 (zero) or 1 of these options. > The device MUST NOT allow both options to be enabled simultaneously. > > 2. If the device supports LLDP-MED, it MUST meet the requirements of an > LLDP-MED Network Connectivity Device, as defined in . > [Again, this does not mean LLDP-MED is required -- only that if it is > implemented, it needs to be implemented per the spec.] > > 3. We might want to require this device to participate in some of the L7 > server discovery mechanisms > 4. If the device has a WAN interface, it MUST meet requirements 1, 3, 5, > 6, and 7 of the Endpoint device, over that WAN interface. > > 5. A different set of L7 server discover mechanisms will probably need > to be recommended. > 6. Do we want to require the device to be able to translate an L7 > response on the WAN side to a DHCP response to LAN devices? Should this > occur automatically? > > 7. If the device receives location information via DHCP on its WAN > interface, it MUST automatically configure itself to pass this > information on to LAN-side devices that request it. > >Un-named intermediate devices which need to support some method of >providing more accurate location (where DHCP Relay is one such method) > > 1. I m really not sure what these devices are, or what the requirements > are. > >Barbara > >***** > >The information transmitted is intended only for the person or entity to >which it is addressed and may contain confidential, proprietary, and/or >privileged material. Any review, retransmission, dissemination or other >use of, or taking of any action in reliance upon this information by >persons or entities other than the intended recipient is prohibited. If >you received this in error, please contact the sender and delete the >material from all computers. 118 >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 10 11:20:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxYG-0002Nx-Sj; Mon, 10 Jul 2006 11:20:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzxYF-0002Nr-Il for ecrit@ietf.org; Mon, 10 Jul 2006 11:19:59 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzxYE-0004bw-4C for ecrit@ietf.org; Mon, 10 Jul 2006 11:19:59 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 10:19:55 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 10 Jul 2006 10:19:55 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 10:19:54 -0500 Message-ID: From: "Thomson, Martin" To: , Date: Mon, 10 Jul 2006 10:19:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 10 Jul 2006 15:19:54.0895 (UTC) FILETIME=[4C1E59F0:01C6A434] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Content-class: urn:content-classes:message Thread-Topic: Re: U-NAPTR Thread-Index: AcakNEswKVrnWPynQRiNIO63QcVSTw== X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: leslie@thinkingcat.com, ledaigle@cisco.com Subject: [Ecrit] Re: U-NAPTR X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes asked if I could elaborate a little on why the U-NAPTR draft [1] is applicable to the ECRIT and GEOPRIV-L7 work. Both LoST and the unnamed L7 protocol are likely to require some form of discovery. Both are currently looking at a DNS-based DDDS application starting with a search in either the access domain or service provider domain [2], [3]. SNAPTR is a good candidate for simplifying the implementation of DDDS, but it can only produce two types of results: a domain name (A/AAAA), and a domain name and port (SRV). Now, there is a possibility that this will not be sufficient for one or both of these protocols as the service might be identified by a URI. "U" flags, and, consequently, URI results were excluded from SNAPTR because SNAPTR explicitly excludes the regex field in the NAPTR record and URI results can only be carried in the regex field. U-NAPTR addresses this issue by describing a simple mechanism where a URI result can be obtained. I think that the U-NAPTR draft is worth a read, at least to get an understanding of the issues. Cheers, Martin [1] http://www.ietf.org/internet-drafts/draft-daigle-unaptr-00.txt [2] http://tools.ietf.org/html/draft-tschofenig-geopriv-l7-lcp-ps-00.txt [3] http://tools.ietf.org/html/draft-ietf-ecrit-service-urn-03.txt ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 10 14:20:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00NH-000728-Nx; Mon, 10 Jul 2006 14:20:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G00NG-00071N-CJ for ecrit@ietf.org; Mon, 10 Jul 2006 14:20:50 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G00NF-0004Od-34 for ecrit@ietf.org; Mon, 10 Jul 2006 14:20:50 -0400 Received: (qmail invoked by alias); 10 Jul 2006 18:20:48 -0000 Received: from h01fd-net84db.lab.risq.net (EHLO [132.219.1.253]) [132.219.1.253] by mail.gmx.net (mp038) with SMTP; 10 Jul 2006 20:20:48 +0200 X-Authenticated: #29516787 Message-ID: <44B29A82.7040803@gmx.net> Date: Mon, 10 Jul 2006 20:20:50 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org, Marc Linser Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [Ecrit] Slides, please X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, please us your slides to upload them to the IETF 66 Preliminary & Interim Materials webpage: https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=66 Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 11 01:36:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0AvY-0002wb-EC; Tue, 11 Jul 2006 01:36:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0AvX-0002wW-CU for ecrit@ietf.org; Tue, 11 Jul 2006 01:36:55 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0AvU-0004Mr-1d for ecrit@ietf.org; Tue, 11 Jul 2006 01:36:55 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 11 Jul 2006 01:36:52 -0400 X-IronPort-AV: i="4.06,226,1149480000"; d="scan'208"; a="92288351:sNHT32217862" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6B5apvP001452 for ; Tue, 11 Jul 2006 01:36:51 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6B5apdU025800 for ; Tue, 11 Jul 2006 01:36:51 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 01:36:51 -0400 Received: from [142.131.134.211] ([10.86.242.18]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 01:36:50 -0400 Message-ID: <44B338F1.6080005@cisco.com> Date: Tue, 11 Jul 2006 01:36:49 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2006 05:36:51.0155 (UTC) FILETIME=[02990230:01C6A4AC] DKIM-Signature: a=rsa-sha1; q=dns; l=3403; t=1152596211; x=1153460211; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:comments=20on=20LoST |To:ecrit@ietf.org; X=v=3Dcisco.com=3B=20h=3DLAkm5cV4iwK68oq7Eoh5mHCNLLQ=3D; b=F65e/FwmLw8OVoIfa/ul+IZRYwmeOOdMTpUENWZ3HG94A+ja01oP6yvX4C8BhCUO7LJI7DSu eEyhyLjlTTrUYAJqNTqyWxvTBG3fONG+Dyb+nKWDEQsxUEPU4Gpakk43; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [Ecrit] comments on LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Major: * LoST doesn't allow for any variability in the format of location information. I wonder if it makes sense to include an indication of the format of the location object, and to allow rejection if the format is not supported. Probably you'd need a baseline for interoperability. * I dont like how dialstring is added as an attribute of the location response, rather than a type of 'service' that you can query for just like emergency service. Can't the dial strings have their own definitions of regions of coverage that are separate from the region of coverage of a psap, for example? * Its not clear how the region element actual specifies a region when it is composed of a series of civic addresses. What is the algorithm for determining whether my current address, expressed in civic coordinates, is inside or outside of a region defined that way? * for dialstrings, suggest perhaps the KPML syntax for digit maps > 6.6. Validated Element > > Each validated element contains a string which is composed by by > concatenating the elements from the request which have been > recognized as valid by the server. Very unclear what this means. I read it several times and couldn't make sense of it. > .7. text Attribute > > This is a text type suitable for internationalized human readable > text. OK - but what is its semantic? * It'd be nice to be able, in a single lost query, ask for multiple services for the same location * For list service query: how do I ask for all services? Is it "urn:service"? "urn:"? "*"? * Security aspects are still really weak. You need to specify basic proceudres as part of the basic client and server processing. Beyond mutual tls I think we want a standard server side authentication mechanism as well, with no client authentication Minor: * figure 1 makes it look like there are two queries (one that provides location, one that proviedes a service URN) followed by two responses. I'd suggest a single arrow in each direction > LoST supports a query using geospatial and civic location information > using the findLoSTByCivic and the findLoSTByGeo query. Geospatial > location information uses GML format [9] and civic location > information utilizes the format defined in [10]. you need to specify exactly which xml element you are talking abtou in both cases. > The type of service desired is specified by the element. > The emergency identifiers listed in the registry established with [6] > will be used in this document. need to be clear that this is the service URN itself * LoST talks in a bunch of places about 'call time', but this concept is specific to voip and I think LoST has applications beyond just voip. Maybe generalize this. * is xml:lang being used for freeform text fields? I couldn't tell. Also, you may want to allow multiple text fields, each in a different lanuage, so that client can render the one it understands Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 11 14:00:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0MWc-0002K3-Dd; Tue, 11 Jul 2006 13:59:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0MWb-0002Jy-6r for ecrit@ietf.org; Tue, 11 Jul 2006 13:59:57 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0MWY-0001Sv-Sd for ecrit@ietf.org; Tue, 11 Jul 2006 13:59:57 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2006 10:59:54 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,230,1149490800"; d="scan'208"; a="31816181:sNHT24376788" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6BHxsch029052; Tue, 11 Jul 2006 13:59:54 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6BHxrdU016030; Tue, 11 Jul 2006 13:59:53 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 13:59:53 -0400 Received: from jmpolk-wxp.cisco.com ([10.86.242.114]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 13:59:53 -0400 Message-Id: <4.3.2.7.2.20060711123208.02a38028@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Jul 2006 12:59:51 -0500 To: ecrit@ietf.org From: "James M. Polk" Subject: Re: [Ecrit] ECRIT WG Status - concern about service-urn-03 In-Reply-To: <44A52735.2050108@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Jul 2006 17:59:53.0315 (UTC) FILETIME=[CFA2C330:01C6A513] DKIM-Signature: a=rsa-sha1; q=dns; l=3049; t=1152640794; x=1153504794; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Ecrit]=20ECRIT=20WG=20Status=20-=20concern=20about=20service-ur n-03 |To:ecrit@ietf.org; X=v=3Dcisco.com=3B=20h=3DxPO8tgqI8oxERLgGSETweS+LL+A=3D; b=gzLBC1TLXx/Ds4mQbf0M6D+IZLP5Dfy+twl/Wh/JpxBFwqp4rqqT+sQXlFN8vvEn/3jbox7S va8h3zuollebGxI+rRDr8T3Zuiwr6Gj4Rsb7r9KjDV5rVVwddvLkInR4; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 03:29 PM 6/30/2006 +0200, Hannes Tschofenig wrote: >Hi all, > >the following three documents are in good shape and passed the WGLC: > >- draft-ietf-ecrit-service-urn-03.txt forgive me for not catching this before, but I have a concern about the Service URN doc moving forward. I think this is a doc that creates and identifies a good namespace or identifier for an emergency call "on the wire". However, I think it makes an interesting comment in the Intro: In this document, we propose a URN namespace that, together with resolution protocols beyond the scope of this document, allows us to define such global, well-known services, while distributing the actual implementation across a large number of service-providing entities. I'm interested in the phrase "beyond the scope of this document", inviting magic to happen, because a solution is not available (meaning not written yet). Later on in the Intro is this: The translation of dial strings to service URNs is beyond the scope of this document; it is likely to depend on the location of the caller... I see this "beyond the scope of this document" phrase again referring to something no invented yet. Yet, with all this "location" and "URN" being interdependent to generate a robust solution, Section 4 discusses with the reader how using LoST can give an answer to this magic, from DNS: When a network entity receives a service URN, it uses the S-NAPTR [6] mechanism to determine how to map the service URN, possibly using other information such as geographic location, to a routable URI. example.com. ; order pref flags service regexp IN NAPTR 50 50 "a" "SURN.sos:LoST" "" ; replacement lost.example.org IN NAPTR 10 50 "s" "SURN.pizza:PLP" "" _plp._tcp.pizzahouse.example.net Somehow not specified here, something "beyond the scope of this document" was used (presumably an emergency URN and an endpoint's Location information) resulting in a LoST server URI being discovered. Now, I may be reading this wrong, but this is the impression. This document is not short of DNS references (3), or URN references (8) - yet none are near any "beyond the scope of this document" comment leading a reader to a solution of how a user's location is sent in DNS (in the clear presumably) to receive a proper LoST Server URI. I suggest all text related to DNS, especially the text giving an answer to a query, such as a LoST Server URI query, be removed from this document, and perhaps moved to another solution/mechanism document discussing that idea (using DNS to retreive a LoST URI for a endpoint). This will leave the Service URN document as an identifier document, which is what it should be, based on the charter item listed here from the ECRIT website: http://www.ietf.org/html.charters/ecrit-charter.html Mar 2006 A Standards Track RFC describing how to identify a session set-up request is to an emergency response center _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 11 15:52:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OH1-0005Q9-Tl; Tue, 11 Jul 2006 15:51:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OH0-0005Pr-Jv for ecrit@ietf.org; Tue, 11 Jul 2006 15:51:58 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0OGy-0003GL-CG for ecrit@ietf.org; Tue, 11 Jul 2006 15:51:58 -0400 Received: from [132.219.13.206] ([::ffff:132.219.13.206]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 11 Jul 2006 15:52:11 -0400 id 015880E5.44B4016B.000052D8 In-Reply-To: <4.3.2.7.2.20060711123208.02a38028@email.cisco.com> References: <4.3.2.7.2.20060711123208.02a38028@email.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <304CCD99-F9B8-436A-ADD0-45C3004F9C53@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] ECRIT WG Status - concern about service-urn-03 Date: Tue, 11 Jul 2006 15:51:52 -0400 To: "James M. Polk" X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jul 11, 2006, at 1:59 PM, James M. Polk wrote: > I'm interested in the phrase "beyond the scope of this document", > inviting magic to happen, because a solution is not available > (meaning not written yet). Perhaps these phrases could be rephrased to mean that we are talking about other documents and the details of those other documents are the responsibility of the reader to comprehend. I don't know. Maybe some genart reviewers would be willing to give us a suggestion... they tend to be good at that. > I suggest all text related to DNS, especially the text giving an > answer to a query, such as a LoST Server URI query, be removed from > this document, and perhaps moved to another solution/mechanism > document discussing that idea (using DNS to retreive a LoST URI for > a endpoint). I do not like this suggestion. This document is not just talking about a generic idea, it is about a specific mechanism. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 11 16:02:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OQy-0002It-D4; Tue, 11 Jul 2006 16:02:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0OQx-0002Hv-5A for ecrit@ietf.org; Tue, 11 Jul 2006 16:02:15 -0400 Received: from zeke.blacka.com ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0OQv-0004xM-UX for ecrit@ietf.org; Tue, 11 Jul 2006 16:02:15 -0400 Received: from [132.219.13.206] ([::ffff:132.219.13.206]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Tue, 11 Jul 2006 16:02:28 -0400 id 015880E5.44B403D4.000054E9 In-Reply-To: <44B338F1.6080005@cisco.com> References: <44B338F1.6080005@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <76E8D1DF-FBE6-4064-83CB-F3572F8B0981@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] comments on LoST Date: Tue, 11 Jul 2006 16:02:10 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jul 11, 2006, at 1:36 AM, Jonathan Rosenberg wrote: > Major: > > * LoST doesn't allow for any variability in the format of location > information. I wonder if it makes sense to include an indication of > the format of the location object, and to allow rejection if the > format is not supported. Probably you'd need a baseline for > interoperability. Rejection? Stating such a thing may be useful during validation, but rejection is not a use case. > * for dialstrings, suggest perhaps the KPML syntax for digit maps Aren't returned dialstrings to be stuck into tel or sip URIs? If so, would KPML be compatible? > * It'd be nice to be able, in a single lost query, ask for multiple > services for the same location Given the conversation on multiple locations, I'd prefer we hold off on this. It is nice to have, but keeping complexity down is also a nice to have. > * Security aspects are still really weak. You need to specify basic > proceudres as part of the basic client and server processing. > Beyond mutual tls I think we want a standard server side > authentication mechanism as well, with no client authentication Being able to have that would be nice, but server side authentication will not work world wide. I suppose it would depend on the TLS library, but some would require a requery with different options if the first query failed due to bad authentication. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 11 16:36:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Oxf-00073X-Q5; Tue, 11 Jul 2006 16:36:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Oxf-00073S-1o for ecrit@ietf.org; Tue, 11 Jul 2006 16:36:03 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Oxd-0000fW-RI for ecrit@ietf.org; Tue, 11 Jul 2006 16:36:03 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G0OxV-0003JH-6l; Tue, 11 Jul 2006 15:35:53 -0500 From: "Brian Rosen" To: "'Andrew Newton'" , "'Jonathan Rosenberg'" Subject: RE: [Ecrit] comments on LoST Date: Tue, 11 Jul 2006 16:35:54 -0400 Message-ID: <04a401c6a529$9e6c07c0$bc1cdb84@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcalJOXVG9yXWRJDTLG30GcP0vJszgAALUtA In-Reply-To: <76E8D1DF-FBE6-4064-83CB-F3572F8B0981@hxr.us> X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >> * for dialstrings, suggest perhaps the KPML syntax for digit maps > >Aren't returned dialstrings to be stuck into tel or sip URIs? If so, >would KPML be compatible? This is a non-trivial issue. In general, they are dialstrings. However, what you do with them is to use them to find the dialstring when entered (and substitute the service urn). One way to do that is to modify the digit map. But, in general, that is a VERY hard task - take an arbitrary digit map and modify it to find the emergency dialstrings, even if they conflict with the existing dial plan. So, I don't think you really do that: you don't attempt to modify the digit map. You use a totally independent check on entered digits and look for the strings. For that, a simple string representation is the best. You could have two independent KPML digit maps, but I think that is pretty silly, because it really is a straight string match with a (list of) dialstring(s). Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 11 17:13:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0PXg-000375-2T; Tue, 11 Jul 2006 17:13:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0PXe-000370-SQ for ecrit@ietf.org; Tue, 11 Jul 2006 17:13:14 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0PXc-0004FZ-KE for ecrit@ietf.org; Tue, 11 Jul 2006 17:13:14 -0400 Received: from [132.219.26.162] (h1aa2-net84db.lab.risq.net [132.219.26.162] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6BLD4d7001882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 11 Jul 2006 17:13:04 -0400 (EDT) Message-ID: <44B4145D.3080402@cs.columbia.edu> Date: Tue, 11 Jul 2006 17:13:01 -0400 From: Henning Schulzrinne User-Agent: Thunderbird 1.5.0.4 (Macintosh/20060516) MIME-Version: 1.0 To: Andrew Newton Subject: Re: [Ecrit] comments on LoST References: <44B338F1.6080005@cisco.com> <76E8D1DF-FBE6-4064-83CB-F3572F8B0981@hxr.us> In-Reply-To: <76E8D1DF-FBE6-4064-83CB-F3572F8B0981@hxr.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I generally agree with Andrew, with some additional comments: >> * for dialstrings, suggest perhaps the KPML syntax for digit maps > > Aren't returned dialstrings to be stuck into tel or sip URIs? If so, > would KPML be compatible? From my view, KPML mainly adds the ability to express dial patterns. I'm not sure that capability is all that useful for services. Would you want to say "dialing any number starting with 9 gets you emergency services?" (Obviously, this also increases the mischief potential: "Dial [any number] to get to PizzaHouse pizza!") > >> * It'd be nice to be able, in a single lost query, ask for multiple >> services for the same location > > Given the conversation on multiple locations, I'd prefer we hold off on > this. It is nice to have, but keeping complexity down is also a nice to > have. To add to this, these services may also have different service areas, so you may not save a whole lot of bytes by doing that. Plus, you now have much more complicated failures: "Sorry, the third service you specified did not exist". Note that different top-level services can also go to different LoST servers, so we now have to worry about people putting unrelated services in one query, creating yet another error case. > > Being able to have that would be nice, but server side authentication > will not work world wide. I suppose it would depend on the TLS library, > but some would require a requery with different options if the first > query failed due to bad authentication. I don't see client authentication as particularly helpful in general, given that the mapping information is generally public. Server authentication would probably generally follow the HTTP(S) model, where you might have the same information available in both modes. > > -andy > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 11 17:21:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Pfz-00044S-Tg; Tue, 11 Jul 2006 17:21:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Pfy-00044N-JQ for ecrit@ietf.org; Tue, 11 Jul 2006 17:21:50 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Pfw-0004sW-BU for ecrit@ietf.org; Tue, 11 Jul 2006 17:21:50 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2006 13:28:35 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,230,1149490800"; d="scan'208"; a="31863497:sNHT29949924" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6BKSZTR027777; Tue, 11 Jul 2006 16:28:35 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6BKSZdU020704; Tue, 11 Jul 2006 16:28:35 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 16:28:35 -0400 Received: from jmpolk-wxp.cisco.com ([10.86.242.165]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 16:28:34 -0400 Message-Id: <4.3.2.7.2.20060711152239.03292008@email.cisco.com> X-Sender: jmpolk@email.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 11 Jul 2006 15:27:51 -0500 To: Andrew Newton From: "James M. Polk" Subject: Re: [Ecrit] ECRIT WG Status - concern about service-urn-03 In-Reply-To: <304CCD99-F9B8-436A-ADD0-45C3004F9C53@hxr.us> References: <4.3.2.7.2.20060711123208.02a38028@email.cisco.com> <4.3.2.7.2.20060711123208.02a38028@email.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 11 Jul 2006 20:28:34.0708 (UTC) FILETIME=[95334D40:01C6A528] DKIM-Signature: a=rsa-sha1; q=dns; l=1038; t=1152649715; x=1153513715; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=22James=20M.=20Polk=22=20 |Subject:Re=3A=20[Ecrit]=20ECRIT=20WG=20Status=20-=20concern=20about=20service-ur n-03 |To:Andrew=20Newton=20; X=v=3Dcisco.com=3B=20h=3DxPO8tgqI8oxERLgGSETweS+LL+A=3D; b=k3ZdWfKpxOb0S0atfi/Mo1ON516wvz8rL10Fa7kDLYNTwEDlkYyrXLWrx+oIAKNWhfZlT3jM ZiwsUYMgrrQezX+foBqXjbdHT6CsXzHov1EjxwI3KbzSAMVeaBPq45jP; Authentication-Results: rtp-dkim-2.cisco.com; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 03:51 PM 7/11/2006 -0400, Andrew Newton wrote: >>I suggest all text related to DNS, especially the text giving an >>answer to a query, such as a LoST Server URI query, be removed from >>this document, and perhaps moved to another solution/mechanism >>document discussing that idea (using DNS to retreive a LoST URI for >>a endpoint). > >I do not like this suggestion. This document is not just talking >about a generic idea, it is about a specific mechanism. I believe this document is tasked with one specific idea: creating an emergency identifier. But it seems to do more than that, and that "more" part is seriously incomplete, hinting at things not even written anywhere yet. If they were written, they would clearly be normatively referenced here, but they aren't written, so they can't be. That's a problem. The ECRIT milestone is to create a Standards Track doc for an emergency identifier. This doc shouldn't add to this task, IMO. The identifier is good, and it needs to be RFCd. >-andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 11 18:38:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Qru-0001Fh-Kt; Tue, 11 Jul 2006 18:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Qrs-0001Fc-RL for ecrit@ietf.org; Tue, 11 Jul 2006 18:38:12 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0Qrr-0008JA-HV for ecrit@ietf.org; Tue, 11 Jul 2006 18:38:12 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 11 Jul 2006 15:05:46 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.06,230,1149490800"; d="scan'208"; a="31890025:sNHT27201084" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6BM5lYS000340; Tue, 11 Jul 2006 18:05:47 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6BM5kdU013286; Tue, 11 Jul 2006 18:05:46 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 18:05:46 -0400 Received: from [132.219.13.201] ([10.86.240.181]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 11 Jul 2006 18:05:46 -0400 Message-ID: <44B420BA.9080907@cisco.com> Date: Tue, 11 Jul 2006 18:05:46 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] comments on LoST References: <04a401c6a529$9e6c07c0$bc1cdb84@cis.neustar.com> In-Reply-To: <04a401c6a529$9e6c07c0$bc1cdb84@cis.neustar.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jul 2006 22:05:46.0177 (UTC) FILETIME=[2906DB10:01C6A536] DKIM-Signature: a=rsa-sha1; q=dns; l=1905; t=1152655547; x=1153519547; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:Jonathan=20Rosenberg=20 |Subject:Re=3A=20[Ecrit]=20comments=20on=20LoST |To:Brian=20Rosen=20; X=v=3Dcisco.com=3B=20h=3DIdKsEI0vuIhDvckWAbrSX4K6l38=3D; b=P+qqbhD7Cx++zk6WUGMrRf+PeSRYtOE2MFwQuWo/NyjV+JzeQl+P7rix7k1Ms2gH/+WxiqHv I7198nUQGIaOtWUbcsB7ObXij51ULrOz916uLRluXvYdPeXO/8K85+Pe; Authentication-Results: rtp-dkim-1.cisco.com; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Some of my thinking is that the scope of LoST isn't JUST emergency services. Its not obvious to me that there will NEVER be a location-based service that has a digit-map that is more complex than an exact match to a fix set of digits. I wasn't proposing to merge dial plans. I don't think you have to do that to use a digit map for emergency services. You would, as you suggest, effectively run them in parallel, and if the emergency digit map matches before anything configured, use it. Thanks, Jonathan R. Brian Rosen wrote: >>>* for dialstrings, suggest perhaps the KPML syntax for digit maps >> >>Aren't returned dialstrings to be stuck into tel or sip URIs? If so, >>would KPML be compatible? > > This is a non-trivial issue. > > In general, they are dialstrings. However, what you do with them is to use > them to find the dialstring when entered (and substitute the service urn). > One way to do that is to modify the digit map. > > But, in general, that is a VERY hard task - take an arbitrary digit map and > modify it to find the emergency dialstrings, even if they conflict with the > existing dial plan. > > So, I don't think you really do that: you don't attempt to modify the digit > map. You use a totally independent check on entered digits and look for the > strings. For that, a simple string representation is the best. > > You could have two independent KPML digit maps, but I think that is pretty > silly, because it really is a straight string match with a (list of) > dialstring(s). > > Brian > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 11 20:43:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0SpL-0005Ki-Bo; Tue, 11 Jul 2006 20:43:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0SpK-0005Kd-4C for ecrit@ietf.org; Tue, 11 Jul 2006 20:43:42 -0400 Received: from aismt08p.bellsouth.com ([139.76.165.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0SpJ-00068h-J9 for ecrit@ietf.org; Tue, 11 Jul 2006 20:43:42 -0400 Received: from ([90.152.53.181]) by aismt08p.bellsouth.com with SMTP id KP-AXPNC.148741129; Tue, 11 Jul 2006 20:43:27 -0400 Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01AL10015010162.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Jul 2006 19:43:27 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Date: Tue, 11 Jul 2006 19:43:26 -0500 Message-ID: <9888E1AA13C3A1459D122996A58C0E1107CA35A9@bre2k61p-55> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) thread-index: AcacS01AozzxQH4SRpCO5st6hhUFBQI/jIJw From: "Stark, Barbara" To: "Andrew Newton" , "Rohan Mahy" X-OriginalArrivalTime: 12 Jul 2006 00:43:27.0351 (UTC) FILETIME=[30537070:01C6A54C] X-Spam-Score: 0.2 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: "Rosen, Brian" , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1308287003==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1308287003== Content-Transfer-Encoding: 7bit Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A54C.2FCD5F26" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A54C.2FCD5F26 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the = network operator does not control the specification of every device = connected to the network.": =20 If the device has a DHCP client, the client MUST support RFC 3825 and = .=20 and If the device supports LLDP-MED, it MUST support the "Location = Identification TLV" as defined in .=20 =20 Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED = spec), the 2nd if statement really doesn't say much. But it would also = suggest that devices that could have soft clients on them (PCs, PDAs) = also need to do that TLV when they do LLDP-MED. All router-type devices = that implement LLDP-MED are also required to support this TLV, per the = spec. =20 Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also = reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP = INFORM message with options as described in RFC 3825 and , = when it is configured to use one of these alternate bootstrap methods = (e.g., PPPoE, PPPoA, static IP address). =20 Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. = If a vendor can't justify putting one or the other of these into a = device (outside of recommendations in this BCP), then I say the protocol = doesn't belong in the device. If the device is going to have one or the = other, or both, then it needs to support the location determination = mechanism that goes with it. Since, for LLDP-MED, that's already a = requirement of the LLDP-MED spec, I really don't see a problem with = stating it here. Barbara =20 -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: To be clear, I do not have a strong feeling about what does on Brian's = list or not. I think LLDP-MED is a completely reasonable thing for a = wired phone vendor to implement on enterprise class phones.=20 Just throwing in my $0.0199997, I have not formed a strong opinion about = this either. It does seem reasonable for enterprise class devices with = ethernet jacks to implement LLPD-MED, or for devices of category Y to = implement method X... as what must be implemented by the device will = always be dictated by the network media it uses. Where this gets a little tricky is that if there is no one common = method, then devices may end up implementing things that are not = appropriate in an attempt to have devices that work in multiple network = environments... and even then they may end up missing the mark. = Therefore, one method that does work in all environments must be = implemented. And that is likely to be the L7-LCP. -andy ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 162 ------_=_NextPart_001_01C6A54C.2FCD5F26 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
What=20 I'd like to see in the doc would be:
For any device that's "intended to be operated on a = network where=20 the network operator does not control the specification of every device=20 connected to the network.":
 
If the device has a = DHCP client, the=20 client MUST support RFC 3825 and <dhcp-civil>.
   and
If the device supports = LLDP-MED, it MUST=20 support the "Location Identification TLV" as defined in <LLDP-MED=20 reference>.
 
Given=20 that the Location Identification TLV is mandatory for all VoIP-type = endpoints=20 implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if = statement=20 really doesn't say much. But it would also suggest that devices that = could have=20 soft clients on them (PCs, PDAs) also need to do that TLV when they do = LLDP-MED.=20 All router-type devices that implement LLDP-MED are also required to = support=20 this TLV, per the spec.
 
Since=20 I'm really not at all concerned with the behavior of endpoints that = don't have a=20 DHCP client, I think the first if statement is also = reasonable.=20 However, I do recommend for such devices that:
If the device allows = for=20 bootstrapping methods other than DHCP, it SHOULD support being = configured to=20 request location through a DHCP INFORM message with options as described = in RFC=20 3825 and <dhcp-civil>, when it is configured to use one of these = alternate=20 bootstrap methods (e.g., PPPoE, PPPoA, static IP address).
 
Anyway, I think both DHCP clients and LLDP-MED need to make it = into=20 devices based on all their merits, and not just on location discovery. = If a=20 vendor can't justify putting one or the other of these into a device = (outside of=20 recommendations in this BCP), then I say the protocol doesn't belong in = the=20 device. If the device is going to have one or the other, or both, then = it needs=20 to support the location determination mechanism that goes with it. = Since, for=20 LLDP-MED, that's already a requirement of the LLDP-MED spec, I = really don't=20 see a problem with stating it here.
Barbara
 
-----Original Message-----
From: Andrew Newton=20 [mailto:andy@hxr.us]
Sent: Friday, June 30, 2006 9:44=20 AM
To: Rohan Mahy
Cc: Rosen, Brian;=20 Ecrit@ietf.org
Subject: Re: LLDP-MED and Phone BCP (Re: = [Ecrit] New=20 phonebcp draft wassubmitted)


On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote:
To=20 be clear, I do not have a strong feeling about what does on Brian's = list or=20 not.  I think LLDP-MED is a completely reasonable thing for a = wired=20 phone vendor to implement on enterprise class phones. 

=
Just throwing in my $0.0199997, I have not formed a strong = opinion about=20 this either.  It does seem reasonable for enterprise class = devices with=20 ethernet jacks to implement LLPD-MED, or for devices of category Y to=20 implement method X... as what must be implemented by the device will = always be=20 dictated by the network media it uses.

Where this gets a little tricky is that if there is no one common = method,=20 then devices may end up implementing things that are not appropriate = in an=20 attempt to have devices that work in multiple network environments... = and even=20 then they may end up missing the mark.  Therefore, one method = that does=20 work in all environments must be implemented.   And that is = likely=20 to be the L7-LCP.

=
-andy
<= FONT color=3D#0000ff>

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. 162

------_=_NextPart_001_01C6A54C.2FCD5F26-- --===============1308287003== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1308287003==-- From ecrit-bounces@ietf.org Tue Jul 11 20:56:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0T29-0005yX-Pi; Tue, 11 Jul 2006 20:56:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0T27-0005yS-Nq for Ecrit@ietf.org; Tue, 11 Jul 2006 20:56:55 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0T27-00013L-AO for Ecrit@ietf.org; Tue, 11 Jul 2006 20:56:55 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6C0upQB020962; Wed, 12 Jul 2006 00:56:51 GMT Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 20:56:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Date: Tue, 11 Jul 2006 20:56:51 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Thread-Index: AcacS01AozzxQH4SRpCO5st6hhUFBQI/jIJwAAEkA+4= From: "Rosen, Brian" To: , , X-OriginalArrivalTime: 12 Jul 2006 00:56:51.0624 (UTC) FILETIME=[0FB5C280:01C6A54E] X-Spam-Score: 1.0 (+) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1520197476==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1520197476== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A54E.0F71AC83" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A54E.0F71AC83 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable But unless every phone supports LLDP-MED, then an enterprise must also = implement DHCP (or L7) in order to support those phones that don't = support LLDP. If every access network has to support those 2, then LLDP = is superfelous. A residential phone may be plugged into an enterprise network. Ditto an = enterprise phone. Location acquisition has to work always. If there is = a list, and one end must support all, with the other end must support at = least one, it always works. =20 I don't see how you can get around that -------------------------- Brian Rosen NeuStar (724) 382-1051 brian.rosen@neustar.biz -----Original Message----- From: Stark, Barbara To: Andrew Newton; Rohan Mahy CC: Rosen, Brian; Ecrit@ietf.org Sent: Tue Jul 11 20:43:26 2006 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the = network operator does not control the specification of every device = connected to the network.": =20 If the device has a DHCP client, the client MUST support RFC 3825 and = .=20 and If the device supports LLDP-MED, it MUST support the "Location = Identification TLV" as defined in .=20 =20 Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED = spec), the 2nd if statement really doesn't say much. But it would also = suggest that devices that could have soft clients on them (PCs, PDAs) = also need to do that TLV when they do LLDP-MED. All router-type devices = that implement LLDP-MED are also required to support this TLV, per the = spec. =20 Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also = reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP = INFORM message with options as described in RFC 3825 and , = when it is configured to use one of these alternate bootstrap methods = (e.g., PPPoE, PPPoA, static IP address). =20 Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. = If a vendor can't justify putting one or the other of these into a = device (outside of recommendations in this BCP), then I say the protocol = doesn't belong in the device. If the device is going to have one or the = other, or both, then it needs to support the location determination = mechanism that goes with it. Since, for LLDP-MED, that's already a = requirement of the LLDP-MED spec, I really don't see a problem with = stating it here. Barbara =20 -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) =09 =09 On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: To be clear, I do not have a strong feeling about what does on Brian's = list or not. I think LLDP-MED is a completely reasonable thing for a = wired phone vendor to implement on enterprise class phones.=20 Just throwing in my $0.0199997, I have not formed a strong opinion = about this either. It does seem reasonable for enterprise class devices = with ethernet jacks to implement LLPD-MED, or for devices of category Y = to implement method X... as what must be implemented by the device will = always be dictated by the network media it uses. Where this gets a little tricky is that if there is no one common = method, then devices may end up implementing things that are not = appropriate in an attempt to have devices that work in multiple network = environments... and even then they may end up missing the mark. = Therefore, one method that does work in all environments must be = implemented. And that is likely to be the L7-LCP. -andy ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 162 ------_=_NextPart_001_01C6A54E.0F71AC83 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted)

But unless every phone supports LLDP-MED, then an = enterprise must also implement DHCP (or L7) in order to support those = phones that don't support LLDP.  If every access network has to = support those 2, then LLDP is superfelous.

A residential phone may be plugged into an enterprise network.  = Ditto an enterprise phone.  Location acquisition has to work = always.  If there is a list, and one end must support all, with the = other end must support at least one, it always works. 

I don't see how you can get around that
--------------------------
Brian Rosen
NeuStar
(724) 382-1051
brian.rosen@neustar.biz


-----Original Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan Mahy
CC: Rosen, Brian; Ecrit@ietf.org
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted)

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where = the network operator does not control the specification of every device = connected to the network.":

If the device has a DHCP client, the client MUST support RFC 3825 and = <dhcp-civil>.
   and
If the device supports LLDP-MED, it MUST support the "Location = Identification TLV" as defined in <LLDP-MED reference>.

Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED = spec), the 2nd if statement really doesn't say much. But it would also = suggest that devices that could have soft clients on them (PCs, PDAs) = also need to do that TLV when they do LLDP-MED. All router-type devices = that implement LLDP-MED are also required to support this TLV, per the = spec.

Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also = reasonable. However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP = INFORM message with options as described in RFC 3825 and = <dhcp-civil>, when it is configured to use one of these alternate = bootstrap methods (e.g., PPPoE, PPPoA, static IP address).

Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. = If a vendor can't justify putting one or the other of these into a = device (outside of recommendations in this BCP), then I say the protocol = doesn't belong in the device. If the device is going to have one or the = other, or both, then it needs to support the location determination = mechanism that goes with it. Since, for LLDP-MED, that's already a = requirement of the LLDP-MED spec, I really don't see a problem with = stating it here.
Barbara


        -----Original = Message-----
        From: Andrew Newton [mailto:andy@hxr.us]
        Sent: Friday, June 30, 2006 = 9:44 AM
        To: Rohan Mahy
        Cc: Rosen, Brian; = Ecrit@ietf.org
        Subject: Re: LLDP-MED and = Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)
       
       

        On Jun 29, 2006, at 6:29 PM, = Rohan Mahy wrote:


        =         To be clear, I do not have a = strong feeling about what does on Brian's list or not.  I think = LLDP-MED is a completely reasonable thing for a wired phone vendor to = implement on enterprise class phones.


        Just throwing in my = $0.0199997, I have not formed a strong opinion about this either.  = It does seem reasonable for enterprise class devices with ethernet jacks = to implement LLPD-MED, or for devices of category Y to implement method = X... as what must be implemented by the device will always be dictated = by the network media it uses.

        Where this gets a little = tricky is that if there is no one common method, then devices may end up = implementing things that are not appropriate in an attempt to have = devices that work in multiple network environments... and even then they = may end up missing the mark.  Therefore, one method that does work = in all environments must be implemented.   And that is likely = to be the L7-LCP.

        -andy

*****

The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 162

------_=_NextPart_001_01C6A54E.0F71AC83-- --===============1520197476== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1520197476==-- From ecrit-bounces@ietf.org Tue Jul 11 23:41:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Vbf-00064q-41; Tue, 11 Jul 2006 23:41:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0Vbe-00062m-9e for Ecrit@ietf.org; Tue, 11 Jul 2006 23:41:46 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0VYs-0002j2-Mk for Ecrit@ietf.org; Tue, 11 Jul 2006 23:38:55 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 22:38:54 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Tue, 11 Jul 2006 22:38:53 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Jul 2006 22:38:53 -0500 Message-ID: From: "Winterbottom, James" To: "Stark, Barbara" , "Andrew Newton" , "Rohan Mahy" Date: Tue, 11 Jul 2006 22:38:51 -0500 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draftwassubmitted) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 12 Jul 2006 03:38:53.0105 (UTC) FILETIME=[B22A0A10:01C6A564] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1107CA35A9@bre2k61p-55> Content-class: urn:content-classes:message Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draftwassubmitted) Thread-Index: AcacS01AozzxQH4SRpCO5st6hhUFBQI/jIJwAAaF0/A= X-Spam-Score: 0.3 (/) X-Scan-Signature: 20f22c03b5c66958bff5ef54fcda6e48 Cc: "Rosen, Brian" , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0971075836==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0971075836== Content-Type: multipart/alternative; boundary="--=_NextPart_ST_22_38_53_Tuesday_July_11_2006_27614" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ----=_NextPart_ST_22_38_53_Tuesday_July_11_2006_27614 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I would be very cautious about recommending the use of RFC-3825 encoding to report emergency locations given the issues raised at IETF-65 in Dallas that are yet to be adequately resolved. In NENA we put a caveat around its use to the effect that location provided in this manner must be regarded as a point only, and that encodings for resolution must be ignored. =20 Cheers James =20 =20 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] ----=_NextPart_ST_22_38_53_Tuesday_July_11_2006_27614 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I would be very cautious about recommending the use of RFC-3825 encoding to report emergency locations giv= en the issues raised at IETF-65 in Dallas that are yet to be adequately resolv= ed. In NENA we put a caveat around its use to the effect that location provided in this manner must be regarded as a point only, and that encodings for resolu= tion must be ignored.

 

Cheers

James

 

 


-----------------------------------------------------------------------= -------------------------
This message is for the designated recipient o= nly and may
contain privileged, proprietary, or otherwise private inform= ation.
If you have received it in error, please notify the sender
i= mmediately and delete the original. Any unauthorized use of
this email = is prohibited.
---------------------------------------------------------= ---------------------------------------
[mf2]

*****

The information transmitted= is intended only for the person or entity to which it is addressed and may= contain confidential, proprietary, and/or privileged material. Any review,= retransmission, dissemination or other use of, or taking of any action in = reliance upon this information by persons or entities other than the intend= ed recipient is prohibited. If you received this in error, please contact t= he sender and delete the material from all computers. 162

 ----=_NextPart_ST_22_38_53_Tuesday_July_11_2006_27614-- --===============0971075836== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0971075836==-- From ecrit-bounces@ietf.org Wed Jul 12 08:05:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0dTX-0005ZD-T0; Wed, 12 Jul 2006 08:05:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0dTX-0005YO-7G for Ecrit@ietf.org; Wed, 12 Jul 2006 08:05:55 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0dTW-0008I9-GV for Ecrit@ietf.org; Wed, 12 Jul 2006 08:05:55 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id EDAA820072; Wed, 12 Jul 2006 08:05:53 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19103-09; Wed, 12 Jul 2006 08:05:52 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id EF0F220079; Wed, 12 Jul 2006 08:05:51 -0400 (EDT) To: "Stark, Barbara" Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: peter_blatherwick@mitel.com Date: Wed, 12 Jul 2006 07:55:47 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 07/12/2006 08:05:51 AM, Serialize complete at 07/12/2006 08:05:51 AM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.8 (/) X-Scan-Signature: ec7c6dab5a62df223002ae71b5179d41 Cc: "Rosen, Brian" , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0876513708==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0876513708== Content-Type: multipart/alternative; boundary="=_alternative 004189F9852571A9_=" This is a multipart message in MIME format. --=_alternative 004189F9852571A9_= Content-Type: text/plain; charset="us-ascii" Hi Barbara, I like the structure of what you are suggesting, and think the same general form could apply to other mechanisms as they come along. Perhaps it reduces to "for every configuration method the endpoint supports, there MUST be support for the corresponding location method". Then add some more "MUST" details for the ones known at this time. Right now we have as methods: DHCP, LLDP-MED, some sort of L7. It seems likely there will be some WLAN approach as well (which could also be LLDP-MED-based ... but lets not reignite debate on yet unknown IEEE decisions). I doubt we would see more any time soon. Seems manageable. And, yes, saying the Location Identification TLVs are MUST for LLDP-MED is redundant, but it is certainly worth saying anyway. > Anyway, I think both DHCP clients and LLDP-MED need to make it into devices based on all their merits, and not just on location discovery. ... Agree. An additional point is that network administrators also make these decisions. The approach used absolutely must match how the network want to run their network, or it will either not be turned on at all or (perhaps worse) it will be on but maintained as a sideline, leading to lowered accuracy and reliability. -- Peter "Stark, Barbara" 11.07.06 20:43 To: "Andrew Newton" , "Rohan Mahy" cc: "Rosen, Brian" , Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the network operator does not control the specification of every device connected to the network.": If the device has a DHCP client, the client MUST support RFC 3825 and . and If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in . Given that the Location Identification TLV is mandatory for all VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if statement really doesn't say much. But it would also suggest that devices that could have soft clients on them (PCs, PDAs) also need to do that TLV when they do LLDP-MED. All router-type devices that implement LLDP-MED are also required to support this TLV, per the spec. Since I'm really not at all concerned with the behavior of endpoints that don't have a DHCP client, I think the first if statement is also reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it SHOULD support being configured to request location through a DHCP INFORM message with options as described in RFC 3825 and , when it is configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static IP address). Anyway, I think both DHCP clients and LLDP-MED need to make it into devices based on all their merits, and not just on location discovery. If a vendor can't justify putting one or the other of these into a device (outside of recommendations in this BCP), then I say the protocol doesn't belong in the device. If the device is going to have one or the other, or both, then it needs to support the location determination mechanism that goes with it. Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really don't see a problem with stating it here. Barbara -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: To be clear, I do not have a strong feeling about what does on Brian's list or not. I think LLDP-MED is a completely reasonable thing for a wired phone vendor to implement on enterprise class phones. Just throwing in my $0.0199997, I have not formed a strong opinion about this either. It does seem reasonable for enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices of category Y to implement method X... as what must be implemented by the device will always be dictated by the network media it uses. Where this gets a little tricky is that if there is no one common method, then devices may end up implementing things that are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark. Therefore, one method that does work in all environments must be implemented. And that is likely to be the L7-LCP. -andy ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162_______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 004189F9852571A9_= Content-Type: text/html; charset="us-ascii"
Hi Barbara,

I like the structure of what you are suggesting, and think the same general form could apply to other mechanisms as they come along.  Perhaps it reduces to "for every configuration method the endpoint supports, there MUST be support for the corresponding location method".   Then add some more "MUST" details for the ones known at this time.  Right now we have as methods: DHCP, LLDP-MED, some sort of L7.  It seems likely there will be some WLAN approach as well (which could also be LLDP-MED-based ... but lets not reignite debate on yet unknown IEEE decisions).  I doubt we would see more any time soon.  Seems manageable.  

And, yes, saying the Location Identification TLVs are MUST for LLDP-MED is redundant, but it is certainly worth saying anyway.  

> Anyway, I think both DHCP clients and LLDP-MED need to make it into devices based on all their merits, and not just on location discovery.  ...
Agree.  An additional point is that network administrators also make these decisions.  The approach used absolutely must match how the network want to run their network, or it will either not be turned on at all or (perhaps worse) it will be on but maintained as a sideline, leading to lowered accuracy and reliability.  

-- Peter





"Stark, Barbara" <Barbara.Stark@BellSouth.com>

11.07.06 20:43

       
        To:        "Andrew Newton" <andy@hxr.us>, "Rohan Mahy" <rohan.mahy@gmail.com>
        cc:        "Rosen, Brian" <Brian.Rosen@neustar.biz>, Ecrit@ietf.org
        Subject:        RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft        wassubmitted)



What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where the network operator does not control the specification of every device connected to the network.":
 
If the device has a DHCP client, the client MUST support RFC 3825 and <dhcp-civil>.
   and
If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in <LLDP-MED reference>.
 
Given that the Location Identification TLV is mandatory for all VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if statement really doesn't say much. But it would also suggest that devices that could have soft clients on them (PCs, PDAs) also need to do that TLV when they do LLDP-MED. All router-type devices that implement LLDP-MED are also required to support this TLV, per the spec.
 
Since I'm really not at all concerned with the behavior of endpoints that don't have a DHCP client, I think the first if statement is also reasonable. However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it SHOULD support being configured to request location through a DHCP INFORM message with options as described in RFC 3825 and <dhcp-civil>, when it is configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static IP address).
 
Anyway, I think both DHCP clients and LLDP-MED need to make it into devices based on all their merits, and not just on location discovery. If a vendor can't justify putting one or the other of these into a device (outside of recommendations in this BCP), then I say the protocol doesn't belong in the device. If the device is going to have one or the other, or both, then it needs to support the location determination mechanism that goes with it. Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really don't see a problem with stating it here.
Barbara
 
-----Original Message-----
From: Andrew Newton [mailto:andy@hxr.us]
Sent: Friday, June 30, 2006 9:44 AM
To: Rohan Mahy
Cc: Rosen, Brian; Ecrit@ietf.org
Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote:

To be clear, I do not have a strong feeling about what does on Brian's list or not.  I think LLDP-MED is a completely reasonable thing for a wired phone vendor to implement on enterprise class phones.

Just throwing in my $0.0199997, I have not formed a strong opinion about this either.  It does seem reasonable for enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices of category Y to implement method X... as what must be implemented by the device will always be dictated by the network media it uses.

Where this gets a little tricky is that if there is no one common method, then devices may end up implementing things that are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark.  Therefore, one method that does work in all environments must be implemented.   And that is likely to be the L7-LCP.

-andy

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--=_alternative 004189F9852571A9_=-- --===============0876513708== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0876513708==-- From ecrit-bounces@ietf.org Wed Jul 12 08:06:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0dUA-0006lU-Mu; Wed, 12 Jul 2006 08:06:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0dU9-0006lP-7k for Ecrit@ietf.org; Wed, 12 Jul 2006 08:06:33 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0dU8-0008JO-HS for Ecrit@ietf.org; Wed, 12 Jul 2006 08:06:33 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 38B5D2008C; Wed, 12 Jul 2006 08:06:32 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19592-01; Wed, 12 Jul 2006 08:06:30 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id F10A7200A9; Wed, 12 Jul 2006 08:06:19 -0400 (EDT) To: "Rosen, Brian" Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: peter_blatherwick@mitel.com Date: Wed, 12 Jul 2006 08:04:44 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 07/12/2006 08:06:19 AM, Serialize complete at 07/12/2006 08:06:19 AM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 1.2 (+) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: Barbara.Stark@bellsouth.com, Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0426563080==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0426563080== Content-Type: multipart/alternative; boundary="=_alternative 00425BB3852571A9_=" This is a multipart message in MIME format. --=_alternative 00425BB3852571A9_= Content-Type: text/plain; charset="us-ascii" Brian, Counter-point to below is that if the device and network do not support mutually agreeable configuration method, then the device is a brick anyway. L7 becomes a fall-back for the cases where the direct configuration method does not support passing location through (best example seems to be home router on DSL or cable modem). An important case, not sure well heard yesterday during meeting, was that in an IPv6 environment with address autoconfig there may be no DHCP at all. This may or may not be a small case as IPv6 rolls out, remains to be seen. And while IPv6 is not really important now in N.A. it is very rapidly becoming important in Asia/Pac and also Australia (I'm told). Cannot ignore it. -- Peter "Rosen, Brian" 11.07.06 20:56 To: , , cc: Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) But unless every phone supports LLDP-MED, then an enterprise must also implement DHCP (or L7) in order to support those phones that don't support LLDP. If every access network has to support those 2, then LLDP is superfelous. A residential phone may be plugged into an enterprise network. Ditto an enterprise phone. Location acquisition has to work always. If there is a list, and one end must support all, with the other end must support at least one, it always works. I don't see how you can get around that -------------------------- Brian Rosen NeuStar (724) 382-1051 brian.rosen@neustar.biz -----Original Message----- From: Stark, Barbara To: Andrew Newton; Rohan Mahy CC: Rosen, Brian; Ecrit@ietf.org Sent: Tue Jul 11 20:43:26 2006 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the network operator does not control the specification of every device connected to the network.": If the device has a DHCP client, the client MUST support RFC 3825 and . and If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in . Given that the Location Identification TLV is mandatory for all VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if statement really doesn't say much. But it would also suggest that devices that could have soft clients on them (PCs, PDAs) also need to do that TLV when they do LLDP-MED. All router-type devices that implement LLDP-MED are also required to support this TLV, per the spec. Since I'm really not at all concerned with the behavior of endpoints that don't have a DHCP client, I think the first if statement is also reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it SHOULD support being configured to request location through a DHCP INFORM message with options as described in RFC 3825 and , when it is configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static IP address). Anyway, I think both DHCP clients and LLDP-MED need to make it into devices based on all their merits, and not just on location discovery. If a vendor can't justify putting one or the other of these into a device (outside of recommendations in this BCP), then I say the protocol doesn't belong in the device. If the device is going to have one or the other, or both, then it needs to support the location determination mechanism that goes with it. Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really don't see a problem with stating it here. Barbara -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: To be clear, I do not have a strong feeling about what does on Brian's list or not. I think LLDP-MED is a completely reasonable thing for a wired phone vendor to implement on enterprise class phones. Just throwing in my $0.0199997, I have not formed a strong opinion about this either. It does seem reasonable for enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices of category Y to implement method X... as what must be implemented by the device will always be dictated by the network media it uses. Where this gets a little tricky is that if there is no one common method, then devices may end up implementing things that are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark. Therefore, one method that does work in all environments must be implemented. And that is likely to be the L7-LCP. -andy ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 00425BB3852571A9_= Content-Type: text/html; charset="us-ascii"
Brian,
Counter-point to below is that if the device and network do not support mutually agreeable configuration method, then the device is a brick anyway.  L7 becomes a fall-back for the cases where the direct configuration method does not support passing location through (best example seems to be home router on DSL or cable modem).  
An important case, not sure well heard yesterday during meeting, was that in an IPv6 environment with address autoconfig there may be no DHCP at all.  This may or may not be a small case as IPv6 rolls out, remains to be seen.  And while IPv6 is not really important now in N.A. it is very rapidly becoming important in Asia/Pac and also Australia (I'm told).  Cannot ignore it.  
-- Peter



"Rosen, Brian" <Brian.Rosen@neustar.biz>

11.07.06 20:56

       
        To:        <Barbara.Stark@bellsouth.com>, <andy@hxr.us>, <rohan.mahy@gmail.com>
        cc:        Ecrit@ietf.org
        Subject:        Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft        wassubmitted)



But unless every phone supports LLDP-MED, then an enterprise must also implement DHCP (or L7) in order to support those phones that don't support LLDP.  If every access network has to support those 2, then LLDP is superfelous.

A residential phone may be plugged into an enterprise network.  Ditto an enterprise phone.  Location acquisition has to work always.  If there is a list, and one end must support all, with the other end must support at least one, it always works.

I don't see how you can get around that
--------------------------
Brian Rosen
NeuStar
(724) 382-1051
brian.rosen@neustar.biz


-----Original Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan Mahy
CC: Rosen, Brian; Ecrit@ietf.org
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where the network operator does not control the specification of every device connected to the network.":

If the device has a DHCP client, the client MUST support RFC 3825 and <dhcp-civil>.
  and
If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in <LLDP-MED reference>.

Given that the Location Identification TLV is mandatory for all VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if statement really doesn't say much. But it would also suggest that devices that could have soft clients on them (PCs, PDAs) also need to do that TLV when they do LLDP-MED. All router-type devices that implement LLDP-MED are also required to support this TLV, per the spec.

Since I'm really not at all concerned with the behavior of endpoints that don't have a DHCP client, I think the first if statement is also reasonable. However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it SHOULD support being configured to request location through a DHCP INFORM message with options as described in RFC 3825 and <dhcp-civil>, when it is configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static IP address).

Anyway, I think both DHCP clients and LLDP-MED need to make it into devices based on all their merits, and not just on location discovery. If a vendor can't justify putting one or the other of these into a device (outside of recommendations in this BCP), then I say the protocol doesn't belong in the device. If the device is going to have one or the other, or both, then it needs to support the location determination mechanism that goes with it. Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really don't see a problem with stating it here.
Barbara


       -----Original Message-----
       From: Andrew Newton [mailto:andy@hxr.us]
       Sent: Friday, June 30, 2006 9:44 AM
       To: Rohan Mahy
       Cc: Rosen, Brian; Ecrit@ietf.org
       Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)
     
     

       On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote:


               To be clear, I do not have a strong feeling about what does on Brian's list or not.  I think LLDP-MED is a completely reasonable thing for a wired phone vendor to implement on enterprise class phones.


       Just throwing in my $0.0199997, I have not formed a strong opinion about this either.  It does seem reasonable for enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices of category Y to implement method X... as what must be implemented by the device will always be dictated by the network media it uses.

       Where this gets a little tricky is that if there is no one common method, then devices may end up implementing things that are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark.  Therefore, one method that does work in all environments must be implemented.   And that is likely to be the L7-LCP.

       -andy

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--=_alternative 00425BB3852571A9_=-- --===============0426563080== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0426563080==-- From ecrit-bounces@ietf.org Wed Jul 12 09:29:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0emY-0006Kk-Af; Wed, 12 Jul 2006 09:29:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0emX-0006K1-3H for Ecrit@ietf.org; Wed, 12 Jul 2006 09:29:37 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0emW-0003Xm-W1 for Ecrit@ietf.org; Wed, 12 Jul 2006 09:29:37 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0eeW-0004St-79 for Ecrit@ietf.org; Wed, 12 Jul 2006 09:21:22 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns4.neustar.com (Postfix) with ESMTP id F2D9D2AC2E; Wed, 12 Jul 2006 13:20:49 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 09:20:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Date: Wed, 12 Jul 2006 09:20:44 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Thread-Index: Acalq55JoAEvc/K+SqG8j4hdobdddQAB+Kfw From: "Rosen, Brian" To: X-OriginalArrivalTime: 12 Jul 2006 13:20:49.0328 (UTC) FILETIME=[FDDADB00:01C6A5B5] X-Spam-Score: -3.5 (---) X-Scan-Signature: e4e7b084ad5ab70bec6636d1707b49c1 Cc: Barbara.Stark@bellsouth.com, Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0079622906==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0079622906== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A5B5.FD6F1DCA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A5B5.FD6F1DCA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This thinking results in cases where assumptions made by one end don't match assumptions made by the other. =20 Let's take LLDP as the example. Barbara would say that if the phone implements LLDP, then it should implement LLDP-MED. Okay, so suppose I have a residential phone which does not implement LLDP, so it doesn't implement LLDP-MED. So far, so good. Now, let's look at an enterprise network. It may implement LLDP, and thus LLDP-MED. Okay, the enterprise phone on the enterprise network works. What happens when the residential phone connects to the enterprise network? No location. Let's keep going. Suppose the residential phone implements DHCP, and thus implemented the DHCP location options. Unless the network ALSO implements DHCP location, it doesn't work. But if the enterprise implements the DHCP mechanism, then the LLDP mechanism is superfluous.=20 =20 Now take the enterprise phone and plug it into a home network, on an access network that does not meet the applicability statement of the L7 mechanism. That network deploys DHCP location. The enterprise phone can't get location unless it also implements DHCP. Now take that same phone and plug it into a network that doesn't deploy DHCP but does meet the applicability statement for the L7 protocol. The enterprise phone ALSO has to implement the L7 protocol. =20 The "implement the location mechanism corresponding to the configuration mechanism" simply does not work. You need a list, where one end implements ALL and the other end implements "at least one of" to get interoperability. There is no other way. =20 It is not the case that the L7 mechanism can be the single fall-back mechanism. It will have an applicability limit, and not all networks will meet it. This is effectively true of DHCP. It would be true of LLDP if it was on the list. It is the reason why, in this case, it is the CLIENT that must implement ALL and the server implement one of. Usually, we have the server taking the "all" role and the client taking the "at least one of" role. =20 Brian =20 ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Wednesday, July 12, 2006 8:05 AM To: Rosen, Brian Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; rohan.mahy@gmail.com Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) =20 Brian,=20 Counter-point to below is that if the device and network do not support mutually agreeable configuration method, then the device is a brick anyway. L7 becomes a fall-back for the cases where the direct configuration method does not support passing location through (best example seems to be home router on DSL or cable modem). =20 An important case, not sure well heard yesterday during meeting, was that in an IPv6 environment with address autoconfig there may be no DHCP at all. This may or may not be a small case as IPv6 rolls out, remains to be seen. And while IPv6 is not really important now in N.A. it is very rapidly becoming important in Asia/Pac and also Australia (I'm told). Cannot ignore it. =20 -- Peter=20 =20 "Rosen, Brian" =20 11.07.06 20:56=20 =20 To: , , =20 cc: Ecrit@ietf.org=20 Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) But unless every phone supports LLDP-MED, then an enterprise must also implement DHCP (or L7) in order to support those phones that don't support LLDP. If every access network has to support those 2, then LLDP is superfelous. A residential phone may be plugged into an enterprise network. Ditto an enterprise phone. Location acquisition has to work always. If there is a list, and one end must support all, with the other end must support at least one, it always works.=20 I don't see how you can get around that -------------------------- Brian Rosen NeuStar (724) 382-1051 brian.rosen@neustar.biz -----Original Message----- From: Stark, Barbara To: Andrew Newton; Rohan Mahy CC: Rosen, Brian; Ecrit@ietf.org Sent: Tue Jul 11 20:43:26 2006 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the network operator does not control the specification of every device connected to the network.": If the device has a DHCP client, the client MUST support RFC 3825 and . and If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in . Given that the Location Identification TLV is mandatory for all VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if statement really doesn't say much. But it would also suggest that devices that could have soft clients on them (PCs, PDAs) also need to do that TLV when they do LLDP-MED. All router-type devices that implement LLDP-MED are also required to support this TLV, per the spec. Since I'm really not at all concerned with the behavior of endpoints that don't have a DHCP client, I think the first if statement is also reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it SHOULD support being configured to request location through a DHCP INFORM message with options as described in RFC 3825 and , when it is configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static IP address). Anyway, I think both DHCP clients and LLDP-MED need to make it into devices based on all their merits, and not just on location discovery. If a vendor can't justify putting one or the other of these into a device (outside of recommendations in this BCP), then I say the protocol doesn't belong in the device. If the device is going to have one or the other, or both, then it needs to support the location determination mechanism that goes with it. Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really don't see a problem with stating it here. Barbara -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us ] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) =20 =20 On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: To be clear, I do not have a strong feeling about what does on Brian's list or not. I think LLDP-MED is a completely reasonable thing for a wired phone vendor to implement on enterprise class phones. Just throwing in my $0.0199997, I have not formed a strong opinion about this either. It does seem reasonable for enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices of category Y to implement method X... as what must be implemented by the device will always be dictated by the network media it uses. Where this gets a little tricky is that if there is no one common method, then devices may end up implementing things that are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark. Therefore, one method that does work in all environments must be implemented. And that is likely to be the L7-LCP. -andy ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C6A5B5.FD6F1DCA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This thinking results in cases = where assumptions made by one end don’t match assumptions made by the = other.

 

Let’s take LLDP as the example.  Barbara would say that if the phone implements LLDP, then = it should implement LLDP-MED.  Okay, so suppose I have a residential = phone which does not implement LLDP, so it doesn’t implement = LLDP-MED.  So far, so good.  Now, let’s look at an enterprise = network.  It may implement LLDP, and thus LLDP-MED.  Okay, the enterprise phone = on the enterprise network works.  What happens when the residential phone connects to the enterprise network?  No location.  Let’s = keep going.  Suppose the residential phone implements DHCP, and thus = implemented the DHCP location options.  Unless the network ALSO implements DHCP = location, it doesn’t work.  But if the enterprise implements the DHCP mechanism, then the LLDP mechanism is superfluous. =

 

Now take the enterprise phone and = plug it into a home network, on an access network that does not meet the = applicability statement of the L7 mechanism.  That network deploys DHCP = location.  The enterprise phone can’t get location unless it also implements DHCP.  Now take that same phone and plug it into a network that = doesn’t deploy DHCP but does meet the applicability statement for the L7 protocol.  The enterprise phone ALSO has to implement the L7 = protocol.

 

The “implement the location mechanism corresponding to the configuration mechanism” simply = does not work.  You need a list, where one end implements ALL and the other = end implements “at least one of” to get interoperability.  = There is no other way.

 

It is not the case that the L7 = mechanism can be the single fall-back mechanism.  It will have an = applicability limit, and not all networks will meet it.  This is effectively true = of DHCP.  It would be true of LLDP if it was on the list.  It is = the reason why, in this case, it is the CLIENT that must implement ALL and = the server implement one of.  Usually, we have the server taking the = “all” role and the client taking the “at least one of” = role.

 

Brian

 

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Wednesday, July 12, = 2006 8:05 AM
To: Rosen, Brian
Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; rohan.mahy@gmail.com
Subject: Re: LLDP-MED and = Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted)

 


Brian,
Counter-point to below is that if the device and network do not support mutually = agreeable configuration method, then the device is a brick anyway.  L7 = becomes a fall-back for the cases where the direct configuration method does not = support passing location through (best example seems to be home router on DSL or = cable modem).  
An important case, not sure well heard yesterday during meeting, was that = in an IPv6 environment with address autoconfig there may be no DHCP at all. =  This may or may not be a small case as IPv6 rolls out, remains to be seen. =  And while IPv6 is not really important now in N.A. it is very rapidly = becoming important in Asia/Pac and also Australia (I'm told).  Cannot ignore it.  
-- Peter


 

"Rosen, Brian" = <Brian.Rosen@neustar.biz>

11.07.06 20:56

       
        To:       =  <Barbara.Stark@bellsouth.com>, <andy@hxr.us>, <rohan.mahy@gmail.com>
        cc:       =  Ecrit@ietf.org
        Subject:        Re: LLDP-MED = and Phone BCP (Re: [Ecrit] New phonebcp draft       =  wassubmitted)




But unless = every phone supports LLDP-MED, then an enterprise must also implement DHCP (or L7) = in order to support those phones that don't support LLDP.  If every access = network has to support those 2, then LLDP is superfelous.

A residential phone may be plugged into an enterprise network. =  Ditto an enterprise phone.  Location acquisition has to work always. =  If there is a list, and one end must support all, with the other end must support = at least one, it always works.

I don't see how you can get around that
--------------------------
Brian Rosen
NeuStar
(724) 382-1051
brian.rosen@neustar.biz


-----Original Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan Mahy
CC: Rosen, Brian; = Ecrit@ietf.org
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where = the network operator does not control the specification of every device = connected to the network.":

If the device has a DHCP client, the client MUST support RFC 3825 and <dhcp-civil>.
  and
If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in <LLDP-MED reference>.

Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the = 2nd if statement really doesn't say much. But it would also suggest that = devices that could have soft clients on them (PCs, PDAs) also need to do that TLV = when they do LLDP-MED. All router-type devices that implement LLDP-MED are also = required to support this TLV, per the spec.

Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also reasonable. = However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP INFORM = message with options as described in RFC 3825 and <dhcp-civil>, when it is = configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, = static IP address).

Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. If a = vendor can't justify putting one or the other of these into a device (outside = of recommendations in this BCP), then I say the protocol doesn't belong in = the device. If the device is going to have one or the other, or both, then = it needs to support the location determination mechanism that goes with it. = Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really = don't see a problem with stating it here.
Barbara


       -----Original Message-----
       From: Andrew Newton [mailto:andy@hxr.us]
       Sent: Friday, June 30, 2006 9:44 AM
       To: Rohan Mahy
       Cc: Rosen, = Brian; Ecrit@ietf.org
       Subject: Re: LLDP-MED and Phone BCP (Re: = [Ecrit] New phonebcp draft wassubmitted)
     
     

       On Jun 29, 2006, at 6:29 PM, Rohan Mahy = wrote:


               To be clear, I do = not have a strong feeling about what does on Brian's list or not.  I = think LLDP-MED is a completely reasonable thing for a wired phone vendor to = implement on enterprise class phones.


       Just throwing in my $0.0199997, I have not = formed a strong opinion about this either.  It does seem reasonable for = enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices = of category Y to implement method X... as what must be implemented by the = device will always be dictated by the network media it uses.

       Where this gets a little tricky is that if = there is no one common method, then devices may end up implementing things that = are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark.  Therefore, one method that does work in all environments must be implemented.   And that is likely to be the L7-LCP.

       -andy

*****

The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or entities = other than the intended recipient is prohibited. If you received this in = error, please contact the sender and delete the material from all computers. = 162
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

------_=_NextPart_001_01C6A5B5.FD6F1DCA-- --===============0079622906== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0079622906==-- From ecrit-bounces@ietf.org Wed Jul 12 09:34:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0er6-0003qA-Hr; Wed, 12 Jul 2006 09:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0er5-0003q4-AE for Ecrit@ietf.org; Wed, 12 Jul 2006 09:34:19 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0er2-00048n-NW for Ecrit@ietf.org; Wed, 12 Jul 2006 09:34:19 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 12 Jul 2006 06:34:16 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k6CDYGj2020036; Wed, 12 Jul 2006 06:34:16 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6CDYDZo015360; Wed, 12 Jul 2006 06:34:13 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 06:34:13 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 06:34:12 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" , "'Stark, Barbara'" , "'Andrew Newton'" , "'Rohan Mahy'" Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) Date: Wed, 12 Jul 2006 09:34:00 -0400 Message-ID: <005f01c6a5b7$d67926a0$9a12db84@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 thread-index: AcacS01AozzxQH4SRpCO5st6hhUFBQI/jIJwAAaF0/AAFPArAA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: X-OriginalArrivalTime: 12 Jul 2006 13:34:13.0145 (UTC) FILETIME=[DCF79890:01C6A5B7] DKIM-Signature: a=rsa-sha1; q=dns; l=7886; t=1152711256; x=1153575256; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20LLDP-MED=20and=20Phone=20BCP=20(Re=3A=20[Ecrit]=20New=20phonebcp draftwassubmitted); X=v=3Dcisco.com=3B=20h=3DaKtPKZ65SXrDhctyptgRxIBKPz8=3D; b=NBLV5MPG4Qe6UBpVBWdtx2X+UgXoDky7XfuXFUmbFQ1or9qtlwQmXizA0zpMsbaYXbTV4/sG pLElR4J+GGRDjCJFcfwD/MWq3ZZOWdSXTaG0IE5k7wl17j1E2lh9dHpG; Authentication-Results: sj-dkim-4.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( 63 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: df9edf1223802dd4cf213867a3af6121 Cc: "'Rosen, Brian'" , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0247369555==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0247369555== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0060_01C6A596.4F6786A0" This is a multi-part message in MIME format. ------=_NextPart_000_0060_01C6A596.4F6786A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit As stated in RFC3825, it is applicable to non-mobile environments. -Marc- _____ From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Tuesday, July 11, 2006 11:39 PM To: Stark, Barbara; Andrew Newton; Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) I would be very cautious about recommending the use of RFC-3825 encoding to report emergency locations given the issues raised at IETF-65 in Dallas that are yet to be adequately resolved. In NENA we put a caveat around its use to the effect that location provided in this manner must be regarded as a point only, and that encodings for resolution must be ignored. Cheers James ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162 ------=_NextPart_000_0060_01C6A596.4F6786A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As stated in RFC3825, it is applicable to = non-mobile=20 environments.
 
-Marc-

From: Winterbottom, James=20 [mailto:James.Winterbottom@andrew.com]
Sent: Tuesday, July = 11, 2006=20 11:39 PM
To: Stark, Barbara; Andrew Newton; Rohan = Mahy
Cc:=20 Rosen, Brian; Ecrit@ietf.org
Subject: RE: LLDP-MED and Phone = BCP=20 (Re: [Ecrit] New phonebcpdraftwassubmitted)

 

I would be = very=20 cautious about recommending the use of RFC-3825 encoding to report = emergency=20 locations given the issues raised at IETF-65 in Dallas that are yet to = be=20 adequately resolved. In NENA we put a caveat around its use to the = effect that=20 location provided in this manner must be regarded as a point only, and = that=20 encodings for resolution must be ignored.

 

Cheers

James

 

 

<= BR>----------------------------------------------------------------------= --------------------------
This=20 message is for the designated recipient only and may
contain = privileged,=20 proprietary, or otherwise private information.
If you have = received it in=20 error, please notify the sender
immediately and delete the = original. Any=20 unauthorized use of
this email is=20 = prohibited.
----------------------------------------------------------= --------------------------------------
[mf2]=20

*****

The information = transmitted is=20 intended only for the person or entity to which it is addressed and = may=20 contain confidential, proprietary, and/or privileged material. Any = review,=20 retransmission, dissemination or other use of, or taking of any action = in=20 reliance upon this information by persons or entities other than the = intended=20 recipient is prohibited. If you received this in error, please contact = the=20 sender and delete the material from all computers.=20 162

 ------=_NextPart_000_0060_01C6A596.4F6786A0-- --===============0247369555== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0247369555==-- From ecrit-bounces@ietf.org Wed Jul 12 09:50:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0f71-00029F-LT; Wed, 12 Jul 2006 09:50:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0f6z-000298-Hx for Ecrit@ietf.org; Wed, 12 Jul 2006 09:50:45 -0400 Received: from bellwecs4.bellnexxia.net ([207.236.237.116] helo=bellwecs4.srvr.bell.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0f6w-0005n2-I9 for Ecrit@ietf.org; Wed, 12 Jul 2006 09:50:45 -0400 Received: (qmail 27593 invoked from network); 12 Jul 2006 13:50:41 -0000 Received: from g.caron@bell.ca by bellwecs4.srvr.bell.ca with EntrustECS-Server-7.4; 12 Jul 2006 13:50:41 -0000 Received: from bellwfep7.bellnexxia.net (HELO bellwfep7-srv.bellnexxia.net) (207.236.237.99) by bellwecs4.srvr.bell.ca with SMTP; 12 Jul 2006 13:50:41 -0000 Received: from TOROONDC918.bell.corp.bce.ca ([142.182.89.79]) by bellwfep7-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20060712135041.DICO9968.bellwfep7-srv.bellnexxia.net@TOROONDC918.bell.corp.bce.ca>; Wed, 12 Jul 2006 09:50:41 -0400 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by TOROONDC918.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 09:50:39 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) Date: Wed, 12 Jul 2006 09:50:39 -0400 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF3081AC7B7@toroondc912> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) Thread-Index: Acalq55JoAEvc/K+SqG8j4hdobdddQAB+KfwAAF0jpA= From: To: , X-OriginalArrivalTime: 12 Jul 2006 13:50:39.0750 (UTC) FILETIME=[29079260:01C6A5BA] X-Spam-Score: 0.9 (/) X-Scan-Signature: 47dfdcb76bc7cdf600c30037ff1750ed Cc: Barbara.Stark@bellsouth.com, Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1970416510==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1970416510== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A5BA.288E9855" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A5BA.288E9855 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, =20 Can you be more precise on the foreseen "applicability limits" of the = yet to be L7 protocol? =20 =20 =20 =20 Guy Caron Bell Canada ________________________________ De : Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Envoy=E9 : 12 juillet 2006 09:21 =C0 : peter_blatherwick@mitel.com Cc : Barbara.Stark@bellsouth.com; Ecrit@ietf.org Objet : RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted) =20 This thinking results in cases where assumptions made by one end don't = match assumptions made by the other. =20 Let's take LLDP as the example. Barbara would say that if the phone = implements LLDP, then it should implement LLDP-MED. Okay, so suppose I = have a residential phone which does not implement LLDP, so it doesn't = implement LLDP-MED. So far, so good. Now, let's look at an enterprise = network. It may implement LLDP, and thus LLDP-MED. Okay, the = enterprise phone on the enterprise network works. What happens when the = residential phone connects to the enterprise network? No location. = Let's keep going. Suppose the residential phone implements DHCP, and = thus implemented the DHCP location options. Unless the network ALSO = implements DHCP location, it doesn't work. But if the enterprise = implements the DHCP mechanism, then the LLDP mechanism is superfluous.=20 =20 Now take the enterprise phone and plug it into a home network, on an = access network that does not meet the applicability statement of the L7 = mechanism. That network deploys DHCP location. The enterprise phone = can't get location unless it also implements DHCP. Now take that same = phone and plug it into a network that doesn't deploy DHCP but does meet = the applicability statement for the L7 protocol. The enterprise phone = ALSO has to implement the L7 protocol. =20 The "implement the location mechanism corresponding to the configuration = mechanism" simply does not work. You need a list, where one end = implements ALL and the other end implements "at least one of" to get = interoperability. There is no other way. =20 It is not the case that the L7 mechanism can be the single fall-back = mechanism. It will have an applicability limit, and not all networks = will meet it. This is effectively true of DHCP. It would be true of = LLDP if it was on the list. It is the reason why, in this case, it is = the CLIENT that must implement ALL and the server implement one of. = Usually, we have the server taking the "all" role and the client taking = the "at least one of" role. =20 Brian =20 ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Wednesday, July 12, 2006 8:05 AM To: Rosen, Brian Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; = rohan.mahy@gmail.com Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) =20 Brian,=20 Counter-point to below is that if the device and network do not support = mutually agreeable configuration method, then the device is a brick = anyway. L7 becomes a fall-back for the cases where the direct = configuration method does not support passing location through (best = example seems to be home router on DSL or cable modem). =20 An important case, not sure well heard yesterday during meeting, was = that in an IPv6 environment with address autoconfig there may be no DHCP = at all. This may or may not be a small case as IPv6 rolls out, remains = to be seen. And while IPv6 is not really important now in N.A. it is = very rapidly becoming important in Asia/Pac and also Australia (I'm = told). Cannot ignore it. =20 -- Peter=20 =20 "Rosen, Brian" =20 11.07.06 20:56=20 =20 To: , , = =20 cc: Ecrit@ietf.org=20 Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New = phonebcp draft wassubmitted) But unless every phone supports LLDP-MED, then an enterprise must also = implement DHCP (or L7) in order to support those phones that don't = support LLDP. If every access network has to support those 2, then LLDP = is superfelous. A residential phone may be plugged into an enterprise network. Ditto an = enterprise phone. Location acquisition has to work always. If there is = a list, and one end must support all, with the other end must support at = least one, it always works.=20 I don't see how you can get around that -------------------------- Brian Rosen NeuStar (724) 382-1051 brian.rosen@neustar.biz -----Original Message----- From: Stark, Barbara To: Andrew Newton; Rohan Mahy CC: Rosen, Brian; Ecrit@ietf.org Sent: Tue Jul 11 20:43:26 2006 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the = network operator does not control the specification of every device = connected to the network.": If the device has a DHCP client, the client MUST support RFC 3825 and = . and If the device supports LLDP-MED, it MUST support the "Location = Identification TLV" as defined in . Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED = spec), the 2nd if statement really doesn't say much. But it would also = suggest that devices that could have soft clients on them (PCs, PDAs) = also need to do that TLV when they do LLDP-MED. All router-type devices = that implement LLDP-MED are also required to support this TLV, per the = spec. Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also = reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP = INFORM message with options as described in RFC 3825 and , = when it is configured to use one of these alternate bootstrap methods = (e.g., PPPoE, PPPoA, static IP address). Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. = If a vendor can't justify putting one or the other of these into a = device (outside of recommendations in this BCP), then I say the protocol = doesn't belong in the device. If the device is going to have one or the = other, or both, then it needs to support the location determination = mechanism that goes with it. Since, for LLDP-MED, that's already a = requirement of the LLDP-MED spec, I really don't see a problem with = stating it here. Barbara -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us ] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp = draft wassubmitted) =20 =20 On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: To be clear, I do not have a strong feeling about what = does on Brian's list or not. I think LLDP-MED is a completely = reasonable thing for a wired phone vendor to implement on enterprise = class phones. Just throwing in my $0.0199997, I have not formed a strong = opinion about this either. It does seem reasonable for enterprise class = devices with ethernet jacks to implement LLPD-MED, or for devices of = category Y to implement method X... as what must be implemented by the = device will always be dictated by the network media it uses. Where this gets a little tricky is that if there is no one common = method, then devices may end up implementing things that are not = appropriate in an attempt to have devices that work in multiple network = environments... and even then they may end up missing the mark. = Therefore, one method that does work in all environments must be = implemented. And that is likely to be the L7-LCP. -andy ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 162 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C6A5BA.288E9855 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Brian,

 

Can you be more precise on the = foreseen “applicability limits” of the yet to be L7 protocol?

 

 

 

 

Guy Caron

Bell Canada

De : Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
Envoy=E9 : 12 = juillet 2006 09:21
=C0 : peter_blatherwick@mitel.com
Cc : Barbara.Stark@bellsouth.com; Ecrit@ietf.org
Objet : RE: LLDP-MED = and Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted)

 

This thinking results in cases = where assumptions made by one end don’t match assumptions made by the = other.

 

Let’s take LLDP as the example.  Barbara would say that if the phone implements LLDP, then = it should implement LLDP-MED.  Okay, so suppose I have a residential = phone which does not implement LLDP, so it doesn’t implement = LLDP-MED.  So far, so good.  Now, let’s look at an enterprise = network.  It may implement LLDP, and thus LLDP-MED.  Okay, the enterprise phone = on the enterprise network works.  What happens when the residential phone connects to the enterprise network?  No location.  Let’s = keep going.  Suppose the residential phone implements DHCP, and thus implemented the DHCP location options.  Unless the network ALSO = implements DHCP location, it doesn’t work.  But if the enterprise = implements the DHCP mechanism, then the LLDP mechanism is superfluous. =

 

Now take the enterprise phone and = plug it into a home network, on an access network that does not meet the = applicability statement of the L7 mechanism.  That network deploys DHCP = location.  The enterprise phone can’t get location unless it also implements DHCP.  Now take that same phone and plug it into a network that doesn’t deploy DHCP but does meet the applicability statement for = the L7 protocol.  The enterprise phone ALSO has to implement the L7 = protocol.

 

The “implement the location mechanism corresponding to the configuration mechanism” simply = does not work.  You need a list, where one end implements ALL and the other = end implements “at least one of” to get interoperability.  There is no = other way.

 

It is not the case that the L7 = mechanism can be the single fall-back mechanism.  It will have an = applicability limit, and not all networks will meet it.  This is effectively true = of DHCP.  It would be true of LLDP if it was on the list.  It is = the reason why, in this case, it is the CLIENT that must implement ALL and = the server implement one of.  Usually, we have the server taking the “all” role and the client taking the “at least one = of” role.

 

Brian

 

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Wednesday, July 12, = 2006 8:05 AM
To: Rosen, Brian
Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; rohan.mahy@gmail.com
Subject: Re: LLDP-MED and = Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted)

 


Brian,
Counter-point to below is that if the device and network do not support mutually = agreeable configuration method, then the device is a brick anyway.  L7 = becomes a fall-back for the cases where the direct configuration method does not = support passing location through (best example seems to be home router on DSL or = cable modem).  
An important case, not sure well heard yesterday during meeting, was that = in an IPv6 environment with address autoconfig there may be no DHCP at all.  This may or may not be a small case as IPv6 rolls out, remains to = be seen.  And while IPv6 is not really important now in N.A. it is = very rapidly becoming important in Asia/Pac and also Australia (I'm told). =  Cannot ignore it.  
-- Peter

 

"Rosen, Brian" = <Brian.Rosen@neustar.biz>

11.07.06 20:56

       
        To:        <Barbara.Stark@bellsouth.com>, <andy@hxr.us>, <rohan.mahy@gmail.com>
        cc:       =  Ecrit@ietf.org
        Subject:        Re: LLDP-MED = and Phone BCP (Re: [Ecrit] New phonebcp draft        wassubmitted)




But unless = every phone supports LLDP-MED, then an enterprise must also implement DHCP (or = L7) in order to support those phones that don't support LLDP.  If every = access network has to support those 2, then LLDP is superfelous.

A residential phone may be plugged into an enterprise network. =  Ditto an enterprise phone.  Location acquisition has to work always. =  If there is a list, and one end must support all, with the other end must support = at least one, it always works.

I don't see how you can get around that
--------------------------
Brian Rosen
NeuStar
(724) 382-1051
brian.rosen@neustar.biz


-----Original Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan Mahy
CC: Rosen, Brian; = Ecrit@ietf.org
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where = the network operator does not control the specification of every device = connected to the network.":

If the device has a DHCP client, the client MUST support RFC 3825 and <dhcp-civil>.
  and
If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in <LLDP-MED reference>.

Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the = 2nd if statement really doesn't say much. But it would also suggest that = devices that could have soft clients on them (PCs, PDAs) also need to do that TLV = when they do LLDP-MED. All router-type devices that implement LLDP-MED are also = required to support this TLV, per the spec.

Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also reasonable. = However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP INFORM = message with options as described in RFC 3825 and <dhcp-civil>, when it is = configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, = static IP address).

Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. If a = vendor can't justify putting one or the other of these into a device (outside = of recommendations in this BCP), then I say the protocol doesn't belong in = the device. If the device is going to have one or the other, or both, then = it needs to support the location determination mechanism that goes with it. = Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really = don't see a problem with stating it here.
Barbara


       -----Original Message-----
       From: Andrew Newton [mailto:andy@hxr.us]
       Sent: Friday, June 30, 2006 9:44 AM
       To: Rohan Mahy
       Cc: Rosen, = Brian; Ecrit@ietf.org
       Subject: Re: LLDP-MED and Phone BCP (Re: = [Ecrit] New phonebcp draft wassubmitted)
     
     

       On Jun 29, 2006, at 6:29 PM, Rohan Mahy = wrote:


               To be clear, I do = not have a strong feeling about what does on Brian's list or not.  I = think LLDP-MED is a completely reasonable thing for a wired phone vendor to = implement on enterprise class phones.


       Just throwing in my $0.0199997, I have not = formed a strong opinion about this either.  It does seem reasonable for = enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices = of category Y to implement method X... as what must be implemented by the = device will always be dictated by the network media it uses.

       Where this gets a little tricky is that if = there is no one common method, then devices may end up implementing things that = are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark.  Therefore, one method that does work in all environments must be implemented.   And that is likely to be the L7-LCP.

       -andy

*****

The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or entities = other than the intended recipient is prohibited. If you received this in = error, please contact the sender and delete the material from all computers. 162
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

=
------_=_NextPart_001_01C6A5BA.288E9855-- --===============1970416510== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1970416510==-- From ecrit-bounces@ietf.org Wed Jul 12 09:55:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fBa-0002S4-5Q; Wed, 12 Jul 2006 09:55:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fBY-0002Rz-57 for Ecrit@ietf.org; Wed, 12 Jul 2006 09:55:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0fBY-00060s-0K for Ecrit@ietf.org; Wed, 12 Jul 2006 09:55:28 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0fBT-00051t-Mx for Ecrit@ietf.org; Wed, 12 Jul 2006 09:55:27 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns3.neustar.com (Postfix) with ESMTP id 6B2CA175A2; Wed, 12 Jul 2006 13:54:53 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 09:54:52 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) Date: Wed, 12 Jul 2006 09:54:47 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) Thread-Index: Acalq55JoAEvc/K+SqG8j4hdobdddQAB+KfwAAF0jpAAADw44A== From: "Rosen, Brian" To: , X-OriginalArrivalTime: 12 Jul 2006 13:54:52.0878 (UTC) FILETIME=[BFE7D6E0:01C6A5BA] X-Spam-Score: -3.5 (---) X-Scan-Signature: 0dcdaa57c570c86b2e4beb0ed476393e Cc: Barbara.Stark@bellsouth.com, Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2008904565==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============2008904565== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A5BA.BFB2D90D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A5BA.BFB2D90D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable No, but I've proposed that the design team craft an applicability = statement for an abstract L7 location acquisition protocol that uses the = IP address as the identifier, together with the security implications of = it, and ask the AD's (including the security AD's) if that would be = acceptable. That idea seemed to find favor as a way to figure out if = the basic idea of using IP address as the identifier will be acceptable, = regardless of the protocol details. I think we will do that work within = the next several weeks. =20 Brian =20 ________________________________ From: g.caron@bell.ca [mailto:g.caron@bell.ca]=20 Sent: Wednesday, July 12, 2006 9:51 AM To: Rosen, Brian; peter_blatherwick@mitel.com Cc: Barbara.Stark@bellsouth.com; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted) =20 Brian, =20 Can you be more precise on the foreseen "applicability limits" of the = yet to be L7 protocol? =20 =20 =20 =20 Guy Caron Bell Canada ________________________________ De : Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Envoy=E9 : 12 juillet 2006 09:21 =C0 : peter_blatherwick@mitel.com Cc : Barbara.Stark@bellsouth.com; Ecrit@ietf.org Objet : RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted) =20 This thinking results in cases where assumptions made by one end don't = match assumptions made by the other. =20 Let's take LLDP as the example. Barbara would say that if the phone = implements LLDP, then it should implement LLDP-MED. Okay, so suppose I = have a residential phone which does not implement LLDP, so it doesn't = implement LLDP-MED. So far, so good. Now, let's look at an enterprise = network. It may implement LLDP, and thus LLDP-MED. Okay, the = enterprise phone on the enterprise network works. What happens when the = residential phone connects to the enterprise network? No location. = Let's keep going. Suppose the residential phone implements DHCP, and = thus implemented the DHCP location options. Unless the network ALSO = implements DHCP location, it doesn't work. But if the enterprise = implements the DHCP mechanism, then the LLDP mechanism is superfluous.=20 =20 Now take the enterprise phone and plug it into a home network, on an = access network that does not meet the applicability statement of the L7 = mechanism. That network deploys DHCP location. The enterprise phone = can't get location unless it also implements DHCP. Now take that same = phone and plug it into a network that doesn't deploy DHCP but does meet = the applicability statement for the L7 protocol. The enterprise phone = ALSO has to implement the L7 protocol. =20 The "implement the location mechanism corresponding to the configuration = mechanism" simply does not work. You need a list, where one end = implements ALL and the other end implements "at least one of" to get = interoperability. There is no other way. =20 It is not the case that the L7 mechanism can be the single fall-back = mechanism. It will have an applicability limit, and not all networks = will meet it. This is effectively true of DHCP. It would be true of = LLDP if it was on the list. It is the reason why, in this case, it is = the CLIENT that must implement ALL and the server implement one of. = Usually, we have the server taking the "all" role and the client taking = the "at least one of" role. =20 Brian =20 ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Wednesday, July 12, 2006 8:05 AM To: Rosen, Brian Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; = rohan.mahy@gmail.com Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) =20 Brian,=20 Counter-point to below is that if the device and network do not support = mutually agreeable configuration method, then the device is a brick = anyway. L7 becomes a fall-back for the cases where the direct = configuration method does not support passing location through (best = example seems to be home router on DSL or cable modem). =20 An important case, not sure well heard yesterday during meeting, was = that in an IPv6 environment with address autoconfig there may be no DHCP = at all. This may or may not be a small case as IPv6 rolls out, remains = to be seen. And while IPv6 is not really important now in N.A. it is = very rapidly becoming important in Asia/Pac and also Australia (I'm = told). Cannot ignore it. =20 -- Peter=20 =20 "Rosen, Brian" =20 11.07.06 20:56=20 =20 To: , , = =20 cc: Ecrit@ietf.org=20 Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New = phonebcp draft wassubmitted) But unless every phone supports LLDP-MED, then an enterprise must also = implement DHCP (or L7) in order to support those phones that don't = support LLDP. If every access network has to support those 2, then LLDP = is superfelous. A residential phone may be plugged into an enterprise network. Ditto an = enterprise phone. Location acquisition has to work always. If there is = a list, and one end must support all, with the other end must support at = least one, it always works.=20 I don't see how you can get around that -------------------------- Brian Rosen NeuStar (724) 382-1051 brian.rosen@neustar.biz -----Original Message----- From: Stark, Barbara To: Andrew Newton; Rohan Mahy CC: Rosen, Brian; Ecrit@ietf.org Sent: Tue Jul 11 20:43:26 2006 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the = network operator does not control the specification of every device = connected to the network.": If the device has a DHCP client, the client MUST support RFC 3825 and = . and If the device supports LLDP-MED, it MUST support the "Location = Identification TLV" as defined in . Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED = spec), the 2nd if statement really doesn't say much. But it would also = suggest that devices that could have soft clients on them (PCs, PDAs) = also need to do that TLV when they do LLDP-MED. All router-type devices = that implement LLDP-MED are also required to support this TLV, per the = spec. Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also = reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP = INFORM message with options as described in RFC 3825 and , = when it is configured to use one of these alternate bootstrap methods = (e.g., PPPoE, PPPoA, static IP address). Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. = If a vendor can't justify putting one or the other of these into a = device (outside of recommendations in this BCP), then I say the protocol = doesn't belong in the device. If the device is going to have one or the = other, or both, then it needs to support the location determination = mechanism that goes with it. Since, for LLDP-MED, that's already a = requirement of the LLDP-MED spec, I really don't see a problem with = stating it here. Barbara -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us ] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp = draft wassubmitted) =20 =20 On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: To be clear, I do not have a strong feeling about what = does on Brian's list or not. I think LLDP-MED is a completely = reasonable thing for a wired phone vendor to implement on enterprise = class phones. Just throwing in my $0.0199997, I have not formed a strong = opinion about this either. It does seem reasonable for enterprise class = devices with ethernet jacks to implement LLPD-MED, or for devices of = category Y to implement method X... as what must be implemented by the = device will always be dictated by the network media it uses. Where this gets a little tricky is that if there is no one common = method, then devices may end up implementing things that are not = appropriate in an attempt to have devices that work in multiple network = environments... and even then they may end up missing the mark. = Therefore, one method that does work in all environments must be = implemented. And that is likely to be the L7-LCP. -andy ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 162 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C6A5BA.BFB2D90D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

No, but I’ve proposed that = the design team craft an applicability statement for an abstract L7 location acquisition protocol that uses the IP address as the identifier, = together with the security implications of it, and ask the AD’s (including the = security AD’s) if that would be acceptable.=A0 That idea seemed to find = favor as a way to figure out if the basic idea of using IP address as the = identifier will be acceptable, regardless of the protocol details.=A0 I think we will do = that work within the next several weeks.

 

Brian

 

From: = g.caron@bell.ca [mailto:g.caron@bell.ca]
Sent: Wednesday, July 12, = 2006 9:51 AM
To: Rosen, Brian; peter_blatherwick@mitel.com
Cc: = Barbara.Stark@bellsouth.com; Ecrit@ietf.org
Subject: RE: LLDP-MED and = Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted)

 

Brian,

 

Can you be more precise on the = foreseen “applicability limits” of the yet to be L7 = protocol?

 

 

 

 

Guy Caron

Bell Canada

De : Rosen, Brian = [mailto:Brian.Rosen@neustar.biz]
Envoy=E9 : 12 = juillet 2006 09:21
=C0 : peter_blatherwick@mitel.com
Cc : Barbara.Stark@bellsouth.com; Ecrit@ietf.org
Objet : RE: LLDP-MED = and Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted)

 

This thinking results in cases = where assumptions made by one end don’t match assumptions made by the = other.

 

Let’s take LLDP as the example.  Barbara would say that if the phone implements LLDP, then = it should implement LLDP-MED.  Okay, so suppose I have a residential = phone which does not implement LLDP, so it doesn’t implement = LLDP-MED.  So far, so good.  Now, let’s look at an enterprise = network.  It may implement LLDP, and thus LLDP-MED.  Okay, the enterprise phone = on the enterprise network works.  What happens when the residential phone connects to the enterprise network?  No location.  Let’s = keep going.  Suppose the residential phone implements DHCP, and thus implemented the DHCP location options.  Unless the network ALSO = implements DHCP location, it doesn’t work.  But if the enterprise = implements the DHCP mechanism, then the LLDP mechanism is superfluous. =

 

Now take the enterprise phone and = plug it into a home network, on an access network that does not meet the = applicability statement of the L7 mechanism.  That network deploys DHCP = location.  The enterprise phone can’t get location unless it also implements DHCP.  Now take that same phone and plug it into a network that doesn’t deploy DHCP but does meet the applicability statement for = the L7 protocol.  The enterprise phone ALSO has to implement the L7 = protocol.

 

The “implement the location mechanism corresponding to the configuration mechanism” simply = does not work.  You need a list, where one end implements ALL and the other = end implements “at least one of” to get interoperability.  = There is no other way.

 

It is not the case that the L7 = mechanism can be the single fall-back mechanism.  It will have an = applicability limit, and not all networks will meet it.  This is effectively true = of DHCP.  It would be true of LLDP if it was on the list.  It is = the reason why, in this case, it is the CLIENT that must implement ALL and = the server implement one of.  Usually, we have the server taking the “all” role and the client taking the “at least one = of” role.

 

Brian

 

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Wednesday, July 12, = 2006 8:05 AM
To: Rosen, Brian
Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; rohan.mahy@gmail.com
Subject: Re: LLDP-MED and = Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted)

 


Brian,
Counter-point to below is that if the device and network do not support mutually = agreeable configuration method, then the device is a brick anyway.  L7 = becomes a fall-back for the cases where the direct configuration method does not = support passing location through (best example seems to be home router on DSL or = cable modem).  
An important case, not sure well heard yesterday during meeting, was that = in an IPv6 environment with address autoconfig there may be no DHCP at all.  This may or may not be a small case as IPv6 rolls out, remains to = be seen.  And while IPv6 is not really important now in N.A. it is = very rapidly becoming important in Asia/Pac and also Australia (I'm told). =  Cannot ignore it.  
-- Peter

 

"Rosen, Brian" = <Brian.Rosen@neustar.biz>

11.07.06 20:56

       
        To:        <Barbara.Stark@bellsouth.com>, <andy@hxr.us>, <rohan.mahy@gmail.com>
        cc:       =  Ecrit@ietf.org
        Subject:        Re: LLDP-MED = and Phone BCP (Re: [Ecrit] New phonebcp draft       =  wassubmitted)




But unless = every phone supports LLDP-MED, then an enterprise must also implement DHCP (or = L7) in order to support those phones that don't support LLDP.  If every = access network has to support those 2, then LLDP is superfelous.

A residential phone may be plugged into an enterprise network. =  Ditto an enterprise phone.  Location acquisition has to work always. =  If there is a list, and one end must support all, with the other end must support = at least one, it always works.

I don't see how you can get around that
--------------------------
Brian Rosen
NeuStar
(724) 382-1051
brian.rosen@neustar.biz


-----Original Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan Mahy
CC: Rosen, Brian; = Ecrit@ietf.org
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where = the network operator does not control the specification of every device = connected to the network.":

If the device has a DHCP client, the client MUST support RFC 3825 and <dhcp-civil>.
  and
If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in <LLDP-MED reference>.

Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the = 2nd if statement really doesn't say much. But it would also suggest that = devices that could have soft clients on them (PCs, PDAs) also need to do that TLV = when they do LLDP-MED. All router-type devices that implement LLDP-MED are also = required to support this TLV, per the spec.

Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also reasonable. = However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP INFORM = message with options as described in RFC 3825 and <dhcp-civil>, when it is = configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, = static IP address).

Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. If a = vendor can't justify putting one or the other of these into a device (outside = of recommendations in this BCP), then I say the protocol doesn't belong in = the device. If the device is going to have one or the other, or both, then it needs = to support the location determination mechanism that goes with it. Since, = for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really = don't see a problem with stating it here.
Barbara


       -----Original Message-----
       From: Andrew Newton [mailto:andy@hxr.us]
       Sent: Friday, June 30, 2006 9:44 AM
       To: Rohan Mahy
       Cc: Rosen, = Brian; Ecrit@ietf.org
       Subject: Re: LLDP-MED and Phone BCP (Re: = [Ecrit] New phonebcp draft wassubmitted)
     
     

       On Jun 29, 2006, at 6:29 PM, Rohan Mahy = wrote:


               To be clear, I do = not have a strong feeling about what does on Brian's list or not.  I = think LLDP-MED is a completely reasonable thing for a wired phone vendor to = implement on enterprise class phones.


       Just throwing in my $0.0199997, I have not = formed a strong opinion about this either.  It does seem reasonable for = enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices = of category Y to implement method X... as what must be implemented by the = device will always be dictated by the network media it uses.

       Where this gets a little tricky is that if = there is no one common method, then devices may end up implementing things that = are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark.  Therefore, one method that does work in all environments must be implemented.   And that is likely to be the L7-LCP.

       -andy

*****

The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or entities = other than the intended recipient is prohibited. If you received this in = error, please contact the sender and delete the material from all computers. = 162
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

=
------_=_NextPart_001_01C6A5BA.BFB2D90D-- --===============2008904565== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============2008904565==-- From ecrit-bounces@ietf.org Wed Jul 12 09:59:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fFE-0002lo-4G; Wed, 12 Jul 2006 09:59:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fFC-0002lj-M4 for Ecrit@ietf.org; Wed, 12 Jul 2006 09:59:14 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0fFB-0006Hv-ND for Ecrit@ietf.org; Wed, 12 Jul 2006 09:59:14 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6CDrrxg032425 for ; Wed, 12 Jul 2006 09:53:54 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) Date: Wed, 12 Jul 2006 16:59:09 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) Thread-Index: Acalq55JoAEvc/K+SqG8j4hdobdddQAB+KfwAAF0jpAAADw44AAAPCFg From: "Romascanu, Dan \(Dan\)" To: "Rosen, Brian" , , X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.8 (/) X-Scan-Signature: c5360d8dc5896b7620777c236feb980a Cc: Barbara.Stark@bellsouth.com, David Kessens , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0480268161==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0480268161== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A5BB.58FC7894" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A5BB.58FC7894 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian, =20 Can you please also include the OPS ADs in these queries in the future?=20 =20 Thanks,=20 =20 Dan =20 =20 =20 =20 _____ =20 From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Wednesday, July 12, 2006 4:55 PM To: g.caron@bell.ca; peter_blatherwick@mitel.com Cc: Barbara.Stark@bellsouth.com; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New = phonebcpdraftwassubmitted) =09 =09 No, but I've proposed that the design team craft an applicability = statement for an abstract L7 location acquisition protocol that uses the = IP address as the identifier, together with the security implications of = it, and ask the AD's (including the security AD's) if that would be = acceptable. That idea seemed to find favor as a way to figure out if = the basic idea of using IP address as the identifier will be acceptable, = regardless of the protocol details. I think we will do that work within = the next several weeks. =20 Brian =20 =09 _____ =20 From: g.caron@bell.ca [mailto:g.caron@bell.ca]=20 Sent: Wednesday, July 12, 2006 9:51 AM To: Rosen, Brian; peter_blatherwick@mitel.com Cc: Barbara.Stark@bellsouth.com; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted) =20 Brian, =20 Can you be more precise on the foreseen "applicability limits" of the = yet to be L7 protocol? =20 =20 =20 =20 Guy Caron Bell Canada =09 _____ =20 De : Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Envoy=E9 : 12 juillet 2006 09:21 =C0 : peter_blatherwick@mitel.com Cc : Barbara.Stark@bellsouth.com; Ecrit@ietf.org Objet : RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted) =20 This thinking results in cases where assumptions made by one end don't = match assumptions made by the other. =20 Let's take LLDP as the example. Barbara would say that if the phone = implements LLDP, then it should implement LLDP-MED. Okay, so suppose I = have a residential phone which does not implement LLDP, so it doesn't = implement LLDP-MED. So far, so good. Now, let's look at an enterprise = network. It may implement LLDP, and thus LLDP-MED. Okay, the = enterprise phone on the enterprise network works. What happens when the = residential phone connects to the enterprise network? No location. = Let's keep going. Suppose the residential phone implements DHCP, and = thus implemented the DHCP location options. Unless the network ALSO = implements DHCP location, it doesn't work. But if the enterprise = implements the DHCP mechanism, then the LLDP mechanism is superfluous.=20 =20 Now take the enterprise phone and plug it into a home network, on an = access network that does not meet the applicability statement of the L7 = mechanism. That network deploys DHCP location. The enterprise phone = can't get location unless it also implements DHCP. Now take that same = phone and plug it into a network that doesn't deploy DHCP but does meet = the applicability statement for the L7 protocol. The enterprise phone = ALSO has to implement the L7 protocol. =20 The "implement the location mechanism corresponding to the = configuration mechanism" simply does not work. You need a list, where = one end implements ALL and the other end implements "at least one of" to = get interoperability. There is no other way. =20 It is not the case that the L7 mechanism can be the single fall-back = mechanism. It will have an applicability limit, and not all networks = will meet it. This is effectively true of DHCP. It would be true of = LLDP if it was on the list. It is the reason why, in this case, it is = the CLIENT that must implement ALL and the server implement one of. = Usually, we have the server taking the "all" role and the client taking = the "at least one of" role. =20 Brian =20 =09 _____ =20 From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Wednesday, July 12, 2006 8:05 AM To: Rosen, Brian Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; = rohan.mahy@gmail.com Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) =20 =09 Brian,=20 Counter-point to below is that if the device and network do not support = mutually agreeable configuration method, then the device is a brick = anyway. L7 becomes a fall-back for the cases where the direct = configuration method does not support passing location through (best = example seems to be home router on DSL or cable modem). =20 An important case, not sure well heard yesterday during meeting, was = that in an IPv6 environment with address autoconfig there may be no DHCP = at all. This may or may not be a small case as IPv6 rolls out, remains = to be seen. And while IPv6 is not really important now in N.A. it is = very rapidly becoming important in Asia/Pac and also Australia (I'm = told). Cannot ignore it. =20 -- Peter=20 =20 "Rosen, Brian" =20 11.07.06 20:56=20 =20 To: , , = =20 cc: Ecrit@ietf.org=20 Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New = phonebcp draft wassubmitted) =09 =09 =09 But unless every phone supports LLDP-MED, then an enterprise must also = implement DHCP (or L7) in order to support those phones that don't = support LLDP. If every access network has to support those 2, then LLDP = is superfelous. =09 A residential phone may be plugged into an enterprise network. Ditto = an enterprise phone. Location acquisition has to work always. If there = is a list, and one end must support all, with the other end must support = at least one, it always works.=20 =09 I don't see how you can get around that -------------------------- Brian Rosen NeuStar (724) 382-1051 brian.rosen@neustar.biz =09 =09 -----Original Message----- From: Stark, Barbara To: Andrew Newton; Rohan Mahy CC: Rosen, Brian; Ecrit@ietf.org Sent: Tue Jul 11 20:43:26 2006 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) =09 What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the = network operator does not control the specification of every device = connected to the network.": =09 If the device has a DHCP client, the client MUST support RFC 3825 and = . and If the device supports LLDP-MED, it MUST support the "Location = Identification TLV" as defined in . =09 Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED = spec), the 2nd if statement really doesn't say much. But it would also = suggest that devices that could have soft clients on them (PCs, PDAs) = also need to do that TLV when they do LLDP-MED. All router-type devices = that implement LLDP-MED are also required to support this TLV, per the = spec. =09 Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also = reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP = INFORM message with options as described in RFC 3825 and , = when it is configured to use one of these alternate bootstrap methods = (e.g., PPPoE, PPPoA, static IP address). =09 Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. = If a vendor can't justify putting one or the other of these into a = device (outside of recommendations in this BCP), then I say the protocol = doesn't belong in the device. If the device is going to have one or the = other, or both, then it needs to support the location determination = mechanism that goes with it. Since, for LLDP-MED, that's already a = requirement of the LLDP-MED spec, I really don't see a problem with = stating it here. Barbara =09 =09 -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us ] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp = draft wassubmitted) =20 =20 =09 On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: =09 =09 To be clear, I do not have a strong feeling about what = does on Brian's list or not. I think LLDP-MED is a completely = reasonable thing for a wired phone vendor to implement on enterprise = class phones. =09 =09 Just throwing in my $0.0199997, I have not formed a strong = opinion about this either. It does seem reasonable for enterprise class = devices with ethernet jacks to implement LLPD-MED, or for devices of = category Y to implement method X... as what must be implemented by the = device will always be dictated by the network media it uses. =09 Where this gets a little tricky is that if there is no one = common method, then devices may end up implementing things that are not = appropriate in an attempt to have devices that work in multiple network = environments... and even then they may end up missing the mark. = Therefore, one method that does work in all environments must be = implemented. And that is likely to be the L7-LCP. =09 -andy =09 ***** =09 The information transmitted is intended only for the person or entity = to which it is addressed and may contain confidential, proprietary, = and/or privileged material. Any review, retransmission, dissemination or = other use of, or taking of any action in reliance upon this information = by persons or entities other than the intended recipient is prohibited. = If you received this in error, please contact the sender and delete the = material from all computers. 162 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C6A5BB.58FC7894 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Brian,
 
Can you please also include the OPS ADs in these = queries in=20 the future?
 
Thanks,
 
Dan
 
 
 
 

From: Rosen, Brian=20 [mailto:Brian.Rosen@neustar.biz]
Sent: Wednesday, July 12, = 2006=20 4:55 PM
To: g.caron@bell.ca;=20 peter_blatherwick@mitel.com
Cc: Barbara.Stark@bellsouth.com; = Ecrit@ietf.org
Subject: RE: LLDP-MED and Phone BCP (Re: = [Ecrit] New=20 phonebcpdraftwassubmitted)

No, but = I=92ve proposed=20 that the design team craft an applicability statement for an abstract = L7=20 location acquisition protocol that uses the IP address as the = identifier,=20 together with the security implications of it, and ask the AD=92s = (including the=20 security AD=92s) if that would be acceptable.  That idea seemed = to find=20 favor as a way to figure out if the basic idea of using IP address as = the=20 identifier will be acceptable, regardless of the protocol = details.  I=20 think we will do that work within the next several=20 weeks.

 

Brian

 

From:=20 g.caron@bell.ca [mailto:g.caron@bell.ca]
Sent: Wednesday, July 12, 2006 = 9:51=20 AM
To: = Rosen, Brian;=20 peter_blatherwick@mitel.com
Cc: = Barbara.Stark@bellsouth.com;=20 Ecrit@ietf.org
Subject: RE:=20 LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft=20 wassubmitted)

 

Brian,

 

Can you be = more=20 precise on the foreseen =93applicability limits=94 of the yet to be L7 = protocol?

 

 

 

 

Guy=20 Caron

Bell Canada

De :=20 Rosen, Brian=20 [mailto:Brian.Rosen@neustar.biz]
Envoy=E9 : 12 juillet 2006 = 09:21
=C0 :=20 peter_blatherwick@mitel.com
Cc : = Barbara.Stark@bellsouth.com;=20 Ecrit@ietf.org
Objet :=20 RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft=20 wassubmitted)

 

This = thinking results=20 in cases where assumptions made by one end don=92t match assumptions = made by the=20 other.

 

Let=92s = take LLDP as=20 the example.  Barbara would say that if the phone implements = LLDP, then=20 it should implement LLDP-MED.  Okay, so suppose I have a = residential=20 phone which does not implement LLDP, so it doesn=92t implement = LLDP-MED. =20 So far, so good.  Now, let=92s look at an enterprise = network.  It may=20 implement LLDP, and thus LLDP-MED.  Okay, the enterprise phone on = the=20 enterprise network works.  What happens when the residential = phone=20 connects to the enterprise network?  No location.  Let=92s = keep going.=20  Suppose the residential phone implements DHCP, and thus = implemented the=20 DHCP location options.  Unless the network ALSO implements DHCP = location,=20 it doesn=92t work.  But if the enterprise implements the DHCP = mechanism,=20 then the LLDP mechanism is superfluous.

 

Now take = the=20 enterprise phone and plug it into a home network, on an access network = that=20 does not meet the applicability statement of the L7 mechanism.  = That=20 network deploys DHCP location.  The enterprise phone can=92t get = location=20 unless it also implements DHCP.  Now take that same phone and = plug it=20 into a network that doesn=92t deploy DHCP but does meet the = applicability=20 statement for the L7 protocol.  The enterprise phone ALSO has to=20 implement the L7 protocol.

 

The = =93implement the=20 location mechanism corresponding to the configuration mechanism=94 = simply does=20 not work.  You need a list, where one end implements ALL and the = other=20 end implements =93at least one of=94 to get interoperability.  = There is no=20 other way.

 

It is not = the case=20 that the L7 mechanism can be the single fall-back mechanism.  It = will=20 have an applicability limit, and not all networks will meet it.  = This is=20 effectively true of DHCP.  It would be true of LLDP if it was on = the=20 list.  It is the reason why, in this case, it is the CLIENT that = must=20 implement ALL and the server implement one of.  Usually, we have = the=20 server taking the =93all=94 role and the client taking the =93at least = one of=94=20 role.

 

Brian

 

From:=20 peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] =
Sent: Wednesday, July 12, 2006 = 8:05=20 AM
To: = Rosen, Brian
Cc: andy@hxr.us;=20 Barbara.Stark@bellsouth.com; Ecrit@ietf.org; = rohan.mahy@gmail.com
Subject: Re: LLDP-MED and Phone = BCP (Re:=20 [Ecrit] New phonebcp draft = wassubmitted)

 


Brian,=20
Counter-point to below = is that if=20 the device and network do not support mutually agreeable configuration = method,=20 then the device is a brick anyway.  L7 becomes a fall-back for = the cases=20 where the direct configuration method does not support passing = location=20 through (best example seems to be home router on DSL or cable modem).=20  
An important case, not = sure well=20 heard yesterday during meeting, was that in an IPv6 environment with = address=20 autoconfig there may be no DHCP at all.  This may or may not be a = small=20 case as IPv6 rolls out, remains to be seen.  And while IPv6 is = not really=20 important now in N.A. it is very rapidly becoming important in = Asia/Pac and=20 also Australia (I'm told). =  Cannot=20 ignore it.  
-- Peter=20

 

"Rosen, Brian"=20 <Brian.Rosen@neustar.biz> =

11.07.06=20 20:56

    =    =20
    =    =20 To:       =  <Barbara.Stark@bellsouth.com>,=20 <andy@hxr.us>, <rohan.mahy@gmail.com>=20
    =    =20 cc:        Ecrit@ietf.org =
    =    =20 Subject:        Re: LLDP-MED and Phone BCP = (Re:=20 [Ecrit] New phonebcp draft      =20 =  wassubmitted)




But unless every phone = supports LLDP-MED,=20 then an enterprise must also implement DHCP (or L7) in order to = support those=20 phones that don't support LLDP.  If every access network has to = support=20 those 2, then LLDP is superfelous.

A residential phone may be = plugged=20 into an enterprise network.  Ditto an enterprise phone. =  Location=20 acquisition has to work always.  If there is a list, and one end = must=20 support all, with the other end must support at least one, it always = works.=20

I don't see how you can get around=20 that
--------------------------
Brian Rosen
NeuStar
(724)=20 382-1051
brian.rosen@neustar.biz


-----Original=20 Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan = Mahy
CC:=20 Rosen, Brian;=20 Ecrit@ietf.org
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: = LLDP-MED and=20 Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

What = I'd like=20 to see in the doc would be:
For any device that's "intended to be = operated=20 on a network where the network operator does not control the = specification of=20 every device connected to the network.":

If the device has a = DHCP=20 client, the client MUST support RFC 3825 and = <dhcp-civil>.
 =20 and
If the device supports LLDP-MED, it MUST support the "Location=20 Identification TLV" as defined in <LLDP-MED = reference>.

Given=20 that the Location Identification TLV is mandatory for all VoIP-type = endpoints=20 implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if = statement=20 really doesn't say much. But it would also suggest that devices that = could=20 have soft clients on them (PCs, PDAs) also need to do that TLV when = they do=20 LLDP-MED. All router-type devices that implement LLDP-MED are also = required to=20 support this TLV, per the spec.

Since I'm really not at all = concerned=20 with the behavior of endpoints that don't have a DHCP client, I think = the=20 first if statement is also reasonable. However, I do recommend for = such=20 devices that:
If the device allows for bootstrapping methods other = than=20 DHCP, it SHOULD support being configured to request location through a = DHCP=20 INFORM message with options as described in RFC 3825 and = <dhcp-civil>,=20 when it is configured to use one of these alternate bootstrap methods = (e.g.,=20 PPPoE, PPPoA, static IP address).

Anyway, I think both DHCP = clients and=20 LLDP-MED need to make it into devices based on all their merits, and = not just=20 on location discovery. If a vendor can't justify putting one or the = other of=20 these into a device (outside of recommendations in this BCP), then I = say the=20 protocol doesn't belong in the device. If the device is going to have = one or=20 the other, or both, then it needs to support the location = determination=20 mechanism that goes with it. Since, for LLDP-MED, that's already a = requirement=20 of the LLDP-MED spec, I really don't see a problem with stating it=20 here.
Barbara


       -----Original=20 Message-----
       From: Andrew Newton=20 [mailto:andy@hxr.us]
       Sent: = Friday, June 30,=20 2006 9:44 AM
       To: Rohan Mahy
  =  =20    Cc: Rosen, = Brian;=20 Ecrit@ietf.org
       Subject: Re: LLDP-MED and = Phone=20 BCP (Re: [Ecrit] New phonebcp draft wassubmitted)
    =  =20
     

       On Jun 29, = 2006, at=20 6:29 PM, Rohan Mahy wrote:


        =  =20      To be clear, I do not have a strong feeling about = what=20 does on Brian's list or not.  I think LLDP-MED is a completely = reasonable=20 thing for a wired phone vendor to implement on enterprise class=20 phones.


       Just throwing in my = $0.0199997,=20 I have not formed a strong opinion about this either.  It does = seem=20 reasonable for enterprise class devices with ethernet jacks to = implement=20 LLPD-MED, or for devices of category Y to implement method X... as = what must=20 be implemented by the device will always be dictated by the network = media it=20 uses.

       Where this gets a little = tricky is=20 that if there is no one common method, then devices may end up = implementing=20 things that are not appropriate in an attempt to have devices that = work in=20 multiple network environments... and even then they may end up missing = the=20 mark.  Therefore, one method that does work in all environments = must be=20 implemented.   And that is likely to be the L7-LCP.

  =  =20    -andy

*****

The information transmitted is = intended=20 only for the person or entity to which it is addressed and may contain = confidential, proprietary, and/or privileged material. Any review,=20 retransmission, dissemination or other use of, or taking of any action = in=20 reliance upon this information by persons or entities other than the = intended=20 recipient is prohibited. If you received this in error, please contact = the=20 sender and delete the material from all computers. = 162
_______________________________________________
Ecrit=20 mailing=20 = list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

------_=_NextPart_001_01C6A5BB.58FC7894-- --===============0480268161== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0480268161==-- From ecrit-bounces@ietf.org Wed Jul 12 10:04:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fK8-0003BR-Ja; Wed, 12 Jul 2006 10:04:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fK7-0003B9-Qi for Ecrit@ietf.org; Wed, 12 Jul 2006 10:04:19 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0fK6-0006aW-Lx for Ecrit@ietf.org; Wed, 12 Jul 2006 10:04:19 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G0fJt-0001cC-Mn; Wed, 12 Jul 2006 09:04:07 -0500 From: "Brian Rosen" To: "'Romascanu, Dan \(Dan\)'" , "Rosen, Brian" , , Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) Date: Wed, 12 Jul 2006 10:04:02 -0400 Message-ID: <064f01c6a5bc$09bd6680$bc1cdb84@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acalq55JoAEvc/K+SqG8j4hdobdddQAB+KfwAAF0jpAAADw44AAAPCFgAAAfndA= In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.6 (/) X-Scan-Signature: 8cc1c558da2accc0f39b338f00bd6728 Cc: Barbara.Stark@bellsouth.com, 'David Kessens' , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0434478962==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0434478962== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0650_01C6A59A.82ABC680" This is a multi-part message in MIME format. ------=_NextPart_000_0650_01C6A59A.82ABC680 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Well, I=92m expecting that we=92ll ask =93our=94 ADs to take it to = whomever they think need to look at it, but I=92m sure this won=92t be a problem. = Note that we haven=92t made any queries to anyone yet. =20 =20 Brian =20 _____ =20 From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]=20 Sent: Wednesday, July 12, 2006 9:59 AM To: Rosen, Brian; g.caron@bell.ca; peter_blatherwick@mitel.com Cc: Barbara.Stark@bellsouth.com; David Kessens; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) =20 Brian, =20 Can you please also include the OPS ADs in these queries in the future?=20 =20 Thanks,=20 =20 Dan =20 =20 =20 =20 =20 _____ =20 From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Wednesday, July 12, 2006 4:55 PM To: g.caron@bell.ca; peter_blatherwick@mitel.com Cc: Barbara.Stark@bellsouth.com; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) No, but I=92ve proposed that the design team craft an applicability = statement for an abstract L7 location acquisition protocol that uses the IP = address as the identifier, together with the security implications of it, and ask = the AD=92s (including the security AD=92s) if that would be acceptable. = That idea seemed to find favor as a way to figure out if the basic idea of using = IP address as the identifier will be acceptable, regardless of the protocol details. I think we will do that work within the next several weeks. =20 Brian =20 _____ =20 From: g.caron@bell.ca [mailto:g.caron@bell.ca]=20 Sent: Wednesday, July 12, 2006 9:51 AM To: Rosen, Brian; peter_blatherwick@mitel.com Cc: Barbara.Stark@bellsouth.com; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) =20 Brian, =20 Can you be more precise on the foreseen =93applicability limits=94 of = the yet to be L7 protocol? =20 =20 =20 =20 Guy Caron Bell Canada _____ =20 De : Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Envoy=E9 : 12 juillet 2006 09:21 =C0 : peter_blatherwick@mitel.com Cc : Barbara.Stark@bellsouth.com; Ecrit@ietf.org Objet : RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) =20 This thinking results in cases where assumptions made by one end don=92t = match assumptions made by the other. =20 Let=92s take LLDP as the example. Barbara would say that if the phone implements LLDP, then it should implement LLDP-MED. Okay, so suppose I = have a residential phone which does not implement LLDP, so it doesn=92t = implement LLDP-MED. So far, so good. Now, let=92s look at an enterprise network. = It may implement LLDP, and thus LLDP-MED. Okay, the enterprise phone on = the enterprise network works. What happens when the residential phone = connects to the enterprise network? No location. Let=92s keep going. Suppose = the residential phone implements DHCP, and thus implemented the DHCP = location options. Unless the network ALSO implements DHCP location, it doesn=92t = work. But if the enterprise implements the DHCP mechanism, then the LLDP = mechanism is superfluous.=20 =20 Now take the enterprise phone and plug it into a home network, on an = access network that does not meet the applicability statement of the L7 = mechanism. That network deploys DHCP location. The enterprise phone can=92t get = location unless it also implements DHCP. Now take that same phone and plug it = into a network that doesn=92t deploy DHCP but does meet the applicability = statement for the L7 protocol. The enterprise phone ALSO has to implement the L7 protocol. =20 The =93implement the location mechanism corresponding to the = configuration mechanism=94 simply does not work. You need a list, where one end = implements ALL and the other end implements =93at least one of=94 to get = interoperability. There is no other way. =20 It is not the case that the L7 mechanism can be the single fall-back mechanism. It will have an applicability limit, and not all networks = will meet it. This is effectively true of DHCP. It would be true of LLDP if = it was on the list. It is the reason why, in this case, it is the CLIENT = that must implement ALL and the server implement one of. Usually, we have = the server taking the =93all=94 role and the client taking the =93at least = one of=94 role. =20 Brian =20 _____ =20 From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Wednesday, July 12, 2006 8:05 AM To: Rosen, Brian Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; rohan.mahy@gmail.com Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) =20 Brian,=20 Counter-point to below is that if the device and network do not support mutually agreeable configuration method, then the device is a brick = anyway. L7 becomes a fall-back for the cases where the direct configuration = method does not support passing location through (best example seems to be home router on DSL or cable modem). =20 An important case, not sure well heard yesterday during meeting, was = that in an IPv6 environment with address autoconfig there may be no DHCP at all. This may or may not be a small case as IPv6 rolls out, remains to be = seen. And while IPv6 is not really important now in N.A. it is very rapidly becoming important in Asia/Pac and also Australia (I'm told). Cannot = ignore it. =20 -- Peter=20 =20 "Rosen, Brian" =20 11.07.06 20:56=20 =20 To: , , =20 cc: Ecrit@ietf.org=20 Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New = phonebcp draft wassubmitted) But unless every phone supports LLDP-MED, then an enterprise must also implement DHCP (or L7) in order to support those phones that don't = support LLDP. If every access network has to support those 2, then LLDP is superfelous. A residential phone may be plugged into an enterprise network. Ditto an enterprise phone. Location acquisition has to work always. If there is = a list, and one end must support all, with the other end must support at = least one, it always works.=20 I don't see how you can get around that -------------------------- Brian Rosen NeuStar (724) 382-1051 brian.rosen@neustar.biz -----Original Message----- From: Stark, Barbara To: Andrew Newton; Rohan Mahy CC: Rosen, Brian; Ecrit@ietf.org Sent: Tue Jul 11 20:43:26 2006 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the network operator does not control the specification of every device connected to the network.": If the device has a DHCP client, the client MUST support RFC 3825 and . and If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in . Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the = 2nd if statement really doesn't say much. But it would also suggest that = devices that could have soft clients on them (PCs, PDAs) also need to do that = TLV when they do LLDP-MED. All router-type devices that implement LLDP-MED = are also required to support this TLV, per the spec. Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also = reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP INFORM = message with options as described in RFC 3825 and , when it is configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static IP address). Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. If a = vendor can't justify putting one or the other of these into a device (outside = of recommendations in this BCP), then I say the protocol doesn't belong in = the device. If the device is going to have one or the other, or both, then = it needs to support the location determination mechanism that goes with it. Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, = I really don't see a problem with stating it here. Barbara -----Original Message----- From: Andrew Newton [ mailto:andy@hxr.us] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp = draft wassubmitted) =20 =20 On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: To be clear, I do not have a strong feeling about what = does on Brian's list or not. I think LLDP-MED is a completely reasonable = thing for a wired phone vendor to implement on enterprise class phones. Just throwing in my $0.0199997, I have not formed a strong = opinion about this either. It does seem reasonable for enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices of category Y = to implement method X... as what must be implemented by the device will = always be dictated by the network media it uses. Where this gets a little tricky is that if there is no one common method, then devices may end up implementing things that are not = appropriate in an attempt to have devices that work in multiple network = environments... and even then they may end up missing the mark. Therefore, one method = that does work in all environments must be implemented. And that is likely = to be the L7-LCP. -andy ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by persons = or entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the material from = all computers. 162 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------=_NextPart_000_0650_01C6A59A.82ABC680 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Well, I’m expecting that = we’ll ask “our” ADs to take it to whomever they think need to look = at it, but I’m sure this won’t be a problem. =A0Note that we = haven’t made any queries to anyone yet.=A0

 

Brian

 

From: = Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
Sent: Wednesday, July 12, = 2006 9:59 AM
To: Rosen, Brian; g.caron@bell.ca; = peter_blatherwick@mitel.com
Cc: = Barbara.Stark@bellsouth.com; David Kessens; Ecrit@ietf.org
Subject: RE: LLDP-MED and = Phone BCP (Re: [Ecrit] New = phonebcpdraftwassubmitted)

 

= Brian,

 

= Can you please also include the OPS ADs in these queries in the future? =

 

= Thanks,

 

= Dan

 

 

 

 

=

 

From: Rosen, Brian = [mailto:Brian.Rosen@neustar.biz]
Sent: Wednesday, July 12, = 2006 4:55 PM
To: g.caron@bell.ca; peter_blatherwick@mitel.com
Cc: = Barbara.Stark@bellsouth.com; Ecrit@ietf.org
Subject: RE: LLDP-MED and = Phone BCP (Re: [Ecrit] New = phonebcpdraftwassubmitted)

No, but I’ve proposed that = the design team craft an applicability statement for an abstract L7 location acquisition protocol that uses the IP address as the identifier, = together with the security implications of it, and ask the AD’s (including the = security AD’s) if that would be acceptable.  That idea seemed to find = favor as a way to figure out if the basic idea of using IP address as the = identifier will be acceptable, regardless of the protocol details.  I think we = will do that work within the next several weeks.

 

Brian

 

From: = g.caron@bell.ca [mailto:g.caron@bell.ca]
Sent: Wednesday, July 12, = 2006 9:51 AM
To: Rosen, Brian; peter_blatherwick@mitel.com
Cc: = Barbara.Stark@bellsouth.com; Ecrit@ietf.org
Subject: RE: LLDP-MED and = Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted)

 

Brian,

 

Can you be more precise on the = foreseen “applicability limits” of the yet to be L7 = protocol?

 

 

 

 

Guy Caron

Bell Canada

De : Rosen, Brian = [mailto:Brian.Rosen@neustar.biz]
Envoy=E9 : 12 = juillet 2006 09:21
=C0 : = peter_blatherwick@mitel.com
Cc : Barbara.Stark@bellsouth.com; Ecrit@ietf.org
Objet : RE: LLDP-MED = and Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted)

 

This thinking results in cases = where assumptions made by one end don’t match assumptions made by the = other.

 

Let’s take LLDP as the example.  Barbara would say that if the phone implements LLDP, then = it should implement LLDP-MED.  Okay, so suppose I have a residential = phone which does not implement LLDP, so it doesn’t implement = LLDP-MED.  So far, so good.  Now, let’s look at an enterprise = network.  It may implement LLDP, and thus LLDP-MED.  Okay, the enterprise phone = on the enterprise network works.  What happens when the residential phone connects to the enterprise network?  No location.  Let’s = keep going.  Suppose the residential phone implements DHCP, and thus implemented the DHCP location options.  Unless the network ALSO = implements DHCP location, it doesn’t work.  But if the enterprise = implements the DHCP mechanism, then the LLDP mechanism is superfluous. =

 

Now take the enterprise phone and = plug it into a home network, on an access network that does not meet the = applicability statement of the L7 mechanism.  That network deploys DHCP = location.  The enterprise phone can’t get location unless it also implements DHCP.  Now take that same phone and plug it into a network that doesn’t deploy DHCP but does meet the applicability statement for = the L7 protocol.  The enterprise phone ALSO has to implement the L7 = protocol.

 

The “implement the location mechanism corresponding to the configuration mechanism” simply = does not work.  You need a list, where one end implements ALL and the other = end implements “at least one of” to get interoperability.  = There is no other way.

 

It is not the case that the L7 = mechanism can be the single fall-back mechanism.  It will have an = applicability limit, and not all networks will meet it.  This is effectively true = of DHCP.  It would be true of LLDP if it was on the list.  It is = the reason why, in this case, it is the CLIENT that must implement ALL and = the server implement one of.  Usually, we have the server taking the “all” role and the client taking the “at least one = of” role.

 

Brian

 

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Wednesday, July 12, = 2006 8:05 AM
To: Rosen, Brian
Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; rohan.mahy@gmail.com
Subject: Re: LLDP-MED and = Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted)

 


Brian,
Counter-point to below is that if the device and network do not support mutually = agreeable configuration method, then the device is a brick anyway.  L7 = becomes a fall-back for the cases where the direct configuration method does not = support passing location through (best example seems to be home router on DSL or = cable modem).  
An important case, not sure well heard yesterday during meeting, was that = in an IPv6 environment with address autoconfig there may be no DHCP at all.  This may or may not be a small case as IPv6 rolls out, remains to = be seen.  And while IPv6 is not really important now in N.A. it is = very rapidly becoming important in Asia/Pac and also Australia (I'm told). =  Cannot ignore it.  
-- Peter

 

"Rosen, Brian" = <Brian.Rosen@neustar.biz>

11.07.06 20:56

       
        To:        <Barbara.Stark@bellsouth.com>, <andy@hxr.us>, <rohan.mahy@gmail.com>
        cc:       =  Ecrit@ietf.org
        Subject:        Re: LLDP-MED = and Phone BCP (Re: [Ecrit] New phonebcp draft        wassubmitted)




But unless = every phone supports LLDP-MED, then an enterprise must also implement DHCP (or = L7) in order to support those phones that don't support LLDP.  If every = access network has to support those 2, then LLDP is superfelous.

A residential phone may be plugged into an enterprise network. =  Ditto an enterprise phone.  Location acquisition has to work always. =  If there is a list, and one end must support all, with the other end must support = at least one, it always works.

I don't see how you can get around that
--------------------------
Brian Rosen
NeuStar
(724) 382-1051
brian.rosen@neustar.biz


-----Original Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan Mahy
CC: Rosen, Brian; = Ecrit@ietf.org
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where = the network operator does not control the specification of every device = connected to the network.":

If the device has a DHCP client, the client MUST support RFC 3825 and <dhcp-civil>.
  and
If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in <LLDP-MED reference>.

Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the = 2nd if statement really doesn't say much. But it would also suggest that = devices that could have soft clients on them (PCs, PDAs) also need to do that TLV = when they do LLDP-MED. All router-type devices that implement LLDP-MED are also = required to support this TLV, per the spec.

Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also reasonable. = However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP INFORM = message with options as described in RFC 3825 and <dhcp-civil>, when it is = configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, = static IP address).

Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. If a = vendor can't justify putting one or the other of these into a device (outside = of recommendations in this BCP), then I say the protocol doesn't belong in = the device. If the device is going to have one or the other, or both, then = it needs to support the location determination mechanism that goes with it. = Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really = don't see a problem with stating it here.
Barbara


       -----Original Message-----
       From: Andrew Newton [mailto:andy@hxr.us]
       Sent: Friday, June 30, 2006 9:44 AM
       To: Rohan Mahy
       Cc: Rosen, = Brian; Ecrit@ietf.org
       Subject: Re: LLDP-MED and Phone BCP (Re: = [Ecrit] New phonebcp draft wassubmitted)
     
     

       On Jun 29, 2006, at 6:29 PM, Rohan Mahy = wrote:


               To be clear, I do = not have a strong feeling about what does on Brian's list or not.  I = think LLDP-MED is a completely reasonable thing for a wired phone vendor to = implement on enterprise class phones.


       Just throwing in my $0.0199997, I have not = formed a strong opinion about this either.  It does seem reasonable for = enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices = of category Y to implement method X... as what must be implemented by the = device will always be dictated by the network media it uses.

       Where this gets a little tricky is that if = there is no one common method, then devices may end up implementing things that = are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark.  Therefore, one method that does work in all environments must be implemented.   And that is likely to be the L7-LCP.

       -andy

*****

The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or entities = other than the intended recipient is prohibited. If you received this in = error, please contact the sender and delete the material from all computers. = 162
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

=
------=_NextPart_000_0650_01C6A59A.82ABC680-- --===============0434478962== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0434478962==-- From ecrit-bounces@ietf.org Wed Jul 12 10:08:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fOH-0003m8-7g; Wed, 12 Jul 2006 10:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fOG-0003kI-5s for Ecrit@ietf.org; Wed, 12 Jul 2006 10:08:36 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0fOF-0006kn-Av for Ecrit@ietf.org; Wed, 12 Jul 2006 10:08:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) Date: Wed, 12 Jul 2006 16:09:56 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B14@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) Thread-Index: Acalq55JoAEvc/K+SqG8j4hdobdddQAB+KfwAAJWZAI= References: From: "Stastny Richard" To: "Rosen, Brian" X-Spam-Score: 0.5 (/) X-Scan-Signature: 325b777e1a3a618c889460b612a65510 Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >You need a list, where one end implements ALL and the other end = implements "at least one of" to get interoperability. There is no = >other way. =20 Fully agree. A device needs to implement ALL possible mechanisms, there = is no other way, since you never know where a device is attached to. Period =20 Richard ________________________________ Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Gesendet: Mi 12.07.2006 15:20 An: peter_blatherwick@mitel.com Cc: Barbara.Stark@bellsouth.com; Ecrit@ietf.org Betreff: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted) This thinking results in cases where assumptions made by one end don't = match assumptions made by the other. =20 Let's take LLDP as the example. Barbara would say that if the phone = implements LLDP, then it should implement LLDP-MED. Okay, so suppose I = have a residential phone which does not implement LLDP, so it doesn't = implement LLDP-MED. So far, so good. Now, let's look at an enterprise = network. It may implement LLDP, and thus LLDP-MED. Okay, the = enterprise phone on the enterprise network works. What happens when the = residential phone connects to the enterprise network? No location. = Let's keep going. Suppose the residential phone implements DHCP, and = thus implemented the DHCP location options. Unless the network ALSO = implements DHCP location, it doesn't work. But if the enterprise = implements the DHCP mechanism, then the LLDP mechanism is superfluous.=20 =20 Now take the enterprise phone and plug it into a home network, on an = access network that does not meet the applicability statement of the L7 = mechanism. That network deploys DHCP location. The enterprise phone = can't get location unless it also implements DHCP. Now take that same = phone and plug it into a network that doesn't deploy DHCP but does meet = the applicability statement for the L7 protocol. The enterprise phone = ALSO has to implement the L7 protocol. =20 The "implement the location mechanism corresponding to the configuration = mechanism" simply does not work. You need a list, where one end = implements ALL and the other end implements "at least one of" to get = interoperability. There is no other way. =20 It is not the case that the L7 mechanism can be the single fall-back = mechanism. It will have an applicability limit, and not all networks = will meet it. This is effectively true of DHCP. It would be true of = LLDP if it was on the list. It is the reason why, in this case, it is = the CLIENT that must implement ALL and the server implement one of. = Usually, we have the server taking the "all" role and the client taking = the "at least one of" role. =20 Brian =20 ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Wednesday, July 12, 2006 8:05 AM To: Rosen, Brian Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; = rohan.mahy@gmail.com Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) =20 Brian,=20 Counter-point to below is that if the device and network do not support = mutually agreeable configuration method, then the device is a brick = anyway. L7 becomes a fall-back for the cases where the direct = configuration method does not support passing location through (best = example seems to be home router on DSL or cable modem). =20 An important case, not sure well heard yesterday during meeting, was = that in an IPv6 environment with address autoconfig there may be no DHCP = at all. This may or may not be a small case as IPv6 rolls out, remains = to be seen. And while IPv6 is not really important now in N.A. it is = very rapidly becoming important in Asia/Pac and also Australia (I'm = told). Cannot ignore it. =20 -- Peter=20 =20 "Rosen, Brian" =20 11.07.06 20:56=20 =20 To: , , = =20 cc: Ecrit@ietf.org=20 Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New = phonebcp draft wassubmitted) But unless every phone supports LLDP-MED, then an enterprise must also = implement DHCP (or L7) in order to support those phones that don't = support LLDP. If every access network has to support those 2, then LLDP = is superfelous. A residential phone may be plugged into an enterprise network. Ditto an = enterprise phone. Location acquisition has to work always. If there is = a list, and one end must support all, with the other end must support at = least one, it always works.=20 I don't see how you can get around that -------------------------- Brian Rosen NeuStar (724) 382-1051 brian.rosen@neustar.biz -----Original Message----- From: Stark, Barbara To: Andrew Newton; Rohan Mahy CC: Rosen, Brian; Ecrit@ietf.org Sent: Tue Jul 11 20:43:26 2006 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the = network operator does not control the specification of every device = connected to the network.": If the device has a DHCP client, the client MUST support RFC 3825 and = . and If the device supports LLDP-MED, it MUST support the "Location = Identification TLV" as defined in . Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED = spec), the 2nd if statement really doesn't say much. But it would also = suggest that devices that could have soft clients on them (PCs, PDAs) = also need to do that TLV when they do LLDP-MED. All router-type devices = that implement LLDP-MED are also required to support this TLV, per the = spec. Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also = reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP = INFORM message with options as described in RFC 3825 and , = when it is configured to use one of these alternate bootstrap methods = (e.g., PPPoE, PPPoA, static IP address). Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. = If a vendor can't justify putting one or the other of these into a = device (outside of recommendations in this BCP), then I say the protocol = doesn't belong in the device. If the device is going to have one or the = other, or both, then it needs to support the location determination = mechanism that goes with it. Since, for LLDP-MED, that's already a = requirement of the LLDP-MED spec, I really don't see a problem with = stating it here. Barbara -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us ] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp = draft wassubmitted) =20 =20 On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: To be clear, I do not have a strong feeling about what = does on Brian's list or not. I think LLDP-MED is a completely = reasonable thing for a wired phone vendor to implement on enterprise = class phones. Just throwing in my $0.0199997, I have not formed a strong = opinion about this either. It does seem reasonable for enterprise class = devices with ethernet jacks to implement LLPD-MED, or for devices of = category Y to implement method X... as what must be implemented by the = device will always be dictated by the network media it uses. Where this gets a little tricky is that if there is no one common = method, then devices may end up implementing things that are not = appropriate in an attempt to have devices that work in multiple network = environments... and even then they may end up missing the mark. = Therefore, one method that does work in all environments must be = implemented. And that is likely to be the L7-LCP. -andy ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 162 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 12 10:19:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fYs-0005fl-4U; Wed, 12 Jul 2006 10:19:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fYr-0005fb-Fn for ecrit@ietf.org; Wed, 12 Jul 2006 10:19:33 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0fYr-0007Vm-0Z for ecrit@ietf.org; Wed, 12 Jul 2006 10:19:33 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6CEJUd25892; Wed, 12 Jul 2006 10:19:30 -0400 (EDT) Received: from [127.0.0.1] ([47.9.28.64] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 10:19:29 -0400 Message-ID: <44B504EC.1030607@nortel.com> Date: Wed, 12 Jul 2006 10:19:24 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Ron Watro Subject: Re: [Ecrit] Review of Security Threats Draft References: <6.1.0.6.2.20060522065257.036212f0@po2.bbn.com> In-Reply-To: <6.1.0.6.2.20060522065257.036212f0@po2.bbn.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2006 14:19:29.0873 (UTC) FILETIME=[30436410:01C6A5BE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Responses below. I've made some changes in response. Thanks for your comments. Ron Watro wrote: > Here are some brief comments on draft-ietf-ecrit-security-threats-01, > dated April 17 2006 > > Good job by Tom to persevere through the various versions of this document. > > General comment: The current draft focuses on the security requirements > for just the parts of the VoIP emergency response system that are ECRIT > work items. Some of the previous incarnations of this document also > included an overview of the full system security concept, so that one > could see that the security being proposed for the ECRIT work items was > consistent with at least one full-scale plan. At the interim meeting, > it was decided to drop any discussion of system security as a whole. > This decision was influenced by several issues, including the desire for > ECRIT to make speedy progress and the lack of any consensus on the full > system approach. There were some dissenting opinions at the interim > meeting, arguing that a properly caveated, strawman view of the full > system and its security concept was needed to provide a basis for the > security services allocated to ECRIT work items. In any event, we > currently have the version without the system view, and going forward we > can expect comments asking why the component security requirements were > not derived from a set of system security requirements (as is commonly > done). [PTT] Already discussed, no action for the moment. > > Specific comments are below: > > Abstract > > --doubled "the" in the last sentence [PTT] Fixed. > > 1 Introduction > > --suggest changing the two "must be" wordings in the 1st paragraph to > "is being" . The marking idea and the mapping server are not the only > feasible solutions to the problems at hand. [PTT] Fixed. > --mixture of commas and periods as list separators in the last paragraph > [PTT] This is prose, not a list. I combined the last three sections in one run-on sentence because putting them into individual sentences would be too boring. > 4 Objectives of attackers > > --for the third bullet, it seems conceivable that a structured emergency > service marker could help support the process of preventing fraudulent > emergency calls (by assisting in track-back of the call, for example). > In this case, there could be interaction with ECRIT work items [PTT] Wrong end of the stick. This is a potential solution based on ECRIT work, rather than a potential problem created by ECRIT work. > --inconsistent punctuation at the end of bulleted items [PTT] Fixed, I think. > > 5 Potential Attacks > > 5.1 Identifier attacks > > --Is the emergency identifier known to be just a single bit, or could it > contain data that can be use for other proposes (time stamp, > cryptographic signature?) [PTT] Something that would be used for other purposes should be a separate field. It is bad protocol design to overload individual fields. > --You say that theft-of-service calls most probably will not include any > location information - but wouldn't they mostly likely include falsified > location information so that they look legit but cannot be tracked back > to the source? [PTT] Fixed as discussed in another E-mail (by mentioning additional possibility of false data). > > 6 Security requirements > > from section 5.1 fraudulent calls > --How will a URI be verified as a PSAP? Will the mapping server be used > or is this a non-ECRIT security requirement? [PTT] This is in the realm of solution, hence out of scope. However, I visualize a database listing every PSAP URI in the world. It seems to me there is an obvious relationship to the mapping service. > --Are long distance calls to remote PSAPs always fraudulent? For > example, a disreputable foreign entity might set up a phony PSAP for its > people to call. Can a service provider refuse to carry or perhaps > reroute a long distance emergency request? [PTT] No, one can easily imagine use cases where long distance calls are legitimate -- typically third party reports of emergencies. > > from section 5.2.1 impersonation of the mapping server > --mapping server discovery is apparently outside the scope of ECRIT > topic, so does ECRIT simply assume that this will be done in a secure > manner? [PTT] The security I-D does state a requirement: "Requirement: the security considerations for any discussion of mapping server discovery MUST address measures to prevent impersonation of the mapping server." > --will the protocol allow exchange with unauthenticated servers if no > authenticated ones can be found? [PTT] That's policy, I assume. The requirement is phrased in the opposite sense, that authentication must be possible. > --does it ever make sense to return mapping server audit data to the > client? Is this data encrypted to make it inaccessible by the client? > Is this design intended to address rogue servers? If not, then why not > just store the data on the server? [PTT] I think you make a valid point. First off, to be clear, the measure is aimed at the case of a legitimate (not rogue) mapping server that has errors in its database. The requirement was stated the way it was because I figured identification of these errors needed the cooperation of the client. But I was assuming a particular solution that I don't think will work. I rephrased to be less directive: "Requirement: the protocol SHOULD include information in the response that allows subsequent correlation of that response with internal logs that may be kept on the mapping server, to allow debugging of mis-directed calls. One example of a way to meet this requirement would be by means of an opaque parameter in the returned URI." > > from section 5.2.3 snooping attack > -- the protocol or system must provide confidentiality mechanisms but > the mapping server should respond to non-complaint clients with > unprotected data if that is the only option [PTT] I think the draft is talking about mandatory-to-implement capabilities. Local policy will undoubtedly accommodate non-compliant clients, but we've had this discussion in various forms before and have decided that the security considerations document should take a firm line. > > Final comment: Any concern about "insider attack" -- rogue PSAPs, SIP > proxies, etc? [PTT] Legitimate concern, but in scope only to the extent dealt with in terms of DOS attacks on mapping server. > > Ron Watro > > > > > > > > > > > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 12 10:25:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ff4-0006uJ-KF; Wed, 12 Jul 2006 10:25:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ff3-0006to-Qt for Ecrit@ietf.org; Wed, 12 Jul 2006 10:25:57 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0ff2-0007ix-Ex for Ecrit@ietf.org; Wed, 12 Jul 2006 10:25:57 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6CEPsjd021559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 12 Jul 2006 07:25:55 -0700 Received: from [132.219.21.211] (vpn-10-50-16-123.qualcomm.com [10.50.16.123]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6CEPmhC016601; Wed, 12 Jul 2006 07:25:53 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <32755D354E6B65498C3BD9FD496C7D462C4B14@oefeg-s04.oefeg.loc> References: <32755D354E6B65498C3BD9FD496C7D462C4B14@oefeg-s04.oefeg.loc> Date: Wed, 12 Jul 2006 07:25:48 -0700 To: "Stastny Richard" , "Rosen, Brian" From: Ted Hardie Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.6 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At 4:09 PM +0200 7/12/06, Stastny Richard wrote: > >You need a list, where one end implements ALL and the other end implements "at least one of" to get interoperability. There is no >other way. > >Fully agree. A device needs to implement ALL possible mechanisms, there is no other way, since you never know where a >device is attached to. Period > >Richard > My agreement with this depends a lot on what "possible" means. If someone defines a pppoe mechanisms, implementing it in a phone that doesn't support ethernet or pppoe is not useful. If you define that as "not a possible mechanism for that phone", then we're probably okay. But that sounds to me closer to what Barbara is saying than what Brian has said. I also believe we need to see the text Brian mentioned in the room yesterday for self-configuration. For some devices, self-configuration will be more accurate than the network-provided location received by many of these methods. But putting that into the list of mechanisms has some pretty interesting results. Last, the l7 question has two issues. First, if you have IP connectivity, will you be able to reach an l7 server? The answer to that had better be yes, since reaching one and reaching a sip service have pretty similar properties. The other question is: will the l7 server be able to identify 1) you and 2) where you. I take it that Brian's primary concern is that it will not be possible to identify a client to the l7 server in ways that will work reliably in all environments. Until we get a little deeper I can't say, but I do have to question whether the effort to get to that point (so that there is single fallback mechanism) is really worse than every client implementing everything, where everything is a potentially growing list. Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 12 10:26:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ffd-00075c-VU; Wed, 12 Jul 2006 10:26:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ffc-00075S-Lf for ecrit@ietf.org; Wed, 12 Jul 2006 10:26:32 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0ffb-0007kE-Fl for ecrit@ietf.org; Wed, 12 Jul 2006 10:26:32 -0400 Received: from [142.131.134.182] ([::ffff:142.131.134.182]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 12 Jul 2006 10:26:46 -0400 id 015880AE.44B506A6.00001DCF In-Reply-To: <76E8D1DF-FBE6-4064-83CB-F3572F8B0981@hxr.us> References: <44B338F1.6080005@cisco.com> <76E8D1DF-FBE6-4064-83CB-F3572F8B0981@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] comments on LoST Date: Wed, 12 Jul 2006 10:26:27 -0400 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Responding to my own message since Jonathan and I had a quick exchange on this subject in the meeting yesterday... On Jul 11, 2006, at 4:02 PM, Andrew Newton wrote: >> * Security aspects are still really weak. You need to specify >> basic proceudres as part of the basic client and server >> processing. Beyond mutual tls I think we want a standard server >> side authentication mechanism as well, with no client authentication > > Being able to have that would be nice, but server side > authentication will not work world wide. I suppose it would depend > on the TLS library, but some would require a requery with different > options if the first query failed due to bad authentication. Just to be clear, you are suggesting this as MUST implement but not MUST deploy, correct? So long as there is plain HTTP, I see no harm in doing this. I believe client authentication will be difficult to achieve in practice, but I see no reason why we can't ask implementations to support it since it is a common feature in most TLS libraries. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 12 10:35:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0foP-0008U4-2F; Wed, 12 Jul 2006 10:35:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0foO-0008TZ-OJ for Ecrit@ietf.org; Wed, 12 Jul 2006 10:35:36 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0foN-00087S-Fp for Ecrit@ietf.org; Wed, 12 Jul 2006 10:35:36 -0400 Received: from [132.219.26.162] (h1aa2-net84db.lab.risq.net [132.219.26.162] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6CEZ6q2004614 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 12 Jul 2006 10:35:18 -0400 (EDT) In-Reply-To: References: <32755D354E6B65498C3BD9FD496C7D462C4B14@oefeg-s04.oefeg.loc> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <191BD98E-909D-4381-8D84-D3E2F4C61A38@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) Date: Wed, 12 Jul 2006 10:35:04 -0400 To: Ted Hardie X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.6 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "Rosen, Brian" , Stastny Richard , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org One of Brian's favorite topics and a limitation of L7 protocols: VPNs. In those cases, you are unlikely to get to the right L7 server or get it the right IP address. In those cases, lower-layer solutions, such as LLDP-MED and DHCP are likely to be more reliable. Thus, I think as important as picking a list, is to also suggest the sequence of things to try and whether to keep trying if you got an answer (which may be wrong). In other words, if you got a location via DHCP, should you also ask via L7? On Jul 12, 2006, at 10:25 AM, Ted Hardie wrote: > At 4:09 PM +0200 7/12/06, Stastny Richard wrote: >>> You need a list, where one end implements ALL and the other end >>> implements "at least one of" to get interoperability. There is >>> no >other way. >> >> Fully agree. A device needs to implement ALL possible mechanisms, >> there is no other way, since you never know where a >> device is attached to. Period >> >> Richard >> > > My agreement with this depends a lot on what "possible" means. If > someone defines a pppoe mechanisms, implementing it in a phone that > doesn't support ethernet or pppoe is not useful. If you define > that as "not a possible mechanism for that phone", then we're > probably okay. But that sounds to me closer to what Barbara is > saying than what Brian has said. > > I also believe we need to see the text Brian mentioned in the room > yesterday for self-configuration. For some devices, self- > configuration will be more accurate than the network-provided > location received by many of these methods. But putting that into > the list of mechanisms has some pretty interesting results. > > Last, the l7 question has two issues. First, if you have IP > connectivity, will you be able to > reach an l7 server? The answer to that had better be yes, since > reaching one and reaching a sip service have pretty similar > properties. The other question is: will the l7 server be able to > identify 1) you and 2) where you. I take it that Brian's primary > concern is that it will not be possible to identify a client to > the l7 server in ways that will work reliably in all > environments. Until we get a little deeper I can't say, but I do > have to question whether the effort to get to that point (so that > there is single fallback mechanism) is really worse than every > client implementing everything, where everything is a potentially > growing list. > > Ted > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 12 10:46:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fzD-0003Y3-Bd; Wed, 12 Jul 2006 10:46:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0fzB-0003X3-9h for Ecrit@ietf.org; Wed, 12 Jul 2006 10:46:45 -0400 Received: from bellwecs5.bellnexxia.net ([207.236.237.117] helo=bellwecs5.srvr.bell.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0fz8-0000C1-3B for Ecrit@ietf.org; Wed, 12 Jul 2006 10:46:45 -0400 Received: (qmail 10217 invoked from network); 12 Jul 2006 14:46:41 -0000 Received: from g.caron@bell.ca by bellwecs5.srvr.bell.ca with EntrustECS-Server-7.4; 12 Jul 2006 14:46:41 -0000 Received: from bellwfep7.bellnexxia.net (HELO bellwfep7-srv.bellnexxia.net) (207.236.237.99) by bellwecs5.srvr.bell.ca with SMTP; 12 Jul 2006 14:46:40 -0000 Received: from TOROONDC908.bell.corp.bce.ca ([142.182.89.88]) by bellwfep7-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20060712144640.DZXH9968.bellwfep7-srv.bellnexxia.net@TOROONDC908.bell.corp.bce.ca>; Wed, 12 Jul 2006 10:46:40 -0400 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by TOROONDC908.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 10:46:30 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) Date: Wed, 12 Jul 2006 10:46:27 -0400 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF3081AC7C0@toroondc912> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) Thread-Index: Acalq55JoAEvc/K+SqG8j4hdobdddQAB+KfwAAF0jpAAADw44AAAM/vA From: To: , X-OriginalArrivalTime: 12 Jul 2006 14:46:30.0229 (UTC) FILETIME=[F6121850:01C6A5C1] X-Spam-Score: 0.9 (/) X-Scan-Signature: 0422d07f8ece7c28c8be9cc3edc33d94 Cc: Barbara.Stark@bellsouth.com, Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1749450051==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1749450051== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A5C1.F4F2C4F0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A5C1.F4F2C4F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Great! =20 Therefore those limits are pure speculation at this time and since a = brochette of experts will be looking into this, we can be optimistic as = of the outcome. =20 If this is the case, I wonder if all those discussions on a possible = list of protocols at the end point would become irrelevant since the L7 = protocol would be in a position to work in all IP based network, = independent of the L2 on which it is riding on (I admit, this is pure = speculation from my part here...). =20 >From an implementation perspective (this is my primary concern as a = broadband access operator AND VoIP service provider in all market = segments), this seems to be the most simplified model. However, I = wouldn't go as far as restricting one to implement only a protocol; I = would say "MUST implement at least the [L7] protocol for location = acquisition...". As stated by Barbara, some other business enablers may = drive a network administrator to implement another one within its = specific environment (the LLDP case) with little incremental efforts and = resources. =20 For the applicability statement you are suggesting, it should apply to = all other candidates as well as they too may have limits and security = implications. =20 Guy Caron Bell Canada ________________________________ De : Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Envoy=E9 : 12 juillet 2006 09:55 =C0 : Caron, Guy (A162859); peter_blatherwick@mitel.com Cc : Barbara.Stark@bellsouth.com; Ecrit@ietf.org Objet : RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted) =20 No, but I've proposed that the design team craft an applicability = statement for an abstract L7 location acquisition protocol that uses the = IP address as the identifier, together with the security implications of = it, and ask the AD's (including the security AD's) if that would be = acceptable. That idea seemed to find favor as a way to figure out if = the basic idea of using IP address as the identifier will be acceptable, = regardless of the protocol details. I think we will do that work within = the next several weeks. =20 Brian =20 ________________________________ From: g.caron@bell.ca [mailto:g.caron@bell.ca]=20 Sent: Wednesday, July 12, 2006 9:51 AM To: Rosen, Brian; peter_blatherwick@mitel.com Cc: Barbara.Stark@bellsouth.com; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted) =20 Brian, =20 Can you be more precise on the foreseen "applicability limits" of the = yet to be L7 protocol? =20 =20 =20 =20 Guy Caron Bell Canada ________________________________ De : Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Envoy=E9 : 12 juillet 2006 09:21 =C0 : peter_blatherwick@mitel.com Cc : Barbara.Stark@bellsouth.com; Ecrit@ietf.org Objet : RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted) =20 This thinking results in cases where assumptions made by one end don't = match assumptions made by the other. =20 Let's take LLDP as the example. Barbara would say that if the phone = implements LLDP, then it should implement LLDP-MED. Okay, so suppose I = have a residential phone which does not implement LLDP, so it doesn't = implement LLDP-MED. So far, so good. Now, let's look at an enterprise = network. It may implement LLDP, and thus LLDP-MED. Okay, the = enterprise phone on the enterprise network works. What happens when the = residential phone connects to the enterprise network? No location. = Let's keep going. Suppose the residential phone implements DHCP, and = thus implemented the DHCP location options. Unless the network ALSO = implements DHCP location, it doesn't work. But if the enterprise = implements the DHCP mechanism, then the LLDP mechanism is superfluous.=20 =20 Now take the enterprise phone and plug it into a home network, on an = access network that does not meet the applicability statement of the L7 = mechanism. That network deploys DHCP location. The enterprise phone = can't get location unless it also implements DHCP. Now take that same = phone and plug it into a network that doesn't deploy DHCP but does meet = the applicability statement for the L7 protocol. The enterprise phone = ALSO has to implement the L7 protocol. =20 The "implement the location mechanism corresponding to the configuration = mechanism" simply does not work. You need a list, where one end = implements ALL and the other end implements "at least one of" to get = interoperability. There is no other way. =20 It is not the case that the L7 mechanism can be the single fall-back = mechanism. It will have an applicability limit, and not all networks = will meet it. This is effectively true of DHCP. It would be true of = LLDP if it was on the list. It is the reason why, in this case, it is = the CLIENT that must implement ALL and the server implement one of. = Usually, we have the server taking the "all" role and the client taking = the "at least one of" role. =20 Brian =20 ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Wednesday, July 12, 2006 8:05 AM To: Rosen, Brian Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; = rohan.mahy@gmail.com Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) =20 Brian,=20 Counter-point to below is that if the device and network do not support = mutually agreeable configuration method, then the device is a brick = anyway. L7 becomes a fall-back for the cases where the direct = configuration method does not support passing location through (best = example seems to be home router on DSL or cable modem). =20 An important case, not sure well heard yesterday during meeting, was = that in an IPv6 environment with address autoconfig there may be no DHCP = at all. This may or may not be a small case as IPv6 rolls out, remains = to be seen. And while IPv6 is not really important now in N.A. it is = very rapidly becoming important in Asia/Pac and also Australia (I'm = told). Cannot ignore it. =20 -- Peter=20 =20 "Rosen, Brian" =20 11.07.06 20:56=20 =20 To: , , = =20 cc: Ecrit@ietf.org=20 Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New = phonebcp draft wassubmitted) But unless every phone supports LLDP-MED, then an enterprise must also = implement DHCP (or L7) in order to support those phones that don't = support LLDP. If every access network has to support those 2, then LLDP = is superfelous. A residential phone may be plugged into an enterprise network. Ditto an = enterprise phone. Location acquisition has to work always. If there is = a list, and one end must support all, with the other end must support at = least one, it always works.=20 I don't see how you can get around that -------------------------- Brian Rosen NeuStar (724) 382-1051 brian.rosen@neustar.biz -----Original Message----- From: Stark, Barbara To: Andrew Newton; Rohan Mahy CC: Rosen, Brian; Ecrit@ietf.org Sent: Tue Jul 11 20:43:26 2006 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the = network operator does not control the specification of every device = connected to the network.": If the device has a DHCP client, the client MUST support RFC 3825 and = . and If the device supports LLDP-MED, it MUST support the "Location = Identification TLV" as defined in . Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED = spec), the 2nd if statement really doesn't say much. But it would also = suggest that devices that could have soft clients on them (PCs, PDAs) = also need to do that TLV when they do LLDP-MED. All router-type devices = that implement LLDP-MED are also required to support this TLV, per the = spec. Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also = reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP = INFORM message with options as described in RFC 3825 and , = when it is configured to use one of these alternate bootstrap methods = (e.g., PPPoE, PPPoA, static IP address). Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. = If a vendor can't justify putting one or the other of these into a = device (outside of recommendations in this BCP), then I say the protocol = doesn't belong in the device. If the device is going to have one or the = other, or both, then it needs to support the location determination = mechanism that goes with it. Since, for LLDP-MED, that's already a = requirement of the LLDP-MED spec, I really don't see a problem with = stating it here. Barbara -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us ] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp = draft wassubmitted) =20 =20 On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: To be clear, I do not have a strong feeling about what = does on Brian's list or not. I think LLDP-MED is a completely = reasonable thing for a wired phone vendor to implement on enterprise = class phones. Just throwing in my $0.0199997, I have not formed a strong = opinion about this either. It does seem reasonable for enterprise class = devices with ethernet jacks to implement LLPD-MED, or for devices of = category Y to implement method X... as what must be implemented by the = device will always be dictated by the network media it uses. Where this gets a little tricky is that if there is no one common = method, then devices may end up implementing things that are not = appropriate in an attempt to have devices that work in multiple network = environments... and even then they may end up missing the mark. = Therefore, one method that does work in all environments must be = implemented. And that is likely to be the L7-LCP. -andy ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 162 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------_=_NextPart_001_01C6A5C1.F4F2C4F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Great!

 

Therefore those limits are pure speculation at this time and since a brochette of experts will be = looking into this, we can be optimistic as of the = outcome.

 

If this is the case, I wonder if = all those discussions on a possible list of protocols at the end point would = become irrelevant since the L7 protocol would be in a position to work in all IP based = network, independent of the L2 on which it is riding on (I admit, this is pure speculation = from my part here…).

 

From an implementation perspective = (this is my primary concern as a broadband access operator AND VoIP service = provider in all market segments), this seems to be the most simplified model. = However, I wouldn’t go as far as restricting one to implement only a = protocol; I would say “MUST implement at least the [L7] protocol for location acquisition…”. As stated by Barbara, some other business = enablers may drive a network administrator to implement another one within its = specific environment (the LLDP case) with little incremental efforts and = resources.

 

For the applicability statement you = are suggesting, it should apply to all other candidates as well as they too = may have limits and security implications.

 

Guy Caron

Bell Canada

De : Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
Envoy=E9 : 12 = juillet 2006 09:55
=C0 : Caron, Guy = (A162859); peter_blatherwick@mitel.com
Cc : Barbara.Stark@bellsouth.com; Ecrit@ietf.org
Objet : RE: LLDP-MED = and Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted)

 

No, but I’ve proposed that = the design team craft an applicability statement for an abstract L7 location acquisition protocol that uses the IP address as the identifier, = together with the security implications of it, and ask the AD’s (including the = security AD’s) if that would be acceptable.  That idea seemed to find = favor as a way to figure out if the basic idea of using IP address as the = identifier will be acceptable, regardless of the protocol details.  I think we = will do that work within the next several weeks.

 

Brian

 

From: = g.caron@bell.ca [mailto:g.caron@bell.ca]
Sent: Wednesday, July 12, = 2006 9:51 AM
To: Rosen, Brian; peter_blatherwick@mitel.com
Cc: = Barbara.Stark@bellsouth.com; Ecrit@ietf.org
Subject: RE: LLDP-MED and = Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted)

 

Brian,

 

Can you be more precise on the = foreseen “applicability limits” of the yet to be L7 = protocol?

 

 

 

 

Guy Caron

Bell Canada

De : Rosen, Brian = [mailto:Brian.Rosen@neustar.biz]
Envoy=E9 : 12 = juillet 2006 09:21
=C0 : = peter_blatherwick@mitel.com
Cc : Barbara.Stark@bellsouth.com; Ecrit@ietf.org
Objet : RE: LLDP-MED = and Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted)

 

This thinking results in cases = where assumptions made by one end don’t match assumptions made by the = other.

 

Let’s take LLDP as the example.  Barbara would say that if the phone implements LLDP, then = it should implement LLDP-MED.  Okay, so suppose I have a residential = phone which does not implement LLDP, so it doesn’t implement = LLDP-MED.  So far, so good.  Now, let’s look at an enterprise = network.  It may implement LLDP, and thus LLDP-MED.  Okay, the enterprise phone = on the enterprise network works.  What happens when the residential phone connects to the enterprise network?  No location.  Let’s = keep going.  Suppose the residential phone implements DHCP, and thus implemented the DHCP location options.  Unless the network ALSO = implements DHCP location, it doesn’t work.  But if the enterprise = implements the DHCP mechanism, then the LLDP mechanism is superfluous. =

 

Now take the enterprise phone and = plug it into a home network, on an access network that does not meet the = applicability statement of the L7 mechanism.  That network deploys DHCP = location.  The enterprise phone can’t get location unless it also implements = DHCP.  Now take that same phone and plug it into a network that doesn’t = deploy DHCP but does meet the applicability statement for the L7 = protocol.  The enterprise phone ALSO has to implement the L7 = protocol.

 

The “implement the location mechanism corresponding to the configuration mechanism” simply = does not work.  You need a list, where one end implements ALL and the other = end implements “at least one of” to get interoperability.  = There is no other way.

 

It is not the case that the L7 = mechanism can be the single fall-back mechanism.  It will have an = applicability limit, and not all networks will meet it.  This is effectively true = of DHCP.  It would be true of LLDP if it was on the list.  It is = the reason why, in this case, it is the CLIENT that must implement ALL and = the server implement one of.  Usually, we have the server taking the “all” role and the client taking the “at least one = of” role.

 

Brian

 

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Wednesday, July 12, = 2006 8:05 AM
To: Rosen, Brian
Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; rohan.mahy@gmail.com
Subject: Re: LLDP-MED and = Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted)

 


Brian,
Counter-point to below is that if the device and network do not support mutually = agreeable configuration method, then the device is a brick anyway.  L7 = becomes a fall-back for the cases where the direct configuration method does not = support passing location through (best example seems to be home router on DSL or = cable modem).  
An important case, not sure well heard yesterday during meeting, was that = in an IPv6 environment with address autoconfig there may be no DHCP at all.  This may or may not be a small case as IPv6 rolls out, remains to = be seen.  And while IPv6 is not really important now in N.A. it is = very rapidly becoming important in Asia/Pac and also Australia (I'm told). =  Cannot ignore it.  
-- Peter

 

"Rosen, Brian" = <Brian.Rosen@neustar.biz>

11.07.06 20:56

       
        To:       =  <Barbara.Stark@bellsouth.com>, <andy@hxr.us>, <rohan.mahy@gmail.com>
        cc:       =  Ecrit@ietf.org
        Subject:        Re: LLDP-MED = and Phone BCP (Re: [Ecrit] New phonebcp draft        wassubmitted)




But unless = every phone supports LLDP-MED, then an enterprise must also implement DHCP (or = L7) in order to support those phones that don't support LLDP.  If every = access network has to support those 2, then LLDP is superfelous.

A residential phone may be plugged into an enterprise network. =  Ditto an enterprise phone.  Location acquisition has to work always. =  If there is a list, and one end must support all, with the other end must support = at least one, it always works.

I don't see how you can get around that
--------------------------
Brian Rosen
NeuStar
(724) 382-1051
brian.rosen@neustar.biz


-----Original Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan Mahy
CC: Rosen, Brian; = Ecrit@ietf.org
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where = the network operator does not control the specification of every device = connected to the network.":

If the device has a DHCP client, the client MUST support RFC 3825 and <dhcp-civil>.
  and
If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in <LLDP-MED reference>.

Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if = statement really doesn't say much. But it would also suggest that devices that = could have soft clients on them (PCs, PDAs) also need to do that TLV when they do LLDP-MED. All router-type devices that implement LLDP-MED are also = required to support this TLV, per the spec.

Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also reasonable. = However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP INFORM = message with options as described in RFC 3825 and <dhcp-civil>, when it is = configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, = static IP address).

Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. If a = vendor can't justify putting one or the other of these into a device (outside = of recommendations in this BCP), then I say the protocol doesn't belong in = the device. If the device is going to have one or the other, or both, then = it needs to support the location determination mechanism that goes with it. = Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really = don't see a problem with stating it here.
Barbara


       -----Original Message-----
       From: Andrew Newton [mailto:andy@hxr.us]
       Sent: Friday, June 30, 2006 9:44 AM
       To: Rohan Mahy
       Cc: Rosen, = Brian; Ecrit@ietf.org
       Subject: Re: LLDP-MED and Phone BCP (Re: = [Ecrit] New phonebcp draft wassubmitted)
     
     

       On Jun 29, 2006, at 6:29 PM, Rohan Mahy = wrote:


               To be clear, I do = not have a strong feeling about what does on Brian's list or not.  I = think LLDP-MED is a completely reasonable thing for a wired phone vendor to = implement on enterprise class phones.


       Just throwing in my $0.0199997, I have not = formed a strong opinion about this either.  It does seem reasonable for = enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices = of category Y to implement method X... as what must be implemented by the = device will always be dictated by the network media it uses.

       Where this gets a little tricky is that if = there is no one common method, then devices may end up implementing things that = are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark.  Therefore, one method that does work in all environments must be implemented.   And that is likely to be the L7-LCP.

       -andy

*****

The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or entities = other than the intended recipient is prohibited. If you received this in = error, please contact the sender and delete the material from all computers. = 162
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

=
------_=_NextPart_001_01C6A5C1.F4F2C4F0-- --===============1749450051== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1749450051==-- From ecrit-bounces@ietf.org Wed Jul 12 10:52:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0g4q-00059d-8M; Wed, 12 Jul 2006 10:52:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0g4o-00059X-RK for Ecrit@ietf.org; Wed, 12 Jul 2006 10:52:34 -0400 Received: from bellwecs2.bellnexxia.net ([207.236.237.114] helo=bellwecs2.srvr.bell.ca) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0g4n-0000WM-Fa for Ecrit@ietf.org; Wed, 12 Jul 2006 10:52:34 -0400 Received: (qmail 19970 invoked from network); 12 Jul 2006 14:52:33 -0000 Received: from g.caron@bell.ca by bellwecs2.srvr.bell.ca with EntrustECS-Server-7.4; 12 Jul 2006 14:52:33 -0000 Received: from bellwfep1.bellnexxia.net (HELO bellwfep1-srv.bellnexxia.net) (207.236.237.107) by bellwecs2.srvr.bell.ca with SMTP; 12 Jul 2006 14:52:32 -0000 Received: from toroondc550.bell.corp.bce.ca ([142.182.84.162]) by bellwfep1-srv.bellnexxia.net (InterMail vM.5.01.06.10 201-253-122-130-110-20040306) with ESMTP id <20060712145232.TCSP26320.bellwfep1-srv.bellnexxia.net@toroondc550.bell.corp.bce.ca>; Wed, 12 Jul 2006 10:52:32 -0400 Received: from toroondc912.bell.corp.bce.ca ([142.182.89.15]) by toroondc550.bell.corp.bce.ca with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 10:52:32 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) Date: Wed, 12 Jul 2006 10:52:31 -0400 Message-ID: <2E62ACF8ADDB4D4F89093CBFDF2FBAF3081AC7C5@toroondc912> In-Reply-To: <191BD98E-909D-4381-8D84-D3E2F4C61A38@cs.columbia.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) Thread-Index: AcalwHjF4QKCT78bQyWDGfPGszyQxgAAYPmg From: To: , X-OriginalArrivalTime: 12 Jul 2006 14:52:32.0465 (UTC) FILETIME=[CDFAEC10:01C6A5C2] X-Spam-Score: 0.2 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: Brian.Rosen@neustar.biz, Richard.Stastny@oefeg.at, Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Henning, VPN is indeed a concern that I hope, will be addressed by the L7 design = team. There are 2 statements in the = draft-tschofenig-geopriv-l7-lcp-ps-00 that leads me to believe that some = solution may be pointing out for that specific concern. Guy Caron Bell Canada -----Message d'origine----- De=A0: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Envoy=E9=A0: 12 juillet 2006 10:35 =C0=A0: Ted Hardie Cc=A0: Rosen, Brian; Stastny Richard; Ecrit@ietf.org Objet=A0: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New = phonebcpdraftwassubmitted) One of Brian's favorite topics and a limitation of L7 protocols: =20 VPNs. In those cases, you are unlikely to get to the right L7 server =20 or get it the right IP address. In those cases, lower-layer =20 solutions, such as LLDP-MED and DHCP are likely to be more reliable. Thus, I think as important as picking a list, is to also suggest the =20 sequence of things to try and whether to keep trying if you got an =20 answer (which may be wrong). In other words, if you got a location =20 via DHCP, should you also ask via L7? On Jul 12, 2006, at 10:25 AM, Ted Hardie wrote: > At 4:09 PM +0200 7/12/06, Stastny Richard wrote: >>> You need a list, where one end implements ALL and the other end =20 >>> implements "at least one of" to get interoperability. There is =20 >>> no >other way. >> >> Fully agree. A device needs to implement ALL possible mechanisms, =20 >> there is no other way, since you never know where a >> device is attached to. Period >> >> Richard >> > > My agreement with this depends a lot on what "possible" means. If =20 > someone defines a pppoe mechanisms, implementing it in a phone that =20 > doesn't support ethernet or pppoe is not useful. If you define =20 > that as "not a possible mechanism for that phone", then we're =20 > probably okay. But that sounds to me closer to what Barbara is =20 > saying than what Brian has said. > > I also believe we need to see the text Brian mentioned in the room =20 > yesterday for self-configuration. For some devices, self-=20 > configuration will be more accurate than the network-provided =20 > location received by many of these methods. But putting that into =20 > the list of mechanisms has some pretty interesting results. > > Last, the l7 question has two issues. First, if you have IP =20 > connectivity, will you be able to > reach an l7 server? The answer to that had better be yes, since =20 > reaching one and reaching a sip service have pretty similar =20 > properties. The other question is: will the l7 server be able to =20 > identify 1) you and 2) where you. I take it that Brian's primary =20 > concern is that it will not be possible to identify a client to =20 > the l7 server in ways that will work reliably in all =20 > environments. Until we get a little deeper I can't say, but I do =20 > have to question whether the effort to get to that point (so that =20 > there is single fallback mechanism) is really worse than every =20 > client implementing everything, where everything is a potentially =20 > growing list. > > Ted > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 12 11:53:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0h1j-0005r3-Lp; Wed, 12 Jul 2006 11:53:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0h1i-0005qy-DD for ecrit@ietf.org; Wed, 12 Jul 2006 11:53:26 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0h1f-0003TT-7J for ecrit@ietf.org; Wed, 12 Jul 2006 11:53:26 -0400 Received: from ([90.152.52.46]) by aismt07p.bellsouth.com with SMTP id KP-AXPTB.149226177; Wed, 12 Jul 2006 11:53:01 -0400 Received: from 01AL10015010161.ad.bls.com ([90.152.53.179]) by 01al10015010118.ad.bls.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 12 Jul 2006 10:53:02 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted) Date: Wed, 12 Jul 2006 10:53:01 -0500 Message-ID: <9888E1AA13C3A1459D122996A58C0E1107CA35AB@bre2k61p-55> X-MS-Has-Attach: Importance: normal Priority: normal X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Thread-Index: Acalq55JoAEvc/K+SqG8j4hdobdddQAB+KfwAAUYf3A= From: "Stark, Barbara" To: "Rosen, Brian" , X-OriginalArrivalTime: 12 Jul 2006 15:53:02.0235 (UTC) FILETIME=[417DDEB0:01C6A5CB] X-Spam-Score: 1.0 (+) X-Scan-Signature: d119718c9ef593f359a025ee0d2770e1 Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0469544441==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0469544441== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A5CB.412E296A" Content-Transfer-Encoding: 7bit This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A5CB.412E296A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think I'm starting to understand where we're losing each others' viewpoints. =20 We have the 2 basic types of networks (as defined in the BCP): (1) networks where the operator can specify what devices are allowed to connect to it, and (2) networks where the operator has no control over what connects. =20 Enterprise networks are generally the former. I know my corporate network guys would be extremely upset if I brought in a VoIP phone from home and tried to connect it through the corporate network. I think it's reasonable to suggest that an enterprise may choose to implement LLDP in its network, and would have the ability to require that all devices that connect to that network must also support LLDP. For devices intended to operate in these closed enterprise networks, LLDP is definitely an option. If vendors make CPE intended for these networks, and if the vendor implements LLDP, I think it's reasonable for this BCP to recommend that such LLDP-capable devices also do the LLDP-MED Location identification. =20 But for open networks, where any device that a consumer buys is expected to work (home networks behind broadband connections, small biz networks, hotspots), I don't think LLDP is viable at this time. I think Brian is right that hotels and hotspots and metropolitan mesh WiFi networks cannot expect devices to support LLDP, and therefore must implement either the DHCP or L7 mechanism. If they must implement one of these 2, then it makes no sense to suggest that they might do LLDP in addition to one of the others, just in case a device came along that could do LLDP-MED. If that device is truly intended to work in that open network, then it would also be able to do DHCP and L7. So why go to the extra work to do LLDP in the network? =20 So, I think that the statement about "If LLDP, then LLDP-MED Location ID is MUST" is completely applicable to devices intended for "closed" networks, but not "open" networks. The BCP already has verbiage that indicates devices intended for these different types of networks might have different requirements. I think we need to expand that and have clear lists of recommendations for devices on "closed" networks (where the operator still wants to use open standards), and for those intended to be connected through "open" networks.=20 Barbara -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Wednesday, July 12, 2006 9:21 AM To: peter_blatherwick@mitel.com Cc: andy@hxr.us; Stark, Barbara; Ecrit@ietf.org; rohan.mahy@gmail.com Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) This thinking results in cases where assumptions made by one end don't match assumptions made by the other. =20 Let's take LLDP as the example. Barbara would say that if the phone implements LLDP, then it should implement LLDP-MED. Okay, so suppose I have a residential phone which does not implement LLDP, so it doesn't implement LLDP-MED. So far, so good. Now, let's look at an enterprise network. It may implement LLDP, and thus LLDP-MED. Okay, the enterprise phone on the enterprise network works. What happens when the residential phone connects to the enterprise network? No location. Let's keep going. Suppose the residential phone implements DHCP, and thus implemented the DHCP location options. Unless the network ALSO implements DHCP location, it doesn't work. But if the enterprise implements the DHCP mechanism, then the LLDP mechanism is superfluous.=20 =20 Now take the enterprise phone and plug it into a home network, on an access network that does not meet the applicability statement of the L7 mechanism. That network deploys DHCP location. The enterprise phone can't get location unless it also implements DHCP. Now take that same phone and plug it into a network that doesn't deploy DHCP but does meet the applicability statement for the L7 protocol. The enterprise phone ALSO has to implement the L7 protocol. =20 The "implement the location mechanism corresponding to the configuration mechanism" simply does not work. You need a list, where one end implements ALL and the other end implements "at least one of" to get interoperability. There is no other way. =20 It is not the case that the L7 mechanism can be the single fall-back mechanism. It will have an applicability limit, and not all networks will meet it. This is effectively true of DHCP. It would be true of LLDP if it was on the list. It is the reason why, in this case, it is the CLIENT that must implement ALL and the server implement one of. Usually, we have the server taking the "all" role and the client taking the "at least one of" role. =20 Brian =20 _____ =20 From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Wednesday, July 12, 2006 8:05 AM To: Rosen, Brian Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; rohan.mahy@gmail.com Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) =20 Brian,=20 Counter-point to below is that if the device and network do not support mutually agreeable configuration method, then the device is a brick anyway. L7 becomes a fall-back for the cases where the direct configuration method does not support passing location through (best example seems to be home router on DSL or cable modem). =20 An important case, not sure well heard yesterday during meeting, was that in an IPv6 environment with address autoconfig there may be no DHCP at all. This may or may not be a small case as IPv6 rolls out, remains to be seen. And while IPv6 is not really important now in N.A. it is very rapidly becoming important in Asia/Pac and also Australia (I'm told). Cannot ignore it. =20 -- Peter=20 =20 "Rosen, Brian" =20 11.07.06 20:56=20 =20 To: , , =20 cc: Ecrit@ietf.org=20 Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) But unless every phone supports LLDP-MED, then an enterprise must also implement DHCP (or L7) in order to support those phones that don't support LLDP. If every access network has to support those 2, then LLDP is superfelous. A residential phone may be plugged into an enterprise network. Ditto an enterprise phone. Location acquisition has to work always. If there is a list, and one end must support all, with the other end must support at least one, it always works.=20 I don't see how you can get around that -------------------------- Brian Rosen NeuStar (724) 382-1051 brian.rosen@neustar.biz -----Original Message----- From: Stark, Barbara To: Andrew Newton; Rohan Mahy CC: Rosen, Brian; Ecrit@ietf.org Sent: Tue Jul 11 20:43:26 2006 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the network operator does not control the specification of every device connected to the network.": If the device has a DHCP client, the client MUST support RFC 3825 and . and If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in . Given that the Location Identification TLV is mandatory for all VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if statement really doesn't say much. But it would also suggest that devices that could have soft clients on them (PCs, PDAs) also need to do that TLV when they do LLDP-MED. All router-type devices that implement LLDP-MED are also required to support this TLV, per the spec. Since I'm really not at all concerned with the behavior of endpoints that don't have a DHCP client, I think the first if statement is also reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it SHOULD support being configured to request location through a DHCP INFORM message with options as described in RFC 3825 and , when it is configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static IP address). Anyway, I think both DHCP clients and LLDP-MED need to make it into devices based on all their merits, and not just on location discovery. If a vendor can't justify putting one or the other of these into a device (outside of recommendations in this BCP), then I say the protocol doesn't belong in the device. If the device is going to have one or the other, or both, then it needs to support the location determination mechanism that goes with it. Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really don't see a problem with stating it here. Barbara -----Original Message----- From: Andrew Newton [ mailto:andy@hxr.us] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) =20 =20 On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: To be clear, I do not have a strong feeling about what does on Brian's list or not. I think LLDP-MED is a completely reasonable thing for a wired phone vendor to implement on enterprise class phones. Just throwing in my $0.0199997, I have not formed a strong opinion about this either. It does seem reasonable for enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices of category Y to implement method X... as what must be implemented by the device will always be dictated by the network media it uses. Where this gets a little tricky is that if there is no one common method, then devices may end up implementing things that are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark. Therefore, one method that does work in all environments must be implemented. And that is likely to be the L7-LCP. -andy ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 118 ------_=_NextPart_001_01C6A5CB.412E296A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 think I'm starting to understand where we're losing each others'=20 viewpoints.
 
We=20 have the 2 basic types of networks (as defined in the BCP): (1) networks = where=20 the operator can specify what devices are allowed to connect to it, and = (2)=20 networks where the operator has no control over what=20 connects.
 
Enterprise networks are generally the former. I know my = corporate network=20 guys would be extremely upset if I brought in a VoIP phone from home and = tried=20 to connect it through the corporate network. I think it's reasonable to = suggest=20 that an enterprise may choose to implement LLDP in its network, and = would have=20 the ability to require that all devices that connect to that network = must also=20 support LLDP. For devices intended to operate in these closed enterprise = networks, LLDP is definitely an option. If vendors make CPE intended for = these=20 networks, and if the vendor implements LLDP, I think it's reasonable for = this=20 BCP to recommend that such LLDP-capable devices also do the LLDP-MED = Location=20 identification.
 
But=20 for open networks, where any device that a consumer buys is expected to = work=20 (home networks behind broadband connections, small biz networks, = hotspots), I=20 don't think LLDP is viable at this time. I think Brian is right that = hotels and=20 hotspots and metropolitan mesh WiFi networks cannot expect devices to = support=20 LLDP, and therefore must implement either the DHCP or L7 mechanism. If = they must=20 implement one of these 2, then it makes no sense to suggest that they = might do=20 LLDP in addition to one of the others, just in case a device came along = that=20 could do LLDP-MED. If that device is truly intended to work in that open = network, then it would also be able to do DHCP and L7. So why go to the = extra=20 work to do LLDP in the network?
 
So, I=20 think that the statement about "If LLDP, then LLDP-MED Location ID is = MUST" is=20 completely applicable to devices intended for "closed" networks, but not = "open"=20 networks. The BCP already has verbiage that indicates devices intended = for these=20 different types of networks might have different requirements. I think = we need=20 to expand that and have clear lists of recommendations for devices on = "closed"=20 networks (where the operator still wants to use open standards), and for = those=20 intended to be connected through "open" networks.
Barbara
-----Original Message-----
From: Rosen, Brian=20 [mailto:Brian.Rosen@neustar.biz]
Sent: Wednesday, July 12, = 2006 9:21=20 AM
To: peter_blatherwick@mitel.com
Cc: = andy@hxr.us; Stark,=20 Barbara; Ecrit@ietf.org; rohan.mahy@gmail.com
Subject: RE: = LLDP-MED=20 and Phone BCP (Re: [Ecrit] New phonebcp draft=20 wassubmitted)

This = thinking results=20 in cases where assumptions made by one end don’t match = assumptions made by the=20 other.

 

Let’s = take LLDP as=20 the example.  Barbara would say that if the phone implements = LLDP, then=20 it should implement LLDP-MED.  Okay, so suppose I have a = residential=20 phone which does not implement LLDP, so it doesn’t implement = LLDP-MED. =20 So far, so good.  Now, let’s look at an enterprise = network.  It may=20 implement LLDP, and thus LLDP-MED.  Okay, the enterprise phone on = the=20 enterprise network works.  What happens when the residential = phone=20 connects to the enterprise network?  No location.  = Let’s keep going.=20  Suppose the residential phone implements DHCP, and thus = implemented the=20 DHCP location options.  Unless the network ALSO implements DHCP = location,=20 it doesn’t work.  But if the enterprise implements the DHCP = mechanism,=20 then the LLDP mechanism is superfluous.

 

Now take = the=20 enterprise phone and plug it into a home network, on an access network = that=20 does not meet the applicability statement of the L7 mechanism.  = That=20 network deploys DHCP location.  The enterprise phone can’t = get location=20 unless it also implements DHCP.  Now take that same phone and = plug it=20 into a network that doesn’t deploy DHCP but does meet the = applicability=20 statement for the L7 protocol.  The enterprise phone ALSO has to=20 implement the L7 protocol.

 

The = “implement the=20 location mechanism corresponding to the configuration mechanism” = simply does=20 not work.  You need a list, where one end implements ALL and the = other=20 end implements “at least one of” to get = interoperability.  There is no=20 other way.

 

It is not = the case=20 that the L7 mechanism can be the single fall-back mechanism.  It = will=20 have an applicability limit, and not all networks will meet it.  = This is=20 effectively true of DHCP.  It would be true of LLDP if it was on = the=20 list.  It is the reason why, in this case, it is the CLIENT that = must=20 implement ALL and the server implement one of.  Usually, we have = the=20 server taking the “all” role and the client taking the = “at least one of”=20 role.

 

Brian

 

From:=20 peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] =
Sent: Wednesday, July 12, 2006 = 8:05=20 AM
To: = Rosen, Brian
Cc: andy@hxr.us;=20 Barbara.Stark@bellsouth.com; Ecrit@ietf.org; = rohan.mahy@gmail.com
Subject: Re: LLDP-MED and Phone = BCP (Re:=20 [Ecrit] New phonebcp draft = wassubmitted)

 


Brian,=20
Counter-point to = below is=20 that if the device and network do not support mutually agreeable = configuration=20 method, then the device is a brick anyway.  L7 becomes a = fall-back for=20 the cases where the direct configuration method does not support = passing=20 location through (best example seems to be home router on DSL or cable = modem).=20  
An important case, = not sure=20 well heard yesterday during meeting, was that in an IPv6 environment = with=20 address autoconfig there may be no DHCP at all.  This may or may = not be a=20 small case as IPv6 rolls out, remains to be seen.  And while IPv6 = is not=20 really important now in N.A. it is very rapidly becoming important in = Asia/Pac=20 and also Australia (I'm told). =  Cannot=20 ignore it.  
-- = Peter=20


 

"Rosen, Brian"=20 <Brian.Rosen@neustar.biz> =

11.07.06=20 20:56

    =    =20
  =    =20   To:      =20  <Barbara.Stark@bellsouth.com>, <andy@hxr.us>,=20 <rohan.mahy@gmail.com>
 =20       cc:      =20  Ecrit@ietf.org
 =20       Subject:        Re: = LLDP-MED=20 and Phone BCP (Re: [Ecrit] New phonebcp draft     =  =20 =  wassubmitted)




But unless every phone = supports LLDP-MED,=20 then an enterprise must also implement DHCP (or L7) in order to = support those=20 phones that don't support LLDP.  If every access network has to = support=20 those 2, then LLDP is superfelous.

A residential phone may be = plugged=20 into an enterprise network.  Ditto an enterprise phone. =  Location=20 acquisition has to work always.  If there is a list, and one end = must=20 support all, with the other end must support at least one, it always = works.=20

I don't see how you can get around=20 that
--------------------------
Brian Rosen
NeuStar
(724)=20 382-1051
brian.rosen@neustar.biz


-----Original=20 Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan = Mahy
CC:=20 Rosen, Brian;=20 Ecrit@ietf.org
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: = LLDP-MED and=20 Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

What = I'd like=20 to see in the doc would be:
For any device that's "intended to be = operated=20 on a network where the network operator does not control the = specification of=20 every device connected to the network.":

If the device has a = DHCP=20 client, the client MUST support RFC 3825 and = <dhcp-civil>.
 =20 and
If the device supports LLDP-MED, it MUST support the "Location=20 Identification TLV" as defined in <LLDP-MED = reference>.

Given=20 that the Location Identification TLV is mandatory for all VoIP-type = endpoints=20 implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if = statement=20 really doesn't say much. But it would also suggest that devices that = could=20 have soft clients on them (PCs, PDAs) also need to do that TLV when = they do=20 LLDP-MED. All router-type devices that implement LLDP-MED are also = required to=20 support this TLV, per the spec.

Since I'm really not at all = concerned=20 with the behavior of endpoints that don't have a DHCP client, I think = the=20 first if statement is also reasonable. However, I do recommend for = such=20 devices that:
If the device allows for bootstrapping methods other = than=20 DHCP, it SHOULD support being configured to request location through a = DHCP=20 INFORM message with options as described in RFC 3825 and = <dhcp-civil>,=20 when it is configured to use one of these alternate bootstrap methods = (e.g.,=20 PPPoE, PPPoA, static IP address).

Anyway, I think both DHCP = clients and=20 LLDP-MED need to make it into devices based on all their merits, and = not just=20 on location discovery. If a vendor can't justify putting one or the = other of=20 these into a device (outside of recommendations in this BCP), then I = say the=20 protocol doesn't belong in the device. If the device is going to have = one or=20 the other, or both, then it needs to support the location = determination=20 mechanism that goes with it. Since, for LLDP-MED, that's already a = requirement=20 of the LLDP-MED spec, I really don't see a problem with stating it=20 here.
Barbara


       -----Original=20 Message-----
       From: Andrew Newton=20 [mailto:andy@hxr.us]
       Sent: = Friday, June 30,=20 2006 9:44 AM
       To: Rohan Mahy
  =  =20    Cc: Rosen, = Brian;=20 Ecrit@ietf.org
       Subject: Re: LLDP-MED and = Phone=20 BCP (Re: [Ecrit] New phonebcp draft wassubmitted)
    =  =20
     

       On Jun 29, = 2006, at=20 6:29 PM, Rohan Mahy wrote:


        =  =20      To be clear, I do not have a strong feeling about = what=20 does on Brian's list or not.  I think LLDP-MED is a completely = reasonable=20 thing for a wired phone vendor to implement on enterprise class=20 phones.


       Just throwing in my = $0.0199997,=20 I have not formed a strong opinion about this either.  It does = seem=20 reasonable for enterprise class devices with ethernet jacks to = implement=20 LLPD-MED, or for devices of category Y to implement method X... as = what must=20 be implemented by the device will always be dictated by the network = media it=20 uses.

       Where this gets a little = tricky is=20 that if there is no one common method, then devices may end up = implementing=20 things that are not appropriate in an attempt to have devices that = work in=20 multiple network environments... and even then they may end up missing = the=20 mark.  Therefore, one method that does work in all environments = must be=20 implemented.   And that is likely to be the L7-LCP.

  =  =20    -andy

*****

The information transmitted is = intended=20 only for the person or entity to which it is addressed and may contain = confidential, proprietary, and/or privileged material. Any review,=20 retransmission, dissemination or other use of, or taking of any action = in=20 reliance upon this information by persons or entities other than the = intended=20 recipient is prohibited. If you received this in error, please contact = the=20 sender and delete the material from all computers. = 162
_______________________________________________
Ecrit=20 mailing=20 = list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. 118

 ------_=_NextPart_001_01C6A5CB.412E296A-- --===============0469544441== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0469544441==-- From ecrit-bounces@ietf.org Wed Jul 12 12:25:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hWp-0002Wp-6M; Wed, 12 Jul 2006 12:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hWn-0002Wk-2C for Ecrit@ietf.org; Wed, 12 Jul 2006 12:25:33 -0400 Received: from [205.151.208.34] (helo=fw.tr.xittelecom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0hWm-0004q9-Ns for Ecrit@ietf.org; Wed, 12 Jul 2006 12:25:33 -0400 Received: from [192.168.2.139] (helo=gestionfm) by fw.tr.xittelecom.com with esmtp (Exim 3.36 #1 (Debian)) id 1G0hZz-0003DH-00; Wed, 12 Jul 2006 12:28:51 -0400 From: "Francois D. Menard" To: "'Henning Schulzrinne'" , "'Ted Hardie'" Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) Date: Wed, 12 Jul 2006 12:25:34 -0400 Message-ID: <00ab01c6a5cf$cde09a60$8b02a8c0@gestionfm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 thread-index: AcalwIknVoZwJ3e5QkSOrTTLp+TRuQADpWDw In-Reply-To: <191BD98E-909D-4381-8D84-D3E2F4C61A38@cs.columbia.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: "'Rosen, Brian'" , 'Stastny Richard' , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think the case where you are in the hotel room with your ATA through = NAT is quite eloquent. The DSL NAT router employed by the hotel operator has to be intelligent enough to acquire location via PPPoE from the underlying operator (if it = was cable modem, it would get it via DHCP) and then present through its NAT STACK, a DHCP offer re-offering the same location tocken it acquired. = The Host grabbing location from its DHCP request has to communicate this information through the VPN software being launched on the host. The = VPN server at the far end, when allocating address should attempt to acquire location of its client before it presents a DHCP offer through the VPN = (or via PPP, or TLS, or whatever). =20 Basically, I think it is up to the VPN server to request the location of = the client prior to assigning its VPN IP address and telling what location = is associated with this IP address (which happens to be the same location = than the underlying location). Is there any better way? F. -- Fran=E7ois D. M=E9nard Charg=E9 de projet Xit t=E9l=E9com inc. 1350 rue Royale #800 Trois-Rivi=E8res, QC, G9A 4J4 Canada fmenard@xittelecom.com Tel: (819) 374-2556 ext. 268 Fax: (819) 374-0395 Cell: (819) 692-1383 =20 -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: 12 juillet 2006 10:35 To: Ted Hardie Cc: Rosen, Brian; Stastny Richard; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) One of Brian's favorite topics and a limitation of L7 protocols: =20 VPNs. In those cases, you are unlikely to get to the right L7 server or = get it the right IP address. In those cases, lower-layer solutions, such as LLDP-MED and DHCP are likely to be more reliable. Thus, I think as important as picking a list, is to also suggest the sequence of things to try and whether to keep trying if you got an = answer (which may be wrong). In other words, if you got a location via DHCP, = should you also ask via L7? On Jul 12, 2006, at 10:25 AM, Ted Hardie wrote: > At 4:09 PM +0200 7/12/06, Stastny Richard wrote: >>> You need a list, where one end implements ALL and the other end=20 >>> implements "at least one of" to get interoperability. There is no=20 >>> >other way. >> >> Fully agree. A device needs to implement ALL possible mechanisms,=20 >> there is no other way, since you never know where a device is=20 >> attached to. Period >> >> Richard >> > > My agreement with this depends a lot on what "possible" means. If=20 > someone defines a pppoe mechanisms, implementing it in a phone that=20 > doesn't support ethernet or pppoe is not useful. If you define that=20 > as "not a possible mechanism for that phone", then we're probably=20 > okay. But that sounds to me closer to what Barbara is saying than=20 > what Brian has said. > > I also believe we need to see the text Brian mentioned in the room=20 > yesterday for self-configuration. For some devices, self-=20 > configuration will be more accurate than the network-provided location = > received by many of these methods. But putting that into the list of=20 > mechanisms has some pretty interesting results. > > Last, the l7 question has two issues. First, if you have IP=20 > connectivity, will you be able to reach an l7 server? The answer to=20 > that had better be yes, since reaching one and reaching a sip service=20 > have pretty similar > properties. The other question is: will the l7 server be able to =20 > identify 1) you and 2) where you. I take it that Brian's primary=20 > concern is that it will not be possible to identify a client to the=20 > l7 server in ways that will work reliably in all environments. Until = > we get a little deeper I can't say, but I do have to question whether=20 > the effort to get to that point (so that there is single fallback=20 > mechanism) is really worse than every client implementing everything,=20 > where everything is a potentially growing list. > > Ted > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 12 12:44:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hom-0004P6-T7; Wed, 12 Jul 2006 12:44:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hom-0004P1-E7 for ecrit@ietf.org; Wed, 12 Jul 2006 12:44:08 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0hom-0005eo-0G for ecrit@ietf.org; Wed, 12 Jul 2006 12:44:08 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=RWATRO1.bbn.com) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1G0hok-0006Z0-5l; Wed, 12 Jul 2006 12:44:07 -0400 Message-Id: <5.1.0.14.2.20060712124226.03137880@127.0.0.1> X-Sender: rwatro@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 12 Jul 2006 12:46:54 -0400 To: "Tom-PT Taylor" From: Ron Watro Subject: Re: [Ecrit] Review of Security Threats Draft In-Reply-To: <44B504EC.1030607@nortel.com> References: <6.1.0.6.2.20060522065257.036212f0@po2.bbn.com> <6.1.0.6.2.20060522065257.036212f0@po2.bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb Cc: ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Thanks Tom. This looks good to me. After attending the GEOPRIV and ECRIT meetings yesterday, I have a better understanding of how the two groups are working together. At 10:19 AM 7/12/2006 -0400, Tom-PT Taylor wrote: >Responses below. I've made some changes in response. Thanks for your comments. > >Ron Watro wrote: >>Here are some brief comments on draft-ietf-ecrit-security-threats-01, >>dated April 17 2006 >>Good job by Tom to persevere through the various versions of this document. >>General comment: The current draft focuses on the security requirements >>for just the parts of the VoIP emergency response system that are ECRIT >>work items. Some of the previous incarnations of this document also >>included an overview of the full system security concept, so that one >>could see that the security being proposed for the ECRIT work items was >>consistent with at least one full-scale plan. At the interim meeting, it >>was decided to drop any discussion of system security as a whole. >>This decision was influenced by several issues, including the desire for >>ECRIT to make speedy progress and the lack of any consensus on the full >>system approach. There were some dissenting opinions at the interim >>meeting, arguing that a properly caveated, strawman view of the full >>system and its security concept was needed to provide a basis for the >>security services allocated to ECRIT work items. In any event, we >>currently have the version without the system view, and going forward we >>can expect comments asking why the component security requirements were >>not derived from a set of system security requirements (as is commonly done). > >[PTT] Already discussed, no action for the moment. >>Specific comments are below: >>Abstract >>--doubled "the" in the last sentence > >[PTT] Fixed. >>1 Introduction >>--suggest changing the two "must be" wordings in the 1st paragraph to "is >>being" . The marking idea and the mapping server are not the only >>feasible solutions to the problems at hand. >[PTT] Fixed. >>--mixture of commas and periods as list separators in the last paragraph >[PTT] This is prose, not a list. I combined the last three sections in one >run-on sentence because putting them into individual sentences would be >too boring. > >>4 Objectives of attackers >>--for the third bullet, it seems conceivable that a structured emergency >>service marker could help support the process of preventing fraudulent >>emergency calls (by assisting in track-back of the call, for example). >>In this case, there could be interaction with ECRIT work items > >[PTT] Wrong end of the stick. This is a potential solution based on ECRIT >work, rather than a potential problem created by ECRIT work. > >>--inconsistent punctuation at the end of bulleted items > >[PTT] Fixed, I think. >>5 Potential Attacks >>5.1 Identifier attacks >>--Is the emergency identifier known to be just a single bit, or could it >>contain data that can be use for other proposes (time stamp, >>cryptographic signature?) > >[PTT] Something that would be used for other purposes should be a separate >field. It is bad protocol design to overload individual fields. > >>--You say that theft-of-service calls most probably will not include any >>location information - but wouldn't they mostly likely include falsified >>location information so that they look legit but cannot be tracked back >>to the source? > >[PTT] Fixed as discussed in another E-mail (by mentioning additional >possibility of false data). >>6 Security requirements >>from section 5.1 fraudulent calls >>--How will a URI be verified as a PSAP? Will the mapping server be used >>or is this a non-ECRIT security requirement? > >[PTT] This is in the realm of solution, hence out of scope. However, I >visualize a database listing every PSAP URI in the world. It seems to me >there is an obvious relationship to the mapping service. > >>--Are long distance calls to remote PSAPs always fraudulent? For >>example, a disreputable foreign entity might set up a phony PSAP for its >>people to call. Can a service provider refuse to carry or perhaps >>reroute a long distance emergency request? > >[PTT] No, one can easily imagine use cases where long distance calls are >legitimate -- typically third party reports of emergencies. >>from section 5.2.1 impersonation of the mapping server >>--mapping server discovery is apparently outside the scope of ECRIT >>topic, so does ECRIT simply assume that this will be done in a secure manner? > >[PTT] The security I-D does state a requirement: > > "Requirement: the security considerations for any discussion of > mapping server discovery MUST address measures to prevent > impersonation of the mapping server." > >>--will the protocol allow exchange with unauthenticated servers if no >>authenticated ones can be found? > >[PTT] That's policy, I assume. The requirement is phrased in the opposite >sense, that authentication must be possible. > >>--does it ever make sense to return mapping server audit data to the >>client? Is this data encrypted to make it inaccessible by the client? >>Is this design intended to address rogue servers? If not, then why not >>just store the data on the server? > >[PTT] I think you make a valid point. First off, to be clear, the measure >is aimed at the case of a legitimate (not rogue) mapping server that has >errors in its database. The requirement was stated the way it was because >I figured identification of these errors needed the cooperation of the >client. But I was assuming a particular solution that I don't think will work. > >I rephrased to be less directive: > >"Requirement: the protocol SHOULD include information in the response that >allows subsequent correlation of that response with internal logs that may >be kept on the mapping server, to allow debugging of mis-directed calls. >One example of a way to meet this requirement would be by means of an >opaque parameter in the returned URI." >>from section 5.2.3 snooping attack >>-- the protocol or system must provide confidentiality mechanisms but the >>mapping server should respond to non-complaint clients with unprotected >>data if that is the only option > >[PTT] I think the draft is talking about mandatory-to-implement >capabilities. Local policy will undoubtedly accommodate non-compliant >clients, but we've had this discussion in various forms before and have >decided that the security considerations document should take a firm line. >>Final comment: Any concern about "insider attack" -- rogue PSAPs, SIP >>proxies, etc? > >[PTT] Legitimate concern, but in scope only to the extent dealt with in >terms of DOS attacks on mapping server. >>Ron Watro >> >> >> >> >> >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 12 12:46:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hqz-0004dB-38; Wed, 12 Jul 2006 12:46:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0hqx-0004d5-4y for Ecrit@ietf.org; Wed, 12 Jul 2006 12:46:23 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0hqw-0005mT-4j for Ecrit@ietf.org; Wed, 12 Jul 2006 12:46:23 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 7F35220025; Wed, 12 Jul 2006 12:46:21 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06942-01-9; Wed, 12 Jul 2006 12:46:20 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id F2053200B2; Wed, 12 Jul 2006 12:46:00 -0400 (EDT) To: "Rosen, Brian" Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: peter_blatherwick@mitel.com Date: Wed, 12 Jul 2006 12:44:35 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 07/12/2006 12:45:59 PM, Serialize complete at 07/12/2006 12:45:59 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.8 (/) X-Scan-Signature: 9724479da43a8325ad975c1a9b841870 Cc: Barbara.Stark@bellsouth.com, Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0548372840==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0548372840== Content-Type: multipart/alternative; boundary="=_alternative 005BF84A852571A9_=" This is a multipart message in MIME format. --=_alternative 005BF84A852571A9_= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi again,=20 I think you miss the point I'm trying to make, quite possibly my=20 not-so-good wording of it. Logic I read into Barbara's comment comes to: IF config method X is supported,=20 THEN MUST support corresponding location method X,=20 Fallback to L7 if none found.=20 In your examples below, if the phone does not support DHCP at all, but=20 does support LLDP-MED, it would not implement DHCP location discovery=20 (duh) but would also be completely non-functional in any network that only = provided DHCP configuration (notable example being IPv6 w. address=20 autoconfig). If an enterprise network allows non-sanctioned endpoints (eg = home devices) to be connected at all, but prefers LLDP for location and a=20 bunch of other reasons, then yes, they would need to either i) suffer the=20 pain providing both DHCP and LLDP, or ii) simply choose to disallow access = to those devices without the one method they want to use for location.=20 (Remember 802.1X is getting quite pervasive in enterprise, and using LLDP=20 it is quite easy to simply not supply a usable VLAN to non -MED / non=20 802.1X authorized devices, resulting in effective quarantine.) Those=20 phones that want to be usable in every possible environment would need to=20 support all methods.=20 I think the result would effectively wind up being the same MUST list,=20 since I cannot imagine a phone not implementing DHCP in foreseeable=20 future, and also expect LLDP will be effective commercial MUST for=20 enterprise (not for non-enterprise, maybe). However I think it would be=20 far easier to maintain as a document process if we can find some way to=20 tie support to the configuration methods already used by the device.=20 (I also note that the text consumed in this thread is probably now longer=20 than code for an LLDP-MED phone implementation. >;-) -- Peter "Rosen, Brian" 12.07.06 09:20 =20 To: cc: , , ,=20 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebc= p draft wassubmitted) This thinking results in cases where assumptions made by one end don't=20 match assumptions made by the other. =20 Let's take LLDP as the example. Barbara would say that if the phone=20 implements LLDP, then it should implement LLDP-MED. Okay, so suppose I=20 have a residential phone which does not implement LLDP, so it doesn't=20 implement LLDP-MED. So far, so good. Now, let's look at an enterprise=20 network. It may implement LLDP, and thus LLDP-MED. Okay, the enterprise=20 phone on the enterprise network works. What happens when the residential=20 phone connects to the enterprise network? No location. Let's keep going. = Suppose the residential phone implements DHCP, and thus implemented the=20 DHCP location options. Unless the network ALSO implements DHCP location,=20 it doesn't work. But if the enterprise implements the DHCP mechanism,=20 then the LLDP mechanism is superfluous.=20 =20 Now take the enterprise phone and plug it into a home network, on an=20 access network that does not meet the applicability statement of the L7=20 mechanism. That network deploys DHCP location. The enterprise phone=20 can't get location unless it also implements DHCP. Now take that same=20 phone and plug it into a network that doesn't deploy DHCP but does meet=20 the applicability statement for the L7 protocol. The enterprise phone=20 ALSO has to implement the L7 protocol. =20 The "implement the location mechanism corresponding to the configuration=20 mechanism" simply does not work. You need a list, where one end=20 implements ALL and the other end implements "at least one of" to get=20 interoperability. There is no other way. =20 It is not the case that the L7 mechanism can be the single fall-back=20 mechanism. It will have an applicability limit, and not all networks will = meet it. This is effectively true of DHCP. It would be true of LLDP if=20 it was on the list. It is the reason why, in this case, it is the CLIENT=20 that must implement ALL and the server implement one of. Usually, we have = the server taking the "all" role and the client taking the "at least one=20 of" role. =20 Brian =20 From: peter=5Fblatherwick@mitel.com [mailto:peter=5Fblatherwick@mitel.com] = Sent: Wednesday, July 12, 2006 8:05 AM To: Rosen, Brian Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org;=20 rohan.mahy@gmail.com Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubm= itted) =20 Brian,=20 Counter-point to below is that if the device and network do not support=20 mutually agreeable configuration method, then the device is a brick=20 anyway. L7 becomes a fall-back for the cases where the direct=20 configuration method does not support passing location through (best=20 example seems to be home router on DSL or cable modem). =20 An important case, not sure well heard yesterday during meeting, was that=20 in an IPv6 environment with address autoconfig there may be no DHCP at=20 all. This may or may not be a small case as IPv6 rolls out, remains to be = seen. And while IPv6 is not really important now in N.A. it is very=20 rapidly becoming important in Asia/Pac and also Australia (I'm told).=20 Cannot ignore it. =20 -- Peter=20 =20 "Rosen, Brian" =20 11.07.06 20:56=20 =20 To: , ,=20 =20 cc: Ecrit@ietf.org=20 Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New=20 phonebcp draft wassubmitted) But unless every phone supports LLDP-MED, then an enterprise must also=20 implement DHCP (or L7) in order to support those phones that don't support = LLDP. If every access network has to support those 2, then LLDP is=20 superfelous. A residential phone may be plugged into an enterprise network. Ditto an=20 enterprise phone. Location acquisition has to work always. If there is a = list, and one end must support all, with the other end must support at=20 least one, it always works.=20 I don't see how you can get around that -------------------------- Brian Rosen NeuStar (724) 382-1051 brian.rosen@neustar.biz -----Original Message----- From: Stark, Barbara To: Andrew Newton; Rohan Mahy CC: Rosen, Brian; Ecrit@ietf.org Sent: Tue Jul 11 20:43:26 2006 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft=20 wassubmitted) What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the=20 network operator does not control the specification of every device=20 connected to the network.": If the device has a DHCP client, the client MUST support RFC 3825 and=20 . and If the device supports LLDP-MED, it MUST support the "Location=20 Identification TLV" as defined in . Given that the Location Identification TLV is mandatory for all VoIP-type=20 endpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd=20 if statement really doesn't say much. But it would also suggest that=20 devices that could have soft clients on them (PCs, PDAs) also need to do=20 that TLV when they do LLDP-MED. All router-type devices that implement=20 LLDP-MED are also required to support this TLV, per the spec. Since I'm really not at all concerned with the behavior of endpoints that=20 don't have a DHCP client, I think the first if statement is also=20 reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it SHOULD=20 support being configured to request location through a DHCP INFORM message = with options as described in RFC 3825 and , when it is=20 configured to use one of these alternate bootstrap methods (e.g., PPPoE,=20 PPPoA, static IP address). Anyway, I think both DHCP clients and LLDP-MED need to make it into=20 devices based on all their merits, and not just on location discovery. If=20 a vendor can't justify putting one or the other of these into a device=20 (outside of recommendations in this BCP), then I say the protocol doesn't=20 belong in the device. If the device is going to have one or the other, or=20 both, then it needs to support the location determination mechanism that=20 goes with it. Since, for LLDP-MED, that's already a requirement of the=20 LLDP-MED spec, I really don't see a problem with stating it here. Barbara -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) =20 =20 On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: To be clear, I do not have a strong feeling about what does = on Brian's list or not. I think LLDP-MED is a completely reasonable thing = for a wired phone vendor to implement on enterprise class phones. Just throwing in my $0.0199997, I have not formed a strong opinion=20 about this either. It does seem reasonable for enterprise class devices=20 with ethernet jacks to implement LLPD-MED, or for devices of category Y to = implement method X... as what must be implemented by the device will=20 always be dictated by the network media it uses. Where this gets a little tricky is that if there is no one common=20 method, then devices may end up implementing things that are not=20 appropriate in an attempt to have devices that work in multiple network=20 environments... and even then they may end up missing the mark. Therefore, = one method that does work in all environments must be implemented. And=20 that is likely to be the L7-LCP. -andy ***** The information transmitted is intended only for the person or entity to=20 which it is addressed and may contain confidential, proprietary, and/or=20 privileged material. Any review, retransmission, dissemination or other=20 use of, or taking of any action in reliance upon this information by=20 persons or entities other than the intended recipient is prohibited. If=20 you received this in error, please contact the sender and delete the=20 material from all computers. 162 =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 005BF84A852571A9_= Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi again,  

I think you miss the point I'm tryin= g to make, quite possibly my not-so-good wording of it.  Logic I read = into Barbara's comment comes to:
   IF config method X is s= upported,
      THEN MUST suppo= rt corresponding location method X,
   Fallback to L7 if none = found.  

In your examples below, if the phone= does not support DHCP at all, but does support LLDP-MED, it would not impl= ement DHCP location discovery (duh) but would also be completely non-functi= onal in any network that only provided DHCP configuration (notable example = being IPv6 w. address autoconfig).  If an enterprise network allows no= n-sanctioned endpoints (eg home devices) to be connected at all, but prefer= s LLDP for location and a bunch of other reasons, then yes, they would need= to either i) suffer the pain providing both DHCP and LLDP, or ii) simply c= hoose to disallow access to those devices without the one method they want = to use for location.  (Remember 802.1X is getting quite pervasive in e= nterprise, and using LLDP it is quite easy to simply not supply a usable VL= AN to non -MED / non 802.1X authorized devices, resulting in effective quar= antine.)   Those phones that want to be usable in every possible envir= onment would need to support all methods.  

I think the result would effectively= wind up being the same MUST list, since I cannot imagine a phone not imple= menting DHCP in foreseeable future, and also expect LLDP will be effective = commercial MUST for enterprise (not for non-enterprise, maybe).  Howev= er I think it would be far easier to maintain as a document process if we c= an find some way to tie support to the configuration methods already used b= y the device.  

(I also note that the text consumed = in this thread is probably now longer than code for an LLDP-MED phone imple= mentation.  >;-)

-- Peter




"Rosen, Brian" <Bria= n.Rosen@neustar.biz>

12.07.06 09:20

       
        To: &nbs= p;      <peter=5Fblatherwick@mitel.com>
        cc: &nbs= p;      <andy@hxr.us>, <Barbara.Stark@bellsouth.com= >, <Ecrit@ietf.org>, <rohan.mahy@gmail.com>
        Subject:=        RE: LLDP-MED and Phone BCP (Re: [Ecrit] New pho= nebcp draft        wassubmitted)



This thinking results in = cases where assumptions made by one end don't match assumptions made by the= other.
 
Let's take LLDP as the ex= ample.  Barbara would say that if the phone implements LLDP, then it s= hould implement LLDP-MED.  Okay, so suppose I have a residential phone= which does not implement LLDP, so it doesn't implement LLDP-MED.  So = far, so good.  Now, let's look at an enterprise network.  It may = implement LLDP, and thus LLDP-MED.  Okay, the enterprise phone on the = enterprise network works.  What happens when the residential phone con= nects to the enterprise network?  No location.  Let's keep going.=  Suppose the residential phone implements DHCP, and thus implemented = the DHCP location options.  Unless the network ALSO implements DHCP lo= cation, it doesn't work.  But if the enterprise implements the DHCP me= chanism, then the LLDP mechanism is superfluous.
 
Now take the enterprise p= hone and plug it into a home network, on an access network that does not me= et the applicability statement of the L7 mechanism.  That network depl= oys DHCP location.  The enterprise phone can't get location unless it = also implements DHCP.  Now take that same phone and plug it into a net= work that doesn't deploy DHCP but does meet the applicability statement for= the L7 protocol.  The enterprise phone ALSO has to implement the L7 p= rotocol.
 
The "implement the locati= on mechanism corresponding to the configuration mechanism" simply does not = work.  You need a list, where one end implements ALL and the other end= implements "at least one of" to get interoperability.  There is no ot= her way.
 
It is not the case that t= he L7 mechanism can be the single fall-back mechanism.  It will have a= n applicability limit, and not all networks will meet it.  This is eff= ectively true of DHCP.  It would be true of LLDP if it was on the list= .  It is the reason why, in this case, it is the CLIENT that must impl= ement ALL and the server implement one of.  Usually, we have the serve= r taking the "all" role and the client taking the "at least one of" role.
 
Brian
 


From: peter=5Fblatherwick@mitel.c= om [mailto:peter=5Fblatherwick@mitel.com]
Sent: Wednesday, July 12, 2006 8:05 AM
To: Rosen, Brian
Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; rohan.mah= y@gmail.com
Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was= submitted)
 

Brian,
Counter-point to below is that if the device and network do not support mut= ually agreeable configuration method, then the device is a brick anyway. &n= bsp;L7 becomes a fall-back for the cases where the direct configuration met= hod does not support passing location through (best example seems to be hom= e router on DSL or cable modem).  
An important case, not sure well heard yesterday during meeting, was that i= n an IPv6 environment with address autoconfig there may be no DHCP at all. =  This may or may not be a small case as IPv6 rolls out, remains to be = seen.  And while IPv6 is not really important now in N.A. it is very r= apidly becoming important in Asia/Pac and also Australia (I'm told).  = Cannot ignore it.  
-- Peter

  "Rosen, Brian&qu= ot; <Brian.Rosen@neustar.biz>

11.07.06 20:56

        <= /font>
       To:        <Barbara.Star= k@bellsouth.com>, <andy@hxr.us>, <rohan.mahy@gmail.com>
       cc:        Ecrit@ietf.org
       Subject:        Re: LLDP-ME= D and Phone BCP (Re: [Ecrit] New phonebcp draft        = wassubmitted)




But unless every phone supports LLDP-MED, then an enterprise must also impl= ement DHCP (or L7) in order to support those phones that don't support LLDP= .  If every access network has to support those 2, then LLDP is superf= elous.

A residential phone may be plugged into an enterprise network.  Ditto = an enterprise phone.  Location acquisition has to work always.  I= f there is a list, and one end must support all, with the other end must su= pport at least one, it always works.

I don't see how you can get around that
--------------------------
Brian Rosen
NeuStar
(724) 382-1051
brian.rosen@neustar.biz


-----Original Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan Mahy
CC: Rosen, Brian; Ecrit@ietf.org
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubm= itted)

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where the = network operator does not control the specification of every device connect= ed to the network.":

If the device has a DHCP client, the client MUST support RFC 3825 and <d= hcp-civil>.
 and
If the device supports LLDP-MED, it MUST support the "Location Identif= ication TLV" as defined in <LLDP-MED reference>.

Given that the Location Identification TLV is mandatory for all VoIP-type e= ndpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if= statement really doesn't say much. But it would also suggest that devices = that could have soft clients on them (PCs, PDAs) also need to do that TLV w= hen they do LLDP-MED. All router-type devices that implement LLDP-MED are a= lso required to support this TLV, per the spec.

Since I'm really not at all concerned with the behavior of endpoints that d= on't have a DHCP client, I think the first if statement is also reasonable.= However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it SHOULD s= upport being configured to request location through a DHCP INFORM message w= ith options as described in RFC 3825 and <dhcp-civil>, when it is con= figured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA= , static IP address).

Anyway, I think both DHCP clients and LLDP-MED need to make it into devices= based on all their merits, and not just on location discovery. If a vendor= can't justify putting one or the other of these into a device (outside of = recommendations in this BCP), then I say the protocol doesn't belong in the= device. If the device is going to have one or the other, or both, then it = needs to support the location determination mechanism that goes with it. Si= nce, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I rea= lly don't see a problem with stating it here.
Barbara


      -----Original Message-----
      From: Andrew Newton [mailto:andy@hxr= .us]
      Sent: Friday, June 30, 2006 9:44 AM
      To: Rohan Mahy
      Cc: Rosen, Brian; Ecrit@ietf.org
      Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New = phonebcp draft wassubmitted)
     
     

      On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote:


              To be clear, I do not hav= e a strong feeling about what does on Brian's list or not.  I think LL= DP-MED is a completely reasonable thing for a wired phone vendor to impleme= nt on enterprise class phones.


      Just throwing in my $0.0199997, I have not formed a s= trong opinion about this either.  It does seem reasonable for enterpri= se class devices with ethernet jacks to implement LLPD-MED, or for devices = of category Y to implement method X... as what must be implemented by the d= evice will always be dictated by the network media it uses.

      Where this gets a little tricky is that if there is n= o one common method, then devices may end up implementing things that are n= ot appropriate in an attempt to have devices that work in multiple network = environments... and even then they may end up missing the mark.  There= fore, one method that does work in all environments must be implemented. &n= bsp; And that is likely to be the L7-LCP.

      -andy

*****

The information transmitted is intended only for the person or entity to wh= ich it is addressed and may contain confidential, proprietary, and/or privi= leged material. Any review, retransmission, dissemination or other use of, = or taking of any action in reliance upon this information by persons or ent= ities other than the intended recipient is prohibited. If you received this= in error, please contact the sender and delete the material from all compu= ters. 162
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--=_alternative 005BF84A852571A9_=-- --===============0548372840== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0548372840==-- From ecrit-bounces@ietf.org Wed Jul 12 12:57:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0i20-0005S1-Fy; Wed, 12 Jul 2006 12:57:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0i1z-0005Rv-Q4 for Ecrit@ietf.org; Wed, 12 Jul 2006 12:57:47 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0i1z-0006I5-9v for Ecrit@ietf.org; Wed, 12 Jul 2006 12:57:47 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 1585F2007E; Wed, 12 Jul 2006 12:57:47 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08449-06-10; Wed, 12 Jul 2006 12:57:45 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 601F92007F; Wed, 12 Jul 2006 12:57:39 -0400 (EDT) To: Henning Schulzrinne Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: peter_blatherwick@mitel.com Date: Wed, 12 Jul 2006 12:50:17 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 07/12/2006 12:57:37 PM, Serialize complete at 07/12/2006 12:57:37 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.8 (/) X-Scan-Signature: ccfb4541e989aa743998098cd315d0fd Cc: "Rosen, Brian" , Stastny Richard , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1193137146==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1193137146== Content-Type: multipart/alternative; boundary="=_alternative 005C7EC1852571A9_=" This is a multipart message in MIME format. --=_alternative 005C7EC1852571A9_= Content-Type: text/plain; charset="us-ascii" Hi Henning, YES, ordering of which method to use is an excellent point! I would encourage using whichever method is supplied, selecting one only, in order of most reliable first. -- Peter Henning Schulzrinne 12.07.06 10:35 To: Ted Hardie cc: "Rosen, Brian" , Stastny Richard , Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) One of Brian's favorite topics and a limitation of L7 protocols: VPNs. In those cases, you are unlikely to get to the right L7 server or get it the right IP address. In those cases, lower-layer solutions, such as LLDP-MED and DHCP are likely to be more reliable. Thus, I think as important as picking a list, is to also suggest the sequence of things to try and whether to keep trying if you got an answer (which may be wrong). In other words, if you got a location via DHCP, should you also ask via L7? On Jul 12, 2006, at 10:25 AM, Ted Hardie wrote: > At 4:09 PM +0200 7/12/06, Stastny Richard wrote: >>> You need a list, where one end implements ALL and the other end >>> implements "at least one of" to get interoperability. There is >>> no >other way. >> >> Fully agree. A device needs to implement ALL possible mechanisms, >> there is no other way, since you never know where a >> device is attached to. Period >> >> Richard >> > > My agreement with this depends a lot on what "possible" means. If > someone defines a pppoe mechanisms, implementing it in a phone that > doesn't support ethernet or pppoe is not useful. If you define > that as "not a possible mechanism for that phone", then we're > probably okay. But that sounds to me closer to what Barbara is > saying than what Brian has said. > > I also believe we need to see the text Brian mentioned in the room > yesterday for self-configuration. For some devices, self- > configuration will be more accurate than the network-provided > location received by many of these methods. But putting that into > the list of mechanisms has some pretty interesting results. > > Last, the l7 question has two issues. First, if you have IP > connectivity, will you be able to > reach an l7 server? The answer to that had better be yes, since > reaching one and reaching a sip service have pretty similar > properties. The other question is: will the l7 server be able to > identify 1) you and 2) where you. I take it that Brian's primary > concern is that it will not be possible to identify a client to > the l7 server in ways that will work reliably in all > environments. Until we get a little deeper I can't say, but I do > have to question whether the effort to get to that point (so that > there is single fallback mechanism) is really worse than every > client implementing everything, where everything is a potentially > growing list. > > Ted > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 005C7EC1852571A9_= Content-Type: text/html; charset="us-ascii"
Hi Henning,

YES, ordering of which method to use is an excellent point!  I would encourage using whichever method is supplied, selecting one only, in order of most reliable first.  

-- Peter



Henning Schulzrinne <hgs@cs.columbia.edu>

12.07.06 10:35

       
        To:        Ted Hardie <hardie@qualcomm.com>
        cc:        "Rosen, Brian" <Brian.Rosen@neustar.biz>, Stastny Richard <Richard.Stastny@oefeg.at>, Ecrit@ietf.org
        Subject:        Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft        wassubmitted)



One of Brian's favorite topics and a limitation of L7 protocols:  
VPNs. In those cases, you are unlikely to get to the right L7 server  
or get it the right IP address. In those cases, lower-layer  
solutions, such as LLDP-MED and DHCP are likely to be more reliable.

Thus, I think as important as picking a list, is to also suggest the  
sequence of things to try and whether to keep trying if you got an  
answer (which may be wrong). In other words, if you got a location  
via DHCP, should you also ask via L7?


On Jul 12, 2006, at 10:25 AM, Ted Hardie wrote:

> At 4:09 PM +0200 7/12/06, Stastny Richard wrote:
>>> You need a list, where one end implements ALL and the other end  
>>> implements "at least one of" to get interoperability.  There is  
>>> no >other way.
>>
>> Fully agree. A device needs to implement ALL possible mechanisms,  
>> there is no other way, since you never know where a
>> device is attached to. Period
>>
>> Richard
>>
>
> My agreement with this depends a lot on what "possible" means.  If  
> someone defines a pppoe mechanisms, implementing it in a phone that  
> doesn't support ethernet or pppoe is  not useful.  If you define  
> that as "not a possible mechanism for that phone", then we're  
> probably okay.  But that sounds to me closer to what Barbara is  
> saying than what Brian has said.
>
> I also believe we need to see the text Brian mentioned in the room  
> yesterday for self-configuration.  For some devices, self-
> configuration will be more accurate than the network-provided  
> location received by many of these methods.  But putting that into  
> the list of mechanisms has some pretty interesting results.
>
> Last, the l7 question has two issues.  First, if you have IP  
> connectivity, will you be able to
> reach an l7 server?  The answer to that had better be yes, since  
> reaching one and reaching a sip service have pretty similar  
> properties.   The other question is: will the l7 server be able to  
> identify 1) you and 2) where you.  I take it that Brian's primary  
> concern is that it  will not be possible to identify a client to  
> the l7 server in ways  that will work reliably in all  
> environments.  Until we get a little deeper I can't say, but I do  
> have to question whether the effort to get to that point (so that  
> there is single fallback mechanism) is really worse than every  
> client implementing everything, where everything is a potentially  
> growing list.
>
>                                                                     Ted
>
> _______________________________________________
> Ecrit mailing list
> Ecrit@ietf.org
> https://www1.ietf.org/mailman/listinfo/ecrit


_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--=_alternative 005C7EC1852571A9_=-- --===============1193137146== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1193137146==-- From ecrit-bounces@ietf.org Wed Jul 12 13:34:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ibE-0008RV-UI; Wed, 12 Jul 2006 13:34:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0ibD-0008RP-I1 for Ecrit@ietf.org; Wed, 12 Jul 2006 13:34:11 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0ibD-0000Lh-8L for Ecrit@ietf.org; Wed, 12 Jul 2006 13:34:11 -0400 Received: from [132.219.26.162] (h1aa2-net84db.lab.risq.net [132.219.26.162] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6CHXr7R007741 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Wed, 12 Jul 2006 13:33:57 -0400 (EDT) In-Reply-To: <9888E1AA13C3A1459D122996A58C0E1107CA35AB@bre2k61p-55> References: <9888E1AA13C3A1459D122996A58C0E1107CA35AB@bre2k61p-55> Mime-Version: 1.0 (Apple Message framework v752.2) Message-Id: From: Henning Schulzrinne Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted) Date: Wed, 12 Jul 2006 13:33:52 -0400 To: "Stark, Barbara" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.1 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: "Rosen, Brian" , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0677665454==" Errors-To: ecrit-bounces@ietf.org --===============0677665454== Content-Type: multipart/alternative; boundary=Apple-Mail-1-472257537 --Apple-Mail-1-472257537 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Jul 12, 2006, at 11:53 AM, Stark, Barbara wrote: > I think I'm starting to understand where we're losing each others' > viewpoints. > > We have the 2 basic types of networks (as defined in the BCP): (1) > networks where the operator can specify what devices are allowed to > connect to it, and (2) networks where the operator has no control > over what connects. > > Enterprise networks are generally the former. I know my corporate > network guys would be extremely upset if I brought in a VoIP phone > from home and tried to connect it through the corporate network. I > think it's reasonable to suggest that an enterprise may choose to > implement LLDP in its network, and would have the ability to > require that all devices that connect to that network must also > support LLDP. For devices intended to operate in these closed > enterprise networks, LLDP is definitely an option. If vendors make > CPE intended for these networks, and if the vendor implements LLDP, > I think it's reasonable for this BCP to recommend that such LLDP- > capable devices also do the LLDP-MED Location identification. > I'm not sure about "most", but I think your estimate of control might be slightly idealistic. Many large networks, such as university networks, routinely have people plug in essentially random devices. We have probably 50,000 such devices on our network, and Columbia is, at best, a mid-size university. I suspect that the same is true for most school systems and at least some Ethernet VLANs in many companies. In many networks, in theory the sys admins has control, in practice people still plug in what they like. Also, Ethernet networks are becoming increasingly popular in multi- family residences, such as apartment buildings. From what I hear, that model is quite common in South Korea, for example. In general, more and more semi-public networks use Ethernet as the access technology. Henning --Apple-Mail-1-472257537 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

On Jul 12, 2006, = at 11:53 AM, Stark, Barbara wrote:

I think I'm starting to understand where = we're losing each others' viewpoints.
=A0
We have the 2 basic types of networks (as defined in the = BCP): (1) networks where the operator can specify what devices are = allowed to connect to it, and (2) networks where the operator has no = control over what connects.
=A0
Enterprise networks are generally the former. I know my = corporate network guys would be extremely upset if I brought in a VoIP = phone from home and tried to connect it through the corporate network. I = think it's reasonable to suggest that an enterprise may choose to = implement LLDP in its network, and would have the ability to require = that all devices that connect to that network must also support LLDP. = For devices intended to operate in these closed enterprise networks, = LLDP is definitely an option. If vendors make CPE intended for these = networks, and if the vendor implements LLDP, I think it's reasonable for = this BCP to recommend that such LLDP-capable devices also do the = LLDP-MED Location identification.
=A0

I'm not sure about "most", = but I think your estimate of control might be slightly idealistic. Many = large networks, such as university networks, routinely have people plug = in essentially random devices. We have probably 50,000 such devices on = our network, and Columbia is, at best, a mid-size university. I suspect = that the same is true for most school systems and at least some Ethernet = VLANs in many companies. In many networks, in theory the sys admins has = control, in practice people still plug in what they like.

Also, Ethernet networks = are becoming increasingly popular in multi-family residences, such as = apartment buildings. =46rom what I hear, that model is quite common in = South Korea, for example. In general, more and more semi-public networks = use Ethernet as the access technology.

Henning


= --Apple-Mail-1-472257537-- --===============0677665454== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0677665454==-- From ecrit-bounces@ietf.org Wed Jul 12 14:01:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0j1i-0000t6-JW; Wed, 12 Jul 2006 14:01:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0j1g-0000rd-L4 for Ecrit@ietf.org; Wed, 12 Jul 2006 14:01:32 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0j1g-0004uP-1o for Ecrit@ietf.org; Wed, 12 Jul 2006 14:01:32 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 12 Jul 2006 11:01:31 -0700 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id k6CI1VIw024408; Wed, 12 Jul 2006 11:01:31 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k6CI1SoM008310; Wed, 12 Jul 2006 11:01:29 -0700 (PDT) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 11:01:28 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 11:01:28 -0700 From: "Marc Linsner" To: "'Francois D. Menard'" Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) Date: Wed, 12 Jul 2006 14:01:13 -0400 Message-ID: <004101c6a5dd$2cb14b90$9a12db84@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <00ab01c6a5cf$cde09a60$8b02a8c0@gestionfm> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcalwIknVoZwJ3e5QkSOrTTLp+TRuQADpWDwAANbVbA= X-OriginalArrivalTime: 12 Jul 2006 18:01:28.0427 (UTC) FILETIME=[32BD73B0:01C6A5DD] DKIM-Signature: a=rsa-sha1; q=dns; l=5684; t=1152727291; x=1153591291; c=relaxed/simple; s=sjdkim4001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20LLDP-MED=20and=20Phone=20BCP=20(Re=3A=20[Ecrit]=20New=20phonebcp draftwassubmitted); X=v=3Dcisco.com=3B=20h=3D6iYIx/AEaHDVppQd+VWMDFnw3Co=3D; b=aGGJpnxBAguZrP3Qh2AP96JFn9MusXk+n5Wmzm8pl7KpTvhh+2MtTs5M9YV37BXK0rqS9jr7 vfEbxPx85/LkP71i/9aTbW/3vpU04ivvTamyZxE4ybtrE69fg8WXqtQn; Authentication-Results: sj-dkim-4.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Francios, Your point about using the FIRST attachment provided location = information is very valid. But in your use case, I would like to think the Hotel operator as a L2 service provider that distributes location information to it's customers that is more precise than what the Hotel's broadband provider could = possibly provide. So, in my thinking, the Hotel operator would deploy a wire map that include floor/room number/etc. The Hotel operator is an = enterprise. -Marc- > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com]=20 > Sent: Wednesday, July 12, 2006 12:26 PM > To: 'Henning Schulzrinne'; 'Ted Hardie' > Cc: 'Rosen, Brian'; 'Stastny Richard'; Ecrit@ietf.org > Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New=20 > phonebcpdraftwassubmitted) >=20 > I think the case where you are in the hotel room with your=20 > ATA through NAT is quite eloquent. >=20 > The DSL NAT router employed by the hotel operator has to be=20 > intelligent enough to acquire location via PPPoE from the=20 > underlying operator (if it was cable modem, it would get it=20 > via DHCP) and then present through its NAT STACK, a DHCP=20 > offer re-offering the same location tocken it acquired. The=20 > Host grabbing location from its DHCP request has to=20 > communicate this information through the VPN software being=20 > launched on the host. The VPN server at the far end, when=20 > allocating address should attempt to acquire location of its=20 > client before it presents a DHCP offer through the VPN (or=20 > via PPP, or TLS, or whatever). =20 >=20 > Basically, I think it is up to the VPN server to request the=20 > location of the client prior to assigning its VPN IP address=20 > and telling what location is associated with this IP address=20 > (which happens to be the same location than the underlying location). >=20 > Is there any better way? >=20 > F. >=20 >=20 > -- > Fran=E7ois D. M=E9nard > Charg=E9 de projet > Xit t=E9l=E9com inc. > 1350 rue Royale #800 > Trois-Rivi=E8res, QC, G9A 4J4 > Canada > fmenard@xittelecom.com > Tel: (819) 374-2556 ext. 268 > Fax: (819) 374-0395 > Cell: (819) 692-1383 > =20 >=20 > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: 12 juillet 2006 10:35 > To: Ted Hardie > Cc: Rosen, Brian; Stastny Richard; Ecrit@ietf.org > Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New > phonebcpdraftwassubmitted) >=20 > One of Brian's favorite topics and a limitation of L7 protocols: =20 > VPNs. In those cases, you are unlikely to get to the right L7=20 > server or get it the right IP address. In those cases,=20 > lower-layer solutions, such as LLDP-MED and DHCP are likely=20 > to be more reliable. >=20 > Thus, I think as important as picking a list, is to also=20 > suggest the sequence of things to try and whether to keep=20 > trying if you got an answer (which may be wrong). In other=20 > words, if you got a location via DHCP, should you also ask via L7? >=20 >=20 > On Jul 12, 2006, at 10:25 AM, Ted Hardie wrote: >=20 > > At 4:09 PM +0200 7/12/06, Stastny Richard wrote: > >>> You need a list, where one end implements ALL and the other end=20 > >>> implements "at least one of" to get interoperability. There is no > >>> >other way. > >> > >> Fully agree. A device needs to implement ALL possible mechanisms,=20 > >> there is no other way, since you never know where a device is=20 > >> attached to. Period > >> > >> Richard > >> > > > > My agreement with this depends a lot on what "possible" means. If=20 > > someone defines a pppoe mechanisms, implementing it in a phone that=20 > > doesn't support ethernet or pppoe is not useful. If you=20 > define that=20 > > as "not a possible mechanism for that phone", then we're probably=20 > > okay. But that sounds to me closer to what Barbara is saying than=20 > > what Brian has said. > > > > I also believe we need to see the text Brian mentioned in the room=20 > > yesterday for self-configuration. For some devices, self-=20 > > configuration will be more accurate than the=20 > network-provided location=20 > > received by many of these methods. But putting that into=20 > the list of=20 > > mechanisms has some pretty interesting results. > > > > Last, the l7 question has two issues. First, if you have IP=20 > > connectivity, will you be able to reach an l7 server? The=20 > answer to=20 > > that had better be yes, since reaching one and reaching a=20 > sip service=20 > > have pretty similar > > properties. The other question is: will the l7 server be able to =20 > > identify 1) you and 2) where you. I take it that Brian's primary=20 > > concern is that it will not be possible to identify a client to the > > l7 server in ways that will work reliably in all=20 > environments. Until=20 > > we get a little deeper I can't say, but I do have to=20 > question whether=20 > > the effort to get to that point (so that there is single fallback > > mechanism) is really worse than every client implementing=20 > everything,=20 > > where everything is a potentially growing list. > > > > Ted > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 12 14:01:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0j1t-0000wM-R2; Wed, 12 Jul 2006 14:01:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0j1s-0000wE-H4 for Ecrit@ietf.org; Wed, 12 Jul 2006 14:01:44 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0j1r-00050Z-F8 for Ecrit@ietf.org; Wed, 12 Jul 2006 14:01:44 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G0j1g-000666-8t; Wed, 12 Jul 2006 13:01:35 -0500 From: "Brian Rosen" To: , "Rosen, Brian" Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) Date: Wed, 12 Jul 2006 14:01:33 -0400 Message-ID: <004001c6a5dd$393507d0$bc1cdb84@cis.neustar.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acal0rSznJ4E0jmLSgS7lLvmXWC0ZwACb3mw X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.6 (/) X-Scan-Signature: b446c230caab880282be239780d76153 Cc: Barbara.Stark@bellsouth.com, Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1772157337==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1772157337== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01C6A5BB.B22367D0" This is a multi-part message in MIME format. ------=_NextPart_000_0041_01C6A5BB.B22367D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agree that a corporate network can force non-801.1X devices from getting packet service, which might make LLDP more tractable, but don't forget soft clients, which would have 802.1X authorizations, but may not have LLDP support (are their standardized LLDP clients for Windows, for example)? It may be possible to get around that problem, but it just makes a requirement that a PC implement a larger list of protocols than a phone does, and I'm not sure that such a great idea. Repeating myself, I think controlling all devices connected to a network is so hard it will be very uncommon. Brian _____ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Wednesday, July 12, 2006 12:45 PM To: Rosen, Brian Cc: Barbara.Stark@bellsouth.com; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraft wassubmitted) Hi again, I think you miss the point I'm trying to make, quite possibly my not-so-good wording of it. Logic I read into Barbara's comment comes to: IF config method X is supported, THEN MUST support corresponding location method X, Fallback to L7 if none found. In your examples below, if the phone does not support DHCP at all, but does support LLDP-MED, it would not implement DHCP location discovery (duh) but would also be completely non-functional in any network that only provided DHCP configuration (notable example being IPv6 w. address autoconfig). If an enterprise network allows non-sanctioned endpoints (eg home devices) to be connected at all, but prefers LLDP for location and a bunch of other reasons, then yes, they would need to either i) suffer the pain providing both DHCP and LLDP, or ii) simply choose to disallow access to those devices without the one method they want to use for location. (Remember 802.1X is getting quite pervasive in enterprise, and using LLDP it is quite easy to simply not supply a usable VLAN to non -MED / non 802.1X authorized devices, resulting in effective quarantine.) Those phones that want to be usable in every possible environment would need to support all methods. I think the result would effectively wind up being the same MUST list, since I cannot imagine a phone not implementing DHCP in foreseeable future, and also expect LLDP will be effective commercial MUST for enterprise (not for non-enterprise, maybe). However I think it would be far easier to maintain as a document process if we can find some way to tie support to the configuration methods already used by the device. (I also note that the text consumed in this thread is probably now longer than code for an LLDP-MED phone implementation. >;-) -- Peter "Rosen, Brian" 12.07.06 09:20 To: cc: , , , Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) This thinking results in cases where assumptions made by one end don't match assumptions made by the other. Let's take LLDP as the example. Barbara would say that if the phone implements LLDP, then it should implement LLDP-MED. Okay, so suppose I have a residential phone which does not implement LLDP, so it doesn't implement LLDP-MED. So far, so good. Now, let's look at an enterprise network. It may implement LLDP, and thus LLDP-MED. Okay, the enterprise phone on the enterprise network works. What happens when the residential phone connects to the enterprise network? No location. Let's keep going. Suppose the residential phone implements DHCP, and thus implemented the DHCP location options. Unless the network ALSO implements DHCP location, it doesn't work. But if the enterprise implements the DHCP mechanism, then the LLDP mechanism is superfluous. Now take the enterprise phone and plug it into a home network, on an access network that does not meet the applicability statement of the L7 mechanism. That network deploys DHCP location. The enterprise phone can't get location unless it also implements DHCP. Now take that same phone and plug it into a network that doesn't deploy DHCP but does meet the applicability statement for the L7 protocol. The enterprise phone ALSO has to implement the L7 protocol. The "implement the location mechanism corresponding to the configuration mechanism" simply does not work. You need a list, where one end implements ALL and the other end implements "at least one of" to get interoperability. There is no other way. It is not the case that the L7 mechanism can be the single fall-back mechanism. It will have an applicability limit, and not all networks will meet it. This is effectively true of DHCP. It would be true of LLDP if it was on the list. It is the reason why, in this case, it is the CLIENT that must implement ALL and the server implement one of. Usually, we have the server taking the "all" role and the client taking the "at least one of" role. Brian _____ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Wednesday, July 12, 2006 8:05 AM To: Rosen, Brian Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; rohan.mahy@gmail.com Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Brian, Counter-point to below is that if the device and network do not support mutually agreeable configuration method, then the device is a brick anyway. L7 becomes a fall-back for the cases where the direct configuration method does not support passing location through (best example seems to be home router on DSL or cable modem). An important case, not sure well heard yesterday during meeting, was that in an IPv6 environment with address autoconfig there may be no DHCP at all. This may or may not be a small case as IPv6 rolls out, remains to be seen. And while IPv6 is not really important now in N.A. it is very rapidly becoming important in Asia/Pac and also Australia (I'm told). Cannot ignore it. -- Peter "Rosen, Brian" 11.07.06 20:56 To: , , cc: Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) But unless every phone supports LLDP-MED, then an enterprise must also implement DHCP (or L7) in order to support those phones that don't support LLDP. If every access network has to support those 2, then LLDP is superfelous. A residential phone may be plugged into an enterprise network. Ditto an enterprise phone. Location acquisition has to work always. If there is a list, and one end must support all, with the other end must support at least one, it always works. I don't see how you can get around that -------------------------- Brian Rosen NeuStar (724) 382-1051 brian.rosen@neustar.biz -----Original Message----- From: Stark, Barbara To: Andrew Newton; Rohan Mahy CC: Rosen, Brian; Ecrit@ietf.org Sent: Tue Jul 11 20:43:26 2006 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the network operator does not control the specification of every device connected to the network.": If the device has a DHCP client, the client MUST support RFC 3825 and . and If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in . Given that the Location Identification TLV is mandatory for all VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if statement really doesn't say much. But it would also suggest that devices that could have soft clients on them (PCs, PDAs) also need to do that TLV when they do LLDP-MED. All router-type devices that implement LLDP-MED are also required to support this TLV, per the spec. Since I'm really not at all concerned with the behavior of endpoints that don't have a DHCP client, I think the first if statement is also reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it SHOULD support being configured to request location through a DHCP INFORM message with options as described in RFC 3825 and , when it is configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static IP address). Anyway, I think both DHCP clients and LLDP-MED need to make it into devices based on all their merits, and not just on location discovery. If a vendor can't justify putting one or the other of these into a device (outside of recommendations in this BCP), then I say the protocol doesn't belong in the device. If the device is going to have one or the other, or both, then it needs to support the location determination mechanism that goes with it. Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really don't see a problem with stating it here. Barbara -----Original Message----- From: Andrew Newton [ mailto:andy@hxr.us] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: To be clear, I do not have a strong feeling about what does on Brian's list or not. I think LLDP-MED is a completely reasonable thing for a wired phone vendor to implement on enterprise class phones. Just throwing in my $0.0199997, I have not formed a strong opinion about this either. It does seem reasonable for enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices of category Y to implement method X... as what must be implemented by the device will always be dictated by the network media it uses. Where this gets a little tricky is that if there is no one common method, then devices may end up implementing things that are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark. Therefore, one method that does work in all environments must be implemented. And that is likely to be the L7-LCP. -andy ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ------=_NextPart_000_0041_01C6A5BB.B22367D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agree that a corporate network can = force non-801.1X devices from getting packet service, which might make LLDP = more tractable, but don’t forget soft clients, which would have 802.1X authorizations, but may not have LLDP support (are their standardized = LLDP clients for Windows, for example)?  It may be possible to get = around that problem, but it just makes a requirement that a PC implement a larger = list of protocols than a phone does, and I’m not sure that such a great = idea.

 

Repeating myself, I think = controlling all devices connected to a network is so hard it will be very = uncommon.

 

Brian

 

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Wednesday, July 12, = 2006 12:45 PM
To: Rosen, Brian
Cc: = Barbara.Stark@bellsouth.com; Ecrit@ietf.org
Subject: RE: LLDP-MED and = Phone BCP (Re: [Ecrit] New phonebcpdraft = wassubmitted)

 


Hi again,  

I think you miss the point I'm trying to make, quite possibly my = not-so-good wording of it.  Logic I read into Barbara's comment comes to: =
   IF config method X is supported,
      THEN MUST support corresponding location method X, =
   Fallback to L7 if none found.  

In your examples below, if the phone does not support DHCP at all, but does support LLDP-MED, it would not implement DHCP location discovery (duh) = but would also be completely non-functional in any network that only = provided DHCP configuration (notable example being IPv6 w. address autoconfig). =  If an enterprise network allows non-sanctioned endpoints (eg home devices) to = be connected at all, but prefers LLDP for location and a bunch of other = reasons, then yes, they would need to either i) suffer the pain providing both = DHCP and LLDP, or ii) simply choose to disallow access to those devices without = the one method they want to use for location.  (Remember 802.1X is getting = quite pervasive in enterprise, and using LLDP it is quite easy to simply not = supply a usable VLAN to non -MED / non 802.1X authorized devices, resulting in = effective quarantine.)   Those phones that want to be usable in every = possible environment would need to support all methods.  

I think the result would effectively wind up being the same MUST list, = since I cannot imagine a phone not implementing DHCP in foreseeable future, and = also expect LLDP will be effective commercial MUST for enterprise (not for non-enterprise, maybe).  However I think it would be far easier to maintain as a document process if we can find some way to tie support to = the configuration methods already used by the device.   =

(I also note that the text consumed in this thread is probably now longer = than code for an LLDP-MED phone implementation.  >;-) =

-- Peter



 

"Rosen, Brian" = <Brian.Rosen@neustar.biz>

12.07.06 09:20

       
        To:       =  <peter_blatherwick@mitel.com>
        cc:       =  <andy@hxr.us>, <Barbara.Stark@bellsouth.com>, <Ecrit@ietf.org>, <rohan.mahy@gmail.com>
        Subject:        RE: LLDP-MED = and Phone BCP (Re: [Ecrit] New phonebcp draft       =  wassubmitted)




This thinking results in cases where = assumptions made by one end don't match assumptions made by the other. =
 
Let's take LLDP as the example.  Barbara would = say that if the phone implements LLDP, then it should implement LLDP-MED. =  Okay, so suppose I have a residential phone which does not implement LLDP, so it = doesn't implement LLDP-MED.  So far, so good.  Now, let's look at an enterprise network.  It may implement LLDP, and thus LLDP-MED. =  Okay, the enterprise phone on the enterprise network works.  What happens = when the residential phone connects to the enterprise network?  No = location.  Let's keep going.  Suppose the residential phone implements = DHCP, and thus implemented the DHCP location options.  Unless the network = ALSO implements DHCP location, it doesn't work.  But if the enterprise implements the DHCP mechanism, then the LLDP mechanism is superfluous. =
 
Now take the enterprise phone and plug it into a home = network, on an access network that does not meet the applicability statement of = the L7 mechanism.  That network deploys DHCP location.  The = enterprise phone can't get location unless it also implements DHCP.  Now take that = same phone and plug it into a network that doesn't deploy DHCP but does meet = the applicability statement for the L7 protocol.  The enterprise phone = ALSO has to implement the L7 protocol.
 
The "implement the location mechanism = corresponding to the configuration mechanism" simply does not work.  You need a = list, where one end implements ALL and the other end implements "at least = one of" to get interoperability.  There is no other = way.
 
It is not the case that the L7 mechanism can be the = single fall-back mechanism.  It will have an applicability limit, and not = all networks will meet it.  This is effectively true of DHCP.  It = would be true of LLDP if it was on the list.  It is the reason why, in = this case, it is the CLIENT that must implement ALL and the server implement = one of.  Usually, we have the server taking the "all" role and = the client taking the "at least one of" role.
 
Brian
 

 


From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] =
Sent: Wednesday, July 12, 2006 8:05 AM
To: Rosen, = Brian
Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; rohan.mahy@gmail.com
Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp = draft wassubmitted)
 

Brian,
Counter-point to below is that if the device and network do not support mutually agreeable configuration method, then the device is a brick = anyway.  L7 becomes a fall-back for the cases where the direct configuration method = does not support passing location through (best example seems to be home = router on DSL or cable modem).  
An important case, not sure well heard yesterday during meeting, was = that in an IPv6 environment with address autoconfig there may be no DHCP at all. =  This may or may not be a small case as IPv6 rolls out, remains to be seen. =  And while IPv6 is not really important now in N.A. it is very rapidly = becoming important in Asia/Pac and also Australia (I'm told).  Cannot ignore it.  
-- Peter

 

"Rosen, Brian" = <Brian.Rosen@neustar.biz>

11.07.06 20:56

       
       To:       =  <Barbara.Stark@bellsouth.com>, <andy@hxr.us>, <rohan.mahy@gmail.com>
       cc:       =  Ecrit@ietf.org
       Subject:        Re: = LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft       =  wassubmitted)





But unless every phone supports LLDP-MED, then an enterprise must also implement DHCP (or L7) in order to support those phones that don't = support LLDP.  If every access network has to support those 2, then LLDP is superfelous.

A residential phone may be plugged into an enterprise network. =  Ditto an enterprise phone.  Location acquisition has to work always. =  If there is a list, and one end must support all, with the other end must support = at least one, it always works.

I don't see how you can get around that
--------------------------
Brian Rosen
NeuStar
(724) 382-1051
brian.rosen@neustar.biz


-----Original Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan Mahy
CC: Rosen, Brian; = Ecrit@ietf.org
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where = the network operator does not control the specification of every device = connected to the network.":

If the device has a DHCP client, the client MUST support RFC 3825 and <dhcp-civil>.
 and
If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in <LLDP-MED reference>.

Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the = 2nd if statement really doesn't say much. But it would also suggest that = devices that could have soft clients on them (PCs, PDAs) also need to do that TLV = when they do LLDP-MED. All router-type devices that implement LLDP-MED are also = required to support this TLV, per the spec.

Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also reasonable. = However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP INFORM = message with options as described in RFC 3825 and <dhcp-civil>, when it is = configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, = static IP address).

Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. If a = vendor can't justify putting one or the other of these into a device (outside = of recommendations in this BCP), then I say the protocol doesn't belong in = the device. If the device is going to have one or the other, or both, then = it needs to support the location determination mechanism that goes with it. = Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really = don't see a problem with stating it here.
Barbara


      -----Original Message-----
      From: Andrew Newton [mailto:andy@hxr.us]
      Sent: Friday, June 30, 2006 9:44 AM
      To: Rohan Mahy
      Cc: Rosen, = Brian; Ecrit@ietf.org
      Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] = New phonebcp draft wassubmitted)
     
     

      On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote:


              To be clear, I do not = have a strong feeling about what does on Brian's list or not.  I think = LLDP-MED is a completely reasonable thing for a wired phone vendor to implement = on enterprise class phones.


      Just throwing in my $0.0199997, I have not formed a = strong opinion about this either.  It does seem reasonable for enterprise = class devices with ethernet jacks to implement LLPD-MED, or for devices of = category Y to implement method X... as what must be implemented by the device will = always be dictated by the network media it uses.

      Where this gets a little tricky is that if there is = no one common method, then devices may end up implementing things that are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark.  Therefore, one method that does work in all environments must be implemented.   And that is likely to be the L7-LCP.

      -andy

*****

The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or entities = other than the intended recipient is prohibited. If you received this in = error, please contact the sender and delete the material from all computers. = 162
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

------=_NextPart_000_0041_01C6A5BB.B22367D0-- --===============1772157337== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1772157337==-- From ecrit-bounces@ietf.org Wed Jul 12 14:12:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jCg-0002ib-LV; Wed, 12 Jul 2006 14:12:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jCf-0002iV-6e for ecrit@ietf.org; Wed, 12 Jul 2006 14:12:53 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jCd-0007KF-QN for ecrit@ietf.org; Wed, 12 Jul 2006 14:12:53 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k6CICnV00436 for ; Wed, 12 Jul 2006 14:12:49 -0400 (EDT) Received: from [127.0.0.1] ([47.9.16.139] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 14:12:46 -0400 Message-ID: <44B53B9A.5000105@nortel.com> Date: Wed, 12 Jul 2006 14:12:42 -0400 From: "Tom-PT Taylor" User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Jul 2006 18:12:46.0732 (UTC) FILETIME=[C70A94C0:01C6A5DE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Ecrit] Update of security draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Here are the exact changes made going from security-threats-02 to security-threats-03. Please advise of any concerns before the Chairs pass this draft to the IESG. 1. Abstract, final sentence: corrected typos "identified", extra "the". 2. Introduction first para last two sentences: [emergency marker and protocol "must be defined" changed to "is being defined" in each case. 3. Changed punctuation on second and fifth bullets of section 4. 4. Section 5.1, para following the last bullet, final sentence: added ", or there could be location information, but it is false". 5. Section 6, response to attack involving corruption of the mapping database: Old text: Requirement: to provide an audit trail, the protocol SHOULD allow the inclusion of an identifier in its response that indicates which database records were used in preparing the response. This identifier SHOULD be encrypted along with randomizing information such as date/time, to minimize the information provided to an attacker in mapping responses. New text: Requirement: the protocol SHOULD include information in the response that allows subsequent correlation of that response with internal logs that may be kept on the mapping server, to allow debugging of mis-directed calls. One example of a way to meet this requirement would be by means of an opaque parameter in the returned URI. 6. Acknowledgements: added Ron Watro and corrected Kamran Aquil's name. I note that the reference to the requirements document will have to be fixed eventually, but that can be done any time up to AUTH 48. Tom Taylor _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 12 14:34:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jXi-0007bl-O3; Wed, 12 Jul 2006 14:34:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jWw-0006ys-1h for Ecrit@ietf.org; Wed, 12 Jul 2006 14:33:50 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jQK-0001Ab-JJ for Ecrit@ietf.org; Wed, 12 Jul 2006 14:27:01 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 13:27:00 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 12 Jul 2006 13:26:59 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 13:26:59 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" , "Stark, Barbara" Date: Wed, 12 Jul 2006 13:26:55 -0500 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 12 Jul 2006 18:26:59.0023 (UTC) FILETIME=[C30BDDF0:01C6A5E0] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Thread-Index: Acal2WUOInw9LMKaSAmZjR/0YEzgGwABtwww X-Spam-Score: 0.1 (/) X-Scan-Signature: 28dc73ba51024f450a593b05aa945739 Cc: "Rosen, Brian" , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0986399847==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0986399847== Content-Type: multipart/alternative; boundary="--=_NextPart_ST_13_26_59_Wednesday_July_12_2006_5016" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ----=_NextPart_ST_13_26_59_Wednesday_July_12_2006_5016 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We all get different views of how these fit together. Our enterprise, which serves a large number of employees (~10,000 from memory) uses a number of methods to ensure that you can't just plug stuff in. For instance, you don't get an IP address unless the networks knows your MAC address. I'm sure that this is the sort of thing that Barbara is talking about - and I am certain that a university is substantially different to most enterprises. =20 M =20 ________________________________ From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]=20 Sent: Thursday, 13 July 2006 3:34 AM To: Stark, Barbara Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) =20 =20 On Jul 12, 2006, at 11:53 AM, Stark, Barbara wrote: I think I'm starting to understand where we're losing each others' viewpoints. =20 We have the 2 basic types of networks (as defined in the BCP): (1) networks where the operator can specify what devices are allowed to connect to it, and (2) networks where the operator has no control over what connects. =20 Enterprise networks are generally the former. I know my corporate network guys would be extremely upset if I brought in a VoIP phone from home and tried to connect it through the corporate network. I think it's reasonable to suggest that an enterprise may choose to implement LLDP in its network, and would have the ability to require that all devices that connect to that network must also support LLDP. For devices intended to operate in these closed enterprise networks, LLDP is definitely an option. If vendors make CPE intended for these networks, and if the vendor implements LLDP, I think it's reasonable for this BCP to recommend that such LLDP-capable devices also do the LLDP-MED Location identification. =20 =20 I'm not sure about "most", but I think your estimate of control might be slightly idealistic. Many large networks, such as university networks, routinely have people plug in essentially random devices. We have probably 50,000 such devices on our network, and Columbia is, at best, a mid-size university. I suspect that the same is true for most school systems and at least some Ethernet VLANs in many companies. In many networks, in theory the sys admins has control, in practice people still plug in what they like. =20 Also, Ethernet networks are becoming increasingly popular in multi-family residences, such as apartment buildings. From what I hear, that model is quite common in South Korea, for example. In general, more and more semi-public networks use Ethernet as the access technology. =20 Henning =20 =20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] ----=_NextPart_ST_13_26_59_Wednesday_July_12_2006_5016 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We all get different views of how thes= e fit together.  Our enterprise, which serves a large number of employee= s (~10,000 from memory) uses a number of methods to ensure that you can’= ;t just plug stuff in.  For instance, you don’t get an IP address u= nless the networks knows your MAC address.  I’m sure that this is the sort= of thing that Barbara is talking about – and I am certain that a university is substantially different to most enterprises.

 

M

 

From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu]
Sent: Thursday, 13 July 2006= 3:34 AM
To: Stark, Barbara
Cc: Rosen, Brian; Ecrit@ietf= =2Eorg
Subject: Re: LLDP-MED and Ph= one BCP (Re: [Ecrit] New phonebcp draft wassubmitted)<= /p>

 

 

On Jul 12, 2006, at 11:53 AM, Stark, Barbara wrote:



= I think I'm starting to understand where we're losing each others' viewpoints= =2E

 

We have the 2 basic types of networks = (as defined in the BCP): (1) networks where the operator can specify what devic= es are allowed to connect to it, and (2) networks where the operator has no control over what connects.

 

Enterprise networks are generally the former. I know my corporate network guys would be extremely upset if I brought in a VoIP phone from home and tr= ied to connect it through the corporate network. I think it's reasonable to sug= gest that an enterprise may choose to implement LLDP in its network, and would h= ave the ability to require that all devices that connect to that network must a= lso support LLDP. For devices intended to operate in these closed enterprise networks, LLDP is definitely an option. If vendors make CPE intended for th= ese networks, and if the vendor implements LLDP, I think it's reasonable for this BCP to recommend that such LLDP-capable devices also do the LLDP-MED Location identification.

 

 

I'm not sure about "most", but I think your estimate of control might be slightly idealistic. Many large networks, such as universi= ty networks, routinely have people plug in essentially random devices. We have probably 50,000 such devices on our network, and Columbia is, at best, a mid-size univer= sity. I suspect that the same is true for most school systems and at least some Ethernet VLANs in many companies. In many networks, in theory the sys admin= s has control, in practice people still plug in what they like.

 

Also, Ethernet networks are becoming increasingly popular in multi-family residences, such as apartment buildings. From what I hear, tha= t model is quite common in South Korea, for example. In general, more and more semi-public networks use Ethernet as the access technology.=

 

Henning

 

 


-----------------------------------------------------------------------= -------------------------
This message is for the designated recipient o= nly and may
contain privileged, proprietary, or otherwise private inform= ation.
If you have received it in error, please notify the sender
i= mmediately and delete the original. Any unauthorized use of
this email = is prohibited.
---------------------------------------------------------= ---------------------------------------
[mf2] ----=_NextPart_ST_13_26_59_Wednesday_July_12_2006_5016-- --===============0986399847== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0986399847==-- From ecrit-bounces@ietf.org Wed Jul 12 14:34:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jXp-0007l4-JA; Wed, 12 Jul 2006 14:34:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0jX1-00076y-FJ for Ecrit@ietf.org; Wed, 12 Jul 2006 14:33:55 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0jLZ-0000uQ-5O for Ecrit@ietf.org; Wed, 12 Jul 2006 14:22:06 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 13:22:00 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 12 Jul 2006 13:22:00 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 13:21:59 -0500 Message-ID: From: "Thomson, Martin" To: "Francois D. Menard" , "Henning Schulzrinne" , "Ted Hardie" Date: Wed, 12 Jul 2006 13:21:56 -0500 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 12 Jul 2006 18:21:59.0551 (UTC) FILETIME=[108C10F0:01C6A5E0] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <00ab01c6a5cf$cde09a60$8b02a8c0@gestionfm> Content-class: urn:content-classes:message Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) Thread-Index: AcalwIknVoZwJ3e5QkSOrTTLp+TRuQADpWDwAAQpgPA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: "Rosen, Brian" , Stastny Richard , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We are getting into GEOPRIV L7 territory here; perhaps you should direct these sorts of comments to the GEOPRIV list. We are, of course, aware of these issues already and we are working on coming up with some sort of solution - at the moment, nothing really looks that great - even what you suggest has limitations that need to be acknowledged. Cheers, Martin > -----Original Message----- > From: Francois D. Menard [mailto:fmenard@xittelecom.com] > Sent: Thursday, 13 July 2006 2:26 AM > To: 'Henning Schulzrinne'; 'Ted Hardie' > Cc: 'Rosen, Brian'; 'Stastny Richard'; Ecrit@ietf.org > Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New > phonebcpdraftwassubmitted) >=20 > I think the case where you are in the hotel room with your ATA through NAT > is quite eloquent. >=20 > The DSL NAT router employed by the hotel operator has to be intelligent > enough to acquire location via PPPoE from the underlying operator (if it > was > cable modem, it would get it via DHCP) and then present through its NAT > STACK, a DHCP offer re-offering the same location tocken it acquired. The > Host grabbing location from its DHCP request has to communicate this > information through the VPN software being launched on the host. The VPN > server at the far end, when allocating address should attempt to acquire > location of its client before it presents a DHCP offer through the VPN (or > via PPP, or TLS, or whatever). >=20 > Basically, I think it is up to the VPN server to request the location of > the > client prior to assigning its VPN IP address and telling what location is > associated with this IP address (which happens to be the same location > than > the underlying location). >=20 > Is there any better way? >=20 > F. >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 12 15:19:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kFS-0006th-Lw; Wed, 12 Jul 2006 15:19:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kFR-0006tQ-Pg for Ecrit@ietf.org; Wed, 12 Jul 2006 15:19:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0j3l-0005P9-32 for Ecrit@ietf.org; Wed, 12 Jul 2006 14:03:41 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0iwE-0008GY-KI for Ecrit@ietf.org; Wed, 12 Jul 2006 13:55:58 -0400 Received: from stntsmtp01.cis.neustar.com (smartexch.neustar.com [10.31.13.96]) by ns4.neustar.com (Postfix) with ESMTP id 6B3F22ACBB; Wed, 12 Jul 2006 17:55:24 +0000 (GMT) Received: from stntexch04.cis.neustar.com ([10.31.13.64]) by stntsmtp01.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 13:55:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted) Date: Wed, 12 Jul 2006 13:55:21 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted) Thread-Index: Acalq55JoAEvc/K+SqG8j4hdobdddQAB+KfwAAUYf3AABN4ZIA== From: "Rosen, Brian" To: "Stark, Barbara" , X-OriginalArrivalTime: 12 Jul 2006 17:55:23.0992 (UTC) FILETIME=[59851580:01C6A5DC] X-Spam-Score: -3.5 (---) X-Scan-Signature: fae6308650eb2c66287cc837c1db2163 Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0439956346==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0439956346== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6A5DC.595B850F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6A5DC.595B850F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think the number of cases where a network operator can control the specification of all devices connected to the network is vanishingly small, but it's possible. Your example is a bad one, I think, because while the IT guys may be unhappy, people do it all the time, and it's gotta work. It's pretty tough to actively prohibit that kind of thing. =20 The language that a network that CAN control the spec can use any protocol it wants holds, and LLDP-MED could be a choice for such networks. That would not have LLDP mentioned in the -phonebcp document. Such networks can use ANY protocol, and I don't see a point in providing recommendations. =20 Your fundamental suggestion that you implement the location protocol associated with the configuration mechanism won't work for "open" networks as you define them. =20 Brian =20 ________________________________ From: Stark, Barbara [mailto:Barbara.Stark@bellsouth.com]=20 Sent: Wednesday, July 12, 2006 11:53 AM To: Rosen, Brian; peter_blatherwick@mitel.com Cc: andy@hxr.us; Ecrit@ietf.org; rohan.mahy@gmail.com Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was submitted) =20 I think I'm starting to understand where we're losing each others' viewpoints. =20 We have the 2 basic types of networks (as defined in the BCP): (1) networks where the operator can specify what devices are allowed to connect to it, and (2) networks where the operator has no control over what connects. =20 Enterprise networks are generally the former. I know my corporate network guys would be extremely upset if I brought in a VoIP phone from home and tried to connect it through the corporate network. I think it's reasonable to suggest that an enterprise may choose to implement LLDP in its network, and would have the ability to require that all devices that connect to that network must also support LLDP. For devices intended to operate in these closed enterprise networks, LLDP is definitely an option. If vendors make CPE intended for these networks, and if the vendor implements LLDP, I think it's reasonable for this BCP to recommend that such LLDP-capable devices also do the LLDP-MED Location identification. =20 But for open networks, where any device that a consumer buys is expected to work (home networks behind broadband connections, small biz networks, hotspots), I don't think LLDP is viable at this time. I think Brian is right that hotels and hotspots and metropolitan mesh WiFi networks cannot expect devices to support LLDP, and therefore must implement either the DHCP or L7 mechanism. If they must implement one of these 2, then it makes no sense to suggest that they might do LLDP in addition to one of the others, just in case a device came along that could do LLDP-MED. If that device is truly intended to work in that open network, then it would also be able to do DHCP and L7. So why go to the extra work to do LLDP in the network? =20 So, I think that the statement about "If LLDP, then LLDP-MED Location ID is MUST" is completely applicable to devices intended for "closed" networks, but not "open" networks. The BCP already has verbiage that indicates devices intended for these different types of networks might have different requirements. I think we need to expand that and have clear lists of recommendations for devices on "closed" networks (where the operator still wants to use open standards), and for those intended to be connected through "open" networks.=20 Barbara -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Wednesday, July 12, 2006 9:21 AM To: peter_blatherwick@mitel.com Cc: andy@hxr.us; Stark, Barbara; Ecrit@ietf.org; rohan.mahy@gmail.com Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) This thinking results in cases where assumptions made by one end don't match assumptions made by the other. =20 Let's take LLDP as the example. Barbara would say that if the phone implements LLDP, then it should implement LLDP-MED. Okay, so suppose I have a residential phone which does not implement LLDP, so it doesn't implement LLDP-MED. So far, so good. Now, let's look at an enterprise network. It may implement LLDP, and thus LLDP-MED. Okay, the enterprise phone on the enterprise network works. What happens when the residential phone connects to the enterprise network? No location. Let's keep going. Suppose the residential phone implements DHCP, and thus implemented the DHCP location options. Unless the network ALSO implements DHCP location, it doesn't work. But if the enterprise implements the DHCP mechanism, then the LLDP mechanism is superfluous.=20 =20 Now take the enterprise phone and plug it into a home network, on an access network that does not meet the applicability statement of the L7 mechanism. That network deploys DHCP location. The enterprise phone can't get location unless it also implements DHCP. Now take that same phone and plug it into a network that doesn't deploy DHCP but does meet the applicability statement for the L7 protocol. The enterprise phone ALSO has to implement the L7 protocol. =20 The "implement the location mechanism corresponding to the configuration mechanism" simply does not work. You need a list, where one end implements ALL and the other end implements "at least one of" to get interoperability. There is no other way. =20 It is not the case that the L7 mechanism can be the single fall-back mechanism. It will have an applicability limit, and not all networks will meet it. This is effectively true of DHCP. It would be true of LLDP if it was on the list. It is the reason why, in this case, it is the CLIENT that must implement ALL and the server implement one of. Usually, we have the server taking the "all" role and the client taking the "at least one of" role. =20 Brian =20 =09 ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Wednesday, July 12, 2006 8:05 AM To: Rosen, Brian Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; rohan.mahy@gmail.com Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) =20 =09 Brian,=20 Counter-point to below is that if the device and network do not support mutually agreeable configuration method, then the device is a brick anyway. L7 becomes a fall-back for the cases where the direct configuration method does not support passing location through (best example seems to be home router on DSL or cable modem). =20 An important case, not sure well heard yesterday during meeting, was that in an IPv6 environment with address autoconfig there may be no DHCP at all. This may or may not be a small case as IPv6 rolls out, remains to be seen. And while IPv6 is not really important now in N.A. it is very rapidly becoming important in Asia/Pac and also Australia (I'm told). Cannot ignore it. =20 -- Peter=20 =09 =09 =20 "Rosen, Brian" =20 11.07.06 20:56=20 =20 To: , , =20 cc: Ecrit@ietf.org=20 Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) =09 =09 =09 But unless every phone supports LLDP-MED, then an enterprise must also implement DHCP (or L7) in order to support those phones that don't support LLDP. If every access network has to support those 2, then LLDP is superfelous. =09 A residential phone may be plugged into an enterprise network. Ditto an enterprise phone. Location acquisition has to work always. If there is a list, and one end must support all, with the other end must support at least one, it always works.=20 =09 I don't see how you can get around that -------------------------- Brian Rosen NeuStar (724) 382-1051 brian.rosen@neustar.biz =09 =09 -----Original Message----- From: Stark, Barbara To: Andrew Newton; Rohan Mahy CC: Rosen, Brian; Ecrit@ietf.org Sent: Tue Jul 11 20:43:26 2006 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) =09 What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the network operator does not control the specification of every device connected to the network.": =09 If the device has a DHCP client, the client MUST support RFC 3825 and . and If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in . =09 Given that the Location Identification TLV is mandatory for all VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the 2nd if statement really doesn't say much. But it would also suggest that devices that could have soft clients on them (PCs, PDAs) also need to do that TLV when they do LLDP-MED. All router-type devices that implement LLDP-MED are also required to support this TLV, per the spec. =09 Since I'm really not at all concerned with the behavior of endpoints that don't have a DHCP client, I think the first if statement is also reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it SHOULD support being configured to request location through a DHCP INFORM message with options as described in RFC 3825 and , when it is configured to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static IP address). =09 Anyway, I think both DHCP clients and LLDP-MED need to make it into devices based on all their merits, and not just on location discovery. If a vendor can't justify putting one or the other of these into a device (outside of recommendations in this BCP), then I say the protocol doesn't belong in the device. If the device is going to have one or the other, or both, then it needs to support the location determination mechanism that goes with it. Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really don't see a problem with stating it here. Barbara =09 =09 -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us ] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) =20 =20 =09 On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: =09 =09 To be clear, I do not have a strong feeling about what does on Brian's list or not. I think LLDP-MED is a completely reasonable thing for a wired phone vendor to implement on enterprise class phones. =09 =09 Just throwing in my $0.0199997, I have not formed a strong opinion about this either. It does seem reasonable for enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices of category Y to implement method X... as what must be implemented by the device will always be dictated by the network media it uses. =09 Where this gets a little tricky is that if there is no one common method, then devices may end up implementing things that are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark. Therefore, one method that does work in all environments must be implemented. And that is likely to be the L7-LCP. =09 -andy =09 ***** =09 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 118 ------_=_NextPart_001_01C6A5DC.595B850F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think the number of cases where a network operator can control the specification of all devices connected = to the network is vanishingly small, but it’s possible.  Your = example is a bad one, I think, because while the IT guys may be unhappy, people do it all = the time, and it’s gotta work.  It’s pretty tough to = actively prohibit that kind of thing. 

 

The language that a network that = CAN control the spec can use any protocol it wants holds, and LLDP-MED could = be a choice for such networks.  That would not have LLDP mentioned in the = –phonebcp document.  Such networks can use ANY protocol, and I don’t = see a point in providing recommendations.

 

Your fundamental suggestion that = you implement the location protocol associated with the configuration = mechanism won’t work for “open” networks as you define = them.

 

Brian

 

From: = Stark, Barbara [mailto:Barbara.Stark@bellsouth.com]
Sent: Wednesday, July 12, = 2006 11:53 AM
To: Rosen, Brian; peter_blatherwick@mitel.com
Cc: andy@hxr.us; = Ecrit@ietf.org; rohan.mahy@gmail.com
Subject: RE: LLDP-MED and = Phone BCP (Re: [Ecrit] New phonebcp draft was = submitted)

 

I think I'm starting to understand = where we're losing each others' viewpoints.

 

We have the 2 basic types of = networks (as defined in the BCP): (1) networks where the operator can specify what = devices are allowed to connect to it, and (2) networks where the operator has no control over what connects.

 

Enterprise networks are generally the former. I know my corporate = network guys would be extremely upset if I brought in a VoIP phone from home and = tried to connect it through the corporate network. I think it's reasonable to = suggest that an enterprise may choose to implement LLDP in its network, and = would have the ability to require that all devices that connect to that network = must also support LLDP. For devices intended to operate in these closed enterprise = networks, LLDP is definitely an option. If vendors make CPE intended for these = networks, and if the vendor implements LLDP, I think it's reasonable for this BCP = to recommend that such LLDP-capable devices also do the LLDP-MED Location identification.

 

But for open networks, where any = device that a consumer buys is expected to work (home networks behind broadband connections, small biz networks, hotspots), I don't think LLDP is viable = at this time. I think Brian is right that hotels and hotspots and = metropolitan mesh WiFi networks cannot expect devices to support LLDP, and therefore = must implement either the DHCP or L7 mechanism. If they must implement one of = these 2, then it makes no sense to suggest that they might do LLDP in addition = to one of the others, just in case a device came along that could do LLDP-MED. = If that device is truly intended to work in that open network, then it would = also be able to do DHCP and L7. So why go to the extra work to do LLDP in the = network?

 

So, I think that the statement = about "If LLDP, then LLDP-MED Location ID is MUST" is completely applicable = to devices intended for "closed" networks, but not = "open" networks. The BCP already has verbiage that indicates devices intended = for these different types of networks might have different requirements. I = think we need to expand that and have clear lists of recommendations for devices = on "closed" networks (where the operator still wants to use open standards), and for those intended to be connected through = "open" networks.

Barbara

=
=

-----Original = Message-----
From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]
Sent: Wednesday, July 12, = 2006 9:21 AM
To: = peter_blatherwick@mitel.com
Cc: andy@hxr.us; Stark, = Barbara; Ecrit@ietf.org; rohan.mahy@gmail.com
Subject: RE: LLDP-MED and = Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted)

This thinking results in cases = where assumptions made by one end don’t match assumptions made by the = other.

 

Let’s take LLDP as the example.  Barbara would say that if the phone implements LLDP, then = it should implement LLDP-MED.  Okay, so suppose I have a residential = phone which does not implement LLDP, so it doesn’t implement = LLDP-MED.  So far, so good.  Now, let’s look at an enterprise = network.  It may implement LLDP, and thus LLDP-MED.  Okay, the enterprise phone = on the enterprise network works.  What happens when the residential phone connects to the enterprise network?  No location.  Let’s = keep going.  Suppose the residential phone implements DHCP, and thus implemented the DHCP location options.  Unless the network ALSO = implements DHCP location, it doesn’t work.  But if the enterprise = implements the DHCP mechanism, then the LLDP mechanism is superfluous. =

 

Now take the enterprise phone and = plug it into a home network, on an access network that does not meet the = applicability statement of the L7 mechanism.  That network deploys DHCP = location.  The enterprise phone can’t get location unless it also implements DHCP.  Now take that same phone and plug it into a network that doesn’t deploy DHCP but does meet the applicability statement for = the L7 protocol.  The enterprise phone ALSO has to implement the L7 = protocol.

 

The “implement the location mechanism corresponding to the configuration mechanism” simply = does not work.  You need a list, where one end implements ALL and the other = end implements “at least one of” to get interoperability.  = There is no other way.

 

It is not the case that the L7 = mechanism can be the single fall-back mechanism.  It will have an = applicability limit, and not all networks will meet it.  This is effectively true = of DHCP.  It would be true of LLDP if it was on the list.  It is = the reason why, in this case, it is the CLIENT that must implement ALL and = the server implement one of.  Usually, we have the server taking the “all” role and the client taking the “at least one = of” role.

 

Brian

 

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Wednesday, July 12, = 2006 8:05 AM
To: Rosen, Brian
Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; rohan.mahy@gmail.com
Subject: Re: LLDP-MED and = Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted)

 


Brian,
Counter-point to below is that if the device and network do not support mutually = agreeable configuration method, then the device is a brick anyway.  L7 = becomes a fall-back for the cases where the direct configuration method does not support = passing location through (best example seems to be home router on DSL or cable = modem).  
An important case, not sure well heard yesterday during meeting, was that = in an IPv6 environment with address autoconfig there may be no DHCP at all.  This may or may not be a small case as IPv6 rolls out, remains to = be seen.  And while IPv6 is not really important now in N.A. it is = very rapidly becoming important in Asia/Pac and also Australia (I'm told). =  Cannot ignore it.  
-- Peter

 

"Rosen, Brian" = <Brian.Rosen@neustar.biz>

11.07.06 20:56

       
        To:        <Barbara.Stark@bellsouth.com>, <andy@hxr.us>, <rohan.mahy@gmail.com>
        cc:       =  Ecrit@ietf.org
        Subject:        Re: LLDP-MED = and Phone BCP (Re: [Ecrit] New phonebcp draft        wassubmitted)




But unless = every phone supports LLDP-MED, then an enterprise must also implement DHCP (or = L7) in order to support those phones that don't support LLDP.  If every = access network has to support those 2, then LLDP is superfelous.

A residential phone may be plugged into an enterprise network. =  Ditto an enterprise phone.  Location acquisition has to work always. =  If there is a list, and one end must support all, with the other end must support = at least one, it always works.

I don't see how you can get around that
--------------------------
Brian Rosen
NeuStar
(724) 382-1051
brian.rosen@neustar.biz


-----Original Message-----
From: Stark, Barbara
To: Andrew Newton; Rohan Mahy
CC: Rosen, Brian; = Ecrit@ietf.org
Sent: Tue Jul 11 20:43:26 2006
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted)

What I'd like to see in the doc would be:
For any device that's "intended to be operated on a network where = the network operator does not control the specification of every device = connected to the network.":

If the device has a DHCP client, the client MUST support RFC 3825 and <dhcp-civil>.
  and
If the device supports LLDP-MED, it MUST support the "Location Identification TLV" as defined in <LLDP-MED reference>.

Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED spec), the = 2nd if statement really doesn't say much. But it would also suggest that = devices that could have soft clients on them (PCs, PDAs) also need to do that TLV = when they do LLDP-MED. All router-type devices that implement LLDP-MED are also = required to support this TLV, per the spec.

Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also reasonable. = However, I do recommend for such devices that:
If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP INFORM message with = options as described in RFC 3825 and <dhcp-civil>, when it is configured = to use one of these alternate bootstrap methods (e.g., PPPoE, PPPoA, static IP address).

Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. If a = vendor can't justify putting one or the other of these into a device (outside = of recommendations in this BCP), then I say the protocol doesn't belong in = the device. If the device is going to have one or the other, or both, then = it needs to support the location determination mechanism that goes with it. = Since, for LLDP-MED, that's already a requirement of the LLDP-MED spec, I really = don't see a problem with stating it here.
Barbara


       -----Original Message-----
       From: Andrew Newton [mailto:andy@hxr.us]
       Sent: Friday, June 30, 2006 9:44 AM
       To: Rohan Mahy
       Cc: Rosen, = Brian; Ecrit@ietf.org
       Subject: Re: LLDP-MED and Phone BCP (Re: = [Ecrit] New phonebcp draft wassubmitted)
     
     

       On Jun 29, 2006, at 6:29 PM, Rohan Mahy = wrote:


               To be clear, I do = not have a strong feeling about what does on Brian's list or not.  I = think LLDP-MED is a completely reasonable thing for a wired phone vendor to = implement on enterprise class phones.


       Just throwing in my $0.0199997, I have not = formed a strong opinion about this either.  It does seem reasonable for = enterprise class devices with ethernet jacks to implement LLPD-MED, or for devices = of category Y to implement method X... as what must be implemented by the = device will always be dictated by the network media it uses.

       Where this gets a little tricky is that if = there is no one common method, then devices may end up implementing things that = are not appropriate in an attempt to have devices that work in multiple network environments... and even then they may end up missing the mark. =  Therefore, one method that does work in all environments must be implemented. =   And that is likely to be the L7-LCP.

       -andy

*****

The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or entities = other than the intended recipient is prohibited. If you received this in = error, please contact the sender and delete the material from all computers. = 162
_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

=

*****

The information = transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or privileged = material. Any review, retransmission, dissemination or other use of, or = taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received this in error, please contact the sender and delete the = material from all computers. 118

 ------_=_NextPart_001_01C6A5DC.595B850F-- --===============0439956346== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0439956346==-- From ecrit-bounces@ietf.org Wed Jul 12 15:29:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kOg-0007VW-Cd; Wed, 12 Jul 2006 15:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kOf-0007VR-HU for Ecrit@ietf.org; Wed, 12 Jul 2006 15:29:21 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G0kOc-0002Qz-DI for Ecrit@ietf.org; Wed, 12 Jul 2006 15:29:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Date: Wed, 12 Jul 2006 21:28:24 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B18@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft wassubmitted) Thread-Index: Acalq55JoAEvc/K+SqG8j4hdobdddQAB+KfwAAUYf3AABN4ZIAADUYRF References: From: "Stastny Richard" To: "Rosen, Brian" X-Spam-Score: 0.5 (/) X-Scan-Signature: c119f9923e40f08a1d7f390ce651ea92 Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org >I think the number of cases where a network operator can control the = specification of all devices connected to the network is >vanishingly = small, but it's possible. =20 But having said that, I cannot imagine that device manufacturers are = developing devices especially for these type of networks. Most devices are general purpose and may be attached = to any network anyway. =20 of course I agree what Ted said: =20 >My agreement with this depends a lot on what "possible" means. If = someone defines a pppoe mechanisms, implementing it in >a phone that = doesn't support ethernet or pppoe is not useful. If you define that as = "not a possible mechanism for that phone", >then we're probably okay.=20 =20 If the device does not support ethernet or PPPoE, it does also not need = to have a location procedure for it. =20 Richard ________________________________ Von: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Gesendet: Mi 12.07.2006 19:55 An: Stark, Barbara; peter_blatherwick@mitel.com Cc: Ecrit@ietf.org Betreff: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) I think the number of cases where a network operator can control the = specification of all devices connected to the network is vanishingly = small, but it's possible. Your example is a bad one, I think, because = while the IT guys may be unhappy, people do it all the time, and it's = gotta work. It's pretty tough to actively prohibit that kind of thing. = =20 The language that a network that CAN control the spec can use any = protocol it wants holds, and LLDP-MED could be a choice for such = networks. That would not have LLDP mentioned in the -phonebcp document. = Such networks can use ANY protocol, and I don't see a point in = providing recommendations. =20 Your fundamental suggestion that you implement the location protocol = associated with the configuration mechanism won't work for "open" = networks as you define them. =20 Brian =20 ________________________________ From: Stark, Barbara [mailto:Barbara.Stark@bellsouth.com]=20 Sent: Wednesday, July 12, 2006 11:53 AM To: Rosen, Brian; peter_blatherwick@mitel.com Cc: andy@hxr.us; Ecrit@ietf.org; rohan.mahy@gmail.com Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft was = submitted) =20 I think I'm starting to understand where we're losing each others' = viewpoints. =20 We have the 2 basic types of networks (as defined in the BCP): (1) = networks where the operator can specify what devices are allowed to = connect to it, and (2) networks where the operator has no control over = what connects. =20 Enterprise networks are generally the former. I know my corporate = network guys would be extremely upset if I brought in a VoIP phone from = home and tried to connect it through the corporate network. I think it's = reasonable to suggest that an enterprise may choose to implement LLDP in = its network, and would have the ability to require that all devices that = connect to that network must also support LLDP. For devices intended to = operate in these closed enterprise networks, LLDP is definitely an = option. If vendors make CPE intended for these networks, and if the = vendor implements LLDP, I think it's reasonable for this BCP to = recommend that such LLDP-capable devices also do the LLDP-MED Location = identification. =20 But for open networks, where any device that a consumer buys is expected = to work (home networks behind broadband connections, small biz networks, = hotspots), I don't think LLDP is viable at this time. I think Brian is = right that hotels and hotspots and metropolitan mesh WiFi networks = cannot expect devices to support LLDP, and therefore must implement = either the DHCP or L7 mechanism. If they must implement one of these 2, = then it makes no sense to suggest that they might do LLDP in addition to = one of the others, just in case a device came along that could do = LLDP-MED. If that device is truly intended to work in that open network, = then it would also be able to do DHCP and L7. So why go to the extra = work to do LLDP in the network? =20 So, I think that the statement about "If LLDP, then LLDP-MED Location ID = is MUST" is completely applicable to devices intended for "closed" = networks, but not "open" networks. The BCP already has verbiage that = indicates devices intended for these different types of networks might = have different requirements. I think we need to expand that and have = clear lists of recommendations for devices on "closed" networks (where = the operator still wants to use open standards), and for those intended = to be connected through "open" networks.=20 Barbara -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz] Sent: Wednesday, July 12, 2006 9:21 AM To: peter_blatherwick@mitel.com Cc: andy@hxr.us; Stark, Barbara; Ecrit@ietf.org; rohan.mahy@gmail.com Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) This thinking results in cases where assumptions made by one end don't = match assumptions made by the other. =20 Let's take LLDP as the example. Barbara would say that if the phone = implements LLDP, then it should implement LLDP-MED. Okay, so suppose I = have a residential phone which does not implement LLDP, so it doesn't = implement LLDP-MED. So far, so good. Now, let's look at an enterprise = network. It may implement LLDP, and thus LLDP-MED. Okay, the = enterprise phone on the enterprise network works. What happens when the = residential phone connects to the enterprise network? No location. = Let's keep going. Suppose the residential phone implements DHCP, and = thus implemented the DHCP location options. Unless the network ALSO = implements DHCP location, it doesn't work. But if the enterprise = implements the DHCP mechanism, then the LLDP mechanism is superfluous.=20 =20 Now take the enterprise phone and plug it into a home network, on an = access network that does not meet the applicability statement of the L7 = mechanism. That network deploys DHCP location. The enterprise phone = can't get location unless it also implements DHCP. Now take that same = phone and plug it into a network that doesn't deploy DHCP but does meet = the applicability statement for the L7 protocol. The enterprise phone = ALSO has to implement the L7 protocol. =20 The "implement the location mechanism corresponding to the = configuration mechanism" simply does not work. You need a list, where = one end implements ALL and the other end implements "at least one of" to = get interoperability. There is no other way. =20 It is not the case that the L7 mechanism can be the single fall-back = mechanism. It will have an applicability limit, and not all networks = will meet it. This is effectively true of DHCP. It would be true of = LLDP if it was on the list. It is the reason why, in this case, it is = the CLIENT that must implement ALL and the server implement one of. = Usually, we have the server taking the "all" role and the client taking = the "at least one of" role. =20 Brian =20 =09 ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Wednesday, July 12, 2006 8:05 AM To: Rosen, Brian Cc: andy@hxr.us; Barbara.Stark@bellsouth.com; Ecrit@ietf.org; = rohan.mahy@gmail.com Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) =20 =09 Brian,=20 Counter-point to below is that if the device and network do not support = mutually agreeable configuration method, then the device is a brick = anyway. L7 becomes a fall-back for the cases where the direct = configuration method does not support passing location through (best = example seems to be home router on DSL or cable modem). =20 An important case, not sure well heard yesterday during meeting, was = that in an IPv6 environment with address autoconfig there may be no DHCP = at all. This may or may not be a small case as IPv6 rolls out, remains = to be seen. And while IPv6 is not really important now in N.A. it is = very rapidly becoming important in Asia/Pac and also Australia (I'm = told). Cannot ignore it. =20 -- Peter=20 =09 =09 =20 "Rosen, Brian" =20 11.07.06 20:56=20 =20 To: , , = =20 cc: Ecrit@ietf.org=20 Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New = phonebcp draft wassubmitted) =09 =09 =09 But unless every phone supports LLDP-MED, then an enterprise must also = implement DHCP (or L7) in order to support those phones that don't = support LLDP. If every access network has to support those 2, then LLDP = is superfelous. =09 A residential phone may be plugged into an enterprise network. Ditto = an enterprise phone. Location acquisition has to work always. If there = is a list, and one end must support all, with the other end must support = at least one, it always works.=20 =09 I don't see how you can get around that -------------------------- Brian Rosen NeuStar (724) 382-1051 brian.rosen@neustar.biz =09 =09 -----Original Message----- From: Stark, Barbara To: Andrew Newton; Rohan Mahy CC: Rosen, Brian; Ecrit@ietf.org Sent: Tue Jul 11 20:43:26 2006 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp draft = wassubmitted) =09 What I'd like to see in the doc would be: For any device that's "intended to be operated on a network where the = network operator does not control the specification of every device = connected to the network.": =09 If the device has a DHCP client, the client MUST support RFC 3825 and = . and If the device supports LLDP-MED, it MUST support the "Location = Identification TLV" as defined in . =09 Given that the Location Identification TLV is mandatory for all = VoIP-type endpoints implementing LLDP-MED (according to the LLDP-MED = spec), the 2nd if statement really doesn't say much. But it would also = suggest that devices that could have soft clients on them (PCs, PDAs) = also need to do that TLV when they do LLDP-MED. All router-type devices = that implement LLDP-MED are also required to support this TLV, per the = spec. =09 Since I'm really not at all concerned with the behavior of endpoints = that don't have a DHCP client, I think the first if statement is also = reasonable. However, I do recommend for such devices that: If the device allows for bootstrapping methods other than DHCP, it = SHOULD support being configured to request location through a DHCP = INFORM message with options as described in RFC 3825 and , = when it is configured to use one of these alternate bootstrap methods = (e.g., PPPoE, PPPoA, static IP address). =09 Anyway, I think both DHCP clients and LLDP-MED need to make it into = devices based on all their merits, and not just on location discovery. = If a vendor can't justify putting one or the other of these into a = device (outside of recommendations in this BCP), then I say the protocol = doesn't belong in the device. If the device is going to have one or the = other, or both, then it needs to support the location determination = mechanism that goes with it. Since, for LLDP-MED, that's already a = requirement of the LLDP-MED spec, I really don't see a problem with = stating it here. Barbara =09 =09 -----Original Message----- From: Andrew Newton [mailto:andy@hxr.us ] Sent: Friday, June 30, 2006 9:44 AM To: Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: Re: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcp = draft wassubmitted) =20 =20 =09 On Jun 29, 2006, at 6:29 PM, Rohan Mahy wrote: =09 =09 To be clear, I do not have a strong feeling about what = does on Brian's list or not. I think LLDP-MED is a completely = reasonable thing for a wired phone vendor to implement on enterprise = class phones. =09 =09 Just throwing in my $0.0199997, I have not formed a strong = opinion about this either. It does seem reasonable for enterprise class = devices with ethernet jacks to implement LLPD-MED, or for devices of = category Y to implement method X... as what must be implemented by the = device will always be dictated by the network media it uses. =09 Where this gets a little tricky is that if there is no one = common method, then devices may end up implementing things that are not = appropriate in an attempt to have devices that work in multiple network = environments... and even then they may end up missing the mark. = Therefore, one method that does work in all environments must be = implemented. And that is likely to be the L7-LCP. =09 -andy =09 ***** =09 The information transmitted is intended only for the person or entity = to which it is addressed and may contain confidential, proprietary, = and/or privileged material. Any review, retransmission, dissemination or = other use of, or taking of any action in reliance upon this information = by persons or entities other than the intended recipient is prohibited. = If you received this in error, please contact the sender and delete the = material from all computers. 162 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit ***** The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or = privileged material. Any review, retransmission, dissemination or other = use of, or taking of any action in reliance upon this information by = persons or entities other than the intended recipient is prohibited. If = you received this in error, please contact the sender and delete the = material from all computers. 118 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 12 16:08:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0l07-0000AM-0H; Wed, 12 Jul 2006 16:08:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0kzz-0008Jv-Oe; Wed, 12 Jul 2006 16:07:55 -0400 Received: from willow.neustar.com ([209.173.53.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0kzy-0002Qh-Fe; Wed, 12 Jul 2006 16:07:55 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k6CJo2QC030775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Jul 2006 19:50:03 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1G0kig-0000vz-Fy; Wed, 12 Jul 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 12 Jul 2006 15:50:02 -0400 X-Spam-Score: 0.3 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: ecrit@ietf.org Subject: [Ecrit] I-D ACTION:draft-ietf-ecrit-security-threats-03.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Emergency Context Resolution with Internet Technologies Working Group of the IETF. Title : Security Threats and Requirements for Emergency Call Marking and Mapping Author(s) : T. Taylor, et al. Filename : draft-ietf-ecrit-security-threats-03.txt Pages : 18 Date : 2006-7-12 This document reviews the security threats associated with: o the marking of signalling messages to indicate that they are related to an emergency; and o the process of mapping from locations to Universal Resource Identifiers (URIs) pointing to Public Safety Answering Points (PSAPs). This mapping occurs as part of the process of routing emergency calls through the IP network. Based on the identified threats, this document establishes a set of security requirements for the mapping protocol and for the handling of emergency-marked calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-security-threats-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ecrit-security-threats-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ecrit-security-threats-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-7-12135852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-security-threats-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-security-threats-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-7-12135852.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --NextPart-- From ecrit-bounces@ietf.org Wed Jul 12 17:23:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0mBV-0003E8-DB; Wed, 12 Jul 2006 17:23:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0mBU-0003Cn-Cc for Ecrit@ietf.org; Wed, 12 Jul 2006 17:23:52 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0mBS-00056l-U4 for Ecrit@ietf.org; Wed, 12 Jul 2006 17:23:52 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 16:23:48 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 12 Jul 2006 16:23:47 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 16:23:47 -0500 Message-ID: From: "Winterbottom, James" To: "Marc Linsner" , "Stark, Barbara" , "Andrew Newton" , "Rohan Mahy" Date: Wed, 12 Jul 2006 16:23:45 -0500 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 12 Jul 2006 21:23:47.0061 (UTC) FILETIME=[75EE0250:01C6A5F9] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <005f01c6a5b7$d67926a0$9a12db84@amer.cisco.com> Content-class: urn:content-classes:message Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) Thread-Index: AcacS01AozzxQH4SRpCO5st6hhUFBQI/jIJwAAaF0/AAFPArAAAQfXfQ X-Spam-Score: 0.1 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Cc: "Rosen, Brian" , Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1631702272==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1631702272== Content-Type: multipart/alternative; boundary="--=_NextPart_ST_16_23_47_Wednesday_July_12_2006_6889" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ----=_NextPart_ST_16_23_47_Wednesday_July_12_2006_6889 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Marc, this has nothing to do with mobile. It is to do with the potential for massive errors to be introduced by the encoding technique used in RFC-3825. Please see appendix A of PIDF-LO profile for more details. =20 =20 ________________________________ From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: Wednesday, 12 July 2006 11:34 PM To: Winterbottom, James; 'Stark, Barbara'; 'Andrew Newton'; 'Rohan Mahy' Cc: 'Rosen, Brian'; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) =20 As stated in RFC3825, it is applicable to non-mobile environments. =20 -Marc- =20 =09 ________________________________ From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Tuesday, July 11, 2006 11:39 PM To: Stark, Barbara; Andrew Newton; Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) =20 I would be very cautious about recommending the use of RFC-3825 encoding to report emergency locations given the issues raised at IETF-65 in Dallas that are yet to be adequately resolved. In NENA we put a caveat around its use to the effect that location provided in this manner must be regarded as a point only, and that encodings for resolution must be ignored. =20 Cheers James =20 =20 =09 =09 ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information.=20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. =09 ------------------------------------------------------------------------ ------------------------ [mf2]=20 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] ----=_NextPart_ST_16_23_47_Wednesday_July_12_2006_6889 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Marc, this has nothing to do with mobi= le. It is to do with the potential for massive errors to be introduced by the enco= ding technique used in RFC-3825. Please see appendix A of PIDF-LO profile for mo= re details.

 

 

From: Marc Lin= sner [mailto:mlinsner@cisco.com]
Sent: Wednesday, 12 July 200= 6 11:34 PM
To: Winterbottom, James; 'St= ark, Barbara'; 'Andrew Newton'; 'Rohan Mahy'
Cc: 'Rosen, Brian'; Ecrit@ie= tf.org
Subject: RE: LLDP-MED and Ph= one BCP (Re: [Ecrit] New phonebcpdraftwassubmitted)

 

As stated in RFC3825, it is applicable= to non-mobile environments.

 

-Marc-

 

From:= Winterbottom, James [mailto:James.Winterbottom@andrew.com]
Sent: Tuesday, July 11, 2006= 11:39 PM
To: Stark, Barbara; Andrew N= ewton; Rohan Mahy
Cc: Rosen, Brian; Ecrit@ietf= =2Eorg
Subject: RE: LLDP-MED and Ph= one BCP (Re: [Ecrit] New phonebcpdraftwassubmitted)

 

I would be very cautious about recommending the use of RFC-3825 encoding to report emergency locations giv= en the issues raised at IETF-65 in Dallas that are yet to be adequately resolv= ed. In NENA we put a caveat around its use to the effect that location provided= in this manner must be regarded as a point only, and that encodings for resolu= tion must be ignored.

 

Cheers

James

 

 


---------------------------------------------------------------------------= ---------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
---------------------------------------------------------------------------= ---------------------
[mf2]

*****

The information transmitted is intended onl= y for the person or entity to which it is addressed and may contain confident= ial, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon thi= s information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and de= lete the material from all computers. 162


-----------------------------------------------------------------------= -------------------------
This message is for the designated recipient o= nly and may
contain privileged, proprietary, or otherwise private inform= ation.
If you have received it in error, please notify the sender
i= mmediately and delete the original. Any unauthorized use of
this email = is prohibited.
---------------------------------------------------------= ---------------------------------------
[mf2] ----=_NextPart_ST_16_23_47_Wednesday_July_12_2006_6889-- --===============1631702272== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1631702272==-- From ecrit-bounces@ietf.org Wed Jul 12 19:22:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0o2C-0007wp-M9; Wed, 12 Jul 2006 19:22:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0o2B-0007v2-4P for Ecrit@ietf.org; Wed, 12 Jul 2006 19:22:23 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0o2B-0006Uk-0f for Ecrit@ietf.org; Wed, 12 Jul 2006 19:22:23 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0o27-0000b4-8O for Ecrit@ietf.org; Wed, 12 Jul 2006 19:22:22 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 12 Jul 2006 16:22:18 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208,217"; a="434023893:sNHT89773904" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k6CNMImP026731; Wed, 12 Jul 2006 16:22:18 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k6CNM9KK019113; Wed, 12 Jul 2006 16:22:16 -0700 (PDT) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 16:22:10 -0700 Received: from mlinsnerwxp ([171.68.225.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 12 Jul 2006 16:22:09 -0700 From: "Marc Linsner" To: "'Winterbottom, James'" Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) Date: Wed, 12 Jul 2006 19:21:57 -0400 Message-ID: <004201c6a609$f92f4920$e1fc010a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcacS01AozzxQH4SRpCO5st6hhUFBQI/jIJwAAaF0/AAFPArAAAQfXfQAAPuxHA= X-OriginalArrivalTime: 12 Jul 2006 23:22:10.0068 (UTC) FILETIME=[FFA6DD40:01C6A609] DKIM-Signature: a=rsa-sha1; q=dns; l=14950; t=1152746538; x=1153610538; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=22Marc=20Linsner=22=20 |Subject:RE=3A=20LLDP-MED=20and=20Phone=20BCP=20(Re=3A=20[Ecrit]=20New=20phonebcp draftwassubmitted); X=v=3Dcisco.com=3B=20h=3DFePG0JACQSAT/KhdTbGKsxcOJx0=3D; b=cDQPUZ7gRe4ytRo9LQKtqvKDxh7FBWFbR8jnl8vfWmo/QGxuTnO+U2t/dZym9IG40Oxcu962 CZcnejZ97gsDqMJxEEyXOPwewbcYsTCQG7k7VaJZLwFRiM1YNvaGAxb4; Authentication-Results: sj-dkim-2.cisco.com; header.From=mlinsner@cisco.com; dkim=pass ( 63 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: -2.6 (--) X-Scan-Signature: da41e01217ab11ad82db577473e913ae Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1848162878==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1848162878== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01C6A5E8.72201A20" This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C6A5E8.72201A20 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Please identify the non-mobile application(s) that use geo and are required to convey uncertainty. -Marc- Marc, this has nothing to do with mobile. It is to do with the potential for massive errors to be introduced by the encoding technique used in RFC-3825. Please see appendix A of PIDF-LO profile for more details. _____ From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Wednesday, 12 July 2006 11:34 PM To: Winterbottom, James; 'Stark, Barbara'; 'Andrew Newton'; 'Rohan Mahy' Cc: 'Rosen, Brian'; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) As stated in RFC3825, it is applicable to non-mobile environments. -Marc- _____ From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Tuesday, July 11, 2006 11:39 PM To: Stark, Barbara; Andrew Newton; Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) I would be very cautious about recommending the use of RFC-3825 encoding to report emergency locations given the issues raised at IETF-65 in Dallas that are yet to be adequately resolved. In NENA we put a caveat around its use to the effect that location provided in this manner must be regarded as a point only, and that encodings for resolution must be ignored. Cheers James ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162 ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] ------=_NextPart_000_0043_01C6A5E8.72201A20 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Please identify the non-mobile = application(s) that=20 use geo and are required to convey uncertainty.
 
-Marc-

 

Marc, this = has=20 nothing to do with mobile. It is to do with the potential for massive = errors=20 to be introduced by the encoding technique used in RFC-3825. Please = see=20 appendix A of PIDF-LO profile for more details. 

 <= /P>

 

 

From: Marc=20 Linsner [mailto:mlinsner@cisco.com]
Sent: Wednesday, 12 July 2006 = 11:34=20 PM
To: = Winterbottom, James;=20 'Stark, Barbara'; 'Andrew Newton'; 'Rohan Mahy'
Cc: 'Rosen, Brian';=20 Ecrit@ietf.org
Subject: RE:=20 LLDP-MED and Phone BCP (Re: [Ecrit] New=20 phonebcpdraftwassubmitted)

 

As stated = in RFC3825,=20 it is applicable to non-mobile = environments.

 

-Marc-

 

From:=20 Winterbottom, James [mailto:James.Winterbottom@andrew.com] =
Sent: Tuesday, July 11, 2006 = 11:39=20 PM
To: Stark, = Barbara;=20 Andrew Newton; Rohan Mahy
Cc: Rosen, Brian;=20 Ecrit@ietf.org
Subject: RE:=20 LLDP-MED and Phone BCP (Re: [Ecrit] New=20 phonebcpdraftwassubmitted)

 

I would = be very=20 cautious about recommending the use of RFC-3825 encoding to report = emergency=20 locations given the issues raised at IETF-65 in Dallas that are yet = to be=20 adequately resolved. In NENA we put a caveat around its use to the = effect=20 that location provided in this manner must be regarded as a point = only, and=20 that encodings for resolution must be = ignored.

 

Cheers

James

 

 


---------------------------------------------------------------= ---------------------------------
This=20 message is for the designated recipient only and may
contain = privileged,=20 proprietary, or otherwise private information.
If you have = received it=20 in error, please notify the sender
immediately and delete the = original.=20 Any unauthorized use of
this email is=20 = prohibited.
----------------------------------------------------------= --------------------------------------
[mf2]=20

*****

The = information=20 transmitted is intended only for the person or entity to which it is = addressed and may contain confidential, proprietary, and/or = privileged=20 material. Any review, retransmission, dissemination or other use of, = or=20 taking of any action in reliance upon this information by persons or = entities other than the intended recipient is prohibited. If you = received=20 this in error, please contact the sender and delete the material = from all=20 computers. 162


---------= -------------------------------------------------------------------------= --------------
This=20 message is for the designated recipient only and may
contain = privileged,=20 proprietary, or otherwise private information.
If you have = received it in=20 error, please notify the sender
immediately and delete the = original. Any=20 unauthorized use of
this email is=20 = prohibited.
----------------------------------------------------------= --------------------------------------
[mf2]=20 ------=_NextPart_000_0043_01C6A5E8.72201A20-- --===============1848162878== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1848162878==-- From ecrit-bounces@ietf.org Wed Jul 12 21:49:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0qKB-0001de-HO; Wed, 12 Jul 2006 21:49:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0q7D-0000Fk-QE for Ecrit@ietf.org; Wed, 12 Jul 2006 21:35:43 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0oIy-0000OJ-6U for Ecrit@ietf.org; Wed, 12 Jul 2006 19:39:44 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G0oEp-0000q6-FA for Ecrit@ietf.org; Wed, 12 Jul 2006 19:35:28 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 18:35:22 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Wed, 12 Jul 2006 18:35:22 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Jul 2006 18:35:22 -0500 Message-ID: From: "Winterbottom, James" To: "Marc Linsner" Date: Wed, 12 Jul 2006 18:35:19 -0500 Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 12 Jul 2006 23:35:22.0285 (UTC) FILETIME=[D7D995D0:01C6A60B] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <004201c6a609$f92f4920$e1fc010a@amer.cisco.com> Content-class: urn:content-classes:message Thread-Topic: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) Thread-Index: AcacS01AozzxQH4SRpCO5st6hhUFBQI/jIJwAAaF0/AAFPArAAAQfXfQAAPuxHAAAGMpIA== X-Spam-Score: -2.6 (--) X-Scan-Signature: c021adebe99b05433d94f84a85f41df2 Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0361480027==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0361480027== Content-Type: multipart/alternative; boundary="--=_NextPart_ST_18_35_22_Wednesday_July_12_2006_32671" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ----=_NextPart_ST_18_35_22_Wednesday_July_12_2006_32671 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Marc you are missing the point entirely. No one is required to convey uncertainty, but RFC-3825 stipulates quite clearly how the values returned in option 123 are to be interpreted. The shape described by the encoding in RFC-3825 is either a 4 sided polygon, or a prism, unless you use the maximum resolution, hence uncertainty is part of the interpretation and mobility=20 has absolutely nothing to do with it. =20 Are you suggesting that the way to interpret the values in RFC-3825 is not normative? =20 ________________________________ From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: Thursday, 13 July 2006 9:22 AM To: Winterbottom, James Cc: Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) =20 Please identify the non-mobile application(s) that use geo and are required to convey uncertainty. =20 -Marc- =20 =20 Marc, this has nothing to do with mobile. It is to do with the potential for massive errors to be introduced by the encoding technique used in RFC-3825. Please see appendix A of PIDF-LO profile for more details.=20 =20 =20 =20 =09 ________________________________ From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: Wednesday, 12 July 2006 11:34 PM To: Winterbottom, James; 'Stark, Barbara'; 'Andrew Newton'; 'Rohan Mahy' Cc: 'Rosen, Brian'; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) =20 As stated in RFC3825, it is applicable to non-mobile environments. =20 -Marc- =20 =09 ________________________________ From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]=20 Sent: Tuesday, July 11, 2006 11:39 PM To: Stark, Barbara; Andrew Newton; Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) =20 I would be very cautious about recommending the use of RFC-3825 encoding to report emergency locations given the issues raised at IETF-65 in Dallas that are yet to be adequately resolved. In NENA we put a caveat around its use to the effect that location provided in this manner must be regarded as a point only, and that encodings for resolution must be ignored. =20 Cheers James =20 =20 =09 =09 ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information.=20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. =09 ------------------------------------------------------------------------ ------------------------ [mf2]=20 ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162 =09 =09 ------------------------------------------------------------------------ ------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information.=20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. =09 ------------------------------------------------------------------------ ------------------------ [mf2]=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] ----=_NextPart_ST_18_35_22_Wednesday_July_12_2006_32671 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Marc you are missing the point entirel= y.

No one is required to convey uncertain= ty, but RFC-3825 stipulates quite clearly how the values returned in option 123= are to be interpreted.

The shape described by the encoding in RFC-3825 is either a 4 sided polygon, or a prism, unless you use the maximu= m resolution, hence uncertainty is part of the interpretation and mobility

has absolutely nothing to do with it.<= o:p>

 

Are you suggesting that the way to interpret the values in RFC-3825 is not normative?=

 

From: Marc Lin= sner [mailto:mlinsner@cisco.com]
Sent: Thursday, 13 July 2006= 9:22 AM
To: Winterbottom, James
Cc: Ecrit@ietf.org
Subject: RE: LLDP-MED and Ph= one BCP (Re: [Ecrit] New phonebcpdraftwassubmitted)

 

Please identify the non-mobile application(s) that use geo and are required to convey uncertainty.<= /font>

 

-Marc-

 

 

Marc, this has nothing to do with mobi= le. It is to do with the potential for massive errors to be introduced by the encoding technique used in RFC-3825. Please see appendix A of PIDF-LO profi= le for more details. 

 <= /font>

 

 

From: Marc Lin= sner [mailto:mlinsner@cisco.com]
Sent: Wednesday, 12 July 200= 6 11:34 PM
To: Winterbottom, James; 'St= ark, Barbara'; 'Andrew Newton'; 'Rohan Mahy'
Cc: 'Rosen, Brian'; Ecrit@ie= tf.org
Subject: RE: LLDP-MED and Ph= one BCP (Re: [Ecrit] New phonebcpdraftwassubmitted)

 

As stated in RFC3825, it is applicable= to non-mobile environments.

 

-Marc-

 

From:= Winterbottom, James [mailto:James.Winterbottom@andrew.com]
Sent: Tuesday, July 11, 2006= 11:39 PM
To: Stark, Barbara; Andrew N= ewton; Rohan Mahy
Cc: Rosen, Brian; Ecrit@ietf= =2Eorg
Subject: RE: LLDP-MED and Ph= one BCP (Re: [Ecrit] New phonebcpdraftwassubmitted)

 

I would be very cautious about recommending the use of RFC-3825 encoding to report emergency locations giv= en the issues raised at IETF-65 in Dallas that are yet to be adequately resolv= ed. In NENA we put a caveat around its use to the effect that location provided= in this manner must be regarded as a point only, and that encodings for resolu= tion must be ignored.

 

Cheers

James

 

 


---------------------------------------------------------------------------= ---------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
---------------------------------------------------------------------------= ---------------------
[mf2]

*****

The information transmitted is intended onl= y for the person or entity to which it is addressed and may contain confident= ial, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon thi= s information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and de= lete the material from all computers. 162


---------------------------------------------------------------------------= ---------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
---------------------------------------------------------------------------= ---------------------
[mf2]


-----------------------------------------------------------------------= -------------------------
This message is for the designated recipient o= nly and may
contain privileged, proprietary, or otherwise private inform= ation.
If you have received it in error, please notify the sender
i= mmediately and delete the original. Any unauthorized use of
this email = is prohibited.
---------------------------------------------------------= ---------------------------------------
[mf2] ----=_NextPart_ST_18_35_22_Wednesday_July_12_2006_32671-- --===============0361480027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0361480027==-- From ecrit-bounces@ietf.org Wed Jul 12 21:51:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0qMf-0001td-3f; Wed, 12 Jul 2006 21:51:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0qMd-0001tY-NP for ecrit@ietf.org; Wed, 12 Jul 2006 21:51:39 -0400 Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0qMc-0006yc-HP for ecrit@ietf.org; Wed, 12 Jul 2006 21:51:39 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Wed, 12 Jul 2006 21:51:53 -0400 id 015880DA.44B5A739.000023CC Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <213C72D4-D6FD-4C07-926A-F142C82EADA9@hxr.us> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Andrew Newton Date: Wed, 12 Jul 2006 21:51:36 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ecrit] fetching LoST URI and dialstring via SIP X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On the plane home, I did some more noodling about the proposal's from James regarding the use of SIP to fetch a PSAP URI and dialstring. Con - We already have another mechanism to do this, LoST. Con - There are real world limitations on REGISTER for these functions. Pro - This is handy should the client not have been given the information to contact a LoST server. In both these situations, I believe the clients should obey the same behavior of using these mechanisms as would a LoST seeker. Specifically, it should use them no more than necessary and not just with every REGISTER. In other words, at network attachment time and invalidation of the cached answer (either by going out of region or timeout). Specific comment on draft-polk-ecrit-lost-server-uri-00: It should not be required to communicate location to get the LoST server URI. That is because it is perfectly reasonable to return the local LoST resolver. Specific comment on draft-polk-ecrit-emergency-dialstring-00: The specification of using HTTP seems really out of place and is very underspecified. Additionally, what is the point of doing this considering LoST does it? -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 09:17:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G114M-0004uo-EG; Thu, 13 Jul 2006 09:17:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G114K-0004uj-PK for ecrit@ietf.org; Thu, 13 Jul 2006 09:17:28 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G114J-0003Te-It for ecrit@ietf.org; Thu, 13 Jul 2006 09:17:28 -0400 Received: from [132.219.26.162] (h1aa2-net84db.lab.risq.net [132.219.26.162] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6DDHOoT007008 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 13 Jul 2006 09:17:24 -0400 (EDT) In-Reply-To: <213C72D4-D6FD-4C07-926A-F142C82EADA9@hxr.us> References: <213C72D4-D6FD-4C07-926A-F142C82EADA9@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <21658E3C-26B0-43C8-80B2-CF7868480C98@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] fetching LoST URI and dialstring via SIP Date: Thu, 13 Jul 2006 09:17:22 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org A general comment (that doesn't disagree with yours): Given that we have the SIP communications framework heading to WGLC, I'm baffled by the notion of having ECRIT invent a new configuration mechanism that was explicitly rejected by the SIP WG. As a pure formality, this whole thing violates the SIP change process. Thus, I'm not sure how useful it is to discuss the details. On Jul 12, 2006, at 9:51 PM, Andrew Newton wrote: > On the plane home, I did some more noodling about the proposal's > from James regarding the use of SIP to fetch a PSAP URI and > dialstring. > > Con - We already have another mechanism to do this, LoST. > Con - There are real world limitations on REGISTER for these > functions. > Pro - This is handy should the client not have been given the > information to contact a LoST server. > > In both these situations, I believe the clients should obey the > same behavior of using these mechanisms as would a LoST seeker. > Specifically, it should use them no more than necessary and not > just with every REGISTER. In other words, at network attachment > time and invalidation of the cached answer (either by going out of > region or timeout). _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 09:26:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11Cd-0002K0-6L; Thu, 13 Jul 2006 09:26:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G11Cc-0002Gr-30 for Ecrit@ietf.org; Thu, 13 Jul 2006 09:26:02 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G11Cb-0003ud-IT for Ecrit@ietf.org; Thu, 13 Jul 2006 09:26:02 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 44BB320021; Thu, 13 Jul 2006 09:26:01 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17321-04; Thu, 13 Jul 2006 09:26:00 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id AB1BB20025; Thu, 13 Jul 2006 09:26:00 -0400 (EDT) MIME-Version: 1.0 To: "Marc Linsner" Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: peter_blatherwick@mitel.com Date: Thu, 13 Jul 2006 09:26:00 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 07/13/2006 09:25:59 AM, Serialize complete at 07/13/2006 09:25:59 AM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.3 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: Ecrit@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1040209897==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1040209897== Content-Type: multipart/alternative; boundary="=_alternative 0049C9AB852571AA_=" This is a multipart message in MIME format. --=_alternative 0049C9AB852571AA_= Content-Type: text/plain; charset="us-ascii" [off list] Hi Marc, Assuming you are going to rebut, could you please re-subject the thread? It is now waaaaay off the original topic, distracting, and there may be others interested in the new topic that have fallen asleep. -- Peter "Marc Linsner" 12.07.06 19:21 To: "'Winterbottom, James'" cc: Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) Please identify the non-mobile application(s) that use geo and are required to convey uncertainty. -Marc- Marc, this has nothing to do with mobile. It is to do with the potential for massive errors to be introduced by the encoding technique used in RFC-3825. Please see appendix A of PIDF-LO profile for more details. From: Marc Linsner [mailto:mlinsner@cisco.com] Sent: Wednesday, 12 July 2006 11:34 PM To: Winterbottom, James; 'Stark, Barbara'; 'Andrew Newton'; 'Rohan Mahy' Cc: 'Rosen, Brian'; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) As stated in RFC3825, it is applicable to non-mobile environments. -Marc- From: Winterbottom, James [mailto:James.Winterbottom@andrew.com] Sent: Tuesday, July 11, 2006 11:39 PM To: Stark, Barbara; Andrew Newton; Rohan Mahy Cc: Rosen, Brian; Ecrit@ietf.org Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted) I would be very cautious about recommending the use of RFC-3825 encoding to report emergency locations given the issues raised at IETF-65 in Dallas that are yet to be adequately resolved. In NENA we put a caveat around its use to the effect that location provided in this manner must be regarded as a point only, and that encodings for resolution must be ignored. Cheers James ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] ***** The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162 ------------------------------------------------------------------------------------------------ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ------------------------------------------------------------------------------------------------ [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 0049C9AB852571AA_= Content-Type: text/html; charset="us-ascii"
[off list]
Hi Marc,
Assuming you are going to rebut, could you please re-subject the thread?  It is now waaaaay off the original topic, distracting, and there may be others interested in the new topic that have fallen asleep.
-- Peter



"Marc Linsner" <mlinsner@cisco.com>

12.07.06 19:21

       
        To:        "'Winterbottom, James'" <James.Winterbottom@andrew.com>
        cc:        Ecrit@ietf.org
        Subject:        RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted)



Please identify the non-mobile application(s) that use geo and are required to convey uncertainty.
 
-Marc-

 
Marc, this has nothing to do with mobile. It is to do with the potential for massive errors to be introduced by the encoding technique used in RFC-3825. Please see appendix A of PIDF-LO profile for more details.
 
 
 


From: Marc Linsner [mailto:mlinsner@cisco.com]
Sent: Wednesday, 12 July 2006 11:34 PM
To: Winterbottom, James; 'Stark, Barbara'; 'Andrew Newton'; 'Rohan Mahy'
Cc: 'Rosen, Brian'; Ecrit@ietf.org
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted)
 
As stated in RFC3825, it is applicable to non-mobile environments.
 
-Marc-
 


From: Winterbottom, James [mailto:James.Winterbottom@andrew.com]
Sent: Tuesday, July 11, 2006 11:39 PM
To: Stark, Barbara; Andrew Newton; Rohan Mahy
Cc: Rosen, Brian; Ecrit@ietf.org
Subject: RE: LLDP-MED and Phone BCP (Re: [Ecrit] New phonebcpdraftwassubmitted)
 
I would be very cautious about recommending the use of RFC-3825 encoding to report emergency locations given the issues raised at IETF-65 in Dallas that are yet to be adequately resolved. In NENA we put a caveat around its use to the effect that location provided in this manner must be regarded as a point only, and that encodings for resolution must be ignored.
 
Cheers
James
 
 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

*****

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162


------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2] _______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--=_alternative 0049C9AB852571AA_=-- --===============1040209897== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1040209897==-- From ecrit-bounces@ietf.org Thu Jul 13 14:54:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16Km-0006sb-Fj; Thu, 13 Jul 2006 14:54:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16Kl-0006sT-8e; Thu, 13 Jul 2006 14:54:47 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G16Kk-0007W2-1P; Thu, 13 Jul 2006 14:54:47 -0400 Received: from [132.219.26.162] (h1aa2-net84db.lab.risq.net [132.219.26.162] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6DIsek6015620 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 13 Jul 2006 14:54:41 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Date: Thu, 13 Jul 2006 14:54:40 -0400 To: rai-discuss@ietf.org X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: xcon@ietf.forg, ECRIT Subject: [Ecrit] Schema --> RelaxNG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Based on Rohan's suggestion of sending this to the mailing list: I would suggest that the RAI area declare that new efforts should, by default, use RelaxNG rather than Schema unless there is a strong reason to do otherwise, such as extending existing Schema-specified work. XCON just had the same discussion that ECRIT had, and it seems unnecessary to re-play the same discussion for each new draft and in each RAI working group. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 15:20:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16jN-0001lp-2Y; Thu, 13 Jul 2006 15:20:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16jK-0001le-91 for ecrit@ietf.org; Thu, 13 Jul 2006 15:20:11 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G16jI-0001RG-Qs for ecrit@ietf.org; Thu, 13 Jul 2006 15:20:10 -0400 Received: (qmail invoked by alias); 13 Jul 2006 19:20:07 -0000 Received: from h1f81-net84db.lab.risq.net (EHLO [132.219.31.129]) [132.219.31.129] by mail.gmx.net (mp024) with SMTP; 13 Jul 2006 21:20:07 +0200 X-Authenticated: #29516787 Message-ID: <44B69CEB.3070802@gmx.net> Date: Thu, 13 Jul 2006 15:20:11 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: hgs@cs.columbia.edu Subject: Re: [Ecrit] Schema --> RelaxNG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ecrit@ietf.org, xcon@ietf.org X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, it would be good to know how Relax NG deals with the interworking with existing XML schemas. In ECRIT, for example, we have to deal with the GML schemas that we need to import. I wonder whether someone has experience about this aspect already. Ciao Hannes Working Henning Schulzrinne wrote: > Based on Rohan's suggestion of sending this to the mailing list: > > I would suggest that the RAI area declare that new efforts should, by > default, use RelaxNG rather than Schema unless there is a strong reason > to do otherwise, such as extending existing Schema-specified work. > > XCON just had the same discussion that ECRIT had, and it seems > unnecessary to re-play the same discussion for each new draft and in > each RAI working group. > > Henning > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 15:37:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16zm-0002SM-Bu; Thu, 13 Jul 2006 15:37:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G16zk-0002Rh-Tk for ecrit@ietf.org; Thu, 13 Jul 2006 15:37:08 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G16yE-0002J4-7D for ecrit@ietf.org; Thu, 13 Jul 2006 15:35:35 -0400 Received: from [132.219.26.162] (h1aa2-net84db.lab.risq.net [132.219.26.162] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6DJZTWq023009 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 13 Jul 2006 15:35:34 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Henning Schulzrinne Date: Thu, 13 Jul 2006 15:35:28 -0400 X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ecrit] LoST #2: geo + civic X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think we narrowed the disagreement in the meeting to two questions: (a) Is PSAP (and service resolution) likely to depend on floor and room number? (b) If (a) is true, how likely is it that systems actually provide geo plus room numbers? Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 15:39:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G172P-0003cY-Ry; Thu, 13 Jul 2006 15:39:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G172P-0003cT-Ch for ecrit@ietf.org; Thu, 13 Jul 2006 15:39:53 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G172N-0002qM-5A for ecrit@ietf.org; Thu, 13 Jul 2006 15:39:53 -0400 Received: from [132.219.26.162] (h1aa2-net84db.lab.risq.net [132.219.26.162] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6DJdkdP002495 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 13 Jul 2006 15:39:50 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <80A8567E-4D44-4CB5-B43D-4B1E4A35F195@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Henning Schulzrinne Date: Thu, 13 Jul 2006 15:39:45 -0400 X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ecrit] LoST #5: Boundary hints X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I would propose that we always return a region hint to the querier. A separate LoST query is then used, if desired, to get the region. This had the advantage that there is no special case of requesting or not requesting boundaries (since the identifier is short) and, more importantly, that the common case that multiple services have the same service boundaries can be handled more efficiently since they'd just use the same identifier. Something like Server returns: 1234 Client queries: 1234 Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 15:42:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G174w-0003q6-Mn; Thu, 13 Jul 2006 15:42:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G174u-0003q0-PW for ecrit@ietf.org; Thu, 13 Jul 2006 15:42:28 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G174t-00032t-II for ecrit@ietf.org; Thu, 13 Jul 2006 15:42:28 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G174l-00056i-Qx; Thu, 13 Jul 2006 14:42:20 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'ECRIT'" Subject: RE: [Ecrit] LoST #2: geo + civic Date: Thu, 13 Jul 2006 15:42:22 -0400 Message-ID: <035901c6a6b4$77831040$bc1cdb84@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acams7mb8GY/i0G0TgmL1OpQ5Fqd9gAAIg3w X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org In my opinion, the answer to (a) is "yes", and the answer to (b) is "not very" Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, July 13, 2006 3:35 PM To: ECRIT Subject: [Ecrit] LoST #2: geo + civic I think we narrowed the disagreement in the meeting to two questions: (a) Is PSAP (and service resolution) likely to depend on floor and room number? (b) If (a) is true, how likely is it that systems actually provide geo plus room numbers? Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 15:49:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17C1-0004rE-FU; Thu, 13 Jul 2006 15:49:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G17C0-0004r9-B7 for ecrit@ietf.org; Thu, 13 Jul 2006 15:49:48 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G17Bz-0003jb-48 for ecrit@ietf.org; Thu, 13 Jul 2006 15:49:48 -0400 Received: from [132.219.26.162] (h1aa2-net84db.lab.risq.net [132.219.26.162] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6DJnkKX004311 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 13 Jul 2006 15:49:46 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Henning Schulzrinne Date: Thu, 13 Jul 2006 15:49:36 -0400 X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] LoST #4: service URN in response message X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Proposed resolution: If the specific service is not available for a particular location, the server MAY return an alternate service. If it does so, it MUST indicate the actual service returned (i.e., its service URN). There is no restriction on the new service offered. Thus, it is possible that a query for urn:service:sos.ambulance returns urn:service:undertaker A server MAY instead return an error response indicating that the service is not available. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 16:52:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18Ap-0008Nx-DB; Thu, 13 Jul 2006 16:52:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18An-0008Ns-TY for ecrit@ietf.org; Thu, 13 Jul 2006 16:52:37 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G18Am-0007jB-Lh for ecrit@ietf.org; Thu, 13 Jul 2006 16:52:37 -0400 Received: from [132.219.26.162] (h1aa2-net84db.lab.risq.net [132.219.26.162] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6DKqZ5n015261 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 13 Jul 2006 16:52:36 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <6B6C53DC-F8CF-48BA-B37C-BD3EF989CC30@cs.columbia.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ECRIT From: Henning Schulzrinne Date: Thu, 13 Jul 2006 16:52:35 -0400 X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Ecrit] LoST #8: Dial strings X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org There are two issues: (1) How to integrate this into the local dial plan. (2) Whether LoST should support local (corporate) dial plans, such as 9 (wait for dial tone) 911 In my opinion, since we have assumed that LoST services can be provided either by the access provider or the (SIP) service provider, having a LoST server provide the precise dial-out sequence is dangerous as only the SIP service provider determines the prefix part. Even on my office SIP phone at Columbia, I have two service providers: the local one and a commercial service provider that gives me better international rates... Thus, I don't think it's a good idea to specify anything except the actual NANPA or equivalent digit strings. In other words, rosen- dialstrings is probably not helpful, at least not without very tight restrictions on the deployment model and with the potential for some unpleasant surprises. As a separate item, more relevant to (say) the SIPPING config work, would be to provide a way to integrate emergency/service dial strings into the overall dial plan by defining a variable. In other words, the dial plan would have something like 9,$ where the $ is replaced by the UA-determined emergency digit string (I'm using comma for pause here). The local dialplan provider can then decide where this element resides in the dial plan and whether to specify something like 9,$T In short, for the LoST document I propose that we use a simple digit sequence (plus *, #) only. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 17:04:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18ME-0001m6-Ul; Thu, 13 Jul 2006 17:04:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G18MD-0001m0-AV for ecrit@ietf.org; Thu, 13 Jul 2006 17:04:25 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G18MA-0008SP-LU for ecrit@ietf.org; Thu, 13 Jul 2006 17:04:25 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G18M1-0002Mz-Q6; Thu, 13 Jul 2006 16:04:14 -0500 From: "Brian Rosen" To: "'Henning Schulzrinne'" , "'ECRIT'" Subject: RE: [Ecrit] LoST #8: Dial strings Date: Thu, 13 Jul 2006 17:04:17 -0400 Message-ID: <039b01c6a6bf$e926b430$bc1cdb84@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <6B6C53DC-F8CF-48BA-B37C-BD3EF989CC30@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcamvkZLrEqgMRcjTQyTtfiAJ1R80QAAL6Pg X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I have no problem with this resolution of the issue. I think sip-config is the way to put "home" dialstrings into the phone. We should probably have the prefix separate and used for both home and local/visited dialstrings. Since I want to have a "manually configured" location possibility, also as a sip-config thing, I'll volunteer to put a draft together on this. The LoST draft won't need to reference it; we'll do that in -phonebcp Brian -----Original Message----- From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] Sent: Thursday, July 13, 2006 4:53 PM To: ECRIT Subject: [Ecrit] LoST #8: Dial strings There are two issues: (1) How to integrate this into the local dial plan. (2) Whether LoST should support local (corporate) dial plans, such as 9 (wait for dial tone) 911 In my opinion, since we have assumed that LoST services can be provided either by the access provider or the (SIP) service provider, having a LoST server provide the precise dial-out sequence is dangerous as only the SIP service provider determines the prefix part. Even on my office SIP phone at Columbia, I have two service providers: the local one and a commercial service provider that gives me better international rates... Thus, I don't think it's a good idea to specify anything except the actual NANPA or equivalent digit strings. In other words, rosen- dialstrings is probably not helpful, at least not without very tight restrictions on the deployment model and with the potential for some unpleasant surprises. As a separate item, more relevant to (say) the SIPPING config work, would be to provide a way to integrate emergency/service dial strings into the overall dial plan by defining a variable. In other words, the dial plan would have something like 9,$ where the $ is replaced by the UA-determined emergency digit string (I'm using comma for pause here). The local dialplan provider can then decide where this element resides in the dial plan and whether to specify something like 9,$T In short, for the LoST document I propose that we use a simple digit sequence (plus *, #) only. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 18:28:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19fh-0007S3-Vq; Thu, 13 Jul 2006 18:28:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19fg-0007R9-5Z for ecrit@ietf.org; Thu, 13 Jul 2006 18:28:36 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G19eg-0007ru-NZ for ecrit@ietf.org; Thu, 13 Jul 2006 18:27:36 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1G19eg0R6l-0001yF; Fri, 14 Jul 2006 00:27:34 +0200 Content-Type: text/plain; charset=utf-8 To: Hannes.Tschofenig@gmx.net, ecrit@ietf.org From: admin Date: Thu, 13 Jul 2006 22:22:01 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1152829321.54.0.981891460442.issue7@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ecrit] [issue7] Adding Additional Info to LoST Response X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org admin added the comment: As discussed in the ECRIT IETF#66 working group session we are not going to= add this functionality to LoST. ---------- status: chatting -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 18:28:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19g1-0007XI-Hq; Thu, 13 Jul 2006 18:28:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19g0-0007WN-6v for ecrit@ietf.org; Thu, 13 Jul 2006 18:28:56 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G19cB-0007SJ-4e for ecrit@ietf.org; Thu, 13 Jul 2006 18:25:00 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1G19cA14zl-00047b; Fri, 14 Jul 2006 00:24:58 +0200 Content-Type: text/plain; charset=utf-8 To: Hannes.Tschofenig@gmx.net, ecrit@ietf.org From: admin Date: Thu, 13 Jul 2006 22:19:26 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1152829166.0.0.598021349419.issue1@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ecrit] [issue1] Do we need a default service URN for the LoST query? X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org admin added the comment: It seems that we decided to mandate the usage of a service identifier in the LoST query. The current LoST draft already makes the 'service' element mand= atory. ---------- status: chatting -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 18:29:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19gr-0007qZ-9J; Thu, 13 Jul 2006 18:29:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19gp-0007nj-RZ for ecrit@ietf.org; Thu, 13 Jul 2006 18:29:47 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G19go-0008J3-Ev for ecrit@ietf.org; Thu, 13 Jul 2006 18:29:47 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1G19gn2FFZ-0005Z5; Fri, 14 Jul 2006 00:29:45 +0200 Content-Type: text/plain; charset=utf-8 To: Hannes.Tschofenig@gmx.net, ecrit@ietf.org From: admin Date: Thu, 13 Jul 2006 22:24:13 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1152829453.27.0.585320556935.issue10@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ecrit] [issue10] Extensibility of the LoST Query X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org admin added the comment: As discussed in the ECRIT IETF#66 working group session we do not need to provide additional functionality in LoST. We do need to make sure that the schema provides enough extension points. ---------- status: chatting -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 18:29:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19gr-0007rP-Ea; Thu, 13 Jul 2006 18:29:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19gq-0007nj-30 for ecrit@ietf.org; Thu, 13 Jul 2006 18:29:48 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G19VW-0005Dl-IP for ecrit@ietf.org; Thu, 13 Jul 2006 18:18:07 -0400 Received: (qmail invoked by alias); 13 Jul 2006 22:18:05 -0000 Received: from h1f81-net84db.lab.risq.net (EHLO [132.219.31.129]) [132.219.31.129] by mail.gmx.net (mp042) with SMTP; 14 Jul 2006 00:18:05 +0200 X-Authenticated: #29516787 Message-ID: <44B6C69F.5070405@gmx.net> Date: Thu, 13 Jul 2006 18:18:07 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ecrit] Open Issues with LoST X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, Henning gave a nice presentation about the open issues in LoST. See http://www3.ietf.org/proceedings/06jul/slides/ecrit-2.ppt We are going to walk through the open issues and your participation is important to make good progress. Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 18:32:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19jc-00007k-69; Thu, 13 Jul 2006 18:32:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19ja-00007f-Da for ecrit@ietf.org; Thu, 13 Jul 2006 18:32:38 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G19jZ-0000DI-15 for ecrit@ietf.org; Thu, 13 Jul 2006 18:32:38 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1G19jY15lX-0002mk; Fri, 14 Jul 2006 00:32:36 +0200 Content-Type: text/plain; charset=utf-8 To: Hannes.Tschofenig@gmx.net, ecrit@ietf.org From: admin Date: Thu, 13 Jul 2006 22:27:04 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1152829624.0.0.140491637629.issue6@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ecrit] [issue6] Loop Detection X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org admin added the comment: As discussed in the ECRIT IETF#66 working group session the 'via' mechanism= will be used. ---------- title: 'Authority' Attribute in LoST Response -> Loop Detection __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 18:41:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19sI-00013b-Bk; Thu, 13 Jul 2006 18:41:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G19sH-00013N-VY for ecrit@ietf.org; Thu, 13 Jul 2006 18:41:37 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G19sG-0000wg-M0 for ecrit@ietf.org; Thu, 13 Jul 2006 18:41:37 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G19s7-00005t-NH; Thu, 13 Jul 2006 17:41:28 -0500 From: "Brian Rosen" To: "'LoST Issue Tracker'" Subject: RE: [Ecrit] [issue7] Adding Additional Info to LoST Response Date: Thu, 13 Jul 2006 18:41:32 -0400 Message-ID: <03c501c6a6cd$7f109ee0$bc1cdb84@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <1152829321.54.0.981891460442.issue7@http://www.tschofenig.priv.at> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acamy60jc0eafByVQzWxMR2lVZu48wAAKO6w X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I don't remember this being discussed, but perhaps I missed it, or we aren't talking about the same thing. I would like to have an optional URI able to be returned in the response which was "additional information" about the location. For the LoST spec, I would propose that no limitation on scheme, or resolution processes for this URI be specified; it's just a URI. In practice, this may be locally defined. That works because the PSAP serving the location is "local" to the location. Of course, authentication would have to be required to dereference this information. The intention is to have a place to deliver to a PSAP information like floor plans, contact information, environmental information, etc. about this location. This is currently part of the NENA i3 spec. Since the actual PSAP that gets a call may change depending on congestion, failures, etc, the information cannot be kept at the PSAP. Brian -----Original Message----- From: admin [mailto:hannes.tschofenig@siemens.com] Sent: Thursday, July 13, 2006 6:22 PM To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org Subject: [Ecrit] [issue7] Adding Additional Info to LoST Response admin added the comment: As discussed in the ECRIT IETF#66 working group session we are not going to add this functionality to LoST. ---------- status: chatting -> done-cbb __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 18:50:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1A0e-0001eH-Iq; Thu, 13 Jul 2006 18:50:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1A0d-0001e9-Hp for ecrit@ietf.org; Thu, 13 Jul 2006 18:50:15 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1A0c-0002Uk-4o for ecrit@ietf.org; Thu, 13 Jul 2006 18:50:15 -0400 Received: from [213.239.234.98] (helo=[213.239.196.40]) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1G1A0b1pcZ-0005Yu; Fri, 14 Jul 2006 00:50:13 +0200 Content-Type: text/plain; charset=utf-8 To: Hannes.Tschofenig@gmx.net, ecrit@ietf.org From: admin Date: Thu, 13 Jul 2006 22:44:41 +0000 X-Roundup-Name: LoST Issue Tracker X-Roundup-Loop: hello X-Roundup-Version: 0.8.2 MIME-Version: 1.0 Message-Id: <1152830681.13.0.178259483035.issue3@http://www.tschofenig.priv.at> Content-Transfer-Encoding: quoted-printable X-Provags-ID: kundenserver.de abuse@kundenserver.de login:518a04bce8f5fdb19ebc1cc661140948 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Subject: [Ecrit] [issue3] List all Services Functionality X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: LoST Issue Tracker List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org admin added the comment: The current draft indicates already that the listService query aims to retu= rn the immediate child elements only. =20 However, the statement needs to be made more explicit. =20 A comment was raised during the meeting that the listServices query current= ly does not contain location information. This needs to be added to the next d= raft version. __________________________________________________ LoST Issue Tracker __________________________________________________ _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 13 19:29:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1AcR-0001Iv-9z; Thu, 13 Jul 2006 19:29:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1AcP-0001Iq-O1 for ecrit@ietf.org; Thu, 13 Jul 2006 19:29:17 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1AcO-0005dP-Eh for ecrit@ietf.org; Thu, 13 Jul 2006 19:29:17 -0400 Received: from [132.219.26.162] (h1aa2-net84db.lab.risq.net [132.219.26.162] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6DNT6Xv003354 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Thu, 13 Jul 2006 19:29:06 -0400 (EDT) In-Reply-To: <03c501c6a6cd$7f109ee0$bc1cdb84@cis.neustar.com> References: <03c501c6a6cd$7f109ee0$bc1cdb84@cis.neustar.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88F0970C-FECA-44E9-9EDE-8E99C9677ABC@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] [issue7] Adding Additional Info to LoST Response Date: Thu, 13 Jul 2006 19:29:05 -0400 To: "Brian Rosen" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org At least in my interpretation, Issue 7 is not quite what you describe, but rather about allowing to annotate services that get returned in some machine-readable format, which may well be service- dependent (distinguished by name spaces). For example, you could imagine returning some kind of service quality indication for non- PSAP services. I''m a bit confused by the service you envision. I'm interpreting this as implying a pointer to some kind of WebDAV-like service where citizens can upload documents about themselves or about a particular location, such as a building. Ted, Hannes and I discussed a slightly more general approach, namely that a response can return a list of distinct URLs. A slight extension is to label the function of that URL, as in sip:help@example.gov http://upload.example.gov mailto:help@example.gov I don't know if 'communications' and 'description' are the only labels; I suspect there are others, such as "finding out more information about the service provider". I'll also note that just specifying a URL without some fairly elaborate protocol mechanisms is probably of little value, unless this is simply a web page that has a web form and allows random citizens to upload documents for any location or person. On Jul 13, 2006, at 6:41 PM, Brian Rosen wrote: > I don't remember this being discussed, but perhaps I missed it, or > we aren't > talking about the same thing. > > I would like to have an optional URI able to be returned in the > response > which was "additional information" about the location. For the > LoST spec, I > would propose that no limitation on scheme, or resolution processes > for this > URI be specified; it's just a URI. In practice, this may be locally > defined. That works because the PSAP serving the location is > "local" to the > location. Of course, authentication would have to be required to > dereference this information. > > The intention is to have a place to deliver to a PSAP information > like floor > plans, contact information, environmental information, etc. about this > location. This is currently part of the NENA i3 spec. Since the > actual > PSAP that gets a call may change depending on congestion, failures, > etc, the > information cannot be kept at the PSAP. > > Brian > > -----Original Message----- > From: admin [mailto:hannes.tschofenig@siemens.com] > Sent: Thursday, July 13, 2006 6:22 PM > To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: [Ecrit] [issue7] Adding Additional Info to LoST Response > > > admin added the comment: > > As discussed in the ECRIT IETF#66 working group session we are not > going to > add > this functionality to LoST. > > ---------- > status: chatting -> done-cbb > > __________________________________________________ > LoST Issue Tracker > > __________________________________________________ > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 14 08:29:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1MnX-000396-4b; Fri, 14 Jul 2006 08:29:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1MnV-000391-Dq for ecrit@ietf.org; Fri, 14 Jul 2006 08:29:33 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1MnU-00039v-5l for ecrit@ietf.org; Fri, 14 Jul 2006 08:29:33 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 07:29:31 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 14 Jul 2006 07:29:31 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 07:29:30 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" , "ECRIT" Date: Fri, 14 Jul 2006 07:29:27 -0500 Subject: RE: [Ecrit] LoST #5: Boundary hints MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 14 Jul 2006 12:29:30.0446 (UTC) FILETIME=[27863EE0:01C6A741] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <80A8567E-4D44-4CB5-B43D-4B1E4A35F195@cs.columbia.edu> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] LoST #5: Boundary hints Thread-Index: AcamtB8e5OyBC43MSKC4H2gefYCb0AAjN+Dg X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Why not provide a URI to the object rather than an opaque string? > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, 14 July 2006 5:40 AM > To: ECRIT > Subject: [Ecrit] LoST #5: Boundary hints >=20 > I would propose that we always return a region hint to the querier. A > separate LoST query is then used, if desired, to get the region. This > had the advantage that there is no special case of requesting or not > requesting boundaries (since the identifier is short) and, more > importantly, that the common case that multiple services have the > same service boundaries can be handled more efficiently since they'd > just use the same identifier. Something like >=20 > Server returns: > 1234 >=20 > Client queries: >=20 > > 1234 > >=20 >=20 > Henning >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 14 08:30:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1MoN-0003Hs-K9; Fri, 14 Jul 2006 08:30:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1MoM-0003Hn-8w for ecrit@ietf.org; Fri, 14 Jul 2006 08:30:26 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1MoL-0003CZ-14 for ecrit@ietf.org; Fri, 14 Jul 2006 08:30:26 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 07:30:24 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 14 Jul 2006 07:30:24 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 07:30:24 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" , "ECRIT" Date: Fri, 14 Jul 2006 07:30:20 -0500 Subject: RE: [Ecrit] LoST #4: service URN in response message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 14 Jul 2006 12:30:24.0105 (UTC) FILETIME=[4781F590:01C6A741] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: Content-class: urn:content-classes:message Thread-Topic: [Ecrit] LoST #4: service URN in response message Thread-Index: AcamtYMiMgnUjOHDTmSefRo8EmqiVAAi7GDQ X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Do we have any additional guidance that would be helpful, or is that the extent of your proposed guidance? > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, 14 July 2006 5:50 AM > To: ECRIT > Subject: [Ecrit] LoST #4: service URN in response message >=20 > Proposed resolution: If the specific service is not available for a > particular location, the server MAY return an alternate service. If > it does so, it MUST indicate the actual service returned (i.e., its > service URN). There is no restriction on the new service offered. > Thus, it is possible that a query for >=20 > urn:service:sos.ambulance >=20 > returns >=20 > urn:service:undertaker >=20 > A server MAY instead return an error response indicating that the > service is not available. >=20 > Henning >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 14 09:20:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Nag-0008B0-79; Fri, 14 Jul 2006 09:20:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Naf-0008Av-8Y for ecrit@ietf.org; Fri, 14 Jul 2006 09:20:21 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Nae-0004vS-1Q for ecrit@ietf.org; Fri, 14 Jul 2006 09:20:21 -0400 Received: from [132.219.27.189] (h1bbd-net84db.lab.risq.net [132.219.27.189] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6EDJjgu004559 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 14 Jul 2006 09:20:19 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <905619EE-ECFD-47F5-AB08-FEFEA64E5BFF@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST #4: service URN in response message Date: Fri, 14 Jul 2006 09:20:19 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org What kind of guidance do you have in mind? On Jul 14, 2006, at 8:30 AM, Thomson, Martin wrote: > Do we have any additional guidance that would be helpful, or is > that the > extent of your proposed guidance? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 14 09:24:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1NeP-0000YI-MS; Fri, 14 Jul 2006 09:24:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1NeP-0000YD-9o for ecrit@ietf.org; Fri, 14 Jul 2006 09:24:13 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1NeN-00052j-Ss for ecrit@ietf.org; Fri, 14 Jul 2006 09:24:13 -0400 Received: (qmail invoked by alias); 14 Jul 2006 13:24:10 -0000 Received: from h1f81-net84db.lab.risq.net (EHLO [132.219.31.129]) [132.219.31.129] by mail.gmx.net (mp037) with SMTP; 14 Jul 2006 15:24:10 +0200 X-Authenticated: #29516787 Message-ID: <44B79AFE.7030004@gmx.net> Date: Fri, 14 Jul 2006 09:24:14 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomson, Martin" Subject: Re: [Ecrit] LoST #5: Boundary hints References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Why do you think that a URI would be more useful in this context? Do you agree with the proposal Henning made? Thomson, Martin wrote: > Why not provide a URI to the object rather than an opaque string? > > >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Friday, 14 July 2006 5:40 AM >>To: ECRIT >>Subject: [Ecrit] LoST #5: Boundary hints >> >>I would propose that we always return a region hint to the querier. A >>separate LoST query is then used, if desired, to get the region. This >>had the advantage that there is no special case of requesting or not >>requesting boundaries (since the identifier is short) and, more >>importantly, that the common case that multiple services have the >>same service boundaries can be handled more efficiently since they'd >>just use the same identifier. Something like >> >>Server returns: >>1234 >> >>Client queries: >> >> >>1234 >> >> >> >>Henning >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 14 09:33:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1NnM-0002HZ-2J; Fri, 14 Jul 2006 09:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Nmz-00025A-Hq for ecrit@ietf.org; Fri, 14 Jul 2006 09:33:05 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Nmx-0005G7-7y for ecrit@ietf.org; Fri, 14 Jul 2006 09:33:05 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 08:33:02 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 14 Jul 2006 08:33:02 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 08:33:01 -0500 Message-ID: From: "Thomson, Martin" To: "Hannes Tschofenig" Date: Fri, 14 Jul 2006 08:33:01 -0500 Subject: RE: [Ecrit] LoST #5: Boundary hints MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 14 Jul 2006 13:33:01.0363 (UTC) FILETIME=[07020830:01C6A74A] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <44B79AFE.7030004@gmx.net> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] LoST #5: Boundary hints Thread-Index: AcanSMuHCDCtxq97TjO1zPFaq978nAAAJyJA X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Hannes, I'm not sure that I can agree at this stage... On a higher level, there are two options: 1. The information is only included upon specific request, but it is always included "by-value". 2. The information is included "by-reference". Both achieve the goal of reducing the size of the response message. I really don't care which is used. The second then has two options: a. The "key" is an opaque string, which requires specific protocol support to retrieve. b. The "key" is a URI. Retrieval depends on the type of URI. Both of these secondary issues require further work before they can be properly evaluated against each other - i.e. what does the URI look like. Regards, Martin > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, 14 July 2006 11:24 PM > To: Thomson, Martin > Cc: Henning Schulzrinne; ECRIT > Subject: Re: [Ecrit] LoST #5: Boundary hints >=20 > Why do you think that a URI would be more useful in this context? >=20 > Do you agree with the proposal Henning made? >=20 >=20 > Thomson, Martin wrote: > > Why not provide a URI to the object rather than an opaque string? > > > > > >>-----Original Message----- > >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>Sent: Friday, 14 July 2006 5:40 AM > >>To: ECRIT > >>Subject: [Ecrit] LoST #5: Boundary hints > >> > >>I would propose that we always return a region hint to the querier. A > >>separate LoST query is then used, if desired, to get the region. This > >>had the advantage that there is no special case of requesting or not > >>requesting boundaries (since the identifier is short) and, more > >>importantly, that the common case that multiple services have the > >>same service boundaries can be handled more efficiently since they'd > >>just use the same identifier. Something like > >> > >>Server returns: > >>1234 > >> > >>Client queries: > >> > >> > >>1234 > >> > >> > >> > >>Henning > >> > >>_______________________________________________ > >>Ecrit mailing list > >>Ecrit@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ecrit > > > > > > ------------------------------------------------------------------------ > ------------------------ > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > ------------------------------------------------------------------------ > ------------------------ > > [mf2] > > > > _______________________________________________ > > Ecrit mailing list > > Ecrit@ietf.org > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 14 09:39:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1NtU-0000O4-FR; Fri, 14 Jul 2006 09:39:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1NtS-0000Jb-9d for ecrit@ietf.org; Fri, 14 Jul 2006 09:39:46 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1NtR-0006D1-2C for ecrit@ietf.org; Fri, 14 Jul 2006 09:39:46 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 08:39:44 -0500 Received: from Unknown [10.3.20.69] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Fri, 14 Jul 2006 08:39:44 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Jul 2006 08:39:43 -0500 Message-ID: From: "Thomson, Martin" To: "Henning Schulzrinne" Date: Fri, 14 Jul 2006 08:39:44 -0500 Subject: RE: [Ecrit] LoST #4: service URN in response message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 14 Jul 2006 13:39:43.0761 (UTC) FILETIME=[F6DB1810:01C6A74A] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <905619EE-ECFD-47F5-AB08-FEFEA64E5BFF@cs.columbia.edu> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] LoST #4: service URN in response message Thread-Index: AcanSEH5JmCboYRPQDmTZKCKgzldOAAAdIHg X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org We talked about the different directions in the "tree" that the server could "climb" before this. Your response threw all of that out - I just wanted to make sure that this was intentional. One piece of guidance that is useful is to say that "urn:service:sos" always has a result available for it. Another piece, which is probably the tricky part, describes which way the server can automatically climb. Upwards, sideways, or wherever are the three options. If you don't have at least a little guidance, then it becomes harder to make an automated decision at the UA when it receives this information. In other words - some text here helps both the server implementers/administrators (they can make informed decisions about what they will do) but it also informs resolver implementers, who sometimes have to make an automated decision when urn:service:undertaker comes back. Not having any additional guidance means that it's harder to achieve consistency between implementations, which, I think, would be advantageous. Sorry, but I don't have the answers on this one, yet. Martin > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, 14 July 2006 11:20 PM > To: Thomson, Martin > Cc: ECRIT > Subject: Re: [Ecrit] LoST #4: service URN in response message >=20 > What kind of guidance do you have in mind? >=20 > On Jul 14, 2006, at 8:30 AM, Thomson, Martin wrote: >=20 > > Do we have any additional guidance that would be helpful, or is > > that the > > extent of your proposed guidance? >=20 ---------------------------------------------------------------------------= --------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. =20 If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------= --------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 14 09:45:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Nyp-0001L9-Ka; Fri, 14 Jul 2006 09:45:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Nyo-0001L0-Di for ecrit@ietf.org; Fri, 14 Jul 2006 09:45:18 -0400 Received: from jalapeno.cc.columbia.edu ([128.59.29.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Nyn-0007m5-6n for ecrit@ietf.org; Fri, 14 Jul 2006 09:45:18 -0400 Received: from [132.219.27.189] (h1bbd-net84db.lab.risq.net [132.219.27.189] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by jalapeno.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6EDjEZF025699 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 14 Jul 2006 09:45:14 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST #4: service URN in response message Date: Fri, 14 Jul 2006 09:45:13 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.5 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On Jul 14, 2006, at 9:39 AM, Thomson, Martin wrote: > We talked about the different directions in the "tree" that the server > could "climb" before this. Your response threw all of that out - I > just > wanted to make sure that this was intentional. Yes, since I interpreted this to be the consensus in the WG meeting (please see the minutes). > > One piece of guidance that is useful is to say that "urn:service:sos" > always has a result available for it. I believe that such operational advice is best encapsulated in the phone-bcp document. LoST is not limited to service:sos > > Another piece, which is probably the tricky part, describes which way > the server can automatically climb. Upwards, sideways, or wherever > are > the three options. If you don't have at least a little guidance, then > it becomes harder to make an automated decision at the UA when it > receives this information. In other words - some text here helps both > the server implementers/administrators (they can make informed > decisions > about what they will do) but it also informs resolver implementers, > who > sometimes have to make an automated decision when > urn:service:undertaker > comes back. There is no climbing, up, down or otherwise. The server decides for each service either to offer a "real" service, if available, or to offer a substitution service. This is a matter of local policy; I don't see how you can usefully automate that. Again, during the WG session, a number of examples were offered where blindly going "up" the service tree would not be desirable. > > Not having any additional guidance means that it's harder to achieve > consistency between implementations, which, I think, would be > advantageous. > I don't think such guidance is necessary for protocol interoperability. > Sorry, but I don't have the answers on this one, yet. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 14 09:56:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1O9e-0006T3-2z; Fri, 14 Jul 2006 09:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1O9c-0006JQ-HS for ecrit@ietf.org; Fri, 14 Jul 2006 09:56:28 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1O9b-0001G2-36 for ecrit@ietf.org; Fri, 14 Jul 2006 09:56:28 -0400 Received: (qmail invoked by alias); 14 Jul 2006 13:49:45 -0000 Received: from h1f81-net84db.lab.risq.net (EHLO [132.219.31.129]) [132.219.31.129] by mail.gmx.net (mp033) with SMTP; 14 Jul 2006 15:49:45 +0200 X-Authenticated: #29516787 Message-ID: <44B7A0FE.5020804@gmx.net> Date: Fri, 14 Jul 2006 09:49:50 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomson, Martin" Subject: Re: [Ecrit] LoST #4: service URN in response message References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Martin, with Hennings proposal we have a lot of freedom for the party that operates the LoST server. In some sense this is good since they know the services best. Here is an example: Imagine there is a region that only understands 'urn:service:sos' but not 'urn:service:sos.fire', 'urn:service:sos.ambulance', and 'urn:service:sos.police'. If a LoST client asks for 'urn:service:sos.fire' then it could get: * 'urn:service:sos' or * 'urn:service:sos.fire' with the values of 'urn:service:sos' being populated to 'urn:service:sos.fire' Another example: Imagine there is a region that only understands 'urn:service:sos.fire', 'urn:service:sos.ambulance', and 'urn:service:sos.police' but it does not understand 'urn:service:sos'. If a LoST client asks for 'urn:service:sos' what would it get? We probably need to state what it means if the LoST client receives a response that indicates 'I couldn't provide a response to your request based on urn:service:sos.ambulance but I have something else for you.' I am not sure what the LoST client can usefully do in this case. Ciao Hannes Thomson, Martin wrote: > Do we have any additional guidance that would be helpful, or is that the > extent of your proposed guidance? > > >>-----Original Message----- >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>Sent: Friday, 14 July 2006 5:50 AM >>To: ECRIT >>Subject: [Ecrit] LoST #4: service URN in response message >> >>Proposed resolution: If the specific service is not available for a >>particular location, the server MAY return an alternate service. If >>it does so, it MUST indicate the actual service returned (i.e., its >>service URN). There is no restriction on the new service offered. >>Thus, it is possible that a query for >> >>urn:service:sos.ambulance >> >>returns >> >>urn:service:undertaker >> >>A server MAY instead return an error response indicating that the >>service is not available. >> >>Henning >> >>_______________________________________________ >>Ecrit mailing list >>Ecrit@ietf.org >>https://www1.ietf.org/mailman/listinfo/ecrit > > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 14 09:59:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OCU-0007MZ-6W; Fri, 14 Jul 2006 09:59:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1OCT-0007MU-CV for ecrit@ietf.org; Fri, 14 Jul 2006 09:59:25 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G1OCR-0001ze-TK for ecrit@ietf.org; Fri, 14 Jul 2006 09:59:25 -0400 Received: (qmail invoked by alias); 14 Jul 2006 13:59:23 -0000 Received: from h1f81-net84db.lab.risq.net (EHLO [132.219.31.129]) [132.219.31.129] by mail.gmx.net (mp027) with SMTP; 14 Jul 2006 15:59:23 +0200 X-Authenticated: #29516787 Message-ID: <44B7A33F.30108@gmx.net> Date: Fri, 14 Jul 2006 09:59:27 -0400 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Thomson, Martin" Subject: Re: [Ecrit] LoST #5: Boundary hints References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Martin, since the identifier is only pointing to the service boundary I wonder whether it is necessary to use a protocol other than LoST. Ciao Hannes Thomson, Martin wrote: > Hi Hannes, > > I'm not sure that I can agree at this stage... > > On a higher level, there are two options: > > 1. The information is only included upon specific request, but it is > always included "by-value". > 2. The information is included "by-reference". > > Both achieve the goal of reducing the size of the response message. I > really don't care which is used. The second then has two options: > > a. The "key" is an opaque string, which requires specific protocol > support to retrieve. > b. The "key" is a URI. Retrieval depends on the type of URI. > > Both of these secondary issues require further work before they can be > properly evaluated against each other - i.e. what does the URI look > like. > > Regards, > Martin > > >>-----Original Message----- >>From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >>Sent: Friday, 14 July 2006 11:24 PM >>To: Thomson, Martin >>Cc: Henning Schulzrinne; ECRIT >>Subject: Re: [Ecrit] LoST #5: Boundary hints >> >>Why do you think that a URI would be more useful in this context? >> >>Do you agree with the proposal Henning made? >> >> >>Thomson, Martin wrote: >> >>>Why not provide a URI to the object rather than an opaque string? >>> >>> >>> >>>>-----Original Message----- >>>>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] >>>>Sent: Friday, 14 July 2006 5:40 AM >>>>To: ECRIT >>>>Subject: [Ecrit] LoST #5: Boundary hints >>>> >>>>I would propose that we always return a region hint to the querier. > > A > >>>>separate LoST query is then used, if desired, to get the region. > > This > >>>>had the advantage that there is no special case of requesting or not >>>>requesting boundaries (since the identifier is short) and, more >>>>importantly, that the common case that multiple services have the >>>>same service boundaries can be handled more efficiently since they'd >>>>just use the same identifier. Something like >>>> >>>>Server returns: >>>>1234 >>>> >>>>Client queries: >>>> >>>> >>>>1234 >>>> >>>> >>>> >>>>Henning >>>> >>>>_______________________________________________ >>>>Ecrit mailing list >>>>Ecrit@ietf.org >>>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >>> > ------------------------------------------------------------------------ > >>------------------------ >> >>>This message is for the designated recipient only and may >>>contain privileged, proprietary, or otherwise private information. >>>If you have received it in error, please notify the sender >>>immediately and delete the original. Any unauthorized use of >>>this email is prohibited. >>> > > ------------------------------------------------------------------------ > >>------------------------ >> >>>[mf2] >>> >>>_______________________________________________ >>>Ecrit mailing list >>>Ecrit@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ecrit >>> >>> >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 14 11:38:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Pk6-0008Fr-QB; Fri, 14 Jul 2006 11:38:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Pk3-0008Da-RT for ecrit@ietf.org; Fri, 14 Jul 2006 11:38:11 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1OlP-0007GJ-DK for ecrit@ietf.org; Fri, 14 Jul 2006 10:35:31 -0400 Received: from brinza.cc.columbia.edu ([128.59.29.8]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G1O51-00064x-SV for ecrit@ietf.org; Fri, 14 Jul 2006 09:51:44 -0400 Received: from [132.219.27.189] (h1bbd-net84db.lab.risq.net [132.219.27.189] (may be forged)) (user=hgs10 mech=PLAIN bits=0) by brinza.cc.columbia.edu (8.13.7/8.13.6) with ESMTP id k6EDJjgt004559 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Fri, 14 Jul 2006 09:19:49 -0400 (EDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST #5: Boundary hints Date: Fri, 14 Jul 2006 09:19:40 -0400 To: "Thomson, Martin" X-Mailer: Apple Mail (2.752.2) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.8 X-Spam-Score: -2.6 (--) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org That's an option, but it depends on what the LoST URL, if any, will look like. One reason *not* to use a URL is that comparing a string is a lot easier than comparing a URL. (You want to compare the identifier/URL to see if you already have that object.) I'm agnostic on this topic, but want to keep it simple. On Jul 14, 2006, at 8:29 AM, Thomson, Martin wrote: > Why not provide a URI to the object rather than an opaque string? _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 14 17:24:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1V8i-0003Ty-Nh; Fri, 14 Jul 2006 17:24:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1V8h-0003Tg-49 for ecrit@ietf.org; Fri, 14 Jul 2006 17:23:59 -0400 Received: from zeke.hxr.us ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1V8f-0001Jd-Sc for ecrit@ietf.org; Fri, 14 Jul 2006 17:23:59 -0400 Received: from [10.0.1.102] ([::ffff:70.174.142.181]) (AUTH: PLAIN anewton, TLS: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 14 Jul 2006 17:24:09 -0400 id 0158811E.44B80B79.00003573 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3384AF17-A381-42A1-885B-DC61BDD012E9@hxr.us> Content-Transfer-Encoding: 7bit From: Andrew Newton Subject: Re: [Ecrit] LoST #5: Boundary hints Date: Fri, 14 Jul 2006 17:23:54 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ECRIT , "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think you've provided a pretty good reason why it should be a string and not a URL. -andy On Jul 14, 2006, at 9:19 AM, Henning Schulzrinne wrote: > That's an option, but it depends on what the LoST URL, if any, will > look like. One reason *not* to use a URL is that comparing a string > is a lot easier than comparing a URL. (You want to compare the > identifier/URL to see if you already have that object.) I'm > agnostic on this topic, but want to keep it simple. > > On Jul 14, 2006, at 8:29 AM, Thomson, Martin wrote: > >> Why not provide a URI to the object rather than an opaque string? > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sat Jul 15 11:35:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1mAa-0003nV-4u; Sat, 15 Jul 2006 11:35:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1mAY-0003nQ-6m for ecrit@ietf.org; Sat, 15 Jul 2006 11:35:02 -0400 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1mAV-0006ne-TQ for ecrit@ietf.org; Sat, 15 Jul 2006 11:35:02 -0400 Received: from lion.cs.columbia.edu (IDENT:wHs9XBgj+TVpkzd5Ngr3emV2WcRm/OGU@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6FFYwlM017440 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Sat, 15 Jul 2006 11:34:58 -0400 (EDT) Received: from [192.168.0.41] (pool-138-89-20-244.mad.east.verizon.net [138.89.20.244]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id k6FFYtoq015139 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sat, 15 Jul 2006 11:34:58 -0400 In-Reply-To: <3384AF17-A381-42A1-885B-DC61BDD012E9@hxr.us> References: <3384AF17-A381-42A1-885B-DC61BDD012E9@hxr.us> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] LoST #5: Boundary hints Date: Sat, 15 Jul 2006 11:34:40 -0400 To: Andrew Newton X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ECRIT , "Thomson, Martin" X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org On the flight home, it occurred to me that I may be wrong on this: If we have a recursive resolution chain, the region information will be inserted by the authoritative server, not the one that the client is querying. Thus, some form of URL (LoST or plain HTTP, most likely) may well be necessary since you probably don't want to go through the whole chain again to get the region. On Jul 14, 2006, at 5:23 PM, Andrew Newton wrote: > I think you've provided a pretty good reason why it should be a > string and not a URL. > > -andy > > On Jul 14, 2006, at 9:19 AM, Henning Schulzrinne wrote: > >> That's an option, but it depends on what the LoST URL, if any, >> will look like. One reason *not* to use a URL is that comparing a >> string is a lot easier than comparing a URL. (You want to compare >> the identifier/URL to see if you already have that object.) I'm >> agnostic on this topic, but want to keep it simple. >> >> On Jul 14, 2006, at 8:29 AM, Thomson, Martin wrote: >> >>> Why not provide a URI to the object rather than an opaque string? >> >> >> _______________________________________________ >> Ecrit mailing list >> Ecrit@ietf.org >> https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 17 08:11:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2Rwn-0003tR-Qj; Mon, 17 Jul 2006 08:11:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1Svy-0002ey-MW; Fri, 14 Jul 2006 15:02:42 -0400 Received: from mailhost.informatik.uni-bremen.de ([2001:638:708:30c9:209:3dff:fe00:7136] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1Svx-00046R-4V; Fri, 14 Jul 2006 15:02:42 -0400 Received: from [127.0.0.1] (m2 [134.102.201.19]) by informatik.uni-bremen.de (8.13.4/8.13.2) with ESMTP id k6EJ2Pf5017855; Fri, 14 Jul 2006 21:02:25 +0200 (CEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Fri, 14 Jul 2006 15:02:21 -0400 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new X-Spam-Score: -2.8 (--) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Mon, 17 Jul 2006 08:11:36 -0400 Cc: xcon@ietf.forg, Carsten Bormann , rai-discuss@ietf.org, ECRIT Subject: [Ecrit] Re: [Rai-discuss] Schema --> RelaxNG X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org > I would suggest that the RAI area declare that new efforts should, > by default, use RelaxNG rather than Schema unless there is a strong > reason to do otherwise, such as extending existing Schema-specified > work. Yes, please. Moving to Relax-NG (typically in compact form) for specification work is and has been a trend that is almost universal in the XML community, for many good reasons. (Oh, and this needn't be limited to RAI; it may be easier to get IETF consensus on this than some may think.) Gruesse, Carsten _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 17 19:05:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2c9t-00061u-2m; Mon, 17 Jul 2006 19:05:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2c9r-00060C-8l for ecrit@ietf.org; Mon, 17 Jul 2006 19:05:47 -0400 Received: from marauder.andrew.com ([198.17.217.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2c9q-0003dg-0R for ecrit@ietf.org; Mon, 17 Jul 2006 19:05:47 -0400 Received: from aopmfilt4.andrew.com ([127.0.0.1]) by marauder.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 18:05:45 -0500 Received: from Unknown [10.3.20.66] by aopmfilt4.andrew.com - SurfControl E-mail Filter (4.7); Mon, 17 Jul 2006 18:05:44 -0500 Received: from AHQEX1.andrew.com ([10.3.21.10]) by aopexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 17 Jul 2006 18:05:44 -0500 Message-ID: From: "Thomson, Martin" To: "Hannes Tschofenig" Date: Mon, 17 Jul 2006 18:04:53 -0500 Subject: RE: [Ecrit] LoST #4: service URN in response message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 17 Jul 2006 23:05:44.0166 (UTC) FILETIME=[8812E860:01C6A9F5] X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 In-Reply-To: <44B7A0FE.5020804@gmx.net> Content-class: urn:content-classes:message Thread-Topic: [Ecrit] LoST #4: service URN in response message Thread-Index: AcanTF7FE9k3TqwJS8CP06Odd/msgACqOGXw X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1410539122==" Errors-To: ecrit-bounces@ietf.org --===============1410539122== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Content-class: urn:content-classes:message SSB0aGluayB0aGF0IEkgYW0gaGFwcHkgd2l0aCBIZW5uaW5nJ3MgcmVzcG9uc2Ugb24gYWxsIG9m IHRoZXNlLiAgVGhlIGd1aWRhbmNlIGZvciB1cm46c2VydmljZTpzb3Mgbm93IGp1c3QgbmVlZHMg dG8gYmUgY2FwdHVyZWQgaW4gdGhlIHBob25lIEJDUC4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBIYW5uZXMgVHNjaG9mZW5pZyBbbWFpbHRvOkhhbm5lcy5Uc2Nob2Zl bmlnQGdteC5uZXRdDQo+IFNlbnQ6IEZyaWRheSwgMTQgSnVseSAyMDA2IDExOjUwIFBNDQo+IFRv OiBUaG9tc29uLCBNYXJ0aW4NCj4gQ2M6IEhlbm5pbmcgU2NodWx6cmlubmU7IEVDUklUDQo+IFN1 YmplY3Q6IFJlOiBbRWNyaXRdIExvU1QgIzQ6IHNlcnZpY2UgVVJOIGluIHJlc3BvbnNlIG1lc3Nh Z2UNCj4gDQo+IEhpIE1hcnRpbiwNCj4gDQo+IHdpdGggSGVubmluZ3MgcHJvcG9zYWwgd2UgaGF2 ZSBhIGxvdCBvZiBmcmVlZG9tIGZvciB0aGUgcGFydHkgdGhhdA0KPiBvcGVyYXRlcyB0aGUgTG9T VCBzZXJ2ZXIuIEluIHNvbWUgc2Vuc2UgdGhpcyBpcyBnb29kIHNpbmNlIHRoZXkga25vdyB0aGUN Cj4gICAgIHNlcnZpY2VzIGJlc3QuDQo+IA0KPiBIZXJlIGlzIGFuIGV4YW1wbGU6IEltYWdpbmUg dGhlcmUgaXMgYSByZWdpb24gdGhhdCBvbmx5IHVuZGVyc3RhbmRzDQo+ICd1cm46c2VydmljZTpz b3MnIGJ1dCBub3QgJ3VybjpzZXJ2aWNlOnNvcy5maXJlJywNCj4gJ3VybjpzZXJ2aWNlOnNvcy5h bWJ1bGFuY2UnLCBhbmQgJ3VybjpzZXJ2aWNlOnNvcy5wb2xpY2UnLg0KPiANCj4gSWYgYSBMb1NU IGNsaWVudCBhc2tzIGZvciAndXJuOnNlcnZpY2U6c29zLmZpcmUnIHRoZW4gaXQgY291bGQgZ2V0 Og0KPiAqICd1cm46c2VydmljZTpzb3MnIG9yDQo+ICogJ3VybjpzZXJ2aWNlOnNvcy5maXJlJyB3 aXRoIHRoZSB2YWx1ZXMgb2YgJ3VybjpzZXJ2aWNlOnNvcycgYmVpbmcNCj4gcG9wdWxhdGVkIHRv ICd1cm46c2VydmljZTpzb3MuZmlyZScNCj4gDQo+IEFub3RoZXIgZXhhbXBsZToNCj4gDQo+IElt YWdpbmUgdGhlcmUgaXMgYSByZWdpb24gdGhhdCBvbmx5IHVuZGVyc3RhbmRzICd1cm46c2Vydmlj ZTpzb3MuZmlyZScsDQo+ICd1cm46c2VydmljZTpzb3MuYW1idWxhbmNlJywgYW5kICd1cm46c2Vy dmljZTpzb3MucG9saWNlJyBidXQgaXQgZG9lcw0KPiBub3QgdW5kZXJzdGFuZCAndXJuOnNlcnZp Y2U6c29zJy4NCj4gDQo+IElmIGEgTG9TVCBjbGllbnQgYXNrcyBmb3IgJ3VybjpzZXJ2aWNlOnNv cycgd2hhdCB3b3VsZCBpdCBnZXQ/DQo+IA0KPiBXZSBwcm9iYWJseSBuZWVkIHRvIHN0YXRlIHdo YXQgaXQgbWVhbnMgaWYgdGhlIExvU1QgY2xpZW50IHJlY2VpdmVzIGENCj4gcmVzcG9uc2UgdGhh dCBpbmRpY2F0ZXMgJ0kgY291bGRuJ3QgcHJvdmlkZSBhIHJlc3BvbnNlIHRvIHlvdXIgcmVxdWVz dA0KPiBiYXNlZCBvbiB1cm46c2VydmljZTpzb3MuYW1idWxhbmNlIGJ1dCBJIGhhdmUgc29tZXRo aW5nIGVsc2UgZm9yIHlvdS4nDQo+IA0KPiBJIGFtIG5vdCBzdXJlIHdoYXQgdGhlIExvU1QgY2xp ZW50IGNhbiB1c2VmdWxseSBkbyBpbiB0aGlzIGNhc2UuDQo+IA0KPiBDaWFvDQo+IEhhbm5lcw0K PiANCj4gVGhvbXNvbiwgTWFydGluIHdyb3RlOg0KPiA+IERvIHdlIGhhdmUgYW55IGFkZGl0aW9u YWwgZ3VpZGFuY2UgdGhhdCB3b3VsZCBiZSBoZWxwZnVsLCBvciBpcyB0aGF0IHRoZQ0KPiA+IGV4 dGVudCBvZiB5b3VyIHByb3Bvc2VkIGd1aWRhbmNlPw0KPiA+DQo+ID4NCj4gPj4tLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PkZyb206IEhlbm5pbmcgU2NodWx6cmlubmUgW21haWx0bzpo Z3NAY3MuY29sdW1iaWEuZWR1XQ0KPiA+PlNlbnQ6IEZyaWRheSwgMTQgSnVseSAyMDA2IDU6NTAg QU0NCj4gPj5UbzogRUNSSVQNCj4gPj5TdWJqZWN0OiBbRWNyaXRdIExvU1QgIzQ6IHNlcnZpY2Ug VVJOIGluIHJlc3BvbnNlIG1lc3NhZ2UNCj4gPj4NCj4gPj5Qcm9wb3NlZCByZXNvbHV0aW9uOiBJ ZiB0aGUgc3BlY2lmaWMgc2VydmljZSBpcyBub3QgYXZhaWxhYmxlIGZvciBhDQo+ID4+cGFydGlj dWxhciBsb2NhdGlvbiwgdGhlIHNlcnZlciBNQVkgcmV0dXJuIGFuIGFsdGVybmF0ZSBzZXJ2aWNl LiBJZg0KPiA+Pml0IGRvZXMgc28sIGl0IE1VU1QgaW5kaWNhdGUgdGhlIGFjdHVhbCBzZXJ2aWNl IHJldHVybmVkIChpLmUuLCBpdHMNCj4gPj5zZXJ2aWNlIFVSTikuIFRoZXJlIGlzIG5vIHJlc3Ry aWN0aW9uIG9uIHRoZSBuZXcgc2VydmljZSBvZmZlcmVkLg0KPiA+PlRodXMsIGl0IGlzIHBvc3Np YmxlIHRoYXQgYSBxdWVyeSBmb3INCj4gPj4NCj4gPj51cm46c2VydmljZTpzb3MuYW1idWxhbmNl DQo+ID4+DQo+ID4+cmV0dXJucw0KPiA+Pg0KPiA+PnVybjpzZXJ2aWNlOnVuZGVydGFrZXINCj4g Pj4NCj4gPj5BIHNlcnZlciBNQVkgaW5zdGVhZCByZXR1cm4gYW4gZXJyb3IgcmVzcG9uc2UgaW5k aWNhdGluZyB0aGF0IHRoZQ0KPiA+PnNlcnZpY2UgaXMgbm90IGF2YWlsYWJsZS4NCj4gPj4NCj4g Pj5IZW5uaW5nDQo+ID4+IA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5k IG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZh dGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFs LiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0= --===============1410539122== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1410539122==-- From ecrit-bounces@ietf.org Tue Jul 18 08:55:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2p6U-000470-3Q; Tue, 18 Jul 2006 08:55:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2p41-0002gH-UP for ecrit@ietf.org; Tue, 18 Jul 2006 08:52:37 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2oqE-0002Po-Cf for ecrit@ietf.org; Tue, 18 Jul 2006 08:38:24 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G2oq6-0000tx-D7; Tue, 18 Jul 2006 07:38:14 -0500 From: "Brian Rosen" To: "'Thomson, Martin'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] LoST #4: service URN in response message Date: Tue, 18 Jul 2006 08:38:15 -0400 Message-ID: <0ac901c6aa67$0be1ab10$bc1cdb84@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcanTF7FE9k3TqwJS8CP06Odd/msgACqOGXwABxdq4A= X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: 'ECRIT' X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I think most of this goes in the LoST document, but the bcp should clearly say that the client has to be prepared for the substitution. It's not really clear it cares a lot, except for, perhaps, the user interface it presents, where the user, if she are paying attention, would probably want to know what is happening to her call. Brian -----Original Message----- From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] Sent: Monday, July 17, 2006 7:05 PM To: Hannes Tschofenig Cc: ECRIT Subject: RE: [Ecrit] LoST #4: service URN in response message I think that I am happy with Henning's response on all of these. The guidance for urn:service:sos now just needs to be captured in the phone BCP. > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Friday, 14 July 2006 11:50 PM > To: Thomson, Martin > Cc: Henning Schulzrinne; ECRIT > Subject: Re: [Ecrit] LoST #4: service URN in response message > > Hi Martin, > > with Hennings proposal we have a lot of freedom for the party that > operates the LoST server. In some sense this is good since they know the > services best. > > Here is an example: Imagine there is a region that only understands > 'urn:service:sos' but not 'urn:service:sos.fire', > 'urn:service:sos.ambulance', and 'urn:service:sos.police'. > > If a LoST client asks for 'urn:service:sos.fire' then it could get: > * 'urn:service:sos' or > * 'urn:service:sos.fire' with the values of 'urn:service:sos' being > populated to 'urn:service:sos.fire' > > Another example: > > Imagine there is a region that only understands 'urn:service:sos.fire', > 'urn:service:sos.ambulance', and 'urn:service:sos.police' but it does > not understand 'urn:service:sos'. > > If a LoST client asks for 'urn:service:sos' what would it get? > > We probably need to state what it means if the LoST client receives a > response that indicates 'I couldn't provide a response to your request > based on urn:service:sos.ambulance but I have something else for you.' > > I am not sure what the LoST client can usefully do in this case. > > Ciao > Hannes > > Thomson, Martin wrote: > > Do we have any additional guidance that would be helpful, or is that the > > extent of your proposed guidance? > > > > > >>-----Original Message----- > >>From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > >>Sent: Friday, 14 July 2006 5:50 AM > >>To: ECRIT > >>Subject: [Ecrit] LoST #4: service URN in response message > >> > >>Proposed resolution: If the specific service is not available for a > >>particular location, the server MAY return an alternate service. If > >>it does so, it MUST indicate the actual service returned (i.e., its > >>service URN). There is no restriction on the new service offered. > >>Thus, it is possible that a query for > >> > >>urn:service:sos.ambulance > >> > >>returns > >> > >>urn:service:undertaker > >> > >>A server MAY instead return an error response indicating that the > >>service is not available. > >> > >>Henning > >> ---------------------------------------------------------------------------- -------------------- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any unauthorized use of this email is prohibited. ---------------------------------------------------------------------------- -------------------- [mf2] _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 18 09:08:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pJa-0002KN-QR; Tue, 18 Jul 2006 09:08:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pJa-0002KF-2d for ecrit@ietf.org; Tue, 18 Jul 2006 09:08:42 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G2pJX-0000Jn-Jh for ecrit@ietf.org; Tue, 18 Jul 2006 09:08:42 -0400 Received: (qmail invoked by alias); 18 Jul 2006 13:08:38 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp031) with SMTP; 18 Jul 2006 15:08:38 +0200 X-Authenticated: #29516787 Message-ID: <44BCDD54.6000808@gmx.net> Date: Tue, 18 Jul 2006 15:08:36 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Subject: [Ecrit] Hum for new WG items X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, our new milestones are available at the charter: http://www.ietf.org/html.charters/ecrit-charter.html Hence, we would like to confirm decisions on the mailing list in order to turn the following three documents into working group docments: * Location-to-URL Mapping Architecture and Framework http://www.ietf-ecrit.org/cache/draft-schulzrinne-ecrit-mapping-arch-00.txt This document matches the following charter item: Nov 2006 An Informational document describing the Mapping Protocol Architecture * Framework for Emergency Calling in Internet Multimedia http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-emergency-framework-00.txt This document matches the following charter item: Dec 2006 An Informational document describing the ECRIT Framework * Best Current Practice for Communications Services in support of Emergency Calling http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-01.txt This document matches the following charter item: Feb 2007 A BCP document describing the emergency call support for devices The chairs have asked the group already at the Washington interim meeting, at the IETF#65 and at the IETF#66 meeting whether there is enough interest in these document. There was strong support for these documents. Please speak for or against making draft-schulzrinne-ecrit-mapping-arch-00.txt, draft-rosen-ecrit-emergency-framework-00.txt and draft-rosen-ecrit-phonebcp-01.txt working group items (unless you have already expressed your opinion). Deadline is the 31st July 2006. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 18 10:54:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qxY-0002nF-Vp; Tue, 18 Jul 2006 10:54:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2qxX-0002n7-Ot for ecrit@ietf.org; Tue, 18 Jul 2006 10:54:03 -0400 Received: from pne-smtpout1-sn1.fre.skanova.net ([81.228.11.98]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2qxW-0004s9-D3 for ecrit@ietf.org; Tue, 18 Jul 2006 10:54:03 -0400 Received: from Misan (213.64.228.153) by pne-smtpout1-sn1.fre.skanova.net (7.2.075) id 44A1364D0044419D; Tue, 18 Jul 2006 16:54:01 +0200 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Hannes Tschofenig" , "ECRIT" Subject: RE: [Ecrit] Hum for new WG items Date: Tue, 18 Jul 2006 16:53:53 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44BCDD54.6000808@gmx.net> Importance: Normal Content-Transfer-Encoding: Quoted-Printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I hum for all three. Gunnar -------------------------------------------------------------------------= --- - Gunnar Hellstr=F6m, Omnitor gunnar.hellstrom@omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Tuesday, July 18, 2006 2:09 PM To: ECRIT Subject: [Ecrit] Hum for new WG items Hi all, our new milestones are available at the charter: http://www.ietf.org/html.charters/ecrit-charter.html Hence, we would like to confirm decisions on the mailing list in order to turn the following three documents into working group docments: * Location-to-URL Mapping Architecture and Framework http://www.ietf-ecrit.org/cache/draft-schulzrinne-ecrit-mapping-arch-00.t= xt This document matches the following charter item: Nov 2006 An Informational document describing the Mapping Protocol Architecture * Framework for Emergency Calling in Internet Multimedia http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-emergency-framework-00.= txt This document matches the following charter item: Dec 2006 An Informational document describing the ECRIT Framework * Best Current Practice for Communications Services in support of Emergency Calling http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-01.txt This document matches the following charter item: Feb 2007 A BCP document describing the emergency call support for devices The chairs have asked the group already at the Washington interim meeting, at the IETF#65 and at the IETF#66 meeting whether there is enough interest in these document. There was strong support for these documents. Please speak for or against making draft-schulzrinne-ecrit-mapping-arch-00.txt, draft-rosen-ecrit-emergency-framework-00.txt and draft-rosen-ecrit-phonebcp-01.txt working group items (unless you have already expressed your opinion). Deadline is the 31st July 2006. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 18 13:10:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2t5S-0003Gw-R6; Tue, 18 Jul 2006 13:10:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2t5R-0003GN-OF for ecrit@ietf.org; Tue, 18 Jul 2006 13:10:21 -0400 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2t5Q-0005Wk-Ae for ecrit@ietf.org; Tue, 18 Jul 2006 13:10:21 -0400 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id EE7AA2004F; Tue, 18 Jul 2006 13:10:19 -0400 (EDT) Received: from smtp.mitel.com ([127.0.0.1]) by localhost (smtp.mitel.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14790-03; Tue, 18 Jul 2006 13:10:19 -0400 (EDT) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id EED8720021; Tue, 18 Jul 2006 13:10:18 -0400 (EDT) To: Hannes Tschofenig Subject: Re: [Ecrit] Hum for new WG items MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: peter_blatherwick@mitel.com Date: Tue, 18 Jul 2006 13:10:19 -0400 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 07/18/2006 01:10:17 PM, Serialize complete at 07/18/2006 01:10:17 PM X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0032117883==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0032117883== Content-Type: multipart/alternative; boundary="=_alternative 005E5442852571AF_=" This is a multipart message in MIME format. --=_alternative 005E5442852571AF_= Content-Type: text/plain; charset="us-ascii" Hummmmmmm in favour of all 3 as WG items. -- Peter Blatherwick Hannes Tschofenig 18.07.06 09:08 To: ECRIT cc: Subject: [Ecrit] Hum for new WG items Hi all, our new milestones are available at the charter: http://www.ietf.org/html.charters/ecrit-charter.html Hence, we would like to confirm decisions on the mailing list in order to turn the following three documents into working group docments: * Location-to-URL Mapping Architecture and Framework http://www.ietf-ecrit.org/cache/draft-schulzrinne-ecrit-mapping-arch-00.txt This document matches the following charter item: Nov 2006 An Informational document describing the Mapping Protocol Architecture * Framework for Emergency Calling in Internet Multimedia http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-emergency-framework-00.txt This document matches the following charter item: Dec 2006 An Informational document describing the ECRIT Framework * Best Current Practice for Communications Services in support of Emergency Calling http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-01.txt This document matches the following charter item: Feb 2007 A BCP document describing the emergency call support for devices The chairs have asked the group already at the Washington interim meeting, at the IETF#65 and at the IETF#66 meeting whether there is enough interest in these document. There was strong support for these documents. Please speak for or against making draft-schulzrinne-ecrit-mapping-arch-00.txt, draft-rosen-ecrit-emergency-framework-00.txt and draft-rosen-ecrit-phonebcp-01.txt working group items (unless you have already expressed your opinion). Deadline is the 31st July 2006. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --=_alternative 005E5442852571AF_= Content-Type: text/html; charset="us-ascii"
Hummmmmmm   in favour of all 3 as WG items.  

-- Peter Blatherwick




Hannes Tschofenig <Hannes.Tschofenig@gmx.net>

18.07.06 09:08

       
        To:        ECRIT <ecrit@ietf.org>
        cc:        
        Subject:        [Ecrit] Hum for new WG items



Hi all,

our new milestones are available at the charter:
http://www.ietf.org/html.charters/ecrit-charter.html

Hence, we would like to confirm decisions on the mailing list in order
to turn the following three documents into working group docments:

* Location-to-URL Mapping Architecture and Framework
http://www.ietf-ecrit.org/cache/draft-schulzrinne-ecrit-mapping-arch-00.txt

This document matches the following charter item:

Nov 2006    An Informational document describing the Mapping Protocol
Architecture

* Framework for Emergency Calling in Internet Multimedia
http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-emergency-framework-00.txt

This document matches the following charter item:

Dec 2006    An Informational document describing the ECRIT Framework

* Best Current Practice for Communications Services in support of
Emergency Calling
http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-01.txt

This document matches the following charter item:

Feb 2007    A BCP document describing the emergency call support for
devices

The chairs have asked the group already at the Washington interim
meeting, at the IETF#65 and at the IETF#66 meeting whether there is
enough interest in these document. There was strong support for these
documents.

Please speak for or against making
draft-schulzrinne-ecrit-mapping-arch-00.txt,
draft-rosen-ecrit-emergency-framework-00.txt and
draft-rosen-ecrit-phonebcp-01.txt working
group items (unless you have already expressed your opinion).

Deadline is the 31st July 2006.

Ciao
Hannes & Marc

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit

--=_alternative 005E5442852571AF_=-- --===============0032117883== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============0032117883==-- From ecrit-bounces@ietf.org Tue Jul 18 14:33:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2uNY-00025R-5M; Tue, 18 Jul 2006 14:33:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2uNW-00025H-DZ for ecrit@ietf.org; Tue, 18 Jul 2006 14:33:06 -0400 Received: from mail.oefeg.at ([62.47.121.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G2uNU-0004Tz-W5 for ecrit@ietf.org; Tue, 18 Jul 2006 14:33:06 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: Re: [Ecrit] Hum for new WG items Date: Tue, 18 Jul 2006 20:31:45 +0200 Message-ID: <32755D354E6B65498C3BD9FD496C7D462C4B31@oefeg-s04.oefeg.loc> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum for new WG items Thread-Index: Acaqay52aMtomqKKQhKR2kdTsfld0wALT4C6 References: <44BCDD54.6000808@gmx.net> From: "Stastny Richard" To: "Hannes Tschofenig" , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I Hum for all three =20 Richard ________________________________ Von: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Gesendet: Di 18.07.2006 15:08 An: ECRIT Betreff: [Ecrit] Hum for new WG items Hi all, our new milestones are available at the charter: http://www.ietf.org/html.charters/ecrit-charter.html Hence, we would like to confirm decisions on the mailing list in order to turn the following three documents into working group docments: * Location-to-URL Mapping Architecture and Framework http://www.ietf-ecrit.org/cache/draft-schulzrinne-ecrit-mapping-arch-00.t= xt This document matches the following charter item: Nov 2006 An Informational document describing the Mapping Protocol Architecture * Framework for Emergency Calling in Internet Multimedia http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-emergency-framework-00.= txt This document matches the following charter item: Dec 2006 An Informational document describing the ECRIT Framework * Best Current Practice for Communications Services in support of Emergency Calling http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-01.txt This document matches the following charter item: Feb 2007 A BCP document describing the emergency call support for devices The chairs have asked the group already at the Washington interim meeting, at the IETF#65 and at the IETF#66 meeting whether there is enough interest in these document. There was strong support for these documents. Please speak for or against making draft-schulzrinne-ecrit-mapping-arch-00.txt, draft-rosen-ecrit-emergency-framework-00.txt and draft-rosen-ecrit-phonebcp-01.txt working group items (unless you have already expressed your opinion). Deadline is the 31st July 2006. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 18 15:36:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2vMz-0002vl-Bj; Tue, 18 Jul 2006 15:36:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2vMx-0002tj-GW for ecrit@ietf.org; Tue, 18 Jul 2006 15:36:35 -0400 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2vMw-0003OF-7W for ecrit@ietf.org; Tue, 18 Jul 2006 15:36:35 -0400 Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6IJUoGX006129 for ; Tue, 18 Jul 2006 15:30:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Hum for new WG items Date: Tue, 18 Jul 2006 22:36:32 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum for new WG items Thread-Index: Acaqa0/L98+Qn7daSD2TMXljfnc1zAANhaaA From: "Romascanu, Dan \(Dan\)" To: "Hannes Tschofenig" , "ECRIT" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hum in favor of all three. Dan =20 =20 > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 > Sent: Tuesday, July 18, 2006 4:09 PM > To: ECRIT > Subject: [Ecrit] Hum for new WG items >=20 > Hi all, >=20 > our new milestones are available at the charter: > http://www.ietf.org/html.charters/ecrit-charter.html >=20 > Hence, we would like to confirm decisions on the mailing list=20 > in order to turn the following three documents into working=20 > group docments: >=20 > * Location-to-URL Mapping Architecture and Framework=20 > http://www.ietf-ecrit.org/cache/draft-schulzrinne-ecrit-mappin > g-arch-00.txt >=20 > This document matches the following charter item: >=20 > Nov 2006 An Informational document describing the Mapping Protocol=20 > Architecture >=20 > * Framework for Emergency Calling in Internet Multimedia=20 > http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-emergency-fr > amework-00.txt >=20 > This document matches the following charter item: >=20 > Dec 2006 An Informational document describing the ECRIT Framework >=20 > * Best Current Practice for Communications Services in=20 > support of Emergency Calling=20 > http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-01.txt >=20 > This document matches the following charter item: >=20 > Feb 2007 A BCP document describing the emergency call support for=20 > devices >=20 > The chairs have asked the group already at the Washington=20 > interim meeting, at the IETF#65 and at the IETF#66 meeting=20 > whether there is enough interest in these document. There was=20 > strong support for these documents. >=20 > Please speak for or against making > draft-schulzrinne-ecrit-mapping-arch-00.txt, > draft-rosen-ecrit-emergency-framework-00.txt and=20 > draft-rosen-ecrit-phonebcp-01.txt working group items (unless=20 > you have already expressed your opinion). >=20 > Deadline is the 31st July 2006. >=20 > Ciao > Hannes & Marc >=20 > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit >=20 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 18 16:24:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2w6t-0002QK-CX; Tue, 18 Jul 2006 16:24:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2w6r-0002QF-KV for ecrit@ietf.org; Tue, 18 Jul 2006 16:24:01 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2w6p-00031G-9E for ecrit@ietf.org; Tue, 18 Jul 2006 16:24:01 -0400 Received: from [192.168.0.101] (S010600095b9792b5.vc.shawcable.net [24.85.243.115]) (authenticated) by agnada.com (8.11.6/8.11.6) with ESMTP id k6IKNtH12207; Tue, 18 Jul 2006 14:23:55 -0600 Message-ID: <44BD435C.1030803@ntt-at.com> Date: Tue, 18 Jul 2006 13:23:56 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Hum for new WG items References: <44BCDD54.6000808@gmx.net> In-Reply-To: <44BCDD54.6000808@gmx.net> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I hum for all three to become a WG items but the last item may need to change its name as it also defines a requirements or suggestions for the network. Regards Shida Schubert Hannes Tschofenig wrote: > Hi all, > > our new milestones are available at the charter: > http://www.ietf.org/html.charters/ecrit-charter.html > > Hence, we would like to confirm decisions on the mailing list in order > to turn the following three documents into working group docments: > > * Location-to-URL Mapping Architecture and Framework > http://www.ietf-ecrit.org/cache/draft-schulzrinne-ecrit-mapping-arch-00.txt > > > This document matches the following charter item: > > Nov 2006 An Informational document describing the Mapping Protocol > Architecture > > * Framework for Emergency Calling in Internet Multimedia > http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-emergency-framework-00.txt > > > This document matches the following charter item: > > Dec 2006 An Informational document describing the ECRIT Framework > > * Best Current Practice for Communications Services in support of > Emergency Calling > http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-01.txt > > This document matches the following charter item: > > Feb 2007 A BCP document describing the emergency call support for devices > > The chairs have asked the group already at the Washington interim > meeting, at the IETF#65 and at the IETF#66 meeting whether there is > enough interest in these document. There was strong support for these > documents. > > Please speak for or against making > draft-schulzrinne-ecrit-mapping-arch-00.txt, > draft-rosen-ecrit-emergency-framework-00.txt and > draft-rosen-ecrit-phonebcp-01.txt working > group items (unless you have already expressed your opinion). > > Deadline is the 31st July 2006. > > Ciao > Hannes & Marc > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Jul 18 19:30:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2z1f-00034a-NG; Tue, 18 Jul 2006 19:30:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2z1e-00034M-SH for ecrit@ietf.org; Tue, 18 Jul 2006 19:30:50 -0400 Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2z1c-0000jq-FO for ecrit@ietf.org; Tue, 18 Jul 2006 19:30:50 -0400 Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id k6INUj65026385; Tue, 18 Jul 2006 18:30:45 -0500 (CDT) Received: from ILEXC1U01.ndc.lucent.com ([135.3.39.3]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 18 Jul 2006 18:30:44 -0500 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Hum for new WG items Date: Tue, 18 Jul 2006 18:30:43 -0500 Message-ID: <7A5EF92F6D86BD419418FFBD69E882B6010A9E9D@ILEXC1U01.ndc.lucent.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum for new WG items Thread-Index: Acaqa1I6Ykb/O9d7TbKC4E0QJnFHvwAVtBQA From: "GOLDMAN, STUART O \(STUART\)" To: "Hannes Tschofenig" , "ECRIT" X-OriginalArrivalTime: 18 Jul 2006 23:30:44.0958 (UTC) FILETIME=[310757E0:01C6AAC2] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hum, hum, and hum. Stuart Goldman Lucent Technologies sgoldman@lucent.com 602 493 8438 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Tuesday, July 18, 2006 6:09 AM To: ECRIT Subject: [Ecrit] Hum for new WG items Hi all, our new milestones are available at the charter: http://www.ietf.org/html.charters/ecrit-charter.html Hence, we would like to confirm decisions on the mailing list in order=20 to turn the following three documents into working group docments: * Location-to-URL Mapping Architecture and Framework http://www.ietf-ecrit.org/cache/draft-schulzrinne-ecrit-mapping-arch-00. txt This document matches the following charter item: Nov 2006 An Informational document describing the Mapping Protocol=20 Architecture * Framework for Emergency Calling in Internet Multimedia http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-emergency-framework-00 .txt This document matches the following charter item: Dec 2006 An Informational document describing the ECRIT Framework * Best Current Practice for Communications Services in support of=20 Emergency Calling http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-01.txt This document matches the following charter item: Feb 2007 A BCP document describing the emergency call support for=20 devices The chairs have asked the group already at the Washington interim=20 meeting, at the IETF#65 and at the IETF#66 meeting whether there is=20 enough interest in these document. There was strong support for these=20 documents. Please speak for or against making=20 draft-schulzrinne-ecrit-mapping-arch-00.txt,=20 draft-rosen-ecrit-emergency-framework-00.txt and=20 draft-rosen-ecrit-phonebcp-01.txt working group items (unless you have already expressed your opinion). Deadline is the 31st July 2006. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 19 00:05:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G33Jd-0006A9-DL; Wed, 19 Jul 2006 00:05:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G33Jc-0006A1-I0 for ecrit@ietf.org; Wed, 19 Jul 2006 00:05:40 -0400 Received: from pne-smtpout2-sn1.fre.skanova.net ([81.228.11.159]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G33Jb-0005t3-6O for ecrit@ietf.org; Wed, 19 Jul 2006 00:05:40 -0400 Received: from Misan (213.64.228.153) by pne-smtpout2-sn1.fre.skanova.net (7.2.075) id 44A135F100452544; Wed, 19 Jul 2006 06:05:32 +0200 From: =?us-ascii?Q?Gunnar_Hellstrom?= To: "Brian Rosen\(br\)" , "Ecrit@Ietf. Org" Date: Wed, 19 Jul 2006 06:05:25 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Subject: [Ecrit] Reference to real-time text in draft-rosen-ecrit-framework-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org I have some small comments on the good draft draft-rosen-ecrit-framework-00 1. In section 12, Media, there is a reference to RFC2793bis that now can be changed to the published RFC 4103 "RTP Payload for Text Conversation". Also change "interactive text" to "real-time text" as IETF nomenclature has now settled for this feature. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Old text in section 12: PSAPs should accept interactive text [I-D.ietf-avt- rfc2793bis]. New text: PSAPs should accept real-time text [RFC4103]. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2. In section 18.1 , references, replace reference to rfc2793bis with rfc 4103 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Old text in section 18.1: [I-D.ietf-avt-rfc2793bis] Hellstrom, G., "RTP Payload for Text Conversation", draft-ietf-avt-rfc2793bis-09 (work in progress), August 2004. New text: [RFC4103] Hellstrom, G. and Jones, P. "RTP Payload for Text Conversation", RFC 4103, May 2005. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Gunnar Hellstrom ---------------------------------------------------------------------------- - Gunnar Hellstrom, Omnitor gunnar.hellstrom@omnitor.se www.omnitor.se -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, June 21, 2006 8:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rosen-ecrit-framework-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Framework for Emergency Calling in Internet Multimedia Author(s) : B. Rosen, et al. Filename : draft-rosen-ecrit-framework-00.txt Pages : 32 Date : 2006-6-21 Summoning emergency help by the public is a core feature of telephone networks. This document describes a framework of how various IETF protocols are combined to place emergency calls. This includes how these calls are routed to the correct Public Safety Answering Point (PSAP) based on the physical location of the caller, while providing the call taker the necessary information to dispatch a first responder to that location. This document explains how location mapping, call identification and end system behavior are combined to allow multimedia emergency calls. It describes at a high level how the pieces (recognizing a call as an emergency call, marking it as such, determining the location of the caller, routing the call based on location) go together, and references the Internet standards that define the details of these mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-ecrit-framework-00.txt _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 19 09:04:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Bik-0000i0-LG; Wed, 19 Jul 2006 09:04:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3Bij-0000hR-44 for ecrit@ietf.org; Wed, 19 Jul 2006 09:04:09 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3Bij-0000km-1l for ecrit@ietf.org; Wed, 19 Jul 2006 09:04:09 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G3Big-0003GW-UY for ecrit@ietf.org; Wed, 19 Jul 2006 09:04:08 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3Bh9-0003VS-PG; Wed, 19 Jul 2006 08:02:32 -0500 From: "Brian Rosen" To: "'Gunnar Hellstrom'" , "'Ecrit@Ietf. Org'" Date: Wed, 19 Jul 2006 09:02:25 -0400 Message-ID: <016a01c6ab33$9b2828e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: Acaq6JEXAgub6u4uQgKPuhH6RDWS9wASuDfw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: -2.5 (--) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: Subject: [Ecrit] RE: Reference to real-time text in draft-rosen-ecrit-framework-00.txt X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Thanks for looking at this. I will make all of these changes in the next revision. Brian -----Original Message----- From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] Sent: Wednesday, July 19, 2006 1:05 AM To: Brian Rosen(br); Ecrit@Ietf. Org Subject: Reference to real-time text in draft-rosen-ecrit-framework-00.txt I have some small comments on the good draft draft-rosen-ecrit-framework-00 1. In section 12, Media, there is a reference to RFC2793bis that now can be changed to the published RFC 4103 "RTP Payload for Text Conversation". Also change "interactive text" to "real-time text" as IETF nomenclature has now settled for this feature. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Old text in section 12: PSAPs should accept interactive text [I-D.ietf-avt- rfc2793bis]. New text: PSAPs should accept real-time text [RFC4103]. +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2. In section 18.1 , references, replace reference to rfc2793bis with rfc 4103 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Old text in section 18.1: [I-D.ietf-avt-rfc2793bis] Hellstrom, G., "RTP Payload for Text Conversation", draft-ietf-avt-rfc2793bis-09 (work in progress), August 2004. New text: [RFC4103] Hellstrom, G. and Jones, P. "RTP Payload for Text Conversation", RFC 4103, May 2005. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Gunnar Hellstrom ---------------------------------------------------------------------------- - Gunnar Hellstrom, Omnitor gunnar.hellstrom@omnitor.se www.omnitor.se -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Wednesday, June 21, 2006 8:50 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-rosen-ecrit-framework-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Framework for Emergency Calling in Internet Multimedia Author(s) : B. Rosen, et al. Filename : draft-rosen-ecrit-framework-00.txt Pages : 32 Date : 2006-6-21 Summoning emergency help by the public is a core feature of telephone networks. This document describes a framework of how various IETF protocols are combined to place emergency calls. This includes how these calls are routed to the correct Public Safety Answering Point (PSAP) based on the physical location of the caller, while providing the call taker the necessary information to dispatch a first responder to that location. This document explains how location mapping, call identification and end system behavior are combined to allow multimedia emergency calls. It describes at a high level how the pieces (recognizing a call as an emergency call, marking it as such, determining the location of the caller, routing the call based on location) go together, and references the Internet standards that define the details of these mechanisms. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-ecrit-framework-00.txt _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 19 11:37:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3E7V-0000le-MT; Wed, 19 Jul 2006 11:37:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3E7U-0000hB-2T for ecrit@ietf.org; Wed, 19 Jul 2006 11:37:52 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3Dxc-0002dp-3a for ecrit@ietf.org; Wed, 19 Jul 2006 11:27:41 -0400 Received: (qmail invoked by alias); 19 Jul 2006 15:27:36 -0000 Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25] by mail.gmx.net (mp036) with SMTP; 19 Jul 2006 17:27:36 +0200 X-Authenticated: #29516787 Message-ID: <44BE4F59.5040905@gmx.net> Date: Wed, 19 Jul 2006 17:27:21 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ecrit] IETF#66 Meeting Minutes X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, please take a look at the meeting minutes: http://www3.ietf.org/proceedings/06jul/minutes/ecrit.txt Thanks to Roger, Andy and Ted. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Jul 19 17:26:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3JYu-0006nk-O9; Wed, 19 Jul 2006 17:26:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3JYt-0006nZ-IC; Wed, 19 Jul 2006 17:26:31 -0400 Received: from cdx28.winwebhosting.com ([70.85.255.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3JYs-0002q9-6k; Wed, 19 Jul 2006 17:26:31 -0400 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSENLT40xp) by cdx28.winwebhosting.com with esmtpa (Exim 4.52) id 1G3JW8-00076g-Ho; Wed, 19 Jul 2006 16:23:41 -0500 From: "Brian Rosen" To: Date: Wed, 19 Jul 2006 17:23:44 -0400 Message-ID: <026c01c6ab79$9fe2a0e0$640fa8c0@cis.neustar.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 thread-index: AcareZxJ2SPVtSd3T9mM5oXpCTpVAw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 X-PopBeforeSMTPSenders: br@brianrosen.net,brosen X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cdx28.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: sip@ietf.org, "'Ecrit@Ietf. Org'" Subject: [Ecrit] Routing of calls based on location X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org NOTE: THIS MESSAGE IS COPIED TO SIP AND ECRIT, IF YOU REPLY, SEND IT ONLY TO GEOPRIV The SIP Location Conveyance document anticipates the ability to route a call based on the location of the caller. The original impetus for this is emergency calling. In ecrit, a mechanism has been defined (LoST) that takes a service request (in the form of a newly defined service urn) and a location and returns a URI. This mechanism is not limited to emergency calling, and could be used for arbitrary location based routing by defining new service urns. However, this opens up the issue of geopriv privacy concerns because the sender does not know the identity of the element (proxy) that will route the call using LoST. It may be that the UAC itself does this, but it may be some other intermediary. If the identity of the intermediary is not known, then protecting the location information becomes more difficult, because we cannot encrypt using keying material from the intended recipient. In fact, we would need to use hop-by-hop security, with transitive trust. This is what the emergency case does, but it also allows no channel security if necessary (usually meaning, try it with TLS and if that fails, try again without TLS). We propose to explicitly allow hop-by-hop security when sending location using SIP for the purpose of location based routing. We will specify you MUST use TLS if sending location by reference (and there will be some words about the choice of URI construction which is raised in another email I am about to send). An important issue that we need to discuss is what "Do Not Distribute" means in this case. We would like it to allow the data to be passed onward. Indeed, SIP proxies shouldn't be dropping headers. We propose that it means that it cannot be distributed except that the location header (and body of course) is passed as it normally would. Note that although this is an issue that concerns the SIP working group, because the location conveyance document is a sip document, it really is a geopriv issue. It also affects ecrit, since we are using its protocol beyond its initial purpose. We ask that this discussion be held on the geopriv list, and not copied to either sip or ecrit. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 20 11:40:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3adg-0002Qa-M4; Thu, 20 Jul 2006 11:40:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3adf-0002QN-HH for ecrit@ietf.org; Thu, 20 Jul 2006 11:40:35 -0400 Received: from smtp5.smtp.bt.com ([217.32.164.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3adc-0006UH-3D for ecrit@ietf.org; Thu, 20 Jul 2006 11:40:35 -0400 Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp5.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Jul 2006 16:40:35 +0100 Received: from I2KM11-UKBR.domain1.systemhost.net ([193.113.197.28]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Jul 2006 16:40:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ecrit] Hum for new WG items Date: Thu, 20 Jul 2006 16:40:28 +0100 Message-ID: <4E28CEA517A795438B120F62D182A8C906D04088@I2KM11-UKBR.domain1.systemhost.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Hum for new WG items Thread-Index: Acaqa1Eazl/aNav8Qo2rHbtDUU5EFgBp21EQ From: To: , X-OriginalArrivalTime: 20 Jul 2006 15:40:30.0071 (UTC) FILETIME=[D478C070:01C6AC12] X-Spam-Score: 0.2 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org HUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUMMMMMMMMMMMMMMM MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM For all 3 Steve Norreys=20 -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: 18 July 2006 14:09 To: ECRIT Subject: [Ecrit] Hum for new WG items Hi all, our new milestones are available at the charter: http://www.ietf.org/html.charters/ecrit-charter.html Hence, we would like to confirm decisions on the mailing list in order to turn the following three documents into working group docments: * Location-to-URL Mapping Architecture and Framework http://www.ietf-ecrit.org/cache/draft-schulzrinne-ecrit-mapping-arch-00. txt This document matches the following charter item: Nov 2006 An Informational document describing the Mapping Protocol=20 Architecture * Framework for Emergency Calling in Internet Multimedia http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-emergency-framework-00 .txt This document matches the following charter item: Dec 2006 An Informational document describing the ECRIT Framework * Best Current Practice for Communications Services in support of Emergency Calling http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-01.txt This document matches the following charter item: Feb 2007 A BCP document describing the emergency call support for=20 devices The chairs have asked the group already at the Washington interim meeting, at the IETF#65 and at the IETF#66 meeting whether there is enough interest in these document. There was strong support for these documents. Please speak for or against making draft-schulzrinne-ecrit-mapping-arch-00.txt, draft-rosen-ecrit-emergency-framework-00.txt and draft-rosen-ecrit-phonebcp-01.txt working group items (unless you have already expressed your opinion). Deadline is the 31st July 2006. Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Jul 20 12:25:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bLP-0004Ui-DE; Thu, 20 Jul 2006 12:25:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3bLO-0004SC-Ox for ecrit@ietf.org; Thu, 20 Jul 2006 12:25:46 -0400 Received: from mx1.cambrium.nl ([217.19.16.130] helo=gollum.cambrium.nl) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3bLN-0002Bh-Ac for ecrit@ietf.org; Thu, 20 Jul 2006 12:25:46 -0400 Received: (qmail 25639 invoked from network); 20 Jul 2006 16:25:44 -0000 Received: from 82-197-192-189.dsl.cambrium.nl (HELO solstice) (82.197.192.189) by gollum.cambrium.nl with SMTP; 20 Jul 2006 16:25:44 -0000 From: "Arnoud van Wijk" To: Subject: RE: [Ecrit] Hum for new WG items Date: Thu, 20 Jul 2006 18:25:46 +0200 Message-ID: <000c01c6ac19$27e33780$1f00a8c0@solstice> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: <4E28CEA517A795438B120F62D182A8C906D04088@I2KM11-UKBR.domain1.systemhost.net> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-index: Acaqa1Eazl/aNav8Qo2rHbtDUU5EFgBp21EQAAGRvXA= X-Spam-Score: 0.1 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Especially big loud HUMMMMMMMMMM for ://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-01.txt Arnoud A. T. van Wijk AnnieS New Technology www.AnnieS.nl Mobile textphone (SIP): arnoud@annies.nl > -----Original Message----- > From: steve.norreys@bt.com [mailto:steve.norreys@bt.com] > Sent: donderdag 20 juli 2006 17:40 > To: Hannes.Tschofenig@gmx.net; ecrit@ietf.org > Subject: RE: [Ecrit] Hum for new WG items > > HUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUMMMMMMMMMMMMMMM > MMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMMM > > For all 3 > > Steve Norreys > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: 18 July 2006 14:09 > To: ECRIT > Subject: [Ecrit] Hum for new WG items > > Hi all, > > our new milestones are available at the charter: > http://www.ietf.org/html.charters/ecrit-charter.html > > Hence, we would like to confirm decisions on the mailing list in order > to turn the following three documents into working group docments: > > * Location-to-URL Mapping Architecture and Framework > http://www.ietf-ecrit.org/cache/draft-schulzrinne-ecrit-mapping-arch-00. > txt > > This document matches the following charter item: > > Nov 2006 An Informational document describing the Mapping Protocol > Architecture > > * Framework for Emergency Calling in Internet Multimedia > http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-emergency-framework-00 > .txt > > This document matches the following charter item: > > Dec 2006 An Informational document describing the ECRIT Framework > > * Best Current Practice for Communications Services in support of > Emergency Calling > http://www.ietf-ecrit.org/cache/draft-rosen-ecrit-phonebcp-01.txt > > This document matches the following charter item: > > Feb 2007 A BCP document describing the emergency call support for > devices > > The chairs have asked the group already at the Washington interim > meeting, at the IETF#65 and at the IETF#66 meeting whether there is > enough interest in these document. There was strong support for these > documents. > > Please speak for or against making > draft-schulzrinne-ecrit-mapping-arch-00.txt, > draft-rosen-ecrit-emergency-framework-00.txt and > draft-rosen-ecrit-phonebcp-01.txt working group items (unless you have > already expressed your opinion). > > Deadline is the 31st July 2006. > > Ciao > Hannes & Marc > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Jul 21 13:51:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3z9p-0001Vr-Ef; Fri, 21 Jul 2006 13:51:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3z9n-0001Up-NE for ecrit@ietf.org; Fri, 21 Jul 2006 13:51:23 -0400 Received: from web39510.mail.mud.yahoo.com ([209.191.106.94]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G3z7c-0004ES-FA for ecrit@ietf.org; Fri, 21 Jul 2006 13:49:09 -0400 Received: (qmail 91668 invoked by uid 60001); 21 Jul 2006 17:49:08 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VLp/eYgfP//vjGUMykvCqAwygBLP5x7Ol5/Qm9cY8O/uI5SmbWfQLVlTP3icneUSJg8wn92llEOSpzmD2T/cmbKsNKJjO/Wg80ZbvfmH4Xi6SQtSyp0mbotSpcbER7wOtbzyJITIPnYXRaMcHXVCvtcXIPD2BuzjVZOdJGh9h58= ; Message-ID: <20060721174908.91666.qmail@web39510.mail.mud.yahoo.com> Received: from [200.107.2.224] by web39510.mail.mud.yahoo.com via HTTP; Fri, 21 Jul 2006 12:49:08 CDT Date: Fri, 21 Jul 2006 12:49:08 -0500 (CDT) From: Mario Defaz To: ecrit@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] submission X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1085073482==" Errors-To: ecrit-bounces@ietf.org --===============1085073482== Content-Type: multipart/alternative; boundary="0-945106246-1153504148=:91664" Content-Transfer-Encoding: 8bit --0-945106246-1153504148=:91664 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.espanol.yahoo.com/ --0-945106246-1153504148=:91664 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.espanol.yahoo.com/ --0-945106246-1153504148=:91664-- --===============1085073482== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit --===============1085073482==-- From ecrit-bounces@ietf.org Sun Jul 23 07:47:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4cR4-00056W-TD; Sun, 23 Jul 2006 07:47:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4cR3-00056R-Br for ecrit@ietf.org; Sun, 23 Jul 2006 07:47:49 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G4cQz-0004sE-UF for ecrit@ietf.org; Sun, 23 Jul 2006 07:47:49 -0400 Received: (qmail invoked by alias); 23 Jul 2006 11:47:37 -0000 Received: from ip-80-226-155-78.vodafone-net.de (EHLO [10.227.167.33]) [80.226.155.78] by mail.gmx.net (mp006) with SMTP; 23 Jul 2006 13:47:37 +0200 X-Authenticated: #29516787 Message-ID: <44C361D0.3030808@gmx.net> Date: Sun, 23 Jul 2006 13:47:28 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [Ecrit] Finishing the ECRIT Requirements Work X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, based on the WGLC comments of the ECRIT requirements draft we concluded that the document is as good as finished. I reviewed the document again and found a few minor bugs that got introduced with a recent terminology alignment with the Service URN draft. Some of you might recall that we had a severe terminology problem with the terms dial strings, emergency identifiers, etc. The requirements draft contains the updated terminology but the text in Section 6 seems to suffer from a few cut-and-paste errors. Hence, I have a few simple text replacement suggestions: Change from: " Id1. Emergency service identifier support: The mapping protocol MUST be able to return one or multiple emergency service identifiers in response to a query. Motivation: Since there is a need for any device or network element to recognize an emergency call throughout the call setup, there is also a need to have the mapping protocol provide support for such an identifier. This is regardless of the device location or the ASP/VSP used. An example of this kind of identifier might be the emergency service URN, 'urn:service:sos'. " to: " Id1. Emergency dial string support: The mapping protocol MUST be able to return one or multiple emergency dial strings in response to a query. Motivation: Since there is a need for any device or network element to recognize an emergency call throughout the call setup, there is also a need to have the mapping protocol provide support for dial strings. '911' is an example of such an emergency dial string. " If we make this change then we can also delete requirement Id1 since it is then covered by Id4. Change from: " Motivation: Any signaling protocol requires the use of some identifier to indicate the called party, and the user terminal may lack the capability to determine the actual emergency address (PSAP URI). " to: " Motivation: Any signaling protocol requires the use of some identifier to indicate the called party, and the user terminal may lack the capability to determine the actual emergency identifier. " Requirement Id4 and Id9 needs to be merged. Id9 is a subset of Id4. You might want to reuse the motiviation text from Id9 in Id4. Minor issue in Section 7: Change from: " A proposed mapping protocol is outlined in the document I-D.hardie-ecrit-lost [9]. " to: " A proposed mapping protocol is outlined in [9]. " Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 23 07:49:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4cSn-0005N2-9z; Sun, 23 Jul 2006 07:49:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4cSm-0005Mx-QD for ecrit@ietf.org; Sun, 23 Jul 2006 07:49:36 -0400 Received: from mail.gmx.net ([213.165.64.21]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G4cSl-00053a-D0 for ecrit@ietf.org; Sun, 23 Jul 2006 07:49:36 -0400 Received: (qmail invoked by alias); 23 Jul 2006 11:49:33 -0000 Received: from ip-80-226-155-78.vodafone-net.de (EHLO [10.227.167.33]) [80.226.155.78] by mail.gmx.net (mp018) with SMTP; 23 Jul 2006 13:49:33 +0200 X-Authenticated: #29516787 Message-ID: <44C36246.2020502@gmx.net> Date: Sun, 23 Jul 2006 13:49:26 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ECRIT Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ecrit] Moving forward with the Service URN Draft X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi all, James raised a concern regarding the Service URN draft in the ECRIT meeting and also at the mailing. He is not happy with the content with respect to the organization of the document. The document contains two things: 1) definition of the service URNs (see Section 3, 5.3 and 5.4.) 2) resolution mechanism (see Section 4 and IANA consideration of the draft-ietf-ecrit-service-urn-03.txt document) In order to create the URN scheme RFC 3406 dictates that a resolution mechanism for the new URN has to be included. Marc, Henning, Jon and Ted met during IETF#66 and discussed the issue and the following resolution was proposed: The content regarding URN resolution (including LoST server discovery) will be moved to the LoST document. The Service URN draft will contain a normative reference to the LoST draft. As a consequence the document will sit in the RFC editors queue waiting for LoST. What do others think about the concerns and the suggested way forward? Ciao Hannes & Marc _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Jul 23 10:24:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4ese-0006w8-By; Sun, 23 Jul 2006 10:24:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4esd-0006w3-8p for ecrit@ietf.org; Sun, 23 Jul 2006 10:24:27 -0400 Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G4esa-00024n-UN for ecrit@ietf.org; Sun, 23 Jul 2006 10:24:27 -0400 Received: from [192.168.0.41] (pool-141-153-188-67.mad.east.verizon.net [141.153.188.67]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id k6NEOM4t017235 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT); Sun, 23 Jul 2006 10:24:22 -0400 (EDT) In-Reply-To: <44C361D0.3030808@gmx.net> References: <44C361D0.3030808@gmx.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A4F4F8A-3C33-42AF-B2BE-481DF1460E06@cs.columbia.edu> Content-Transfer-Encoding: 7bit From: Henning Schulzrinne Subject: Re: [Ecrit] Finishing the ECRIT Requirements Work Date: Sun, 23 Jul 2006 10:24:14 -0400 To: Hannes Tschofenig X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org See inline. On Jul 23, 2006, at 7:47 AM, Hannes Tschofenig wrote: > Hi all, > > Change from: > > " > Id1. Emergency service identifier support: The mapping protocol > MUST > be able to return one or multiple emergency service > identifiers in > response to a query. > > Motivation: Since there is a need for any device or network > element to recognize an emergency call throughout the call > setup, > there is also a need to have the mapping protocol provide > support > for such an identifier. This is regardless of the device > location > or the ASP/VSP used. An example of this kind of identifier > might > be the emergency service URN, 'urn:service:sos'. > > " > > to: > > " > Id1. Emergency dial string support: The mapping protocol MUST > be able to return one or multiple emergency dial strings in > response to a query. > > Motivation: Since there is a need for any device or network > element to recognize an emergency call throughout the call > setup, > there is also a need to have the mapping protocol provide > support > for dial strings. '911' is an example of such an emergency dial > string. > > " > > If we make this change then we can also delete requirement Id1 > since it is then covered by Id4. > This is probably lost in the history of the draft somewhere, but I'm guessing that this actually refers to the ability to return multiple PSAP URLs. I have to admit that, on re-reading, I find that the various identifier definitions in the draft are less than crisp and easy to distinguish, as the word "identifier" is used rather liberally. I think this needs to be cleaned up since the terminology section is probably the part that other documents should refer to, long after the requirements themselves have become uninteresting. I think we should define these terms: service number: The service number is a string of digits used to reach the service. It is the number typically dialed on devices directly connected to the PSTN and the number reserved by national or regional numbering authorities. The service number may depend on the location of the caller. For example, the general emergency service number in the United States is 112 and the poison control service number is 18002221222. In most cases, the service number and dial string are the same; they may differ in some private phone networks. A service number may be carried in tel URLs, along with a context identifier [RFC]. service dial string: The service dial string identifies the string of digits that a caller must dial to reach a particular (emergency) service. In devices directly connected to the PSTN, the service dial string is the same as the service number and may thus depend on the location of the caller. However, in private phone networks, such as in PBXs, the service dial string may contain a prefix to reach an outside line. For example, in a hotel, the dial string for emergency services in the United States might be 9911. Service dial strings are outside the scope of this document. service identifier: The service identifier describes the emergency service independent of the user interface mechanism, the signaling protocol that is used to reach the service and the caller's geographic location. It is a protocol constant and used within the mapping and signaling protocols. An example is the service URN []. service URL: The service URL is a routable URL that contains the address of the PSAP or other emergency service. It depends on the specific signaling or data transport protocol used to reach the emergency service. Examples include SIP, XMPP and mailto URLs. We could also add a table to make this clearer: depends on location? depends on protocol? user- visible? example protocol usage service number: yes no yes tel URL service dial string: yes no yes SIP dial string service identifier: no no unlikely LoST, SIP service URL: no yes unlikely SIP request URI --- end text --- For concreteness, we could also replace each "service" with "emergency service". Note that this reflects the discussion we had in the context of the LoST draft. The requirements draft defines, but never uses, the term ESI. I would drop this term as it just adds confusion. > > Change from: > > " > Motivation: Any signaling protocol requires the use of some > identifier to indicate the called party, and the user > terminal may > lack the capability to determine the actual emergency address > (PSAP URI). > " > > to: > > " > Motivation: Any signaling protocol requires the use of some > identifier to indicate the called party, and the user > terminal may > lack the capability to determine the actual emergency > identifier. > " > > > > Requirement Id4 and Id9 needs to be merged. Id9 is a subset of Id4. > You might want to reuse the motiviation text from Id9 in Id4. I think we should simply have one requirement for each identifier noted above, in the same order. Henning _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 24 03:51:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4vDj-0001hS-V8; Mon, 24 Jul 2006 03:51:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G4vDi-0001hN-Ic for ecrit@ietf.org; Mon, 24 Jul 2006 03:51:18 -0400 Received: from mail.gmx.de ([213.165.64.21] helo=mail.gmx.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G4vDf-00062T-VS for ecrit@ietf.org; Mon, 24 Jul 2006 03:51:18 -0400 Received: (qmail invoked by alias); 24 Jul 2006 07:51:10 -0000 Received: from ip-80-226-238-41.vodafone-net.de (EHLO [10.227.149.148]) [80.226.238.41] by mail.gmx.net (mp032) with SMTP; 24 Jul 2006 09:51:10 +0200 X-Authenticated: #29516787 Message-ID: <44C47BE5.9090309@gmx.net> Date: Mon, 24 Jul 2006 09:51:01 +0200 From: Hannes Tschofenig User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne Subject: Re: [Ecrit] Finishing the ECRIT Requirements Work References: <44C361D0.3030808@gmx.net> <5A4F4F8A-3C33-42AF-B2BE-481DF1460E06@cs.columbia.edu> In-Reply-To: <5A4F4F8A-3C33-42AF-B2BE-481DF1460E06@cs.columbia.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hi Henning, The most important question: Who is going to make the draft update and when can be group read the final result? Please find my comments inline: Henning Schulzrinne wrote: > See inline. > > On Jul 23, 2006, at 7:47 AM, Hannes Tschofenig wrote: > >> Hi all, >> >> Change from: >> >> " >> Id1. Emergency service identifier support: The mapping protocol MUST >> be able to return one or multiple emergency service identifiers in >> response to a query. >> >> Motivation: Since there is a need for any device or network >> element to recognize an emergency call throughout the call setup, >> there is also a need to have the mapping protocol provide support >> for such an identifier. This is regardless of the device location >> or the ASP/VSP used. An example of this kind of identifier might >> be the emergency service URN, 'urn:service:sos'. >> >> " >> >> to: >> >> " >> Id1. Emergency dial string support: The mapping protocol MUST >> be able to return one or multiple emergency dial strings in >> response to a query. >> >> Motivation: Since there is a need for any device or network >> element to recognize an emergency call throughout the call setup, >> there is also a need to have the mapping protocol provide support >> for dial strings. '911' is an example of such an emergency dial >> string. >> >> " >> >> If we make this change then we can also delete requirement Id1 since >> it is then covered by Id4. >> > > This is probably lost in the history of the draft somewhere, but I'm > guessing that this actually refers to the ability to return multiple > PSAP URLs. Currently the requirement for multiple PSAP URIs is covered by Ma7. > > I have to admit that, on re-reading, I find that the various identifier > definitions in the draft are less than crisp and easy to distinguish, > as the word "identifier" is used rather liberally. I think this needs > to be cleaned up since the terminology section is probably the part > that other documents should refer to, long after the requirements > themselves have become uninteresting. I agree. > > I think we should define these terms: > > service number: The service number is a string of digits used to reach > the service. It is the number typically dialed on devices directly > connected to the PSTN and the number reserved by national or regional > numbering authorities. The service number may depend on the location of > the caller. For example, the general emergency service number in the > United States is 112 and the poison control service number is > 18002221222. In most cases, the service number and dial string are the > same; they may differ in some private phone networks. A service number > may be carried in tel URLs, along with a context identifier [RFC]. > > service dial string: The service dial string identifies the string of > digits that a caller must dial to reach a particular (emergency) > service. In devices directly connected to the PSTN, the service dial > string is the same as the service number and may thus depend on the > location of the caller. However, in private phone networks, such as in > PBXs, the service dial string may contain a prefix to reach an outside > line. For example, in a hotel, the dial string for emergency services > in the United States might be 9911. Service dial strings are outside > the scope of this document. > > service identifier: The service identifier describes the emergency > service independent of the user interface mechanism, the signaling > protocol that is used to reach the service and the caller's geographic > location. It is a protocol constant and used within the mapping and > signaling protocols. An example is the service URN []. > > service URL: The service URL is a routable URL that contains the > address of the PSAP or other emergency service. It depends on the > specific signaling or data transport protocol used to reach the > emergency service. Examples include SIP, XMPP and mailto URLs. > > We could also add a table to make this clearer: > > depends on location? depends on protocol? user- > visible? example protocol usage > service number: yes no > yes tel URL > service dial string: yes no > yes SIP dial string > service identifier: no no > unlikely LoST, SIP > service URL: no yes > unlikely SIP request URI > > > --- end text --- > > For concreteness, we could also replace each "service" with "emergency > service". I am fine with the terms. They are a generalized from of the 'emergency dial string' and 'emergency identifier' that are already in the draft. > > Note that this reflects the discussion we had in the context of the > LoST draft. The requirements draft defines, but never uses, the term > ESI. I would drop this term as it just adds confusion. Fine with me. > > > >> >> Change from: >> >> " >> Motivation: Any signaling protocol requires the use of some >> identifier to indicate the called party, and the user terminal may >> lack the capability to determine the actual emergency address >> (PSAP URI). >> " >> >> to: >> >> " >> Motivation: Any signaling protocol requires the use of some >> identifier to indicate the called party, and the user terminal may >> lack the capability to determine the actual emergency identifier. >> " >> >> >> >> Requirement Id4 and Id9 needs to be merged. Id9 is a subset of Id4. >> You might want to reuse the motiviation text from Id9 in Id4. > > > I think we should simply have one requirement for each identifier noted > above, in the same order. I would like to see the text first. Ciao Hannes > > Henning > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Jul 24 09:21:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G50NX-0008In-7T; Mon, 24 Jul 2006 09:21:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G50NV-0008If-EG for ecrit@ietf.org; Mon, 24 Jul 2006 09:21:45 -0400 Received: from zeke.toscano.org ([69.31.8.124] helo=zeke.ecotroph.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G50NU-0006tq-86 for ecrit@ietf.org; Mon, 24 Jul 2006 09:21:45 -0400 Received: from [127.0.0.1] ([::ffff:208.50.38.5]) (AUTH: LOGIN anewton) by zeke.ecotroph.net with esmtp; Mon, 24 Jul 2006 09:21:54 -0400 id 01588075.44C4C972.00007E6F Message-ID: <44C4C95F.1000300@hxr.us> Date: Mon, 24 Jul 2006 09:21:35 -0400 From: Andrew Newton User-Agent: Thunderbird 1.5.0.4 (Windows/20060516) MIME-Version: 1.0 To: Hannes Tschofenig Subject: Re: [Ecrit] Moving forward with the Service URN Draft References: <44C36246.2020502@gmx.net> In-Reply-To: <44C36246.2020502@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: ECRIT X-BeenThere: ecrit@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ecrit.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ecrit-bounces@ietf.org Hannes Tschofenig wrote: > What do others think about the concerns and the suggested way forward? I think it is unnecessary, but this is a workable compromise. -andy _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit