From ecrit-bounces@ietf.org Thu Nov 01 04:05:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InV1S-0007M5-UM; Thu, 01 Nov 2007 04:03:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InV1R-0007K3-H7 for ecrit@ietf.org; Thu, 01 Nov 2007 04:03:25 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InV1I-0003DB-HN for ecrit@ietf.org; Thu, 01 Nov 2007 04:03:25 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1InV16-0008KP-4v; Thu, 01 Nov 2007 03:03:04 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Richard Barnes'" , "'Stark, Barbara'" , "'ECRIT'" References: <002801c81bbc$a673fd00$1d69fe90@cis.neustar.com><7582BC68E4994F4ABF0BD4723975C3FA063767D9@crexc41p><47288F84.5010203@bbn.com> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery Date: Thu, 1 Nov 2007 04:03:08 -0400 Message-ID: <02b501c81c5d$a644eb90$1d69fe90@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: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuA= In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: 9af087f15dbdd4c64ae6bbcdbc5b1d44 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 think the problem that Barbara points out is precisely the problem in deploying HELD. Claiming that a problem can't be solved, and therefore should not be mentioned is, uh, ?unhelpful? Having the "caveat" instead of a deployment recommendation understates the problem. While it is possible to deploy HELD so that it almost always works, it will take a lot of attention by a lot of entities to make that happen. For example, if HELD is deployed, no non-bypassable VPNs can be permitted. The protocol document should be very clear about what it takes to make HELD work. I have no problem including text that covers what devices and LIS's need to do, as long as it was noted that it won't always be sufficient. We might also include text on how enterprise networks should be configured. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Wednesday, October 31, 2007 11:58 AM > To: Richard Barnes; Stark, Barbara; ECRIT > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > indraft-ietf-geopriv-http-location-delivery > > I think that the "device" requirement at most should be that efforts > should be made to ensure that the LIS is discovered and used on the > physical access network and not via any VPN tunnel. > > Perhaps more importantly, there should be a complementary requirement on > the LIS that it not attempt to provide location for an IP address that > it cannot associate a physical location with. For example, a LIS in an > enterprise, where that enterprise supports VPN access, should know or be > able to determine that the client requests are arriving over a VPN from > an end point whose location cannot be determined. The HELD response > should indicate that location cannot be provided. > > Cheers, > Martin > > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Thursday, 1 November 2007 1:22 AM > To: Stark, Barbara; ECRIT > Subject: [Ecrit] Re: [Geopriv] Use of IP address as anidentifier > indraft-ietf-geopriv-http-location-delivery > > Right, I think what's needed is more a caveat that HELD provides the > location of the source IP address in the IP header of the request -- > whatever that may be. > > --Richard > > > > Stark, Barbara wrote: > > How is a client supposed to know whether a "VPN, NAT or other IP > address > > modification exists between the client and the server which could > > produce incorrect location"? One of the best uses of HELD is the case > > where there is a NAT (and the box with the NAT is location unaware). > For > > landline broadband services, this NAT exists, but doesn't produce an > > incorrect location. So this NAT is ok. How can you distinguish between > a > > NAT that produces an incorrect location, vs. one that produces a > correct > > location? > > > > The VPN could be originated out of the router, and not the client. How > > would the client know this VPN even exists? > > > > Unless you can tell me the logic to use to implement this proposed > > requirement, I can't support it. > > Barbara > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, October 31, 2007 8:51 AM > > To: geopriv@ietf.org > > Subject: [Geopriv] Use of IP address as an identifier > > indraft-ietf-geopriv-http-location-delivery > > > > In the long set of discussions that have lead to HELD, one of the > > biggest > > concerns a few of us have had is the problem than an IP address may > not > > be a > > good identifier for determining the location of the client. There is > a > > draft that describes alternate identifiers. However, there is no > > discussion > > in the present draft of the base protocol on these issues. > > > > I would like to propose that we add text something like: > > > > Use of HELD is subject to the viability of the identifier used by the > > LIS to > > determine location. This document describes the use of the IP address > > of > > the client as the identifier. When a NAT, VPN or other forms of > address > > modification occur between the client and the server, the location > > returned > > may be inaccurate. This is not always the case. For example, a NAT > > used in > > a residential local area network is typically not a problem, because > the > > external IP address used on the WAN side of the NAT is in fact the > right > > identifier for all of the devices in the residence. On the other > hand, > > if > > there is a VPN between the client and the server, for example for a > > teleworker, then the address seen by the server may not be the right > > address > > to identify the location of the client. Where a VPN is deployed, > > clients > > often have the ability to bypass the VPN for a transaction like HELD. > > > > HELD Clients MUST NOT send HELD requests where IP address is the > > identifier > > and a VPN, NAT or other IP address modification exists between the > > client > > and the server which could produce incorrect location. HELD MUST NOT > be > > deployed in networks where the client cannot comply reasonably > reliably > > with > > that requirement. > > > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > ***** > > > > 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. GA623 > > > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > R > > _______________________________________________ > 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 Thu Nov 01 05:42:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InWZN-0002Lq-Nb; Thu, 01 Nov 2007 05:42:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InWZI-0002D0-CD for ecrit@ietf.org; Thu, 01 Nov 2007 05:42:28 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InWZC-0000bi-4t for ecrit@ietf.org; Thu, 01 Nov 2007 05:42:28 -0400 Received: from ([139.76.131.31]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.187884727; Thu, 01 Nov 2007 05:41:50 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010625.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 1 Nov 2007 05:41:50 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 1 Nov 2007 05:41:50 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 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] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery Date: Thu, 1 Nov 2007 05:41:47 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA063769EA@crexc41p> In-Reply-To: <02b501c81c5d$a644eb90$1d69fe90@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery thread-index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUA== References: <002801c81bbc$a673fd00$1d69fe90@cis.neustar.com><7582BC68E4994F4ABF0BD4723975C3FA063767D9@crexc41p><47288F84.5010203@bbn.com> <02b501c81c5d$a644eb90$1d69fe90@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Dawson, Martin" , "Richard Barnes" , "ECRIT" X-OriginalArrivalTime: 01 Nov 2007 09:41:50.0555 (UTC) FILETIME=[6D93F2B0:01C81C6B] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df 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 Oh, fine, I'll try to be helpful, then. I definitely agree with having the problem mentioned and properly characterized. But when we write requirements, I want to be sure that the requirements are implementable. Certainly, end devices must do location configuration before establishing a VPN. Once an end device has established a VPN, it must not do any LIS discovery or HELD queries over the VPN connection. The Access Network, however, needs to have the requirement that its LIS be able to know which subnets of IP addresses are supplied to devices coming over VPN access, or have been provided to a company that provides its own LIS. That is, such blocks of IP addresses need to be configurable in the LIS. Then there's the requirement that the LIS must not provide location to these IP addresses. The access network (access provider + ISP) also has a responsibility not to place a LIS on the core side of any NAT that is employed in the access network. Note that this isn't meant to apply to home router NATs, since those aren't part of the access network, according to the definition of access network. I really think that the access network has greater ability, and therefore greater responsibility, to minimize the occurrence of problems due to VPNs and NATs. As we discussed (Brian and I), I'm going to try to suggest a way to better include in phonebcp requirements for routers employed in "small areas". One of the requirements we need for these, is that they MUST act as the LIS for LAN-side devices, when they have VPN connections to the WAN. Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, November 01, 2007 4:03 AM To: 'Dawson, Martin'; 'Richard Barnes'; Stark, Barbara; 'ECRIT' Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery I think the problem that Barbara points out is precisely the problem in deploying HELD. Claiming that a problem can't be solved, and therefore should not be mentioned is, uh, ?unhelpful? Having the "caveat" instead of a deployment recommendation understates the problem. While it is possible to deploy HELD so that it almost always works, it will take a lot of attention by a lot of entities to make that happen. For example, if HELD is deployed, no non-bypassable VPNs can be permitted. The protocol document should be very clear about what it takes to make HELD work. I have no problem including text that covers what devices and LIS's need to do, as long as it was noted that it won't always be sufficient. We might also include text on how enterprise networks should be configured. Brian =20 > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Wednesday, October 31, 2007 11:58 AM > To: Richard Barnes; Stark, Barbara; ECRIT > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > indraft-ietf-geopriv-http-location-delivery >=20 > I think that the "device" requirement at most should be that efforts > should be made to ensure that the LIS is discovered and used on the > physical access network and not via any VPN tunnel. >=20 > Perhaps more importantly, there should be a complementary requirement on > the LIS that it not attempt to provide location for an IP address that > it cannot associate a physical location with. For example, a LIS in an > enterprise, where that enterprise supports VPN access, should know or be > able to determine that the client requests are arriving over a VPN from > an end point whose location cannot be determined. The HELD response > should indicate that location cannot be provided. >=20 > Cheers, > Martin >=20 > -----Original Message----- > From: Richard Barnes [mailto:rbarnes@bbn.com] > Sent: Thursday, 1 November 2007 1:22 AM > To: Stark, Barbara; ECRIT > Subject: [Ecrit] Re: [Geopriv] Use of IP address as anidentifier > indraft-ietf-geopriv-http-location-delivery >=20 > Right, I think what's needed is more a caveat that HELD provides the > location of the source IP address in the IP header of the request -- > whatever that may be. >=20 > --Richard >=20 >=20 >=20 > Stark, Barbara wrote: > > How is a client supposed to know whether a "VPN, NAT or other IP > address > > modification exists between the client and the server which could > > produce incorrect location"? One of the best uses of HELD is the case > > where there is a NAT (and the box with the NAT is location unaware). > For > > landline broadband services, this NAT exists, but doesn't produce an > > incorrect location. So this NAT is ok. How can you distinguish between > a > > NAT that produces an incorrect location, vs. one that produces a > correct > > location? > > > > The VPN could be originated out of the router, and not the client. How > > would the client know this VPN even exists? > > > > Unless you can tell me the logic to use to implement this proposed > > requirement, I can't support it. > > Barbara > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Wednesday, October 31, 2007 8:51 AM > > To: geopriv@ietf.org > > Subject: [Geopriv] Use of IP address as an identifier > > indraft-ietf-geopriv-http-location-delivery > > > > In the long set of discussions that have lead to HELD, one of the > > biggest > > concerns a few of us have had is the problem than an IP address may > not > > be a > > good identifier for determining the location of the client. There is > a > > draft that describes alternate identifiers. However, there is no > > discussion > > in the present draft of the base protocol on these issues. > > > > I would like to propose that we add text something like: > > > > Use of HELD is subject to the viability of the identifier used by the > > LIS to > > determine location. This document describes the use of the IP address > > of > > the client as the identifier. When a NAT, VPN or other forms of > address > > modification occur between the client and the server, the location > > returned > > may be inaccurate. This is not always the case. For example, a NAT > > used in > > a residential local area network is typically not a problem, because > the > > external IP address used on the WAN side of the NAT is in fact the > right > > identifier for all of the devices in the residence. On the other > hand, > > if > > there is a VPN between the client and the server, for example for a > > teleworker, then the address seen by the server may not be the right > > address > > to identify the location of the client. Where a VPN is deployed, > > clients > > often have the ability to bypass the VPN for a transaction like HELD. > > > > HELD Clients MUST NOT send HELD requests where IP address is the > > identifier > > and a VPN, NAT or other IP address modification exists between the > > client > > and the server which could produce incorrect location. HELD MUST NOT > be > > deployed in networks where the client cannot comply reasonably > reliably > > with > > that requirement. > > > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > ***** > > > > 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. GA623 > > > > > > > > > > _______________________________________________ > > Geopriv mailing list > > Geopriv@ietf.org > > https://www1.ietf.org/mailman/listinfo/geopriv > > > R >=20 > _______________________________________________ > 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. > 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] >=20 >=20 > _______________________________________________ > 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. GA625 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 01 05:45:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InWcG-0004Nz-Sb; Thu, 01 Nov 2007 05:45:32 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InWcF-0004Mz-A2 for ecrit@ietf.org; Thu, 01 Nov 2007 05:45:31 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InWcE-00010U-41 for ecrit@ietf.org; Thu, 01 Nov 2007 05:45:31 -0400 X-SEF-Processed: 5_0_0_910__2007_11_01_04_55_44 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 01 Nov 2007 04:55:44 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Nov 2007 04:45:25 -0500 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 Subject: RE: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier indraft-ietf-geopriv-http-location-delivery Date: Thu, 1 Nov 2007 04:45:22 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA063769EA@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyAvQ References: <002801c81bbc$a673fd00$1d69fe90@cis.neustar.com><7582BC68E4994F4ABF0BD4723975C3FA063767D9@crexc41p><47288F84.5010203@bbn.com><02b501c81c5d$a644eb90$1d69fe90@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA063769EA@crexc41p> From: "Winterbottom, James" To: "Stark, Barbara" , "Brian Rosen" , "Dawson, Martin" , "Richard Barnes" , "ECRIT" X-OriginalArrivalTime: 01 Nov 2007 09:45:25.0226 (UTC) FILETIME=[ED8824A0:01C81C6B] X-Spam-Score: 1.8 (+) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 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 Aren't these issues already characterized in the L7 LCP problems=0D=0Astate= ment=3F=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Stark, Barbara= [mailto:bs7652@att.com]=0D=0A> Sent: Thursday, 1 November 2007 8:42 PM=0D=0A= > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT=0D=0A> Subject: RE= : [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier=0D=0A> indraft-ietf= -geopriv-http-location-delivery=0D=0A>=20=0D=0A> Oh, fine, I'll try to be h= elpful, then.=0D=0A> I definitely agree with having the problem mentioned a= nd properly=0D=0A> characterized. But when we write requirements, I want to= be sure that=0D=0A> the requirements are implementable.=0D=0A>=20=0D=0A> C= ertainly, end devices must do location configuration before=0D=0A> establis= hing a VPN. Once an end device has established a VPN, it must=0D=0A> not do= any LIS discovery or HELD queries over the VPN connection.=0D=0A>=20=0D=0A= > The Access Network, however, needs to have the requirement that its=0D=0A= LIS=0D=0A> be able to know which subnets of IP addresses are supplied to de= vices=0D=0A> coming over VPN access, or have been provided to a company tha= t=0D=0Aprovides=0D=0A> its own LIS. That is, such blocks of IP addresses ne= ed to be=0D=0A> configurable in the LIS. Then there's the requirement that = the LIS=0D=0Amust=0D=0A> not provide location to these IP addresses.=0D=0A>= =20=0D=0A> The access network (access provider + ISP) also has a responsibi= lity=0D=0Anot=0D=0A> to place a LIS on the core side of any NAT that is emp= loyed in the=0D=0A> access network. Note that this isn't meant to apply to = home router=0D=0ANATs,=0D=0A> since those aren't part of the access network= , according to the=0D=0A> definition of access network.=0D=0A>=20=0D=0A> I = really think that the access network has greater ability, and=0D=0A> theref= ore greater responsibility, to minimize the occurrence of=0D=0Aproblems=0D=0A= > due to VPNs and NATs.=0D=0A>=20=0D=0A> As we discussed (Brian and I), I'm= going to try to suggest a way to=0D=0A> better include in phonebcp require= ments for routers employed in "small=0D=0A> areas". One of the requirements= we need for these, is that they MUST=0D=0Aact=0D=0A> as the LIS for LAN-si= de devices, when they have VPN connections to the=0D=0A> WAN.=0D=0A> Barbar= a=0D=0A>=20=0D=0A> -----Original Message-----=0D=0A> From: Brian Rosen [mai= lto:br@brianrosen.net]=0D=0A> Sent: Thursday, November 01, 2007 4:03 AM=0D=0A= > To: 'Dawson, Martin'; 'Richard Barnes'; Stark, Barbara; 'ECRIT'=0D=0A> Su= bject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier=0D=0A> in= draft-ietf-geopriv-http-location-delivery=0D=0A>=20=0D=0A> I think the prob= lem that Barbara points out is precisely the problem=0D=0Ain=0D=0A> deployi= ng HELD. Claiming that a problem can't be solved, and=0D=0Atherefore=0D=0A= > should not be mentioned is, uh, =3Funhelpful=3F Having the "caveat"=0D=0A= instead=0D=0A> of=0D=0A> a deployment recommendation understates the proble= m. While it is=0D=0A> possible=0D=0A> to deploy HELD so that it almost alw= ays works, it will take a lot of=0D=0A> attention by a lot of entities to m= ake that happen. For example, if=0D=0A> HELD is=0D=0A> deployed, no non-by= passable VPNs can be permitted. The protocol=0D=0A> document=0D=0A> should= be very clear about what it takes to make HELD work.=0D=0A>=20=0D=0A> I ha= ve no problem including text that covers what devices and LIS's=0D=0Aneed=0D= =0A> to=0D=0A> do, as long as it was noted that it won't always be sufficie= nt. We=0D=0A> might=0D=0A> also include text on how enterprise networks sh= ould be configured.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A>=20=0D=0A> > ---= --Original Message-----=0D=0A> > From: Dawson, Martin [mailto:Martin.Dawson= @andrew.com]=0D=0A> > Sent: Wednesday, October 31, 2007 11:58 AM=0D=0A> > T= o: Richard Barnes; Stark, Barbara; ECRIT=0D=0A> > Subject: RE: [Ecrit] Re: = [Geopriv] Use of IP address asanidentifier=0D=0A> > indraft-ietf-geopriv-ht= tp-location-delivery=0D=0A> >=0D=0A> > I think that the "device" requiremen= t at most should be that efforts=0D=0A> > should be made to ensure that the= LIS is discovered and used on the=0D=0A> > physical access network and not= via any VPN tunnel.=0D=0A> >=0D=0A> > Perhaps more importantly, there shou= ld be a complementary=0D=0Arequirement=0D=0A> on=0D=0A> > the LIS that it n= ot attempt to provide location for an IP address=0D=0Athat=0D=0A> > it cann= ot associate a physical location with. For example, a LIS in=0D=0Aan=0D=0A>= > enterprise, where that enterprise supports VPN access, should know=0D=0A= or=0D=0A> be=0D=0A> > able to determine that the client requests are arrivi= ng over a VPN=0D=0A> from=0D=0A> > an end point whose location cannot be de= termined. The HELD response=0D=0A> > should indicate that location cannot b= e provided.=0D=0A> >=0D=0A> > Cheers,=0D=0A> > Martin=0D=0A> >=0D=0A> > ---= --Original Message-----=0D=0A> > From: Richard Barnes [mailto:rbarnes@bbn.c= om]=0D=0A> > Sent: Thursday, 1 November 2007 1:22 AM=0D=0A> > To: Stark, Ba= rbara; ECRIT=0D=0A> > Subject: [Ecrit] Re: [Geopriv] Use of IP address as a= nidentifier=0D=0A> > indraft-ietf-geopriv-http-location-delivery=0D=0A> >=0D= =0A> > Right, I think what's needed is more a caveat that HELD provides the=0D= =0A> > location of the source IP address in the IP header of the request --=0D= =0A> > whatever that may be.=0D=0A> >=0D=0A> > --Richard=0D=0A> >=0D=0A> >=0D= =0A> >=0D=0A> > Stark, Barbara wrote:=0D=0A> > > How is a client supposed t= o know whether a "VPN, NAT or other IP=0D=0A> > address=0D=0A> > > modifica= tion exists between the client and the server which could=0D=0A> > > produc= e incorrect location"=3F One of the best uses of HELD is the=0D=0A> case=0D= =0A> > > where there is a NAT (and the box with the NAT is location=0D=0Aun= aware).=0D=0A> > For=0D=0A> > > landline broadband services, this NAT exist= s, but doesn't produce=0D=0Aan=0D=0A> > > incorrect location. So this NAT i= s ok. How can you distinguish=0D=0A> between=0D=0A> > a=0D=0A> > > NAT that= produces an incorrect location, vs. one that produces a=0D=0A> > correct=0D= =0A> > > location=3F=0D=0A> > >=0D=0A> > > The VPN could be originated out = of the router, and not the client.=0D=0A> How=0D=0A> > > would the client k= now this VPN even exists=3F=0D=0A> > >=0D=0A> > > Unless you can tell me th= e logic to use to implement this proposed=0D=0A> > > requirement, I can't s= upport it.=0D=0A> > > Barbara=0D=0A> > >=0D=0A> > > -----Original Message--= ---=0D=0A> > > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > Sent= : Wednesday, October 31, 2007 8:51 AM=0D=0A> > > To: geopriv@ietf.org=0D=0A= > > > Subject: [Geopriv] Use of IP address as an identifier=0D=0A> > > indr= aft-ietf-geopriv-http-location-delivery=0D=0A> > >=0D=0A> > > In the long s= et of discussions that have lead to HELD, one of the=0D=0A> > > biggest=0D=0A= > > > concerns a few of us have had is the problem than an IP address=0D=0A= may=0D=0A> > not=0D=0A> > > be a=0D=0A> > > good identifier for determining= the location of the client. There=0D=0A> is=0D=0A> > a=0D=0A> > > draft t= hat describes alternate identifiers. However, there is no=0D=0A> > > discu= ssion=0D=0A> > > in the present draft of the base protocol on these issues.=0D= =0A> > >=0D=0A> > > I would like to propose that we add text something like= :=0D=0A> > >=0D=0A> > > Use of HELD is subject to the viability of the iden= tifier used by=0D=0A> the=0D=0A> > > LIS to=0D=0A> > > determine location. = This document describes the use of the IP=0D=0A> address=0D=0A> > > of=0D=0A= > > > the client as the identifier. When a NAT, VPN or other forms of=0D=0A= > > address=0D=0A> > > modification occur between the client and the server= , the location=0D=0A> > > returned=0D=0A> > > may be inaccurate. This is n= ot always the case. For example, a=0D=0ANAT=0D=0A> > > used in=0D=0A> > > = a residential local area network is typically not a problem,=0D=0Abecause=0D= =0A> > the=0D=0A> > > external IP address used on the WAN side of the NAT i= s in fact the=0D=0A> > right=0D=0A> > > identifier for all of the devices i= n the residence. On the other=0D=0A> > hand,=0D=0A> > > if=0D=0A> > > ther= e is a VPN between the client and the server, for example for=0D=0Aa=0D=0A>= > > teleworker, then the address seen by the server may not be the=0D=0Ari= ght=0D=0A> > > address=0D=0A> > > to identify the location of the client. = Where a VPN is deployed,=0D=0A> > > clients=0D=0A> > > often have the abili= ty to bypass the VPN for a transaction like=0D=0A> HELD.=0D=0A> > >=0D=0A> = > > HELD Clients MUST NOT send HELD requests where IP address is the=0D=0A>= > > identifier=0D=0A> > > and a VPN, NAT or other IP address modification = exists between the=0D=0A> > > client=0D=0A> > > and the server which could = produce incorrect location. HELD MUST=0D=0A> NOT=0D=0A> > be=0D=0A> > > de= ployed in networks where the client cannot comply reasonably=0D=0A> > relia= bly=0D=0A> > > with=0D=0A> > > that requirement.=0D=0A> > >=0D=0A> > >=0D=0A= > > >=0D=0A> > >=0D=0A> > > _______________________________________________=0D= =0A> > > Geopriv mailing list=0D=0A> > > Geopriv@ietf.org=0D=0A> > > https:= //www1.ietf.org/mailman/listinfo/geopriv=0D=0A> > >=0D=0A> > > *****=0D=0A>= > >=0D=0A> > > The information transmitted is intended only for the person= or=0D=0A> entity=0D=0A> > to which it is addressed and may contain confide= ntial, proprietary,=0D=0A> > and/or privileged material. Any review, retran= smission,=0D=0Adissemination=0D=0A> or=0D=0A> > other use of, or taking of = any action in reliance upon this=0D=0A> information=0D=0A> > by persons or = entities other than the intended recipient is=0D=0A> prohibited.=0D=0A> > I= f you received this in error, please contact the sender and delete=0D=0A> t= he=0D=0A> > material from all computers. GA623=0D=0A> > >=0D=0A> > >=0D=0A>= > >=0D=0A> > >=0D=0A> > > _______________________________________________=0D= =0A> > > Geopriv mailing list=0D=0A> > > Geopriv@ietf.org=0D=0A> > > https:= //www1.ietf.org/mailman/listinfo/geopriv=0D=0A> > >=0D=0A> > R=0D=0A> >=0D=0A= > > _______________________________________________=0D=0A> > Ecrit mailing = list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.ietf.org/mailman/listinf= o/ecrit=0D=0A> >=0D=0A> >=0D=0A>=0D=0A-------------------------------------= -----------------------------------=0D=0A> --=0D=0A> > --------------------= --=0D=0A> > This message is for the designated recipient only and may=0D=0A= > > contain privileged, proprietary, or otherwise private information.=0D=0A= > > If you have received it in error, please notify the sender=0D=0A> > imm= ediately and delete the original. Any unauthorized use of=0D=0A> > this em= ail is prohibited.=0D=0A> >=0D=0A>=0D=0A-----------------------------------= -------------------------------------=0D=0A> --=0D=0A> > ------------------= ----=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A> > ____________________________= ___________________=0D=0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A= > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A>=20=0D=0A>= *****=0D=0A>=20=0D=0A> The information transmitted is intended only for th= e person or entity=0D=0Ato=0D=0A> which it is addressed and may contain con= fidential, proprietary,=0D=0Aand/or=0D=0A> privileged material. Any review,= retransmission, dissemination or=0D=0Aother=0D=0A> use of, or taking of an= y action in reliance upon this information by=0D=0A> persons or entities ot= her than the intended recipient is prohibited.=0D=0AIf=0D=0A> you received = this in error, please contact the sender and delete the=0D=0A> material fro= m all computers. GA625=0D=0A>=20=0D=0A>=20=0D=0A>=20=0D=0A> _______________= ________________________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@iet= f.org=0D=0A> https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A------= ---------------------------------------------------------------------------= ---------------=0D=0AThis message is for the designated recipient only and = may=0D=0Acontain privileged, proprietary, or otherwise private information.= =20=0D=0AIf you have received it in error, please notify the sender=0D=0Ai= mmediately and delete the original. Any unauthorized use of=0D=0Athis emai= l is prohibited.=0D=0A-----------------------------------------------------= -------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 01 06:16:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InX5w-0000J2-Bp; Thu, 01 Nov 2007 06:16:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InX5u-0000IB-Ld for ecrit@ietf.org; Thu, 01 Nov 2007 06:16:10 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InX5t-000233-Eq for ecrit@ietf.org; Thu, 01 Nov 2007 06:16:10 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1InX5l-0000U5-VH; Thu, 01 Nov 2007 05:16:03 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Dawson, Martin'" , "'Richard Barnes'" , "'ECRIT'" References: <002801c81bbc$a673fd00$1d69fe90@cis.neustar.com><7582BC68E4994F4ABF0BD4723975C3FA063767D9@crexc41p><47288F84.5010203@bbn.com> <02b501c81c5d$a644eb90$1d69fe90@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA063769EA@crexc41p> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery Date: Thu, 1 Nov 2007 06:16:02 -0400 Message-ID: <02df01c81c70$37797240$1d69fe90@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: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6g In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA063769EA@crexc41p> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: a4cdc653ecdd96665f2aa1c1af034c9e 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 That's helpful. I don't think it's sufficient. My example, hardware VPN/tunnel mechanisms cannot be permitted, has to be spelled out. Also, phonebcp recommends location update at call time. We haven't worked out this detail, but I think we want to at least recommend that a mobile device send routing location as a value, and dispatch location as a reference (where needed), just to avoid the repeated dereference by all call routing elements. That means you would want to do the HELD LCP operation at call time. You need to discuss enterprise networks behind access networks that provide HELD, or try to use HELD within an enterprise network. I think it's hard to think through ALL the instances where an IP address isn't reliable as an identifier to be used for location, which is why I phrased my proposed text the way I did. Brian > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Thursday, November 01, 2007 5:42 AM > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > indraft-ietf-geopriv-http-location-delivery > > Oh, fine, I'll try to be helpful, then. > I definitely agree with having the problem mentioned and properly > characterized. But when we write requirements, I want to be sure that > the requirements are implementable. > > Certainly, end devices must do location configuration before > establishing a VPN. Once an end device has established a VPN, it must > not do any LIS discovery or HELD queries over the VPN connection. > > The Access Network, however, needs to have the requirement that its LIS > be able to know which subnets of IP addresses are supplied to devices > coming over VPN access, or have been provided to a company that provides > its own LIS. That is, such blocks of IP addresses need to be > configurable in the LIS. Then there's the requirement that the LIS must > not provide location to these IP addresses. > > The access network (access provider + ISP) also has a responsibility not > to place a LIS on the core side of any NAT that is employed in the > access network. Note that this isn't meant to apply to home router NATs, > since those aren't part of the access network, according to the > definition of access network. > > I really think that the access network has greater ability, and > therefore greater responsibility, to minimize the occurrence of problems > due to VPNs and NATs. > > As we discussed (Brian and I), I'm going to try to suggest a way to > better include in phonebcp requirements for routers employed in "small > areas". One of the requirements we need for these, is that they MUST act > as the LIS for LAN-side devices, when they have VPN connections to the > WAN. > Barbara > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, November 01, 2007 4:03 AM > To: 'Dawson, Martin'; 'Richard Barnes'; Stark, Barbara; 'ECRIT' > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > indraft-ietf-geopriv-http-location-delivery > > I think the problem that Barbara points out is precisely the problem in > deploying HELD. Claiming that a problem can't be solved, and therefore > should not be mentioned is, uh, ?unhelpful? Having the "caveat" instead > of > a deployment recommendation understates the problem. While it is > possible > to deploy HELD so that it almost always works, it will take a lot of > attention by a lot of entities to make that happen. For example, if > HELD is > deployed, no non-bypassable VPNs can be permitted. The protocol > document > should be very clear about what it takes to make HELD work. > > I have no problem including text that covers what devices and LIS's need > to > do, as long as it was noted that it won't always be sufficient. We > might > also include text on how enterprise networks should be configured. > > Brian > > > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Wednesday, October 31, 2007 11:58 AM > > To: Richard Barnes; Stark, Barbara; ECRIT > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > I think that the "device" requirement at most should be that efforts > > should be made to ensure that the LIS is discovered and used on the > > physical access network and not via any VPN tunnel. > > > > Perhaps more importantly, there should be a complementary requirement > on > > the LIS that it not attempt to provide location for an IP address that > > it cannot associate a physical location with. For example, a LIS in an > > enterprise, where that enterprise supports VPN access, should know or > be > > able to determine that the client requests are arriving over a VPN > from > > an end point whose location cannot be determined. The HELD response > > should indicate that location cannot be provided. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > Sent: Thursday, 1 November 2007 1:22 AM > > To: Stark, Barbara; ECRIT > > Subject: [Ecrit] Re: [Geopriv] Use of IP address as anidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > Right, I think what's needed is more a caveat that HELD provides the > > location of the source IP address in the IP header of the request -- > > whatever that may be. > > > > --Richard > > > > > > > > Stark, Barbara wrote: > > > How is a client supposed to know whether a "VPN, NAT or other IP > > address > > > modification exists between the client and the server which could > > > produce incorrect location"? One of the best uses of HELD is the > case > > > where there is a NAT (and the box with the NAT is location unaware). > > For > > > landline broadband services, this NAT exists, but doesn't produce an > > > incorrect location. So this NAT is ok. How can you distinguish > between > > a > > > NAT that produces an incorrect location, vs. one that produces a > > correct > > > location? > > > > > > The VPN could be originated out of the router, and not the client. > How > > > would the client know this VPN even exists? > > > > > > Unless you can tell me the logic to use to implement this proposed > > > requirement, I can't support it. > > > Barbara > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, October 31, 2007 8:51 AM > > > To: geopriv@ietf.org > > > Subject: [Geopriv] Use of IP address as an identifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > In the long set of discussions that have lead to HELD, one of the > > > biggest > > > concerns a few of us have had is the problem than an IP address may > > not > > > be a > > > good identifier for determining the location of the client. There > is > > a > > > draft that describes alternate identifiers. However, there is no > > > discussion > > > in the present draft of the base protocol on these issues. > > > > > > I would like to propose that we add text something like: > > > > > > Use of HELD is subject to the viability of the identifier used by > the > > > LIS to > > > determine location. This document describes the use of the IP > address > > > of > > > the client as the identifier. When a NAT, VPN or other forms of > > address > > > modification occur between the client and the server, the location > > > returned > > > may be inaccurate. This is not always the case. For example, a NAT > > > used in > > > a residential local area network is typically not a problem, because > > the > > > external IP address used on the WAN side of the NAT is in fact the > > right > > > identifier for all of the devices in the residence. On the other > > hand, > > > if > > > there is a VPN between the client and the server, for example for a > > > teleworker, then the address seen by the server may not be the right > > > address > > > to identify the location of the client. Where a VPN is deployed, > > > clients > > > often have the ability to bypass the VPN for a transaction like > HELD. > > > > > > HELD Clients MUST NOT send HELD requests where IP address is the > > > identifier > > > and a VPN, NAT or other IP address modification exists between the > > > client > > > and the server which could produce incorrect location. HELD MUST > NOT > > be > > > deployed in networks where the client cannot comply reasonably > > reliably > > > with > > > that requirement. > > > > > > > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > ***** > > > > > > 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. GA623 > > > > > > > > > > > > > > > _______________________________________________ > > > Geopriv mailing list > > > Geopriv@ietf.org > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > R > > > > _______________________________________________ > > 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 > > > ***** > > 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. GA625 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 01 09:36:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InaCn-0004I5-80; Thu, 01 Nov 2007 09:35:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InaCl-0004CA-DM for ecrit@ietf.org; Thu, 01 Nov 2007 09:35:27 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InaCb-0001m2-4d for ecrit@ietf.org; Thu, 01 Nov 2007 09:35:23 -0400 X-SEF-Processed: 5_0_0_910__2007_11_01_08_45_02 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 01 Nov 2007 08:45:02 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Nov 2007 08:34:43 -0500 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 Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery Date: Thu, 1 Nov 2007 08:34:40 -0500 Message-ID: In-Reply-To: <02df01c81c70$37797240$1d69fe90@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAfBuFA= References: <002801c81bbc$a673fd00$1d69fe90@cis.neustar.com><7582BC68E4994F4ABF0BD4723975C3FA063767D9@crexc41p><47288F84.5010203@bbn.com> <02b501c81c5d$a644eb90$1d69fe90@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA063769EA@crexc41p> <02df01c81c70$37797240$1d69fe90@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , "Stark, Barbara" , "Richard Barnes" , "ECRIT" X-OriginalArrivalTime: 01 Nov 2007 13:34:43.0005 (UTC) FILETIME=[F5CE9ED0:01C81C8B] X-Spam-Score: 1.8 (+) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 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 If you've got two enterprise sites connected via a branch to branch VPN=0D=0A= tunnel then it's quite possible to have a single LIS at the one site or=0D=0A= separate LIS at each site providing successful location fixes for both=0D=0A= sites. So it's not a case of forbidding hardware VPNs.=0D=0A=0D=0AI think t= he only hard rule - and it should be obvious anyway - is that=0D=0Aif a LIS= can't provide the location for a presented IP address then it=0D=0Ashould = not provide a location.=0D=0A=0D=0AIf an enterprise, for example, deploys a= locked down VPN client on their=0D=0AInternet-nomadic staff computers such= that they cannot communicate=0D=0Aoutside the VPN once the tunnel is estab= lished, then that enterprise has=0D=0Amade a decision that they do not want= to let those devices access the=0D=0Alocation service available at the loc= al physical network - particularly=0D=0Aif it won't even make the HELD quer= y prior to tunnel establishment.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A= -----Original Message-----=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net= ]=20=0D=0ASent: Thursday, 1 November 2007 9:16 PM=0D=0ATo: 'Stark, Barbara'= ; Dawson, Martin; 'Richard Barnes'; 'ECRIT'=0D=0ASubject: RE: [Ecrit] Re: [= Geopriv] Use of IP address asanidentifier=0D=0Aindraft-ietf-geopriv-http-lo= cation-delivery=0D=0A=0D=0AThat's helpful.=0D=0A=0D=0AI don't think it's su= fficient. My example, hardware VPN/tunnel=0D=0Amechanisms=0D=0Acannot be p= ermitted, has to be spelled out. Also, phonebcp recommends=0D=0Alocation u= pdate at call time. We haven't worked out this detail, but I=0D=0Athink we= want to at least recommend that a mobile device send routing=0D=0Alocation= as a value, and dispatch location as a reference (where=0D=0Aneeded),=0D=0A= just to avoid the repeated dereference by all call routing elements.=0D=0AT= hat=0D=0Ameans you would want to do the HELD LCP operation at call time.=0D= =0A=0D=0AYou need to discuss enterprise networks behind access networks tha= t=0D=0Aprovide=0D=0AHELD, or try to use HELD within an enterprise network.=0D= =0A=0D=0AI think it's hard to think through ALL the instances where an IP a= ddress=0D=0Aisn't reliable as an identifier to be used for location, which = is why I=0D=0Aphrased my proposed text the way I did.=0D=0A=0D=0ABrian=20=0D= =0A=0D=0A> -----Original Message-----=0D=0A> From: Stark, Barbara [mailto:b= s7652@att.com]=0D=0A> Sent: Thursday, November 01, 2007 5:42 AM=0D=0A> To: = Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT=0D=0A> Subject: RE: [Ecr= it] Re: [Geopriv] Use of IP address asanidentifier=0D=0A> indraft-ietf-geop= riv-http-location-delivery=0D=0A>=20=0D=0A> Oh, fine, I'll try to be helpfu= l, then.=0D=0A> I definitely agree with having the problem mentioned and pr= operly=0D=0A> characterized. But when we write requirements, I want to be s= ure that=0D=0A> the requirements are implementable.=0D=0A>=20=0D=0A> Certai= nly, end devices must do location configuration before=0D=0A> establishing = a VPN. Once an end device has established a VPN, it must=0D=0A> not do any = LIS discovery or HELD queries over the VPN connection.=0D=0A>=20=0D=0A> The= Access Network, however, needs to have the requirement that its=0D=0ALIS=0D= =0A> be able to know which subnets of IP addresses are supplied to devices=0D= =0A> coming over VPN access, or have been provided to a company that=0D=0Ap= rovides=0D=0A> its own LIS. That is, such blocks of IP addresses need to be=0D= =0A> configurable in the LIS. Then there's the requirement that the LIS=0D=0A= must=0D=0A> not provide location to these IP addresses.=0D=0A>=20=0D=0A> Th= e access network (access provider + ISP) also has a responsibility=0D=0Anot=0D= =0A> to place a LIS on the core side of any NAT that is employed in the=0D=0A= > access network. Note that this isn't meant to apply to home router=0D=0AN= ATs,=0D=0A> since those aren't part of the access network, according to the=0D= =0A> definition of access network.=0D=0A>=20=0D=0A> I really think that the= access network has greater ability, and=0D=0A> therefore greater responsib= ility, to minimize the occurrence of=0D=0Aproblems=0D=0A> due to VPNs and N= ATs.=0D=0A>=20=0D=0A> As we discussed (Brian and I), I'm going to try to su= ggest a way to=0D=0A> better include in phonebcp requirements for routers e= mployed in "small=0D=0A> areas". One of the requirements we need for these,= is that they MUST=0D=0Aact=0D=0A> as the LIS for LAN-side devices, when th= ey have VPN connections to the=0D=0A> WAN.=0D=0A> Barbara=0D=0A>=20=0D=0A> = -----Original Message-----=0D=0A> From: Brian Rosen [mailto:br@brianrosen.n= et]=0D=0A> Sent: Thursday, November 01, 2007 4:03 AM=0D=0A> To: 'Dawson, Ma= rtin'; 'Richard Barnes'; Stark, Barbara; 'ECRIT'=0D=0A> Subject: RE: [Ecrit= ] Re: [Geopriv] Use of IP address asanidentifier=0D=0A> indraft-ietf-geopri= v-http-location-delivery=0D=0A>=20=0D=0A> I think the problem that Barbara = points out is precisely the problem=0D=0Ain=0D=0A> deploying HELD. Claimin= g that a problem can't be solved, and=0D=0Atherefore=0D=0A> should not be m= entioned is, uh, =3Funhelpful=3F Having the "caveat"=0D=0Ainstead=0D=0A> o= f=0D=0A> a deployment recommendation understates the problem. While it is=0D= =0A> possible=0D=0A> to deploy HELD so that it almost always works, it will= take a lot of=0D=0A> attention by a lot of entities to make that happen. = For example, if=0D=0A> HELD is=0D=0A> deployed, no non-bypassable VPNs can = be permitted. The protocol=0D=0A> document=0D=0A> should be very clear abo= ut what it takes to make HELD work.=0D=0A>=20=0D=0A> I have no problem incl= uding text that covers what devices and LIS's=0D=0Aneed=0D=0A> to=0D=0A> do= , as long as it was noted that it won't always be sufficient. We=0D=0A> mi= ght=0D=0A> also include text on how enterprise networks should be configure= d.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A>=20=0D=0A> > -----Original Messag= e-----=0D=0A> > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com]=0D=0A= > > Sent: Wednesday, October 31, 2007 11:58 AM=0D=0A> > To: Richard Barnes;= Stark, Barbara; ECRIT=0D=0A> > Subject: RE: [Ecrit] Re: [Geopriv] Use of I= P address asanidentifier=0D=0A> > indraft-ietf-geopriv-http-location-delive= ry=0D=0A> >=0D=0A> > I think that the "device" requirement at most should b= e that efforts=0D=0A> > should be made to ensure that the LIS is discovered= and used on the=0D=0A> > physical access network and not via any VPN tunne= l.=0D=0A> >=0D=0A> > Perhaps more importantly, there should be a complement= ary=0D=0Arequirement=0D=0A> on=0D=0A> > the LIS that it not attempt to prov= ide location for an IP address=0D=0Athat=0D=0A> > it cannot associate a phy= sical location with. For example, a LIS in=0D=0Aan=0D=0A> > enterprise, whe= re that enterprise supports VPN access, should know=0D=0Aor=0D=0A> be=0D=0A= > > able to determine that the client requests are arriving over a VPN=0D=0A= > from=0D=0A> > an end point whose location cannot be determined. The HELD = response=0D=0A> > should indicate that location cannot be provided.=0D=0A> = >=0D=0A> > Cheers,=0D=0A> > Martin=0D=0A> >=0D=0A> > -----Original Message-= ----=0D=0A> > From: Richard Barnes [mailto:rbarnes@bbn.com]=0D=0A> > Sent: = Thursday, 1 November 2007 1:22 AM=0D=0A> > To: Stark, Barbara; ECRIT=0D=0A>= > Subject: [Ecrit] Re: [Geopriv] Use of IP address as anidentifier=0D=0A> = > indraft-ietf-geopriv-http-location-delivery=0D=0A> >=0D=0A> > Right, I th= ink what's needed is more a caveat that HELD provides the=0D=0A> > location= of the source IP address in the IP header of the request --=0D=0A> > whate= ver that may be.=0D=0A> >=0D=0A> > --Richard=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A= > > Stark, Barbara wrote:=0D=0A> > > How is a client supposed to know wheth= er a "VPN, NAT or other IP=0D=0A> > address=0D=0A> > > modification exists = between the client and the server which could=0D=0A> > > produce incorrect = location"=3F One of the best uses of HELD is the=0D=0A> case=0D=0A> > > whe= re there is a NAT (and the box with the NAT is location=0D=0Aunaware).=0D=0A= > > For=0D=0A> > > landline broadband services, this NAT exists, but doesn'= t produce=0D=0Aan=0D=0A> > > incorrect location. So this NAT is ok. How can= you distinguish=0D=0A> between=0D=0A> > a=0D=0A> > > NAT that produces an = incorrect location, vs. one that produces a=0D=0A> > correct=0D=0A> > > loc= ation=3F=0D=0A> > >=0D=0A> > > The VPN could be originated out of the route= r, and not the client.=0D=0A> How=0D=0A> > > would the client know this VPN= even exists=3F=0D=0A> > >=0D=0A> > > Unless you can tell me the logic to u= se to implement this proposed=0D=0A> > > requirement, I can't support it.=0D= =0A> > > Barbara=0D=0A> > >=0D=0A> > > -----Original Message-----=0D=0A> > = > From: Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > Sent: Wednesday, = October 31, 2007 8:51 AM=0D=0A> > > To: geopriv@ietf.org=0D=0A> > > Subject= : [Geopriv] Use of IP address as an identifier=0D=0A> > > indraft-ietf-geop= riv-http-location-delivery=0D=0A> > >=0D=0A> > > In the long set of discuss= ions that have lead to HELD, one of the=0D=0A> > > biggest=0D=0A> > > conce= rns a few of us have had is the problem than an IP address=0D=0Amay=0D=0A> = > not=0D=0A> > > be a=0D=0A> > > good identifier for determining the locati= on of the client. There=0D=0A> is=0D=0A> > a=0D=0A> > > draft that describ= es alternate identifiers. However, there is no=0D=0A> > > discussion=0D=0A= > > > in the present draft of the base protocol on these issues.=0D=0A> > >=0D= =0A> > > I would like to propose that we add text something like:=0D=0A> > = >=0D=0A> > > Use of HELD is subject to the viability of the identifier used= by=0D=0A> the=0D=0A> > > LIS to=0D=0A> > > determine location. This docum= ent describes the use of the IP=0D=0A> address=0D=0A> > > of=0D=0A> > > the= client as the identifier. When a NAT, VPN or other forms of=0D=0A> > addr= ess=0D=0A> > > modification occur between the client and the server, the lo= cation=0D=0A> > > returned=0D=0A> > > may be inaccurate. This is not alway= s the case. For example, a=0D=0ANAT=0D=0A> > > used in=0D=0A> > > a reside= ntial local area network is typically not a problem,=0D=0Abecause=0D=0A> > = the=0D=0A> > > external IP address used on the WAN side of the NAT is in fa= ct the=0D=0A> > right=0D=0A> > > identifier for all of the devices in the r= esidence. On the other=0D=0A> > hand,=0D=0A> > > if=0D=0A> > > there is a = VPN between the client and the server, for example for=0D=0Aa=0D=0A> > > te= leworker, then the address seen by the server may not be the=0D=0Aright=0D=0A= > > > address=0D=0A> > > to identify the location of the client. Where a V= PN is deployed,=0D=0A> > > clients=0D=0A> > > often have the ability to byp= ass the VPN for a transaction like=0D=0A> HELD.=0D=0A> > >=0D=0A> > > HELD = Clients MUST NOT send HELD requests where IP address is the=0D=0A> > > iden= tifier=0D=0A> > > and a VPN, NAT or other IP address modification exists be= tween the=0D=0A> > > client=0D=0A> > > and the server which could produce i= ncorrect location. HELD MUST=0D=0A> NOT=0D=0A> > be=0D=0A> > > deployed in= networks where the client cannot comply reasonably=0D=0A> > reliably=0D=0A= > > > with=0D=0A> > > that requirement.=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D= =0A> > >=0D=0A> > > _______________________________________________=0D=0A> = > > Geopriv mailing list=0D=0A> > > Geopriv@ietf.org=0D=0A> > > https://www= 1.ietf.org/mailman/listinfo/geopriv=0D=0A> > >=0D=0A> > > *****=0D=0A> > >=0D= =0A> > > The information transmitted is intended only for the person or=0D=0A= > entity=0D=0A> > to which it is addressed and may contain confidential, pr= oprietary,=0D=0A> > and/or privileged material. Any review, retransmission,=0D= =0Adissemination=0D=0A> or=0D=0A> > other use of, or taking of any action i= n reliance upon this=0D=0A> information=0D=0A> > by persons or entities oth= er than the intended recipient is=0D=0A> prohibited.=0D=0A> > If you receiv= ed this in error, please contact the sender and delete=0D=0A> the=0D=0A> > = material from all computers. GA623=0D=0A> > >=0D=0A> > >=0D=0A> > >=0D=0A> = > >=0D=0A> > > _______________________________________________=0D=0A> > > G= eopriv mailing list=0D=0A> > > Geopriv@ietf.org=0D=0A> > > https://www1.iet= f.org/mailman/listinfo/geopriv=0D=0A> > >=0D=0A> > R=0D=0A> >=0D=0A> > ____= ___________________________________________=0D=0A> > Ecrit mailing list=0D=0A= > > Ecrit@ietf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/ecrit=0D= =0A> >=0D=0A> >=0D=0A>=0D=0A-----------------------------------------------= -------------------------=0D=0A> --=0D=0A> > ----------------------=0D=0A> = > This message is for the designated recipient only and may=0D=0A> > contai= n privileged, proprietary, or otherwise private information.=0D=0A> > If yo= u have received it in error, please notify the sender=0D=0A> > immediately = and delete the original. Any unauthorized use of=0D=0A> > this email is pr= ohibited.=0D=0A> >=0D=0A>=0D=0A--------------------------------------------= ----------------------------=0D=0A> --=0D=0A> > ----------------------=0D=0A= > > [mf2]=0D=0A> >=0D=0A> >=0D=0A> > ______________________________________= _________=0D=0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > http= s://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A>=20=0D=0A> *****=0D= =0A>=20=0D=0A> The information transmitted is intended only for the person = or entity=0D=0Ato=0D=0A> which it is addressed and may contain confidential= , proprietary,=0D=0Aand/or=0D=0A> privileged material. Any review, retransm= ission, dissemination or=0D=0Aother=0D=0A> use of, or taking of any action = in reliance upon this information by=0D=0A> persons or entities other than = the intended recipient is prohibited.=0D=0AIf=0D=0A> you received this in e= rror, please contact the sender and delete the=0D=0A> material from all com= puters. GA625=0D=0A=0D=0A=0D=0A=0D=0A--------------------------------------= ----------------------------------------------------------=0D=0AThis messag= e is for the designated recipient only and may=0D=0Acontain privileged, pro= prietary, or otherwise private information. =20=0D=0AIf you have received i= t in error, please notify the sender=0D=0Aimmediately and delete the origin= al. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A----------= ---------------------------------------------------------------------------= -----------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 01 09:44:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InaL1-0004mH-Pz; Thu, 01 Nov 2007 09:43:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InaL0-0004lb-Gu for ecrit@ietf.org; Thu, 01 Nov 2007 09:43:58 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InaKu-00024w-6f for ecrit@ietf.org; Thu, 01 Nov 2007 09:43:58 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1InaKg-0002wk-4H; Thu, 01 Nov 2007 08:43:39 -0500 From: "Brian Rosen" To: "'Dawson, Martin'" , "'Stark, Barbara'" , "'Richard Barnes'" , "'ECRIT'" References: <002801c81bbc$a673fd00$1d69fe90@cis.neustar.com><7582BC68E4994F4ABF0BD4723975C3FA063767D9@crexc41p><47288F84.5010203@bbn.com> <02b501c81c5d$a644eb90$1d69fe90@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA063769EA@crexc41p> <02df01c81c70$37797240$1d69fe90@cis.neustar.com> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery Date: Thu, 1 Nov 2007 09:43:44 -0400 Message-ID: <030601c81c8d$3b637780$1d69fe90@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: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAfBuFAAAJMvoA== In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: e06437eb72f6703f11713d345be8298a 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 Right. Agree with all of this. More text to add. Brian > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Thursday, November 01, 2007 9:35 AM > To: Brian Rosen; Stark, Barbara; Richard Barnes; ECRIT > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > indraft-ietf-geopriv-http-location-delivery > > If you've got two enterprise sites connected via a branch to branch VPN > tunnel then it's quite possible to have a single LIS at the one site or > separate LIS at each site providing successful location fixes for both > sites. So it's not a case of forbidding hardware VPNs. > > I think the only hard rule - and it should be obvious anyway - is that > if a LIS can't provide the location for a presented IP address then it > should not provide a location. > > If an enterprise, for example, deploys a locked down VPN client on their > Internet-nomadic staff computers such that they cannot communicate > outside the VPN once the tunnel is established, then that enterprise has > made a decision that they do not want to let those devices access the > location service available at the local physical network - particularly > if it won't even make the HELD query prior to tunnel establishment. > > Cheers, > Martin > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, 1 November 2007 9:16 PM > To: 'Stark, Barbara'; Dawson, Martin; 'Richard Barnes'; 'ECRIT' > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > indraft-ietf-geopriv-http-location-delivery > > That's helpful. > > I don't think it's sufficient. My example, hardware VPN/tunnel > mechanisms > cannot be permitted, has to be spelled out. Also, phonebcp recommends > location update at call time. We haven't worked out this detail, but I > think we want to at least recommend that a mobile device send routing > location as a value, and dispatch location as a reference (where > needed), > just to avoid the repeated dereference by all call routing elements. > That > means you would want to do the HELD LCP operation at call time. > > You need to discuss enterprise networks behind access networks that > provide > HELD, or try to use HELD within an enterprise network. > > I think it's hard to think through ALL the instances where an IP address > isn't reliable as an identifier to be used for location, which is why I > phrased my proposed text the way I did. > > Brian > > > -----Original Message----- > > From: Stark, Barbara [mailto:bs7652@att.com] > > Sent: Thursday, November 01, 2007 5:42 AM > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > Oh, fine, I'll try to be helpful, then. > > I definitely agree with having the problem mentioned and properly > > characterized. But when we write requirements, I want to be sure that > > the requirements are implementable. > > > > Certainly, end devices must do location configuration before > > establishing a VPN. Once an end device has established a VPN, it must > > not do any LIS discovery or HELD queries over the VPN connection. > > > > The Access Network, however, needs to have the requirement that its > LIS > > be able to know which subnets of IP addresses are supplied to devices > > coming over VPN access, or have been provided to a company that > provides > > its own LIS. That is, such blocks of IP addresses need to be > > configurable in the LIS. Then there's the requirement that the LIS > must > > not provide location to these IP addresses. > > > > The access network (access provider + ISP) also has a responsibility > not > > to place a LIS on the core side of any NAT that is employed in the > > access network. Note that this isn't meant to apply to home router > NATs, > > since those aren't part of the access network, according to the > > definition of access network. > > > > I really think that the access network has greater ability, and > > therefore greater responsibility, to minimize the occurrence of > problems > > due to VPNs and NATs. > > > > As we discussed (Brian and I), I'm going to try to suggest a way to > > better include in phonebcp requirements for routers employed in "small > > areas". One of the requirements we need for these, is that they MUST > act > > as the LIS for LAN-side devices, when they have VPN connections to the > > WAN. > > Barbara > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, November 01, 2007 4:03 AM > > To: 'Dawson, Martin'; 'Richard Barnes'; Stark, Barbara; 'ECRIT' > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > I think the problem that Barbara points out is precisely the problem > in > > deploying HELD. Claiming that a problem can't be solved, and > therefore > > should not be mentioned is, uh, ?unhelpful? Having the "caveat" > instead > > of > > a deployment recommendation understates the problem. While it is > > possible > > to deploy HELD so that it almost always works, it will take a lot of > > attention by a lot of entities to make that happen. For example, if > > HELD is > > deployed, no non-bypassable VPNs can be permitted. The protocol > > document > > should be very clear about what it takes to make HELD work. > > > > I have no problem including text that covers what devices and LIS's > need > > to > > do, as long as it was noted that it won't always be sufficient. We > > might > > also include text on how enterprise networks should be configured. > > > > Brian > > > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Wednesday, October 31, 2007 11:58 AM > > > To: Richard Barnes; Stark, Barbara; ECRIT > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > I think that the "device" requirement at most should be that efforts > > > should be made to ensure that the LIS is discovered and used on the > > > physical access network and not via any VPN tunnel. > > > > > > Perhaps more importantly, there should be a complementary > requirement > > on > > > the LIS that it not attempt to provide location for an IP address > that > > > it cannot associate a physical location with. For example, a LIS in > an > > > enterprise, where that enterprise supports VPN access, should know > or > > be > > > able to determine that the client requests are arriving over a VPN > > from > > > an end point whose location cannot be determined. The HELD response > > > should indicate that location cannot be provided. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > Sent: Thursday, 1 November 2007 1:22 AM > > > To: Stark, Barbara; ECRIT > > > Subject: [Ecrit] Re: [Geopriv] Use of IP address as anidentifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > Right, I think what's needed is more a caveat that HELD provides the > > > location of the source IP address in the IP header of the request -- > > > whatever that may be. > > > > > > --Richard > > > > > > > > > > > > Stark, Barbara wrote: > > > > How is a client supposed to know whether a "VPN, NAT or other IP > > > address > > > > modification exists between the client and the server which could > > > > produce incorrect location"? One of the best uses of HELD is the > > case > > > > where there is a NAT (and the box with the NAT is location > unaware). > > > For > > > > landline broadband services, this NAT exists, but doesn't produce > an > > > > incorrect location. So this NAT is ok. How can you distinguish > > between > > > a > > > > NAT that produces an incorrect location, vs. one that produces a > > > correct > > > > location? > > > > > > > > The VPN could be originated out of the router, and not the client. > > How > > > > would the client know this VPN even exists? > > > > > > > > Unless you can tell me the logic to use to implement this proposed > > > > requirement, I can't support it. > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Wednesday, October 31, 2007 8:51 AM > > > > To: geopriv@ietf.org > > > > Subject: [Geopriv] Use of IP address as an identifier > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > In the long set of discussions that have lead to HELD, one of the > > > > biggest > > > > concerns a few of us have had is the problem than an IP address > may > > > not > > > > be a > > > > good identifier for determining the location of the client. There > > is > > > a > > > > draft that describes alternate identifiers. However, there is no > > > > discussion > > > > in the present draft of the base protocol on these issues. > > > > > > > > I would like to propose that we add text something like: > > > > > > > > Use of HELD is subject to the viability of the identifier used by > > the > > > > LIS to > > > > determine location. This document describes the use of the IP > > address > > > > of > > > > the client as the identifier. When a NAT, VPN or other forms of > > > address > > > > modification occur between the client and the server, the location > > > > returned > > > > may be inaccurate. This is not always the case. For example, a > NAT > > > > used in > > > > a residential local area network is typically not a problem, > because > > > the > > > > external IP address used on the WAN side of the NAT is in fact the > > > right > > > > identifier for all of the devices in the residence. On the other > > > hand, > > > > if > > > > there is a VPN between the client and the server, for example for > a > > > > teleworker, then the address seen by the server may not be the > right > > > > address > > > > to identify the location of the client. Where a VPN is deployed, > > > > clients > > > > often have the ability to bypass the VPN for a transaction like > > HELD. > > > > > > > > HELD Clients MUST NOT send HELD requests where IP address is the > > > > identifier > > > > and a VPN, NAT or other IP address modification exists between the > > > > client > > > > and the server which could produce incorrect location. HELD MUST > > NOT > > > be > > > > deployed in networks where the client cannot comply reasonably > > > reliably > > > > with > > > > that requirement. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > > ***** > > > > > > > > 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. GA623 > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Geopriv mailing list > > > > Geopriv@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/geopriv > > > > > > > R > > > > > > _______________________________________________ > > > 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 > > > > > > ***** > > > > 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. GA625 > > > > -------------------------------------------------------------------------- > ---------------------- > 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 Thu Nov 01 09:59:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InaZT-00039z-Ib; Thu, 01 Nov 2007 09:58:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InaZS-000395-IE for ecrit@ietf.org; Thu, 01 Nov 2007 09:58:54 -0400 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InaZR-0001e3-EU for ecrit@ietf.org; Thu, 01 Nov 2007 09:58:54 -0400 Received: from ([139.76.131.91]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.187902023; Thu, 01 Nov 2007 09:58:31 -0400 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 1 Nov 2007 09:58:31 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 1 Nov 2007 09:58:31 -0400 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 Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery Date: Thu, 1 Nov 2007 09:58:27 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA06376AAE@crexc41p> In-Reply-To: <02df01c81c70$37797240$1d69fe90@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPA= References: <002801c81bbc$a673fd00$1d69fe90@cis.neustar.com><7582BC68E4994F4ABF0BD4723975C3FA063767D9@crexc41p><47288F84.5010203@bbn.com> <02b501c81c5d$a644eb90$1d69fe90@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA063769EA@crexc41p> <02df01c81c70$37797240$1d69fe90@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Dawson, Martin" , "Richard Barnes" , "ECRIT" X-OriginalArrivalTime: 01 Nov 2007 13:58:31.0095 (UTC) FILETIME=[4903DC70:01C81C8F] X-Spam-Score: 0.2 (/) X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91 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 your proposed verbiage characterizing the problem.=20 I think that requirements on end devices using HELD and access networks providing HELD responses is a phonebcp issue, and not http-location-delivery.=20 Within phonebcp, I think that enterprise networks (that are not able to control the capabilities of devices attaching to them) are already included in the definition of access network. That seems to currently be implicit, but perhaps it should be explicit. Then all requirements that apply to access networks will explicitly apply to such enterprise networks. I'm not sure I see what such enterprise networks need to do different than public access networks. You already have some VPN and NAT requirements there: AN-14 Network administrators MUST take care in assigning IP addresses such that VPN address assignments can be distinguished from local devices (by subnet choice, for example), and LISs should not attempt to provide location to addresses that arrive via VPN connections. AN-15 Placement of NAT devices should consider the effect of the NAT on the LCP. The device location update when the device has a VPN established that doesn't allow split tunneling is definitely a gap. I think it could be solved with some HELD extensions (which is a geopriv issue). That is, I think that if we allow the initial (pre-VPN) request to also negotiate identification and authentication for future updates, that we could solve the update problem. The intermediary SOHO (small office/home office) router that sets up the non-split tunneling VPN on behalf of its LAN needs to be required (in phonebcp) to act as the LIS for all devices in its LAN. That's part of the additional requirements I'm working on providing you (Brian). Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, November 01, 2007 6:16 AM To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery That's helpful. I don't think it's sufficient. My example, hardware VPN/tunnel mechanisms cannot be permitted, has to be spelled out. Also, phonebcp recommends location update at call time. We haven't worked out this detail, but I think we want to at least recommend that a mobile device send routing location as a value, and dispatch location as a reference (where needed), just to avoid the repeated dereference by all call routing elements. That means you would want to do the HELD LCP operation at call time. You need to discuss enterprise networks behind access networks that provide HELD, or try to use HELD within an enterprise network. I think it's hard to think through ALL the instances where an IP address isn't reliable as an identifier to be used for location, which is why I phrased my proposed text the way I did. Brian=20 > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Thursday, November 01, 2007 5:42 AM > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > indraft-ietf-geopriv-http-location-delivery >=20 > Oh, fine, I'll try to be helpful, then. > I definitely agree with having the problem mentioned and properly > characterized. But when we write requirements, I want to be sure that > the requirements are implementable. >=20 > Certainly, end devices must do location configuration before > establishing a VPN. Once an end device has established a VPN, it must > not do any LIS discovery or HELD queries over the VPN connection. >=20 > The Access Network, however, needs to have the requirement that its LIS > be able to know which subnets of IP addresses are supplied to devices > coming over VPN access, or have been provided to a company that provides > its own LIS. That is, such blocks of IP addresses need to be > configurable in the LIS. Then there's the requirement that the LIS must > not provide location to these IP addresses. >=20 > The access network (access provider + ISP) also has a responsibility not > to place a LIS on the core side of any NAT that is employed in the > access network. Note that this isn't meant to apply to home router NATs, > since those aren't part of the access network, according to the > definition of access network. >=20 > I really think that the access network has greater ability, and > therefore greater responsibility, to minimize the occurrence of problems > due to VPNs and NATs. >=20 > As we discussed (Brian and I), I'm going to try to suggest a way to > better include in phonebcp requirements for routers employed in "small > areas". One of the requirements we need for these, is that they MUST act > as the LIS for LAN-side devices, when they have VPN connections to the > WAN. > Barbara >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, November 01, 2007 4:03 AM > To: 'Dawson, Martin'; 'Richard Barnes'; Stark, Barbara; 'ECRIT' > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > indraft-ietf-geopriv-http-location-delivery >=20 > I think the problem that Barbara points out is precisely the problem in > deploying HELD. Claiming that a problem can't be solved, and therefore > should not be mentioned is, uh, ?unhelpful? Having the "caveat" instead > of > a deployment recommendation understates the problem. While it is > possible > to deploy HELD so that it almost always works, it will take a lot of > attention by a lot of entities to make that happen. For example, if > HELD is > deployed, no non-bypassable VPNs can be permitted. The protocol > document > should be very clear about what it takes to make HELD work. >=20 > I have no problem including text that covers what devices and LIS's need > to > do, as long as it was noted that it won't always be sufficient. We > might > also include text on how enterprise networks should be configured. >=20 > Brian >=20 >=20 > > -----Original Message----- > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > Sent: Wednesday, October 31, 2007 11:58 AM > > To: Richard Barnes; Stark, Barbara; ECRIT > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > I think that the "device" requirement at most should be that efforts > > should be made to ensure that the LIS is discovered and used on the > > physical access network and not via any VPN tunnel. > > > > Perhaps more importantly, there should be a complementary requirement > on > > the LIS that it not attempt to provide location for an IP address that > > it cannot associate a physical location with. For example, a LIS in an > > enterprise, where that enterprise supports VPN access, should know or > be > > able to determine that the client requests are arriving over a VPN > from > > an end point whose location cannot be determined. The HELD response > > should indicate that location cannot be provided. > > > > Cheers, > > Martin > > > > -----Original Message----- > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > Sent: Thursday, 1 November 2007 1:22 AM > > To: Stark, Barbara; ECRIT > > Subject: [Ecrit] Re: [Geopriv] Use of IP address as anidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > Right, I think what's needed is more a caveat that HELD provides the > > location of the source IP address in the IP header of the request -- > > whatever that may be. > > > > --Richard > > > > > > > > Stark, Barbara wrote: > > > How is a client supposed to know whether a "VPN, NAT or other IP > > address > > > modification exists between the client and the server which could > > > produce incorrect location"? One of the best uses of HELD is the > case > > > where there is a NAT (and the box with the NAT is location unaware). > > For > > > landline broadband services, this NAT exists, but doesn't produce an > > > incorrect location. So this NAT is ok. How can you distinguish > between > > a > > > NAT that produces an incorrect location, vs. one that produces a > > correct > > > location? > > > > > > The VPN could be originated out of the router, and not the client. > How > > > would the client know this VPN even exists? > > > > > > Unless you can tell me the logic to use to implement this proposed > > > requirement, I can't support it. > > > Barbara > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Wednesday, October 31, 2007 8:51 AM > > > To: geopriv@ietf.org > > > Subject: [Geopriv] Use of IP address as an identifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > In the long set of discussions that have lead to HELD, one of the > > > biggest > > > concerns a few of us have had is the problem than an IP address may > > not > > > be a > > > good identifier for determining the location of the client. There > is > > a > > > draft that describes alternate identifiers. However, there is no > > > discussion > > > in the present draft of the base protocol on these issues. > > > > > > I would like to propose that we add text something like: > > > > > > Use of HELD is subject to the viability of the identifier used by > the > > > LIS to > > > determine location. This document describes the use of the IP > address > > > of > > > the client as the identifier. When a NAT, VPN or other forms of > > address > > > modification occur between the client and the server, the location > > > returned > > > may be inaccurate. This is not always the case. For example, a NAT > > > used in > > > a residential local area network is typically not a problem, because > > the > > > external IP address used on the WAN side of the NAT is in fact the > > right > > > identifier for all of the devices in the residence. On the other > > hand, > > > if > > > there is a VPN between the client and the server, for example for a > > > teleworker, then the address seen by the server may not be the right > > > address > > > to identify the location of the client. Where a VPN is deployed, > > > clients > > > often have the ability to bypass the VPN for a transaction like > HELD. > > > > > > HELD Clients MUST NOT send HELD requests where IP address is the > > > identifier > > > and a VPN, NAT or other IP address modification exists between the > > > client > > > and the server which could produce incorrect location. HELD MUST > NOT > > be > > > deployed in networks where the client cannot comply reasonably > > reliably > > > with > > > that requirement. > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 01 10:07:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inagv-00024p-M3; Thu, 01 Nov 2007 10:06:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inagu-0001wj-TR for ecrit@ietf.org; Thu, 01 Nov 2007 10:06:36 -0400 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Inagk-0001oS-6d for ecrit@ietf.org; Thu, 01 Nov 2007 10:06:26 -0400 Received: (qmail invoked by alias); 01 Nov 2007 14:06:24 -0000 Received: from dhcp-guest-bru-peg1-144-254-105-13.cisco.com (EHLO [144.254.105.13]) [144.254.105.13] by mail.gmx.net (mp002) with SMTP; 01 Nov 2007 15:06:24 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18QzmdovywQziHkPEVfmxP9M2PhghJYz4Aok/t5vh BTNL5cHQ/NA2ZS Message-ID: <4729DD5F.1000405@gmx.net> Date: Thu, 01 Nov 2007 15:06:23 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Richard Barnes Subject: Re: [Ecrit] media security & phone bcp References: <47267236.30105@gmx.net> <4726C9A6.4050304@bbn.com> In-Reply-To: <4726C9A6.4050304@bbn.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: bb8f917bb6b8da28fc948aeffb74aa17 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 Richard, I suggest to use SDES since it is currently the only thing that is available today (from a deployment point of view). I just wanted to be pragmatic. Ciao Hannes Richard Barnes wrote: > Hannes, > > That's a good catch. There should be a discussion of media security > in phonebcp. Could you clarify why you think SDES is the mechanism of > choice? > > --Richard > > > > Hannes Tschofenig wrote: >> I noticed that phone bcp talks about signaling security but it does >> not speak about media security. >> I believe SRTP is possible for emergency calls. For key management I >> would mandate Security Descriptions [RFC4568] >> >> Sounds reasonable? >> >> _______________________________________________ >> 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 Nov 01 10:09:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inajn-0004Lj-Kf; Thu, 01 Nov 2007 10:09:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inajn-0004KH-1x for ecrit@ietf.org; Thu, 01 Nov 2007 10:09:35 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Inajl-0001s0-QP for ecrit@ietf.org; Thu, 01 Nov 2007 10:09:34 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Inajc-0002J6-Nl; Thu, 01 Nov 2007 09:09:25 -0500 From: "Brian Rosen" To: "'Stark, Barbara'" , "'Dawson, Martin'" , "'Richard Barnes'" , "'ECRIT'" References: <002801c81bbc$a673fd00$1d69fe90@cis.neustar.com><7582BC68E4994F4ABF0BD4723975C3FA063767D9@crexc41p><47288F84.5010203@bbn.com> <02b501c81c5d$a644eb90$1d69fe90@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA063769EA@crexc41p> <02df01c81c70$37797240$1d69fe90@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA06376AAE@crexc41p> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery Date: Thu, 1 Nov 2007 10:09:33 -0400 Message-ID: <031201c81c90$d66f8400$1d69fe90@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: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEA== In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA06376AAE@crexc41p> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: c0aa019322dfce838bd8604f5a841b57 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 The text belongs in the HELD document because it has nothing to do with emergency calls. It affects all uses of HELD. I don't have a problem with expanding text in -phonebcp Brian > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Thursday, November 01, 2007 9:58 AM > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > indraft-ietf-geopriv-http-location-delivery > > I have no problem with your proposed verbiage characterizing the > problem. > > I think that requirements on end devices using HELD and access networks > providing HELD responses is a phonebcp issue, and not > http-location-delivery. > > Within phonebcp, I think that enterprise networks (that are not able to > control the capabilities of devices attaching to them) are already > included in the definition of access network. That seems to currently be > implicit, but perhaps it should be explicit. Then all requirements that > apply to access networks will explicitly apply to such enterprise > networks. I'm not sure I see what such enterprise networks need to do > different than public access networks. You already have some VPN and NAT > requirements there: > AN-14 Network administrators MUST take care in assigning IP addresses > such that VPN address assignments can be distinguished from local > devices (by subnet choice, for example), and LISs should not attempt > to provide location to addresses that arrive via VPN connections. > > AN-15 Placement of NAT devices should consider the effect of the NAT > on the LCP. > > The device location update when the device has a VPN established that > doesn't allow split tunneling is definitely a gap. I think it could be > solved with some HELD extensions (which is a geopriv issue). That is, I > think that if we allow the initial (pre-VPN) request to also negotiate > identification and authentication for future updates, that we could > solve the update problem. > > The intermediary SOHO (small office/home office) router that sets up the > non-split tunneling VPN on behalf of its LAN needs to be required (in > phonebcp) to act as the LIS for all devices in its LAN. That's part of > the additional requirements I'm working on providing you (Brian). > Barbara > > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, November 01, 2007 6:16 AM > To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > indraft-ietf-geopriv-http-location-delivery > > That's helpful. > > I don't think it's sufficient. My example, hardware VPN/tunnel > mechanisms > cannot be permitted, has to be spelled out. Also, phonebcp recommends > location update at call time. We haven't worked out this detail, but I > think we want to at least recommend that a mobile device send routing > location as a value, and dispatch location as a reference (where > needed), > just to avoid the repeated dereference by all call routing elements. > That > means you would want to do the HELD LCP operation at call time. > > You need to discuss enterprise networks behind access networks that > provide > HELD, or try to use HELD within an enterprise network. > > I think it's hard to think through ALL the instances where an IP address > isn't reliable as an identifier to be used for location, which is why I > phrased my proposed text the way I did. > > Brian > > > -----Original Message----- > > From: Stark, Barbara [mailto:bs7652@att.com] > > Sent: Thursday, November 01, 2007 5:42 AM > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > Oh, fine, I'll try to be helpful, then. > > I definitely agree with having the problem mentioned and properly > > characterized. But when we write requirements, I want to be sure that > > the requirements are implementable. > > > > Certainly, end devices must do location configuration before > > establishing a VPN. Once an end device has established a VPN, it must > > not do any LIS discovery or HELD queries over the VPN connection. > > > > The Access Network, however, needs to have the requirement that its > LIS > > be able to know which subnets of IP addresses are supplied to devices > > coming over VPN access, or have been provided to a company that > provides > > its own LIS. That is, such blocks of IP addresses need to be > > configurable in the LIS. Then there's the requirement that the LIS > must > > not provide location to these IP addresses. > > > > The access network (access provider + ISP) also has a responsibility > not > > to place a LIS on the core side of any NAT that is employed in the > > access network. Note that this isn't meant to apply to home router > NATs, > > since those aren't part of the access network, according to the > > definition of access network. > > > > I really think that the access network has greater ability, and > > therefore greater responsibility, to minimize the occurrence of > problems > > due to VPNs and NATs. > > > > As we discussed (Brian and I), I'm going to try to suggest a way to > > better include in phonebcp requirements for routers employed in "small > > areas". One of the requirements we need for these, is that they MUST > act > > as the LIS for LAN-side devices, when they have VPN connections to the > > WAN. > > Barbara > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, November 01, 2007 4:03 AM > > To: 'Dawson, Martin'; 'Richard Barnes'; Stark, Barbara; 'ECRIT' > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > I think the problem that Barbara points out is precisely the problem > in > > deploying HELD. Claiming that a problem can't be solved, and > therefore > > should not be mentioned is, uh, ?unhelpful? Having the "caveat" > instead > > of > > a deployment recommendation understates the problem. While it is > > possible > > to deploy HELD so that it almost always works, it will take a lot of > > attention by a lot of entities to make that happen. For example, if > > HELD is > > deployed, no non-bypassable VPNs can be permitted. The protocol > > document > > should be very clear about what it takes to make HELD work. > > > > I have no problem including text that covers what devices and LIS's > need > > to > > do, as long as it was noted that it won't always be sufficient. We > > might > > also include text on how enterprise networks should be configured. > > > > Brian > > > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Wednesday, October 31, 2007 11:58 AM > > > To: Richard Barnes; Stark, Barbara; ECRIT > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > I think that the "device" requirement at most should be that efforts > > > should be made to ensure that the LIS is discovered and used on the > > > physical access network and not via any VPN tunnel. > > > > > > Perhaps more importantly, there should be a complementary > requirement > > on > > > the LIS that it not attempt to provide location for an IP address > that > > > it cannot associate a physical location with. For example, a LIS in > an > > > enterprise, where that enterprise supports VPN access, should know > or > > be > > > able to determine that the client requests are arriving over a VPN > > from > > > an end point whose location cannot be determined. The HELD response > > > should indicate that location cannot be provided. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > Sent: Thursday, 1 November 2007 1:22 AM > > > To: Stark, Barbara; ECRIT > > > Subject: [Ecrit] Re: [Geopriv] Use of IP address as anidentifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > Right, I think what's needed is more a caveat that HELD provides the > > > location of the source IP address in the IP header of the request -- > > > whatever that may be. > > > > > > --Richard > > > > > > > > > > > > Stark, Barbara wrote: > > > > How is a client supposed to know whether a "VPN, NAT or other IP > > > address > > > > modification exists between the client and the server which could > > > > produce incorrect location"? One of the best uses of HELD is the > > case > > > > where there is a NAT (and the box with the NAT is location > unaware). > > > For > > > > landline broadband services, this NAT exists, but doesn't produce > an > > > > incorrect location. So this NAT is ok. How can you distinguish > > between > > > a > > > > NAT that produces an incorrect location, vs. one that produces a > > > correct > > > > location? > > > > > > > > The VPN could be originated out of the router, and not the client. > > How > > > > would the client know this VPN even exists? > > > > > > > > Unless you can tell me the logic to use to implement this proposed > > > > requirement, I can't support it. > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Wednesday, October 31, 2007 8:51 AM > > > > To: geopriv@ietf.org > > > > Subject: [Geopriv] Use of IP address as an identifier > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > In the long set of discussions that have lead to HELD, one of the > > > > biggest > > > > concerns a few of us have had is the problem than an IP address > may > > > not > > > > be a > > > > good identifier for determining the location of the client. There > > is > > > a > > > > draft that describes alternate identifiers. However, there is no > > > > discussion > > > > in the present draft of the base protocol on these issues. > > > > > > > > I would like to propose that we add text something like: > > > > > > > > Use of HELD is subject to the viability of the identifier used by > > the > > > > LIS to > > > > determine location. This document describes the use of the IP > > address > > > > of > > > > the client as the identifier. When a NAT, VPN or other forms of > > > address > > > > modification occur between the client and the server, the location > > > > returned > > > > may be inaccurate. This is not always the case. For example, a > NAT > > > > used in > > > > a residential local area network is typically not a problem, > because > > > the > > > > external IP address used on the WAN side of the NAT is in fact the > > > right > > > > identifier for all of the devices in the residence. On the other > > > hand, > > > > if > > > > there is a VPN between the client and the server, for example for > a > > > > teleworker, then the address seen by the server may not be the > right > > > > address > > > > to identify the location of the client. Where a VPN is deployed, > > > > clients > > > > often have the ability to bypass the VPN for a transaction like > > HELD. > > > > > > > > HELD Clients MUST NOT send HELD requests where IP address is the > > > > identifier > > > > and a VPN, NAT or other IP address modification exists between the > > > > client > > > > and the server which could produce incorrect location. HELD MUST > > NOT > > > be > > > > deployed in networks where the client cannot comply reasonably > > > reliably > > > > with > > > > that requirement. > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 01 10:39:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InbCe-0000so-IX; Thu, 01 Nov 2007 10:39:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InbCd-0000qS-2A for ecrit@ietf.org; Thu, 01 Nov 2007 10:39:23 -0400 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1InbCW-0003tQ-OI for ecrit@ietf.org; Thu, 01 Nov 2007 10:39:23 -0400 Received: from ([139.76.131.91]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.32821814; Thu, 01 Nov 2007 10:38:43 -0400 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 1 Nov 2007 10:38:43 -0400 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Thu, 1 Nov 2007 10:38:42 -0400 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 Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery Date: Thu, 1 Nov 2007 10:38:39 -0400 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA06376AD7@crexc41p> In-Reply-To: <031201c81c90$d66f8400$1d69fe90@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBw References: <7582BC68E4994F4ABF0BD4723975C3FA06376AAE@crexc41p> <031201c81c90$d66f8400$1d69fe90@cis.neustar.com> From: "Stark, Barbara" To: "Brian Rosen" , "Dawson, Martin" , "Richard Barnes" , "ECRIT" X-OriginalArrivalTime: 01 Nov 2007 14:38:42.0872 (UTC) FILETIME=[E68BD380:01C81C94] X-Spam-Score: 0.2 (/) X-Scan-Signature: db284e046c8702920c1c6125bc4d0b7a 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 HELD is a protocol, purely and simply. It's not a BCP and cannot and should not attempt to use MUST and SHOULD language around behavior of devices and networks that use the protocol, outside of requirements directly related to formatting of the protocol messages. Http-location-delivery MUST NOT contain normative language that attempts to restrict the environment where HELD may be used. I have no problem with including a discussion of these issues in http-location-delivery. But if you want something stronger, it needs to be a BCP. Since phonebcp only applies to use for emergency services, then I guess you'd need a more generic BCP out of geopriv. Since such a HELD BCP (from geopriv) may or may not be recognized by device manufacturers, I'd recommend making sure that phonebcp does have what's needed, as far as use of HELD for emergency services. Barbara -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net]=20 Sent: Thursday, November 01, 2007 10:10 AM To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery The text belongs in the HELD document because it has nothing to do with emergency calls. It affects all uses of HELD. I don't have a problem with expanding text in -phonebcp Brian > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Thursday, November 01, 2007 9:58 AM > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > indraft-ietf-geopriv-http-location-delivery >=20 > I have no problem with your proposed verbiage characterizing the > problem. >=20 > I think that requirements on end devices using HELD and access networks > providing HELD responses is a phonebcp issue, and not > http-location-delivery. >=20 > Within phonebcp, I think that enterprise networks (that are not able to > control the capabilities of devices attaching to them) are already > included in the definition of access network. That seems to currently be > implicit, but perhaps it should be explicit. Then all requirements that > apply to access networks will explicitly apply to such enterprise > networks. I'm not sure I see what such enterprise networks need to do > different than public access networks. You already have some VPN and NAT > requirements there: > AN-14 Network administrators MUST take care in assigning IP addresses > such that VPN address assignments can be distinguished from local > devices (by subnet choice, for example), and LISs should not attempt > to provide location to addresses that arrive via VPN connections. >=20 > AN-15 Placement of NAT devices should consider the effect of the NAT > on the LCP. >=20 > The device location update when the device has a VPN established that > doesn't allow split tunneling is definitely a gap. I think it could be > solved with some HELD extensions (which is a geopriv issue). That is, I > think that if we allow the initial (pre-VPN) request to also negotiate > identification and authentication for future updates, that we could > solve the update problem. >=20 > The intermediary SOHO (small office/home office) router that sets up the > non-split tunneling VPN on behalf of its LAN needs to be required (in > phonebcp) to act as the LIS for all devices in its LAN. That's part of > the additional requirements I'm working on providing you (Brian). > Barbara >=20 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, November 01, 2007 6:16 AM > To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > indraft-ietf-geopriv-http-location-delivery >=20 > That's helpful. >=20 > I don't think it's sufficient. My example, hardware VPN/tunnel > mechanisms > cannot be permitted, has to be spelled out. Also, phonebcp recommends > location update at call time. We haven't worked out this detail, but I > think we want to at least recommend that a mobile device send routing > location as a value, and dispatch location as a reference (where > needed), > just to avoid the repeated dereference by all call routing elements. > That > means you would want to do the HELD LCP operation at call time. >=20 > You need to discuss enterprise networks behind access networks that > provide > HELD, or try to use HELD within an enterprise network. >=20 > I think it's hard to think through ALL the instances where an IP address > isn't reliable as an identifier to be used for location, which is why I > phrased my proposed text the way I did. >=20 > Brian >=20 > > -----Original Message----- > > From: Stark, Barbara [mailto:bs7652@att.com] > > Sent: Thursday, November 01, 2007 5:42 AM > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > Oh, fine, I'll try to be helpful, then. > > I definitely agree with having the problem mentioned and properly > > characterized. But when we write requirements, I want to be sure that > > the requirements are implementable. > > > > Certainly, end devices must do location configuration before > > establishing a VPN. Once an end device has established a VPN, it must > > not do any LIS discovery or HELD queries over the VPN connection. > > > > The Access Network, however, needs to have the requirement that its > LIS > > be able to know which subnets of IP addresses are supplied to devices > > coming over VPN access, or have been provided to a company that > provides > > its own LIS. That is, such blocks of IP addresses need to be > > configurable in the LIS. Then there's the requirement that the LIS > must > > not provide location to these IP addresses. > > > > The access network (access provider + ISP) also has a responsibility > not > > to place a LIS on the core side of any NAT that is employed in the > > access network. Note that this isn't meant to apply to home router > NATs, > > since those aren't part of the access network, according to the > > definition of access network. > > > > I really think that the access network has greater ability, and > > therefore greater responsibility, to minimize the occurrence of > problems > > due to VPNs and NATs. > > > > As we discussed (Brian and I), I'm going to try to suggest a way to > > better include in phonebcp requirements for routers employed in "small > > areas". One of the requirements we need for these, is that they MUST > act > > as the LIS for LAN-side devices, when they have VPN connections to the > > WAN. > > Barbara > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, November 01, 2007 4:03 AM > > To: 'Dawson, Martin'; 'Richard Barnes'; Stark, Barbara; 'ECRIT' > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > I think the problem that Barbara points out is precisely the problem > in > > deploying HELD. Claiming that a problem can't be solved, and > therefore > > should not be mentioned is, uh, ?unhelpful? Having the "caveat" > instead > > of > > a deployment recommendation understates the problem. While it is > > possible > > to deploy HELD so that it almost always works, it will take a lot of > > attention by a lot of entities to make that happen. For example, if > > HELD is > > deployed, no non-bypassable VPNs can be permitted. The protocol > > document > > should be very clear about what it takes to make HELD work. > > > > I have no problem including text that covers what devices and LIS's > need > > to > > do, as long as it was noted that it won't always be sufficient. We > > might > > also include text on how enterprise networks should be configured. > > > > Brian > > > > > > > -----Original Message----- > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > Sent: Wednesday, October 31, 2007 11:58 AM > > > To: Richard Barnes; Stark, Barbara; ECRIT > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > I think that the "device" requirement at most should be that efforts > > > should be made to ensure that the LIS is discovered and used on the > > > physical access network and not via any VPN tunnel. > > > > > > Perhaps more importantly, there should be a complementary > requirement > > on > > > the LIS that it not attempt to provide location for an IP address > that > > > it cannot associate a physical location with. For example, a LIS in > an > > > enterprise, where that enterprise supports VPN access, should know > or > > be > > > able to determine that the client requests are arriving over a VPN > > from > > > an end point whose location cannot be determined. The HELD response > > > should indicate that location cannot be provided. > > > > > > Cheers, > > > Martin > > > > > > -----Original Message----- > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > Sent: Thursday, 1 November 2007 1:22 AM > > > To: Stark, Barbara; ECRIT > > > Subject: [Ecrit] Re: [Geopriv] Use of IP address as anidentifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > Right, I think what's needed is more a caveat that HELD provides the > > > location of the source IP address in the IP header of the request -- > > > whatever that may be. > > > > > > --Richard > > > > > > > > > > > > Stark, Barbara wrote: > > > > How is a client supposed to know whether a "VPN, NAT or other IP > > > address > > > > modification exists between the client and the server which could > > > > produce incorrect location"? One of the best uses of HELD is the > > case > > > > where there is a NAT (and the box with the NAT is location > unaware). > > > For > > > > landline broadband services, this NAT exists, but doesn't produce > an > > > > incorrect location. So this NAT is ok. How can you distinguish > > between > > > a > > > > NAT that produces an incorrect location, vs. one that produces a > > > correct > > > > location? > > > > > > > > The VPN could be originated out of the router, and not the client. > > How > > > > would the client know this VPN even exists? > > > > > > > > Unless you can tell me the logic to use to implement this proposed > > > > requirement, I can't support it. > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Wednesday, October 31, 2007 8:51 AM > > > > To: geopriv@ietf.org > > > > Subject: [Geopriv] Use of IP address as an identifier > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > In the long set of discussions that have lead to HELD, one of the > > > > biggest > > > > concerns a few of us have had is the problem than an IP address > may > > > not > > > > be a > > > > good identifier for determining the location of the client. There > > is > > > a > > > > draft that describes alternate identifiers. However, there is no > > > > discussion > > > > in the present draft of the base protocol on these issues. > > > > > > > > I would like to propose that we add text something like: > > > > > > > > Use of HELD is subject to the viability of the identifier used by > > the > > > > LIS to > > > > determine location. This document describes the use of the IP > > address > > > > of > > > > the client as the identifier. When a NAT, VPN or other forms of > > > address > > > > modification occur between the client and the server, the location > > > > returned > > > > may be inaccurate. This is not always the case. For example, a > NAT > > > > used in > > > > a residential local area network is typically not a problem, > because > > > the > > > > external IP address used on the WAN side of the NAT is in fact the > > > right > > > > identifier for all of the devices in the residence. On the other > > > hand, > > > > if > > > > there is a VPN between the client and the server, for example for > a > > > > teleworker, then the address seen by the server may not be the > right > > > > address > > > > to identify the location of the client. Where a VPN is deployed, > > > > clients > > > > often have the ability to bypass the VPN for a transaction like > > HELD. > > > > > > > > HELD Clients MUST NOT send HELD requests where IP address is the > > > > identifier > > > > and a VPN, NAT or other IP address modification exists between the > > > > client > > > > and the server which could produce incorrect location. HELD MUST > > NOT > > > be > > > > deployed in networks where the client cannot comply reasonably > > > reliably > > > > with > > > > that requirement. > > > > _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 01 10:55:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InbRW-0001h2-Ob; Thu, 01 Nov 2007 10:54:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InbRV-0001eX-R8 for ecrit@ietf.org; Thu, 01 Nov 2007 10:54:45 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InbRV-0002tz-Aj for ecrit@ietf.org; Thu, 01 Nov 2007 10:54:45 -0400 Received: from dommiel.bbn.com ([192.1.122.15] helo=localhost.localdomain) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1InbRS-00010H-4t; Thu, 01 Nov 2007 10:54:42 -0400 Message-ID: <4729E8AD.9000704@bbn.com> Date: Thu, 01 Nov 2007 10:54:37 -0400 From: Richard Barnes User-Agent: Thunderbird 2.0.0.5 (X11/20070727) MIME-Version: 1.0 To: "Stark, Barbara" Subject: Re: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery References: <7582BC68E4994F4ABF0BD4723975C3FA06376AAE@crexc41p> <031201c81c90$d66f8400$1d69fe90@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA06376AD7@crexc41p> In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA06376AD7@crexc41p> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: "Dawson, Martin" , 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 As far as which document this belongs in, I mostly don't care. However, it shouldn't be in phonebcp because it's not emergency-specific. My analysis of the situation is below, if it's helpful. --Richard There are two things that cause problems for HELD (using IP source address as an identifier for the endpoint): 1. The IP address that HELD uses is the IP source address 2. There are several logical steps between IP address and location -- e.g. IP --> MAC --> WLAN AP --> Loc -- e.g. IP --> MAC --> port --> Loc So a HELD LIS can position an endpoint if: 1. The LIS has sufficient knowledge of the network to which the endpoint is physically attached to derive its location (given the proper IP address) 2. The IP source address in the HELD request is the one that will direct the LIS to return the endpoint's location In most cases, (2) means that the source address is the one the network assigned, or that the source address was not changed while the packet was in transit. Martin's pair of enterprise networks "glued together" with a VPN meets these criteria (with all three versions of 2). The LIS is an enterprise asset, so it can be provisioned with knowledge of both networks. And even if a packet traverses the VPN, it's just tunneled whole, and the source address is never changed. In the "road warrior" VPN case: 1. In a query from the endpoint to an enterprise LIS: Criterion (2) is true -- IP source addresses are carried faithfully from source to LIS. But criterion (1) is false, because the LIS does not have sufficient information about the host's attachment to locate it. 2. In a query from the endpoint to an access network LIS through the tunnel: Criterion (1) is true, but criterion (2) is false. The LIS has sufficient information, but the source address is in the enterprise network, not the right one. 3. In a query from the endpoint to an access network LIS outside the tunnel: This works because (1) the LIS knows about the network the endpoint is physically attached to, and (2) the LIS gets the IP address that it assigned. If the endpoint and the LIS are on opposite sides of a NAT, (1) is almost always false, and (2) as well. (1) is only true if the LIS is aware of the network topology behind the NAT (even if not the addressing), and (2) is only true if the LIS is aware of the address mapping in the LIS. Note that (2) cannot be true if there's multiple hosts with different locations are fronted by a NAT with a single public address (since HELD doesn't account for port numbers). In a particular deployment scenario, the problem is to determine under what observable conditions these criteria are true, and constrain the LIS to answering queries only when they are likely to be true. With respect to (2): It seems like you could have some assurance using the HELD identity extension for the endpoint to include it's own IP address in the HELD request. The LIS could then detect changes in the source IP addresses by comparing the two. With respect to (1): This is much more difficult to deal with, since you can extend the network without the LIS being aware, like by adding a VPN out to a remote point. Getting any assurance on this point requires strong constraints on the structure of the network. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 01 10:59:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InbVb-0006sd-Sk; Thu, 01 Nov 2007 10:58:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InbVb-0006rg-37 for ecrit@ietf.org; Thu, 01 Nov 2007 10:58:59 -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 1InbVZ-00038P-F4 for ecrit@ietf.org; Thu, 01 Nov 2007 10:58:59 -0400 X-IronPort-AV: E=Sophos;i="4.21,358,1188802800"; d="scan'208";a="542171927" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 01 Nov 2007 07:58:53 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lA1EwomH000597; Thu, 1 Nov 2007 07:58:50 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id lA1Ewf8S000942; Thu, 1 Nov 2007 14:58:41 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 10:58:40 -0400 Received: from mlinsnerwxp02 ([144.254.2.93]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 10:58:39 -0400 From: "Marc Linsner" To: "'Brian Rosen'" , "'Stark, Barbara'" , "'ECRIT'" Subject: RE: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier indraft-ietf-geopriv-http-location-delivery Date: Thu, 1 Nov 2007 10:58:38 -0400 Message-ID: <002001c81c97$afe6ff50$5d02fe90@cisco.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.3138 Thread-index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAABsKtg In-Reply-To: <031201c81c90$d66f8400$1d69fe90@cis.neustar.com> X-OriginalArrivalTime: 01 Nov 2007 14:58:39.0889 (UTC) FILETIME=[B0062010:01C81C97] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15518.002 X-TM-AS-Result: No--18.598000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13532; t=1193929130; x=1194793130; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Re=3A=20[Geopriv]=20Use=20of=20IP=20address asanidentifier=09indraft-ietf-geopriv-http-location-delivery |Sender:=20; bh=b0i7StD7KxsOS2Nv/bELsFZ4SBHZf9OBTCyutPJzTZM=; b=aXCwQhXLCS20j4YGe1v5lvrae/R0pTe/GsQJVJj71GHDcm/b+XmUtpmcAHpLmGNEsp0ED/Da Mm10Nq2KgRkXKvnHJrkgOTUAQWf9RF4epAGrwTGHF9NTgui4duXefxwG; Authentication-Results: sj-dkim-3; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 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 addition to Brian's comment, the whole discussion assumes IP address as the identifier a LIS utilizes for location lookup. I simply ask that the use case is clarified when text is added. -Marc- > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, November 01, 2007 10:10 AM > To: 'Stark, Barbara'; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP > addressasanidentifier indraft-ietf-geopriv-http-location-delivery > > The text belongs in the HELD document because it has nothing > to do with emergency calls. It affects all uses of HELD. > > I don't have a problem with expanding text in -phonebcp > > Brian > > > -----Original Message----- > > From: Stark, Barbara [mailto:bs7652@att.com] > > Sent: Thursday, November 01, 2007 9:58 AM > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > I have no problem with your proposed verbiage characterizing the > > problem. > > > > I think that requirements on end devices using HELD and access > > networks providing HELD responses is a phonebcp issue, and not > > http-location-delivery. > > > > Within phonebcp, I think that enterprise networks (that are > not able > > to control the capabilities of devices attaching to them) > are already > > included in the definition of access network. That seems to > currently > > be implicit, but perhaps it should be explicit. Then all > requirements > > that apply to access networks will explicitly apply to such > enterprise > > networks. I'm not sure I see what such enterprise networks > need to do > > different than public access networks. You already have > some VPN and > > NAT requirements there: > > AN-14 Network administrators MUST take care in assigning > IP addresses > > such that VPN address assignments can be distinguished from local > > devices (by subnet choice, for example), and LISs should > not attempt > > to provide location to addresses that arrive via VPN connections. > > > > AN-15 Placement of NAT devices should consider the > effect of the NAT > > on the LCP. > > > > The device location update when the device has a VPN > established that > > doesn't allow split tunneling is definitely a gap. I think > it could be > > solved with some HELD extensions (which is a geopriv > issue). That is, > > I think that if we allow the initial (pre-VPN) request to also > > negotiate identification and authentication for future > updates, that > > we could solve the update problem. > > > > The intermediary SOHO (small office/home office) router > that sets up > > the non-split tunneling VPN on behalf of its LAN needs to > be required > > (in > > phonebcp) to act as the LIS for all devices in its LAN. > That's part of > > the additional requirements I'm working on providing you (Brian). > > Barbara > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, November 01, 2007 6:16 AM > > To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > That's helpful. > > > > I don't think it's sufficient. My example, hardware VPN/tunnel > > mechanisms cannot be permitted, has to be spelled out. > Also, phonebcp > > recommends location update at call time. We haven't worked > out this > > detail, but I think we want to at least recommend that a > mobile device > > send routing location as a value, and dispatch location as > a reference > > (where needed), just to avoid the repeated dereference by all call > > routing elements. > > That > > means you would want to do the HELD LCP operation at call time. > > > > You need to discuss enterprise networks behind access networks that > > provide HELD, or try to use HELD within an enterprise network. > > > > I think it's hard to think through ALL the instances where an IP > > address isn't reliable as an identifier to be used for > location, which > > is why I phrased my proposed text the way I did. > > > > Brian > > > > > -----Original Message----- > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > Sent: Thursday, November 01, 2007 5:42 AM > > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > asanidentifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > Oh, fine, I'll try to be helpful, then. > > > I definitely agree with having the problem mentioned and properly > > > characterized. But when we write requirements, I want to be sure > > > that the requirements are implementable. > > > > > > Certainly, end devices must do location configuration before > > > establishing a VPN. Once an end device has established a VPN, it > > > must not do any LIS discovery or HELD queries over the > VPN connection. > > > > > > The Access Network, however, needs to have the > requirement that its > > LIS > > > be able to know which subnets of IP addresses are supplied to > > > devices coming over VPN access, or have been provided to > a company > > > that > > provides > > > its own LIS. That is, such blocks of IP addresses need to be > > > configurable in the LIS. Then there's the requirement that the LIS > > must > > > not provide location to these IP addresses. > > > > > > The access network (access provider + ISP) also has a > responsibility > > not > > > to place a LIS on the core side of any NAT that is > employed in the > > > access network. Note that this isn't meant to apply to home router > > NATs, > > > since those aren't part of the access network, according to the > > > definition of access network. > > > > > > I really think that the access network has greater ability, and > > > therefore greater responsibility, to minimize the occurrence of > > problems > > > due to VPNs and NATs. > > > > > > As we discussed (Brian and I), I'm going to try to > suggest a way to > > > better include in phonebcp requirements for routers employed in > > > "small areas". One of the requirements we need for these, is that > > > they MUST > > act > > > as the LIS for LAN-side devices, when they have VPN > connections to > > > the WAN. > > > Barbara > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, November 01, 2007 4:03 AM > > > To: 'Dawson, Martin'; 'Richard Barnes'; Stark, Barbara; 'ECRIT' > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > asanidentifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > I think the problem that Barbara points out is precisely > the problem > > in > > > deploying HELD. Claiming that a problem can't be solved, and > > therefore > > > should not be mentioned is, uh, ?unhelpful? Having the "caveat" > > instead > > > of > > > a deployment recommendation understates the problem. While it is > > > possible to deploy HELD so that it almost always works, > it will take > > > a lot of attention by a lot of entities to make that happen. For > > > example, if HELD is deployed, no non-bypassable VPNs can be > > > permitted. The protocol document should be very clear > about what it > > > takes to make HELD work. > > > > > > I have no problem including text that covers what devices > and LIS's > > need > > > to > > > do, as long as it was noted that it won't always be > sufficient. We > > > might also include text on how enterprise networks should be > > > configured. > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > Sent: Wednesday, October 31, 2007 11:58 AM > > > > To: Richard Barnes; Stark, Barbara; ECRIT > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > > > > asanidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > I think that the "device" requirement at most should be that > > > > efforts should be made to ensure that the LIS is discovered and > > > > used on the physical access network and not via any VPN tunnel. > > > > > > > > Perhaps more importantly, there should be a complementary > > requirement > > > on > > > > the LIS that it not attempt to provide location for an > IP address > > that > > > > it cannot associate a physical location with. For > example, a LIS > > > > in > > an > > > > enterprise, where that enterprise supports VPN access, > should know > > or > > > be > > > > able to determine that the client requests are arriving > over a VPN > > > from > > > > an end point whose location cannot be determined. The HELD > > > > response should indicate that location cannot be provided. > > > > > > > > Cheers, > > > > Martin > > > > > > > > -----Original Message----- > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > Sent: Thursday, 1 November 2007 1:22 AM > > > > To: Stark, Barbara; ECRIT > > > > Subject: [Ecrit] Re: [Geopriv] Use of IP address as > anidentifier > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > Right, I think what's needed is more a caveat that HELD > provides > > > > the location of the source IP address in the IP header of the > > > > request -- whatever that may be. > > > > > > > > --Richard > > > > > > > > > > > > > > > > Stark, Barbara wrote: > > > > > How is a client supposed to know whether a "VPN, NAT > or other IP > > > > address > > > > > modification exists between the client and the server which > > > > > could produce incorrect location"? One of the best > uses of HELD > > > > > is the > > > case > > > > > where there is a NAT (and the box with the NAT is location > > unaware). > > > > For > > > > > landline broadband services, this NAT exists, but doesn't > > > > > produce > > an > > > > > incorrect location. So this NAT is ok. How can you distinguish > > > between > > > > a > > > > > NAT that produces an incorrect location, vs. one that > produces a > > > > correct > > > > > location? > > > > > > > > > > The VPN could be originated out of the router, and > not the client. > > > How > > > > > would the client know this VPN even exists? > > > > > > > > > > Unless you can tell me the logic to use to implement this > > > > > proposed requirement, I can't support it. > > > > > Barbara > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Wednesday, October 31, 2007 8:51 AM > > > > > To: geopriv@ietf.org > > > > > Subject: [Geopriv] Use of IP address as an identifier > > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > In the long set of discussions that have lead to HELD, one of > > > > > the biggest concerns a few of us have had is the > problem than an > > > > > IP address > > may > > > > not > > > > > be a > > > > > good identifier for determining the location of the client. > > > > > There > > > is > > > > a > > > > > draft that describes alternate identifiers. However, > there is > > > > > no discussion in the present draft of the base > protocol on these > > > > > issues. > > > > > > > > > > I would like to propose that we add text something like: > > > > > > > > > > Use of HELD is subject to the viability of the > identifier used > > > > > by > > > the > > > > > LIS to > > > > > determine location. This document describes the use of the IP > > > address > > > > > of > > > > > the client as the identifier. When a NAT, VPN or > other forms of > > > > address > > > > > modification occur between the client and the server, the > > > > > location returned may be inaccurate. This is not always the > > > > > case. For example, a > > NAT > > > > > used in > > > > > a residential local area network is typically not a problem, > > because > > > > the > > > > > external IP address used on the WAN side of the NAT > is in fact > > > > > the > > > > right > > > > > identifier for all of the devices in the residence. On the > > > > > other > > > > hand, > > > > > if > > > > > there is a VPN between the client and the server, for example > > > > > for > > a > > > > > teleworker, then the address seen by the server may not be the > > right > > > > > address > > > > > to identify the location of the client. Where a VPN is > > > > > deployed, clients often have the ability to bypass > the VPN for a > > > > > transaction like > > > HELD. > > > > > > > > > > HELD Clients MUST NOT send HELD requests where IP > address is the > > > > > identifier and a VPN, NAT or other IP address modification > > > > > exists between the client and the server which could produce > > > > > incorrect location. HELD MUST > > > NOT > > > > be > > > > > deployed in networks where the client cannot comply reasonably > > > > reliably > > > > > with > > > > > that requirement. > > > > > > > > _______________________________________________ > 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 Nov 01 11:23:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1InbsT-0000Hf-5K; Thu, 01 Nov 2007 11:22:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1InbsS-0000Fp-5h for ecrit@ietf.org; Thu, 01 Nov 2007 11:22:36 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1InbsR-0003or-Jx for ecrit@ietf.org; Thu, 01 Nov 2007 11:22:36 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1InbsI-0002se-4U; Thu, 01 Nov 2007 10:22:26 -0500 From: "Brian Rosen" To: "'Marc Linsner'" , "'Stark, Barbara'" , "'ECRIT'" References: <031201c81c90$d66f8400$1d69fe90@cis.neustar.com> <002001c81c97$afe6ff50$5d02fe90@cisco.com> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier indraft-ietf-geopriv-http-location-delivery Date: Thu, 1 Nov 2007 11:22:31 -0400 Message-ID: <033e01c81c9b$07ffeaa0$1d69fe90@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: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAABsKtgAADH7hA= In-Reply-To: <002001c81c97$afe6ff50$5d02fe90@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: a2c12dacc0736f14d6b540e805505a86 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 The current HELD document ONLY allows IP addresses as identifiers. I agree with your point, and the text should be made clear on that point. If you read my original proposed text, I believe I was clear. Brian > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Thursday, November 01, 2007 10:59 AM > To: 'Brian Rosen'; 'Stark, Barbara'; 'ECRIT' > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier > indraft-ietf-geopriv-http-location-delivery > > In addition to Brian's comment, the whole discussion assumes IP address as > the identifier a LIS utilizes for location lookup. I simply ask that the > use case is clarified when text is added. > > -Marc- > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, November 01, 2007 10:10 AM > > To: 'Stark, Barbara'; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP > > addressasanidentifier indraft-ietf-geopriv-http-location-delivery > > > > The text belongs in the HELD document because it has nothing > > to do with emergency calls. It affects all uses of HELD. > > > > I don't have a problem with expanding text in -phonebcp > > > > Brian > > > > > -----Original Message----- > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > Sent: Thursday, November 01, 2007 9:58 AM > > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > I have no problem with your proposed verbiage characterizing the > > > problem. > > > > > > I think that requirements on end devices using HELD and access > > > networks providing HELD responses is a phonebcp issue, and not > > > http-location-delivery. > > > > > > Within phonebcp, I think that enterprise networks (that are > > not able > > > to control the capabilities of devices attaching to them) > > are already > > > included in the definition of access network. That seems to > > currently > > > be implicit, but perhaps it should be explicit. Then all > > requirements > > > that apply to access networks will explicitly apply to such > > enterprise > > > networks. I'm not sure I see what such enterprise networks > > need to do > > > different than public access networks. You already have > > some VPN and > > > NAT requirements there: > > > AN-14 Network administrators MUST take care in assigning > > IP addresses > > > such that VPN address assignments can be distinguished from local > > > devices (by subnet choice, for example), and LISs should > > not attempt > > > to provide location to addresses that arrive via VPN connections. > > > > > > AN-15 Placement of NAT devices should consider the > > effect of the NAT > > > on the LCP. > > > > > > The device location update when the device has a VPN > > established that > > > doesn't allow split tunneling is definitely a gap. I think > > it could be > > > solved with some HELD extensions (which is a geopriv > > issue). That is, > > > I think that if we allow the initial (pre-VPN) request to also > > > negotiate identification and authentication for future > > updates, that > > > we could solve the update problem. > > > > > > The intermediary SOHO (small office/home office) router > > that sets up > > > the non-split tunneling VPN on behalf of its LAN needs to > > be required > > > (in > > > phonebcp) to act as the LIS for all devices in its LAN. > > That's part of > > > the additional requirements I'm working on providing you (Brian). > > > Barbara _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 01 11:38:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inc7p-0005bt-2a; Thu, 01 Nov 2007 11:38:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inc7n-0005VK-3Y for ecrit@ietf.org; Thu, 01 Nov 2007 11:38:27 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Inc7h-0004WL-DB for ecrit@ietf.org; Thu, 01 Nov 2007 11:38:21 -0400 X-SEF-Processed: 5_0_0_910__2007_11_01_10_48_38 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 01 Nov 2007 10:48:38 -0500 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Nov 2007 10:38:19 -0500 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 Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery Date: Thu, 1 Nov 2007 10:38:13 -0500 Message-ID: In-Reply-To: <4729E8AD.9000704@bbn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgclyTTrKYFakctSlmmnTWocg38cgABYdIA References: <7582BC68E4994F4ABF0BD4723975C3FA06376AAE@crexc41p> <031201c81c90$d66f8400$1d69fe90@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA06376AD7@crexc41p> <4729E8AD.9000704@bbn.com> From: "Dawson, Martin" To: "Richard Barnes" , "Stark, Barbara" X-OriginalArrivalTime: 01 Nov 2007 15:38:19.0046 (UTC) FILETIME=[3A1CAC60:01C81C9D] X-Spam-Score: 1.8 (+) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Richard,=0D=0A=0D=0AA network can be extended in many ways without the L= IS being "aware".=0D=0AGenerally that would be a failure to maintain the LI= S state on the part=0D=0Aof the administrator.=0D=0A=0D=0AAs Brian said, wr= t the NAT scenario, it's not a problem as long as the=0D=0Alocation of the = NAT device is actually considered adequate as far as=0D=0Arepresenting the = location of the end point is concerned. Typically=0D=0Athat's the case for = a residential broadband connection and, indeed, is=0D=0Aexactly analogous t= o a POTS service providing the residential address=0D=0Aassociated with the= phone service even though there may be a cordless=0D=0Aphone on that POTS = connection with a one kilometre range.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D= =0A-----Original Message-----=0D=0AFrom: Richard Barnes [mailto:rbarnes@bbn= =2Ecom]=20=0D=0ASent: Friday, 2 November 2007 1:55 AM=0D=0ATo: Stark, Barba= ra=0D=0ACc: Brian Rosen; Dawson, Martin; ECRIT=0D=0ASubject: Re: [Ecrit] Re= : [Geopriv] Use of IP address asanidentifier=0D=0Aindraft-ietf-geopriv-http= -location-delivery=0D=0A=0D=0AAs far as which document this belongs in, I m= ostly don't care. However,=0D=0A=0D=0A it shouldn't be in phonebcp becaus= e it's not emergency-specific.=0D=0A=0D=0AMy analysis of the situation is b= elow, if it's helpful.=0D=0A=0D=0A--Richard=0D=0A=0D=0A=0D=0AThere are two = things that cause problems for HELD (using IP source=20=0D=0Aaddress as an = identifier for the endpoint):=0D=0A1. The IP address that HELD uses is the = IP source address=0D=0A2. There are several logical steps between IP addres= s and location=0D=0A=09-- e.g. IP --> MAC --> WLAN AP --> Loc=0D=0A=09-- e.= g. IP --> MAC --> port --> Loc=0D=0A=0D=0A=0D=0ASo a HELD LIS can position = an endpoint if:=0D=0A1. The LIS has sufficient knowledge of the network to = which the endpoint=0D=0A=0D=0Ais physically attached to derive its location= (given the proper IP=0D=0Aaddress)=0D=0A2. The IP source address in the HE= LD request is the one that will direct=0D=0A=0D=0Athe LIS to return the end= point's location=0D=0AIn most cases, (2) means that the source address is t= he one the network=20=0D=0Aassigned, or that the source address was not cha= nged while the packet=20=0D=0Awas in transit.=0D=0A=0D=0AMartin's pair of e= nterprise networks "glued together" with a VPN meets=20=0D=0Athese criteria= (with all three versions of 2). The LIS is an enterprise=0D=0A=0D=0Aasset= , so it can be provisioned with knowledge of both networks. And=20=0D=0Aev= en if a packet traverses the VPN, it's just tunneled whole, and the=20=0D=0A= source address is never changed.=0D=0A=0D=0AIn the "road warrior" VPN case:=0D= =0A1. In a query from the endpoint to an enterprise LIS: Criterion (2) is =0D= =0Atrue -- IP source addresses are carried faithfully from source to LIS. =0D= =0ABut criterion (1) is false, because the LIS does not have sufficient=20=0D= =0Ainformation about the host's attachment to locate it.=0D=0A2. In a query= from the endpoint to an access network LIS through the=20=0D=0Atunnel: Cri= terion (1) is true, but criterion (2) is false. The LIS has=20=0D=0Asuffic= ient information, but the source address is in the enterprise=20=0D=0Anetwo= rk, not the right one.=0D=0A3. In a query from the endpoint to an access ne= twork LIS outside the=20=0D=0Atunnel: This works because (1) the LIS knows = about the network the=20=0D=0Aendpoint is physically attached to, and (2) t= he LIS gets the IP address=20=0D=0Athat it assigned.=0D=0A=0D=0AIf the endp= oint and the LIS are on opposite sides of a NAT, (1) is=20=0D=0Aalmost alwa= ys false, and (2) as well. (1) is only true if the LIS is=20=0D=0Aaware of= the network topology behind the NAT (even if not the=20=0D=0Aaddressing), = and (2) is only true if the LIS is aware of the address=20=0D=0Amapping in = the LIS. Note that (2) cannot be true if there's multiple=20=0D=0Ahosts wi= th different locations are fronted by a NAT with a single public=0D=0A=0D=0A= address (since HELD doesn't account for port numbers).=0D=0A=0D=0AIn a part= icular deployment scenario, the problem is to determine under=20=0D=0Awhat = observable conditions these criteria are true, and constrain the=20=0D=0ALI= S to answering queries only when they are likely to be true.=0D=0A=0D=0AWit= h respect to (2): It seems like you could have some assurance using=20=0D=0A= the HELD identity extension for the endpoint to include it's own IP=20=0D=0A= address in the HELD request. The LIS could then detect changes in the=20=0D= =0Asource IP addresses by comparing the two.=0D=0A=0D=0AWith respect to (1)= : This is much more difficult to deal with, since you=0D=0A=0D=0Acan extend= the network without the LIS being aware, like by adding a VPN=0D=0A=0D=0Ao= ut to a remote point. Getting any assurance on this point requires=20=0D=0A= strong constraints on the structure of the network.=0D=0A=0D=0A------------= ---------------------------------------------------------------------------= ---------=0D=0AThis message is for the designated recipient only and may=0D= =0Acontain privileged, proprietary, or otherwise private information. =20=0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 01 12:26:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IncrJ-0005NZ-Jf; Thu, 01 Nov 2007 12:25:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IncrI-0005Iq-F0 for ecrit@ietf.org; Thu, 01 Nov 2007 12:25:28 -0400 Received: from mail.skype.net ([193.88.6.4]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Incr8-0005yF-T8 for ecrit@ietf.org; Thu, 01 Nov 2007 12:25:19 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 45DCD110995 for ; Thu, 1 Nov 2007 17:25:16 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdq9o7biXY3B for ; Thu, 1 Nov 2007 17:25:12 +0100 (CET) Received: from [144.254.105.16] (dhcp-guest-bru-peg1-144-254-105-16.cisco.com [144.254.105.16]) by mail.skype.net (Postfix) with ESMTP id A70DF111097 for ; Thu, 1 Nov 2007 17:25:12 +0100 (CET) User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Thu, 01 Nov 2007 18:25:08 +0200 From: Andres K=?ISO-8859-1?B?/A==?=tt To: Message-ID: Thread-Topic: Ecrit Digest, Vol 34, Issue 3 Thread-Index: Acgco8RhAt95D4iXEdyzFwAX8sNx3Q== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ecrit] Re: Ecrit Digest, Vol 34, Issue 3 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 > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Thursday, November 01, 2007 6:16 AM > To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > indraft-ietf-geopriv-http-location-delivery >=20 > That's helpful. >=20 > I don't think it's sufficient. My example, hardware VPN/tunnel > mechanisms > cannot be permitted, has to be spelled out. What do you mean by "not permitted"? So if the user is unfortunate enough t= o get into trouble in a situation like that they can't contact a PSAP? Yours, Andres K=FCtt _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 01 16:56:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inh4k-0000FM-Im; Thu, 01 Nov 2007 16:55:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inh4k-0000Es-12 for ecrit@ietf.org; Thu, 01 Nov 2007 16:55:38 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Inh4i-0001wq-QH for ecrit@ietf.org; Thu, 01 Nov 2007 16:55:38 -0400 X-IronPort-AV: E=Sophos;i="4.21,359,1188802800"; d="scan'208";a="184282316" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 01 Nov 2007 13:55:36 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA1KtZ33028449; Thu, 1 Nov 2007 13:55:35 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA1Kt0YL023081; Thu, 1 Nov 2007 20:55:31 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 16:55:30 -0400 Received: from mlinsnerwxp02 ([10.61.66.108]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Nov 2007 16:55:29 -0400 From: "Marc Linsner" To: "=?iso-8859-1?Q?'Andres_K_=FC_tt'?=" , Subject: RE: [Ecrit] Re: Ecrit Digest, Vol 34, Issue 3 Date: Thu, 1 Nov 2007 16:55:28 -0400 Message-ID: <001d01c81cc9$88fa2c00$6c423d0a@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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: Thread-Index: Acgco8RhAt95D4iXEdyzFwAX8sNx3QAJMsWw X-OriginalArrivalTime: 01 Nov 2007 20:55:29.0389 (UTC) FILETIME=[891491D0:01C81CC9] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15518.002 X-TM-AS-Result: No--10.211600-8.000000-4 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=601; t=1193950536; x=1194814536; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Re=3A=20Ecrit=20Digest, =20Vol=2034, =20Issue =203 |Sender:=20; bh=ac+n1bFchGupSbxc9vt8E2b3Z+32fR3xxNk4bJyCR3s=; b=KXZugTAAt/3RepXe+ysngld1uz8TpKo97mdiir7T1KHjtowOsjhltb8iq8WMhV/4dUR8dNs5 tJGoz3Yrk9hhGfGJmHApfXi7UZ6zn/528GfNuj0JXfJz31y/djLL6FWL8usHTZEeU4XsvVr08v ZwFSibLoidootBcg/RLtrYcIM=; Authentication-Results: sj-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.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 Andres, > >=20 > > I don't think it's sufficient. My example, hardware VPN/tunnel=20 > > mechanisms cannot be permitted, has to be spelled out. > What do you mean by "not permitted"? So if the user is=20 > unfortunate enough to get into trouble in a situation like=20 > that they can't contact a PSAP? No, they are talking about one of the failure modes of an L7 LCP architecture. -Marc- >=20 > Yours, > Andres K=FCtt >=20 >=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 Thu Nov 01 17:32:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inhdv-0007aO-HO; Thu, 01 Nov 2007 17:31:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Inhdu-0007aB-Mm for ecrit@ietf.org; Thu, 01 Nov 2007 17:31:58 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Inhdt-0007la-8G for ecrit@ietf.org; Thu, 01 Nov 2007 17:31:58 -0400 X-SEF-Processed: 5_0_0_910__2007_11_01_16_42_13 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 01 Nov 2007 16:42:12 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Nov 2007 16:31:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier indraft-ietf-geopriv-http-location-delivery Date: Thu, 1 Nov 2007 16:31:51 -0500 Message-ID: In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA06376AD7@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkA= References: <7582BC68E4994F4ABF0BD4723975C3FA06376AAE@crexc41p><031201c81c90$d66f8400$1d69fe90@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA06376AD7@crexc41p> From: "Thomson, Martin" To: "Stark, Barbara" , "Brian Rosen" , "Dawson, Martin" , "Richard Barnes" , "ECRIT" X-OriginalArrivalTime: 01 Nov 2007 21:31:53.0011 (UTC) FILETIME=[9E9ED830:01C81CCE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5fb88b8381f3896aeacc5a021513237b 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: , Content-Type: multipart/mixed; boundary="===============1869830443==" Errors-To: ecrit-bounces@ietf.org --===============1869830443== Content-class: urn:content-classes:message Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHRvIHN0cm9uZ2x5IGFncmVlIHdpdGggQmFyYmFyYS4gIElmIC1waG9uZS1iY3AgaXNu J3QgdGhlIHJpZ2h0IHBsYWNlIGZvciB0aGVzZSByZWNvbW1lbmRhdGlvbnMgdGhlbiBzb21lb25l IGNhbiB3cml0ZSBhbm90aGVyIEJDUC4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBTdGFyaywgQmFyYmFyYSBbbWFpbHRvOmJzNzY1MkBhdHQuY29tXQ0KPiBTZW50OiBG cmlkYXksIDIgTm92ZW1iZXIgMjAwNyAxOjM5IEFNDQo+IFRvOiBCcmlhbiBSb3NlbjsgRGF3c29u LCBNYXJ0aW47IFJpY2hhcmQgQmFybmVzOyBFQ1JJVA0KPiBTdWJqZWN0OiBSRTogW0Vjcml0XSBS ZTogW0dlb3ByaXZdIFVzZSBvZiBJUCBhZGRyZXNzYXNhbmlkZW50aWZpZXINCj4gaW5kcmFmdC1p ZXRmLWdlb3ByaXYtaHR0cC1sb2NhdGlvbi1kZWxpdmVyeQ0KPiANCj4gSEVMRCBpcyBhIHByb3Rv Y29sLCBwdXJlbHkgYW5kIHNpbXBseS4gSXQncyBub3QgYSBCQ1AgYW5kIGNhbm5vdCBhbmQNCj4g c2hvdWxkIG5vdCBhdHRlbXB0IHRvIHVzZSBNVVNUIGFuZCBTSE9VTEQgbGFuZ3VhZ2UgYXJvdW5k IGJlaGF2aW9yIG9mDQo+IGRldmljZXMgYW5kIG5ldHdvcmtzIHRoYXQgdXNlIHRoZSBwcm90b2Nv bCwgb3V0c2lkZSBvZiByZXF1aXJlbWVudHMNCj4gZGlyZWN0bHkgcmVsYXRlZCB0byBmb3JtYXR0 aW5nIG9mIHRoZSBwcm90b2NvbCBtZXNzYWdlcy4NCj4gSHR0cC1sb2NhdGlvbi1kZWxpdmVyeSBN VVNUIE5PVCBjb250YWluIG5vcm1hdGl2ZSBsYW5ndWFnZSB0aGF0IGF0dGVtcHRzDQo+IHRvIHJl c3RyaWN0IHRoZSBlbnZpcm9ubWVudCB3aGVyZSBIRUxEIG1heSBiZSB1c2VkLiBJIGhhdmUgbm8g cHJvYmxlbQ0KPiB3aXRoIGluY2x1ZGluZyBhIGRpc2N1c3Npb24gb2YgdGhlc2UgaXNzdWVzIGlu IGh0dHAtbG9jYXRpb24tZGVsaXZlcnkuDQo+IEJ1dCBpZiB5b3Ugd2FudCBzb21ldGhpbmcgc3Ry b25nZXIsIGl0IG5lZWRzIHRvIGJlIGEgQkNQLiBTaW5jZSBwaG9uZWJjcA0KPiBvbmx5IGFwcGxp ZXMgdG8gdXNlIGZvciBlbWVyZ2VuY3kgc2VydmljZXMsIHRoZW4gSSBndWVzcyB5b3UnZCBuZWVk IGENCj4gbW9yZSBnZW5lcmljIEJDUCBvdXQgb2YgZ2VvcHJpdi4NCj4gDQo+IFNpbmNlIHN1Y2gg YSBIRUxEIEJDUCAoZnJvbSBnZW9wcml2KSBtYXkgb3IgbWF5IG5vdCBiZSByZWNvZ25pemVkIGJ5 DQo+IGRldmljZSBtYW51ZmFjdHVyZXJzLCBJJ2QgcmVjb21tZW5kIG1ha2luZyBzdXJlIHRoYXQg cGhvbmViY3AgZG9lcyBoYXZlDQo+IHdoYXQncyBuZWVkZWQsIGFzIGZhciBhcyB1c2Ugb2YgSEVM RCBmb3IgZW1lcmdlbmN5IHNlcnZpY2VzLg0KPiBCYXJiYXJhDQo+IA0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCcmlhbiBSb3NlbiBbbWFpbHRvOmJyQGJyaWFucm9zZW4u bmV0XQ0KPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDEsIDIwMDcgMTA6MTAgQU0NCj4gVG86 IFN0YXJrLCBCYXJiYXJhOyAnRGF3c29uLCBNYXJ0aW4nOyAnUmljaGFyZCBCYXJuZXMnOyAnRUNS SVQnDQo+IFN1YmplY3Q6IFJFOiBbRWNyaXRdIFJlOiBbR2VvcHJpdl0gVXNlIG9mIElQIGFkZHJl c3MgYXNhbmlkZW50aWZpZXINCj4gaW5kcmFmdC1pZXRmLWdlb3ByaXYtaHR0cC1sb2NhdGlvbi1k ZWxpdmVyeQ0KPiANCj4gVGhlIHRleHQgYmVsb25ncyBpbiB0aGUgSEVMRCBkb2N1bWVudCBiZWNh dXNlIGl0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGgNCj4gZW1lcmdlbmN5IGNhbGxzLiAgSXQgYWZm ZWN0cyBhbGwgdXNlcyBvZiBIRUxELg0KPiANCj4gSSBkb24ndCBoYXZlIGEgcHJvYmxlbSB3aXRo IGV4cGFuZGluZyB0ZXh0IGluIC1waG9uZWJjcA0KPiANCj4gQnJpYW4NCj4gDQo+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBTdGFyaywgQmFyYmFyYSBbbWFpbHRvOmJz NzY1MkBhdHQuY29tXQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwMSwgMjAwNyA5OjU4 IEFNDQo+ID4gVG86IEJyaWFuIFJvc2VuOyBEYXdzb24sIE1hcnRpbjsgUmljaGFyZCBCYXJuZXM7 IEVDUklUDQo+ID4gU3ViamVjdDogUkU6IFtFY3JpdF0gUmU6IFtHZW9wcml2XSBVc2Ugb2YgSVAg YWRkcmVzcyBhc2FuaWRlbnRpZmllcg0KPiA+IGluZHJhZnQtaWV0Zi1nZW9wcml2LWh0dHAtbG9j YXRpb24tZGVsaXZlcnkNCj4gPg0KPiA+IEkgaGF2ZSBubyBwcm9ibGVtIHdpdGggeW91ciBwcm9w b3NlZCB2ZXJiaWFnZSBjaGFyYWN0ZXJpemluZyB0aGUNCj4gPiBwcm9ibGVtLg0KPiA+DQo+ID4g SSB0aGluayB0aGF0IHJlcXVpcmVtZW50cyBvbiBlbmQgZGV2aWNlcyB1c2luZyBIRUxEIGFuZCBh Y2Nlc3MNCj4gbmV0d29ya3MNCj4gPiBwcm92aWRpbmcgSEVMRCByZXNwb25zZXMgaXMgYSBwaG9u ZWJjcCBpc3N1ZSwgYW5kIG5vdA0KPiA+IGh0dHAtbG9jYXRpb24tZGVsaXZlcnkuDQo+ID4NCj4g PiBXaXRoaW4gcGhvbmViY3AsIEkgdGhpbmsgdGhhdCBlbnRlcnByaXNlIG5ldHdvcmtzICh0aGF0 IGFyZSBub3QgYWJsZQ0KPiB0bw0KPiA+IGNvbnRyb2wgdGhlIGNhcGFiaWxpdGllcyBvZiBkZXZp Y2VzIGF0dGFjaGluZyB0byB0aGVtKSBhcmUgYWxyZWFkeQ0KPiA+IGluY2x1ZGVkIGluIHRoZSBk ZWZpbml0aW9uIG9mIGFjY2VzcyBuZXR3b3JrLiBUaGF0IHNlZW1zIHRvIGN1cnJlbnRseQ0KPiBi ZQ0KPiA+IGltcGxpY2l0LCBidXQgcGVyaGFwcyBpdCBzaG91bGQgYmUgZXhwbGljaXQuIFRoZW4g YWxsIHJlcXVpcmVtZW50cw0KPiB0aGF0DQo+ID4gYXBwbHkgdG8gYWNjZXNzIG5ldHdvcmtzIHdp bGwgZXhwbGljaXRseSBhcHBseSB0byBzdWNoIGVudGVycHJpc2UNCj4gPiBuZXR3b3Jrcy4gSSdt IG5vdCBzdXJlIEkgc2VlIHdoYXQgc3VjaCBlbnRlcnByaXNlIG5ldHdvcmtzIG5lZWQgdG8gZG8N Cj4gPiBkaWZmZXJlbnQgdGhhbiBwdWJsaWMgYWNjZXNzIG5ldHdvcmtzLiBZb3UgYWxyZWFkeSBo YXZlIHNvbWUgVlBOIGFuZA0KPiBOQVQNCj4gPiByZXF1aXJlbWVudHMgdGhlcmU6DQo+ID4gICAg QU4tMTQgTmV0d29yayBhZG1pbmlzdHJhdG9ycyBNVVNUIHRha2UgY2FyZSBpbiBhc3NpZ25pbmcg SVANCj4gYWRkcmVzc2VzDQo+ID4gICAgc3VjaCB0aGF0IFZQTiBhZGRyZXNzIGFzc2lnbm1lbnRz IGNhbiBiZSBkaXN0aW5ndWlzaGVkIGZyb20gbG9jYWwNCj4gPiAgICBkZXZpY2VzIChieSBzdWJu ZXQgY2hvaWNlLCBmb3IgZXhhbXBsZSksIGFuZCBMSVNzIHNob3VsZCBub3QNCj4gYXR0ZW1wdA0K PiA+ICAgIHRvIHByb3ZpZGUgbG9jYXRpb24gdG8gYWRkcmVzc2VzIHRoYXQgYXJyaXZlIHZpYSBW UE4gY29ubmVjdGlvbnMuDQo+ID4NCj4gPiAgICBBTi0xNSBQbGFjZW1lbnQgb2YgTkFUIGRldmlj ZXMgc2hvdWxkIGNvbnNpZGVyIHRoZSBlZmZlY3Qgb2YgdGhlDQo+IE5BVA0KPiA+ICAgIG9uIHRo ZSBMQ1AuDQo+ID4NCj4gPiBUaGUgZGV2aWNlIGxvY2F0aW9uIHVwZGF0ZSB3aGVuIHRoZSBkZXZp Y2UgaGFzIGEgVlBOIGVzdGFibGlzaGVkIHRoYXQNCj4gPiBkb2Vzbid0IGFsbG93IHNwbGl0IHR1 bm5lbGluZyBpcyBkZWZpbml0ZWx5IGEgZ2FwLiBJIHRoaW5rIGl0IGNvdWxkIGJlDQo+ID4gc29s dmVkIHdpdGggc29tZSBIRUxEIGV4dGVuc2lvbnMgKHdoaWNoIGlzIGEgZ2VvcHJpdiBpc3N1ZSku IFRoYXQgaXMsDQo+IEkNCj4gPiB0aGluayB0aGF0IGlmIHdlIGFsbG93IHRoZSBpbml0aWFsIChw cmUtVlBOKSByZXF1ZXN0IHRvIGFsc28gbmVnb3RpYXRlDQo+ID4gaWRlbnRpZmljYXRpb24gYW5k IGF1dGhlbnRpY2F0aW9uIGZvciBmdXR1cmUgdXBkYXRlcywgdGhhdCB3ZSBjb3VsZA0KPiA+IHNv bHZlIHRoZSB1cGRhdGUgcHJvYmxlbS4NCj4gPg0KPiA+IFRoZSBpbnRlcm1lZGlhcnkgU09ITyAo c21hbGwgb2ZmaWNlL2hvbWUgb2ZmaWNlKSByb3V0ZXIgdGhhdCBzZXRzIHVwDQo+IHRoZQ0KPiA+ IG5vbi1zcGxpdCB0dW5uZWxpbmcgVlBOIG9uIGJlaGFsZiBvZiBpdHMgTEFOIG5lZWRzIHRvIGJl IHJlcXVpcmVkIChpbg0KPiA+IHBob25lYmNwKSB0byBhY3QgYXMgdGhlIExJUyBmb3IgYWxsIGRl dmljZXMgaW4gaXRzIExBTi4gVGhhdCdzIHBhcnQgb2YNCj4gPiB0aGUgYWRkaXRpb25hbCByZXF1 aXJlbWVudHMgSSdtIHdvcmtpbmcgb24gcHJvdmlkaW5nIHlvdSAoQnJpYW4pLg0KPiA+IEJhcmJh cmENCj4gPg0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogQnJpYW4g Um9zZW4gW21haWx0bzpickBicmlhbnJvc2VuLm5ldF0NCj4gPiBTZW50OiBUaHVyc2RheSwgTm92 ZW1iZXIgMDEsIDIwMDcgNjoxNiBBTQ0KPiA+IFRvOiBTdGFyaywgQmFyYmFyYTsgJ0Rhd3Nvbiwg TWFydGluJzsgJ1JpY2hhcmQgQmFybmVzJzsgJ0VDUklUJw0KPiA+IFN1YmplY3Q6IFJFOiBbRWNy aXRdIFJlOiBbR2VvcHJpdl0gVXNlIG9mIElQIGFkZHJlc3MgYXNhbmlkZW50aWZpZXINCj4gPiBp bmRyYWZ0LWlldGYtZ2VvcHJpdi1odHRwLWxvY2F0aW9uLWRlbGl2ZXJ5DQo+ID4NCj4gPiBUaGF0 J3MgaGVscGZ1bC4NCj4gPg0KPiA+IEkgZG9uJ3QgdGhpbmsgaXQncyBzdWZmaWNpZW50LiAgTXkg ZXhhbXBsZSwgaGFyZHdhcmUgVlBOL3R1bm5lbA0KPiA+IG1lY2hhbmlzbXMNCj4gPiBjYW5ub3Qg YmUgcGVybWl0dGVkLCBoYXMgdG8gYmUgc3BlbGxlZCBvdXQuICBBbHNvLCBwaG9uZWJjcCByZWNv bW1lbmRzDQo+ID4gbG9jYXRpb24gdXBkYXRlIGF0IGNhbGwgdGltZS4gIFdlIGhhdmVuJ3Qgd29y a2VkIG91dCB0aGlzIGRldGFpbCwgYnV0DQo+IEkNCj4gPiB0aGluayB3ZSB3YW50IHRvIGF0IGxl YXN0IHJlY29tbWVuZCB0aGF0IGEgbW9iaWxlIGRldmljZSBzZW5kIHJvdXRpbmcNCj4gPiBsb2Nh dGlvbiBhcyBhIHZhbHVlLCBhbmQgZGlzcGF0Y2ggbG9jYXRpb24gYXMgYSByZWZlcmVuY2UgKHdo ZXJlDQo+ID4gbmVlZGVkKSwNCj4gPiBqdXN0IHRvIGF2b2lkIHRoZSByZXBlYXRlZCBkZXJlZmVy ZW5jZSBieSBhbGwgY2FsbCByb3V0aW5nIGVsZW1lbnRzLg0KPiA+IFRoYXQNCj4gPiBtZWFucyB5 b3Ugd291bGQgd2FudCB0byBkbyB0aGUgSEVMRCBMQ1Agb3BlcmF0aW9uIGF0IGNhbGwgdGltZS4N Cj4gPg0KPiA+IFlvdSBuZWVkIHRvIGRpc2N1c3MgZW50ZXJwcmlzZSBuZXR3b3JrcyBiZWhpbmQg YWNjZXNzIG5ldHdvcmtzIHRoYXQNCj4gPiBwcm92aWRlDQo+ID4gSEVMRCwgb3IgdHJ5IHRvIHVz ZSBIRUxEIHdpdGhpbiBhbiBlbnRlcnByaXNlIG5ldHdvcmsuDQo+ID4NCj4gPiBJIHRoaW5rIGl0 J3MgaGFyZCB0byB0aGluayB0aHJvdWdoIEFMTCB0aGUgaW5zdGFuY2VzIHdoZXJlIGFuIElQDQo+ IGFkZHJlc3MNCj4gPiBpc24ndCByZWxpYWJsZSBhcyBhbiBpZGVudGlmaWVyIHRvIGJlIHVzZWQg Zm9yIGxvY2F0aW9uLCB3aGljaCBpcyB3aHkNCj4gSQ0KPiA+IHBocmFzZWQgbXkgcHJvcG9zZWQg dGV4dCB0aGUgd2F5IEkgZGlkLg0KPiA+DQo+ID4gQnJpYW4NCj4gPg0KPiA+ID4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+IEZyb206IFN0YXJrLCBCYXJiYXJhIFttYWlsdG86YnM3 NjUyQGF0dC5jb21dDQo+ID4gPiBTZW50OiBUaHVyc2RheSwgTm92ZW1iZXIgMDEsIDIwMDcgNTo0 MiBBTQ0KPiA+ID4gVG86IEJyaWFuIFJvc2VuOyBEYXdzb24sIE1hcnRpbjsgUmljaGFyZCBCYXJu ZXM7IEVDUklUDQo+ID4gPiBTdWJqZWN0OiBSRTogW0Vjcml0XSBSZTogW0dlb3ByaXZdIFVzZSBv ZiBJUCBhZGRyZXNzIGFzYW5pZGVudGlmaWVyDQo+ID4gPiBpbmRyYWZ0LWlldGYtZ2VvcHJpdi1o dHRwLWxvY2F0aW9uLWRlbGl2ZXJ5DQo+ID4gPg0KPiA+ID4gT2gsIGZpbmUsIEknbGwgdHJ5IHRv IGJlIGhlbHBmdWwsIHRoZW4uDQo+ID4gPiBJIGRlZmluaXRlbHkgYWdyZWUgd2l0aCBoYXZpbmcg dGhlIHByb2JsZW0gbWVudGlvbmVkIGFuZCBwcm9wZXJseQ0KPiA+ID4gY2hhcmFjdGVyaXplZC4g QnV0IHdoZW4gd2Ugd3JpdGUgcmVxdWlyZW1lbnRzLCBJIHdhbnQgdG8gYmUgc3VyZQ0KPiB0aGF0 DQo+ID4gPiB0aGUgcmVxdWlyZW1lbnRzIGFyZSBpbXBsZW1lbnRhYmxlLg0KPiA+ID4NCj4gPiA+ IENlcnRhaW5seSwgZW5kIGRldmljZXMgbXVzdCBkbyBsb2NhdGlvbiBjb25maWd1cmF0aW9uIGJl Zm9yZQ0KPiA+ID4gZXN0YWJsaXNoaW5nIGEgVlBOLiBPbmNlIGFuIGVuZCBkZXZpY2UgaGFzIGVz dGFibGlzaGVkIGEgVlBOLCBpdA0KPiBtdXN0DQo+ID4gPiBub3QgZG8gYW55IExJUyBkaXNjb3Zl cnkgb3IgSEVMRCBxdWVyaWVzIG92ZXIgdGhlIFZQTiBjb25uZWN0aW9uLg0KPiA+ID4NCj4gPiA+ IFRoZSBBY2Nlc3MgTmV0d29yaywgaG93ZXZlciwgbmVlZHMgdG8gaGF2ZSB0aGUgcmVxdWlyZW1l bnQgdGhhdCBpdHMNCj4gPiBMSVMNCj4gPiA+IGJlIGFibGUgdG8ga25vdyB3aGljaCBzdWJuZXRz IG9mIElQIGFkZHJlc3NlcyBhcmUgc3VwcGxpZWQgdG8NCj4gZGV2aWNlcw0KPiA+ID4gY29taW5n IG92ZXIgVlBOIGFjY2Vzcywgb3IgaGF2ZSBiZWVuIHByb3ZpZGVkIHRvIGEgY29tcGFueSB0aGF0 DQo+ID4gcHJvdmlkZXMNCj4gPiA+IGl0cyBvd24gTElTLiBUaGF0IGlzLCBzdWNoIGJsb2NrcyBv ZiBJUCBhZGRyZXNzZXMgbmVlZCB0byBiZQ0KPiA+ID4gY29uZmlndXJhYmxlIGluIHRoZSBMSVMu IFRoZW4gdGhlcmUncyB0aGUgcmVxdWlyZW1lbnQgdGhhdCB0aGUgTElTDQo+ID4gbXVzdA0KPiA+ ID4gbm90IHByb3ZpZGUgbG9jYXRpb24gdG8gdGhlc2UgSVAgYWRkcmVzc2VzLg0KPiA+ID4NCj4g PiA+IFRoZSBhY2Nlc3MgbmV0d29yayAoYWNjZXNzIHByb3ZpZGVyICsgSVNQKSBhbHNvIGhhcyBh IHJlc3BvbnNpYmlsaXR5DQo+ID4gbm90DQo+ID4gPiB0byBwbGFjZSBhIExJUyBvbiB0aGUgY29y ZSBzaWRlIG9mIGFueSBOQVQgdGhhdCBpcyBlbXBsb3llZCBpbiB0aGUNCj4gPiA+IGFjY2VzcyBu ZXR3b3JrLiBOb3RlIHRoYXQgdGhpcyBpc24ndCBtZWFudCB0byBhcHBseSB0byBob21lIHJvdXRl cg0KPiA+IE5BVHMsDQo+ID4gPiBzaW5jZSB0aG9zZSBhcmVuJ3QgcGFydCBvZiB0aGUgYWNjZXNz IG5ldHdvcmssIGFjY29yZGluZyB0byB0aGUNCj4gPiA+IGRlZmluaXRpb24gb2YgYWNjZXNzIG5l dHdvcmsuDQo+ID4gPg0KPiA+ID4gSSByZWFsbHkgdGhpbmsgdGhhdCB0aGUgYWNjZXNzIG5ldHdv cmsgaGFzIGdyZWF0ZXIgYWJpbGl0eSwgYW5kDQo+ID4gPiB0aGVyZWZvcmUgZ3JlYXRlciByZXNw b25zaWJpbGl0eSwgdG8gbWluaW1pemUgdGhlIG9jY3VycmVuY2Ugb2YNCj4gPiBwcm9ibGVtcw0K PiA+ID4gZHVlIHRvIFZQTnMgYW5kIE5BVHMuDQo+ID4gPg0KPiA+ID4gQXMgd2UgZGlzY3Vzc2Vk IChCcmlhbiBhbmQgSSksIEknbSBnb2luZyB0byB0cnkgdG8gc3VnZ2VzdCBhIHdheSB0bw0KPiA+ ID4gYmV0dGVyIGluY2x1ZGUgaW4gcGhvbmViY3AgcmVxdWlyZW1lbnRzIGZvciByb3V0ZXJzIGVt cGxveWVkIGluDQo+ICJzbWFsbA0KPiA+ID4gYXJlYXMiLiBPbmUgb2YgdGhlIHJlcXVpcmVtZW50 cyB3ZSBuZWVkIGZvciB0aGVzZSwgaXMgdGhhdCB0aGV5IE1VU1QNCj4gPiBhY3QNCj4gPiA+IGFz IHRoZSBMSVMgZm9yIExBTi1zaWRlIGRldmljZXMsIHdoZW4gdGhleSBoYXZlIFZQTiBjb25uZWN0 aW9ucyB0bw0KPiB0aGUNCj4gPiA+IFdBTi4NCj4gPiA+IEJhcmJhcmENCj4gPiA+DQo+ID4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogQnJpYW4gUm9zZW4gW21haWx0 bzpickBicmlhbnJvc2VuLm5ldF0NCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBOb3ZlbWJlciAwMSwg MjAwNyA0OjAzIEFNDQo+ID4gPiBUbzogJ0Rhd3NvbiwgTWFydGluJzsgJ1JpY2hhcmQgQmFybmVz JzsgU3RhcmssIEJhcmJhcmE7ICdFQ1JJVCcNCj4gPiA+IFN1YmplY3Q6IFJFOiBbRWNyaXRdIFJl OiBbR2VvcHJpdl0gVXNlIG9mIElQIGFkZHJlc3MgYXNhbmlkZW50aWZpZXINCj4gPiA+IGluZHJh ZnQtaWV0Zi1nZW9wcml2LWh0dHAtbG9jYXRpb24tZGVsaXZlcnkNCj4gPiA+DQo+ID4gPiBJIHRo aW5rIHRoZSBwcm9ibGVtIHRoYXQgQmFyYmFyYSBwb2ludHMgb3V0IGlzIHByZWNpc2VseSB0aGUg cHJvYmxlbQ0KPiA+IGluDQo+ID4gPiBkZXBsb3lpbmcgSEVMRC4gIENsYWltaW5nIHRoYXQgYSBw cm9ibGVtIGNhbid0IGJlIHNvbHZlZCwgYW5kDQo+ID4gdGhlcmVmb3JlDQo+ID4gPiBzaG91bGQg bm90IGJlIG1lbnRpb25lZCBpcywgdWgsID91bmhlbHBmdWw/ICBIYXZpbmcgdGhlICJjYXZlYXQi DQo+ID4gaW5zdGVhZA0KPiA+ID4gb2YNCj4gPiA+IGEgZGVwbG95bWVudCByZWNvbW1lbmRhdGlv biB1bmRlcnN0YXRlcyB0aGUgcHJvYmxlbS4gIFdoaWxlIGl0IGlzDQo+ID4gPiBwb3NzaWJsZQ0K PiA+ID4gdG8gZGVwbG95IEhFTEQgc28gdGhhdCBpdCBhbG1vc3QgYWx3YXlzIHdvcmtzLCBpdCB3 aWxsIHRha2UgYSBsb3Qgb2YNCj4gPiA+IGF0dGVudGlvbiBieSBhIGxvdCBvZiBlbnRpdGllcyB0 byBtYWtlIHRoYXQgaGFwcGVuLiAgRm9yIGV4YW1wbGUsIGlmDQo+ID4gPiBIRUxEIGlzDQo+ID4g PiBkZXBsb3llZCwgbm8gbm9uLWJ5cGFzc2FibGUgVlBOcyBjYW4gYmUgcGVybWl0dGVkLiAgVGhl IHByb3RvY29sDQo+ID4gPiBkb2N1bWVudA0KPiA+ID4gc2hvdWxkIGJlIHZlcnkgY2xlYXIgYWJv dXQgd2hhdCBpdCB0YWtlcyB0byBtYWtlIEhFTEQgd29yay4NCj4gPiA+DQo+ID4gPiBJIGhhdmUg bm8gcHJvYmxlbSBpbmNsdWRpbmcgdGV4dCB0aGF0IGNvdmVycyB3aGF0IGRldmljZXMgYW5kIExJ UydzDQo+ID4gbmVlZA0KPiA+ID4gdG8NCj4gPiA+IGRvLCBhcyBsb25nIGFzIGl0IHdhcyBub3Rl ZCB0aGF0IGl0IHdvbid0IGFsd2F5cyBiZSBzdWZmaWNpZW50LiAgV2UNCj4gPiA+IG1pZ2h0DQo+ ID4gPiBhbHNvIGluY2x1ZGUgdGV4dCBvbiBob3cgZW50ZXJwcmlzZSBuZXR3b3JrcyBzaG91bGQg YmUgY29uZmlndXJlZC4NCj4gPiA+DQo+ID4gPiBCcmlhbg0KPiA+ID4NCj4gPiA+DQo+ID4gPiA+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZyb206IERhd3NvbiwgTWFydGlu IFttYWlsdG86TWFydGluLkRhd3NvbkBhbmRyZXcuY29tXQ0KPiA+ID4gPiBTZW50OiBXZWRuZXNk YXksIE9jdG9iZXIgMzEsIDIwMDcgMTE6NTggQU0NCj4gPiA+ID4gVG86IFJpY2hhcmQgQmFybmVz OyBTdGFyaywgQmFyYmFyYTsgRUNSSVQNCj4gPiA+ID4gU3ViamVjdDogUkU6IFtFY3JpdF0gUmU6 IFtHZW9wcml2XSBVc2Ugb2YgSVAgYWRkcmVzcw0KPiBhc2FuaWRlbnRpZmllcg0KPiA+ID4gPiBp bmRyYWZ0LWlldGYtZ2VvcHJpdi1odHRwLWxvY2F0aW9uLWRlbGl2ZXJ5DQo+ID4gPiA+DQo+ID4g PiA+IEkgdGhpbmsgdGhhdCB0aGUgImRldmljZSIgcmVxdWlyZW1lbnQgYXQgbW9zdCBzaG91bGQg YmUgdGhhdA0KPiBlZmZvcnRzDQo+ID4gPiA+IHNob3VsZCBiZSBtYWRlIHRvIGVuc3VyZSB0aGF0 IHRoZSBMSVMgaXMgZGlzY292ZXJlZCBhbmQgdXNlZCBvbg0KPiB0aGUNCj4gPiA+ID4gcGh5c2lj YWwgYWNjZXNzIG5ldHdvcmsgYW5kIG5vdCB2aWEgYW55IFZQTiB0dW5uZWwuDQo+ID4gPiA+DQo+ ID4gPiA+IFBlcmhhcHMgbW9yZSBpbXBvcnRhbnRseSwgdGhlcmUgc2hvdWxkIGJlIGEgY29tcGxl bWVudGFyeQ0KPiA+IHJlcXVpcmVtZW50DQo+ID4gPiBvbg0KPiA+ID4gPiB0aGUgTElTIHRoYXQg aXQgbm90IGF0dGVtcHQgdG8gcHJvdmlkZSBsb2NhdGlvbiBmb3IgYW4gSVAgYWRkcmVzcw0KPiA+ IHRoYXQNCj4gPiA+ID4gaXQgY2Fubm90IGFzc29jaWF0ZSBhIHBoeXNpY2FsIGxvY2F0aW9uIHdp dGguIEZvciBleGFtcGxlLCBhIExJUw0KPiBpbg0KPiA+IGFuDQo+ID4gPiA+IGVudGVycHJpc2Us IHdoZXJlIHRoYXQgZW50ZXJwcmlzZSBzdXBwb3J0cyBWUE4gYWNjZXNzLCBzaG91bGQga25vdw0K PiA+IG9yDQo+ID4gPiBiZQ0KPiA+ID4gPiBhYmxlIHRvIGRldGVybWluZSB0aGF0IHRoZSBjbGll bnQgcmVxdWVzdHMgYXJlIGFycml2aW5nIG92ZXIgYSBWUE4NCj4gPiA+IGZyb20NCj4gPiA+ID4g YW4gZW5kIHBvaW50IHdob3NlIGxvY2F0aW9uIGNhbm5vdCBiZSBkZXRlcm1pbmVkLiBUaGUgSEVM RA0KPiByZXNwb25zZQ0KPiA+ID4gPiBzaG91bGQgaW5kaWNhdGUgdGhhdCBsb2NhdGlvbiBjYW5u b3QgYmUgcHJvdmlkZWQuDQo+ID4gPiA+DQo+ID4gPiA+IENoZWVycywNCj4gPiA+ID4gTWFydGlu DQo+ID4gPiA+DQo+ID4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+IEZy b206IFJpY2hhcmQgQmFybmVzIFttYWlsdG86cmJhcm5lc0BiYm4uY29tXQ0KPiA+ID4gPiBTZW50 OiBUaHVyc2RheSwgMSBOb3ZlbWJlciAyMDA3IDE6MjIgQU0NCj4gPiA+ID4gVG86IFN0YXJrLCBC YXJiYXJhOyBFQ1JJVA0KPiA+ID4gPiBTdWJqZWN0OiBbRWNyaXRdIFJlOiBbR2VvcHJpdl0gVXNl IG9mIElQIGFkZHJlc3MgYXMgYW5pZGVudGlmaWVyDQo+ID4gPiA+IGluZHJhZnQtaWV0Zi1nZW9w cml2LWh0dHAtbG9jYXRpb24tZGVsaXZlcnkNCj4gPiA+ID4NCj4gPiA+ID4gUmlnaHQsIEkgdGhp bmsgd2hhdCdzIG5lZWRlZCBpcyBtb3JlIGEgY2F2ZWF0IHRoYXQgSEVMRCBwcm92aWRlcw0KPiB0 aGUNCj4gPiA+ID4gbG9jYXRpb24gb2YgdGhlIHNvdXJjZSBJUCBhZGRyZXNzIGluIHRoZSBJUCBo ZWFkZXIgb2YgdGhlIHJlcXVlc3QNCj4gLS0NCj4gPiA+ID4gd2hhdGV2ZXIgdGhhdCBtYXkgYmUu DQo+ID4gPiA+DQo+ID4gPiA+IC0tUmljaGFyZA0KPiA+ID4gPg0KPiA+ID4gPg0KPiA+ID4gPg0K PiA+ID4gPiBTdGFyaywgQmFyYmFyYSB3cm90ZToNCj4gPiA+ID4gPiBIb3cgaXMgYSBjbGllbnQg c3VwcG9zZWQgdG8ga25vdyB3aGV0aGVyIGEgIlZQTiwgTkFUIG9yIG90aGVyIElQDQo+ID4gPiA+ IGFkZHJlc3MNCj4gPiA+ID4gPiBtb2RpZmljYXRpb24gZXhpc3RzIGJldHdlZW4gdGhlIGNsaWVu dCBhbmQgdGhlIHNlcnZlciB3aGljaA0KPiBjb3VsZA0KPiA+ID4gPiA+IHByb2R1Y2UgaW5jb3Jy ZWN0IGxvY2F0aW9uIj8gT25lIG9mIHRoZSBiZXN0IHVzZXMgb2YgSEVMRCBpcyB0aGUNCj4gPiA+ IGNhc2UNCj4gPiA+ID4gPiB3aGVyZSB0aGVyZSBpcyBhIE5BVCAoYW5kIHRoZSBib3ggd2l0aCB0 aGUgTkFUIGlzIGxvY2F0aW9uDQo+ID4gdW5hd2FyZSkuDQo+ID4gPiA+IEZvcg0KPiA+ID4gPiA+ IGxhbmRsaW5lIGJyb2FkYmFuZCBzZXJ2aWNlcywgdGhpcyBOQVQgZXhpc3RzLCBidXQgZG9lc24n dA0KPiBwcm9kdWNlDQo+ID4gYW4NCj4gPiA+ID4gPiBpbmNvcnJlY3QgbG9jYXRpb24uIFNvIHRo aXMgTkFUIGlzIG9rLiBIb3cgY2FuIHlvdSBkaXN0aW5ndWlzaA0KPiA+ID4gYmV0d2Vlbg0KPiA+ ID4gPiBhDQo+ID4gPiA+ID4gTkFUIHRoYXQgcHJvZHVjZXMgYW4gaW5jb3JyZWN0IGxvY2F0aW9u LCB2cy4gb25lIHRoYXQgcHJvZHVjZXMgYQ0KPiA+ID4gPiBjb3JyZWN0DQo+ID4gPiA+ID4gbG9j YXRpb24/DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGUgVlBOIGNvdWxkIGJlIG9yaWdpbmF0ZWQg b3V0IG9mIHRoZSByb3V0ZXIsIGFuZCBub3QgdGhlDQo+IGNsaWVudC4NCj4gPiA+IEhvdw0KPiA+ ID4gPiA+IHdvdWxkIHRoZSBjbGllbnQga25vdyB0aGlzIFZQTiBldmVuIGV4aXN0cz8NCj4gPiA+ ID4gPg0KPiA+ID4gPiA+IFVubGVzcyB5b3UgY2FuIHRlbGwgbWUgdGhlIGxvZ2ljIHRvIHVzZSB0 byBpbXBsZW1lbnQgdGhpcw0KPiBwcm9wb3NlZA0KPiA+ID4gPiA+IHJlcXVpcmVtZW50LCBJIGNh bid0IHN1cHBvcnQgaXQuDQo+ID4gPiA+ID4gQmFyYmFyYQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiBCcmlhbiBSb3NlbiBb bWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0XQ0KPiA+ID4gPiA+IFNlbnQ6IFdlZG5lc2RheSwgT2N0 b2JlciAzMSwgMjAwNyA4OjUxIEFNDQo+ID4gPiA+ID4gVG86IGdlb3ByaXZAaWV0Zi5vcmcNCj4g PiA+ID4gPiBTdWJqZWN0OiBbR2VvcHJpdl0gVXNlIG9mIElQIGFkZHJlc3MgYXMgYW4gaWRlbnRp Zmllcg0KPiA+ID4gPiA+IGluZHJhZnQtaWV0Zi1nZW9wcml2LWh0dHAtbG9jYXRpb24tZGVsaXZl cnkNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEluIHRoZSBsb25nIHNldCBvZiBkaXNjdXNzaW9ucyB0 aGF0IGhhdmUgbGVhZCB0byBIRUxELCBvbmUgb2YNCj4gdGhlDQo+ID4gPiA+ID4gYmlnZ2VzdA0K PiA+ID4gPiA+IGNvbmNlcm5zIGEgZmV3IG9mIHVzIGhhdmUgaGFkIGlzIHRoZSBwcm9ibGVtIHRo YW4gYW4gSVAgYWRkcmVzcw0KPiA+IG1heQ0KPiA+ID4gPiBub3QNCj4gPiA+ID4gPiBiZSBhDQo+ ID4gPiA+ID4gZ29vZCBpZGVudGlmaWVyIGZvciBkZXRlcm1pbmluZyB0aGUgbG9jYXRpb24gb2Yg dGhlIGNsaWVudC4NCj4gVGhlcmUNCj4gPiA+IGlzDQo+ID4gPiA+IGENCj4gPiA+ID4gPiBkcmFm dCB0aGF0IGRlc2NyaWJlcyBhbHRlcm5hdGUgaWRlbnRpZmllcnMuICBIb3dldmVyLCB0aGVyZSBp cw0KPiBubw0KPiA+ID4gPiA+IGRpc2N1c3Npb24NCj4gPiA+ID4gPiBpbiB0aGUgcHJlc2VudCBk cmFmdCBvZiB0aGUgYmFzZSBwcm90b2NvbCBvbiB0aGVzZSBpc3N1ZXMuDQo+ID4gPiA+ID4NCj4g PiA+ID4gPiBJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSB0aGF0IHdlIGFkZCB0ZXh0IHNvbWV0aGlu ZyBsaWtlOg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVXNlIG9mIEhFTEQgaXMgc3ViamVjdCB0byB0 aGUgdmlhYmlsaXR5IG9mIHRoZSBpZGVudGlmaWVyIHVzZWQNCj4gYnkNCj4gPiA+IHRoZQ0KPiA+ ID4gPiA+IExJUyB0bw0KPiA+ID4gPiA+IGRldGVybWluZSBsb2NhdGlvbi4gIFRoaXMgZG9jdW1l bnQgZGVzY3JpYmVzIHRoZSB1c2Ugb2YgdGhlIElQDQo+ID4gPiBhZGRyZXNzDQo+ID4gPiA+ID4g b2YNCj4gPiA+ID4gPiB0aGUgY2xpZW50IGFzIHRoZSBpZGVudGlmaWVyLiAgV2hlbiBhIE5BVCwg VlBOIG9yIG90aGVyIGZvcm1zIG9mDQo+ID4gPiA+IGFkZHJlc3MNCj4gPiA+ID4gPiBtb2RpZmlj YXRpb24gb2NjdXIgYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgc2VydmVyLCB0aGUNCj4gbG9j YXRpb24NCj4gPiA+ID4gPiByZXR1cm5lZA0KPiA+ID4gPiA+IG1heSBiZSBpbmFjY3VyYXRlLiAg VGhpcyBpcyBub3QgYWx3YXlzIHRoZSBjYXNlLiAgRm9yIGV4YW1wbGUsIGENCj4gPiBOQVQNCj4g PiA+ID4gPiB1c2VkIGluDQo+ID4gPiA+ID4gYSByZXNpZGVudGlhbCBsb2NhbCBhcmVhIG5ldHdv cmsgaXMgdHlwaWNhbGx5IG5vdCBhIHByb2JsZW0sDQo+ID4gYmVjYXVzZQ0KPiA+ID4gPiB0aGUN Cj4gPiA+ID4gPiBleHRlcm5hbCBJUCBhZGRyZXNzIHVzZWQgb24gdGhlIFdBTiBzaWRlIG9mIHRo ZSBOQVQgaXMgaW4gZmFjdA0KPiB0aGUNCj4gPiA+ID4gcmlnaHQNCj4gPiA+ID4gPiBpZGVudGlm aWVyIGZvciBhbGwgb2YgdGhlIGRldmljZXMgaW4gdGhlIHJlc2lkZW5jZS4gIE9uIHRoZQ0KPiBv dGhlcg0KPiA+ID4gPiBoYW5kLA0KPiA+ID4gPiA+IGlmDQo+ID4gPiA+ID4gdGhlcmUgaXMgYSBW UE4gYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgc2VydmVyLCBmb3IgZXhhbXBsZQ0KPiBmb3IN Cj4gPiBhDQo+ID4gPiA+ID4gdGVsZXdvcmtlciwgdGhlbiB0aGUgYWRkcmVzcyBzZWVuIGJ5IHRo ZSBzZXJ2ZXIgbWF5IG5vdCBiZSB0aGUNCj4gPiByaWdodA0KPiA+ID4gPiA+IGFkZHJlc3MNCj4g PiA+ID4gPiB0byBpZGVudGlmeSB0aGUgbG9jYXRpb24gb2YgdGhlIGNsaWVudC4gIFdoZXJlIGEg VlBOIGlzDQo+IGRlcGxveWVkLA0KPiA+ID4gPiA+IGNsaWVudHMNCj4gPiA+ID4gPiBvZnRlbiBo YXZlIHRoZSBhYmlsaXR5IHRvIGJ5cGFzcyB0aGUgVlBOIGZvciBhIHRyYW5zYWN0aW9uIGxpa2UN Cj4gPiA+IEhFTEQuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBIRUxEIENsaWVudHMgTVVTVCBOT1Qg c2VuZCBIRUxEIHJlcXVlc3RzIHdoZXJlIElQIGFkZHJlc3MgaXMgdGhlDQo+ID4gPiA+ID4gaWRl bnRpZmllcg0KPiA+ID4gPiA+IGFuZCBhIFZQTiwgTkFUIG9yIG90aGVyIElQIGFkZHJlc3MgbW9k aWZpY2F0aW9uIGV4aXN0cyBiZXR3ZWVuDQo+IHRoZQ0KPiA+ID4gPiA+IGNsaWVudA0KPiA+ID4g PiA+IGFuZCB0aGUgc2VydmVyIHdoaWNoIGNvdWxkIHByb2R1Y2UgaW5jb3JyZWN0IGxvY2F0aW9u LiAgSEVMRA0KPiBNVVNUDQo+ID4gPiBOT1QNCj4gPiA+ID4gYmUNCj4gPiA+ID4gPiBkZXBsb3ll ZCBpbiBuZXR3b3JrcyB3aGVyZSB0aGUgY2xpZW50IGNhbm5vdCBjb21wbHkgcmVhc29uYWJseQ0K PiA+ID4gPiByZWxpYWJseQ0KPiA+ID4gPiA+IHdpdGgNCj4gPiA+ID4gPiB0aGF0IHJlcXVpcmVt ZW50Lg0KPiA+ID4gPiA+DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gRWNyaXQgbWFpbGluZyBsaXN0DQo+IEVjcml0QGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Vjcml0DQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0 aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQs IHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91 IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1t ZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBv Zg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQpbbWYyXQ0K --===============1869830443== 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 --===============1869830443==-- From ecrit-bounces@ietf.org Fri Nov 02 15:34:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io2He-0004RZ-H0; Fri, 02 Nov 2007 15:34:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io2Hd-0004RG-Jz for ecrit@ietf.org; Fri, 02 Nov 2007 15:34:21 -0400 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io2HX-0003VZ-Ex for ecrit@ietf.org; Fri, 02 Nov 2007 15:34:21 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JQW001JM90NHW@usaga01-in.huawei.com> for ecrit@ietf.org; Fri, 02 Nov 2007 12:33:59 -0700 (PDT) Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0JQW004C190MNC@usaga01-in.huawei.com> for ecrit@ietf.org; Fri, 02 Nov 2007 12:33:59 -0700 (PDT) Date: Fri, 02 Nov 2007 14:33:20 -0500 From: Spencer Dawkins Subject: Re: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier indraft-ietf-geopriv-http-location-delivery To: ECRIT Message-id: <10d201c81d87$39eb94f0$6401a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Outlook Express 6.00.2900.3138 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <7582BC68E4994F4ABF0BD4723975C3FA06376AAE@crexc41p> <031201c81c90$d66f8400$1d69fe90@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA06376AD7@crexc41p> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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, Barbara and Martin, My question may be more appropriate for the ADs, but as far as I know, there is no prohibition about putting MUST and SHOULD language governing device/network behavior in standards-track documents. Putting this information in a separate document might be the right thing to do, but isn't required by our standards process. > HELD is a protocol, purely and simply. It's not a BCP and cannot and > should not attempt to use MUST and SHOULD language around behavior of > devices and networks that use the protocol, outside of requirements > directly related to formatting of the protocol messages. The first example I thought of, "TCP Congestion Control", ftp://ftp.rfc-editor.org/in-notes/rfc2581.txt, is a Proposed Standard and includes both MUSTs and SHOULDs governing device behavior with no protocol message formatting specification at all. I'm not a routing expert, but I'd be surprised if I couldn't find routing standards-track documents that also include 2119 normative language about router behavior. I'm also not a security expert, but I'd expect SecDir reviewers to need this information to evaluate security considerations for HELD. Thanks, Spencer _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Fri Nov 02 15:37:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io2Ke-0006El-3q; Fri, 02 Nov 2007 15:37:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io2Kc-0006ER-JV for ecrit@ietf.org; Fri, 02 Nov 2007 15:37:26 -0400 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Io2KW-0003cp-9d for ecrit@ietf.org; Fri, 02 Nov 2007 15:37:26 -0400 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Io2KI-0003uG-Fs; Fri, 02 Nov 2007 14:37:07 -0500 From: "Brian Rosen" To: "'Thomson, Martin'" , "'Stark, Barbara'" , "'Dawson, Martin'" , "'Richard Barnes'" , "'ECRIT'" References: <7582BC68E4994F4ABF0BD4723975C3FA06376AAE@crexc41p><031201c81c90$d66f8400$1d69fe90@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA06376AD7@crexc41p> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier indraft-ietf-geopriv-http-location-delivery Date: Fri, 2 Nov 2007 15:37:13 -0400 Message-ID: <01da01c81d87$c75d4c70$2fea0446@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.3198 Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYA== In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: 9178bae9f85419fdc08e9f2c86e345d0 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 Chair/AD opinion please I will write a BCP if we need it. I think that would be silly, and the protocol document is the appropriate place for documenting deployment concerns for the protocol. Brian > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > Sent: Thursday, November 01, 2007 5:32 PM > To: Stark, Barbara; Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier > indraft-ietf-geopriv-http-location-delivery > > I have to strongly agree with Barbara. If -phone-bcp isn't the right > place for these recommendations then someone can write another BCP. > > > -----Original Message----- > > From: Stark, Barbara [mailto:bs7652@att.com] > > Sent: Friday, 2 November 2007 1:39 AM > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > HELD is a protocol, purely and simply. It's not a BCP and cannot and > > should not attempt to use MUST and SHOULD language around behavior of > > devices and networks that use the protocol, outside of requirements > > directly related to formatting of the protocol messages. > > Http-location-delivery MUST NOT contain normative language that attempts > > to restrict the environment where HELD may be used. I have no problem > > with including a discussion of these issues in http-location-delivery. > > But if you want something stronger, it needs to be a BCP. Since phonebcp > > only applies to use for emergency services, then I guess you'd need a > > more generic BCP out of geopriv. > > > > Since such a HELD BCP (from geopriv) may or may not be recognized by > > device manufacturers, I'd recommend making sure that phonebcp does have > > what's needed, as far as use of HELD for emergency services. > > Barbara > > > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Thursday, November 01, 2007 10:10 AM > > To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > The text belongs in the HELD document because it has nothing to do with > > emergency calls. It affects all uses of HELD. > > > > I don't have a problem with expanding text in -phonebcp > > > > Brian > > > > > -----Original Message----- > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > Sent: Thursday, November 01, 2007 9:58 AM > > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > I have no problem with your proposed verbiage characterizing the > > > problem. > > > > > > I think that requirements on end devices using HELD and access > > networks > > > providing HELD responses is a phonebcp issue, and not > > > http-location-delivery. > > > > > > Within phonebcp, I think that enterprise networks (that are not able > > to > > > control the capabilities of devices attaching to them) are already > > > included in the definition of access network. That seems to currently > > be > > > implicit, but perhaps it should be explicit. Then all requirements > > that > > > apply to access networks will explicitly apply to such enterprise > > > networks. I'm not sure I see what such enterprise networks need to do > > > different than public access networks. You already have some VPN and > > NAT > > > requirements there: > > > AN-14 Network administrators MUST take care in assigning IP > > addresses > > > such that VPN address assignments can be distinguished from local > > > devices (by subnet choice, for example), and LISs should not > > attempt > > > to provide location to addresses that arrive via VPN connections. > > > > > > AN-15 Placement of NAT devices should consider the effect of the > > NAT > > > on the LCP. > > > > > > The device location update when the device has a VPN established that > > > doesn't allow split tunneling is definitely a gap. I think it could be > > > solved with some HELD extensions (which is a geopriv issue). That is, > > I > > > think that if we allow the initial (pre-VPN) request to also negotiate > > > identification and authentication for future updates, that we could > > > solve the update problem. > > > > > > The intermediary SOHO (small office/home office) router that sets up > > the > > > non-split tunneling VPN on behalf of its LAN needs to be required (in > > > phonebcp) to act as the LIS for all devices in its LAN. That's part of > > > the additional requirements I'm working on providing you (Brian). > > > Barbara > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, November 01, 2007 6:16 AM > > > To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > That's helpful. > > > > > > I don't think it's sufficient. My example, hardware VPN/tunnel > > > mechanisms > > > cannot be permitted, has to be spelled out. Also, phonebcp recommends > > > location update at call time. We haven't worked out this detail, but > > I > > > think we want to at least recommend that a mobile device send routing > > > location as a value, and dispatch location as a reference (where > > > needed), > > > just to avoid the repeated dereference by all call routing elements. > > > That > > > means you would want to do the HELD LCP operation at call time. > > > > > > You need to discuss enterprise networks behind access networks that > > > provide > > > HELD, or try to use HELD within an enterprise network. > > > > > > I think it's hard to think through ALL the instances where an IP > > address > > > isn't reliable as an identifier to be used for location, which is why > > I > > > phrased my proposed text the way I did. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > Sent: Thursday, November 01, 2007 5:42 AM > > > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > Oh, fine, I'll try to be helpful, then. > > > > I definitely agree with having the problem mentioned and properly > > > > characterized. But when we write requirements, I want to be sure > > that > > > > the requirements are implementable. > > > > > > > > Certainly, end devices must do location configuration before > > > > establishing a VPN. Once an end device has established a VPN, it > > must > > > > not do any LIS discovery or HELD queries over the VPN connection. > > > > > > > > The Access Network, however, needs to have the requirement that its > > > LIS > > > > be able to know which subnets of IP addresses are supplied to > > devices > > > > coming over VPN access, or have been provided to a company that > > > provides > > > > its own LIS. That is, such blocks of IP addresses need to be > > > > configurable in the LIS. Then there's the requirement that the LIS > > > must > > > > not provide location to these IP addresses. > > > > > > > > The access network (access provider + ISP) also has a responsibility > > > not > > > > to place a LIS on the core side of any NAT that is employed in the > > > > access network. Note that this isn't meant to apply to home router > > > NATs, > > > > since those aren't part of the access network, according to the > > > > definition of access network. > > > > > > > > I really think that the access network has greater ability, and > > > > therefore greater responsibility, to minimize the occurrence of > > > problems > > > > due to VPNs and NATs. > > > > > > > > As we discussed (Brian and I), I'm going to try to suggest a way to > > > > better include in phonebcp requirements for routers employed in > > "small > > > > areas". One of the requirements we need for these, is that they MUST > > > act > > > > as the LIS for LAN-side devices, when they have VPN connections to > > the > > > > WAN. > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, November 01, 2007 4:03 AM > > > > To: 'Dawson, Martin'; 'Richard Barnes'; Stark, Barbara; 'ECRIT' > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address asanidentifier > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > I think the problem that Barbara points out is precisely the problem > > > in > > > > deploying HELD. Claiming that a problem can't be solved, and > > > therefore > > > > should not be mentioned is, uh, ?unhelpful? Having the "caveat" > > > instead > > > > of > > > > a deployment recommendation understates the problem. While it is > > > > possible > > > > to deploy HELD so that it almost always works, it will take a lot of > > > > attention by a lot of entities to make that happen. For example, if > > > > HELD is > > > > deployed, no non-bypassable VPNs can be permitted. The protocol > > > > document > > > > should be very clear about what it takes to make HELD work. > > > > > > > > I have no problem including text that covers what devices and LIS's > > > need > > > > to > > > > do, as long as it was noted that it won't always be sufficient. We > > > > might > > > > also include text on how enterprise networks should be configured. > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > Sent: Wednesday, October 31, 2007 11:58 AM > > > > > To: Richard Barnes; Stark, Barbara; ECRIT > > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > > asanidentifier > > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > I think that the "device" requirement at most should be that > > efforts > > > > > should be made to ensure that the LIS is discovered and used on > > the > > > > > physical access network and not via any VPN tunnel. > > > > > > > > > > Perhaps more importantly, there should be a complementary > > > requirement > > > > on > > > > > the LIS that it not attempt to provide location for an IP address > > > that > > > > > it cannot associate a physical location with. For example, a LIS > > in > > > an > > > > > enterprise, where that enterprise supports VPN access, should know > > > or > > > > be > > > > > able to determine that the client requests are arriving over a VPN > > > > from > > > > > an end point whose location cannot be determined. The HELD > > response > > > > > should indicate that location cannot be provided. > > > > > > > > > > Cheers, > > > > > Martin > > > > > > > > > > -----Original Message----- > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > Sent: Thursday, 1 November 2007 1:22 AM > > > > > To: Stark, Barbara; ECRIT > > > > > Subject: [Ecrit] Re: [Geopriv] Use of IP address as anidentifier > > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > Right, I think what's needed is more a caveat that HELD provides > > the > > > > > location of the source IP address in the IP header of the request > > -- > > > > > whatever that may be. > > > > > > > > > > --Richard > > > > > > > > > > > > > > > > > > > > Stark, Barbara wrote: > > > > > > How is a client supposed to know whether a "VPN, NAT or other IP > > > > > address > > > > > > modification exists between the client and the server which > > could > > > > > > produce incorrect location"? One of the best uses of HELD is the > > > > case > > > > > > where there is a NAT (and the box with the NAT is location > > > unaware). > > > > > For > > > > > > landline broadband services, this NAT exists, but doesn't > > produce > > > an > > > > > > incorrect location. So this NAT is ok. How can you distinguish > > > > between > > > > > a > > > > > > NAT that produces an incorrect location, vs. one that produces a > > > > > correct > > > > > > location? > > > > > > > > > > > > The VPN could be originated out of the router, and not the > > client. > > > > How > > > > > > would the client know this VPN even exists? > > > > > > > > > > > > Unless you can tell me the logic to use to implement this > > proposed > > > > > > requirement, I can't support it. > > > > > > Barbara > > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Wednesday, October 31, 2007 8:51 AM > > > > > > To: geopriv@ietf.org > > > > > > Subject: [Geopriv] Use of IP address as an identifier > > > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > > > In the long set of discussions that have lead to HELD, one of > > the > > > > > > biggest > > > > > > concerns a few of us have had is the problem than an IP address > > > may > > > > > not > > > > > > be a > > > > > > good identifier for determining the location of the client. > > There > > > > is > > > > > a > > > > > > draft that describes alternate identifiers. However, there is > > no > > > > > > discussion > > > > > > in the present draft of the base protocol on these issues. > > > > > > > > > > > > I would like to propose that we add text something like: > > > > > > > > > > > > Use of HELD is subject to the viability of the identifier used > > by > > > > the > > > > > > LIS to > > > > > > determine location. This document describes the use of the IP > > > > address > > > > > > of > > > > > > the client as the identifier. When a NAT, VPN or other forms of > > > > > address > > > > > > modification occur between the client and the server, the > > location > > > > > > returned > > > > > > may be inaccurate. This is not always the case. For example, a > > > NAT > > > > > > used in > > > > > > a residential local area network is typically not a problem, > > > because > > > > > the > > > > > > external IP address used on the WAN side of the NAT is in fact > > the > > > > > right > > > > > > identifier for all of the devices in the residence. On the > > other > > > > > hand, > > > > > > if > > > > > > there is a VPN between the client and the server, for example > > for > > > a > > > > > > teleworker, then the address seen by the server may not be the > > > right > > > > > > address > > > > > > to identify the location of the client. Where a VPN is > > deployed, > > > > > > clients > > > > > > often have the ability to bypass the VPN for a transaction like > > > > HELD. > > > > > > > > > > > > HELD Clients MUST NOT send HELD requests where IP address is the > > > > > > identifier > > > > > > and a VPN, NAT or other IP address modification exists between > > the > > > > > > client > > > > > > and the server which could produce incorrect location. HELD > > MUST > > > > NOT > > > > > be > > > > > > deployed in networks where the client cannot comply reasonably > > > > > reliably > > > > > > with > > > > > > that requirement. > > > > > > > > > > > > _______________________________________________ > > 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 Nov 02 16:53:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io3W2-0005Om-0e; Fri, 02 Nov 2007 16:53:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Io3W0-0005Mn-Sr for ecrit@ietf.org; Fri, 02 Nov 2007 16:53:16 -0400 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Io3Vx-0006mw-E6 for ecrit@ietf.org; Fri, 02 Nov 2007 16:53:13 -0400 Received: from macmini1.cs.columbia.edu (macmini1.cs.columbia.edu [128.59.23.102]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lA2KrAqZ029564 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 2 Nov 2007 16:53:10 -0400 (EDT) From: Henning Schulzrinne To: Spencer Dawkins In-Reply-To: <10d201c81d87$39eb94f0$6401a8c0@china.huawei.com> Subject: Re: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier indraft-ietf-geopriv-http-location-delivery X-Priority: 3 References: <7582BC68E4994F4ABF0BD4723975C3FA06376AAE@crexc41p> <031201c81c90$d66f8400$1d69fe90@cis.neustar.com> <7582BC68E4994F4ABF0BD4723975C3FA06376AD7@crexc41p> <10d201c81d87$39eb94f0$6401a8c0@china.huawei.com> Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v912) Date: Fri, 2 Nov 2007 16:53:09 -0400 X-Mailer: Apple Mail (2.912) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 agree with Spencer. Based on previous experience, message/syntax-only documents are frowned upon. (We had to rewrite RPH, for example, largely because it was perceived as being too syntax-focused. RFC 3261 tries to provide a much more semantically-based description, compared to the syntax- focused RFC 2543). In other words, standards MUST describe semantics, not just syntax, and applicability, and SHOULD describe motivation and background where necessary and helpful to implementors. In my personal opinion, RFCs are meant to be useful to implementors and should be self-contained. Describing how to make something actually work (or where it might not work) is something that every implementor needs to know. I don't see a need for a separate BCP here. Henning On Nov 2, 2007, at 3:33 PM, Spencer Dawkins wrote: > Hi, Barbara and Martin, > > My question may be more appropriate for the ADs, but as far as I > know, there is no prohibition about putting MUST and SHOULD language > governing device/network behavior in standards-track documents. > > Putting this information in a separate document might be the right > thing to do, but isn't required by our standards process. > > >> HELD is a protocol, purely and simply. It's not a BCP and cannot and >> should not attempt to use MUST and SHOULD language around behavior of >> devices and networks that use the protocol, outside of requirements >> directly related to formatting of the protocol messages. > > The first example I thought of, "TCP Congestion Control", ftp://ftp.rfc-editor.org/in-notes/rfc2581.txt > , is a Proposed Standard and includes both MUSTs and SHOULDs > governing device behavior with no protocol message formatting > specification at all. > > I'm not a routing expert, but I'd be surprised if I couldn't find > routing standards-track documents that also include 2119 normative > language about router behavior. > > I'm also not a security expert, but I'd expect SecDir reviewers to > need this information to evaluate security considerations for HELD. > > Thanks, > > Spencer > > > _______________________________________________ > 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 Nov 03 14:11:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoNTQ-0004d0-Iq; Sat, 03 Nov 2007 14:11:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IoNTP-0004bF-3x for ecrit@ietf.org; Sat, 03 Nov 2007 14:11:55 -0400 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IoNTN-00026R-B9 for ecrit@ietf.org; Sat, 03 Nov 2007 14:11:54 -0400 X-SEF-Processed: 5_0_0_910__2007_11_03_13_22_13 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sat, 03 Nov 2007 13:22:13 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 3 Nov 2007 13:11:51 -0500 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 Subject: RE: [Ecrit] Re: [Geopriv] Use of IPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Date: Sat, 3 Nov 2007 13:11:46 -0500 Message-ID: In-Reply-To: <01da01c81d87$c75d4c70$2fea0446@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] Use of IPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYAAudC4w References: <7582BC68E4994F4ABF0BD4723975C3FA06376AAE@crexc41p><031201c81c90$d66f8400$1d69fe90@cis.neustar.com><7582BC68E4994F4ABF0BD4723975C3FA06376AD7@crexc41p> <01da01c81d87$c75d4c70$2fea0446@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Thomson, Martin" , "Stark, Barbara" , "Dawson, Martin" , "Richard Barnes" , "ECRIT" X-OriginalArrivalTime: 03 Nov 2007 18:11:51.0164 (UTC) FILETIME=[01C9D3C0:01C81E45] X-Spam-Score: 1.8 (+) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 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 Perhaps I am missing something here, but it seems to me that this not a=0D=0A= HELD problem so much as a service discovery problem, which from what I=0D=0A= am lead to believe can be just as problematic with DHCP when it is run=0D=0A= over VPNs. Consequently unless we are going to address that issue too, I=0D= =0Athink that AGAIN singling HELD out to address a generic problem is=0D=0A= totally inappropriate.=0D=0A=0D=0AA simple HELD-based LIS/relay-service add= ed to a home router will avoid=0D=0Athe issues that have been described by = Brian to the same degree that=0D=0Athey are avoided by DHCP. This is very e= asy to do and we have made this=0D=0Awork in OpenWRT running on a linksys h= ome-router. I am not keen to start=0D=0Adescribing these kinds of solutions= in the base HELD specification, a=0D=0ABCP is more appropriate, though a m= ention of care would seem reasonable.=0D=0A=0D=0ACheers=0D=0AJames=0D=0A=0D= =0A=0D=0A> -----Original Message-----=0D=0A> From: Brian Rosen [mailto:br@b= rianrosen.net]=0D=0A> Sent: Saturday, 3 November 2007 6:37 AM=0D=0A> To: Th= omson, Martin; 'Stark, Barbara'; Dawson, Martin; 'Richard=0D=0ABarnes';=0D=0A= > 'ECRIT'=0D=0A> Subject: RE: [Ecrit] Re: [Geopriv] Use of IPaddressasanide= ntifier=0D=0Aindraft-=0D=0A> ietf-geopriv-http-location-delivery=0D=0A>=20=0D= =0A> Chair/AD opinion please=0D=0A>=20=0D=0A> I will write a BCP if we need= it. I think that would be silly, and=0D=0Athe=0D=0A> protocol document is= the appropriate place for documenting deployment=0D=0A> concerns for the p= rotocol.=0D=0A>=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Original Message---= --=0D=0A> > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=0D=0A>= > Sent: Thursday, November 01, 2007 5:32 PM=0D=0A> > To: Stark, Barbara; B= rian Rosen; Dawson, Martin; Richard Barnes;=0D=0AECRIT=0D=0A> > Subject: RE= : [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier=0D=0A> > indraft-ie= tf-geopriv-http-location-delivery=0D=0A> >=0D=0A> > I have to strongly agre= e with Barbara. If -phone-bcp isn't the=0D=0Aright=0D=0A> > place for thes= e recommendations then someone can write another BCP.=0D=0A> >=0D=0A> > > -= ----Original Message-----=0D=0A> > > From: Stark, Barbara [mailto:bs7652@at= t.com]=0D=0A> > > Sent: Friday, 2 November 2007 1:39 AM=0D=0A> > > To: Bria= n Rosen; Dawson, Martin; Richard Barnes; ECRIT=0D=0A> > > Subject: RE: [Ecr= it] Re: [Geopriv] Use of IP addressasanidentifier=0D=0A> > > indraft-ietf-g= eopriv-http-location-delivery=0D=0A> > >=0D=0A> > > HELD is a protocol, pur= ely and simply. It's not a BCP and cannot=0D=0Aand=0D=0A> > > should not at= tempt to use MUST and SHOULD language around behavior=0D=0Aof=0D=0A> > > de= vices and networks that use the protocol, outside of=0D=0Arequirements=0D=0A= > > > directly related to formatting of the protocol messages.=0D=0A> > > H= ttp-location-delivery MUST NOT contain normative language that=0D=0A> attem= pts=0D=0A> > > to restrict the environment where HELD may be used. I have n= o=0D=0Aproblem=0D=0A> > > with including a discussion of these issues in=0D= =0Ahttp-location-delivery.=0D=0A> > > But if you want something stronger, i= t needs to be a BCP. Since=0D=0A> phonebcp=0D=0A> > > only applies to use f= or emergency services, then I guess you'd=0D=0Aneed a=0D=0A> > > more gener= ic BCP out of geopriv.=0D=0A> > >=0D=0A> > > Since such a HELD BCP (from ge= opriv) may or may not be recognized=0D=0Aby=0D=0A> > > device manufacturers= , I'd recommend making sure that phonebcp does=0D=0A> have=0D=0A> > > what'= s needed, as far as use of HELD for emergency services.=0D=0A> > > Barbara=0D= =0A> > >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Brian Rosen= [mailto:br@brianrosen.net]=0D=0A> > > Sent: Thursday, November 01, 2007 10= :10 AM=0D=0A> > > To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; '= ECRIT'=0D=0A> > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address=0D=0A= asanidentifier=0D=0A> > > indraft-ietf-geopriv-http-location-delivery=0D=0A= > > >=0D=0A> > > The text belongs in the HELD document because it has nothi= ng to do=0D=0A> with=0D=0A> > > emergency calls. It affects all uses of HE= LD.=0D=0A> > >=0D=0A> > > I don't have a problem with expanding text in -ph= onebcp=0D=0A> > >=0D=0A> > > Brian=0D=0A> > >=0D=0A> > > > -----Original Me= ssage-----=0D=0A> > > > From: Stark, Barbara [mailto:bs7652@att.com]=0D=0A>= > > > Sent: Thursday, November 01, 2007 9:58 AM=0D=0A> > > > To: Brian Ros= en; Dawson, Martin; Richard Barnes; ECRIT=0D=0A> > > > Subject: RE: [Ecrit]= Re: [Geopriv] Use of IP address=0D=0Aasanidentifier=0D=0A> > > > indraft-i= etf-geopriv-http-location-delivery=0D=0A> > > >=0D=0A> > > > I have no prob= lem with your proposed verbiage characterizing the=0D=0A> > > > problem.=0D= =0A> > > >=0D=0A> > > > I think that requirements on end devices using HELD= and access=0D=0A> > > networks=0D=0A> > > > providing HELD responses is a = phonebcp issue, and not=0D=0A> > > > http-location-delivery.=0D=0A> > > >=0D= =0A> > > > Within phonebcp, I think that enterprise networks (that are not=0D= =0Aable=0D=0A> > > to=0D=0A> > > > control the capabilities of devices atta= ching to them) are=0D=0Aalready=0D=0A> > > > included in the definition of = access network. That seems to=0D=0A> currently=0D=0A> > > be=0D=0A> > > > i= mplicit, but perhaps it should be explicit. Then all=0D=0Arequirements=0D=0A= > > > that=0D=0A> > > > apply to access networks will explicitly apply to s= uch=0D=0Aenterprise=0D=0A> > > > networks. I'm not sure I see what such ent= erprise networks need=0D=0Ato=0D=0A> do=0D=0A> > > > different than public = access networks. You already have some VPN=0D=0Aand=0D=0A> > > NAT=0D=0A> >= > > requirements there:=0D=0A> > > > AN-14 Network administrators MUST = take care in assigning IP=0D=0A> > > addresses=0D=0A> > > > such that VP= N address assignments can be distinguished from=0D=0Alocal=0D=0A> > > > = devices (by subnet choice, for example), and LISs should not=0D=0A> > > att= empt=0D=0A> > > > to provide location to addresses that arrive via VPN=0D= =0Aconnections.=0D=0A> > > >=0D=0A> > > > AN-15 Placement of NAT devices= should consider the effect of=0D=0Athe=0D=0A> > > NAT=0D=0A> > > > on t= he LCP.=0D=0A> > > >=0D=0A> > > > The device location update when the devic= e has a VPN established=0D=0A> that=0D=0A> > > > doesn't allow split tunnel= ing is definitely a gap. I think it=0D=0Acould=0D=0A> be=0D=0A> > > > solve= d with some HELD extensions (which is a geopriv issue).=0D=0AThat=0D=0A> is= ,=0D=0A> > > I=0D=0A> > > > think that if we allow the initial (pre-VPN) re= quest to also=0D=0A> negotiate=0D=0A> > > > identification and authenticati= on for future updates, that we=0D=0Acould=0D=0A> > > > solve the update pro= blem.=0D=0A> > > >=0D=0A> > > > The intermediary SOHO (small office/home of= fice) router that=0D=0Asets up=0D=0A> > > the=0D=0A> > > > non-split tunnel= ing VPN on behalf of its LAN needs to be=0D=0Arequired=0D=0A> (in=0D=0A> > = > > phonebcp) to act as the LIS for all devices in its LAN. That's=0D=0Apar= t=0D=0A> of=0D=0A> > > > the additional requirements I'm working on providi= ng you=0D=0A(Brian).=0D=0A> > > > Barbara=0D=0A> > > >=0D=0A> > > > -----Or= iginal Message-----=0D=0A> > > > From: Brian Rosen [mailto:br@brianrosen.ne= t]=0D=0A> > > > Sent: Thursday, November 01, 2007 6:16 AM=0D=0A> > > > To: = Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT'=0D=0A> > > > Su= bject: RE: [Ecrit] Re: [Geopriv] Use of IP address=0D=0Aasanidentifier=0D=0A= > > > > indraft-ietf-geopriv-http-location-delivery=0D=0A> > > >=0D=0A> > >= > That's helpful.=0D=0A> > > >=0D=0A> > > > I don't think it's sufficient.= My example, hardware VPN/tunnel=0D=0A> > > > mechanisms=0D=0A> > > > cann= ot be permitted, has to be spelled out. Also, phonebcp=0D=0A> recommends=0D= =0A> > > > location update at call time. We haven't worked out this=0D=0Ad= etail,=0D=0A> but=0D=0A> > > I=0D=0A> > > > think we want to at least recom= mend that a mobile device send=0D=0A> routing=0D=0A> > > > location as a va= lue, and dispatch location as a reference (where=0D=0A> > > > needed),=0D=0A= > > > > just to avoid the repeated dereference by all call routing=0D=0Aele= ments.=0D=0A> > > > That=0D=0A> > > > means you would want to do the HELD L= CP operation at call time.=0D=0A> > > >=0D=0A> > > > You need to discuss en= terprise networks behind access networks=0D=0Athat=0D=0A> > > > provide=0D=0A= > > > > HELD, or try to use HELD within an enterprise network.=0D=0A> > > >=0D= =0A> > > > I think it's hard to think through ALL the instances where an IP=0D= =0A> > > address=0D=0A> > > > isn't reliable as an identifier to be used fo= r location, which=0D=0Ais=0D=0A> why=0D=0A> > > I=0D=0A> > > > phrased my p= roposed text the way I did.=0D=0A> > > >=0D=0A> > > > Brian=0D=0A> > > >=0D= =0A> > > > > -----Original Message-----=0D=0A> > > > > From: Stark, Barbara= [mailto:bs7652@att.com]=0D=0A> > > > > Sent: Thursday, November 01, 2007 5= :42 AM=0D=0A> > > > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRI= T=0D=0A> > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address=0D=0A= > asanidentifier=0D=0A> > > > > indraft-ietf-geopriv-http-location-delivery=0D= =0A> > > > >=0D=0A> > > > > Oh, fine, I'll try to be helpful, then.=0D=0A> = > > > > I definitely agree with having the problem mentioned and=0D=0Aprope= rly=0D=0A> > > > > characterized. But when we write requirements, I want to= be=0D=0Asure=0D=0A> > > that=0D=0A> > > > > the requirements are implement= able.=0D=0A> > > > >=0D=0A> > > > > Certainly, end devices must do location= configuration before=0D=0A> > > > > establishing a VPN. Once an end device= has established a VPN,=0D=0Ait=0D=0A> > > must=0D=0A> > > > > not do any L= IS discovery or HELD queries over the VPN=0D=0Aconnection.=0D=0A> > > > >=0D= =0A> > > > > The Access Network, however, needs to have the requirement=0D=0A= that=0D=0A> its=0D=0A> > > > LIS=0D=0A> > > > > be able to know which subne= ts of IP addresses are supplied to=0D=0A> > > devices=0D=0A> > > > > coming= over VPN access, or have been provided to a company=0D=0Athat=0D=0A> > > >= provides=0D=0A> > > > > its own LIS. That is, such blocks of IP addresses = need to be=0D=0A> > > > > configurable in the LIS. Then there's the require= ment that the=0D=0ALIS=0D=0A> > > > must=0D=0A> > > > > not provide locatio= n to these IP addresses.=0D=0A> > > > >=0D=0A> > > > > The access network (= access provider + ISP) also has a=0D=0A> responsibility=0D=0A> > > > not=0D= =0A> > > > > to place a LIS on the core side of any NAT that is employed in=0D= =0Athe=0D=0A> > > > > access network. Note that this isn't meant to apply t= o home=0D=0Arouter=0D=0A> > > > NATs,=0D=0A> > > > > since those aren't par= t of the access network, according to=0D=0Athe=0D=0A> > > > > definition of= access network.=0D=0A> > > > >=0D=0A> > > > > I really think that the acce= ss network has greater ability,=0D=0Aand=0D=0A> > > > > therefore greater r= esponsibility, to minimize the occurrence=0D=0Aof=0D=0A> > > > problems=0D=0A= > > > > > due to VPNs and NATs.=0D=0A> > > > >=0D=0A> > > > > As we discuss= ed (Brian and I), I'm going to try to suggest a=0D=0Away=0D=0A> to=0D=0A> >= > > > better include in phonebcp requirements for routers employed=0D=0Ain=0D= =0A> > > "small=0D=0A> > > > > areas". One of the requirements we need for = these, is that=0D=0Athey=0D=0A> MUST=0D=0A> > > > act=0D=0A> > > > > as the= LIS for LAN-side devices, when they have VPN=0D=0Aconnections to=0D=0A> > = > the=0D=0A> > > > > WAN.=0D=0A> > > > > Barbara=0D=0A> > > > >=0D=0A> > > = > > -----Original Message-----=0D=0A> > > > > From: Brian Rosen [mailto:br@= brianrosen.net]=0D=0A> > > > > Sent: Thursday, November 01, 2007 4:03 AM=0D= =0A> > > > > To: 'Dawson, Martin'; 'Richard Barnes'; Stark, Barbara;=0D=0A'= ECRIT'=0D=0A> > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address=0D= =0A> asanidentifier=0D=0A> > > > > indraft-ietf-geopriv-http-location-deliv= ery=0D=0A> > > > >=0D=0A> > > > > I think the problem that Barbara points o= ut is precisely the=0D=0A> problem=0D=0A> > > > in=0D=0A> > > > > deploying= HELD. Claiming that a problem can't be solved, and=0D=0A> > > > therefore=0D= =0A> > > > > should not be mentioned is, uh, =3Funhelpful=3F Having the=0D= =0A"caveat"=0D=0A> > > > instead=0D=0A> > > > > of=0D=0A> > > > > a deploym= ent recommendation understates the problem. While it=0D=0Ais=0D=0A> > > > = > possible=0D=0A> > > > > to deploy HELD so that it almost always works, it= will take a=0D=0Alot=0D=0A> of=0D=0A> > > > > attention by a lot of entiti= es to make that happen. For=0D=0Aexample,=0D=0A> if=0D=0A> > > > > HELD is=0D= =0A> > > > > deployed, no non-bypassable VPNs can be permitted. The=0D=0Ap= rotocol=0D=0A> > > > > document=0D=0A> > > > > should be very clear about w= hat it takes to make HELD work.=0D=0A> > > > >=0D=0A> > > > > I have no pro= blem including text that covers what devices and=0D=0A> LIS's=0D=0A> > > > = need=0D=0A> > > > > to=0D=0A> > > > > do, as long as it was noted that it w= on't always be=0D=0Asufficient.=0D=0A> We=0D=0A> > > > > might=0D=0A> > > >= > also include text on how enterprise networks should be=0D=0Aconfigured.=0D= =0A> > > > >=0D=0A> > > > > Brian=0D=0A> > > > >=0D=0A> > > > >=0D=0A> > > = > > > -----Original Message-----=0D=0A> > > > > > From: Dawson, Martin [mai= lto:Martin.Dawson@andrew.com]=0D=0A> > > > > > Sent: Wednesday, October 31,= 2007 11:58 AM=0D=0A> > > > > > To: Richard Barnes; Stark, Barbara; ECRIT=0D= =0A> > > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address=0D=0A> = > > asanidentifier=0D=0A> > > > > > indraft-ietf-geopriv-http-location-deli= very=0D=0A> > > > > >=0D=0A> > > > > > I think that the "device" requiremen= t at most should be that=0D=0A> > > efforts=0D=0A> > > > > > should be made= to ensure that the LIS is discovered and used=0D=0Aon=0D=0A> > > the=0D=0A= > > > > > > physical access network and not via any VPN tunnel.=0D=0A> > > = > > >=0D=0A> > > > > > Perhaps more importantly, there should be a compleme= ntary=0D=0A> > > > requirement=0D=0A> > > > > on=0D=0A> > > > > > the LIS t= hat it not attempt to provide location for an IP=0D=0A> address=0D=0A> > > = > that=0D=0A> > > > > > it cannot associate a physical location with. For e= xample, a=0D=0ALIS=0D=0A> > > in=0D=0A> > > > an=0D=0A> > > > > > enterpris= e, where that enterprise supports VPN access,=0D=0Ashould=0D=0A> know=0D=0A= > > > > or=0D=0A> > > > > be=0D=0A> > > > > > able to determine that the cl= ient requests are arriving over=0D=0Aa=0D=0A> VPN=0D=0A> > > > > from=0D=0A= > > > > > > an end point whose location cannot be determined. The HELD=0D=0A= > > > response=0D=0A> > > > > > should indicate that location cannot be pro= vided.=0D=0A> > > > > >=0D=0A> > > > > > Cheers,=0D=0A> > > > > > Martin=0D= =0A> > > > > >=0D=0A> > > > > > -----Original Message-----=0D=0A> > > > > >= From: Richard Barnes [mailto:rbarnes@bbn.com]=0D=0A> > > > > > Sent: Thurs= day, 1 November 2007 1:22 AM=0D=0A> > > > > > To: Stark, Barbara; ECRIT=0D=0A= > > > > > > Subject: [Ecrit] Re: [Geopriv] Use of IP address as=0D=0Aaniden= tifier=0D=0A> > > > > > indraft-ietf-geopriv-http-location-delivery=0D=0A> = > > > > >=0D=0A> > > > > > Right, I think what's needed is more a caveat th= at HELD=0D=0Aprovides=0D=0A> > > the=0D=0A> > > > > > location of the sourc= e IP address in the IP header of the=0D=0A> request=0D=0A> > > --=0D=0A> > = > > > > whatever that may be.=0D=0A> > > > > >=0D=0A> > > > > > --Richard=0D= =0A> > > > > >=0D=0A> > > > > >=0D=0A> > > > > >=0D=0A> > > > > > Stark, Ba= rbara wrote:=0D=0A> > > > > > > How is a client supposed to know whether a = "VPN, NAT or=0D=0Aother=0D=0A> IP=0D=0A> > > > > > address=0D=0A> > > > > >= > modification exists between the client and the server=0D=0Awhich=0D=0A> = > > could=0D=0A> > > > > > > produce incorrect location"=3F One of the best= uses of HELD=0D=0Ais=0D=0A> the=0D=0A> > > > > case=0D=0A> > > > > > > whe= re there is a NAT (and the box with the NAT is location=0D=0A> > > > unawar= e).=0D=0A> > > > > > For=0D=0A> > > > > > > landline broadband services, th= is NAT exists, but doesn't=0D=0A> > > produce=0D=0A> > > > an=0D=0A> > > > = > > > incorrect location. So this NAT is ok. How can you=0D=0Adistinguish=0D= =0A> > > > > between=0D=0A> > > > > > a=0D=0A> > > > > > > NAT that produce= s an incorrect location, vs. one that=0D=0Aproduces=0D=0A> a=0D=0A> > > > >= > correct=0D=0A> > > > > > > location=3F=0D=0A> > > > > > >=0D=0A> > > > >= > > The VPN could be originated out of the router, and not the=0D=0A> > > = client.=0D=0A> > > > > How=0D=0A> > > > > > > would the client know this VP= N even exists=3F=0D=0A> > > > > > >=0D=0A> > > > > > > Unless you can tell = me the logic to use to implement this=0D=0A> > > proposed=0D=0A> > > > > > = > requirement, I can't support it.=0D=0A> > > > > > > Barbara=0D=0A> > > > = > > >=0D=0A> > > > > > > -----Original Message-----=0D=0A> > > > > > > From= : Brian Rosen [mailto:br@brianrosen.net]=0D=0A> > > > > > > Sent: Wednesday= , October 31, 2007 8:51 AM=0D=0A> > > > > > > To: geopriv@ietf.org=0D=0A> >= > > > > > Subject: [Geopriv] Use of IP address as an identifier=0D=0A> > >= > > > > indraft-ietf-geopriv-http-location-delivery=0D=0A> > > > > > >=0D=0A= > > > > > > > In the long set of discussions that have lead to HELD, one=0D= =0Aof=0D=0A> > > the=0D=0A> > > > > > > biggest=0D=0A> > > > > > > concerns= a few of us have had is the problem than an IP=0D=0A> address=0D=0A> > > >= may=0D=0A> > > > > > not=0D=0A> > > > > > > be a=0D=0A> > > > > > > good i= dentifier for determining the location of the=0D=0Aclient.=0D=0A> > > There=0D= =0A> > > > > is=0D=0A> > > > > > a=0D=0A> > > > > > > draft that describes = alternate identifiers. However,=0D=0Athere is=0D=0A> > > no=0D=0A> > > > >= > > discussion=0D=0A> > > > > > > in the present draft of the base protoco= l on these issues.=0D=0A> > > > > > >=0D=0A> > > > > > > I would like to pr= opose that we add text something like:=0D=0A> > > > > > >=0D=0A> > > > > > = > Use of HELD is subject to the viability of the identifier=0D=0Aused=0D=0A= > > > by=0D=0A> > > > > the=0D=0A> > > > > > > LIS to=0D=0A> > > > > > > de= termine location. This document describes the use of=0D=0Athe IP=0D=0A> > = > > > address=0D=0A> > > > > > > of=0D=0A> > > > > > > the client as the id= entifier. When a NAT, VPN or other=0D=0Aforms=0D=0A> of=0D=0A> > > > > > a= ddress=0D=0A> > > > > > > modification occur between the client and the ser= ver, the=0D=0A> > > location=0D=0A> > > > > > > returned=0D=0A> > > > > > >= may be inaccurate. This is not always the case. For=0D=0Aexample,=0D=0A>= a=0D=0A> > > > NAT=0D=0A> > > > > > > used in=0D=0A> > > > > > > a residen= tial local area network is typically not a=0D=0Aproblem,=0D=0A> > > > becau= se=0D=0A> > > > > > the=0D=0A> > > > > > > external IP address used on the = WAN side of the NAT is in=0D=0Afact=0D=0A> > > the=0D=0A> > > > > > right=0D= =0A> > > > > > > identifier for all of the devices in the residence. On=0D= =0Athe=0D=0A> > > other=0D=0A> > > > > > hand,=0D=0A> > > > > > > if=0D=0A>= > > > > > > there is a VPN between the client and the server, for=0D=0Aexa= mple=0D=0A> > > for=0D=0A> > > > a=0D=0A> > > > > > > teleworker, then the = address seen by the server may not be=0D=0Athe=0D=0A> > > > right=0D=0A> > = > > > > > address=0D=0A> > > > > > > to identify the location of the client= =2E Where a VPN is=0D=0A> > > deployed,=0D=0A> > > > > > > clients=0D=0A> = > > > > > > often have the ability to bypass the VPN for a transaction=0D=0A= > like=0D=0A> > > > > HELD.=0D=0A> > > > > > >=0D=0A> > > > > > > HELD Clie= nts MUST NOT send HELD requests where IP address=0D=0Ais=0D=0A> the=0D=0A> = > > > > > > identifier=0D=0A> > > > > > > and a VPN, NAT or other IP addres= s modification exists=0D=0Abetween=0D=0A> > > the=0D=0A> > > > > > > client=0D= =0A> > > > > > > and the server which could produce incorrect location.=0D=0A= HELD=0D=0A> > > MUST=0D=0A> > > > > NOT=0D=0A> > > > > > be=0D=0A> > > > > = > > deployed in networks where the client cannot comply=0D=0Areasonably=0D=0A= > > > > > > reliably=0D=0A> > > > > > > with=0D=0A> > > > > > > that requir= ement.=0D=0A> > > > > > >=0D=0A> > >=0D=0A> > >=0D=0A> > > ________________= _______________________________=0D=0A> > > Ecrit mailing list=0D=0A> > > Ec= rit@ietf.org=0D=0A> > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>= >=0D=0A> >=0D=0A----------------------------------------------------------= --------------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > This mess= age is for the designated recipient only and may=0D=0A> > contain privilege= d, proprietary, or otherwise private information.=0D=0A> > If you have rece= ived it in error, please notify the sender=0D=0A> > immediately and delete = the original. Any unauthorized use of=0D=0A> > this email is prohibited.=0D= =0A> >=0D=0A---------------------------------------------------------------= ---------=0D=0A> --=0D=0A> > ----------------------=0D=0A> > [mf2]=0D=0A> =0D= =0A>=20=0D=0A> _______________________________________________=0D=0A> Ecrit= mailing list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/li= stinfo/ecrit=0D=0A=0D=0A---------------------------------------------------= ---------------------------------------------=0D=0AThis message is for the = designated recipient only and may=0D=0Acontain privileged, proprietary, or = otherwise private information. =20=0D=0AIf you have received it in error, p= lease notify the sender=0D=0Aimmediately and delete the original. Any unau= thorized use of=0D=0Athis email is prohibited.=0D=0A-----------------------= -------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 05 04:17:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ioy5f-0007RA-4a; Mon, 05 Nov 2007 04:17:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ioy5d-0007OJ-QY for ecrit@ietf.org; Mon, 05 Nov 2007 04:17:49 -0500 Received: from fk-out-0910.google.com ([209.85.128.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ioy5c-0001bJ-JR for ecrit@ietf.org; Mon, 05 Nov 2007 04:17:49 -0500 Received: by fk-out-0910.google.com with SMTP id z23so1533073fkz for ; Mon, 05 Nov 2007 01:17:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=UCOFzxlcTxcYpCQUuYzbTwps2KKf/+Vl444L8MhZ1Po=; b=VbJUnsyPeeoXP/OrcE0eF7TloQniV+YDx/j0wJF67U+T6+CWTWRAYcuCRtnLL8TeAnzh6yfeQEpxk8Ikay7+MlbrfhMno3Cej8QnOgPT0pZsXoXdz1uXZ2TVN6YISNzewRMJ0hDfPFWVu+mU5GXdHa6XUCA0sk0lgw0JWZcxLfY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=bkSc1FviXJmtEtk3LvC6ArrVRpDM9WJMnJ9BgQOhwzbuPOsbtYhTOJQpB7WDSKNCb6TG5cy1+GAmbPKdjhGKpi8PAZlEx9TOH94vDK37m2sQ2Gwu9rWCaPH1owozZNiEKGqozAbfYj5wcbRpyBPdsPDdNWQWMR34Q91lOQ94SiE= Received: by 10.82.138.6 with SMTP id l6mr9254264bud.1194252802070; Mon, 05 Nov 2007 00:53:22 -0800 (PST) Received: by 10.82.165.18 with HTTP; Mon, 5 Nov 2007 00:53:22 -0800 (PST) Message-ID: Date: Mon, 5 Nov 2007 09:53:22 +0100 From: "Karl Heinz Wolf" To: "Hannes Tschofenig" Subject: Re: [Ecrit] Review of draft-ietf-ecrit-phonebcp-02.txt In-Reply-To: <472473EC.1060208@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <472473EC.1060208@gmx.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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, > ED-13/SP-11/AN-1 Elements MUST NOT convert (civic to geo or geo to > civic) from the form of location the determination mechanism > supplied. > > You cannot put a "MUST NOT" requirement here since we need this translation > in case we receive location information from DHCP and use it with > SIP Location Conveyance. In some sense this contradicts requirement ED-39. > I do not see a need for conversion from civic to geo when receiving DHCP location information and using SIP Location conveyance. If I get DHCP civic location, I map it to the appropriate PIDF-LO fields for civic location. If I get DHCP geo location, I put the coordinates to the PIDF-LO. It is a different format, but no civic/geo conversion. karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 05 08:13:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip1lr-0001eG-5z; Mon, 05 Nov 2007 08:13:39 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip1lp-0001bP-LG for ecrit@ietf.org; Mon, 05 Nov 2007 08:13:37 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip1ln-0005ji-Ut for ecrit@ietf.org; Mon, 05 Nov 2007 08:13:37 -0500 X-IronPort-AV: E=Sophos;i="4.21,372,1188792000"; d="scan'208";a="75251934" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 Nov 2007 08:13:35 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lA5DDZUi012791; Mon, 5 Nov 2007 08:13:35 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA5DDWex011804; Mon, 5 Nov 2007 13:13:35 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 08:13:32 -0500 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 08:13:09 -0500 From: "Marc Linsner" To: "'Brian Rosen'" , "'ECRIT'" Subject: RE: [Ecrit] Re: [Geopriv] Use of IPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Date: Mon, 5 Nov 2007 08:13:08 -0500 Message-ID: <00e701c81fad$9c55efa0$2d0d0d0a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYACJZSdg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <01da01c81d87$c75d4c70$2fea0446@cis.neustar.com> X-OriginalArrivalTime: 05 Nov 2007 13:13:09.0389 (UTC) FILETIME=[9C677BD0:01C81FAD] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15522.000 X-TM-AS-Result: No--15.070300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=18553; t=1194268415; x=1195132415; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Re=3A=20[Geopriv]=20Use=20of=20IPaddressasa nidentifier=09indraft-ietf-geopriv-http-location-delivery |Sender:=20 |To:=20=22'Brian=20Rosen'=22=20, =20=22'ECRIT'=22=20; bh=EZZGQQpze+vpvs3B+cYQWPyyFhUwEYjZKI0iANUETIM=; b=YhS8lTgEz0+uZT5lAhoVIuY6AjYAJ8p7M4NloBa8gRjWe3BgXDBv73R8aeCQ01Twkj6Cdyi7 YqO963KJ72lrjI7/+yBvIOSvTo6LS0jWSnPyx4p25PXylFEdP+YCFz7I; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9b157e6e8a3799aef911c0bc37fc93a6 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 Brian, IMO, applicability belongs in the base document. I believe there will be much difficulty moving the HELD draft through the IESG without strict usage guidelines included. -Marc- > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net] > Sent: Friday, November 02, 2007 3:37 PM > To: 'Thomson, Martin'; 'Stark, Barbara'; 'Dawson, Martin'; > 'Richard Barnes'; 'ECRIT' > Subject: RE: [Ecrit] Re: [Geopriv] Use of > IPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery > > Chair/AD opinion please > > I will write a BCP if we need it. I think that would be > silly, and the protocol document is the appropriate place for > documenting deployment concerns for the protocol. > > Brian > > > -----Original Message----- > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > Sent: Thursday, November 01, 2007 5:32 PM > > To: Stark, Barbara; Brian Rosen; Dawson, Martin; Richard > Barnes; ECRIT > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier > > indraft-ietf-geopriv-http-location-delivery > > > > I have to strongly agree with Barbara. If -phone-bcp isn't > the right > > place for these recommendations then someone can write another BCP. > > > > > -----Original Message----- > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > Sent: Friday, 2 November 2007 1:39 AM > > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP > addressasanidentifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > HELD is a protocol, purely and simply. It's not a BCP and > cannot and > > > should not attempt to use MUST and SHOULD language around > behavior > > > of devices and networks that use the protocol, outside of > > > requirements directly related to formatting of the > protocol messages. > > > Http-location-delivery MUST NOT contain normative language that > > > attempts to restrict the environment where HELD may be > used. I have > > > no problem with including a discussion of these issues in > http-location-delivery. > > > But if you want something stronger, it needs to be a BCP. Since > > > phonebcp only applies to use for emergency services, then I guess > > > you'd need a more generic BCP out of geopriv. > > > > > > Since such a HELD BCP (from geopriv) may or may not be > recognized by > > > device manufacturers, I'd recommend making sure that > phonebcp does > > > have what's needed, as far as use of HELD for emergency services. > > > Barbara > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, November 01, 2007 10:10 AM > > > To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > asanidentifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > The text belongs in the HELD document because it has > nothing to do > > > with emergency calls. It affects all uses of HELD. > > > > > > I don't have a problem with expanding text in -phonebcp > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > Sent: Thursday, November 01, 2007 9:58 AM > > > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > > > > asanidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > I have no problem with your proposed verbiage > characterizing the > > > > problem. > > > > > > > > I think that requirements on end devices using HELD and access > > > networks > > > > providing HELD responses is a phonebcp issue, and not > > > > http-location-delivery. > > > > > > > > Within phonebcp, I think that enterprise networks (that are not > > > > able > > > to > > > > control the capabilities of devices attaching to them) > are already > > > > included in the definition of access network. That seems to > > > > currently > > > be > > > > implicit, but perhaps it should be explicit. Then all > requirements > > > that > > > > apply to access networks will explicitly apply to such > enterprise > > > > networks. I'm not sure I see what such enterprise > networks need to > > > > do different than public access networks. You already have some > > > > VPN and > > > NAT > > > > requirements there: > > > > AN-14 Network administrators MUST take care in assigning IP > > > addresses > > > > such that VPN address assignments can be > distinguished from local > > > > devices (by subnet choice, for example), and LISs should not > > > attempt > > > > to provide location to addresses that arrive via VPN > connections. > > > > > > > > AN-15 Placement of NAT devices should consider the effect of > > > > the > > > NAT > > > > on the LCP. > > > > > > > > The device location update when the device has a VPN > established > > > > that doesn't allow split tunneling is definitely a gap. > I think it > > > > could be solved with some HELD extensions (which is a geopriv > > > > issue). That is, > > > I > > > > think that if we allow the initial (pre-VPN) request to also > > > > negotiate identification and authentication for future updates, > > > > that we could solve the update problem. > > > > > > > > The intermediary SOHO (small office/home office) router > that sets > > > > up > > > the > > > > non-split tunneling VPN on behalf of its LAN needs to > be required > > > > (in > > > > phonebcp) to act as the LIS for all devices in its LAN. That's > > > > part of the additional requirements I'm working on > providing you (Brian). > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, November 01, 2007 6:16 AM > > > > To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > > > > asanidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > That's helpful. > > > > > > > > I don't think it's sufficient. My example, hardware VPN/tunnel > > > > mechanisms cannot be permitted, has to be spelled out. Also, > > > > phonebcp recommends location update at call time. We haven't > > > > worked out this detail, but > > > I > > > > think we want to at least recommend that a mobile device send > > > > routing location as a value, and dispatch location as a > reference > > > > (where needed), just to avoid the repeated dereference > by all call > > > > routing elements. > > > > That > > > > means you would want to do the HELD LCP operation at call time. > > > > > > > > You need to discuss enterprise networks behind access networks > > > > that provide HELD, or try to use HELD within an enterprise > > > > network. > > > > > > > > I think it's hard to think through ALL the instances where an IP > > > address > > > > isn't reliable as an identifier to be used for > location, which is > > > > why > > > I > > > > phrased my proposed text the way I did. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > Sent: Thursday, November 01, 2007 5:42 AM > > > > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > > > > > asanidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > Oh, fine, I'll try to be helpful, then. > > > > > I definitely agree with having the problem mentioned and > > > > > properly characterized. But when we write > requirements, I want > > > > > to be sure > > > that > > > > > the requirements are implementable. > > > > > > > > > > Certainly, end devices must do location configuration before > > > > > establishing a VPN. Once an end device has > established a VPN, it > > > must > > > > > not do any LIS discovery or HELD queries over the VPN > connection. > > > > > > > > > > The Access Network, however, needs to have the > requirement that > > > > > its > > > > LIS > > > > > be able to know which subnets of IP addresses are supplied to > > > devices > > > > > coming over VPN access, or have been provided to a > company that > > > > provides > > > > > its own LIS. That is, such blocks of IP addresses need to be > > > > > configurable in the LIS. Then there's the requirement > that the > > > > > LIS > > > > must > > > > > not provide location to these IP addresses. > > > > > > > > > > The access network (access provider + ISP) also has a > > > > > responsibility > > > > not > > > > > to place a LIS on the core side of any NAT that is > employed in > > > > > the access network. Note that this isn't meant to > apply to home > > > > > router > > > > NATs, > > > > > since those aren't part of the access network, > according to the > > > > > definition of access network. > > > > > > > > > > I really think that the access network has greater > ability, and > > > > > therefore greater responsibility, to minimize the > occurrence of > > > > problems > > > > > due to VPNs and NATs. > > > > > > > > > > As we discussed (Brian and I), I'm going to try to > suggest a way > > > > > to better include in phonebcp requirements for > routers employed > > > > > in > > > "small > > > > > areas". One of the requirements we need for these, is > that they > > > > > MUST > > > > act > > > > > as the LIS for LAN-side devices, when they have VPN > connections > > > > > to > > > the > > > > > WAN. > > > > > Barbara > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Thursday, November 01, 2007 4:03 AM > > > > > To: 'Dawson, Martin'; 'Richard Barnes'; Stark, > Barbara; 'ECRIT' > > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > > > > > asanidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > I think the problem that Barbara points out is precisely the > > > > > problem > > > > in > > > > > deploying HELD. Claiming that a problem can't be solved, and > > > > therefore > > > > > should not be mentioned is, uh, ?unhelpful? Having > the "caveat" > > > > instead > > > > > of > > > > > a deployment recommendation understates the problem. > While it > > > > > is possible to deploy HELD so that it almost always works, it > > > > > will take a lot of attention by a lot of entities to > make that > > > > > happen. For example, if HELD is deployed, no non-bypassable > > > > > VPNs can be permitted. The protocol document should be very > > > > > clear about what it takes to make HELD work. > > > > > > > > > > I have no problem including text that covers what devices and > > > > > LIS's > > > > need > > > > > to > > > > > do, as long as it was noted that it won't always be > sufficient. > > > > > We might also include text on how enterprise networks > should be > > > > > configured. > > > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > > Sent: Wednesday, October 31, 2007 11:58 AM > > > > > > To: Richard Barnes; Stark, Barbara; ECRIT > > > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > > > asanidentifier > > > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > > > I think that the "device" requirement at most should be that > > > efforts > > > > > > should be made to ensure that the LIS is discovered > and used > > > > > > on > > > the > > > > > > physical access network and not via any VPN tunnel. > > > > > > > > > > > > Perhaps more importantly, there should be a complementary > > > > requirement > > > > > on > > > > > > the LIS that it not attempt to provide location for an IP > > > > > > address > > > > that > > > > > > it cannot associate a physical location with. For > example, a > > > > > > LIS > > > in > > > > an > > > > > > enterprise, where that enterprise supports VPN > access, should > > > > > > know > > > > or > > > > > be > > > > > > able to determine that the client requests are > arriving over a > > > > > > VPN > > > > > from > > > > > > an end point whose location cannot be determined. The HELD > > > response > > > > > > should indicate that location cannot be provided. > > > > > > > > > > > > Cheers, > > > > > > Martin > > > > > > > > > > > > -----Original Message----- > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > Sent: Thursday, 1 November 2007 1:22 AM > > > > > > To: Stark, Barbara; ECRIT > > > > > > Subject: [Ecrit] Re: [Geopriv] Use of IP address as > > > > > > anidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > > > Right, I think what's needed is more a caveat that HELD > > > > > > provides > > > the > > > > > > location of the source IP address in the IP header of the > > > > > > request > > > -- > > > > > > whatever that may be. > > > > > > > > > > > > --Richard > > > > > > > > > > > > > > > > > > > > > > > > Stark, Barbara wrote: > > > > > > > How is a client supposed to know whether a "VPN, NAT or > > > > > > > other IP > > > > > > address > > > > > > > modification exists between the client and the > server which > > > could > > > > > > > produce incorrect location"? One of the best uses > of HELD is > > > > > > > the > > > > > case > > > > > > > where there is a NAT (and the box with the NAT is location > > > > unaware). > > > > > > For > > > > > > > landline broadband services, this NAT exists, but doesn't > > > produce > > > > an > > > > > > > incorrect location. So this NAT is ok. How can you > > > > > > > distinguish > > > > > between > > > > > > a > > > > > > > NAT that produces an incorrect location, vs. one that > > > > > > > produces a > > > > > > correct > > > > > > > location? > > > > > > > > > > > > > > The VPN could be originated out of the router, and not the > > > client. > > > > > How > > > > > > > would the client know this VPN even exists? > > > > > > > > > > > > > > Unless you can tell me the logic to use to implement this > > > proposed > > > > > > > requirement, I can't support it. > > > > > > > Barbara > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > Sent: Wednesday, October 31, 2007 8:51 AM > > > > > > > To: geopriv@ietf.org > > > > > > > Subject: [Geopriv] Use of IP address as an identifier > > > > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > > > > > In the long set of discussions that have lead to > HELD, one > > > > > > > of > > > the > > > > > > > biggest > > > > > > > concerns a few of us have had is the problem than an IP > > > > > > > address > > > > may > > > > > > not > > > > > > > be a > > > > > > > good identifier for determining the location of > the client. > > > There > > > > > is > > > > > > a > > > > > > > draft that describes alternate identifiers. > However, there > > > > > > > is > > > no > > > > > > > discussion > > > > > > > in the present draft of the base protocol on these issues. > > > > > > > > > > > > > > I would like to propose that we add text something like: > > > > > > > > > > > > > > Use of HELD is subject to the viability of the identifier > > > > > > > used > > > by > > > > > the > > > > > > > LIS to > > > > > > > determine location. This document describes the > use of the > > > > > > > IP > > > > > address > > > > > > > of > > > > > > > the client as the identifier. When a NAT, VPN or other > > > > > > > forms of > > > > > > address > > > > > > > modification occur between the client and the server, the > > > location > > > > > > > returned > > > > > > > may be inaccurate. This is not always the case. For > > > > > > > example, a > > > > NAT > > > > > > > used in > > > > > > > a residential local area network is typically not > a problem, > > > > because > > > > > > the > > > > > > > external IP address used on the WAN side of the NAT is in > > > > > > > fact > > > the > > > > > > right > > > > > > > identifier for all of the devices in the > residence. On the > > > other > > > > > > hand, > > > > > > > if > > > > > > > there is a VPN between the client and the server, for > > > > > > > example > > > for > > > > a > > > > > > > teleworker, then the address seen by the server > may not be > > > > > > > the > > > > right > > > > > > > address > > > > > > > to identify the location of the client. Where a VPN is > > > deployed, > > > > > > > clients > > > > > > > often have the ability to bypass the VPN for a > transaction > > > > > > > like > > > > > HELD. > > > > > > > > > > > > > > HELD Clients MUST NOT send HELD requests where IP > address is > > > > > > > the identifier and a VPN, NAT or other IP address > > > > > > > modification exists between > > > the > > > > > > > client > > > > > > > and the server which could produce incorrect > location. HELD > > > MUST > > > > > NOT > > > > > > be > > > > > > > deployed in networks where the client cannot comply > > > > > > > reasonably > > > > > > reliably > > > > > > > with > > > > > > > that requirement. > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 Mon Nov 05 08:38:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2AB-0003Xo-KM; Mon, 05 Nov 2007 08:38:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2AA-0003Wy-Kt for ecrit@ietf.org; Mon, 05 Nov 2007 08:38:46 -0500 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip2A8-0006Vs-TH for ecrit@ietf.org; Mon, 05 Nov 2007 08:38:46 -0500 Received: from ([139.76.131.79]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.188090751; Mon, 05 Nov 2007 08:38:25 -0500 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 5 Nov 2007 08:38:25 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 5 Nov 2007 08:38:25 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 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] Re: [Geopriv] Use ofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Date: Mon, 5 Nov 2007 08:38:24 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA06376ED7@crexc41p> In-Reply-To: <00e701c81fad$9c55efa0$2d0d0d0a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] Use ofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery thread-index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYACJZSdgAACjFGA= References: <01da01c81d87$c75d4c70$2fea0446@cis.neustar.com> <00e701c81fad$9c55efa0$2d0d0d0a@cisco.com> From: "Stark, Barbara" To: "Marc Linsner" , "Brian Rosen" , "ECRIT" X-OriginalArrivalTime: 05 Nov 2007 13:38:25.0691 (UTC) FILETIME=[2430CEB0:01C81FB1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9361ae25efd9cff62e36f70ef966350e 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 OK. So I agree that descriptive usage guidance is a good thing. It sounds like there's general consensus on that. If you want normative language in these guidelines, I can be swayed, but I would ask that such requirements be reasonable, rational, implementable, and do not attempt to unnecessarily cripple usage of the protocol. If they aren't useful, implementers like me will be tempted to simply ignore them. We implementers have a long history of doing that, and I think it weakens RFCs when implementers freely pick and choose which normative guidance they want to abide by. Barbara=20 -----Original Message----- From: Marc Linsner [mailto:mlinsner@cisco.com]=20 Sent: Monday, November 05, 2007 8:13 AM To: 'Brian Rosen'; 'ECRIT' Subject: RE: [Ecrit] Re: [Geopriv] Use ofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Brian, IMO, applicability belongs in the base document. I believe there will be much difficulty moving the HELD draft through the IESG without strict usage guidelines included. -Marc- > -----Original Message----- > From: Brian Rosen [mailto:br@brianrosen.net]=20 > Sent: Friday, November 02, 2007 3:37 PM > To: 'Thomson, Martin'; 'Stark, Barbara'; 'Dawson, Martin';=20 > 'Richard Barnes'; 'ECRIT' > Subject: RE: [Ecrit] Re: [Geopriv] Use of=20 > IPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery >=20 > Chair/AD opinion please >=20 > I will write a BCP if we need it. I think that would be=20 > silly, and the protocol document is the appropriate place for=20 > documenting deployment concerns for the protocol. >=20 > Brian >=20 > > -----Original Message----- > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > Sent: Thursday, November 01, 2007 5:32 PM > > To: Stark, Barbara; Brian Rosen; Dawson, Martin; Richard=20 > Barnes; ECRIT > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier=20 > > indraft-ietf-geopriv-http-location-delivery > >=20 > > I have to strongly agree with Barbara. If -phone-bcp isn't=20 > the right=20 > > place for these recommendations then someone can write another BCP. > >=20 > > > -----Original Message----- > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > Sent: Friday, 2 November 2007 1:39 AM > > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP=20 > addressasanidentifier=20 > > > indraft-ietf-geopriv-http-location-delivery > > > > > > HELD is a protocol, purely and simply. It's not a BCP and=20 > cannot and=20 > > > should not attempt to use MUST and SHOULD language around=20 > behavior=20 > > > of devices and networks that use the protocol, outside of=20 > > > requirements directly related to formatting of the=20 > protocol messages. > > > Http-location-delivery MUST NOT contain normative language that=20 > > > attempts to restrict the environment where HELD may be=20 > used. I have=20 > > > no problem with including a discussion of these issues in=20 > http-location-delivery. > > > But if you want something stronger, it needs to be a BCP. Since=20 > > > phonebcp only applies to use for emergency services, then I guess=20 > > > you'd need a more generic BCP out of geopriv. > > > > > > Since such a HELD BCP (from geopriv) may or may not be=20 > recognized by=20 > > > device manufacturers, I'd recommend making sure that=20 > phonebcp does=20 > > > have what's needed, as far as use of HELD for emergency services. > > > Barbara > > > > > > -----Original Message----- > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > Sent: Thursday, November 01, 2007 10:10 AM > > > To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address=20 > asanidentifier=20 > > > indraft-ietf-geopriv-http-location-delivery > > > > > > The text belongs in the HELD document because it has=20 > nothing to do=20 > > > with emergency calls. It affects all uses of HELD. > > > > > > I don't have a problem with expanding text in -phonebcp > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > Sent: Thursday, November 01, 2007 9:58 AM > > > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address=20 > > > > asanidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > I have no problem with your proposed verbiage=20 > characterizing the=20 > > > > problem. > > > > > > > > I think that requirements on end devices using HELD and access > > > networks > > > > providing HELD responses is a phonebcp issue, and not=20 > > > > http-location-delivery. > > > > > > > > Within phonebcp, I think that enterprise networks (that are not=20 > > > > able > > > to > > > > control the capabilities of devices attaching to them)=20 > are already=20 > > > > included in the definition of access network. That seems to=20 > > > > currently > > > be > > > > implicit, but perhaps it should be explicit. Then all=20 > requirements > > > that > > > > apply to access networks will explicitly apply to such=20 > enterprise=20 > > > > networks. I'm not sure I see what such enterprise=20 > networks need to=20 > > > > do different than public access networks. You already have some=20 > > > > VPN and > > > NAT > > > > requirements there: > > > > AN-14 Network administrators MUST take care in assigning IP > > > addresses > > > > such that VPN address assignments can be=20 > distinguished from local > > > > devices (by subnet choice, for example), and LISs should not > > > attempt > > > > to provide location to addresses that arrive via VPN=20 > connections. > > > > > > > > AN-15 Placement of NAT devices should consider the effect of=20 > > > > the > > > NAT > > > > on the LCP. > > > > > > > > The device location update when the device has a VPN=20 > established=20 > > > > that doesn't allow split tunneling is definitely a gap.=20 > I think it=20 > > > > could be solved with some HELD extensions (which is a geopriv=20 > > > > issue). That is, > > > I > > > > think that if we allow the initial (pre-VPN) request to also=20 > > > > negotiate identification and authentication for future updates,=20 > > > > that we could solve the update problem. > > > > > > > > The intermediary SOHO (small office/home office) router=20 > that sets=20 > > > > up > > > the > > > > non-split tunneling VPN on behalf of its LAN needs to=20 > be required=20 > > > > (in > > > > phonebcp) to act as the LIS for all devices in its LAN. That's=20 > > > > part of the additional requirements I'm working on=20 > providing you (Brian). > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, November 01, 2007 6:16 AM > > > > To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address=20 > > > > asanidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > That's helpful. > > > > > > > > I don't think it's sufficient. My example, hardware VPN/tunnel=20 > > > > mechanisms cannot be permitted, has to be spelled out. Also,=20 > > > > phonebcp recommends location update at call time. We haven't=20 > > > > worked out this detail, but > > > I > > > > think we want to at least recommend that a mobile device send=20 > > > > routing location as a value, and dispatch location as a=20 > reference=20 > > > > (where needed), just to avoid the repeated dereference=20 > by all call=20 > > > > routing elements. > > > > That > > > > means you would want to do the HELD LCP operation at call time. > > > > > > > > You need to discuss enterprise networks behind access networks=20 > > > > that provide HELD, or try to use HELD within an enterprise=20 > > > > network. > > > > > > > > I think it's hard to think through ALL the instances where an IP > > > address > > > > isn't reliable as an identifier to be used for=20 > location, which is=20 > > > > why > > > I > > > > phrased my proposed text the way I did. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > Sent: Thursday, November 01, 2007 5:42 AM > > > > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address=20 > > > > > asanidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > Oh, fine, I'll try to be helpful, then. > > > > > I definitely agree with having the problem mentioned and=20 > > > > > properly characterized. But when we write=20 > requirements, I want=20 > > > > > to be sure > > > that > > > > > the requirements are implementable. > > > > > > > > > > Certainly, end devices must do location configuration before=20 > > > > > establishing a VPN. Once an end device has=20 > established a VPN, it > > > must > > > > > not do any LIS discovery or HELD queries over the VPN=20 > connection. > > > > > > > > > > The Access Network, however, needs to have the=20 > requirement that=20 > > > > > its > > > > LIS > > > > > be able to know which subnets of IP addresses are supplied to > > > devices > > > > > coming over VPN access, or have been provided to a=20 > company that > > > > provides > > > > > its own LIS. That is, such blocks of IP addresses need to be=20 > > > > > configurable in the LIS. Then there's the requirement=20 > that the=20 > > > > > LIS > > > > must > > > > > not provide location to these IP addresses. > > > > > > > > > > The access network (access provider + ISP) also has a=20 > > > > > responsibility > > > > not > > > > > to place a LIS on the core side of any NAT that is=20 > employed in=20 > > > > > the access network. Note that this isn't meant to=20 > apply to home=20 > > > > > router > > > > NATs, > > > > > since those aren't part of the access network,=20 > according to the=20 > > > > > definition of access network. > > > > > > > > > > I really think that the access network has greater=20 > ability, and=20 > > > > > therefore greater responsibility, to minimize the=20 > occurrence of > > > > problems > > > > > due to VPNs and NATs. > > > > > > > > > > As we discussed (Brian and I), I'm going to try to=20 > suggest a way=20 > > > > > to better include in phonebcp requirements for=20 > routers employed=20 > > > > > in > > > "small > > > > > areas". One of the requirements we need for these, is=20 > that they=20 > > > > > MUST > > > > act > > > > > as the LIS for LAN-side devices, when they have VPN=20 > connections=20 > > > > > to > > > the > > > > > WAN. > > > > > Barbara > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Thursday, November 01, 2007 4:03 AM > > > > > To: 'Dawson, Martin'; 'Richard Barnes'; Stark,=20 > Barbara; 'ECRIT' > > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address=20 > > > > > asanidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > I think the problem that Barbara points out is precisely the=20 > > > > > problem > > > > in > > > > > deploying HELD. Claiming that a problem can't be solved, and > > > > therefore > > > > > should not be mentioned is, uh, ?unhelpful? Having=20 > the "caveat" > > > > instead > > > > > of > > > > > a deployment recommendation understates the problem. =20 > While it=20 > > > > > is possible to deploy HELD so that it almost always works, it=20 > > > > > will take a lot of attention by a lot of entities to=20 > make that=20 > > > > > happen. For example, if HELD is deployed, no non-bypassable=20 > > > > > VPNs can be permitted. The protocol document should be very=20 > > > > > clear about what it takes to make HELD work. > > > > > > > > > > I have no problem including text that covers what devices and=20 > > > > > LIS's > > > > need > > > > > to > > > > > do, as long as it was noted that it won't always be=20 > sufficient. =20 > > > > > We might also include text on how enterprise networks=20 > should be=20 > > > > > configured. > > > > > > > > > > Brian > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > > Sent: Wednesday, October 31, 2007 11:58 AM > > > > > > To: Richard Barnes; Stark, Barbara; ECRIT > > > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > > > asanidentifier > > > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > > > I think that the "device" requirement at most should be that > > > efforts > > > > > > should be made to ensure that the LIS is discovered=20 > and used=20 > > > > > > on > > > the > > > > > > physical access network and not via any VPN tunnel. > > > > > > > > > > > > Perhaps more importantly, there should be a complementary > > > > requirement > > > > > on > > > > > > the LIS that it not attempt to provide location for an IP=20 > > > > > > address > > > > that > > > > > > it cannot associate a physical location with. For=20 > example, a=20 > > > > > > LIS > > > in > > > > an > > > > > > enterprise, where that enterprise supports VPN=20 > access, should=20 > > > > > > know > > > > or > > > > > be > > > > > > able to determine that the client requests are=20 > arriving over a=20 > > > > > > VPN > > > > > from > > > > > > an end point whose location cannot be determined. The HELD > > > response > > > > > > should indicate that location cannot be provided. > > > > > > > > > > > > Cheers, > > > > > > Martin > > > > > > > > > > > > -----Original Message----- > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > Sent: Thursday, 1 November 2007 1:22 AM > > > > > > To: Stark, Barbara; ECRIT > > > > > > Subject: [Ecrit] Re: [Geopriv] Use of IP address as=20 > > > > > > anidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > > > Right, I think what's needed is more a caveat that HELD=20 > > > > > > provides > > > the > > > > > > location of the source IP address in the IP header of the=20 > > > > > > request > > > -- > > > > > > whatever that may be. > > > > > > > > > > > > --Richard > > > > > > > > > > > > > > > > > > > > > > > > Stark, Barbara wrote: > > > > > > > How is a client supposed to know whether a "VPN, NAT or=20 > > > > > > > other IP > > > > > > address > > > > > > > modification exists between the client and the=20 > server which > > > could > > > > > > > produce incorrect location"? One of the best uses=20 > of HELD is=20 > > > > > > > the > > > > > case > > > > > > > where there is a NAT (and the box with the NAT is location > > > > unaware). > > > > > > For > > > > > > > landline broadband services, this NAT exists, but doesn't > > > produce > > > > an > > > > > > > incorrect location. So this NAT is ok. How can you=20 > > > > > > > distinguish > > > > > between > > > > > > a > > > > > > > NAT that produces an incorrect location, vs. one that=20 > > > > > > > produces a > > > > > > correct > > > > > > > location? > > > > > > > > > > > > > > The VPN could be originated out of the router, and not the > > > client. > > > > > How > > > > > > > would the client know this VPN even exists? > > > > > > > > > > > > > > Unless you can tell me the logic to use to implement this > > > proposed > > > > > > > requirement, I can't support it. > > > > > > > Barbara > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > Sent: Wednesday, October 31, 2007 8:51 AM > > > > > > > To: geopriv@ietf.org > > > > > > > Subject: [Geopriv] Use of IP address as an identifier=20 > > > > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > > > > > In the long set of discussions that have lead to=20 > HELD, one=20 > > > > > > > of > > > the > > > > > > > biggest > > > > > > > concerns a few of us have had is the problem than an IP=20 > > > > > > > address > > > > may > > > > > > not > > > > > > > be a > > > > > > > good identifier for determining the location of=20 > the client. > > > There > > > > > is > > > > > > a > > > > > > > draft that describes alternate identifiers. =20 > However, there=20 > > > > > > > is > > > no > > > > > > > discussion > > > > > > > in the present draft of the base protocol on these issues. > > > > > > > > > > > > > > I would like to propose that we add text something like: > > > > > > > > > > > > > > Use of HELD is subject to the viability of the identifier=20 > > > > > > > used > > > by > > > > > the > > > > > > > LIS to > > > > > > > determine location. This document describes the=20 > use of the=20 > > > > > > > IP > > > > > address > > > > > > > of > > > > > > > the client as the identifier. When a NAT, VPN or other=20 > > > > > > > forms of > > > > > > address > > > > > > > modification occur between the client and the server, the > > > location > > > > > > > returned > > > > > > > may be inaccurate. This is not always the case. For=20 > > > > > > > example, a > > > > NAT > > > > > > > used in > > > > > > > a residential local area network is typically not=20 > a problem, > > > > because > > > > > > the > > > > > > > external IP address used on the WAN side of the NAT is in=20 > > > > > > > fact > > > the > > > > > > right > > > > > > > identifier for all of the devices in the=20 > residence. On the > > > other > > > > > > hand, > > > > > > > if > > > > > > > there is a VPN between the client and the server, for=20 > > > > > > > example > > > for > > > > a > > > > > > > teleworker, then the address seen by the server=20 > may not be=20 > > > > > > > the > > > > right > > > > > > > address > > > > > > > to identify the location of the client. Where a VPN is > > > deployed, > > > > > > > clients > > > > > > > often have the ability to bypass the VPN for a=20 > transaction=20 > > > > > > > like > > > > > HELD. > > > > > > > > > > > > > > HELD Clients MUST NOT send HELD requests where IP=20 > address is=20 > > > > > > > the identifier and a VPN, NAT or other IP address=20 > > > > > > > modification exists between > > > the > > > > > > > client > > > > > > > and the server which could produce incorrect=20 > location. HELD > > > MUST > > > > > NOT > > > > > > be > > > > > > > deployed in networks where the client cannot comply=20 > > > > > > > reasonably > > > > > > reliably > > > > > > > with > > > > > > > that requirement. > > > > > > > > > > > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > >=20 > >=20 > ---------------------------------------------------------------------- > > ---- > > ---------------------- > > This message is for the designated recipient only and may contain=20 > > privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender=20 > immediately=20 > > and delete the original. Any unauthorized use of this email is=20 > > prohibited. > >=20 > ---------------------------------------------------------------------- > > ---- > > ---------------------- > > [mf2] >=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 ***** 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. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 05 08:54:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2PA-0001db-Mi; Mon, 05 Nov 2007 08:54:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2P8-0001Zz-Ue for ecrit@ietf.org; Mon, 05 Nov 2007 08:54:14 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip2P8-0006pe-GF for ecrit@ietf.org; Mon, 05 Nov 2007 08:54:14 -0500 X-IronPort-AV: E=Sophos;i="4.21,372,1188802800"; d="scan'208";a="413324765" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2007 05:54:03 -0800 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/8.12.11) with ESMTP id lA5Ds3KG027114; Mon, 5 Nov 2007 08:54:03 -0500 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 lA5DrfgM029560; Mon, 5 Nov 2007 13:54:01 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 08:52:56 -0500 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 08:52:19 -0500 From: "Marc Linsner" To: "'Winterbottom, James'" , "'ECRIT'" Subject: RE: [Ecrit] Re: [Geopriv] Use ofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Date: Mon, 5 Nov 2007 08:52:18 -0500 Message-ID: <00eb01c81fb3$151e3f50$2d0d0d0a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYAAudC4wAFtIv9A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: X-OriginalArrivalTime: 05 Nov 2007 13:52:19.0456 (UTC) FILETIME=[15274000:01C81FB3] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15522.000 X-TM-AS-Result: No-2.166600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1961; t=1194270843; x=1195134843; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Re=3A=20[Geopriv]=20Use=20ofIPaddressasanid entifier=09indraft-ietf-geopriv-http-location-delivery |Sender:=20 |To:=20=22'Winterbottom, =20James'=22=20, =0 A=20=20=20=20=20=20=20=20=22'ECRIT'=22=20; bh=Ymh99F2vS8M4XQhsMA/ShmUPZnzBVQn2AQEuXLOQhBM=; b=UJaEPKMXK60w0/4uqQP0UtaG6kEpWpfWS8KN1rs2K5GvUz9CE1Cd9zQNTb5dDzoC2G3BO0hN 4PHg81FSb4nODIqZ4F84cC4ZgreA1ls5r/NWj1Oa1Bx1YAeOviIXOJfx; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 James, In-line.... > Perhaps I am missing something here, but it seems to me that > this not a HELD problem so much as a service discovery > problem, which from what I am lead to believe can be just as > problematic with DHCP when it is run over VPNs. Consequently > unless we are going to address that issue too, I think that > AGAIN singling HELD out to address a generic problem is > totally inappropriate. 1) I don't understand your service discovery statement. DHCP server discovery is under strict control of the broadcast domain administration. The end host does not participate in this process. 2) In the case of a software VPN client, it is assumed the end host receives configuration information prior to establishment of the tunnel. It has been stated many times the end host must utilize the location received during the first step, prior to tunnel establishment. It would also be prudent that location information not be passed during tunnel establishment. 3) In the case of a hardware VPN it is typical that the remote device co-located with the end host provides network configuration. Location can be included at that time. > > A simple HELD-based LIS/relay-service added to a home router > will avoid the issues that have been described by Brian to > the same degree that they are avoided by DHCP. This is very > easy to do and we have made this work in OpenWRT running on a > linksys home-router. 4) This would not work in the typical hardware VPN environment. 5) I assume you are not suggesting home users to run OpenWRT..? I am not keen to start describing these > kinds of solutions in the base HELD specification, a BCP is > more appropriate, though a mention of care would seem reasonable. 6) As I stated in another email, in my experience, the IESG will want applicability included in the base draft, but I'm continually surprised by the IESG... :^) -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 05 08:58:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2Th-0001IL-MY; Mon, 05 Nov 2007 08:58:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2Tg-0001Hm-Vk for ecrit@ietf.org; Mon, 05 Nov 2007 08:58:56 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip2Tf-0007OQ-GG for ecrit@ietf.org; Mon, 05 Nov 2007 08:58:56 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id lA5DwOSf017652; Mon, 5 Nov 2007 06:58:25 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Mon, 5 Nov 2007 06:58:24 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) 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 Subject: RE: [Ecrit] Re: [Geopriv] Use ofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Date: Mon, 5 Nov 2007 06:58:24 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C67DA6B2@srvxchg3.cablelabs.com> In-Reply-To: <00e701c81fad$9c55efa0$2d0d0d0a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] Use ofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYACJZSdgAAFpYBA= References: <01da01c81d87$c75d4c70$2fea0446@cis.neustar.com> <00e701c81fad$9c55efa0$2d0d0d0a@cisco.com> From: "Jean-Francois Mule" To: "Marc Linsner" , "Brian Rosen" , "ECRIT" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 2af167865907217f0b49c659e31a77f7 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 P-A-I (RFC 3325) is an example of a 'base' document that defines a protocol mechanism and also contains an applicability statement. =20 A suggestion may be to formulate what (deployment/implementation) conditions make the protocol applicable to warn folks developing it when they design the implementation, as opposed to listing many concerns or negative cases. Jean-Francois. > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Monday, November 05, 2007 6:13 AM > To: 'Brian Rosen'; 'ECRIT' > Subject: RE: [Ecrit] Re: [Geopriv] Use ofIPaddressasanidentifier > indraft-ietf-geopriv-http-location-delivery >=20 > Brian, >=20 > IMO, applicability belongs in the base document. I believe there will > be > much difficulty moving the HELD draft through the IESG without strict > usage > guidelines included. >=20 > -Marc- >=20 >=20 > > -----Original Message----- > > From: Brian Rosen [mailto:br@brianrosen.net] > > Sent: Friday, November 02, 2007 3:37 PM > > To: 'Thomson, Martin'; 'Stark, Barbara'; 'Dawson, Martin'; > > 'Richard Barnes'; 'ECRIT' > > Subject: RE: [Ecrit] Re: [Geopriv] Use of > > IPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery > > > > Chair/AD opinion please > > > > I will write a BCP if we need it. I think that would be > > silly, and the protocol document is the appropriate place for > > documenting deployment concerns for the protocol. > > > > Brian > > > > > -----Original Message----- > > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > > Sent: Thursday, November 01, 2007 5:32 PM > > > To: Stark, Barbara; Brian Rosen; Dawson, Martin; Richard > > Barnes; ECRIT > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier > > > indraft-ietf-geopriv-http-location-delivery > > > > > > I have to strongly agree with Barbara. If -phone-bcp isn't > > the right > > > place for these recommendations then someone can write another BCP. > > > > > > > -----Original Message----- > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > Sent: Friday, 2 November 2007 1:39 AM > > > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP > > addressasanidentifier > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > HELD is a protocol, purely and simply. It's not a BCP and > > cannot and > > > > should not attempt to use MUST and SHOULD language around > > behavior > > > > of devices and networks that use the protocol, outside of > > > > requirements directly related to formatting of the > > protocol messages. > > > > Http-location-delivery MUST NOT contain normative language that > > > > attempts to restrict the environment where HELD may be > > used. I have > > > > no problem with including a discussion of these issues in > > http-location-delivery. > > > > But if you want something stronger, it needs to be a BCP. Since > > > > phonebcp only applies to use for emergency services, then I > guess > > > > you'd need a more generic BCP out of geopriv. > > > > > > > > Since such a HELD BCP (from geopriv) may or may not be > > recognized by > > > > device manufacturers, I'd recommend making sure that > > phonebcp does > > > > have what's needed, as far as use of HELD for emergency services. > > > > Barbara > > > > > > > > -----Original Message----- > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > Sent: Thursday, November 01, 2007 10:10 AM > > > > To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > > asanidentifier > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > The text belongs in the HELD document because it has > > nothing to do > > > > with emergency calls. It affects all uses of HELD. > > > > > > > > I don't have a problem with expanding text in -phonebcp > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > Sent: Thursday, November 01, 2007 9:58 AM > > > > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > > > > > asanidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > I have no problem with your proposed verbiage > > characterizing the > > > > > problem. > > > > > > > > > > I think that requirements on end devices using HELD and access > > > > networks > > > > > providing HELD responses is a phonebcp issue, and not > > > > > http-location-delivery. > > > > > > > > > > Within phonebcp, I think that enterprise networks (that are > not > > > > > able > > > > to > > > > > control the capabilities of devices attaching to them) > > are already > > > > > included in the definition of access network. That seems to > > > > > currently > > > > be > > > > > implicit, but perhaps it should be explicit. Then all > > requirements > > > > that > > > > > apply to access networks will explicitly apply to such > > enterprise > > > > > networks. I'm not sure I see what such enterprise > > networks need to > > > > > do different than public access networks. You already have > some > > > > > VPN and > > > > NAT > > > > > requirements there: > > > > > AN-14 Network administrators MUST take care in assigning IP > > > > addresses > > > > > such that VPN address assignments can be > > distinguished from local > > > > > devices (by subnet choice, for example), and LISs should > not > > > > attempt > > > > > to provide location to addresses that arrive via VPN > > connections. > > > > > > > > > > AN-15 Placement of NAT devices should consider the effect > of > > > > > the > > > > NAT > > > > > on the LCP. > > > > > > > > > > The device location update when the device has a VPN > > established > > > > > that doesn't allow split tunneling is definitely a gap. > > I think it > > > > > could be solved with some HELD extensions (which is a geopriv > > > > > issue). That is, > > > > I > > > > > think that if we allow the initial (pre-VPN) request to also > > > > > negotiate identification and authentication for future updates, > > > > > that we could solve the update problem. > > > > > > > > > > The intermediary SOHO (small office/home office) router > > that sets > > > > > up > > > > the > > > > > non-split tunneling VPN on behalf of its LAN needs to > > be required > > > > > (in > > > > > phonebcp) to act as the LIS for all devices in its LAN. That's > > > > > part of the additional requirements I'm working on > > providing you (Brian). > > > > > Barbara > > > > > > > > > > -----Original Message----- > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > Sent: Thursday, November 01, 2007 6:16 AM > > > > > To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; > 'ECRIT' > > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > > > > > asanidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > That's helpful. > > > > > > > > > > I don't think it's sufficient. My example, hardware > VPN/tunnel > > > > > mechanisms cannot be permitted, has to be spelled out. Also, > > > > > phonebcp recommends location update at call time. We haven't > > > > > worked out this detail, but > > > > I > > > > > think we want to at least recommend that a mobile device send > > > > > routing location as a value, and dispatch location as a > > reference > > > > > (where needed), just to avoid the repeated dereference > > by all call > > > > > routing elements. > > > > > That > > > > > means you would want to do the HELD LCP operation at call time. > > > > > > > > > > You need to discuss enterprise networks behind access networks > > > > > that provide HELD, or try to use HELD within an enterprise > > > > > network. > > > > > > > > > > I think it's hard to think through ALL the instances where an > IP > > > > address > > > > > isn't reliable as an identifier to be used for > > location, which is > > > > > why > > > > I > > > > > phrased my proposed text the way I did. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Stark, Barbara [mailto:bs7652@att.com] > > > > > > Sent: Thursday, November 01, 2007 5:42 AM > > > > > > To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT > > > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > > > > > > asanidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > > > Oh, fine, I'll try to be helpful, then. > > > > > > I definitely agree with having the problem mentioned and > > > > > > properly characterized. But when we write > > requirements, I want > > > > > > to be sure > > > > that > > > > > > the requirements are implementable. > > > > > > > > > > > > Certainly, end devices must do location configuration before > > > > > > establishing a VPN. Once an end device has > > established a VPN, it > > > > must > > > > > > not do any LIS discovery or HELD queries over the VPN > > connection. > > > > > > > > > > > > The Access Network, however, needs to have the > > requirement that > > > > > > its > > > > > LIS > > > > > > be able to know which subnets of IP addresses are supplied > to > > > > devices > > > > > > coming over VPN access, or have been provided to a > > company that > > > > > provides > > > > > > its own LIS. That is, such blocks of IP addresses need to be > > > > > > configurable in the LIS. Then there's the requirement > > that the > > > > > > LIS > > > > > must > > > > > > not provide location to these IP addresses. > > > > > > > > > > > > The access network (access provider + ISP) also has a > > > > > > responsibility > > > > > not > > > > > > to place a LIS on the core side of any NAT that is > > employed in > > > > > > the access network. Note that this isn't meant to > > apply to home > > > > > > router > > > > > NATs, > > > > > > since those aren't part of the access network, > > according to the > > > > > > definition of access network. > > > > > > > > > > > > I really think that the access network has greater > > ability, and > > > > > > therefore greater responsibility, to minimize the > > occurrence of > > > > > problems > > > > > > due to VPNs and NATs. > > > > > > > > > > > > As we discussed (Brian and I), I'm going to try to > > suggest a way > > > > > > to better include in phonebcp requirements for > > routers employed > > > > > > in > > > > "small > > > > > > areas". One of the requirements we need for these, is > > that they > > > > > > MUST > > > > > act > > > > > > as the LIS for LAN-side devices, when they have VPN > > connections > > > > > > to > > > > the > > > > > > WAN. > > > > > > Barbara > > > > > > > > > > > > -----Original Message----- > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > Sent: Thursday, November 01, 2007 4:03 AM > > > > > > To: 'Dawson, Martin'; 'Richard Barnes'; Stark, > > Barbara; 'ECRIT' > > > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > > > > > > asanidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > > > I think the problem that Barbara points out is precisely the > > > > > > problem > > > > > in > > > > > > deploying HELD. Claiming that a problem can't be solved, > and > > > > > therefore > > > > > > should not be mentioned is, uh, ?unhelpful? Having > > the "caveat" > > > > > instead > > > > > > of > > > > > > a deployment recommendation understates the problem. > > While it > > > > > > is possible to deploy HELD so that it almost always works, > it > > > > > > will take a lot of attention by a lot of entities to > > make that > > > > > > happen. For example, if HELD is deployed, no non-bypassable > > > > > > VPNs can be permitted. The protocol document should be very > > > > > > clear about what it takes to make HELD work. > > > > > > > > > > > > I have no problem including text that covers what devices > and > > > > > > LIS's > > > > > need > > > > > > to > > > > > > do, as long as it was noted that it won't always be > > sufficient. > > > > > > We might also include text on how enterprise networks > > should be > > > > > > configured. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > > > > > > > Sent: Wednesday, October 31, 2007 11:58 AM > > > > > > > To: Richard Barnes; Stark, Barbara; ECRIT > > > > > > > Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address > > > > asanidentifier > > > > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > > > > > I think that the "device" requirement at most should be > that > > > > efforts > > > > > > > should be made to ensure that the LIS is discovered > > and used > > > > > > > on > > > > the > > > > > > > physical access network and not via any VPN tunnel. > > > > > > > > > > > > > > Perhaps more importantly, there should be a complementary > > > > > requirement > > > > > > on > > > > > > > the LIS that it not attempt to provide location for an IP > > > > > > > address > > > > > that > > > > > > > it cannot associate a physical location with. For > > example, a > > > > > > > LIS > > > > in > > > > > an > > > > > > > enterprise, where that enterprise supports VPN > > access, should > > > > > > > know > > > > > or > > > > > > be > > > > > > > able to determine that the client requests are > > arriving over a > > > > > > > VPN > > > > > > from > > > > > > > an end point whose location cannot be determined. The HELD > > > > response > > > > > > > should indicate that location cannot be provided. > > > > > > > > > > > > > > Cheers, > > > > > > > Martin > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Richard Barnes [mailto:rbarnes@bbn.com] > > > > > > > Sent: Thursday, 1 November 2007 1:22 AM > > > > > > > To: Stark, Barbara; ECRIT > > > > > > > Subject: [Ecrit] Re: [Geopriv] Use of IP address as > > > > > > > anidentifier indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > > > > > Right, I think what's needed is more a caveat that HELD > > > > > > > provides > > > > the > > > > > > > location of the source IP address in the IP header of the > > > > > > > request > > > > -- > > > > > > > whatever that may be. > > > > > > > > > > > > > > --Richard > > > > > > > > > > > > > > > > > > > > > > > > > > > > Stark, Barbara wrote: > > > > > > > > How is a client supposed to know whether a "VPN, NAT or > > > > > > > > other IP > > > > > > > address > > > > > > > > modification exists between the client and the > > server which > > > > could > > > > > > > > produce incorrect location"? One of the best uses > > of HELD is > > > > > > > > the > > > > > > case > > > > > > > > where there is a NAT (and the box with the NAT is > location > > > > > unaware). > > > > > > > For > > > > > > > > landline broadband services, this NAT exists, but > doesn't > > > > produce > > > > > an > > > > > > > > incorrect location. So this NAT is ok. How can you > > > > > > > > distinguish > > > > > > between > > > > > > > a > > > > > > > > NAT that produces an incorrect location, vs. one that > > > > > > > > produces a > > > > > > > correct > > > > > > > > location? > > > > > > > > > > > > > > > > The VPN could be originated out of the router, and not > the > > > > client. > > > > > > How > > > > > > > > would the client know this VPN even exists? > > > > > > > > > > > > > > > > Unless you can tell me the logic to use to implement > this > > > > proposed > > > > > > > > requirement, I can't support it. > > > > > > > > Barbara > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Brian Rosen [mailto:br@brianrosen.net] > > > > > > > > Sent: Wednesday, October 31, 2007 8:51 AM > > > > > > > > To: geopriv@ietf.org > > > > > > > > Subject: [Geopriv] Use of IP address as an identifier > > > > > > > > indraft-ietf-geopriv-http-location-delivery > > > > > > > > > > > > > > > > In the long set of discussions that have lead to > > HELD, one > > > > > > > > of > > > > the > > > > > > > > biggest > > > > > > > > concerns a few of us have had is the problem than an IP > > > > > > > > address > > > > > may > > > > > > > not > > > > > > > > be a > > > > > > > > good identifier for determining the location of > > the client. > > > > There > > > > > > is > > > > > > > a > > > > > > > > draft that describes alternate identifiers. > > However, there > > > > > > > > is > > > > no > > > > > > > > discussion > > > > > > > > in the present draft of the base protocol on these > issues. > > > > > > > > > > > > > > > > I would like to propose that we add text something like: > > > > > > > > > > > > > > > > Use of HELD is subject to the viability of the > identifier > > > > > > > > used > > > > by > > > > > > the > > > > > > > > LIS to > > > > > > > > determine location. This document describes the > > use of the > > > > > > > > IP > > > > > > address > > > > > > > > of > > > > > > > > the client as the identifier. When a NAT, VPN or other > > > > > > > > forms of > > > > > > > address > > > > > > > > modification occur between the client and the server, > the > > > > location > > > > > > > > returned > > > > > > > > may be inaccurate. This is not always the case. For > > > > > > > > example, a > > > > > NAT > > > > > > > > used in > > > > > > > > a residential local area network is typically not > > a problem, > > > > > because > > > > > > > the > > > > > > > > external IP address used on the WAN side of the NAT is > in > > > > > > > > fact > > > > the > > > > > > > right > > > > > > > > identifier for all of the devices in the > > residence. On the > > > > other > > > > > > > hand, > > > > > > > > if > > > > > > > > there is a VPN between the client and the server, for > > > > > > > > example > > > > for > > > > > a > > > > > > > > teleworker, then the address seen by the server > > may not be > > > > > > > > the > > > > > right > > > > > > > > address > > > > > > > > to identify the location of the client. Where a VPN is > > > > deployed, > > > > > > > > clients > > > > > > > > often have the ability to bypass the VPN for a > > transaction > > > > > > > > like > > > > > > HELD. > > > > > > > > > > > > > > > > HELD Clients MUST NOT send HELD requests where IP > > address is > > > > > > > > the identifier and a VPN, NAT or other IP address > > > > > > > > modification exists between > > > > the > > > > > > > > client > > > > > > > > and the server which could produce incorrect > > location. HELD > > > > MUST > > > > > > NOT > > > > > > > be > > > > > > > > deployed in networks where the client cannot comply > > > > > > > > reasonably > > > > > > > reliably > > > > > > > > with > > > > > > > > that requirement. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > _______________________________________________ > 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 Nov 05 09:28:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2wB-0007DA-LW; Mon, 05 Nov 2007 09:28:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip2wA-00079H-Ot for ecrit@ietf.org; Mon, 05 Nov 2007 09:28:22 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Ip2w8-0007sY-AQ for ecrit@ietf.org; Mon, 05 Nov 2007 09:28:22 -0500 Received: (qmail invoked by alias); 05 Nov 2007 14:28:17 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp029) with SMTP; 05 Nov 2007 15:28:17 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18XzBAjFIcX5O6M/6J8bh1C6FWVHfiG/Z3GBpt9mt i3GX7D1YwuS6Ku Message-ID: <472F2880.1030000@gmx.net> Date: Mon, 05 Nov 2007 15:28:16 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Jean-Francois Mule References: <01da01c81d87$c75d4c70$2fea0446@cis.neustar.com> <00e701c81fad$9c55efa0$2d0d0d0a@cisco.com> <9AAEDF491EF7CA48AB587781B8F5D7C67DA6B2@srvxchg3.cablelabs.com> In-Reply-To: <9AAEDF491EF7CA48AB587781B8F5D7C67DA6B2@srvxchg3.cablelabs.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: eda4528ec6326d3504ad3a985d220c76 Cc: ECRIT Subject: [Ecrit] Applicability Statement 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 RFC 4776 and RFC 3825 do not contain an applicability statement either although the applicability of DHCP is also limited. Ciao Hannes Jean-Francois Mule wrote: > P-A-I (RFC 3325) is an example of a 'base' document that defines a > protocol mechanism and also contains an applicability statement. > > A suggestion may be to formulate what (deployment/implementation) > conditions make the protocol applicable to warn folks developing it when > they design the implementation, as opposed to listing many concerns or > negative cases. > > Jean-Francois. > > > >> -----Original Message----- >> From: Marc Linsner [mailto:mlinsner@cisco.com] >> Sent: Monday, November 05, 2007 6:13 AM >> To: 'Brian Rosen'; 'ECRIT' >> Subject: RE: [Ecrit] Re: [Geopriv] Use ofIPaddressasanidentifier >> indraft-ietf-geopriv-http-location-delivery >> >> Brian, >> >> IMO, applicability belongs in the base document. I believe there will >> be >> much difficulty moving the HELD draft through the IESG without strict >> usage >> guidelines included. >> >> -Marc- >> >> >> >>> -----Original Message----- >>> From: Brian Rosen [mailto:br@brianrosen.net] >>> Sent: Friday, November 02, 2007 3:37 PM >>> To: 'Thomson, Martin'; 'Stark, Barbara'; 'Dawson, Martin'; >>> 'Richard Barnes'; 'ECRIT' >>> Subject: RE: [Ecrit] Re: [Geopriv] Use of >>> IPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery >>> >>> Chair/AD opinion please >>> >>> I will write a BCP if we need it. I think that would be >>> silly, and the protocol document is the appropriate place for >>> documenting deployment concerns for the protocol. >>> >>> Brian >>> >>> >>>> -----Original Message----- >>>> From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] >>>> Sent: Thursday, November 01, 2007 5:32 PM >>>> To: Stark, Barbara; Brian Rosen; Dawson, Martin; Richard >>>> >>> Barnes; ECRIT >>> >>>> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP addressasanidentifier >>>> indraft-ietf-geopriv-http-location-delivery >>>> >>>> I have to strongly agree with Barbara. If -phone-bcp isn't >>>> >>> the right >>> >>>> place for these recommendations then someone can write another >>>> > BCP. > >>>>> -----Original Message----- >>>>> From: Stark, Barbara [mailto:bs7652@att.com] >>>>> Sent: Friday, 2 November 2007 1:39 AM >>>>> To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT >>>>> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP >>>>> >>> addressasanidentifier >>> >>>>> indraft-ietf-geopriv-http-location-delivery >>>>> >>>>> HELD is a protocol, purely and simply. It's not a BCP and >>>>> >>> cannot and >>> >>>>> should not attempt to use MUST and SHOULD language around >>>>> >>> behavior >>> >>>>> of devices and networks that use the protocol, outside of >>>>> requirements directly related to formatting of the >>>>> >>> protocol messages. >>> >>>>> Http-location-delivery MUST NOT contain normative language that >>>>> attempts to restrict the environment where HELD may be >>>>> >>> used. I have >>> >>>>> no problem with including a discussion of these issues in >>>>> >>> http-location-delivery. >>> >>>>> But if you want something stronger, it needs to be a BCP. Since >>>>> phonebcp only applies to use for emergency services, then I >>>>> >> guess >> >>>>> you'd need a more generic BCP out of geopriv. >>>>> >>>>> Since such a HELD BCP (from geopriv) may or may not be >>>>> >>> recognized by >>> >>>>> device manufacturers, I'd recommend making sure that >>>>> >>> phonebcp does >>> >>>>> have what's needed, as far as use of HELD for emergency >>>>> > services. > >>>>> Barbara >>>>> >>>>> -----Original Message----- >>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>> Sent: Thursday, November 01, 2007 10:10 AM >>>>> To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; 'ECRIT' >>>>> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address >>>>> >>> asanidentifier >>> >>>>> indraft-ietf-geopriv-http-location-delivery >>>>> >>>>> The text belongs in the HELD document because it has >>>>> >>> nothing to do >>> >>>>> with emergency calls. It affects all uses of HELD. >>>>> >>>>> I don't have a problem with expanding text in -phonebcp >>>>> >>>>> Brian >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Stark, Barbara [mailto:bs7652@att.com] >>>>>> Sent: Thursday, November 01, 2007 9:58 AM >>>>>> To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT >>>>>> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address >>>>>> asanidentifier indraft-ietf-geopriv-http-location-delivery >>>>>> >>>>>> I have no problem with your proposed verbiage >>>>>> >>> characterizing the >>> >>>>>> problem. >>>>>> >>>>>> I think that requirements on end devices using HELD and access >>>>>> >>>>> networks >>>>> >>>>>> providing HELD responses is a phonebcp issue, and not >>>>>> http-location-delivery. >>>>>> >>>>>> Within phonebcp, I think that enterprise networks (that are >>>>>> >> not >> >>>>>> able >>>>>> >>>>> to >>>>> >>>>>> control the capabilities of devices attaching to them) >>>>>> >>> are already >>> >>>>>> included in the definition of access network. That seems to >>>>>> currently >>>>>> >>>>> be >>>>> >>>>>> implicit, but perhaps it should be explicit. Then all >>>>>> >>> requirements >>> >>>>> that >>>>> >>>>>> apply to access networks will explicitly apply to such >>>>>> >>> enterprise >>> >>>>>> networks. I'm not sure I see what such enterprise >>>>>> >>> networks need to >>> >>>>>> do different than public access networks. You already have >>>>>> >> some >> >>>>>> VPN and >>>>>> >>>>> NAT >>>>> >>>>>> requirements there: >>>>>> AN-14 Network administrators MUST take care in assigning IP >>>>>> >>>>> addresses >>>>> >>>>>> such that VPN address assignments can be >>>>>> >>> distinguished from local >>> >>>>>> devices (by subnet choice, for example), and LISs should >>>>>> >> not >> >>>>> attempt >>>>> >>>>>> to provide location to addresses that arrive via VPN >>>>>> >>> connections. >>> >>>>>> AN-15 Placement of NAT devices should consider the effect >>>>>> >> of >> >>>>>> the >>>>>> >>>>> NAT >>>>> >>>>>> on the LCP. >>>>>> >>>>>> The device location update when the device has a VPN >>>>>> >>> established >>> >>>>>> that doesn't allow split tunneling is definitely a gap. >>>>>> >>> I think it >>> >>>>>> could be solved with some HELD extensions (which is a geopriv >>>>>> issue). That is, >>>>>> >>>>> I >>>>> >>>>>> think that if we allow the initial (pre-VPN) request to also >>>>>> negotiate identification and authentication for future >>>>>> > updates, > >>>>>> that we could solve the update problem. >>>>>> >>>>>> The intermediary SOHO (small office/home office) router >>>>>> >>> that sets >>> >>>>>> up >>>>>> >>>>> the >>>>> >>>>>> non-split tunneling VPN on behalf of its LAN needs to >>>>>> >>> be required >>> >>>>>> (in >>>>>> phonebcp) to act as the LIS for all devices in its LAN. That's >>>>>> part of the additional requirements I'm working on >>>>>> >>> providing you (Brian). >>> >>>>>> Barbara >>>>>> >>>>>> -----Original Message----- >>>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>>> Sent: Thursday, November 01, 2007 6:16 AM >>>>>> To: Stark, Barbara; 'Dawson, Martin'; 'Richard Barnes'; >>>>>> >> 'ECRIT' >> >>>>>> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address >>>>>> asanidentifier indraft-ietf-geopriv-http-location-delivery >>>>>> >>>>>> That's helpful. >>>>>> >>>>>> I don't think it's sufficient. My example, hardware >>>>>> >> VPN/tunnel >> >>>>>> mechanisms cannot be permitted, has to be spelled out. Also, >>>>>> phonebcp recommends location update at call time. We haven't >>>>>> worked out this detail, but >>>>>> >>>>> I >>>>> >>>>>> think we want to at least recommend that a mobile device send >>>>>> routing location as a value, and dispatch location as a >>>>>> >>> reference >>> >>>>>> (where needed), just to avoid the repeated dereference >>>>>> >>> by all call >>> >>>>>> routing elements. >>>>>> That >>>>>> means you would want to do the HELD LCP operation at call >>>>>> > time. > >>>>>> You need to discuss enterprise networks behind access networks >>>>>> that provide HELD, or try to use HELD within an enterprise >>>>>> network. >>>>>> >>>>>> I think it's hard to think through ALL the instances where an >>>>>> >> IP >> >>>>> address >>>>> >>>>>> isn't reliable as an identifier to be used for >>>>>> >>> location, which is >>> >>>>>> why >>>>>> >>>>> I >>>>> >>>>>> phrased my proposed text the way I did. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Stark, Barbara [mailto:bs7652@att.com] >>>>>>> Sent: Thursday, November 01, 2007 5:42 AM >>>>>>> To: Brian Rosen; Dawson, Martin; Richard Barnes; ECRIT >>>>>>> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address >>>>>>> asanidentifier indraft-ietf-geopriv-http-location-delivery >>>>>>> >>>>>>> Oh, fine, I'll try to be helpful, then. >>>>>>> I definitely agree with having the problem mentioned and >>>>>>> properly characterized. But when we write >>>>>>> >>> requirements, I want >>> >>>>>>> to be sure >>>>>>> >>>>> that >>>>> >>>>>>> the requirements are implementable. >>>>>>> >>>>>>> Certainly, end devices must do location configuration before >>>>>>> establishing a VPN. Once an end device has >>>>>>> >>> established a VPN, it >>> >>>>> must >>>>> >>>>>>> not do any LIS discovery or HELD queries over the VPN >>>>>>> >>> connection. >>> >>>>>>> The Access Network, however, needs to have the >>>>>>> >>> requirement that >>> >>>>>>> its >>>>>>> >>>>>> LIS >>>>>> >>>>>>> be able to know which subnets of IP addresses are supplied >>>>>>> >> to >> >>>>> devices >>>>> >>>>>>> coming over VPN access, or have been provided to a >>>>>>> >>> company that >>> >>>>>> provides >>>>>> >>>>>>> its own LIS. That is, such blocks of IP addresses need to be >>>>>>> configurable in the LIS. Then there's the requirement >>>>>>> >>> that the >>> >>>>>>> LIS >>>>>>> >>>>>> must >>>>>> >>>>>>> not provide location to these IP addresses. >>>>>>> >>>>>>> The access network (access provider + ISP) also has a >>>>>>> responsibility >>>>>>> >>>>>> not >>>>>> >>>>>>> to place a LIS on the core side of any NAT that is >>>>>>> >>> employed in >>> >>>>>>> the access network. Note that this isn't meant to >>>>>>> >>> apply to home >>> >>>>>>> router >>>>>>> >>>>>> NATs, >>>>>> >>>>>>> since those aren't part of the access network, >>>>>>> >>> according to the >>> >>>>>>> definition of access network. >>>>>>> >>>>>>> I really think that the access network has greater >>>>>>> >>> ability, and >>> >>>>>>> therefore greater responsibility, to minimize the >>>>>>> >>> occurrence of >>> >>>>>> problems >>>>>> >>>>>>> due to VPNs and NATs. >>>>>>> >>>>>>> As we discussed (Brian and I), I'm going to try to >>>>>>> >>> suggest a way >>> >>>>>>> to better include in phonebcp requirements for >>>>>>> >>> routers employed >>> >>>>>>> in >>>>>>> >>>>> "small >>>>> >>>>>>> areas". One of the requirements we need for these, is >>>>>>> >>> that they >>> >>>>>>> MUST >>>>>>> >>>>>> act >>>>>> >>>>>>> as the LIS for LAN-side devices, when they have VPN >>>>>>> >>> connections >>> >>>>>>> to >>>>>>> >>>>> the >>>>> >>>>>>> WAN. >>>>>>> Barbara >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>>>> Sent: Thursday, November 01, 2007 4:03 AM >>>>>>> To: 'Dawson, Martin'; 'Richard Barnes'; Stark, >>>>>>> >>> Barbara; 'ECRIT' >>> >>>>>>> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address >>>>>>> asanidentifier indraft-ietf-geopriv-http-location-delivery >>>>>>> >>>>>>> I think the problem that Barbara points out is precisely the >>>>>>> problem >>>>>>> >>>>>> in >>>>>> >>>>>>> deploying HELD. Claiming that a problem can't be solved, >>>>>>> >> and >> >>>>>> therefore >>>>>> >>>>>>> should not be mentioned is, uh, ?unhelpful? Having >>>>>>> >>> the "caveat" >>> >>>>>> instead >>>>>> >>>>>>> of >>>>>>> a deployment recommendation understates the problem. >>>>>>> >>> While it >>> >>>>>>> is possible to deploy HELD so that it almost always works, >>>>>>> >> it >> >>>>>>> will take a lot of attention by a lot of entities to >>>>>>> >>> make that >>> >>>>>>> happen. For example, if HELD is deployed, no non-bypassable >>>>>>> VPNs can be permitted. The protocol document should be very >>>>>>> clear about what it takes to make HELD work. >>>>>>> >>>>>>> I have no problem including text that covers what devices >>>>>>> >> and >> >>>>>>> LIS's >>>>>>> >>>>>> need >>>>>> >>>>>>> to >>>>>>> do, as long as it was noted that it won't always be >>>>>>> >>> sufficient. >>> >>>>>>> We might also include text on how enterprise networks >>>>>>> >>> should be >>> >>>>>>> configured. >>>>>>> >>>>>>> Brian >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] >>>>>>>> Sent: Wednesday, October 31, 2007 11:58 AM >>>>>>>> To: Richard Barnes; Stark, Barbara; ECRIT >>>>>>>> Subject: RE: [Ecrit] Re: [Geopriv] Use of IP address >>>>>>>> >>>>> asanidentifier >>>>> >>>>>>>> indraft-ietf-geopriv-http-location-delivery >>>>>>>> >>>>>>>> I think that the "device" requirement at most should be >>>>>>>> >> that >> >>>>> efforts >>>>> >>>>>>>> should be made to ensure that the LIS is discovered >>>>>>>> >>> and used >>> >>>>>>>> on >>>>>>>> >>>>> the >>>>> >>>>>>>> physical access network and not via any VPN tunnel. >>>>>>>> >>>>>>>> Perhaps more importantly, there should be a complementary >>>>>>>> >>>>>> requirement >>>>>> >>>>>>> on >>>>>>> >>>>>>>> the LIS that it not attempt to provide location for an IP >>>>>>>> address >>>>>>>> >>>>>> that >>>>>> >>>>>>>> it cannot associate a physical location with. For >>>>>>>> >>> example, a >>> >>>>>>>> LIS >>>>>>>> >>>>> in >>>>> >>>>>> an >>>>>> >>>>>>>> enterprise, where that enterprise supports VPN >>>>>>>> >>> access, should >>> >>>>>>>> know >>>>>>>> >>>>>> or >>>>>> >>>>>>> be >>>>>>> >>>>>>>> able to determine that the client requests are >>>>>>>> >>> arriving over a >>> >>>>>>>> VPN >>>>>>>> >>>>>>> from >>>>>>> >>>>>>>> an end point whose location cannot be determined. The HELD >>>>>>>> >>>>> response >>>>> >>>>>>>> should indicate that location cannot be provided. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Martin >>>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Richard Barnes [mailto:rbarnes@bbn.com] >>>>>>>> Sent: Thursday, 1 November 2007 1:22 AM >>>>>>>> To: Stark, Barbara; ECRIT >>>>>>>> Subject: [Ecrit] Re: [Geopriv] Use of IP address as >>>>>>>> anidentifier indraft-ietf-geopriv-http-location-delivery >>>>>>>> >>>>>>>> Right, I think what's needed is more a caveat that HELD >>>>>>>> provides >>>>>>>> >>>>> the >>>>> >>>>>>>> location of the source IP address in the IP header of the >>>>>>>> request >>>>>>>> >>>>> -- >>>>> >>>>>>>> whatever that may be. >>>>>>>> >>>>>>>> --Richard >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Stark, Barbara wrote: >>>>>>>> >>>>>>>>> How is a client supposed to know whether a "VPN, NAT or >>>>>>>>> other IP >>>>>>>>> >>>>>>>> address >>>>>>>> >>>>>>>>> modification exists between the client and the >>>>>>>>> >>> server which >>> >>>>> could >>>>> >>>>>>>>> produce incorrect location"? One of the best uses >>>>>>>>> >>> of HELD is >>> >>>>>>>>> the >>>>>>>>> >>>>>>> case >>>>>>> >>>>>>>>> where there is a NAT (and the box with the NAT is >>>>>>>>> >> location >> >>>>>> unaware). >>>>>> >>>>>>>> For >>>>>>>> >>>>>>>>> landline broadband services, this NAT exists, but >>>>>>>>> >> doesn't >> >>>>> produce >>>>> >>>>>> an >>>>>> >>>>>>>>> incorrect location. So this NAT is ok. How can you >>>>>>>>> distinguish >>>>>>>>> >>>>>>> between >>>>>>> >>>>>>>> a >>>>>>>> >>>>>>>>> NAT that produces an incorrect location, vs. one that >>>>>>>>> produces a >>>>>>>>> >>>>>>>> correct >>>>>>>> >>>>>>>>> location? >>>>>>>>> >>>>>>>>> The VPN could be originated out of the router, and not >>>>>>>>> >> the >> >>>>> client. >>>>> >>>>>>> How >>>>>>> >>>>>>>>> would the client know this VPN even exists? >>>>>>>>> >>>>>>>>> Unless you can tell me the logic to use to implement >>>>>>>>> >> this >> >>>>> proposed >>>>> >>>>>>>>> requirement, I can't support it. >>>>>>>>> Barbara >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Brian Rosen [mailto:br@brianrosen.net] >>>>>>>>> Sent: Wednesday, October 31, 2007 8:51 AM >>>>>>>>> To: geopriv@ietf.org >>>>>>>>> Subject: [Geopriv] Use of IP address as an identifier >>>>>>>>> indraft-ietf-geopriv-http-location-delivery >>>>>>>>> >>>>>>>>> In the long set of discussions that have lead to >>>>>>>>> >>> HELD, one >>> >>>>>>>>> of >>>>>>>>> >>>>> the >>>>> >>>>>>>>> biggest >>>>>>>>> concerns a few of us have had is the problem than an IP >>>>>>>>> address >>>>>>>>> >>>>>> may >>>>>> >>>>>>>> not >>>>>>>> >>>>>>>>> be a >>>>>>>>> good identifier for determining the location of >>>>>>>>> >>> the client. >>> >>>>> There >>>>> >>>>>>> is >>>>>>> >>>>>>>> a >>>>>>>> >>>>>>>>> draft that describes alternate identifiers. >>>>>>>>> >>> However, there >>> >>>>>>>>> is >>>>>>>>> >>>>> no >>>>> >>>>>>>>> discussion >>>>>>>>> in the present draft of the base protocol on these >>>>>>>>> >> issues. >> >>>>>>>>> I would like to propose that we add text something like: >>>>>>>>> >>>>>>>>> Use of HELD is subject to the viability of the >>>>>>>>> >> identifier >> >>>>>>>>> used >>>>>>>>> >>>>> by >>>>> >>>>>>> the >>>>>>> >>>>>>>>> LIS to >>>>>>>>> determine location. This document describes the >>>>>>>>> >>> use of the >>> >>>>>>>>> IP >>>>>>>>> >>>>>>> address >>>>>>> >>>>>>>>> of >>>>>>>>> the client as the identifier. When a NAT, VPN or other >>>>>>>>> forms of >>>>>>>>> >>>>>>>> address >>>>>>>> >>>>>>>>> modification occur between the client and the server, >>>>>>>>> >> the >> >>>>> location >>>>> >>>>>>>>> returned >>>>>>>>> may be inaccurate. This is not always the case. For >>>>>>>>> example, a >>>>>>>>> >>>>>> NAT >>>>>> >>>>>>>>> used in >>>>>>>>> a residential local area network is typically not >>>>>>>>> >>> a problem, >>> >>>>>> because >>>>>> >>>>>>>> the >>>>>>>> >>>>>>>>> external IP address used on the WAN side of the NAT is >>>>>>>>> >> in >> >>>>>>>>> fact >>>>>>>>> >>>>> the >>>>> >>>>>>>> right >>>>>>>> >>>>>>>>> identifier for all of the devices in the >>>>>>>>> >>> residence. On the >>> >>>>> other >>>>> >>>>>>>> hand, >>>>>>>> >>>>>>>>> if >>>>>>>>> there is a VPN between the client and the server, for >>>>>>>>> example >>>>>>>>> >>>>> for >>>>> >>>>>> a >>>>>> >>>>>>>>> teleworker, then the address seen by the server >>>>>>>>> >>> may not be >>> >>>>>>>>> the >>>>>>>>> >>>>>> right >>>>>> >>>>>>>>> address >>>>>>>>> to identify the location of the client. Where a VPN is >>>>>>>>> >>>>> deployed, >>>>> >>>>>>>>> clients >>>>>>>>> often have the ability to bypass the VPN for a >>>>>>>>> >>> transaction >>> >>>>>>>>> like >>>>>>>>> >>>>>>> HELD. >>>>>>> >>>>>>>>> HELD Clients MUST NOT send HELD requests where IP >>>>>>>>> >>> address is >>> >>>>>>>>> the identifier and a VPN, NAT or other IP address >>>>>>>>> modification exists between >>>>>>>>> >>>>> the >>>>> >>>>>>>>> client >>>>>>>>> and the server which could produce incorrect >>>>>>>>> >>> location. HELD >>> >>>>> MUST >>>>> >>>>>>> NOT >>>>>>> >>>>>>>> be >>>>>>>> >>>>>>>>> deployed in networks where the client cannot comply >>>>>>>>> reasonably >>>>>>>>> >>>>>>>> reliably >>>>>>>> >>>>>>>>> with >>>>>>>>> that requirement. >>>>>>>>> >>>>>>>>> >>>>> _______________________________________________ >>>>> 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 >> > > > _______________________________________________ > 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 Nov 05 10:12:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip3cz-0005GN-H3; Mon, 05 Nov 2007 10:12:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip3cy-0005FV-8N for ecrit@ietf.org; Mon, 05 Nov 2007 10:12:36 -0500 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 1Ip3cx-0000mD-Qv for ecrit@ietf.org; Mon, 05 Nov 2007 10:12:36 -0500 X-IronPort-AV: E=Sophos;i="4.21,373,1188802800"; d="scan'208";a="543253831" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 05 Nov 2007 07:12:34 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA5FCY7g017030; Mon, 5 Nov 2007 07:12:34 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lA5FC1vu003583; Mon, 5 Nov 2007 15:12:34 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 10:12:01 -0500 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 10:11:57 -0500 From: "Marc Linsner" To: "'Hannes Tschofenig'" Date: Mon, 5 Nov 2007 10:11:57 -0500 Message-ID: <00f501c81fbe$3548cd30$2d0d0d0a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgfuCQXaCcia68+RUOuTwijqtJ+egAArdPA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <472F2880.1030000@gmx.net> X-OriginalArrivalTime: 05 Nov 2007 15:11:57.0930 (UTC) FILETIME=[355884A0:01C81FBE] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15522.000 X-TM-AS-Result: No--1.753700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1422; t=1194275554; x=1195139554; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20Applicability=20Statement |Sender:=20; bh=HCi0ACBpap8uAay7ohU+cil7Y8bkwUCM4/i1Bp6dGx8=; b=hYG9HQowo8177+xgrDOqWXXxnmSMjsMNdkdtNyBL0hQZkUVx9S91QfjCVvlagtK2h3JJcWXu eMyyHqtxpdJIE99nZG2otbdgTeRITJ2XPcW9Y9FFIUSImK5eI4bWM4WO; Authentication-Results: sj-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: 'ECRIT' Subject: [Ecrit] RE: Applicability Statement 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, > > RFC 4776 and RFC 3825 do not contain an applicability > statement either although the applicability of DHCP is also limited. The applicability of DHCP is well known, stated elsewhere and not required in drafts that are simply adding options. The applicability of the option is prudent. An example of an applicability statement from RFC 3825: " The goal of this option is to enable a wired Ethernet host to obtain its location, which it could provide to an emergency responder, as one example. Wireless hosts can utilize this option to gain knowledge of the location of the radio access point used during host configuration, but would need some more exotic mechanisms, maybe GPS, or maybe a future DHCP option, which includes a list of geo-locations like that defined here, containing the locations of the radio access points that are close to the client. " The intent of the above is a state this option is most applicable to wired Ethernet hosts. As I stated in other emails, IMO, if you don't provide words in the base draft that provide guidance to utilizing IP address as the identifier for location lookup, the IESG will immediately come back and ask what happens when the host is behind NATs and/or VPN tunnels. Yes, such guidance will appear to restrict the usage of the protocol, but it's certainly best that everyone know that prior to implementation. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 05 10:21:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip3lX-0004sS-SU; Mon, 05 Nov 2007 10:21:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip3lX-0004sK-3y for ecrit@ietf.org; Mon, 05 Nov 2007 10:21:27 -0500 Received: from demumfd001.nsn-inter.net ([217.115.75.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip3lV-00013G-15 for ecrit@ietf.org; Mon, 05 Nov 2007 10:21:27 -0500 Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id lA5FLI7j004666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Nov 2007 16:21:18 +0100 Received: from demuexc023.nsn-intra.net (webmail.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id lA5FLDc9023053; Mon, 5 Nov 2007 16:21:17 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 16:21:15 +0100 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] RE: Applicability Statement Date: Mon, 5 Nov 2007 16:21:14 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB4C5159@DEMUEXC012.nsn-intra.net> In-Reply-To: <00f501c81fbe$3548cd30$2d0d0d0a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] RE: Applicability Statement Thread-Index: AcgfuCQXaCcia68+RUOuTwijqtJ+egAArdPAAAEjV2A= References: <472F2880.1030000@gmx.net> <00f501c81fbe$3548cd30$2d0d0d0a@cisco.com> From: "Tschofenig, Hannes (NSN - DE/Munich)" To: "ext Marc Linsner" , "Hannes Tschofenig" X-OriginalArrivalTime: 05 Nov 2007 15:21:15.0419 (UTC) FILETIME=[81A296B0:01C81FBF] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 But this text relates more to the supported location shapes rather to = the usage of DHCP for conveying location information as such.=20 Ciao Hannes =20 > -----Urspr=FCngliche Nachricht----- > Von: ext Marc Linsner [mailto:mlinsner@cisco.com]=20 > Gesendet: Montag, 5. November 2007 16:12 > An: 'Hannes Tschofenig' > Cc: 'ECRIT' > Betreff: [Ecrit] RE: Applicability Statement >=20 > Hannes, > >=20 > > RFC 4776 and RFC 3825 do not contain an applicability=20 > > statement either although the applicability of DHCP is also limited. >=20 > The applicability of DHCP is well known, stated elsewhere and=20 > not required > in drafts that are simply adding options. The applicability=20 > of the option > is prudent. An example of an applicability statement from RFC 3825: >=20 > " > The goal of this option is to enable a wired Ethernet host to=20 > obtain its > location, which it could provide to an emergency responder,=20 > as one example. >=20 > Wireless hosts can utilize this option to gain knowledge of=20 > the location of > the radio access point used during host configuration, but=20 > would need some > more exotic mechanisms, maybe GPS, or maybe a future DHCP=20 > option, which > includes a list of geo-locations like that defined here,=20 > containing the > locations of the radio access points that are close to the client. > " >=20 > The intent of the above is a state this option is most=20 > applicable to wired > Ethernet hosts. >=20 > As I stated in other emails, IMO, if you don't provide words=20 > in the base > draft that provide guidance to utilizing IP address as the=20 > identifier for > location lookup, the IESG will immediately come back and ask=20 > what happens > when the host is behind NATs and/or VPN tunnels. Yes, such=20 > guidance will > appear to restrict the usage of the protocol, but it's=20 > certainly best that > everyone know that prior to implementation. >=20 > -Marc- >=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 Mon Nov 05 10:51:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip4ED-0004s5-Sd; Mon, 05 Nov 2007 10:51:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip4EC-0004ou-Hs for ecrit@ietf.org; Mon, 05 Nov 2007 10:51:04 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip4EC-0001bz-26 for ecrit@ietf.org; Mon, 05 Nov 2007 10:51:04 -0500 X-SEF-Processed: 5_0_0_910__2007_11_05_10_01_26 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 05 Nov 2007 10:01:26 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Nov 2007 09:51:01 -0600 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 Subject: RE: [Ecrit] Re: [Geopriv] Use ofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Date: Mon, 5 Nov 2007 09:51:00 -0600 Message-ID: In-Reply-To: <00eb01c81fb3$151e3f50$2d0d0d0a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] Use ofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYAAudC4wAFtIv9AABPXvIA== References: <00eb01c81fb3$151e3f50$2d0d0d0a@cisco.com> From: "Winterbottom, James" To: "Marc Linsner" , "ECRIT" X-OriginalArrivalTime: 05 Nov 2007 15:51:01.0468 (UTC) FILETIME=[AA3409C0:01C81FC3] X-Spam-Score: 1.8 (+) 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 Marc,=20=0D=0AInline.=0D=0A=0D=0A=0D=0A>=20=0D=0A> 2) In the case of a soft= ware VPN client, it is assumed the end host=0D=0A> receives=0D=0A> configur= ation information prior to establishment of the tunnel. It=0D=0Ahas=0D=0A>= been=0D=0A> stated many times the end host must utilize the location recei= ved=0D=0Aduring=0D=0A> the=0D=0A> first step, prior to tunnel establishment= =2E It would also be prudent=0D=0Athat=0D=0A> location information not be = passed during tunnel establishment.=0D=0A=0D=0A[AJW] Assumptions are always= dangerous. Why is it okay for you to assume=0D=0Athis for DHCP but it is n= ot okay for HELD to make the same assumption=3F=0D=0ASeems like yet another= double standard to me.=0D=0A=0D=0A>=20=0D=0A> 3) In the case of a hardware= VPN it is typical that the remote device=0D=0A> co-located with the end ho= st provides network configuration. Location=0D=0Acan=0D=0A> be included at= that time.=0D=0A=0D=0A[AJW] Where does the remote device get it from=3F If= it is a PPP-based=0D=0Adevice it would have to be manually configured, sur= ely you are not=0D=0Asuggesting that this is a good option=3F I can equally= well put a HELD=0D=0Aserver in my local router and do the same thing.=20=0D= =0A=0D=0A> >=0D=0A> > A simple HELD-based LIS/relay-service added to a home= router=0D=0A> > will avoid the issues that have been described by Brian to=0D= =0A> > the same degree that they are avoided by DHCP. This is very=0D=0A> >= easy to do and we have made this work in OpenWRT running on a=0D=0A> > lin= ksys home-router.=0D=0A>=20=0D=0A> 4) This would not work in the typical ha= rdware VPN environment.=0D=0A=0D=0A[AJW] Actually see point 3, it works jus= t as well as the DHCP option you=0D=0Ahave suggested.=0D=0A=0D=0A>=20=0D=0A= > 5) I assume you are not suggesting home users to run OpenWRT..=3F=0D=0A=0D= =0A[AJW] It works and it is reliable, but I don't need it in order to run=0D= =0AHELD in 95% of cases, and I don't have to upgrade the home router and=0D= =0Aall of the intervening network connectivity to support DHCP either... ;)=0D= =0A=0D=0A>=20=0D=0A> I am not keen to start describing these=0D=0A> > kinds= of solutions in the base HELD specification, a BCP is=0D=0A> > more approp= riate, though a mention of care would seem reasonable.=0D=0A>=20=0D=0A> 6) = As I stated in another email, in my experience, the IESG will want=0D=0A> a= pplicability included in the base draft, but I'm continually=0D=0Asurprised= by=0D=0A> the IESG... :^)=0D=0A>=20=0D=0A>=20=0D=0A> -Marc-=0D=0A>=20=0D=0A= >=20=0D=0A=0D=0A-----------------------------------------------------------= -------------------------------------=0D=0AThis message is for the designat= ed recipient only and may=0D=0Acontain privileged, proprietary, or otherwis= e private information. =20=0D=0AIf you have received it in error, please no= tify the sender=0D=0Aimmediately and delete the original. Any unauthorized= use of=0D=0Athis email is prohibited.=0D=0A-------------------------------= -----------------------------------------------------------------=0D=0A[mf2= ]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 05 11:46:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip565-0005d8-IC; Mon, 05 Nov 2007 11:46:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip563-0005Zc-Ai for ecrit@ietf.org; Mon, 05 Nov 2007 11:46:43 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip562-0003Bv-ST for ecrit@ietf.org; Mon, 05 Nov 2007 11:46:43 -0500 X-IronPort-AV: E=Sophos;i="4.21,373,1188792000"; d="scan'208";a="75271797" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 05 Nov 2007 11:46:42 -0500 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/8.12.11) with ESMTP id lA5GkglL019194; Mon, 5 Nov 2007 11:46:42 -0500 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 lA5GkXfu002834; Mon, 5 Nov 2007 16:46:42 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 11:46:34 -0500 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 11:46:22 -0500 From: "Marc Linsner" To: "'Tschofenig, Hannes \(NSN - DE/Munich\)'" , "'Hannes Tschofenig'" Subject: RE: [Ecrit] RE: Applicability Statement Date: Mon, 5 Nov 2007 11:46:21 -0500 Message-ID: <00fd01c81fcb$65d1f5a0$2d0d0d0a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgfuCQXaCcia68+RUOuTwijqtJ+egAArdPAAAEjV2AAAZi9UA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <5FB585F183235B42A9E70095055136FB4C5159@DEMUEXC012.nsn-intra.net> X-OriginalArrivalTime: 05 Nov 2007 16:46:22.0890 (UTC) FILETIME=[65ECD0A0:01C81FCB] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15522.000 X-TM-AS-Result: No--7.207400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2154; t=1194281202; x=1195145202; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20RE=3A=20Applicability=20Statement |Sender:=20 |To:=20=22'Tschofenig, =20Hannes=20\(NSN=20-=20DE/Munich\)'=22=20, =0A=20=20=20=20=20=20=20=20=22'Hannes=20Tschofenig'=22= 20; bh=wzEfpbA5B7M2I3/i8kHpq5IS0rbg+MhAatFIXO8nCKM=; b=ogPxAnniSFaviySlxNDi+Da9/+SvXpqzXipM33yfbX3KOfnrEVTetxyZuANT+sjttA1E+98n CFyimiI1YEueGvApRXgeL3myWzXgutmvlybsSd7HQj/JmeRpdR2CUOrR; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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, > > But this text relates more to the supported location shapes > rather to the usage of DHCP for conveying location > information as such. > No, the text relates to the applicability of utilizing DHCP as the LCP for wired and wireless end hosts. I don't see any reference to location shapes....?? What am I missing? -Marc- > > Hannes, > > > > > > RFC 4776 and RFC 3825 do not contain an applicability statement > > > either although the applicability of DHCP is also limited. > > > > The applicability of DHCP is well known, stated elsewhere and not > > required in drafts that are simply adding options. The > applicability > > of the option is prudent. An example of an applicability statement > > from RFC 3825: > > > > " > > The goal of this option is to enable a wired Ethernet host > to obtain > > its location, which it could provide to an emergency > responder, as one > > example. > > > > Wireless hosts can utilize this option to gain knowledge of the > > location of the radio access point used during host > configuration, but > > would need some more exotic mechanisms, maybe GPS, or maybe > a future > > DHCP option, which includes a list of geo-locations like > that defined > > here, containing the locations of the radio access points that are > > close to the client. > > " > > > > The intent of the above is a state this option is most > applicable to > > wired Ethernet hosts. > > > > As I stated in other emails, IMO, if you don't provide words in the > > base draft that provide guidance to utilizing IP address as the > > identifier for location lookup, the IESG will immediately come back > > and ask what happens when the host is behind NATs and/or > VPN tunnels. > > Yes, such guidance will appear to restrict the usage of the > protocol, > > but it's certainly best that everyone know that prior to > > implementation. > > > > -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 Mon Nov 05 11:46:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip568-0005jR-OU; Mon, 05 Nov 2007 11:46:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip567-0005fv-12 for ecrit@ietf.org; Mon, 05 Nov 2007 11:46:47 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip565-00032M-Qd for ecrit@ietf.org; Mon, 05 Nov 2007 11:46:47 -0500 X-IronPort-AV: E=Sophos;i="4.21,373,1188792000"; d="scan'208";a="136151369" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 05 Nov 2007 11:46:45 -0500 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/8.12.11) with ESMTP id lA5GkgpJ022480; Mon, 5 Nov 2007 11:46:42 -0500 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 lA5GkXfs002834; Mon, 5 Nov 2007 16:46:38 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 11:46:33 -0500 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 11:46:22 -0500 From: "Marc Linsner" To: "'Winterbottom, James'" , "'ECRIT'" Subject: RE: [Ecrit] Re: [Geopriv] Use ofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Date: Mon, 5 Nov 2007 11:46:21 -0500 Message-ID: <00fc01c81fcb$655ac9d0$2d0d0d0a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYAAudC4wAFtIv9AABPXvIAAA8vLA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: X-OriginalArrivalTime: 05 Nov 2007 16:46:22.0124 (UTC) FILETIME=[6577EEC0:01C81FCB] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15522.000 X-TM-AS-Result: No--13.779400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3216; t=1194281205; x=1195145205; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Re=3A=20[Geopriv]=20Use=20ofIPaddressasanid entifier=09indraft-ietf-geopriv-http-location-delivery |Sender:=20 |To:=20=22'Winterbottom, =20James'=22=20, =0 A=20=20=20=20=20=20=20=20=22'ECRIT'=22=20; bh=Ar7g3BDzjxdBt/lnbBxOHxYt5ysObR1w/ufjM/bcfZw=; b=R/xnYz59nQRdhWweZsMzZ6CPOs9CsuWP7dsN5QQE5+jwho/kI92ogA/SXXP7WlkdWoauOq7U /R3opozd2OWycqOHyzqpaTO1og04ARac98MWK5XCe1m6gD3dP3Nr72NO; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 James, This thread has mutated from the topic of using IP address identifier in HELD. In-line... > > > > > 2) In the case of a software VPN client, it is assumed the end host > > receives > > configuration information prior to establishment of the tunnel. It > has > > been > > stated many times the end host must utilize the location received > during > > the > > first step, prior to tunnel establishment. It would also be prudent > that > > location information not be passed during tunnel establishment. > > [AJW] Assumptions are always dangerous. Why is it okay for > you to assume > this for DHCP but it is not okay for HELD to make the same assumption? > Seems like yet another double standard to me. This assumption is not dangerous. If the end host does not have local network configuration/knowledge, the software VPN cannot be established. Certainly, after establishing network connectivity, the end host could perform a HELD query for location. But using HELD for location discovery after establishment of the VPN tunnel (original topic of this thread) will likely fail. The two failure modes are: The VPN client does not allow traffic to the local network, or the VPN tunnel is the primary route and the HELD server is off-net. > > > > > 3) In the case of a hardware VPN it is typical that the > remote device > > co-located with the end host provides network > configuration. Location > can > > be included at that time. > > [AJW] Where does the remote device get it from? If it is a PPP-based > device it would have to be manually configured, surely you are not > suggesting that this is a good option? I can equally well put a HELD > server in my local router and do the same thing. > Remote device = hardware VPN box. The normal implementation for this device is to sit behind the home gateway/router/firewall, parallel to the home network. I have no problem manually configuring such a box with location for distribution. Typically, end hosts that are connected to the remote device have no knowledge of the home network, nor connectivity to it, hence an end host connecting behind this remote device could not use HELD to discover location from the home network or local SP. > > > > > > A simple HELD-based LIS/relay-service added to a home router > > > will avoid the issues that have been described by Brian to > > > the same degree that they are avoided by DHCP. This is very > > > easy to do and we have made this work in OpenWRT running on a > > > linksys home-router. > > > > 4) This would not work in the typical hardware VPN environment. > > [AJW] Actually see point 3, it works just as well as the DHCP > option you > have suggested. No, it does not/would not work. > > > > > 5) I assume you are not suggesting home users to run OpenWRT..? > > [AJW] It works and it is reliable, but I don't need it in order to run > HELD in 95% of cases, and I don't have to upgrade the home router and > all of the intervening network connectivity to support DHCP > either... ;) Then I suggest you include such verbiage in the HELD draft and see if the IESG accepts it. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 05 12:02:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip5L7-0006ZM-Aa; Mon, 05 Nov 2007 12:02:17 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip5L6-0006YM-MX for ecrit@ietf.org; Mon, 05 Nov 2007 12:02:16 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip5L6-0003m0-6v for ecrit@ietf.org; Mon, 05 Nov 2007 12:02:16 -0500 X-SEF-Processed: 5_0_0_910__2007_11_05_11_12_36 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 05 Nov 2007 11:12:36 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Nov 2007 11:02:11 -0600 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 Subject: RE: [Ecrit] Re: [Geopriv] Use ofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Date: Mon, 5 Nov 2007 11:02:10 -0600 Message-ID: In-Reply-To: <00fc01c81fcb$655ac9d0$2d0d0d0a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Re: [Geopriv] Use ofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYAAudC4wAFtIv9AABPXvIAAA8vLAAAGRWrA= References: <00fc01c81fcb$655ac9d0$2d0d0d0a@cisco.com> From: "Winterbottom, James" To: "Marc Linsner" , "ECRIT" X-OriginalArrivalTime: 05 Nov 2007 17:02:11.0715 (UTC) FILETIME=[9B780530:01C81FCD] X-Spam-Score: 1.8 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 =0D=0A=0D=0AInline,=0D=0A=0D=0A> > >=0D=0A> > > 3) In the case of a hardwar= e VPN it is typical that the=0D=0A> > remote device=0D=0A> > > co-located w= ith the end host provides network=0D=0A> > configuration. Location=0D=0A> = > can=0D=0A> > > be included at that time.=0D=0A> >=0D=0A> > [AJW] Where do= es the remote device get it from=3F If it is a PPP-based=0D=0A> > device it= would have to be manually configured, surely you are not=0D=0A> > suggesti= ng that this is a good option=3F I can equally well put a HELD=0D=0A> > ser= ver in my local router and do the same thing.=0D=0A> >=0D=0A>=20=0D=0A> Rem= ote device =3D hardware VPN box. The normal implementation for this=0D=0A>= device=0D=0A> is to sit behind the home gateway/router/firewall, parallel = to the=0D=0Ahome=0D=0A> network. I have no problem manually configuring su= ch a box with=0D=0Alocation=0D=0A> for distribution. Typically, end hosts = that are connected to the=0D=0Aremote=0D=0A> device have no knowledge of th= e home network, nor connectivity to it,=0D=0A> hence=0D=0A> an end host con= necting behind this remote device could not use HELD to=0D=0A> discover loc= ation from the home network or local SP.=0D=0A=0D=0A[AJW] huh=3F=3F LIS Dis= covery clearly states that a DHCP option can be used=0D=0Ato provide the id= entity of the LIS to the end-device. There is=0D=0Aabsolutely nothing stopi= ng this URL from pointing to a location object=0D=0Aon the hardware box. In= fact if it has a webserver running on it (as=0D=0Amost home routers do) th= en you have 90% of the HELD server already in=0D=0Aplace. Supporting manual= location configuration and a new DHCP option is=0D=0Athe same amount for w= ork for either solution.=0D=0A=0D=0A>=20=0D=0A> > > >=0D=0A> > > > A simple= HELD-based LIS/relay-service added to a home router=0D=0A> > > > will avoi= d the issues that have been described by Brian to=0D=0A> > > > the same deg= ree that they are avoided by DHCP. This is very=0D=0A> > > > easy to do and= we have made this work in OpenWRT running on a=0D=0A> > > > linksys home-r= outer.=0D=0A> > >=0D=0A> > > 4) This would not work in the typical hardware= VPN environment.=0D=0A> >=0D=0A> > [AJW] Actually see point 3, it works ju= st as well as the DHCP=0D=0A> > option you=0D=0A> > have suggested.=0D=0A> =0D= =0A> No, it does not/would not work.=0D=0A=0D=0A[AJW] I think it does, plea= se at my clarified response to 3.=0D=0A=0D=0A>=20=0D=0A>=20=0D=0A> >=0D=0A>= > >=0D=0A> > > 5) I assume you are not suggesting home users to run OpenWR= T..=3F=0D=0A> >=0D=0A> > [AJW] It works and it is reliable, but I don't nee= d it in order to=0D=0Arun=0D=0A> > HELD in 95% of cases, and I don't have t= o upgrade the home router=0D=0Aand=0D=0A> > all of the intervening network = connectivity to support DHCP=0D=0A> > either... ;)=0D=0A>=20=0D=0A> Then I = suggest you include such verbiage in the HELD draft and see if=0D=0Athe=0D=0A= > IESG accepts it.=0D=0A=0D=0A[AJW] Okay.. thanks.=0D=0A=0D=0A>=20=0D=0A> -= Marc-=0D=0A=0D=0A----------------------------------------------------------= --------------------------------------=0D=0AThis message is for the designa= ted recipient only and may=0D=0Acontain privileged, proprietary, or otherwi= se private information. =20=0D=0AIf you have received it in error, please n= otify the sender=0D=0Aimmediately and delete the original. Any unauthorize= d use of=0D=0Athis email is prohibited.=0D=0A------------------------------= ------------------------------------------------------------------=0D=0A[mf= 2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 05 13:18:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip6Wc-0006dK-AB; Mon, 05 Nov 2007 13:18:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip6Wb-0006cZ-87 for ecrit@ietf.org; Mon, 05 Nov 2007 13:18:13 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ip6Wa-0005gR-0P for ecrit@ietf.org; Mon, 05 Nov 2007 13:18:13 -0500 X-IronPort-AV: E=Sophos;i="4.21,373,1188802800"; d="scan'208";a="543338530" Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-3.cisco.com with ESMTP; 05 Nov 2007 10:18:08 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id lA5II8TJ019011; Mon, 5 Nov 2007 10:18:08 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lA5IHwvw017153; Mon, 5 Nov 2007 18:18:08 GMT 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.1830); Mon, 5 Nov 2007 10:17:57 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.146.111]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 10:17:57 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 05 Nov 2007 12:17:54 -0600 To: "Tschofenig, Hannes (NSN - DE/Munich)" , "ext Marc Linsner" , "Hannes Tschofenig" From: "James M. Polk" Subject: Re: AW: [Ecrit] RE: Applicability Statement In-Reply-To: <5FB585F183235B42A9E70095055136FB4C5159@DEMUEXC012.nsn-intr a.net> References: <472F2880.1030000@gmx.net> <00f501c81fbe$3548cd30$2d0d0d0a@cisco.com> <5FB585F183235B42A9E70095055136FB4C5159@DEMUEXC012.nsn-intra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Message-ID: X-OriginalArrivalTime: 05 Nov 2007 18:17:57.0361 (UTC) FILETIME=[30E28E10:01C81FD8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2513; t=1194286688; x=1195150688; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20AW=3A=20[Ecrit]=20RE=3A=20Applicability=20Statement |Sender:=20; bh=tV/3pXa23xQ+ZuFdx+SFQ/vANWMSsNYD/Zd43w3917M=; b=rHNaONwcceAZz34PlZ0bpcrUhKiGwfDITrdzkWwXjJAUmGN03YG+iSPL/wiR5oOvLG7xCUia 7BklTMgU3I7hFzK/upkV2x/NpHJW3A1WbpzgnJ7k5bURFrjfWUT9jy+M; Authentication-Results: sj-dkim-8; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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 09:21 AM 11/5/2007, Tschofenig, Hannes (NSN - DE/Munich) wrote: >But this text relates more to the supported=20 >location shapes rather to the usage of DHCP for=20 >conveying location information as such. The word "shape" (or any such synonym) is not in=20 3825, so I don't find this criticism relevant or applicable. >Ciao >Hannes > > > > -----Urspr=FCngliche Nachricht----- > > Von: ext Marc Linsner [mailto:mlinsner@cisco.com] > > Gesendet: Montag, 5. November 2007 16:12 > > An: 'Hannes Tschofenig' > > Cc: 'ECRIT' > > Betreff: [Ecrit] RE: Applicability Statement > > > > Hannes, > > > > > > RFC 4776 and RFC 3825 do not contain an applicability > > > statement either although the applicability of DHCP is also limited. > > > > The applicability of DHCP is well known, stated elsewhere and > > not required > > in drafts that are simply adding options. The applicability > > of the option > > is prudent. An example of an applicability statement from RFC 3825: > > > > " > > The goal of this option is to enable a wired Ethernet host to > > obtain its > > location, which it could provide to an emergency responder, > > as one example. > > > > Wireless hosts can utilize this option to gain knowledge of > > the location of > > the radio access point used during host configuration, but > > would need some > > more exotic mechanisms, maybe GPS, or maybe a future DHCP > > option, which > > includes a list of geo-locations like that defined here, > > containing the > > locations of the radio access points that are close to the client. > > " > > > > The intent of the above is a state this option is most > > applicable to wired > > Ethernet hosts. > > > > As I stated in other emails, IMO, if you don't provide words > > in the base > > draft that provide guidance to utilizing IP address as the > > identifier for > > location lookup, the IESG will immediately come back and ask > > what happens > > when the host is behind NATs and/or VPN tunnels. Yes, such > > guidance will > > appear to restrict the usage of the protocol, but it's > > certainly best that > > everyone know that prior to implementation. > > > > -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 Mon Nov 05 13:48:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip6zn-0008G0-O2; Mon, 05 Nov 2007 13:48:23 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ip6zm-0008Eh-UW for ecrit@ietf.org; Mon, 05 Nov 2007 13:48:22 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ip6zm-0007g7-HI for ecrit@ietf.org; Mon, 05 Nov 2007 13:48:22 -0500 X-IronPort-AV: E=Sophos;i="4.21,373,1188802800"; d="scan'208";a="413444332" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2007 10:48:21 -0800 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/8.12.11) with ESMTP id lA5ImKu2017784; Mon, 5 Nov 2007 13:48:20 -0500 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 lA5ImIfu018781; Mon, 5 Nov 2007 18:48:18 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 13:48:18 -0500 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Nov 2007 13:47:55 -0500 From: "Marc Linsner" To: "'Winterbottom, James'" , "'ECRIT'" Subject: RE: [Ecrit] Re: [Geopriv] Use ofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Date: Mon, 5 Nov 2007 13:47:54 -0500 Message-ID: <011101c81fdc$60681840$2d0d0d0a@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYAAudC4wAFtIv9AABPXvIAAA8vLAAAGRWrAAAoeMcA== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: X-OriginalArrivalTime: 05 Nov 2007 18:47:55.0108 (UTC) FILETIME=[606CFA40:01C81FDC] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15522.000 X-TM-AS-Result: No--8.030100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1101; t=1194288500; x=1195152500; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20Re=3A=20[Geopriv]=20Use=20ofIPaddressasanid entifier=09indraft-ietf-geopriv-http-location-delivery |Sender:=20 |To:=20=22'Winterbottom, =20James'=22=20, =0 A=20=20=20=20=20=20=20=20=22'ECRIT'=22=20; bh=szpG2E+49iEZVeudKXAy9M5TY1ZzBKyFXcRs0A3UVvI=; b=gqas2II1iCshoGQbe1hKjUj4inJhLsMgPb1gxMVYViIb3s5wrMZ1cz2b01htBk/BW8mtzBIf U0ZTq1aehArZX/E98pZSftUgpf+5ZNcfTIQNH0q/qPX8dvPN3x6gvd+E; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 James, You seem to be connecting several dots and making assumptions that I'm not. > > [AJW] huh?? LIS Discovery clearly states that a DHCP option > can be used to provide the identity of the LIS to the > end-device. There is absolutely nothing stoping this URL from > pointing to a location object on the hardware box. In fact if > it has a webserver running on it (as most home routers do) > then you have 90% of the HELD server already in place. > Supporting manual location configuration and a new DHCP > option is the same amount for work for either solution. 1) Are you including hardware VPN devices in the 'home router' ("as most home routers do") category? They are not the same device. 2) You are assuming a hardware VPN device includes a http server AND that enterprise IT departments have a desire to turn them on. That's a long stretch. 3) You are requesting enterprise IT departments to deploy HELD in the hardware VPN device when DHCP is already deployed. Most will object. 4) So, the LIS discovery option is not new to DHCP? ;^) -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 06 05:45:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpLvY-0002An-7i; Tue, 06 Nov 2007 05:45:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpLvW-00028q-V9 for ecrit@ietf.org; Tue, 06 Nov 2007 05:44:58 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpLvT-0006ox-5c for ecrit@ietf.org; Tue, 06 Nov 2007 05:44:58 -0500 X-SEF-Processed: 5_0_0_910__2007_11_06_04_55_18 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 06 Nov 2007 04:55:17 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 04:44:52 -0600 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: Tue, 6 Nov 2007 04:44:34 -0600 Message-ID: In-Reply-To: <00eb01c81fb3$151e3f50$2d0d0d0a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] UseofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYAAudC4wAFtIv9AALMZWIA== References: <00eb01c81fb3$151e3f50$2d0d0d0a@cisco.com> From: "Dawson, Martin" To: "Marc Linsner" , "Winterbottom, James" , "ECRIT" X-OriginalArrivalTime: 06 Nov 2007 10:44:52.0955 (UTC) FILETIME=[102122B0:01C82062] X-Spam-Score: 1.8 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [Ecrit] Re: [Geopriv] UseofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery 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 Marc,=0D=0A=0D=0ACould you elaborate, specifically, on what the "hardwar= e" VPN issue is=0D=0Athat you're describing=3F What are the network element= s involved, where is=0D=0Athe signalling going, and where does the problem = arise=3F=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message---= --=0D=0AFrom: Marc Linsner [mailto:mlinsner@cisco.com]=20=0D=0ASent: Tuesda= y, 6 November 2007 12:52 AM=0D=0ATo: Winterbottom, James; 'ECRIT'=0D=0ASubj= ect: RE: [Ecrit] Re: [Geopriv] UseofIPaddressasanidentifier=0D=0Aindraft-ie= tf-geopriv-http-location-delivery=0D=0A=0D=0AJames,=0D=0A=0D=0AIn-line.... =0D= =0A=0D=0A> Perhaps I am missing something here, but it seems to me that=20=0D= =0A> this not a HELD problem so much as a service discovery=20=0D=0A> probl= em, which from what I am lead to believe can be just as=20=0D=0A> problemat= ic with DHCP when it is run over VPNs. Consequently=20=0D=0A> unless we are= going to address that issue too, I think that=20=0D=0A> AGAIN singling HEL= D out to address a generic problem is=20=0D=0A> totally inappropriate.=0D=0A=0D= =0A1) I don't understand your service discovery statement. DHCP server=0D=0A= discovery is under strict control of the broadcast domain=0D=0Aadministrati= on.=0D=0AThe end host does not participate in this process.=0D=0A=0D=0A2) I= n the case of a software VPN client, it is assumed the end host=0D=0Areceiv= es=0D=0Aconfiguration information prior to establishment of the tunnel. It= has=0D=0Abeen=0D=0Astated many times the end host must utilize the locatio= n received during=0D=0Athe=0D=0Afirst step, prior to tunnel establishment. = It would also be prudent=0D=0Athat=0D=0Alocation information not be passed= during tunnel establishment.=0D=0A=0D=0A3) In the case of a hardware VPN i= t is typical that the remote device=0D=0Aco-located with the end host provi= des network configuration. Location=0D=0Acan=0D=0Abe included at that time= =2E=0D=0A=0D=0A=0D=0A>=20=0D=0A> A simple HELD-based LIS/relay-service adde= d to a home router=20=0D=0A> will avoid the issues that have been described= by Brian to=20=0D=0A> the same degree that they are avoided by DHCP. This = is very=20=0D=0A> easy to do and we have made this work in OpenWRT running = on a=20=0D=0A> linksys home-router.=20=0D=0A=0D=0A4) This would not work in= the typical hardware VPN environment.=0D=0A=0D=0A5) I assume you are not s= uggesting home users to run OpenWRT..=3F=0D=0A=0D=0AI am not keen to start = describing these=20=0D=0A> kinds of solutions in the base HELD specificatio= n, a BCP is=20=0D=0A> more appropriate, though a mention of care would seem= reasonable.=0D=0A=0D=0A6) As I stated in another email, in my experience, = the IESG will want=0D=0Aapplicability included in the base draft, but I'm c= ontinually surprised=0D=0Aby=0D=0Athe IESG... :^)=0D=0A=0D=0A=0D=0A-Marc-=0D= =0A=0D=0A=0D=0A=0D=0A_______________________________________________=0D=0AE= crit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/li= stinfo/ecrit=0D=0A=0D=0A---------------------------------------------------= ---------------------------------------------=0D=0AThis message is for the = designated recipient only and may=0D=0Acontain privileged, proprietary, or = otherwise private information. =20=0D=0AIf you have received it in error, p= lease notify the sender=0D=0Aimmediately and delete the original. Any unau= thorized use of=0D=0Athis email is prohibited.=0D=0A-----------------------= -------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 06 09:13:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpPBb-0000cv-Fq; Tue, 06 Nov 2007 09:13:47 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpPBX-0000a2-CJ for ecrit@ietf.org; Tue, 06 Nov 2007 09:13:43 -0500 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 1IpPBW-0008CR-ON for ecrit@ietf.org; Tue, 06 Nov 2007 09:13:43 -0500 X-IronPort-AV: E=Sophos;i="4.21,378,1188802800"; d="scan'208";a="543700402" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2007 06:13:41 -0800 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/8.12.11) with ESMTP id lA6EDfRK003479; Tue, 6 Nov 2007 09:13:41 -0500 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 lA6EDYg2017089; Tue, 6 Nov 2007 14:13:39 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 09:13:34 -0500 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 09:13:12 -0500 From: "Marc Linsner" To: "'Dawson, Martin'" , "'ECRIT'" Date: Tue, 6 Nov 2007 09:13:12 -0500 Message-ID: <004901c8207f$2a814730$2d0d0d0a@cisco.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.3138 Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYAAudC4wAFtIv9AALMZWIAAGka4A In-Reply-To: X-OriginalArrivalTime: 06 Nov 2007 14:13:12.0806 (UTC) FILETIME=[2A9F0860:01C8207F] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.002 X-TM-AS-Result: No--12.711200-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3448; t=1194358421; x=1195222421; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20UseofIPaddressasanidentifier=09indraft-ie tf-geopriv-http-location-delivery |Sender:=20 |To:=20=22'Dawson, =20Martin'=22=20, =20=22'ECRIT '=22=20; bh=R0QxDfpSHZHLcVG0WvLrS3aPST5qzZd+Ic+IU0bIW34=; b=tOxcHr7QDZyyw7K6e3gNkq615qZtPf0N0uJbq1+oZjrX/VPlnCZ8akQCacwZrxvTEYDwir9m QEAZT4v8uuIP3K36IwC0UiY2PPLyI/yTEAlg1UydGkkkWMVKV2Ox7k7h; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Subject: [Ecrit] RE: [Geopriv] UseofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery 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 Martin, > > Could you elaborate, specifically, on what the "hardware" VPN > issue is that you're describing? What are the network > elements involved, where is the signalling going, and where > does the problem arise? > I am not sure what you are asking. As this thread mutated, James proposed the cautions suggested for inclusion in the HELD draft surrounding NATs & VPNs were not related to HELD, but to service discovery. James also suggested that "A simple HELD-based LIS/relay-service added to a home router" could solve part/all of the issue. I was attempting to explain service discovery and how these claims worked with each VPN use case. -Marc- > James, > > In-line.... > > > Perhaps I am missing something here, but it seems to me > that this not > > a HELD problem so much as a service discovery problem, > which from what > > I am lead to believe can be just as problematic with DHCP > when it is > > run over VPNs. Consequently unless we are going to address > that issue > > too, I think that AGAIN singling HELD out to address a > generic problem > > is totally inappropriate. > > 1) I don't understand your service discovery statement. DHCP > server discovery is under strict control of the broadcast > domain administration. > The end host does not participate in this process. > > 2) In the case of a software VPN client, it is assumed the > end host receives configuration information prior to > establishment of the tunnel. It has been stated many times > the end host must utilize the location received during the > first step, prior to tunnel establishment. It would also be > prudent that location information not be passed during tunnel > establishment. > > 3) In the case of a hardware VPN it is typical that the > remote device co-located with the end host provides network > configuration. Location can be included at that time. > > > > > > A simple HELD-based LIS/relay-service added to a home router will > > avoid the issues that have been described by Brian to the > same degree > > that they are avoided by DHCP. This is very easy to do and we have > > made this work in OpenWRT running on a linksys home-router. > > 4) This would not work in the typical hardware VPN environment. > > 5) I assume you are not suggesting home users to run OpenWRT..? > > I am not keen to start describing these > > kinds of solutions in the base HELD specification, a BCP is more > > appropriate, though a mention of care would seem reasonable. > > 6) As I stated in another email, in my experience, the IESG > will want applicability included in the base draft, but I'm > continually surprised by the IESG... :^) > > > -Marc- > > > > _______________________________________________ > 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 Tue Nov 06 09:39:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpPaB-0004g0-0D; Tue, 06 Nov 2007 09:39:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpPa9-0004dc-4s; Tue, 06 Nov 2007 09:39:09 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpPa3-0005Sm-8Y; Tue, 06 Nov 2007 09:39:09 -0500 X-IronPort-AV: E=Sophos;i="4.21,378,1188802800"; d="scan'208";a="413768116" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2007 06:39:02 -0800 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/8.12.11) with ESMTP id lA6Ed15n015919; Tue, 6 Nov 2007 09:39:01 -0500 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 lA6Ed0fw026155; Tue, 6 Nov 2007 14:39:01 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 09:38:58 -0500 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 09:38:03 -0500 From: "Marc Linsner" To: "'Dawson, Martin'" , Date: Tue, 6 Nov 2007 09:38:03 -0500 Message-ID: <005c01c82082$a34f2710$2d0d0d0a@cisco.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.3138 Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYAAudC4wAFtIv9AALMZWIAAGka4AAAEISLAAADbygA== In-Reply-To: X-OriginalArrivalTime: 06 Nov 2007 14:38:03.0824 (UTC) FILETIME=[A3565300:01C82082] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.002 X-TM-AS-Result: No--18.846700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5602; t=1194359941; x=1195223941; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20UseofIPaddressasanidentifier=09indraft-ie tf-geopriv-http-location-delivery |Sender:=20 |To:=20=22'Dawson, =20Martin'=22=20, =20; bh=YPJpqTjSL9dq9RLvWKGa3o5Gc+TF2nqi1jJ2FYLi3w0=; b=O14/C6F0WldycqO92/PRgEHTKxK9mCuxnA+q3sTW2uYkT12NtDsZ/BXv4MmYBupBbzEFIuvN YFrZK8JbESw0HVm4a6YYaORTfYvZcKawsO19TCg2Cqc1L3pKgNESN31C; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: 'ECRIT' Subject: [Ecrit] RE: [Geopriv] UseofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery 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 Martin, In the case of software VPN, if you read #2, I'm trying to explain that location configuration needs to happen prior to tunnel establishment. There are too many variables involved to depend on LIS/location discovery working properly during/after tunnel establishment (end host route tables, subnet restrictions, etc.). In the case of hardware VPN, if you read #3 & #4, I'm trying to explain that, in most cases, the hardware VPN device offers network configuration to the end host and typically the end host has no visibility to the home network/home router, therefore could not utilizes services of the home or local SP network. -Marc- > -----Original Message----- > From: Dawson, Martin [mailto:Martin.Dawson@andrew.com] > Sent: Tuesday, November 06, 2007 9:21 AM > To: Marc Linsner; geopriv@ietf.org > Subject: RE: [Geopriv] UseofIPaddressasanidentifier > indraft-ietf-geopriv-http-location-delivery > > I'm trying to understand - given the same constraints in > terms of how they are used - what the difference between DHCP > and HELD is supposed to be in these use cases... > > Cheers, > Martin > > -----Original Message----- > From: Marc Linsner [mailto:mlinsner@cisco.com] > Sent: Wednesday, 7 November 2007 1:13 AM > To: Dawson, Martin; 'ECRIT' > Subject: RE: [Geopriv] UseofIPaddressasanidentifier > indraft-ietf-geopriv-http-location-delivery > > Martin, > > > > > Could you elaborate, specifically, on what the "hardware" > VPN issue is > > that you're describing? What are the network elements > involved, where > > is the signalling going, and where does the problem arise? > > > > I am not sure what you are asking. As this thread mutated, > James proposed the cautions suggested for inclusion in the > HELD draft surrounding NATs & VPNs were not related to HELD, > but to service discovery. James also suggested that "A > simple HELD-based LIS/relay-service added to a home router" > could solve part/all of the issue. I was attempting to > explain service discovery and how these claims worked with > each VPN use case. > > -Marc- > > > > > James, > > > > In-line.... > > > > > Perhaps I am missing something here, but it seems to me > > that this not > > > a HELD problem so much as a service discovery problem, > > which from what > > > I am lead to believe can be just as problematic with DHCP > > when it is > > > run over VPNs. Consequently unless we are going to address > > that issue > > > too, I think that AGAIN singling HELD out to address a > > generic problem > > > is totally inappropriate. > > > > 1) I don't understand your service discovery statement. > DHCP server > > discovery is under strict control of the broadcast domain > > administration. > > The end host does not participate in this process. > > > > 2) In the case of a software VPN client, it is assumed the end host > > receives configuration information prior to establishment of the > > tunnel. It has been stated many times the end host must > utilize the > > location received during the first step, prior to tunnel > > establishment. It would also be prudent that location > information not > > be passed during tunnel establishment. > > > > 3) In the case of a hardware VPN it is typical that the > remote device > > co-located with the end host provides network > configuration. Location > > can be included at that time. > > > > > > > > > > A simple HELD-based LIS/relay-service added to a home router will > > > avoid the issues that have been described by Brian to the > > same degree > > > that they are avoided by DHCP. This is very easy to do > and we have > > > made this work in OpenWRT running on a linksys home-router. > > > > 4) This would not work in the typical hardware VPN environment. > > > > 5) I assume you are not suggesting home users to run OpenWRT..? > > > > I am not keen to start describing these > > > kinds of solutions in the base HELD specification, a BCP is more > > > appropriate, though a mention of care would seem reasonable. > > > > 6) As I stated in another email, in my experience, the IESG > will want > > applicability included in the base draft, but I'm continually > > surprised by the IESG... :^) > > > > > > -Marc- > > > > > > > > _______________________________________________ > > 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] > > > > -------------------------------------------------------------- > ---------------------------------- > 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 Nov 06 09:50:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpPl2-00087F-PY; Tue, 06 Nov 2007 09:50:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpPl1-00086A-3E; Tue, 06 Nov 2007 09:50:23 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpPl0-000143-BN; Tue, 06 Nov 2007 09:50:23 -0500 X-SEF-Processed: 5_0_0_910__2007_11_06_09_00_43 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 06 Nov 2007 09:00:43 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 08:50:18 -0600 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: Tue, 6 Nov 2007 08:50:03 -0600 Message-ID: In-Reply-To: <005c01c82082$a34f2710$2d0d0d0a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] UseofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYAAudC4wAFtIv9AALMZWIAAGka4AAAEISLAAADbygAAAwXlg References: <005c01c82082$a34f2710$2d0d0d0a@cisco.com> From: "Dawson, Martin" To: "Marc Linsner" , X-OriginalArrivalTime: 06 Nov 2007 14:50:18.0032 (UTC) FILETIME=[58F59300:01C82084] X-Spam-Score: 1.8 (+) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: ECRIT Subject: [Ecrit] RE: [Geopriv] UseofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery 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 Below.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A-----Original Message-----=0D= =0AFrom: Marc Linsner [mailto:mlinsner@cisco.com]=20=0D=0ASent: Wednesday, = 7 November 2007 1:38 AM=0D=0ATo: Dawson, Martin; geopriv@ietf.org=0D=0ACc: = 'ECRIT'=0D=0ASubject: RE: [Geopriv] UseofIPaddressasanidentifier=0D=0Aindra= ft-ietf-geopriv-http-location-delivery=0D=0A=0D=0AMartin,=0D=0A=0D=0AIn the= case of software VPN, if you read #2, I'm trying to explain that=0D=0Aloca= tion configuration needs to happen prior to tunnel establishment.=0D=0ATher= e=0D=0Aare too many variables involved to depend on LIS/location discovery=0D= =0Aworking=0D=0Aproperly during/after tunnel establishment (end host route = tables,=0D=0Asubnet=0D=0Arestrictions, etc.).=0D=0A[[MCD]] Right - which is= the same constraint as applies to using DHCP...=0D=0A=0D=0AIn the case of = hardware VPN, if you read #3 & #4, I'm trying to explain=0D=0Athat, in most= cases, the hardware VPN device offers network=0D=0Aconfiguration to=0D=0At= he end host and typically the end host has no visibility to the home=0D=0An= etwork/home router, therefore could not utilizes services of the home=0D=0A= or=0D=0Alocal SP network.=0D=0A=0D=0A[[MCD]] This is the one I'm asking you= to explain... let's start with=0D=0Athe target/user device in the home net= work... where is this hardware VPN=0D=0Adevice=3F=0D=0A-Marc-=0D=0A=0D=0A=0D= =0A=0D=0A=20=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Dawson, M= artin [mailto:Martin.Dawson@andrew.com]=20=0D=0A> Sent: Tuesday, November 0= 6, 2007 9:21 AM=0D=0A> To: Marc Linsner; geopriv@ietf.org=0D=0A> Subject: R= E: [Geopriv] UseofIPaddressasanidentifier=20=0D=0A> indraft-ietf-geopriv-ht= tp-location-delivery=0D=0A>=20=0D=0A> I'm trying to understand - given the = same constraints in=20=0D=0A> terms of how they are used - what the differe= nce between DHCP=20=0D=0A> and HELD is supposed to be in these use cases...=0D= =0A>=20=0D=0A> Cheers,=0D=0A> Martin=0D=0A>=20=0D=0A> -----Original Message= -----=0D=0A> From: Marc Linsner [mailto:mlinsner@cisco.com]=0D=0A> Sent: We= dnesday, 7 November 2007 1:13 AM=0D=0A> To: Dawson, Martin; 'ECRIT'=0D=0A> = Subject: RE: [Geopriv] UseofIPaddressasanidentifier=20=0D=0A> indraft-ietf-= geopriv-http-location-delivery=0D=0A>=20=0D=0A> Martin,=0D=0A>=20=0D=0A> > =0D= =0A> > Could you elaborate, specifically, on what the "hardware"=20=0D=0A> = VPN issue is=20=0D=0A> > that you're describing=3F What are the network ele= ments=20=0D=0A> involved, where=20=0D=0A> > is the signalling going, and wh= ere does the problem arise=3F=0D=0A> >=20=0D=0A>=20=0D=0A> I am not sure wh= at you are asking. As this thread mutated,=20=0D=0A> James proposed the ca= utions suggested for inclusion in the=20=0D=0A> HELD draft surrounding NATs= & VPNs were not related to HELD,=20=0D=0A> but to service discovery. Jame= s also suggested that "A=20=0D=0A> simple HELD-based LIS/relay-service adde= d to a home router"=20=0D=0A> could solve part/all of the issue. I was att= empting to=20=0D=0A> explain service discovery and how these claims worked = with=20=0D=0A> each VPN use case.=0D=0A>=20=0D=0A> -Marc- =20=0D=0A>=20=0D= =0A>=20=0D=0A>=20=0D=0A> > James,=0D=0A> >=20=0D=0A> > In-line....=20=0D=0A= > >=20=0D=0A> > > Perhaps I am missing something here, but it seems to me=0D= =0A> > that this not=0D=0A> > > a HELD problem so much as a service discove= ry problem,=0D=0A> > which from what=0D=0A> > > I am lead to believe can be= just as problematic with DHCP=0D=0A> > when it is=0D=0A> > > run over VPNs= =2E Consequently unless we are going to address=0D=0A> > that issue=0D=0A> = > > too, I think that AGAIN singling HELD out to address a=0D=0A> > generic= problem=0D=0A> > > is totally inappropriate.=0D=0A> >=20=0D=0A> > 1) I don= 't understand your service discovery statement. =20=0D=0A> DHCP server=20=0D= =0A> > discovery is under strict control of the broadcast domain=20=0D=0A> = > administration.=0D=0A> > The end host does not participate in this proces= s.=0D=0A> >=20=0D=0A> > 2) In the case of a software VPN client, it is assu= med the end host=20=0D=0A> > receives configuration information prior to es= tablishment of the=20=0D=0A> > tunnel. It has been stated many times the e= nd host must=20=0D=0A> utilize the=20=0D=0A> > location received during the= first step, prior to tunnel=20=0D=0A> > establishment. It would also be p= rudent that location=20=0D=0A> information not=20=0D=0A> > be passed during= tunnel establishment.=0D=0A> >=20=0D=0A> > 3) In the case of a hardware VP= N it is typical that the=20=0D=0A> remote device=20=0D=0A> > co-located wit= h the end host provides network=20=0D=0A> configuration. Location=20=0D=0A= > > can be included at that time.=0D=0A> >=20=0D=0A> >=20=0D=0A> > >=20=0D=0A= > > > A simple HELD-based LIS/relay-service added to a home router will=20=0D= =0A> > > avoid the issues that have been described by Brian to the=0D=0A> >= same degree=0D=0A> > > that they are avoided by DHCP. This is very easy to= do=20=0D=0A> and we have=20=0D=0A> > > made this work in OpenWRT running o= n a linksys home-router.=0D=0A> >=20=0D=0A> > 4) This would not work in the= typical hardware VPN environment.=0D=0A> >=20=0D=0A> > 5) I assume you are= not suggesting home users to run OpenWRT..=3F=0D=0A> >=20=0D=0A> > I am no= t keen to start describing these=0D=0A> > > kinds of solutions in the base = HELD specification, a BCP is more=20=0D=0A> > > appropriate, though a menti= on of care would seem reasonable.=0D=0A> >=20=0D=0A> > 6) As I stated in an= other email, in my experience, the IESG=20=0D=0A> will want=20=0D=0A> > app= licability included in the base draft, but I'm continually=20=0D=0A> > surp= rised by the IESG... :^)=0D=0A> >=20=0D=0A> >=20=0D=0A> > -Marc-=0D=0A> > =0D= =0A> >=20=0D=0A> >=20=0D=0A> > ____________________________________________= ___=0D=0A> > Ecrit mailing list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://ww= w1.ietf.org/mailman/listinfo/ecrit=0D=0A> >=20=0D=0A> > -------------------= -------------------------------------------=0D=0A> > ----------------------= ------------=0D=0A> > This message is for the designated recipient only and= may contain=20=0D=0A> > privileged, proprietary, or otherwise private info= rmation.=0D=0A> > If you have received it in error, please notify the sende= r=20=0D=0A> immediately=20=0D=0A> > and delete the original. Any unauthori= zed use of this email is=20=0D=0A> > prohibited.=0D=0A> > -----------------= ---------------------------------------------=0D=0A> > --------------------= --------------=0D=0A> > [mf2]=0D=0A> >=20=0D=0A>=20=0D=0A> ----------------= ----------------------------------------------=0D=0A> ---------------------= -------------=0D=0A> This message is for the designated recipient only and = may=20=0D=0A> contain privileged, proprietary, or otherwise private informa= tion. =20=0D=0A> If you have received it in error, please notify the sender= =20=0D=0A> immediately and delete the original. Any unauthorized use of =0D= =0A> this email is prohibited.=0D=0A> -------------------------------------= -------------------------=0D=0A> ----------------------------------=0D=0A> = [mf2]=0D=0A>=20=0D=0A=0D=0A------------------------------------------------= ------------------------------------------------=0D=0AThis message is for t= he designated recipient only and may=0D=0Acontain privileged, proprietary, = or otherwise private information. =20=0D=0AIf you have received it in error= , please notify the sender=0D=0Aimmediately and delete the original. Any u= nauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------------= ---------------------------------------------------------------------------= -=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 06 10:07:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQ1u-0004PF-Gh; Tue, 06 Nov 2007 10:07:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQ1u-0004OQ-8Y for ecrit@ietf.org; Tue, 06 Nov 2007 10:07:50 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpQ1t-0001p1-Ok for ecrit@ietf.org; Tue, 06 Nov 2007 10:07:49 -0500 Received: (qmail invoked by alias); 06 Nov 2007 15:07:48 -0000 Received: from socks-ic-ext.mch.sbs.de (EHLO [194.138.17.187]) [194.138.17.187] by mail.gmx.net (mp010) with SMTP; 06 Nov 2007 16:07:48 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/qAOsj8+bqtMwlXD4r5gOmiRK5fQBTQpT/tLnS3J EKJHyfvIcV4eUT Message-ID: <47308343.1020701@gmx.net> Date: Tue, 06 Nov 2007 16:07:47 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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: 08e48e05374109708c00c6208b534009 Subject: [Ecrit] draft-ietf-ecrit-phonebcp-02.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 draft-ietf-ecrit-phonebcp-02.txt does not list the requirements for the PSAP side in Appendix A. Brian, are you going to list them in a future version? Ciao Hannes _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 06 10:24:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQIK-0002wr-Ud; Tue, 06 Nov 2007 10:24:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQIJ-0002wO-4u; Tue, 06 Nov 2007 10:24:47 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpQIC-00070q-VM; Tue, 06 Nov 2007 10:24:47 -0500 X-IronPort-AV: E=Sophos;i="4.21,378,1188802800"; d="scan'208";a="247428620" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2007 07:24:39 -0800 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/8.12.11) with ESMTP id lA6FOdOB006342; Tue, 6 Nov 2007 10:24:39 -0500 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 lA6FOZfu014109; Tue, 6 Nov 2007 15:24:38 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 10:24:38 -0500 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 10:24:14 -0500 From: "Marc Linsner" To: "'Dawson, Martin'" , Date: Tue, 6 Nov 2007 10:24:13 -0500 Message-ID: <006701c82089$16b22080$2d0d0d0a@cisco.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.3138 Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYAAudC4wAFtIv9AALMZWIAAGka4AAAEISLAAADbygAAAwXlgAABvXSA= In-Reply-To: X-OriginalArrivalTime: 06 Nov 2007 15:24:14.0424 (UTC) FILETIME=[16BE5580:01C82089] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.002 X-TM-AS-Result: No--1.253000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1187; t=1194362679; x=1195226679; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]=20UseofIPaddressasanidentifier=09indraft-ie tf-geopriv-http-location-delivery |Sender:=20 |To:=20=22'Dawson, =20Martin'=22=20, =20; bh=/HNfu6x9L1GLNrWHCu/g99jw8OoSLfUsoGNAtlkQWcg=; b=HACySDP5YDsbzoEmI7Ve/O1vHn5KjXCYuGL4Il7nRMV+42bjskY+CpgglJVajR5537oZl708 8tamcfy+SBewgZq3gh0WElBUIIH00q2bMwHImv67M68LZGo8Hkic9sZH; Authentication-Results: rtp-dkim-1; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: 'ECRIT' Subject: [Ecrit] RE: [Geopriv] UseofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery 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 Martin, In-line... > > In the case of software VPN, if you read #2, I'm trying to > explain that location configuration needs to happen prior to > tunnel establishment. > There > are too many variables involved to depend on LIS/location > discovery working properly during/after tunnel establishment > (end host route tables, subnet restrictions, etc.). > [[MCD]] Right - which is the same constraint as applies to > using DHCP... Not exactly the same. End host invocation of DHCP is predictable and therefore solutions are predictable. End host invocation of HELD is not predictable nor controllable. > > In the case of hardware VPN, if you read #3 & #4, I'm trying > to explain that, in most cases, the hardware VPN device > offers network configuration to the end host and typically > the end host has no visibility to the home network/home > router, therefore could not utilizes services of the home or > local SP network. > > [[MCD]] This is the one I'm asking you to explain... let's > start with the target/user device in the home network... > where is this hardware VPN device? You actually need me to answer this? -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 06 10:42:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQZ8-0005tL-Az; Tue, 06 Nov 2007 10:42:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpQZ6-0005mZ-KF; Tue, 06 Nov 2007 10:42:08 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpQZ2-0007Mc-Lb; Tue, 06 Nov 2007 10:42:08 -0500 X-SEF-Processed: 5_0_0_910__2007_11_06_09_52_29 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 06 Nov 2007 09:52:29 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 6 Nov 2007 09:42:04 -0600 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: Tue, 6 Nov 2007 09:42:01 -0600 Message-ID: In-Reply-To: <006701c82089$16b22080$2d0d0d0a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] UseofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYAAudC4wAFtIv9AALMZWIAAGka4AAAEISLAAADbygAAAwXlgAABvXSAAAWlmUA== References: <006701c82089$16b22080$2d0d0d0a@cisco.com> From: "Dawson, Martin" To: "Marc Linsner" , X-OriginalArrivalTime: 06 Nov 2007 15:42:04.0134 (UTC) FILETIME=[94572060:01C8208B] X-Spam-Score: 1.8 (+) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ECRIT Subject: [Ecrit] RE: [Geopriv] UseofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery 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 ditto=0D=0A=0D=0A-----Original Message-----=0D=0AFrom: Marc Linsner [mailto= :mlinsner@cisco.com]=20=0D=0ASent: Wednesday, 7 November 2007 2:24 AM=0D=0A= To: Dawson, Martin; geopriv@ietf.org=0D=0ACc: 'ECRIT'=0D=0ASubject: RE: [Ge= opriv] UseofIPaddressasanidentifier=0D=0Aindraft-ietf-geopriv-http-location= -delivery=0D=0A=0D=0AMartin,=0D=0A=0D=0AIn-line...=0D=0A>=20=0D=0A> In the = case of software VPN, if you read #2, I'm trying to=20=0D=0A> explain that = location configuration needs to happen prior to=20=0D=0A> tunnel establishm= ent.=0D=0A> There=0D=0A> are too many variables involved to depend on LIS/l= ocation=20=0D=0A> discovery working properly during/after tunnel establishm= ent=20=0D=0A> (end host route tables, subnet restrictions, etc.).=0D=0A> [[= MCD]] Right - which is the same constraint as applies to=20=0D=0A> using DH= CP...=0D=0A=0D=0ANot exactly the same. End host invocation of DHCP is pred= ictable and=0D=0Atherefore solutions are predictable. End host invocation = of HELD is not=0D=0Apredictable nor controllable.=0D=0A[[MCD]] Seems a matt= er of degree - DHCP requests could be sent broadcast=0D=0Aor unicast; it's = not totally predictable.=0D=0A=0D=0A=0D=0A>=20=0D=0A> In the case of hardwa= re VPN, if you read #3 & #4, I'm trying=20=0D=0A> to explain that, in most = cases, the hardware VPN device=20=0D=0A> offers network configuration to th= e end host and typically=20=0D=0A> the end host has no visibility to the ho= me network/home=20=0D=0A> router, therefore could not utilizes services of = the home or=20=0D=0A> local SP network.=0D=0A>=20=0D=0A> [[MCD]] This is th= e one I'm asking you to explain... let's=20=0D=0A> start with the target/us= er device in the home network...=20=0D=0A> where is this hardware VPN devic= e=3F=0D=0A=0D=0AYou actually need me to answer this=3F=0D=0A[[MCD]] I don't= know that I need it; but I'd appreciate it. Is that it a=0D=0Aproblem=3F=0D= =0A=0D=0A-Marc-=0D=0A=0D=0A------------------------------------------------= ------------------------------------------------=0D=0AThis message is for t= he designated recipient only and may=0D=0Acontain privileged, proprietary, = or otherwise private information. =20=0D=0AIf you have received it in error= , please notify the sender=0D=0Aimmediately and delete the original. Any u= nauthorized use of=0D=0Athis email is prohibited.=0D=0A--------------------= ---------------------------------------------------------------------------= -=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 06 12:42:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSRY-0006Nd-M6; Tue, 06 Nov 2007 12:42:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpSRX-0006N9-B0; Tue, 06 Nov 2007 12:42:27 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IpSRW-0005tk-SA; Tue, 06 Nov 2007 12:42:27 -0500 X-IronPort-AV: E=Sophos;i="4.21,379,1188802800"; d="scan'208";a="413832328" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 06 Nov 2007 09:42:25 -0800 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lA6HgPHU013560; Tue, 6 Nov 2007 12:42:25 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lA6HgPW7004580; Tue, 6 Nov 2007 17:42:25 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 12:42:25 -0500 Received: from mlinsnerwxp02 ([10.82.170.66]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Nov 2007 12:42:24 -0500 From: "Marc Linsner" To: "'Dawson, Martin'" , Date: Tue, 6 Nov 2007 12:42:23 -0500 Message-ID: <008901c8209c$63cf5be0$2d0d0d0a@cisco.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.3138 Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYAAudC4wAFtIv9AALMZWIAAGka4AAAEISLAAADbygAAAwXlgAABvXSAAAWlmUAAAv+vA In-Reply-To: X-OriginalArrivalTime: 06 Nov 2007 17:42:24.0738 (UTC) FILETIME=[6427DC20:01C8209C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15528.002 X-TM-AS-Result: No--9.601700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2138; t=1194370945; x=1195234945; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Geopriv]UseofIPaddressasanidentifier=09indraft-ietf- geopriv-http-location-delivery |Sender:=20 |To:=20=22'Dawson, =20Martin'=22=20, =20; bh=1VafrRQYbfcp9dRFVUZ0b5RWmrhHPjsQ9hqq/qoF2y0=; b=RRvgnPMdv/QQ806WQrazpEU8sjC46pD6/hMarI0hLJ3il3JiCqHwFRJG3l0mJxtKhAvRY/uF shoYt6N9dhkMUs8hEwH0COyh0frpOAaQx4lxlnOiq3AVw18kAcw1FvA5; Authentication-Results: rtp-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 'ECRIT' Subject: [Ecrit] RE: [Geopriv]UseofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery 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 Martin, > > > > In the case of software VPN, if you read #2, I'm trying to explain > > that location configuration needs to happen prior to tunnel > > establishment. > > There > > are too many variables involved to depend on LIS/location discovery > > working properly during/after tunnel establishment (end host route > > tables, subnet restrictions, etc.). > > [[MCD]] Right - which is the same constraint as applies to using > > DHCP... > > Not exactly the same. End host invocation of DHCP is > predictable and therefore solutions are predictable. End > host invocation of HELD is not predictable nor controllable. > [[MCD]] Seems a matter of degree - DHCP requests could be > sent broadcast or unicast; it's not totally predictable. Your comment makes no sense, besides broadcast vs. unicast being irrelavent to this discussion, there is no mechanism to advise an end host of the available DHCP servers prior to the initial end host DHC discover packet. The handling of the discovery packets is under total control of the broadcast domain administration. It is very predictable when an end host invokes DHCP. It is very predictable what DHCP server an end host communicates with. Hence, the response from the DHCP server is totally controllable. > > > > > > In the case of hardware VPN, if you read #3 & #4, I'm trying to > > explain that, in most cases, the hardware VPN device offers network > > configuration to the end host and typically the end host has no > > visibility to the home network/home router, therefore could not > > utilizes services of the home or local SP network. > > > > [[MCD]] This is the one I'm asking you to explain... let's > start with > > the target/user device in the home network... > > where is this hardware VPN device? > > You actually need me to answer this? > [[MCD]] I don't know that I need it; but I'd appreciate it. > Is that it a problem? The use case is a hardware VPN device in the home network, so the hardware VPN device connects to the home network and the end host connects to the VPN device. -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 06 16:48:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpWH9-0008Mv-U5; Tue, 06 Nov 2007 16:47:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpWH7-0008I3-Q1 for ecrit@ietf.org; Tue, 06 Nov 2007 16:47:57 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpWH5-0000n1-BN for ecrit@ietf.org; Tue, 06 Nov 2007 16:47:57 -0500 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IpWH1-0005FR-Ci; Tue, 06 Nov 2007 15:47:52 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <47308343.1020701@gmx.net> Subject: RE: [Ecrit] draft-ietf-ecrit-phonebcp-02.txt Date: Tue, 6 Nov 2007 16:47:53 -0500 Message-ID: <079801c820be$b1a53b10$2fea0446@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.3198 Thread-Index: Acgghs3ER6hsQTyWQCK280KshOJ7+AAN5otg In-Reply-To: <47308343.1020701@gmx.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 thought about that. If folks think it would be useful, I can create another responsible party and have PSAP requirements. I really don't want to "turn around" requirements so that if I say the endpoint has to put the location on the SIP signaling with -conveyance, I don't want to have to reword that to say the PSAP has to accept location with -conveyance. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, November 06, 2007 10:08 AM > To: ECRIT > Subject: [Ecrit] draft-ietf-ecrit-phonebcp-02.txt > > draft-ietf-ecrit-phonebcp-02.txt does not list the requirements for the > PSAP side in Appendix A. > > Brian, are you going to list them in a future version? > > 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 Tue Nov 06 16:59:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpWS1-0003qn-4I; Tue, 06 Nov 2007 16:59:13 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpWRz-0003mN-Sk for ecrit@ietf.org; Tue, 06 Nov 2007 16:59:11 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IpWRy-0005NS-3V for ecrit@ietf.org; Tue, 06 Nov 2007 16:59:11 -0500 Received: (qmail invoked by alias); 06 Nov 2007 21:59:09 -0000 Received: from p54985EBE.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.94.190] by mail.gmx.net (mp034) with SMTP; 06 Nov 2007 22:59:09 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19BZ9UfMC1BjzsWIY2H5R3l1UPnGT3yjFfgI4V9BC KVcaYWEc+gwiaI Message-ID: <4730E3AB.8040100@gmx.net> Date: Tue, 06 Nov 2007 22:59:07 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Brian Rosen Subject: Re: [Ecrit] draft-ietf-ecrit-phonebcp-02.txt References: <47308343.1020701@gmx.net> <079801c820be$b1a53b10$2fea0446@cis.neustar.com> In-Reply-To: <079801c820be$b1a53b10$2fea0446@cis.neustar.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: 8b30eb7682a596edff707698f4a80f7d 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 This issue came to my mind when I listened to Alain's presentation about the EGEA work and their intention to list operational needs of PSAPs. It seems that the Phone BCP document is in fact the only document that lists specifications a PSAP has to support. Ciao Hannes Brian Rosen wrote: > I thought about that. If folks think it would be useful, I can create > another responsible party and have PSAP requirements. I really don't want > to "turn around" requirements so that if I say the endpoint has to put the > location on the SIP signaling with -conveyance, I don't want to have to > reword that to say the PSAP has to accept location with -conveyance. > > Brian > > >> -----Original Message----- >> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] >> Sent: Tuesday, November 06, 2007 10:08 AM >> To: ECRIT >> Subject: [Ecrit] draft-ietf-ecrit-phonebcp-02.txt >> >> draft-ietf-ecrit-phonebcp-02.txt does not list the requirements for the >> PSAP side in Appendix A. >> >> Brian, are you going to list them in a future version? >> >> 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 Tue Nov 06 17:08:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpWaZ-0004xg-Dc; Tue, 06 Nov 2007 17:08:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpWaY-0004xW-2m for ecrit@ietf.org; Tue, 06 Nov 2007 17:08:02 -0500 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpWaU-0001gU-CA for ecrit@ietf.org; Tue, 06 Nov 2007 17:08:02 -0500 Received: from ([139.76.131.91]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.33177736; Tue, 06 Nov 2007 17:07:32 -0500 Received: from 01NC27689010627.AD.BLS.COM ([90.144.44.202]) by 01GAF5142010624.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 6 Nov 2007 17:07:32 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010627.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 6 Nov 2007 17:07:32 -0500 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: Tue, 6 Nov 2007 17:07:31 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0654C5F4@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Additional framework-03 and phonebcp-02 comments Thread-Index: AcggwW0S71bAYSoLSpS6udXkqxQHXw== From: "Stark, Barbara" To: "ECRIT" X-OriginalArrivalTime: 06 Nov 2007 22:07:32.0234 (UTC) FILETIME=[6DC31EA0:01C820C1] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Subject: [Ecrit] Additional framework-03 and phonebcp-02 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: , Errors-To: ecrit-bounces@ietf.org Brian and I had a little chat at the Emergency Services Workshop, and I agreed to provide some suggestions for additions to phonebcp, to bring into it some more of the details that are currently in the DSL Forum WT-164 text. Here's a summary of what the comments in this email are about: - Address non-SIP intermediary devices (ie, routers) better. AN-12 is awkward, since the home router isn't really a part of the access network. Also address case where calling application is distinct from OS, and cannot control the OS. Need to improve terminology section to better describe these. - LIS and LoST server determination - DHCP INFORM usage Not included in this email are the detailed flows. If others want them added to phonebcp, we should discuss. I'm not sure how those would get translated to an IETF document. Terminology Need to define ED, AN, SP abbreviations: ED - the User Equipment (UE) of ecrit-requirements AN - the Access Network of ecrit-framework SP - the ASP (of which VSP is a subset) of ecrit-requirements Add a new device type of "INT" for Intermediary Device Need to define this uniquely within phonebcp, since it's not defined elsewhere. Or else define in framework and describe its role in a subsection of 6.2 Location Determination. It would probably need to be defined as a device that is in close proximity to the ED (within a "small area") and provides a NAPT function between the WAN and the LAN that the ED is in. In general, it will also provide DHCP server functionality, and may have DHCP client capability on its WAN side. While it is possible for the emergency framework to work without upgrading most legacy intermediary devices, the possibility of failure is decreased when these devices are upgraded to support the functionality identified in phonebcp. The following phonebcp requirements would apply to an INT: ED-12 through ED-27, AN-1 through AN-3, AN-5, AN-6, AN-11, AN-13, AN-16 After ED-21, there needs to be a requirement that defines the recommended defaults for parameters in a HELD request. My previous email gave suggestions for responseTime. It may also be useful (but may not be necessary) to suggest that the default for all other parameters SHOULD be null. New: The device MUST support a random back-off period (between 30 seconds and 300 seconds) for re-trying the HELD query, when no response is received. New: ED-xx If the device is configured to use DHCP for bootstrapping, it MUST include both options for location acquisition (civic and geodetic), the option for LIS discovery, and the option for LoST discovery as required in [requirement references].=20 New: ED-xx If the device sends a DHCP INFORM message, it MUST include both options for location acquisition (civic and geodetic), the option for LIS discovery, and the option for LoST discovery as required in [requirement references]. Change AN-12 to an INT requirement. In ED-24, I recommend changing "non-bypassable VPNs" to "VPNs that do not allow split tunneling" to use more standard jargon. --- new section --- Need a section on LIS and LoST Discovery New: ED-xx Endpoints MUST support one or more mechanisms that allow them to determine their public IP address. Examples include ICE and HTTP get. New: ED-xx Endpoints MUST support LIS discovery as described in [LIS-DISCOVERY], and the LoST discovery as described in [LOST-DISCOVERY]. [need to add these references, see below] New: ED-xx The device MUST have a configurable default LoST server parameter. If the device is provided by or managed by an Application Service Provider (ASP), such as a Voice Service Provider (VSP), it is expected that the ASP will configure this option. ---- end new section--- After ED-27: New: ED-xx If a location refresh fails (that just attempts to use the last successful method), the endpoint MUST attempt all location configuration options. If the location can still not be determined, the endpoint MUST continue to use its last known location. --- new section --- Need a section for requirements for OSs, and for applications running on OSs that provide location to apps. Also, requirements for apps running on OSs that don't provide location, and where the app can't control LLDP or DHCP. ??-xx If the client that needs the location information is unable to control Layer 2 and 3 protocols, then that client application MUST attempt to get location, LIS, and/or LoST information from the OS, before proceeding with location acquisition using HELD. ??-xx In many cases, Operating Systems (OSs) will need to do location configuration for applications that run on top of them. The following requirements apply to such OSs: ED-12 through ED-18 and ED-21 through ED-27. (ED-20 doesn't seem like it applies to an OS?) ??-xx OSs that do location configuration operations on behalf of applications MUST provide a published interface for applications to get their location information from the OS.=20 ---- end new section--- ED-48: add phrase at end of reqt "...whenever they get an initial or updated location." Additional References [lost-discovery] Schulzrinne, H., J. Polk, and H. Tschofenig, "A Dynamic Host Configuration Protocol (DHCP) based Location-to-Service Translation Protocol (LoST) Discovery Procedure", draft-ietf-ecrit-dhc-lost-discovery-02, July 2007 [lis-discovery] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)" draft-thomson-geopriv-lis-discovery-03 (work in progress), September 2007) _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 06 17:15:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpWiD-0003wr-9e; Tue, 06 Nov 2007 17:15:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IpWiB-0003wE-S6 for ecrit@ietf.org; Tue, 06 Nov 2007 17:15:55 -0500 Received: from aismt06p.bellsouth.com ([139.76.165.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IpWi7-0001vC-Jg for ecrit@ietf.org; Tue, 06 Nov 2007 17:15:55 -0500 Received: from ([139.76.131.79]) by aismt06p.bellsouth.com with ESMTP id KP-AXPRN.33178587; Tue, 06 Nov 2007 17:15:34 -0500 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010621.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 6 Nov 2007 17:15:34 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Tue, 6 Nov 2007 17:15:33 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 6 Nov 2007 17:15:33 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0654C5FA@crexc41p> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Additional phonebcp comment thread-index: AcggwowvypgZkcwdScmNXJiJxIsmDQ== From: "Stark, Barbara" To: "ECRIT" X-OriginalArrivalTime: 06 Nov 2007 22:15:34.0171 (UTC) FILETIME=[8D04DEB0:01C820C2] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ecrit] Additional phonebcp comment 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 emergency workshop meeting, I discussed with Brian how to characterize the fact that while we really want VSPs to be able to recognize local emergency dial strings, that this may not be reasonable, since they have no requirements on them to always know where devices are. My suggestion is that requirements for the SP to recognize visited dial strings (SP-9, SP-35) needs to be a SHOULD with explanation of where and why it won't work. 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. GA621 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 07 22:07:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipxji-0005PW-GA; Wed, 07 Nov 2007 22:07:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ipxjg-0005Nm-BN; Wed, 07 Nov 2007 22:07:16 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ipxjf-0005WF-Lk; Wed, 07 Nov 2007 22:07:16 -0500 X-SEF-Processed: 5_0_0_910__2007_11_07_21_17_42 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 07 Nov 2007 21:17:42 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 7 Nov 2007 21:07:15 -0600 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: Wed, 7 Nov 2007 21:07:13 -0600 Message-ID: In-Reply-To: <008901c8209c$63cf5be0$2d0d0d0a@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv]UseofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery Thread-Index: AcgbybEXSbCAOBblSyyXicIwG1/inQADC3TgACDjLuAAAdNnUAACyA6gAAWwyPAAA3cmEAAAaxBwAA8VQkAALkUUYAAudC4wAFtIv9AALMZWIAAGka4AAAEISLAAADbygAAAwXlgAABvXSAAAWlmUAAAv+vAAEkeh4A= References: <008901c8209c$63cf5be0$2d0d0d0a@cisco.com> From: "Dawson, Martin" To: "Marc Linsner" , X-OriginalArrivalTime: 08 Nov 2007 03:07:15.0213 (UTC) FILETIME=[76DDB3D0:01C821B4] X-Spam-Score: 1.8 (+) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ECRIT Subject: [Ecrit] RE: [Geopriv]UseofIPaddressasanidentifier indraft-ietf-geopriv-http-location-delivery 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 Marc,=0D=0A=0D=0AI'll elaborate... let's use the example of some applica= tion wanting to=0D=0Ause 3825 on a Windows OS where a software VPN is also = installed.=0D=0A=0D=0AMy point is actually that you can't assume anything a= bout where the=0D=0Asoftware VPN virtual network adaptor inserts itself in = the Windows=0D=0Akernel (including whether it does or doesn't).=0D=0A=0D=0A= We can certainly know that Windows will hijack (i.e. "take=0D=0Aresponsibil= ity for") the initial DHCP broadcast associated with the=0D=0Aphysical NIC = connection initialization. There's no opportunity to ask=0D=0Afor option 12= 3 at that stage. Anybody who wants to take advantage of a=0D=0A3825-enabled= server at the moment (and possibly for all time) will need=0D=0Ato impleme= nt a subsequent DHCP request. This will almost certainly=0D=0Ainvolve the c= onstruction of a unicast request - something like the=0D=0Afollowing:=0D=0A=0D= =0Abyte privateoption =3D=0D=0AConvert.ToByte(Configuration.GetValue("dhcpp= rivateoption"));=0D=0A=0D=0A request.AddOption(55, new byte[1] { 123 });=0D= =0A=0D=0A DHCPPacket packet =3D DHCPClient.Request(info, dhcpserver, reques= t);=0D=0A=0D=0ASo - what will the software VPN do with that=3F I think the = answer is that=0D=0Awe don't know - it will depend on the implementation. N= evertheless, I=0D=0Athink it's clearly possible that it will result in the = unicast being=0D=0Apushed down the VPN tunnel. I don't see any difference b= etween this and=0D=0Athe scenario of a HELD request being pushed down the V= PN tunnel. Hence,=0D=0AI don't think there's any basis for suggesting that,= in a software VPN=0D=0Ascenario, DHCP is guaranteed to be functional or th= at it is exempt from=0D=0Adocumenting such issues any more than HELD is.=0D= =0A=0D=0AYou could argue that the OS is responsible for asking for option 1= 23 at=0D=0ANIC initialization time. I could similarly argue that the OS be=0D= =0Aresponsible for doing the HELD query at the same time. It is all a=0D=0A= matter of degree and there are a lot of assumptions about DHCP which I=0D=0A= think are spurious.=0D=0A=0D=0AWith respect to the hardware VPN - again - a= hardware VPN could be=0D=0Aconfigured badly such that it routes the local = LIS requests down the=0D=0Atunnel. It could do the same thing with a DHCP u= nicast - if the CHADDR=0D=0Ais outside the subnet. The DHCP server *could* = be inside the broadcast=0D=0Adomain but, then, so could a LIS. As long as y= ou stick to the same rules=0D=0Afor each model, the qualitative nature of t= he risks isn't any different.=0D=0A=0D=0ANote - I'm not arguing that it's n= ot useful to have such caveats spelt=0D=0Aout whatever the acquisition prot= ocol in question is. However, I think=0D=0Atoo much is made of the differen= ce between HELD and DHCP and the need=0D=0Afor good advice in either case.=0D= =0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A=0D=0A-----Original Message-----=0D= =0AFrom: Marc Linsner [mailto:mlinsner@cisco.com]=20=0D=0ASent: Wednesday, = 7 November 2007 4:42 AM=0D=0ATo: Dawson, Martin; geopriv@ietf.org=0D=0ACc: = 'ECRIT'=0D=0ASubject: RE: [Geopriv]UseofIPaddressasanidentifier=0D=0Aindraf= t-ietf-geopriv-http-location-delivery=0D=0A=0D=0AMartin,=20=0D=0A=0D=0A> > =0D= =0A> > In the case of software VPN, if you read #2, I'm trying to explain =0D= =0A> > that location configuration needs to happen prior to tunnel=20=0D=0A= > > establishment.=0D=0A> > There=0D=0A> > are too many variables involved = to depend on LIS/location discovery=20=0D=0A> > working properly during/aft= er tunnel establishment (end host route=20=0D=0A> > tables, subnet restrict= ions, etc.).=0D=0A> > [[MCD]] Right - which is the same constraint as appli= es to using=20=0D=0A> > DHCP...=0D=0A>=20=0D=0A> Not exactly the same. End= host invocation of DHCP is=20=0D=0A> predictable and therefore solutions a= re predictable. End=20=0D=0A> host invocation of HELD is not predictable n= or controllable.=0D=0A> [[MCD]] Seems a matter of degree - DHCP requests co= uld be=20=0D=0A> sent broadcast or unicast; it's not totally predictable.=0D= =0A=0D=0AYour comment makes no sense, besides broadcast vs. unicast being=0D= =0Airrelavent=0D=0Ato this discussion, there is no mechanism to advise an e= nd host of the=0D=0Aavailable DHCP servers prior to the initial end host DH= C discover=0D=0Apacket.=0D=0AThe handling of the discovery packets is under= total control of the=0D=0Abroadcast domain administration.=0D=0A=0D=0AIt i= s very predictable when an end host invokes DHCP. It is very=0D=0Apredicta= ble what DHCP server an end host communicates with. Hence, the=0D=0Arespon= se from the DHCP server is totally controllable.=0D=0A=0D=0A>=20=0D=0A>=20=0D= =0A> >=20=0D=0A> > In the case of hardware VPN, if you read #3 & #4, I'm tr= ying to=20=0D=0A> > explain that, in most cases, the hardware VPN device of= fers network=20=0D=0A> > configuration to the end host and typically the en= d host has no=20=0D=0A> > visibility to the home network/home router, there= fore could not=20=0D=0A> > utilizes services of the home or local SP networ= k.=0D=0A> >=20=0D=0A> > [[MCD]] This is the one I'm asking you to explain..= =2E let's=20=0D=0A> start with=20=0D=0A> > the target/user device in the ho= me network...=0D=0A> > where is this hardware VPN device=3F=0D=0A>=20=0D=0A= > You actually need me to answer this=3F=0D=0A> [[MCD]] I don't know that I= need it; but I'd appreciate it.=20=0D=0A> Is that it a problem=3F=0D=0A=0D= =0AThe use case is a hardware VPN device in the home network, so the=0D=0Ah= ardware=0D=0AVPN device connects to the home network and the end host conne= cts to the=0D=0AVPN=0D=0Adevice.=0D=0A=0D=0A-Marc-=0D=0A=0D=0A-------------= ---------------------------------------------------------------------------= --------=0D=0AThis message is for the designated recipient only and may=0D=0A= contain privileged, proprietary, or otherwise private information. =20=0D=0A= If you have received it in error, please notify the sender=0D=0Aimmediately= and delete the original. Any unauthorized use of=0D=0Athis email is prohi= bited.=0D=0A---------------------------------------------------------------= ---------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Nov 11 04:57:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir9Z0-00059X-Ox; Sun, 11 Nov 2007 04:57:10 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ir9Yy-00058G-VL for ecrit@ietf.org; Sun, 11 Nov 2007 04:57:09 -0500 Received: from s87.loopia.se ([194.9.94.112]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ir9Yw-0000gr-W8 for ecrit@ietf.org; Sun, 11 Nov 2007 04:57:08 -0500 Received: (qmail 67282 invoked from network); 11 Nov 2007 09:57:04 -0000 Received: from s34.loopia.se (HELO s42.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 11 Nov 2007 09:57:04 -0000 Received: (qmail 90238 invoked from network); 11 Nov 2007 09:57:01 -0000 Received: from h214n1fls34o265.telia.com (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[213.64.232.214]) (envelope-sender ) by s42.loopia.se (qmail-ldap-1.03) with SMTP for ; 11 Nov 2007 09:57:01 -0000 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "'Hannes Tschofenig'" , "'Ecrit@Ietf. Org'" Date: Sun, 11 Nov 2007 10:57:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcgZX6m3IjwI0v8kTqWJPAMs6CoQgAAmd/SgAo2E3CA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 22e211536bda974b2dcf811522dc525d Cc: Subject: [Ecrit] Mechanisms for adding supporting services to emergency calls 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 Message-Id: This is a proposal to add descriptions about relay service invocation in emergency calls to the ecrit specification series. In the discussion about change proposals to the phonebcp specification copied further down in this mai, I proposed to add some words about the = need to add a relay service to some emergency calls.=20 It has some common interest with other supporting services, such as = language interpretation, that may be invoked in a three-party call arrangement = when needed. I suggest that the inclusion of relay services ( and possibly other supporting services ) is taken a step forward in the ecrit collection of specifications. We have observed in small trials, that it is important = to connect relay services in true three-party call fashion with the = emergency services, so that the PSAP can share as many media as possible with the user, while getting support with language or mode translations from the relay service. This proposal connects to point 1.1 below about phonebcp section 9.2 = point 15: -----------------------------Copy from phonebcp discussion------------------------------- 9.2 point 15 now reads: " 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the PSAP should handle the call. For example, a language preference expressed in an Accept-Language header may be used as a hint to cause the PSAP to route the call to a call taker who speaks the requested language. " The Caller Preference [RFC 3841] may be used also for indicating the = need to connect a relay service, either simply by specifying a media preference = for text or a media preference for video with a language preference for a = sign language.=20 ++++I suggest to add last in this point.=20 ------------------------------------ "SIP Caller Preferences may also be used to indicate a need to invoke a relay service for communication with people with disabilities in the = call." -----------------------------End of copy------------------------------------------------------ Some more thoughts should be spent to this proposal, for deciding: a. What new tags are needed for the Caller preference evaluation? b. Will caller preference be the main mechanism for invoking relay = services, do we need to specify other ways as well for cases where Caller = preferences are not supported? c. The need is very similar to the everyday need to invoke relay = services in some calls for these users. So, the discussion should partly be held in = some general group, e.g. sipping. The kinds of relay services currently in use are: 1. sign language relay services (usually called "video relay") = translating between sign language in a video phone and voice in a voice phone. 2. Sign and text relay service translating between sign language from = the user and voice vs voice to real-time text to the user. ( used by signing deaf-blind users ) 3. text relay service translating between real-time text with the user = and voice with voice phone users. Voice may also be taken through in various combinations, leaving text translation to be done in only one way. 4. captioned telephony. A variant of text relay. Real-time text = translation added as captions to the voice towards the user in a voice call between = two parties. 5. speech-to-speech relay services, for people who speak weak or = distorded to get expert support in clarifying parts that need clarification during = a voice call. 6. cognitive support relay services, adding support for memory and = cognitive related disorders. =20 For all these services there is also a language dimension. You need to = reach a service that can handle your language in the mode that the relay = service handles. Example: American Sign Language relay service if you use = American Sign Language. Thoughts in this direction is earlier documented in RFC 3351. I suggest that we start defining and registering tags for these cases = and decide to what extent the mechanisms need to be described in the ecrit documents. Gunnar ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se -----Original Message----- From: Gunnar Hellstr=F6m [mailto:gunnar.hellstrom@omnitor.se]=20 Sent: Monday, October 29, 2007 12:17 PM To: 'Hannes Tschofenig' Cc: 'Ecrit@Ietf. Org' Subject: RE: [Ecrit] Modification proposals for media supportin draft-ietf-ecrit-phonebcp Hi, Thanks, I have inline answers marked below. Change proposals are marked ++++++++=20 Further comments: 1. Connection of relay services -------------------------------- Recent experience with trials with emergency calls with people with communication related disabilities have made me realize that there are further procedures to define. In order to handle these calls, it is often most efficient to set up a = three party multimedia call with the user, the PSAP and a suitable relay = service. The relay services support call handling by translating, e.g. between = sign language and voice, between real-time text and voice, by adding = real-time text as captions to voice or by supporting weak speech or speech that is hard to understand with clear speech. PSAPS may be able to handle real-time text themselves, but it was = evident from the trial that support from a full three-party connected text relay service made it possible for the the PSAP to concentrate on their = original task. It is obvious for the other communication modes that relay = services need to be invoked in the calls. Some signaling may be needed for invoking the most appropriate relay services rapidly end efficiently in the call.=20 There are two requirement points in the phonebcp draft that relate to = this need, and may be expanded a bit in order to include this need. It is in 9.2, point 15 and in 11, point 1. 1.1 Use Caller preferences for connection of relay services. ------------------------------------------------------------- 9.2 point 15 now reads: " 15. SIP Caller Preferences [RFC3841] MAY be used to signal how the PSAP should handle the call. For example, a language preference expressed in an Accept-Language header may be used as a hint to cause the PSAP to route the call to a call taker who speaks the requested language. " The Caller Preference [RFC 3841] may be used also for indicating the = need to connect a relay service, either simply by specifying a media preference = for text or a media preference for video with a language preference for a = sign language.=20 ++++I suggest to add last in this point.=20 ------------------------------------ "SIP Caller Preferences may also be used to indicate a need to invoke a relay service for communication with people with disabilities in the = call." 1.2 Use of conference calls and REFER to invoke relay services -------------------------------------------------------------- Section 11, point 1 now reads:=20 " 11. Mid-call behavior ED-61/SP-38 During the course of an emergency call, devices and proxies MUST support REFER transactions and the Referred-by: header [RFC3515] to: 1. Be REFERed to a conference bridge; PSAPs often include dispatchers, responders or specialists on a call." A relay service can be seen as a specialist to be included in the call.=20 ++++It may be good to point that out specifically by adding the=20 ++++following sentence last in Section 11, point 1.: ------------------------------ "Relay services for communication with people with disabilities may be included in the call in this way." 2. There is a slight inconsistency around the use of G.711. ----------------------------------------------------------- Requirement ED-60 in Appendix A, Point 12 says: " 12. A normal SDP offer SHOULD be included in the INVITE. The offer MUST include the G.711 codec, see Section 14." Requirement ED-71, in Appendix A, says: " ED-71 Endpoints supporting voice MUST support G.711 A law (and mu Law in North America) encoded voice as described in [RFC3551]." So, ED-60 gives the impression that voice support is mandatory, while = ED-71 gives the impression that it is optional. There are current SIP = terminals with only real-time text support according to RFC 4103. The question is = if such designs shall be enabled to call emergency services, or if they = need to be complemented with a G.711 voice codec. Some text users are not = interested in using voice at all. +++++Conclusion: ----------- If there is any specific reason why voice is needed in the call, then I think the words "supporting voice" should be deleted from ED-71. If not, = the last sentence in ED-60 Point 12 should read "If voice is supported, the offer MUST include the G.711 codec, see Section 14. 3. Further points inline below. Gunnar -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] Sent: Sunday, October 28, 2007 1:40 PM To: Gunnar Hellstr=F6m Cc: Ecrit@Ietf. Org Subject: Re: [Ecrit] Modification proposals for media support in draft-ietf-ecrit-phonebcp Hi Gunnar, I just found this mail and noticed that nobody responded to you. Are these issues covered with the recent draft update? Ciao Hannes Gunnar Hellstr=F6m wrote: > I want to propose a few small modifications to=20 > draft-ietf-ecrit-phonebcp-00.txt > > > 1. Editorial and explanation. > ---------------------------------- > The last lines in section 2 reads: > > =93o The proxy recognizes the call as an emergency call and routes = the > call using normal SIP routing mechanisms > [RFC4504] details Best Current Practice for SIP user agents. This > memo can be considered an addition to it for endpoints.=94 > > A full stop is missing after mechanisms, and it is unusual to start a=20 > sentence with a reference. I also suggest to include a hint on what is = > found in RFC 4504 > > I suggest a slight change to: > > " o The proxy recognizes the call as an emergency call, routes the > call using normal SIP routing mechanisms. > > Best Current Practice for SIP user agents including handling of audio=20 > and real-time text [RFC 4103] media detailed in [RFC4504] SHOULD be applied. > This memo can be considered an addition to it for endpoints." The text is rearranged and the new text mainly found in sections 9 = ED-54 and repeated in A.1. Some small adjustments are still needed. It reads: " ED-54 Best Current Practice for SIP user agents including handling = of audio, video and real-time text [RFC4103] SHOULD be applied. This memo can be considered as an addition to it for endpoints." I have a couple of comments still on it: A. Originally, this sentence referred to RFC 4504 as a general Best = Current Practice for SIP endpoints, and especially the real-time text support.=20 By eliminating RFC 4504, it is not clear what Best Current Practice it refers to. It has instead a direct reference to RFC 4103 for real-time = text, and that is good and equally important as the G.711 reference for voice elsewhere. I do not know what reasoning there was behind removing the reference to = RFC 4504. Not knowing the background,=20 +++++I suggest to include the reference "[RFC 4504]" again after the=20 +++++words "SIP user agents" to read "SIP user agents [RFC 4504]".=20 If there was a specific reason to omit the reference to RFC 4504, I = think ED-54 can be left without that reference.=20 +++++B. It may be unclear what "it" in the last sentence refers to. I suggest changing "it" to "such Best Current Practice". =20 > > 2. Add a bullet point in the list in section 2. > ------------------------------------------------ > I also suggest that the sequence of steps should end with media=20 > establishment rather than just routing > > Insert as a new bullet point last in the list in section 2: > > o The call is established and common media streams opened. > This is now well covered in section 14. > > 3. More real-time text improvements > --------------------------------------- > Section 3 starts: > " Although present PSAPs have only support for voice calls" > > That is not true. A reasonable part of the population has also support = > for real-time text calls. So, the support for real-time text expected=20 > from IP is to maintain and extend support rather than fulfilling new expectations. > > I suggest rewording to: > > " Support for voice calls and real-time text calls placed through PSTN = > facilities or systems connected to the PSTN is found in present PSAPs. > Future PSAPs will however support Internet connectivity and a wider=20 > range of media types and provide higher functionality." This is well expressed in other ways now. > > 4. Handle unused references. > ---------------------------- > In the current version, I have observed two unused references. > [RFC 4103] and [draft-ietf-sipping-toip], both related to the=20 > real-time text medium. > > Revival of reference [rfc 4103] is proposed in 3) above. > > In order to revive the use of [sipping-toip], I suggest adding this=20 > line between the two paragraphs of section 3: > > "The expectations for emergency service support for the real-time text = > medium, described in [draft-ietf-sipping-toip], section 7.1 SHOULD be=20 > fulfilled." > > ( draft-ietf-sipping-toip-07 is in publication requested state ) Yes, done. > > > > With these small changes I think the phonebcp draft will be a good=20 > guidance for design of user terminals. > Tanks Gunnar > > > Thanks > > Gunnar > > ------------------------------------------------------------------- > Gunnar Hellstr=F6m > Omnitor > gunnar.hellstrom@omnitor.se > Tel: +46708204288 > www.omnitor.se > > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > =20 __________ NOD32 2599 (20071017) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit __________ NOD32 2599 (20071017) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Nov 11 05:55:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrATs-00028p-90; Sun, 11 Nov 2007 05:55:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrATr-000224-8b for ecrit@ietf.org; Sun, 11 Nov 2007 05:55:55 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IrATn-0006OX-IO for ecrit@ietf.org; Sun, 11 Nov 2007 05:55:55 -0500 Received: (qmail invoked by alias); 11 Nov 2007 10:55:49 -0000 Received: from p549872BF.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.114.191] by mail.gmx.net (mp048) with SMTP; 11 Nov 2007 11:55:49 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1966ElY2D56COOOrVEsyPwhTEf2h+Ir4qGgXuNpqQ 8f6FyFGXFsvVrF Message-ID: <4736DFB3.3060203@gmx.net> Date: Sun, 11 Nov 2007 11:55:47 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) 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: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ecrit] Proposed Agenda for IETF#70 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 is a first try... * Status Update and Agenda Bashing Chairs * IESG Comments regarding LoST, LoST mapping architecture and LoST discovery Chairs http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-03.txt http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-02.txt * Open issues with Framework and Phone BCP Brian Rosen http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt * Location Hiding Solution Space Yet to be decided http://tools.ietf.org/html/draft-schulzrinne-ecrit-location-hiding-req-00 http://tools.ietf.org/html/draft-barnes-ecrit-auth * Unauthenticated Emergency Services Yet to be decided http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access-00 * Forest Guide Exchange Protocol Henning Schulzrinne http://tools.ietf.org/html/draft-schulzrinne-ecrit-lost-sync-00 * Specifying Holes in LoST Service Boundaries James Winterbottom http://tools.ietf.org/html/draft-winterbottom-ecrit-specifying-holes-00.txt * RPH Header for Emergency Services James Polk http://tools.ietf.org/wg/ecrit/draft-polk-ecrit-local-emergency-rph-namespace-01.txt _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 12 03:23:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrUZx-0003W2-0u; Mon, 12 Nov 2007 03:23:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrUZw-0003Vk-37 for ecrit@ietf.org; Mon, 12 Nov 2007 03:23:32 -0500 Received: from mu-out-0910.google.com ([209.85.134.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrUZt-000820-RB for ecrit@ietf.org; Mon, 12 Nov 2007 03:23:32 -0500 Received: by mu-out-0910.google.com with SMTP id i10so1373446mue for ; Mon, 12 Nov 2007 00:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; bh=bFaY1pui35aMQfwJbRgeDOGfzGdzdBRPk+OyoWMb41I=; b=r13q4b7VLd3X9gtJe+C8+t371fiwd5HVzjyo6pEhby5K6fWrN71kH5DL1C0BbdseL+Cqn+dIqr28gMcu6/xh8vAlJYMSmqHzXJXhdfItOIEjAEbp9zP7QG8uk33KUCkC6vMZGsov9dmtVHtREymASHs9buPjmZOQARs5l+UpYPw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=jvJrmSsLH4R5ri0pgG7DNNfk5RjZnhBpNX5poS3W+DKsyHiwqbGYvM6aa95N2Gb3mw3mvMSRwnoKK5RNe4wxX7rscm5z0YRBCJvNUP/y+iohN1X+/dcT1Qe0MMvGEemfGlmMYZW1XUuiUA7P0Tx5p0KK7tXIJ1YYHnxMkLBA1nc= Received: by 10.82.138.6 with SMTP id l6mr6860492bud.1194855807048; Mon, 12 Nov 2007 00:23:27 -0800 (PST) Received: by 10.82.182.18 with HTTP; Mon, 12 Nov 2007 00:23:27 -0800 (PST) Message-ID: Date: Mon, 12 Nov 2007 09:23:27 +0100 From: "Karl Heinz Wolf" To: ECRIT MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ecrit] ELIN 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 LLDP-MED supports not just civic and coordinate based location information, but also an ELIN. How does this type of location information fit to the IETF Framework? Is this case considered in any document? I couldn't find any information on how to proceed with this type of location information. cheers Karl Heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 12 04:03:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrVCb-0007Ah-8o; Mon, 12 Nov 2007 04:03:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrVCZ-00078j-6D for ecrit@ietf.org; Mon, 12 Nov 2007 04:03:27 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrVCV-0001BQ-KD for ecrit@ietf.org; Mon, 12 Nov 2007 04:03:27 -0500 X-SEF-Processed: 5_0_0_910__2007_11_12_03_13_54 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 12 Nov 2007 03:13:54 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Nov 2007 03:03:22 -0600 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 Subject: RE: [Ecrit] ELIN Date: Mon, 12 Nov 2007 03:03:21 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ELIN Thread-Index: AcglBVE9wfBFo/kPSdS72HylD7ValQABA2bg References: From: "Winterbottom, James" To: "Karl Heinz Wolf" , "ECRIT" X-OriginalArrivalTime: 12 Nov 2007 09:03:22.0579 (UTC) FILETIME=[E0760230:01C8250A] X-Spam-Score: 1.8 (+) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Hi Karl Heinz,=0D=0A=0D=0AAn ELIN is a specific callback number that repres= ents an area in an MLTS=0D=0A(Multi-Line Telephone System). As far as I kno= w they are only used in=0D=0Athe USA. The following description may not be = 100% right, but it is=0D=0Apretty close.=0D=0A=0D=0AEssentially if you have= a company or campus that occupies a large area,=0D=0Ayou can break this up= into smaller areas to make it easier for emergency=0D=0Aservice crews to f= ind people. In some States this is mandated when the=0D=0Aarea becomes more= than a certain size (8000 sqr feet is commonly=0D=0Aquoted). Generally wha= t happens is that all telephone extensions in a=0D=0Acertain area are assoc= iated with what is called an ERL (emergency=0D=0Aresource location), this i= s done in the PABX provisioning. Each ERL is=0D=0Aallocated an ELIN that se= rves as the presented calling number to the=0D=0APSAP for any extension pro= visioned against the ERL. The PSAP is able to=0D=0Ause the ELIN to get the = floor location and area serviced by a specific=0D=0AELIN. The ELIN also ser= ves as the number that the PSAP will callback in=0D=0Athe case of the call = being dropped.=0D=0A=0D=0ATo this extent the ELIN is the way in which LLDP-= MED currently supports=0D=0Alocation by reference.=0D=0A=0D=0APlease let me= know if this isn't clear and I will try an clarify=0D=0Afurther.=0D=0A=0D=0A= Cheers=0D=0AJames=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Karl= Heinz Wolf [mailto:khwolf1@gmail.com]=0D=0A> Sent: Monday, 12 November 200= 7 7:23 PM=0D=0A> To: ECRIT=0D=0A> Subject: [Ecrit] ELIN=0D=0A>=20=0D=0A> LL= DP-MED supports not just civic and coordinate based location=0D=0A> informa= tion, but also an ELIN. How does this type of location=0D=0A> information f= it to the IETF Framework=3F Is this case considered in any=0D=0A> document=3F=0D= =0A> I couldn't find any information on how to proceed with this type of=0D= =0A> location information.=0D=0A>=20=0D=0A> cheers=0D=0A> Karl Heinz=0D=0A>= =20=0D=0A> _______________________________________________=0D=0A> Ecrit mai= ling list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listin= fo/ecrit=0D=0A=0D=0A-------------------------------------------------------= -----------------------------------------=0D=0AThis message is for the desi= gnated recipient only and may=0D=0Acontain privileged, proprietary, or othe= rwise private information. =20=0D=0AIf you have received it in error, pleas= e notify the sender=0D=0Aimmediately and delete the original. Any unauthor= ized use of=0D=0Athis email is prohibited.=0D=0A---------------------------= ---------------------------------------------------------------------=0D=0A= [mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 12 04:30:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrVd2-0005un-Ao; Mon, 12 Nov 2007 04:30:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrVd1-0005ue-6F for ecrit@ietf.org; Mon, 12 Nov 2007 04:30:47 -0500 Received: from fk-out-0910.google.com ([209.85.128.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrVcy-0002Ow-Je for ecrit@ietf.org; Mon, 12 Nov 2007 04:30:47 -0500 Received: by fk-out-0910.google.com with SMTP id z23so1418906fkz for ; Mon, 12 Nov 2007 01:30:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=7Eg1CL0JD1jgP5uoIt9EedFYkgpeIT0ZPNhp8WEIdAg=; b=h307l3bELUlRaVCA5o6r5xlVpNdl9KyaHUXq2Psc7L9jCrKCqRoG1GFgrh6+JRCGCzdYaPcTyuaga8sCPmcePCJ04vc9H8z45Pci7G2OwoarbqJAhvu2cVtkoGmyyQVrQXgPLAIW4mQEBx57T5RBfItZNbbN7uPZz4ZAS8f1Xy8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p61FTTwkS2RNi6j5q+wYpBKTxBo/cn5+i1xIrvtcB5dz65GHOoBKYBTnkg7/ugvyXxy6iAEMhPfuQgjYWNqMJdltDD3dwBDxRxqNuNbUGaeUlQ4epuBfY+c0dnLZKdy3UquJp0VCxert2m1Ja3ggDdIr2skdFTOZrnNk/iejXyk= Received: by 10.82.174.20 with SMTP id w20mr8049202bue.1194859843538; Mon, 12 Nov 2007 01:30:43 -0800 (PST) Received: by 10.82.182.18 with HTTP; Mon, 12 Nov 2007 01:30:38 -0800 (PST) Message-ID: Date: Mon, 12 Nov 2007 10:30:38 +0100 From: "Karl Heinz Wolf" To: "Winterbottom, James" Subject: Re: [Ecrit] ELIN In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 1.7 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 James! Thank you for your detailed description of the ELIN. One more question: how does the callback from the PSAP work, if there are multiple extensions with the same ELIN? Anyway, in case a company uses ELINs, and LLDP-MED location information tells the client this ELIN, what is the client supposed to do? cheers karl heinz On Nov 12, 2007 10:03 AM, Winterbottom, James wrote: > Hi Karl Heinz, > > An ELIN is a specific callback number that represents an area in an MLTS > (Multi-Line Telephone System). As far as I know they are only used in > the USA. The following description may not be 100% right, but it is > pretty close. > > Essentially if you have a company or campus that occupies a large area, > you can break this up into smaller areas to make it easier for emergency > service crews to find people. In some States this is mandated when the > area becomes more than a certain size (8000 sqr feet is commonly > quoted). Generally what happens is that all telephone extensions in a > certain area are associated with what is called an ERL (emergency > resource location), this is done in the PABX provisioning. Each ERL is > allocated an ELIN that serves as the presented calling number to the > PSAP for any extension provisioned against the ERL. The PSAP is able to > use the ELIN to get the floor location and area serviced by a specific > ELIN. The ELIN also serves as the number that the PSAP will callback in > the case of the call being dropped. > > To this extent the ELIN is the way in which LLDP-MED currently supports > location by reference. > > Please let me know if this isn't clear and I will try an clarify > further. > > Cheers > James > > > > -----Original Message----- > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > Sent: Monday, 12 November 2007 7:23 PM > > To: ECRIT > > Subject: [Ecrit] ELIN > > > > LLDP-MED supports not just civic and coordinate based location > > information, but also an ELIN. How does this type of location > > information fit to the IETF Framework? Is this case considered in any > > document? > > I couldn't find any information on how to proceed with this type of > > location information. > > > > cheers > > Karl Heinz > > > > _______________________________________________ > > 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 Mon Nov 12 04:46:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrVsY-0002v3-O6; Mon, 12 Nov 2007 04:46:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrVsX-0002us-Om for ecrit@ietf.org; Mon, 12 Nov 2007 04:46:49 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrVsT-0002wR-JE for ecrit@ietf.org; Mon, 12 Nov 2007 04:46:49 -0500 X-SEF-Processed: 5_0_0_910__2007_11_12_03_57_16 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 12 Nov 2007 03:57:16 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Nov 2007 03:46:44 -0600 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 Subject: RE: [Ecrit] ELIN Date: Mon, 12 Nov 2007 03:46:42 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ELIN Thread-Index: AcglDrP0q71sDCJCRdaqX1m7oWU59wAAhDrg References: From: "Winterbottom, James" To: "Karl Heinz Wolf" X-OriginalArrivalTime: 12 Nov 2007 09:46:44.0345 (UTC) FILETIME=[EF3BFE90:01C82510] X-Spam-Score: 3.5 (+++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Karl Heinz,=0D=0A=0D=0AIt is the only the extension that actually has th= e ELIN number that gets=0D=0Acalled back. So all extensions with the same E= LIN need to be close to=0D=0Aone another.=0D=0A=0D=0AAs to what the client = does when its gets the ELIN from LLDP-MED I have=0D=0Ano idea... *8)=0D=0A=0D= =0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> F= rom: Karl Heinz Wolf [mailto:khwolf1@gmail.com]=0D=0A> Sent: Monday, 12 Nov= ember 2007 8:31 PM=0D=0A> To: Winterbottom, James=0D=0A> Cc: ECRIT=0D=0A> S= ubject: Re: [Ecrit] ELIN=0D=0A>=20=0D=0A> Hi James!=0D=0A>=20=0D=0A> Thank = you for your detailed description of the ELIN.=0D=0A> One more question: ho= w does the callback from the PSAP work, if there=0D=0A> are multiple extens= ions with the same ELIN=3F=0D=0A>=20=0D=0A> Anyway, in case a company uses = ELINs, and LLDP-MED location=0D=0A> information tells the client this ELIN,= what is the client supposed to=0D=0A> do=3F=0D=0A>=20=0D=0A> cheers=0D=0A>= karl heinz=0D=0A>=20=0D=0A> On Nov 12, 2007 10:03 AM, Winterbottom, James=0D= =0A> wrote:=0D=0A> > Hi Karl Heinz,=0D=0A> = >=0D=0A> > An ELIN is a specific callback number that represents an area in= an=0D=0AMLTS=0D=0A> > (Multi-Line Telephone System). As far as I know they= are only used=0D=0Ain=0D=0A> > the USA. The following description may not = be 100% right, but it is=0D=0A> > pretty close.=0D=0A> >=0D=0A> > Essential= ly if you have a company or campus that occupies a large=0D=0Aarea,=0D=0A> = > you can break this up into smaller areas to make it easier for=0D=0Aemerg= ency=0D=0A> > service crews to find people. In some States this is mandated= when=0D=0Athe=0D=0A> > area becomes more than a certain size (8000 sqr fee= t is commonly=0D=0A> > quoted). Generally what happens is that all telephon= e extensions in=0D=0Aa=0D=0A> > certain area are associated with what is ca= lled an ERL (emergency=0D=0A> > resource location), this is done in the PAB= X provisioning. Each ERL=0D=0Ais=0D=0A> > allocated an ELIN that serves as = the presented calling number to the=0D=0A> > PSAP for any extension provisi= oned against the ERL. The PSAP is able=0D=0Ato=0D=0A> > use the ELIN to get= the floor location and area serviced by a=0D=0Aspecific=0D=0A> > ELIN. The= ELIN also serves as the number that the PSAP will callback=0D=0Ain=0D=0A> = > the case of the call being dropped.=0D=0A> >=0D=0A> > To this extent the = ELIN is the way in which LLDP-MED currently=0D=0Asupports=0D=0A> > location= by reference.=0D=0A> >=0D=0A> > Please let me know if this isn't clear and= I will try an clarify=0D=0A> > further.=0D=0A> >=0D=0A> > Cheers=0D=0A> > = James=0D=0A> >=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > Fr= om: Karl Heinz Wolf [mailto:khwolf1@gmail.com]=0D=0A> > > Sent: Monday, 12 = November 2007 7:23 PM=0D=0A> > > To: ECRIT=0D=0A> > > Subject: [Ecrit] ELIN=0D= =0A> > >=0D=0A> > > LLDP-MED supports not just civic and coordinate based l= ocation=0D=0A> > > information, but also an ELIN. How does this type of loc= ation=0D=0A> > > information fit to the IETF Framework=3F Is this case cons= idered in=0D=0Aany=0D=0A> > > document=3F=0D=0A> > > I couldn't find any in= formation on how to proceed with this type=0D=0Aof=0D=0A> > > location info= rmation.=0D=0A> > >=0D=0A> > > cheers=0D=0A> > > Karl Heinz=0D=0A> > >=0D=0A= > > > _______________________________________________=0D=0A> > > Ecrit mail= ing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://www1.ietf.org/mailman= /listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A------------------------------------= ------------------------------------=0D=0A> ------------------------=0D=0A>= > This message is for the designated recipient only and may=0D=0A> > conta= in privileged, proprietary, or otherwise private information.=0D=0A> > If y= ou have received it in error, please notify the sender=0D=0A> > immediately= and delete the original. Any unauthorized use of=0D=0A> > this email is p= rohibited.=0D=0A> >=0D=0A--------------------------------------------------= ----------------------=0D=0A> ------------------------=0D=0A> > [mf2]=0D=0A= > >=0D=0A> >=0D=0A=0D=0A---------------------------------------------------= ---------------------------------------------=0D=0AThis message is for the = designated recipient only and may=0D=0Acontain privileged, proprietary, or = otherwise private information. =20=0D=0AIf you have received it in error, p= lease notify the sender=0D=0Aimmediately and delete the original. Any unau= thorized use of=0D=0Athis email is prohibited.=0D=0A-----------------------= -------------------------------------------------------------------------=0D= =0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 12 10:47:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrbVd-0003fy-DU; Mon, 12 Nov 2007 10:47:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrbVc-0003fJ-08 for ecrit@ietf.org; Mon, 12 Nov 2007 10:47:32 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrbVb-0004JV-A3 for ecrit@ietf.org; Mon, 12 Nov 2007 10:47:31 -0500 X-SEF-Processed: 5_0_0_910__2007_11_12_09_57_59 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Mon, 12 Nov 2007 09:57:58 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 12 Nov 2007 09:47:26 -0600 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 Subject: RE: [Ecrit] ELIN Date: Mon, 12 Nov 2007 09:47:26 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ELIN Thread-Index: AcglDrP0q71sDCJCRdaqX1m7oWU59wAAhDrgAAxOAiA= References: From: "Dawson, Martin" To: "Winterbottom, James" , "ECRIT" X-OriginalArrivalTime: 12 Nov 2007 15:47:26.0189 (UTC) FILETIME=[52C751D0:01C82543] X-Spam-Score: 3.5 (+++) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 And I guess the other point is that the PABX allocates the ELIN to the=0D=0A= outgoing call dynamically and assigns it to the originating extension=0D=0A= (in case of callback) for the duration of the call and some period after=0D= =0Acall termination=3F There should be a pool of ELINs for each ERL in case=0D= =0Amore than one extension is originating an emergency call from that ERL.=0D= =0A=0D=0AThe other half of the story is that this generally works in conjun= ction=0D=0Awith what is known as PS-ALI (Private switch ALI). It's a two po= rt=0D=0Aarrangement. It's a standard ALI from the PSAP perspective, but the=0D= =0Aenterprise has access to the database and can populate it with the=0D=0A= ELIN-ERL information.=0D=0A=0D=0AOne thing an LLDP-MED client could do is p= rovide the ELIN to the PABX in=0D=0Athe call setup. This is beyond the scop= e of the LLDP-MED specification.=0D=0A=0D=0AOn the other hand, it's all a b= it half-baked, and it really wasn't a=0D=0Agood idea to embed this sort of = application information down at the link=0D=0Alayer in the first place - IM= HO.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A=0D=0A=0D=0A-----Original Mes= sage-----=0D=0AFrom: Winterbottom, James [mailto:James.Winterbottom@andrew.= com]=20=0D=0ASent: Monday, 12 November 2007 8:47 PM=0D=0ATo: Karl Heinz Wol= f=0D=0ACc: ECRIT=0D=0ASubject: RE: [Ecrit] ELIN=0D=0A=0D=0AHi Karl Heinz,=0D= =0A=0D=0AIt is the only the extension that actually has the ELIN number tha= t gets=0D=0Acalled back. So all extensions with the same ELIN need to be cl= ose to=0D=0Aone another.=0D=0A=0D=0AAs to what the client does when its get= s the ELIN from LLDP-MED I have=0D=0Ano idea... *8)=0D=0A=0D=0ACheers=0D=0A= James=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Karl Heinz= Wolf [mailto:khwolf1@gmail.com]=0D=0A> Sent: Monday, 12 November 2007 8:31= PM=0D=0A> To: Winterbottom, James=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ec= rit] ELIN=0D=0A>=20=0D=0A> Hi James!=0D=0A>=20=0D=0A> Thank you for your de= tailed description of the ELIN.=0D=0A> One more question: how does the call= back from the PSAP work, if there=0D=0A> are multiple extensions with the s= ame ELIN=3F=0D=0A>=20=0D=0A> Anyway, in case a company uses ELINs, and LLDP= -MED location=0D=0A> information tells the client this ELIN, what is the cl= ient supposed to=0D=0A> do=3F=0D=0A>=20=0D=0A> cheers=0D=0A> karl heinz=0D=0A= >=20=0D=0A> On Nov 12, 2007 10:03 AM, Winterbottom, James=0D=0A> wrote:=0D=0A> > Hi Karl Heinz,=0D=0A> >=0D=0A> > An E= LIN is a specific callback number that represents an area in an=0D=0AMLTS=0D= =0A> > (Multi-Line Telephone System). As far as I know they are only used=0D= =0Ain=0D=0A> > the USA. The following description may not be 100% right, bu= t it is=0D=0A> > pretty close.=0D=0A> >=0D=0A> > Essentially if you have a = company or campus that occupies a large=0D=0Aarea,=0D=0A> > you can break t= his up into smaller areas to make it easier for=0D=0Aemergency=0D=0A> > ser= vice crews to find people. In some States this is mandated when=0D=0Athe=0D= =0A> > area becomes more than a certain size (8000 sqr feet is commonly=0D=0A= > > quoted). Generally what happens is that all telephone extensions in=0D=0A= a=0D=0A> > certain area are associated with what is called an ERL (emergenc= y=0D=0A> > resource location), this is done in the PABX provisioning. Each = ERL=0D=0Ais=0D=0A> > allocated an ELIN that serves as the presented calling= number to the=0D=0A> > PSAP for any extension provisioned against the ERL.= The PSAP is able=0D=0Ato=0D=0A> > use the ELIN to get the floor location a= nd area serviced by a=0D=0Aspecific=0D=0A> > ELIN. The ELIN also serves as = the number that the PSAP will callback=0D=0Ain=0D=0A> > the case of the cal= l being dropped.=0D=0A> >=0D=0A> > To this extent the ELIN is the way in wh= ich LLDP-MED currently=0D=0Asupports=0D=0A> > location by reference.=0D=0A>= >=0D=0A> > Please let me know if this isn't clear and I will try an clarif= y=0D=0A> > further.=0D=0A> >=0D=0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A>= >=0D=0A> > > -----Original Message-----=0D=0A> > > From: Karl Heinz Wolf [= mailto:khwolf1@gmail.com]=0D=0A> > > Sent: Monday, 12 November 2007 7:23 PM=0D= =0A> > > To: ECRIT=0D=0A> > > Subject: [Ecrit] ELIN=0D=0A> > >=0D=0A> > > L= LDP-MED supports not just civic and coordinate based location=0D=0A> > > in= formation, but also an ELIN. How does this type of location=0D=0A> > > info= rmation fit to the IETF Framework=3F Is this case considered in=0D=0Aany=0D= =0A> > > document=3F=0D=0A> > > I couldn't find any information on how to p= roceed with this type=0D=0Aof=0D=0A> > > location information.=0D=0A> > >=0D= =0A> > > cheers=0D=0A> > > Karl Heinz=0D=0A> > >=0D=0A> > > _______________= ________________________________=0D=0A> > > Ecrit mailing list=0D=0A> > > E= crit@ietf.org=0D=0A> > > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A= > >=0D=0A> >=0D=0A---------------------------------------------------------= ---------------=0D=0A> ------------------------=0D=0A> > This message is fo= r the designated recipient only and may=0D=0A> > contain privileged, propri= etary, or otherwise private information.=0D=0A> > If you have received it i= n error, please notify the sender=0D=0A> > immediately and delete the origi= nal. Any unauthorized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D= =0A------------------------------------------------------------------------=0D= =0A> ------------------------=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A=0D=0A-= -----------------------------------------------------------------------=0D=0A= ------------------------=0D=0AThis message is for the designated recipient = only and may=0D=0Acontain privileged, proprietary, or otherwise private inf= ormation. =20=0D=0AIf you have received it in error, please notify the send= er=0D=0Aimmediately and delete the original. Any unauthorized use of=0D=0A= this email is prohibited.=0D=0A--------------------------------------------= ----------------------------=0D=0A------------------------=0D=0A[mf2]=0D=0A=0D= =0A=0D=0A_______________________________________________=0D=0AEcrit mailing= list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/ecrit=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 12 11:08:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrbqH-0003dg-OW; Mon, 12 Nov 2007 11:08:53 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrbqG-0003dC-3W for ecrit@ietf.org; Mon, 12 Nov 2007 11:08:52 -0500 Received: from smtp.mitel.com ([216.191.234.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IrbqE-0006W6-L8 for ecrit@ietf.org; Mon, 12 Nov 2007 11:08:52 -0500 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 4CD882C08B; Mon, 12 Nov 2007 11:08:50 -0500 (EST) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com 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 kUxXnnKSCHtB; Mon, 12 Nov 2007 11:08:49 -0500 (EST) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id E31BA2C031; Mon, 12 Nov 2007 11:08:48 -0500 (EST) In-Reply-To: To: "Karl Heinz Wolf" , "Winterbottom, James" Subject: RE: [Ecrit] ELIN MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Mon, 12 Nov 2007 11:08:46 -0500 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 11/12/2007 11:08:45 AM, Serialize complete at 11/12/2007 11:08:45 AM X-Spam-Score: 1.7 (+) X-Scan-Signature: 9e1884bf469cda400682762c3e8d96c9 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="===============0003840843==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0003840843== Content-Type: multipart/alternative; boundary="=_alternative 0058B17885257391_=" This is a multipart message in MIME format. --=_alternative 0058B17885257391_= Content-Type: text/plain; charset="US-ASCII" Hi Karl, James' description earlier on how ELIN works is essentially correct. A couple of added bits: - ELIN can also be used for ECS call routing. If the call gets placed on an out of district GW, it can be used in PSTN to route to the correct (in district) PSAP. - At the PSAP, ELIN is effectively a dB index to look up details on the source of the call, based on ERL data that is provisioned in the PSAP dB (street location, in-building location, etc etc) - I don't *think* ELIN is generally used as the callback number. In ISDN-based signalling, there is both the ELIN and a callback number. I *think* the PSAP side is (or can be) provisioned with callback corresponding to the ELIN in its dB. The callback number is typically not an extension, but a designated responder within the enterprise at that location, e.g. the security desk. Perhaps others on the list with direct experience can comment on this point? > ... all extensions with the same ELIN need to be close to one another. Yes, all extensions with the same ELIN *will* be physically close together. But this is not directly related to callback. It is by definition of what the ERL is -- it is a small enough region in a building to allow emergency responders to find someone. > ... what the client does when its gets the ELIN from LLDP-MED I have no idea ELIN was added to LLDP-MED for completeness and for compatibility with existing PSTN infrastructure. Since existing E911 systems in N.A. use ELIN today, there was no easy way to support it with Civic and Geo types only. (I am a little surprised ELIN type has not been defined in IETF as well ... but that's another story.) Thinking was that the device could receive ELIN, pass it in SIP signalling towards PSTN GW, that would then insert the ELIN into PSTN trunk signalling. I do not know if anyone uses it this way. > To this extent the ELIN is the way in which LLDP-MED currently supports > location by reference. Yes, ELIN is effectively a form of location-by-reference. LLDP-MED can also be readily extended to support LbyR in the sense used in Geopriv / ECRIT as well. Since location objects are directly supplied by the network infrastructure in LLDP-MED's case, it is not entirely clear to me why LbyR would really be needed / useful for LLDP-MED deployments. Cheers, Peter Blatherwick "Winterbottom, James" 12.11.07 04:46 To: "Karl Heinz Wolf" cc: ECRIT Subject: RE: [Ecrit] ELIN Hi Karl Heinz, It is the only the extension that actually has the ELIN number that gets called back. So all extensions with the same ELIN need to be close to one another. As to what the client does when its gets the ELIN from LLDP-MED I have no idea... *8) Cheers James > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Monday, 12 November 2007 8:31 PM > To: Winterbottom, James > Cc: ECRIT > Subject: Re: [Ecrit] ELIN > > Hi James! > > Thank you for your detailed description of the ELIN. > One more question: how does the callback from the PSAP work, if there > are multiple extensions with the same ELIN? > > Anyway, in case a company uses ELINs, and LLDP-MED location > information tells the client this ELIN, what is the client supposed to > do? > > cheers > karl heinz > > On Nov 12, 2007 10:03 AM, Winterbottom, James > wrote: > > Hi Karl Heinz, > > > > An ELIN is a specific callback number that represents an area in an MLTS > > (Multi-Line Telephone System). As far as I know they are only used in > > the USA. The following description may not be 100% right, but it is > > pretty close. > > > > Essentially if you have a company or campus that occupies a large area, > > you can break this up into smaller areas to make it easier for emergency > > service crews to find people. In some States this is mandated when the > > area becomes more than a certain size (8000 sqr feet is commonly > > quoted). Generally what happens is that all telephone extensions in a > > certain area are associated with what is called an ERL (emergency > > resource location), this is done in the PABX provisioning. Each ERL is > > allocated an ELIN that serves as the presented calling number to the > > PSAP for any extension provisioned against the ERL. The PSAP is able to > > use the ELIN to get the floor location and area serviced by a specific > > ELIN. The ELIN also serves as the number that the PSAP will callback in > > the case of the call being dropped. > > > > To this extent the ELIN is the way in which LLDP-MED currently supports > > location by reference. > > > > Please let me know if this isn't clear and I will try an clarify > > further. > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > Sent: Monday, 12 November 2007 7:23 PM > > > To: ECRIT > > > Subject: [Ecrit] ELIN > > > > > > LLDP-MED supports not just civic and coordinate based location > > > information, but also an ELIN. How does this type of location > > > information fit to the IETF Framework? Is this case considered in any > > > document? > > > I couldn't find any information on how to proceed with this type of > > > location information. > > > > > > cheers > > > Karl Heinz > > > > > > _______________________________________________ > > > 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] > > > > ------------------------------------------------------------------------------------------------ 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 0058B17885257391_= Content-Type: text/html; charset="US-ASCII"
Hi Karl,  
James' description earlier on how ELIN works is essentially correct.  A couple of added bits:

- ELIN can also be used for ECS call routing.  If the call gets placed on an out of district GW, it can be used in PSTN to route to the correct (in district) PSAP.  

- At the PSAP, ELIN is effectively a dB index to look up details on the source of the call, based on ERL data that is provisioned in the PSAP dB (street location, in-building location, etc etc)

- I don't *think* ELIN is generally used as the callback number.  In ISDN-based signalling, there is both the ELIN and a callback number.  I *think* the PSAP side is (or can be) provisioned with callback corresponding to the ELIN in its dB.  The callback number is typically not an extension, but a designated responder within the enterprise at that location, e.g. the security desk.  Perhaps others on the list with direct experience can comment on this point?  

> ... all extensions with the same ELIN need to be close to one another.
Yes, all extensions with the same ELIN *will* be physically close together.  But this is not directly related to callback.  It is by definition of what the ERL is -- it is a small enough region in a building to allow emergency responders to find someone.  

> ... what the client does when its gets the ELIN from LLDP-MED I have no idea
ELIN was added to LLDP-MED for completeness and for compatibility with existing PSTN infrastructure.  Since existing E911 systems in N.A. use ELIN today, there was no easy way to support it with Civic and Geo types only.  (I am a little surprised ELIN type has not been defined in IETF as well ... but that's another story.)  Thinking was that the device could receive ELIN, pass it in SIP signalling towards PSTN GW, that would then insert the ELIN into PSTN trunk signalling.  I do not know if anyone uses it this way.  

> To this extent the ELIN is the way in which LLDP-MED currently supports
> location by reference.
Yes, ELIN is effectively a form of location-by-reference.  LLDP-MED can also be readily extended to support LbyR in the sense used in Geopriv / ECRIT as well.  Since location objects are directly supplied by the network infrastructure in LLDP-MED's case, it is not entirely clear to me why LbyR would really be needed / useful for LLDP-MED deployments.  

Cheers,
Peter Blatherwick





"Winterbottom, James" <James.Winterbottom@andrew.com>

12.11.07 04:46

       
        To:        "Karl Heinz Wolf" <khwolf1@gmail.com>
        cc:        ECRIT <ecrit@ietf.org>
        Subject:        RE: [Ecrit] ELIN



Hi Karl Heinz,

It is the only the extension that actually has the ELIN number that gets
called back. So all extensions with the same ELIN need to be close to
one another.

As to what the client does when its gets the ELIN from LLDP-MED I have
no idea... *8)

Cheers
James


> -----Original Message-----
> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]
> Sent: Monday, 12 November 2007 8:31 PM
> To: Winterbottom, James
> Cc: ECRIT
> Subject: Re: [Ecrit] ELIN
>
> Hi James!
>
> Thank you for your detailed description of the ELIN.
> One more question: how does the callback from the PSAP work, if there
> are multiple extensions with the same ELIN?
>
> Anyway, in case a company uses ELINs, and LLDP-MED location
> information tells the client this ELIN, what is the client supposed to
> do?
>
> cheers
> karl heinz
>
> On Nov 12, 2007 10:03 AM, Winterbottom, James
> <James.Winterbottom@andrew.com> wrote:
> > Hi Karl Heinz,
> >
> > An ELIN is a specific callback number that represents an area in an
MLTS
> > (Multi-Line Telephone System). As far as I know they are only used
in
> > the USA. The following description may not be 100% right, but it is
> > pretty close.
> >
> > Essentially if you have a company or campus that occupies a large
area,
> > you can break this up into smaller areas to make it easier for
emergency
> > service crews to find people. In some States this is mandated when
the
> > area becomes more than a certain size (8000 sqr feet is commonly
> > quoted). Generally what happens is that all telephone extensions in
a
> > certain area are associated with what is called an ERL (emergency
> > resource location), this is done in the PABX provisioning. Each ERL
is
> > allocated an ELIN that serves as the presented calling number to the
> > PSAP for any extension provisioned against the ERL. The PSAP is able
to
> > use the ELIN to get the floor location and area serviced by a
specific
> > ELIN. The ELIN also serves as the number that the PSAP will callback
in
> > the case of the call being dropped.
> >
> > To this extent the ELIN is the way in which LLDP-MED currently
supports
> > location by reference.
> >
> > Please let me know if this isn't clear and I will try an clarify
> > further.
> >
> > Cheers
> > James
> >
> >
> > > -----Original Message-----
> > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]
> > > Sent: Monday, 12 November 2007 7:23 PM
> > > To: ECRIT
> > > Subject: [Ecrit] ELIN
> > >
> > > LLDP-MED supports not just civic and coordinate based location
> > > information, but also an ELIN. How does this type of location
> > > information fit to the IETF Framework? Is this case considered in
any
> > > document?
> > > I couldn't find any information on how to proceed with this type
of
> > > location information.
> > >
> > > cheers
> > > Karl Heinz
> > >
> > > _______________________________________________
> > > 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]
> >
> >

------------------------------------------------------------------------------------------------
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 0058B17885257391_=-- --===============0003840843== 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 --===============0003840843==-- From ecrit-bounces@ietf.org Mon Nov 12 11:58:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ircbq-0005Fd-4K; Mon, 12 Nov 2007 11:58:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ircbo-00053Z-Ko for ecrit@ietf.org; Mon, 12 Nov 2007 11:58:00 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ircbj-00040H-NC for ecrit@ietf.org; Mon, 12 Nov 2007 11:58:00 -0500 X-IronPort-AV: E=Sophos;i="4.21,406,1188792000"; d="scan'208,217";a="82863790" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.avaya.com with ESMTP; 12 Nov 2007 11:57:55 -0500 X-IronPort-AV: E=Sophos;i="4.21,406,1188792000"; d="scan'208,217";a="130044149" Received: from unknown (HELO 300815ANEX3.global.avaya.com) ([198.152.6.138]) by co300216-co-erhwest-out.avaya.com with ESMTP; 12 Nov 2007 11:57:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] ELIN Date: Mon, 12 Nov 2007 11:47:54 -0500 Message-ID: <3036F4A94122BD4AAAAB441FE8884528791166@300815ANEX3.global.avaya.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ELIN Thread-Index: AcglRnKvOhLglwJtQKu99Ew/TEOLPQAA0LWA References: From: "Rodrig, Benny (Benny)" To: , "Karl Heinz Wolf" , "Winterbottom, James" X-Spam-Score: 1.7 (+) X-Scan-Signature: 4863a9796402a44fdb52482f353618fe 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="===============1458878316==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============1458878316== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8254B.CC090D4C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8254B.CC090D4C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another point to add is that when an endpoint moves within the campus/enterprise, a different ELIN may have to be passed to the PSAP with the emergency call, depending on the endpoint's location. To figure this out automatically, getting the right ELIN directly from the local network via LLDP-MED can be a good solution. =20 Regarding the callback point below - I think the ELIN is typically used as the callback number, and the MLTS can then either forward the callback to the original caller or to a designated responder e.g. the security desk. =20 Benny ________________________________ From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20 Sent: Monday, November 12, 2007 11:09 AM To: Karl Heinz Wolf; Winterbottom, James Cc: ECRIT Subject: RE: [Ecrit] ELIN =09 =09 Hi Karl, =20 James' description earlier on how ELIN works is essentially correct. A couple of added bits:=20 =09 - ELIN can also be used for ECS call routing. If the call gets placed on an out of district GW, it can be used in PSTN to route to the correct (in district) PSAP. =20 =09 - At the PSAP, ELIN is effectively a dB index to look up details on the source of the call, based on ERL data that is provisioned in the PSAP dB (street location, in-building location, etc etc)=20 =09 - I don't *think* ELIN is generally used as the callback number. In ISDN-based signalling, there is both the ELIN and a callback number. I *think* the PSAP side is (or can be) provisioned with callback corresponding to the ELIN in its dB. The callback number is typically not an extension, but a designated responder within the enterprise at that location, e.g. the security desk. Perhaps others on the list with direct experience can comment on this point? =20 =09 > ... all extensions with the same ELIN need to be close to one another.=20 Yes, all extensions with the same ELIN *will* be physically close together. But this is not directly related to callback. It is by definition of what the ERL is -- it is a small enough region in a building to allow emergency responders to find someone. =20 =09 > ... what the client does when its gets the ELIN from LLDP-MED I have no idea=20 ELIN was added to LLDP-MED for completeness and for compatibility with existing PSTN infrastructure. Since existing E911 systems in N.A. use ELIN today, there was no easy way to support it with Civic and Geo types only. (I am a little surprised ELIN type has not been defined in IETF as well ... but that's another story.) Thinking was that the device could receive ELIN, pass it in SIP signalling towards PSTN GW, that would then insert the ELIN into PSTN trunk signalling. I do not know if anyone uses it this way. =20 =09 > To this extent the ELIN is the way in which LLDP-MED currently supports > location by reference.=20 Yes, ELIN is effectively a form of location-by-reference. LLDP-MED can also be readily extended to support LbyR in the sense used in Geopriv / ECRIT as well. Since location objects are directly supplied by the network infrastructure in LLDP-MED's case, it is not entirely clear to me why LbyR would really be needed / useful for LLDP-MED deployments. =20 =09 Cheers,=20 Peter Blatherwick=20 =09 =09 =09 =09 =09 =09 "Winterbottom, James" =20 12.11.07 04:46=20 =20 To: "Karl Heinz Wolf" =20 cc: ECRIT =20 Subject: RE: [Ecrit] ELIN Hi Karl Heinz, =09 It is the only the extension that actually has the ELIN number that gets called back. So all extensions with the same ELIN need to be close to one another. =09 As to what the client does when its gets the ELIN from LLDP-MED I have no idea... *8) =09 Cheers James =09 =09 > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Monday, 12 November 2007 8:31 PM > To: Winterbottom, James > Cc: ECRIT > Subject: Re: [Ecrit] ELIN >=20 > Hi James! >=20 > Thank you for your detailed description of the ELIN. > One more question: how does the callback from the PSAP work, if there > are multiple extensions with the same ELIN? >=20 > Anyway, in case a company uses ELINs, and LLDP-MED location > information tells the client this ELIN, what is the client supposed to > do? >=20 > cheers > karl heinz >=20 > On Nov 12, 2007 10:03 AM, Winterbottom, James > wrote: > > Hi Karl Heinz, > > > > An ELIN is a specific callback number that represents an area in an MLTS > > (Multi-Line Telephone System). As far as I know they are only used in > > the USA. The following description may not be 100% right, but it is > > pretty close. > > > > Essentially if you have a company or campus that occupies a large area, > > you can break this up into smaller areas to make it easier for emergency > > service crews to find people. In some States this is mandated when the > > area becomes more than a certain size (8000 sqr feet is commonly > > quoted). Generally what happens is that all telephone extensions in a > > certain area are associated with what is called an ERL (emergency > > resource location), this is done in the PABX provisioning. Each ERL is > > allocated an ELIN that serves as the presented calling number to the > > PSAP for any extension provisioned against the ERL. The PSAP is able to > > use the ELIN to get the floor location and area serviced by a specific > > ELIN. The ELIN also serves as the number that the PSAP will callback in > > the case of the call being dropped. > > > > To this extent the ELIN is the way in which LLDP-MED currently supports > > location by reference. > > > > Please let me know if this isn't clear and I will try an clarify > > further. > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > Sent: Monday, 12 November 2007 7:23 PM > > > To: ECRIT > > > Subject: [Ecrit] ELIN > > > > > > LLDP-MED supports not just civic and coordinate based location > > > information, but also an ELIN. How does this type of location > > > information fit to the IETF Framework? Is this case considered in any > > > document? > > > I couldn't find any information on how to proceed with this type of > > > location information. > > > > > > cheers > > > Karl Heinz > > > > > > _______________________________________________ > > > Ecrit mailing list > > > Ecrit@ietf.org > > > https://www1.ietf.org/mailman/listinfo/ecrit > > > > =09 ------------------------------------------------------------------------ > ------------------------ > > 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. > > =09 ------------------------------------------------------------------------ > ------------------------ > > [mf2] > > > > =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] =09 =09 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit =09 =09 ------_=_NextPart_001_01C8254B.CC090D4C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Another point to add is that when an endpoint = moves within=20 the campus/enterprise, a different ELIN may have to be passed to the = PSAP with=20 the emergency call, depending on the endpoint's location. To figure this = out=20 automatically, getting the right ELIN directly from the local network = via=20 LLDP-MED can be a good solution.
 
Regarding the callback point below - I think = the ELIN is=20 typically used as the callback number, and the MLTS can then either = forward the=20 callback to the original caller or to a designated responder e.g. the = security=20 desk.
 
Benny

From: peter_blatherwick@mitel.com=20 [mailto:peter_blatherwick@mitel.com]
Sent: Monday, November = 12,=20 2007 11:09 AM
To: Karl Heinz Wolf; Winterbottom, = James
Cc:=20 ECRIT
Subject: RE: [Ecrit] ELIN


Hi Karl,   =
James' description earlier on how ELIN = works is=20 essentially correct.  A couple of added bits: =

- ELIN can also be used for ECS call = routing.  If=20 the call gets placed on an out of district GW, it can be used in PSTN = to route=20 to the correct (in district) PSAP.  

- At the PSAP, ELIN is effectively a dB index to look up = details on the=20 source of the call, based on ERL data that is provisioned in the PSAP = dB=20 (street location, in-building location, etc etc)

- I don't *think* ELIN is generally used as = the=20 callback number.  In ISDN-based signalling, there is both the = ELIN and a=20 callback number.  I *think* the PSAP side is (or can be) = provisioned with=20 callback corresponding to the ELIN in its dB.  The callback = number is=20 typically not an extension, but a designated responder within the = enterprise=20 at that location, e.g. the security desk.  Perhaps others on the = list=20 with direct experience can comment on this point?   =

> ... all = extensions with=20 the same ELIN need to be close to one another.
Yes, all extensions with the same ELIN = *will* be=20 physically close together.  But this is not directly related to = callback.=20  It is by definition of what the ERL is -- it is a small enough = region in=20 a building to allow emergency responders to find someone. =  =20

> ... what the=20 client does when its gets the ELIN from LLDP-MED I have no = idea=20
ELIN was added to LLDP-MED for = completeness=20 and for compatibility with existing PSTN infrastructure.  Since = existing=20 E911 systems in N.A. use ELIN today, there was no easy way to support = it with=20 Civic and Geo types only.  (I am a little surprised ELIN type has = not=20 been defined in IETF as well ... but that's another story.) =  Thinking was=20 that the device could receive ELIN, pass it in SIP signalling towards = PSTN GW,=20 that would then insert the ELIN into PSTN trunk signalling.  I do = not=20 know if anyone uses it this way.  

> To this extent the ELIN is the = way in=20 which LLDP-MED currently supports
> location by = reference.=20
Yes, ELIN is effectively a form = of=20 location-by-reference.  LLDP-MED can also be readily extended to = support=20 LbyR in the sense used in Geopriv / ECRIT as well.  Since = location=20 objects are directly supplied by the network infrastructure in = LLDP-MED's=20 case, it is not entirely clear to me why LbyR would really be needed / = useful=20 for LLDP-MED deployments.  

Cheers,
Peter=20 Blatherwick





"Winterbottom, James"=20 <James.Winterbottom@andrew.com>=20

12.11.07 04:46

        =
        To: =    =20    "Karl Heinz Wolf" <khwolf1@gmail.com>=20
        = cc:  =20      ECRIT <ecrit@ietf.org> =
        Subject: =  =20      RE: [Ecrit]=20 ELIN



Hi Karl = Heinz,

It is the only the extension that actually has the ELIN = number=20 that gets
called back. So all extensions with the same ELIN need to = be=20 close to
one another.

As to what the client does when its = gets the=20 ELIN from LLDP-MED I have
no idea...=20 *8)

Cheers
James


> -----Original = Message-----
>=20 From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]
> Sent: Monday, = 12=20 November 2007 8:31 PM
> To: Winterbottom, James
> Cc:=20 ECRIT
> Subject: Re: [Ecrit] ELIN
>
> Hi = James!
>=20
> Thank you for your detailed description of the ELIN.
> = One more=20 question: how does the callback from the PSAP work, if there
> = are=20 multiple extensions with the same ELIN?
>
> Anyway, in = case a=20 company uses ELINs, and LLDP-MED location
> information tells = the client=20 this ELIN, what is the client supposed to
> do?
>
> = cheers
> karl heinz
>
> On Nov 12, 2007 10:03 AM,=20 Winterbottom, James
> <James.Winterbottom@andrew.com>=20 wrote:
> > Hi Karl Heinz,
> >
> > An ELIN = is a=20 specific callback number that represents an area in an
MLTS
> = >=20 (Multi-Line Telephone System). As far as I know they are only=20 used
in
> > the USA. The following description may not be = 100%=20 right, but it is
> > pretty close.
> >
> >=20 Essentially if you have a company or campus that occupies a=20 large
area,
> > you can break this up into smaller areas = to make=20 it easier for
emergency
> > service crews to find people. = In some=20 States this is mandated when
the
> > area becomes more = than a=20 certain size (8000 sqr feet is commonly
> > quoted). = Generally what=20 happens is that all telephone extensions in
a
> > certain = area are=20 associated with what is called an ERL (emergency
> > resource = location), this is done in the PABX provisioning. Each = ERL
is
> >=20 allocated an ELIN that serves as the presented calling number to = the
>=20 > PSAP for any extension provisioned against the ERL. The PSAP is=20 able
to
> > use the ELIN to get the floor location and = area=20 serviced by a
specific
> > ELIN. The ELIN also serves as = the=20 number that the PSAP will callback
in
> > the case of the = call=20 being dropped.
> >
> > To this extent the ELIN is = the way in=20 which LLDP-MED currently
supports
> > location by=20 reference.
> >
> > Please let me know if this isn't = clear=20 and I will try an clarify
> > further.
> >
> = >=20 Cheers
> > James
> >
> >
> > >=20 -----Original Message-----
> > > From: Karl Heinz Wolf=20 [mailto:khwolf1@gmail.com]
> > > Sent: Monday, 12 November = 2007=20 7:23 PM
> > > To: ECRIT
> > > Subject: [Ecrit] = ELIN
> > >
> > > LLDP-MED supports not just = civic and=20 coordinate based location
> > > information, but also an = ELIN. How=20 does this type of location
> > > information fit to the = IETF=20 Framework? Is this case considered in
any
> > >=20 document?
> > > I couldn't find any information on how to = proceed=20 with this type
of
> > > location information.
> = >=20 >
> > > cheers
> > > Karl Heinz
> = >=20 >
> > > = _______________________________________________
>=20 > > Ecrit mailing list
> > > Ecrit@ietf.org
> = >=20 > https://www1.ietf.org/mailman/listinfo/ecrit
> >
> = = >
-----------------------------------------------------------------= -------
>=20 ------------------------
> > This message is for the = designated=20 recipient only and may
> > contain privileged, proprietary, = or=20 otherwise private information.
> > If you have received it in = error,=20 please notify the sender
> > immediately and delete the = original.=20  Any unauthorized use of
> > this email is = prohibited.
>=20 = >
-----------------------------------------------------------------= -------
>=20 ------------------------
> > [mf2]
> >
>=20 = >

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


______________= _________________________________
Ecrit=20 mailing=20 = list
Ecrit@ietf.org
https://www1.ietf.org/mailman/listinfo/ecrit
------_=_NextPart_001_01C8254B.CC090D4C-- --===============1458878316== 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 --===============1458878316==-- From ecrit-bounces@ietf.org Mon Nov 12 12:06:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcjZ-0003eM-1i; Mon, 12 Nov 2007 12:06:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IrcjX-0003a6-Mj for ecrit@ietf.org; Mon, 12 Nov 2007 12:05:59 -0500 Received: from s87.loopia.se ([194.9.94.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IrcjT-0004Iv-PX for ecrit@ietf.org; Mon, 12 Nov 2007 12:05:59 -0500 Received: (qmail 42637 invoked from network); 12 Nov 2007 17:05:53 -0000 Received: from s34.loopia.se (HELO s24.loopia.se) ([194.9.94.70]) (envelope-sender ) by s87.loopia.se (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 12 Nov 2007 17:05:53 -0000 Received: (qmail 55935 invoked from network); 12 Nov 2007 17:05:52 -0000 Received: from 177.99.wireless.igfbrazil2007.br (HELO GunnarH) (gunnar.hellstrom@omnitor.se@[189.76.99.177]) (envelope-sender ) by s24.loopia.se (qmail-ldap-1.03) with SMTP for ; 12 Nov 2007 17:05:52 -0000 From: =?iso-8859-1?Q?Gunnar_Hellstr=F6m?= To: "Ecrit@Ietf. Org" Subject: RE: [Ecrit] Proposed Agenda for IETF#70 Date: Mon, 12 Nov 2007 18:05:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <4736DFB3.3060203@gmx.net> Thread-Index: AcgkUXJhT8s0RvIcSca4beNmp4LQ3wAGV5SA X-Spam-Score: -1.0 (-) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: Arnoud van Wijk 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 Message-Id: Hannes, Can the issues around detailing of accessibility for people with disabilities and invoking relay services in the calls be a subtopic = under "Open issues with framework and Pone BCP?" I know Arnoud van Wijk will be there and can be prepared to cover it. ( this links to a question I just sent to the list, titled "Mechanisms = for adding supporting services to emergency calls" )=20 Gunnar =20 ------------------------------------------------------------------- Gunnar Hellstr=F6m Omnitor gunnar.hellstrom@omnitor.se Tel: +46708204288 www.omnitor.se -----Original Message----- From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20 Sent: Sunday, November 11, 2007 11:56 AM To: ECRIT Subject: [Ecrit] Proposed Agenda for IETF#70 Here is a first try... * Status Update and Agenda Bashing Chairs * IESG Comments regarding LoST, LoST mapping architecture and LoST = discovery Chairs http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-03.txt http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-0= 2.t xt * Open issues with Framework and Phone BCP Brian Rosen http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt * Location Hiding Solution Space Yet to be decided http://tools.ietf.org/html/draft-schulzrinne-ecrit-location-hiding-req-00= http://tools.ietf.org/html/draft-barnes-ecrit-auth * Unauthenticated Emergency Services Yet to be decided http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access= -00 * Forest Guide Exchange Protocol Henning Schulzrinne http://tools.ietf.org/html/draft-schulzrinne-ecrit-lost-sync-00 * Specifying Holes in LoST Service Boundaries James Winterbottom http://tools.ietf.org/html/draft-winterbottom-ecrit-specifying-holes-00.t= xt * RPH Header for Emergency Services James Polk http://tools.ietf.org/wg/ecrit/draft-polk-ecrit-local-emergency-rph-names= pac e-01.txt _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit __________ NOD32 2651 (20071110) Information __________ Detta meddelande =E4r genoms=F6kt av NOD32 Antivirus. http://www.nod32.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 12 13:57:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IreTd-0008Ul-9a; Mon, 12 Nov 2007 13:57:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IreTa-0008Qg-UL for ecrit@ietf.org; Mon, 12 Nov 2007 13:57:39 -0500 Received: from smtp.mitel.com ([216.191.234.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IreTY-0005Sr-Ve for ecrit@ietf.org; Mon, 12 Nov 2007 13:57:38 -0500 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 9E9EA2C07A; Mon, 12 Nov 2007 13:57:36 -0500 (EST) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com 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 TsFQ3s597x84; Mon, 12 Nov 2007 13:57:34 -0500 (EST) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id B11CB2C043; Mon, 12 Nov 2007 13:57:34 -0500 (EST) In-Reply-To: <3036F4A94122BD4AAAAB441FE8884528791166@300815ANEX3.global.avaya.com> To: "Rodrig, Benny (Benny)" Subject: RE: [Ecrit] ELIN MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Mon, 12 Nov 2007 13:57:31 -0500 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 11/12/2007 01:57:30 PM, Serialize complete at 11/12/2007 01:57:30 PM X-Spam-Score: 1.7 (+) X-Scan-Signature: 78a8240bd7a9c0d7033035fffd7b84c6 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="===============1059391114==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============1059391114== Content-Type: multipart/alternative; boundary="=_alternative 0068249E85257391_=" This is a multipart message in MIME format. --=_alternative 0068249E85257391_= Content-Type: text/plain; charset="US-ASCII" Hi again, and thanks for the further input Benny, Yes, I certainly agree (contrary to Martin's obviously inflammatory and self-serving comments earlier) that LLDP-MED can make a very good, simple solution in many situations. And many of those scenarios need to address working with traditional E911 systems, hence inclusion of ELIN in LLDP-MED. For better or worse, interworking with pre-existing ECS systems such as E911 is not a part of ECRIT's mandate, hence is not described in any ECRIT document, or anywhere in IETF for that matter. LLDP-MED only defines the protocol and exchange of TLVs. The usage is defined in other documents. For a bit more background on this, and how it can play in to the application level, see also TIA's TSB-146-A which describes several network topologies and possible solutions to the emergency call location problem, as well as others pieces of the puzzle. Note that this document was not intended to define any particular solution, but to discuss a range of alternatives. Although recently updated (in March 07) it is also a second revision with the first dating several years back now (2004 I believe). Available at: http://www.tiaonline.org/standards/technology/voip/documents/TSB-146-AFinalforPublication.pdf (You will likely be asked to fill in some info and press [I agree] button on the way.) See also DSL Forum draft WT-164 recently posted to this list, which shows device startup state diagrams including LLDP-MED, DHCP and HELD. Cheers, Peter Blatherwick "Rodrig, Benny (Benny)" 12.11.07 11:47 To: , "Karl Heinz Wolf" , "Winterbottom, James" cc: "ECRIT" Subject: RE: [Ecrit] ELIN Another point to add is that when an endpoint moves within the campus/enterprise, a different ELIN may have to be passed to the PSAP with the emergency call, depending on the endpoint's location. To figure this out automatically, getting the right ELIN directly from the local network via LLDP-MED can be a good solution. Regarding the callback point below - I think the ELIN is typically used as the callback number, and the MLTS can then either forward the callback to the original caller or to a designated responder e.g. the security desk. Benny From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com] Sent: Monday, November 12, 2007 11:09 AM To: Karl Heinz Wolf; Winterbottom, James Cc: ECRIT Subject: RE: [Ecrit] ELIN Hi Karl, James' description earlier on how ELIN works is essentially correct. A couple of added bits: - ELIN can also be used for ECS call routing. If the call gets placed on an out of district GW, it can be used in PSTN to route to the correct (in district) PSAP. - At the PSAP, ELIN is effectively a dB index to look up details on the source of the call, based on ERL data that is provisioned in the PSAP dB (street location, in-building location, etc etc) - I don't *think* ELIN is generally used as the callback number. In ISDN-based signalling, there is both the ELIN and a callback number. I *think* the PSAP side is (or can be) provisioned with callback corresponding to the ELIN in its dB. The callback number is typically not an extension, but a designated responder within the enterprise at that location, e.g. the security desk. Perhaps others on the list with direct experience can comment on this point? > ... all extensions with the same ELIN need to be close to one another. Yes, all extensions with the same ELIN *will* be physically close together. But this is not directly related to callback. It is by definition of what the ERL is -- it is a small enough region in a building to allow emergency responders to find someone. > ... what the client does when its gets the ELIN from LLDP-MED I have no idea ELIN was added to LLDP-MED for completeness and for compatibility with existing PSTN infrastructure. Since existing E911 systems in N.A. use ELIN today, there was no easy way to support it with Civic and Geo types only. (I am a little surprised ELIN type has not been defined in IETF as well ... but that's another story.) Thinking was that the device could receive ELIN, pass it in SIP signalling towards PSTN GW, that would then insert the ELIN into PSTN trunk signalling. I do not know if anyone uses it this way. > To this extent the ELIN is the way in which LLDP-MED currently supports > location by reference. Yes, ELIN is effectively a form of location-by-reference. LLDP-MED can also be readily extended to support LbyR in the sense used in Geopriv / ECRIT as well. Since location objects are directly supplied by the network infrastructure in LLDP-MED's case, it is not entirely clear to me why LbyR would really be needed / useful for LLDP-MED deployments. Cheers, Peter Blatherwick "Winterbottom, James" 12.11.07 04:46 To: "Karl Heinz Wolf" cc: ECRIT Subject: RE: [Ecrit] ELIN Hi Karl Heinz, It is the only the extension that actually has the ELIN number that gets called back. So all extensions with the same ELIN need to be close to one another. As to what the client does when its gets the ELIN from LLDP-MED I have no idea... *8) Cheers James > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Monday, 12 November 2007 8:31 PM > To: Winterbottom, James > Cc: ECRIT > Subject: Re: [Ecrit] ELIN > > Hi James! > > Thank you for your detailed description of the ELIN. > One more question: how does the callback from the PSAP work, if there > are multiple extensions with the same ELIN? > > Anyway, in case a company uses ELINs, and LLDP-MED location > information tells the client this ELIN, what is the client supposed to > do? > > cheers > karl heinz > > On Nov 12, 2007 10:03 AM, Winterbottom, James > wrote: > > Hi Karl Heinz, > > > > An ELIN is a specific callback number that represents an area in an MLTS > > (Multi-Line Telephone System). As far as I know they are only used in > > the USA. The following description may not be 100% right, but it is > > pretty close. > > > > Essentially if you have a company or campus that occupies a large area, > > you can break this up into smaller areas to make it easier for emergency > > service crews to find people. In some States this is mandated when the > > area becomes more than a certain size (8000 sqr feet is commonly > > quoted). Generally what happens is that all telephone extensions in a > > certain area are associated with what is called an ERL (emergency > > resource location), this is done in the PABX provisioning. Each ERL is > > allocated an ELIN that serves as the presented calling number to the > > PSAP for any extension provisioned against the ERL. The PSAP is able to > > use the ELIN to get the floor location and area serviced by a specific > > ELIN. The ELIN also serves as the number that the PSAP will callback in > > the case of the call being dropped. > > > > To this extent the ELIN is the way in which LLDP-MED currently supports > > location by reference. > > > > Please let me know if this isn't clear and I will try an clarify > > further. > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > Sent: Monday, 12 November 2007 7:23 PM > > > To: ECRIT > > > Subject: [Ecrit] ELIN > > > > > > LLDP-MED supports not just civic and coordinate based location > > > information, but also an ELIN. How does this type of location > > > information fit to the IETF Framework? Is this case considered in any > > > document? > > > I couldn't find any information on how to proceed with this type of > > > location information. > > > > > > cheers > > > Karl Heinz > > > > > > _______________________________________________ > > > 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] > > > > ------------------------------------------------------------------------------------------------ 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 0068249E85257391_= Content-Type: text/html; charset="US-ASCII"
Hi again, and thanks for the further input Benny,

Yes, I certainly agree (contrary to Martin's obviously inflammatory and self-serving comments earlier) that LLDP-MED can make a very good, simple solution in many situations.  And many of those scenarios need to address working with traditional E911 systems, hence inclusion of ELIN in LLDP-MED.  For better or worse, interworking with pre-existing ECS systems such as E911 is not a part of ECRIT's mandate, hence is not described in any ECRIT document, or anywhere in IETF for that matter.    

LLDP-MED only defines the protocol and exchange of TLVs.  The usage is defined in other documents.

For a bit more background on this, and how it can play in to the application level, see also TIA's TSB-146-A which describes several network topologies and possible solutions to the emergency call location problem, as well as others pieces of the puzzle.  Note that this document was not intended to define any particular solution, but to discuss a range of alternatives.  Although recently updated (in March 07) it is also a second revision with the first dating several years back now (2004 I believe).  Available at:
    http://www.tiaonline.org/standards/technology/voip/documents/TSB-146-AFinalforPublication.pdf
(You will likely be asked to fill in some info and press [I agree] button on the way.)  

See also DSL Forum draft WT-164 recently posted to this list, which shows device startup state diagrams including LLDP-MED, DHCP and HELD.    

Cheers,
Peter Blatherwick




"Rodrig, Benny (Benny)" <brodrig@avaya.com>

12.11.07 11:47

       
        To:        <peter_blatherwick@mitel.com>, "Karl Heinz Wolf" <khwolf1@gmail.com>, "Winterbottom, James" <James.Winterbottom@andrew.com>
        cc:        "ECRIT" <ecrit@ietf.org>
        Subject:        RE: [Ecrit] ELIN



Another point to add is that when an endpoint moves within the campus/enterprise, a different ELIN may have to be passed to the PSAP with the emergency call, depending on the endpoint's location. To figure this out automatically, getting the right ELIN directly from the local network via LLDP-MED can be a good solution.
 
Regarding the callback point below - I think the ELIN is typically used as the callback number, and the MLTS can then either forward the callback to the original caller or to a designated responder e.g. the security desk.
 
Benny

From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
Sent: Monday, November 12, 2007 11:09 AM
To: Karl Heinz Wolf; Winterbottom, James
Cc: ECRIT
Subject: RE: [Ecrit] ELIN

Hi Karl,  
James' description earlier on how ELIN works is essentially correct.  A couple of added bits:

- ELIN can also be used for ECS call routing.  If the call gets placed on an out of district GW, it can be used in PSTN to route to the correct (in district) PSAP.  

- At the PSAP, ELIN is effectively a dB index to look up details on the source of the call, based on ERL data that is provisioned in the PSAP dB (street location, in-building location, etc etc)

- I don't *think* ELIN is generally used as the callback number.  In ISDN-based signalling, there is both the ELIN and a callback number.  I *think* the PSAP side is (or can be) provisioned with callback corresponding to the ELIN in its dB.  The callback number is typically not an extension, but a designated responder within the enterprise at that location, e.g. the security desk.  Perhaps others on the list with direct experience can comment on this point?  

> ... all extensions with the same ELIN need to be close to one another.
Yes, all extensions with the same ELIN *will* be physically close together.  But this is not directly related to callback.  It is by definition of what the ERL is -- it is a small enough region in a building to allow emergency responders to find someone.  

> ... what the client does when its gets the ELIN from LLDP-MED I have no idea
ELIN was added to LLDP-MED for completeness and for compatibility with existing PSTN infrastructure.  Since existing E911 systems in N.A. use ELIN today, there was no easy way to support it with Civic and Geo types only.  (I am a little surprised ELIN type has not been defined in IETF as well ... but that's another story.)  Thinking was that the device could receive ELIN, pass it in SIP signalling towards PSTN GW, that would then insert the ELIN into PSTN trunk signalling.  I do not know if anyone uses it this way.  

> To this extent the ELIN is the way in which LLDP-MED currently supports
> location by reference.
Yes, ELIN is effectively a form of location-by-reference.  LLDP-MED can also be readily extended to support LbyR in the sense used in Geopriv / ECRIT as well.  Since location objects are directly supplied by the network infrastructure in LLDP-MED's case, it is not entirely clear to me why LbyR would really be needed / useful for LLDP-MED deployments.  

Cheers,
Peter Blatherwick




"Winterbottom, James" <James.Winterbottom@andrew.com>

12.11.07 04:46

       
       To:        "Karl Heinz Wolf" <khwolf1@gmail.com>
       cc:        ECRIT <ecrit@ietf.org>
       Subject:        RE: [Ecrit] ELIN




Hi Karl Heinz,

It is the only the extension that actually has the ELIN number that gets
called back. So all extensions with the same ELIN need to be close to
one another.

As to what the client does when its gets the ELIN from LLDP-MED I have
no idea... *8)

Cheers
James


> -----Original Message-----
> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]
> Sent: Monday, 12 November 2007 8:31 PM
> To: Winterbottom, James
> Cc: ECRIT
> Subject: Re: [Ecrit] ELIN
>
> Hi James!
>
> Thank you for your detailed description of the ELIN.
> One more question: how does the callback from the PSAP work, if there
> are multiple extensions with the same ELIN?
>
> Anyway, in case a company uses ELINs, and LLDP-MED location
> information tells the client this ELIN, what is the client supposed to
> do?
>
> cheers
> karl heinz
>
> On Nov 12, 2007 10:03 AM, Winterbottom, James
> <James.Winterbottom@andrew.com> wrote:
> > Hi Karl Heinz,
> >
> > An ELIN is a specific callback number that represents an area in an
MLTS
> > (Multi-Line Telephone System). As far as I know they are only used
in
> > the USA. The following description may not be 100% right, but it is
> > pretty close.
> >
> > Essentially if you have a company or campus that occupies a large
area,
> > you can break this up into smaller areas to make it easier for
emergency
> > service crews to find people. In some States this is mandated when
the
> > area becomes more than a certain size (8000 sqr feet is commonly
> > quoted). Generally what happens is that all telephone extensions in
a
> > certain area are associated with what is called an ERL (emergency
> > resource location), this is done in the PABX provisioning. Each ERL
is
> > allocated an ELIN that serves as the presented calling number to the
> > PSAP for any extension provisioned against the ERL. The PSAP is able
to
> > use the ELIN to get the floor location and area serviced by a
specific
> > ELIN. The ELIN also serves as the number that the PSAP will callback
in
> > the case of the call being dropped.
> >
> > To this extent the ELIN is the way in which LLDP-MED currently
supports
> > location by reference.
> >
> > Please let me know if this isn't clear and I will try an clarify
> > further.
> >
> > Cheers
> > James
> >
> >
> > > -----Original Message-----
> > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]
> > > Sent: Monday, 12 November 2007 7:23 PM
> > > To: ECRIT
> > > Subject: [Ecrit] ELIN
> > >
> > > LLDP-MED supports not just civic and coordinate based location
> > > information, but also an ELIN. How does this type of location
> > > information fit to the IETF Framework? Is this case considered in
any
> > > document?
> > > I couldn't find any information on how to proceed with this type
of
> > > location information.
> > >
> > > cheers
> > > Karl Heinz
> > >
> > > _______________________________________________
> > > 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]
> >
> >

------------------------------------------------------------------------------------------------
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 0068249E85257391_=-- --===============1059391114== 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 --===============1059391114==-- From ecrit-bounces@ietf.org Tue Nov 13 16:31:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is3MN-0001UT-II; Tue, 13 Nov 2007 16:31:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is3ML-0001Pp-Pv for ecrit@ietf.org; Tue, 13 Nov 2007 16:31:49 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Is3ML-0000aQ-4M for ecrit@ietf.org; Tue, 13 Nov 2007 16:31:49 -0500 Received: (qmail invoked by alias); 13 Nov 2007 21:31:47 -0000 Received: from unknown (EHLO [172.20.62.115]) [198.181.231.11] by mail.gmx.net (mp020) with SMTP; 13 Nov 2007 22:31:47 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/BhrEsvijBxnF+qSJpqaRbRZElHtqslg+j7r6APZ oNX9brkhghxLNg Message-ID: <473A17C0.6080807@gmx.net> Date: Tue, 13 Nov 2007 22:31:44 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= Subject: Re: [Ecrit] Proposed Agenda for IETF#70 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: Arnoud van Wijk , "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 Sure. Brian will collect the open issues and will present them. Gunnar Hellström wrote: > Hannes, > Can the issues around detailing of accessibility for people with > disabilities and invoking relay services in the calls be a subtopic under > "Open issues with framework and Pone BCP?" > > I know Arnoud van Wijk will be there and can be prepared to cover it. > > ( this links to a question I just sent to the list, titled "Mechanisms for > adding supporting services to emergency calls" ) > > Gunnar > ------------------------------------------------------------------- > Gunnar Hellström > Omnitor > gunnar.hellstrom@omnitor.se > Tel: +46708204288 > www.omnitor.se > > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Sunday, November 11, 2007 11:56 AM > To: ECRIT > Subject: [Ecrit] Proposed Agenda for IETF#70 > > Here is a first try... > > * Status Update and Agenda Bashing > Chairs > > * IESG Comments regarding LoST, LoST mapping architecture and LoST discovery > Chairs http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-03.txt > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-02.t > xt > > * Open issues with Framework and Phone BCP Brian Rosen > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt > > * Location Hiding Solution Space > Yet to be decided > http://tools.ietf.org/html/draft-schulzrinne-ecrit-location-hiding-req-00 > http://tools.ietf.org/html/draft-barnes-ecrit-auth > > * Unauthenticated Emergency Services > Yet to be decided > http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access-00 > > * Forest Guide Exchange Protocol > Henning Schulzrinne > http://tools.ietf.org/html/draft-schulzrinne-ecrit-lost-sync-00 > > * Specifying Holes in LoST Service Boundaries James Winterbottom > http://tools.ietf.org/html/draft-winterbottom-ecrit-specifying-holes-00.txt > > * RPH Header for Emergency Services > James Polk > http://tools.ietf.org/wg/ecrit/draft-polk-ecrit-local-emergency-rph-namespac > e-01.txt > > > _______________________________________________ > Ecrit mailing list > Ecrit@ietf.org > https://www1.ietf.org/mailman/listinfo/ecrit > > __________ NOD32 2651 (20071110) Information __________ > > Detta meddelande är genomsökt av NOD32 Antivirus. > http://www.nod32.com > > > > _______________________________________________ > 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 Nov 13 16:34:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is3On-00069n-Ql; Tue, 13 Nov 2007 16:34:21 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is3Om-00067z-Ja for ecrit@ietf.org; Tue, 13 Nov 2007 16:34:20 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1Is3Om-0000eh-2J for ecrit@ietf.org; Tue, 13 Nov 2007 16:34:20 -0500 Received: (qmail invoked by alias); 13 Nov 2007 21:34:18 -0000 Received: from unknown (EHLO [172.20.62.115]) [198.181.231.11] by mail.gmx.net (mp052) with SMTP; 13 Nov 2007 22:34:18 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/rKDlsgXfrkCRtLOZ5IiFP29TV73lDtdUEqMwzvJ 9BntdAua4zbK7L Message-ID: <473A1859.1090308@gmx.net> Date: Tue, 13 Nov 2007 22:34:17 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: ECRIT Subject: Re: [Ecrit] Proposed Agenda for IETF#70 References: <4736DFB3.3060203@gmx.net> In-Reply-To: <4736DFB3.3060203@gmx.net> 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: 02ec665d00de228c50c93ed6b5e4fc1a 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 Btw, Barbara proposed a couple of clarifications for to the mailing list and also in her presentation at the emergency services workshop. She had a chat with Brian at the workshop and I hope that some or all of her comments will be addressed with the next draft version. In case there are open issues I suggest to talk about them. Ciao Hannes Hannes Tschofenig wrote: > Here is a first try... > > * Status Update and Agenda Bashing > Chairs > > * IESG Comments regarding LoST, LoST mapping architecture and LoST > discovery > Chairs > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-03.txt > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery-02.txt > > > * Open issues with Framework and Phone BCP > Brian Rosen > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt > > * Location Hiding Solution Space > Yet to be decided > http://tools.ietf.org/html/draft-schulzrinne-ecrit-location-hiding-req-00 > http://tools.ietf.org/html/draft-barnes-ecrit-auth > > * Unauthenticated Emergency Services > Yet to be decided > http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated-access-00 > > > * Forest Guide Exchange Protocol > Henning Schulzrinne > http://tools.ietf.org/html/draft-schulzrinne-ecrit-lost-sync-00 > > * Specifying Holes in LoST Service Boundaries > James Winterbottom > http://tools.ietf.org/html/draft-winterbottom-ecrit-specifying-holes-00.txt > > > * RPH Header for Emergency Services > James Polk > http://tools.ietf.org/wg/ecrit/draft-polk-ecrit-local-emergency-rph-namespace-01.txt > > > > _______________________________________________ > 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 Nov 13 17:02:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is3po-0002pe-Vs; Tue, 13 Nov 2007 17:02:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Is3pn-0002mH-3G for ecrit@ietf.org; Tue, 13 Nov 2007 17:02:15 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Is3pk-0005Xq-Jd for ecrit@ietf.org; Tue, 13 Nov 2007 17:02:15 -0500 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1Is3pd-0001d9-TY; Tue, 13 Nov 2007 16:02:06 -0600 From: "Brian Rosen" To: "'Hannes Tschofenig'" , "'ECRIT'" References: <4736DFB3.3060203@gmx.net> <473A1859.1090308@gmx.net> Subject: RE: [Ecrit] Proposed Agenda for IETF#70 Date: Tue, 13 Nov 2007 17:02:08 -0500 Message-ID: <010601c82640$d78f6300$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 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <473A1859.1090308@gmx.net> Thread-Index: AcgmPPdcKKmDfhgVTn6aQdTIRv7CfQAA9jzQ X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: b280b4db656c3ca28dd62e5e0b03daa8 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 Yes, indeed they will. Brian > -----Original Message----- > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] > Sent: Tuesday, November 13, 2007 4:34 PM > To: ECRIT > Subject: Re: [Ecrit] Proposed Agenda for IETF#70 > > Btw, Barbara proposed a couple of clarifications for > to the mailing list and also in her > presentation at the emergency services workshop. She had a chat with > Brian at the workshop and I hope that some or all of her comments will > be addressed with the next draft version. > > In case there are open issues I suggest to talk about them. > > Ciao > Hannes > > > Hannes Tschofenig wrote: > > Here is a first try... > > > > * Status Update and Agenda Bashing > > Chairs > > > > * IESG Comments regarding LoST, LoST mapping architecture and LoST > > discovery > > Chairs > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-mapping-arch-03.txt > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-dhc-lost-discovery- > 02.txt > > > > > > * Open issues with Framework and Phone BCP > > Brian Rosen > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-02.txt > > http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-03.txt > > > > * Location Hiding Solution Space > > Yet to be decided > > http://tools.ietf.org/html/draft-schulzrinne-ecrit-location-hiding-req- > 00 > > http://tools.ietf.org/html/draft-barnes-ecrit-auth > > > > * Unauthenticated Emergency Services > > Yet to be decided > > http://tools.ietf.org/html/draft-schulzrinne-ecrit-unauthenticated- > access-00 > > > > > > * Forest Guide Exchange Protocol > > Henning Schulzrinne > > http://tools.ietf.org/html/draft-schulzrinne-ecrit-lost-sync-00 > > > > * Specifying Holes in LoST Service Boundaries > > James Winterbottom > > http://tools.ietf.org/html/draft-winterbottom-ecrit-specifying-holes- > 00.txt > > > > > > * RPH Header for Emergency Services > > James Polk > > http://tools.ietf.org/wg/ecrit/draft-polk-ecrit-local-emergency-rph- > namespace-01.txt > > > > > > > > _______________________________________________ > > 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 Nov 15 05:25:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isbug-0005Ih-Jx; Thu, 15 Nov 2007 05:25:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isbuf-0005Gh-CL for ecrit@ietf.org; Thu, 15 Nov 2007 05:25:33 -0500 Received: from mu-out-0910.google.com ([209.85.134.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Isbua-0005YO-0S for ecrit@ietf.org; Thu, 15 Nov 2007 05:25:33 -0500 Received: by mu-out-0910.google.com with SMTP id i10so506020mue for ; Thu, 15 Nov 2007 02:25:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=na8WHVbVeMtJjHz3L4lrbx3iXprzoaCfHJzbEptTKpE=; b=ceVLnDwzlqHMUajXrh9OTm+Wcu64lzaS80ucUYQm9tIogc9TiLD6QHBYugj1Rthboa1+hp1PuaFLsyZFdD9LSCW58LXhi7uyzaoClZCNu5dnGhzWQ/Ri142O5myA/ZSULicJNWNnRQmLEK55ZQcC7C2YoBAsphaOqNnN0zxXj6M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ha54dRELMv4PNYCb/mqCYZYrmeD5WYIJw5+bJtPtACeLtugFPaYFIdvimcgAm8nEvRDlPD1Iz/Wmux27fq8pCi+U0rAu7IXyPgazndNPpzVopTBFzpcdsay7XZ2Y4dYLgqrcRD72IRkGStiYAxPzBYz3V0/Iw5griaZ/o0uK2J4= Received: by 10.82.189.6 with SMTP id m6mr1050284buf.1195122326951; Thu, 15 Nov 2007 02:25:26 -0800 (PST) Received: by 10.82.182.18 with HTTP; Thu, 15 Nov 2007 02:25:26 -0800 (PST) Message-ID: Date: Thu, 15 Nov 2007 11:25:26 +0100 From: "Karl Heinz Wolf" To: peter_blatherwick@mitel.com Subject: Re: [Ecrit] ELIN In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Spam-Score: 1.7 (+) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c 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 Peter, thanks for your additional information on ELINs. > > ... what the client does when its gets the ELIN from LLDP-MED I have no > idea > ELIN was added to LLDP-MED for completeness and for compatibility with > existing PSTN infrastructure. Since existing E911 systems in N.A. use ELIN > today, there was no easy way to support it with Civic and Geo types only. > (I am a little surprised ELIN type has not been defined in IETF as well ... > but that's another story.) Thinking was that the device could receive ELIN, > pass it in SIP signalling towards PSTN GW, that would then insert the ELIN > into PSTN trunk signalling. I do not know if anyone uses it this way. > How can this gateway be determined? Would it be imaginable to have a LoST location profile for ELINs, get the responsible PSAP via LoST for the given ELIN and convey the ELIN in the SIP message directly to the PSAP (without a gateway) as location by reference? cheers, karl heinz > > > To this extent the ELIN is the way in which LLDP-MED currently supports > > location by reference. > Yes, ELIN is effectively a form of location-by-reference. LLDP-MED can also > be readily extended to support LbyR in the sense used in Geopriv / ECRIT as > well. Since location objects are directly supplied by the network > infrastructure in LLDP-MED's case, it is not entirely clear to me why LbyR > would really be needed / useful for LLDP-MED deployments. > > Cheers, > Peter Blatherwick > > > > > > > > "Winterbottom, James" > > 12.11.07 04:46 > To: "Karl Heinz Wolf" > cc: ECRIT > Subject: RE: [Ecrit] ELIN > > > > > Hi Karl Heinz, > > It is the only the extension that actually has the ELIN number that gets > called back. So all extensions with the same ELIN need to be close to > one another. > > As to what the client does when its gets the ELIN from LLDP-MED I have > no idea... *8) > > Cheers > James > > > > -----Original Message----- > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > Sent: Monday, 12 November 2007 8:31 PM > > To: Winterbottom, James > > Cc: ECRIT > > Subject: Re: [Ecrit] ELIN > > > > Hi James! > > > > Thank you for your detailed description of the ELIN. > > One more question: how does the callback from the PSAP work, if there > > are multiple extensions with the same ELIN? > > > > Anyway, in case a company uses ELINs, and LLDP-MED location > > information tells the client this ELIN, what is the client supposed to > > do? > > > > cheers > > karl heinz > > > > On Nov 12, 2007 10:03 AM, Winterbottom, James > > wrote: > > > Hi Karl Heinz, > > > > > > An ELIN is a specific callback number that represents an area in an > MLTS > > > (Multi-Line Telephone System). As far as I know they are only used > in > > > the USA. The following description may not be 100% right, but it is > > > pretty close. > > > > > > Essentially if you have a company or campus that occupies a large > area, > > > you can break this up into smaller areas to make it easier for > emergency > > > service crews to find people. In some States this is mandated when > the > > > area becomes more than a certain size (8000 sqr feet is commonly > > > quoted). Generally what happens is that all telephone extensions in > a > > > certain area are associated with what is called an ERL (emergency > > > resource location), this is done in the PABX provisioning. Each ERL > is > > > allocated an ELIN that serves as the presented calling number to the > > > PSAP for any extension provisioned against the ERL. The PSAP is able > to > > > use the ELIN to get the floor location and area serviced by a > specific > > > ELIN. The ELIN also serves as the number that the PSAP will callback > in > > > the case of the call being dropped. > > > > > > To this extent the ELIN is the way in which LLDP-MED currently > supports > > > location by reference. > > > > > > Please let me know if this isn't clear and I will try an clarify > > > further. > > > > > > Cheers > > > James > > > > > > > > > > -----Original Message----- > > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > > Sent: Monday, 12 November 2007 7:23 PM > > > > To: ECRIT > > > > Subject: [Ecrit] ELIN > > > > > > > > LLDP-MED supports not just civic and coordinate based location > > > > information, but also an ELIN. How does this type of location > > > > information fit to the IETF Framework? Is this case considered in > any > > > > document? > > > > I couldn't find any information on how to proceed with this type > of > > > > location information. > > > > > > > > cheers > > > > Karl Heinz > > > > > > > > _______________________________________________ > > > > 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] > > > > > > > > > ------------------------------------------------------------------------------------------------ > 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 Thu Nov 15 08:36:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iseth-0004df-Pd; Thu, 15 Nov 2007 08:36:45 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Isetf-0004aV-Q2 for ecrit@ietf.org; Thu, 15 Nov 2007 08:36:43 -0500 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 1Isetf-0003R2-Dk for ecrit@ietf.org; Thu, 15 Nov 2007 08:36:43 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 15 Nov 2007 05:36:43 -0800 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/8.12.11) with ESMTP id lAFDagXq027215; Thu, 15 Nov 2007 05:36:42 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAFDadCj029829; Thu, 15 Nov 2007 13:36:42 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 08:36:41 -0500 Received: from mlinsnerwxp02 ([10.82.170.67]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Nov 2007 08:36:41 -0500 From: "Marc Linsner" To: "'Karl Heinz Wolf'" Subject: RE: [Ecrit] ELIN Date: Thu, 15 Nov 2007 08:36:40 -0500 Message-ID: <006a01c8278c$8e382cd0$2f0d0d0a@cisco.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.3198 Thread-Index: AcgnceGckr3cQ3GZQ5uPWH1rRy27OgAGEfaw In-Reply-To: X-OriginalArrivalTime: 15 Nov 2007 13:36:41.0806 (UTC) FILETIME=[8E66B6E0:01C8278C] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-5.000.1023-15546.002 X-TM-AS-Result: No--10.470100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1314; t=1195133802; x=1195997802; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20=22Marc=20Linsner=22=20 |Subject:=20RE=3A=20[Ecrit]=20ELIN |Sender:=20; bh=Uh0yKg6uX76phGYr0esuIcqzOuDrVBA9bpwgYo7xMzU=; b=i7gOwc1gB3xIT3AWFMvv0fPd3j5ts7CAlIx6iHpoL0KG5IpN4ckJYuSFzyWk2gM4EfRn02PL dEzfTPX2hpHTdumg1rkbfT8SKSvrs0hZtkF+xYKtSXP5JasuHVh4AxE4; Authentication-Results: sj-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Karl, > > > > How can this gateway be determined? > Would it be imaginable to have a LoST location profile for > ELINs, get the responsible PSAP via LoST for the given ELIN > and convey the ELIN in the SIP message directly to the PSAP > (without a gateway) as location by reference? > In the US PSTN today, E911 location is supported via an out-of-band database that uses calling party number (ANI) as the query key. Enterprises will assign an ELIN to a geographic area of their campus, submit the proper database entry, then swap the calling party to match the ELIN on outbound 911 calls. This allows the PSAP to use the ELIN and query the database for the location information. PSAP callbacks can be redirected to the originator via the enterprise call control (requires the ELIN to be a dialable number). This mechanism facilitates the moves-adds-changes of enterprise phones around the campus without the requirement for constant database updates, the ELINs are static. The enterprise call control can locate the phone using normal L2/L3 network management tools. The gateway is normally operated by the enterprise and gateway selection is based on the ELIN/campus location. There are 1000s of these systems operating in the US today. I hope this helps, -Marc- _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 15 10:16:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsgRn-0005GX-JV; Thu, 15 Nov 2007 10:16:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsgRj-00058B-0z for ecrit@ietf.org; Thu, 15 Nov 2007 10:15:59 -0500 Received: from smtp.mitel.com ([216.191.234.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IsgRe-0008Gk-J0 for ecrit@ietf.org; Thu, 15 Nov 2007 10:15:59 -0500 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 5A91C2C09E; Thu, 15 Nov 2007 10:15:54 -0500 (EST) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com 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 tcrAUTFg5NOU; Thu, 15 Nov 2007 10:15:52 -0500 (EST) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 2FF972C08E; Thu, 15 Nov 2007 10:15:52 -0500 (EST) In-Reply-To: To: "Karl Heinz Wolf" Subject: Re: [Ecrit] ELIN MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Thu, 15 Nov 2007 10:15:51 -0500 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 11/15/2007 10:15:50 AM, Serialize complete at 11/15/2007 10:15:50 AM X-Spam-Score: 1.7 (+) X-Scan-Signature: d4a1871e876bd836d4c351e861e8720d 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="===============0943778178==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0943778178== Content-Type: multipart/alternative; boundary="=_alternative 0053D91E85257394_=" This is a multipart message in MIME format. --=_alternative 0053D91E85257394_= Content-Type: text/plain; charset="US-ASCII" Hi again Karl, See Marc's nice description... Specifically on the IETF work, I think ELIN probably does not apply very well, since ECRIT scope is explicitly not covering interfacing to traditional PSTN-base Emerg Call Service, and is explicitly international in scope. ELIN is (at this time) specific to N.A. E-911 for enterprise. Might be worth considering though, just not here ... hmmm ..... -- Peter "Karl Heinz Wolf" 15.11.07 05:25 To: peter_blatherwick@mitel.com cc: "Winterbottom, James" , ECRIT Subject: Re: [Ecrit] ELIN Hi Peter, thanks for your additional information on ELINs. > > ... what the client does when its gets the ELIN from LLDP-MED I have no > idea > ELIN was added to LLDP-MED for completeness and for compatibility with > existing PSTN infrastructure. Since existing E911 systems in N.A. use ELIN > today, there was no easy way to support it with Civic and Geo types only. > (I am a little surprised ELIN type has not been defined in IETF as well ... > but that's another story.) Thinking was that the device could receive ELIN, > pass it in SIP signalling towards PSTN GW, that would then insert the ELIN > into PSTN trunk signalling. I do not know if anyone uses it this way. > How can this gateway be determined? Would it be imaginable to have a LoST location profile for ELINs, get the responsible PSAP via LoST for the given ELIN and convey the ELIN in the SIP message directly to the PSAP (without a gateway) as location by reference? cheers, karl heinz > > > To this extent the ELIN is the way in which LLDP-MED currently supports > > location by reference. > Yes, ELIN is effectively a form of location-by-reference. LLDP-MED can also > be readily extended to support LbyR in the sense used in Geopriv / ECRIT as > well. Since location objects are directly supplied by the network > infrastructure in LLDP-MED's case, it is not entirely clear to me why LbyR > would really be needed / useful for LLDP-MED deployments. > > Cheers, > Peter Blatherwick > > > > > > > > "Winterbottom, James" > > 12.11.07 04:46 > To: "Karl Heinz Wolf" > cc: ECRIT > Subject: RE: [Ecrit] ELIN > > > > > Hi Karl Heinz, > > It is the only the extension that actually has the ELIN number that gets > called back. So all extensions with the same ELIN need to be close to > one another. > > As to what the client does when its gets the ELIN from LLDP-MED I have > no idea... *8) > > Cheers > James > > > > -----Original Message----- > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > Sent: Monday, 12 November 2007 8:31 PM > > To: Winterbottom, James > > Cc: ECRIT > > Subject: Re: [Ecrit] ELIN > > > > Hi James! > > > > Thank you for your detailed description of the ELIN. > > One more question: how does the callback from the PSAP work, if there > > are multiple extensions with the same ELIN? > > > > Anyway, in case a company uses ELINs, and LLDP-MED location > > information tells the client this ELIN, what is the client supposed to > > do? > > > > cheers > > karl heinz > > > > On Nov 12, 2007 10:03 AM, Winterbottom, James > > wrote: > > > Hi Karl Heinz, > > > > > > An ELIN is a specific callback number that represents an area in an > MLTS > > > (Multi-Line Telephone System). As far as I know they are only used > in > > > the USA. The following description may not be 100% right, but it is > > > pretty close. > > > > > > Essentially if you have a company or campus that occupies a large > area, > > > you can break this up into smaller areas to make it easier for > emergency > > > service crews to find people. In some States this is mandated when > the > > > area becomes more than a certain size (8000 sqr feet is commonly > > > quoted). Generally what happens is that all telephone extensions in > a > > > certain area are associated with what is called an ERL (emergency > > > resource location), this is done in the PABX provisioning. Each ERL > is > > > allocated an ELIN that serves as the presented calling number to the > > > PSAP for any extension provisioned against the ERL. The PSAP is able > to > > > use the ELIN to get the floor location and area serviced by a > specific > > > ELIN. The ELIN also serves as the number that the PSAP will callback > in > > > the case of the call being dropped. > > > > > > To this extent the ELIN is the way in which LLDP-MED currently > supports > > > location by reference. > > > > > > Please let me know if this isn't clear and I will try an clarify > > > further. > > > > > > Cheers > > > James > > > > > > > > > > -----Original Message----- > > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > > Sent: Monday, 12 November 2007 7:23 PM > > > > To: ECRIT > > > > Subject: [Ecrit] ELIN > > > > > > > > LLDP-MED supports not just civic and coordinate based location > > > > information, but also an ELIN. How does this type of location > > > > information fit to the IETF Framework? Is this case considered in > any > > > > document? > > > > I couldn't find any information on how to proceed with this type > of > > > > location information. > > > > > > > > cheers > > > > Karl Heinz > > > > > > > > _______________________________________________ > > > > 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] > > > > > > > > > ------------------------------------------------------------------------------------------------ > 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 0053D91E85257394_= Content-Type: text/html; charset="US-ASCII"
Hi again Karl,
See Marc's nice description...  

Specifically on the IETF work, I think ELIN probably does not apply very well, since ECRIT scope is explicitly not covering interfacing to traditional PSTN-base Emerg Call Service, and is explicitly international in scope.   ELIN is (at this time) specific to N.A. E-911 for enterprise.  Might be worth considering though, just not here ... hmmm .....      

-- Peter




"Karl Heinz Wolf" <khwolf1@gmail.com>

15.11.07 05:25

       
        To:        peter_blatherwick@mitel.com
        cc:        "Winterbottom, James" <James.Winterbottom@andrew.com>, ECRIT <ecrit@ietf.org>
        Subject:        Re: [Ecrit] ELIN



Hi Peter,
thanks for your additional information on ELINs.

> > ... what the client does when its gets the ELIN from LLDP-MED I have no
> idea
> ELIN was added to LLDP-MED for completeness and for compatibility with
> existing PSTN infrastructure.  Since existing E911 systems in N.A. use ELIN
> today, there was no easy way to support it with Civic and Geo types only.
> (I am a little surprised ELIN type has not been defined in IETF as well ...
> but that's another story.)  Thinking was that the device could receive ELIN,
> pass it in SIP signalling towards PSTN GW, that would then insert the ELIN
> into PSTN trunk signalling.  I do not know if anyone uses it this way.
>

How can this gateway be determined?
Would it be imaginable to have a LoST location profile for ELINs, get
the responsible PSAP via LoST for the given ELIN and convey the ELIN
in the SIP message directly to the PSAP (without a gateway) as
location by reference?

cheers,
karl heinz

>
> > To this extent the ELIN is the way in which LLDP-MED currently supports
>  > location by reference.
> Yes, ELIN is effectively a form of location-by-reference.  LLDP-MED can also
> be readily extended to support LbyR in the sense used in Geopriv / ECRIT as
> well.  Since location objects are directly supplied by the network
> infrastructure in LLDP-MED's case, it is not entirely clear to me why LbyR
> would really be needed / useful for LLDP-MED deployments.
>
> Cheers,
> Peter Blatherwick
>
>
>
>
>
>
>
> "Winterbottom, James" <James.Winterbottom@andrew.com>
>
> 12.11.07 04:46
>         To:        "Karl Heinz Wolf" <khwolf1@gmail.com>
>         cc:        ECRIT <ecrit@ietf.org>
>         Subject:        RE: [Ecrit] ELIN
>
>
>
>
> Hi Karl Heinz,
>
>  It is the only the extension that actually has the ELIN number that gets
>  called back. So all extensions with the same ELIN need to be close to
>  one another.
>
>  As to what the client does when its gets the ELIN from LLDP-MED I have
>  no idea... *8)
>
>  Cheers
>  James
>
>
>  > -----Original Message-----
>  > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]
>  > Sent: Monday, 12 November 2007 8:31 PM
>  > To: Winterbottom, James
>  > Cc: ECRIT
>  > Subject: Re: [Ecrit] ELIN
>  >
>  > Hi James!
>  >
>  > Thank you for your detailed description of the ELIN.
>  > One more question: how does the callback from the PSAP work, if there
>  > are multiple extensions with the same ELIN?
>  >
>  > Anyway, in case a company uses ELINs, and LLDP-MED location
>  > information tells the client this ELIN, what is the client supposed to
>  > do?
>  >
>  > cheers
>  > karl heinz
>  >
>  > On Nov 12, 2007 10:03 AM, Winterbottom, James
>  > <James.Winterbottom@andrew.com> wrote:
>  > > Hi Karl Heinz,
>  > >
>  > > An ELIN is a specific callback number that represents an area in an
>  MLTS
>  > > (Multi-Line Telephone System). As far as I know they are only used
>  in
>  > > the USA. The following description may not be 100% right, but it is
>  > > pretty close.
>  > >
>  > > Essentially if you have a company or campus that occupies a large
>  area,
>  > > you can break this up into smaller areas to make it easier for
>  emergency
>  > > service crews to find people. In some States this is mandated when
>  the
>  > > area becomes more than a certain size (8000 sqr feet is commonly
>  > > quoted). Generally what happens is that all telephone extensions in
>  a
>  > > certain area are associated with what is called an ERL (emergency
>  > > resource location), this is done in the PABX provisioning. Each ERL
>  is
>  > > allocated an ELIN that serves as the presented calling number to the
>  > > PSAP for any extension provisioned against the ERL. The PSAP is able
>  to
>  > > use the ELIN to get the floor location and area serviced by a
>  specific
>  > > ELIN. The ELIN also serves as the number that the PSAP will callback
>  in
>  > > the case of the call being dropped.
>  > >
>  > > To this extent the ELIN is the way in which LLDP-MED currently
>  supports
>  > > location by reference.
>  > >
>  > > Please let me know if this isn't clear and I will try an clarify
>  > > further.
>  > >
>  > > Cheers
>  > > James
>  > >
>  > >
>  > > > -----Original Message-----
>  > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]
>  > > > Sent: Monday, 12 November 2007 7:23 PM
>  > > > To: ECRIT
>  > > > Subject: [Ecrit] ELIN
>  > > >
>  > > > LLDP-MED supports not just civic and coordinate based location
>  > > > information, but also an ELIN. How does this type of location
>  > > > information fit to the IETF Framework? Is this case considered in
>  any
>  > > > document?
>  > > > I couldn't find any information on how to proceed with this type
>  of
>  > > > location information.
>  > > >
>  > > > cheers
>  > > > Karl Heinz
>  > > >
>  > > > _______________________________________________
>  > > > 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]
>  > >
>  > >
>
>
> ------------------------------------------------------------------------------------------------
>  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 0053D91E85257394_=-- --===============0943778178== 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 --===============0943778178==-- From ecrit-bounces@ietf.org Thu Nov 15 11:42:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshnT-0007BF-1l; Thu, 15 Nov 2007 11:42:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IshnR-0007B6-NF for ecrit@ietf.org; Thu, 15 Nov 2007 11:42:29 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IshnO-0004WK-Q6 for ecrit@ietf.org; Thu, 15 Nov 2007 11:42:29 -0500 Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1IsijE-0001hx-8S; Thu, 15 Nov 2007 11:42:12 -0600 From: "Brian Rosen" To: "'Karl Heinz Wolf'" , References: Subject: RE: [Ecrit] ELIN Date: Thu, 15 Nov 2007 11:42:08 -0500 Message-ID: <000d01c827a6$7c049a70$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: Acgncesme0LLe7hLQ52cEZ0u8FGHwwAHlrTQ In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: 1.7 (+) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 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 ELINs are peculiar to the U.S. Multiple Line Telephone Systems, and really are only applicable in the current TDM based emergency calling system. I don't think it makes any sense to mix current generation systems, which would include ELINs with next generation, IP based systems. PBX systems today cater to specific countries emergency call systems, which in the U.S. would include support for ELINs. I don't think we get enough mileage out of standardizing something that is specific to the U.S., and is going away in favor of a more general LoST based routing system. Brian > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Thursday, November 15, 2007 5:25 AM > To: peter_blatherwick@mitel.com > Cc: ECRIT > Subject: Re: [Ecrit] ELIN > > Hi Peter, > thanks for your additional information on ELINs. > > > > ... what the client does when its gets the ELIN from LLDP-MED I have > no > > idea > > ELIN was added to LLDP-MED for completeness and for compatibility with > > existing PSTN infrastructure. Since existing E911 systems in N.A. use > ELIN > > today, there was no easy way to support it with Civic and Geo types > only. > > (I am a little surprised ELIN type has not been defined in IETF as well > ... > > but that's another story.) Thinking was that the device could receive > ELIN, > > pass it in SIP signalling towards PSTN GW, that would then insert the > ELIN > > into PSTN trunk signalling. I do not know if anyone uses it this way. > > > > How can this gateway be determined? > Would it be imaginable to have a LoST location profile for ELINs, get > the responsible PSAP via LoST for the given ELIN and convey the ELIN > in the SIP message directly to the PSAP (without a gateway) as > location by reference? > > cheers, > karl heinz > > > > > > To this extent the ELIN is the way in which LLDP-MED currently > supports > > > location by reference. > > Yes, ELIN is effectively a form of location-by-reference. LLDP-MED can > also > > be readily extended to support LbyR in the sense used in Geopriv / ECRIT > as > > well. Since location objects are directly supplied by the network > > infrastructure in LLDP-MED's case, it is not entirely clear to me why > LbyR > > would really be needed / useful for LLDP-MED deployments. > > > > Cheers, > > Peter Blatherwick > > > > > > > > > > > > > > > > "Winterbottom, James" > > > > 12.11.07 04:46 > > To: "Karl Heinz Wolf" > > cc: ECRIT > > Subject: RE: [Ecrit] ELIN > > > > > > > > > > Hi Karl Heinz, > > > > It is the only the extension that actually has the ELIN number that > gets > > called back. So all extensions with the same ELIN need to be close to > > one another. > > > > As to what the client does when its gets the ELIN from LLDP-MED I have > > no idea... *8) > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > Sent: Monday, 12 November 2007 8:31 PM > > > To: Winterbottom, James > > > Cc: ECRIT > > > Subject: Re: [Ecrit] ELIN > > > > > > Hi James! > > > > > > Thank you for your detailed description of the ELIN. > > > One more question: how does the callback from the PSAP work, if there > > > are multiple extensions with the same ELIN? > > > > > > Anyway, in case a company uses ELINs, and LLDP-MED location > > > information tells the client this ELIN, what is the client supposed > to > > > do? > > > > > > cheers > > > karl heinz > > > > > > On Nov 12, 2007 10:03 AM, Winterbottom, James > > > wrote: > > > > Hi Karl Heinz, > > > > > > > > An ELIN is a specific callback number that represents an area in an > > MLTS > > > > (Multi-Line Telephone System). As far as I know they are only used > > in > > > > the USA. The following description may not be 100% right, but it is > > > > pretty close. > > > > > > > > Essentially if you have a company or campus that occupies a large > > area, > > > > you can break this up into smaller areas to make it easier for > > emergency > > > > service crews to find people. In some States this is mandated when > > the > > > > area becomes more than a certain size (8000 sqr feet is commonly > > > > quoted). Generally what happens is that all telephone extensions in > > a > > > > certain area are associated with what is called an ERL (emergency > > > > resource location), this is done in the PABX provisioning. Each ERL > > is > > > > allocated an ELIN that serves as the presented calling number to > the > > > > PSAP for any extension provisioned against the ERL. The PSAP is > able > > to > > > > use the ELIN to get the floor location and area serviced by a > > specific > > > > ELIN. The ELIN also serves as the number that the PSAP will > callback > > in > > > > the case of the call being dropped. > > > > > > > > To this extent the ELIN is the way in which LLDP-MED currently > > supports > > > > location by reference. > > > > > > > > Please let me know if this isn't clear and I will try an clarify > > > > further. > > > > > > > > Cheers > > > > James > > > > > > > > > > > > > -----Original Message----- > > > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > > > Sent: Monday, 12 November 2007 7:23 PM > > > > > To: ECRIT > > > > > Subject: [Ecrit] ELIN > > > > > > > > > > LLDP-MED supports not just civic and coordinate based location > > > > > information, but also an ELIN. How does this type of location > > > > > information fit to the IETF Framework? Is this case considered in > > any > > > > > document? > > > > > I couldn't find any information on how to proceed with this type > > of > > > > > location information. > > > > > > > > > > cheers > > > > > Karl Heinz > > > > > > > > > > _______________________________________________ > > > > > 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] > > > > > > > > > > > > > > ------------------------------------------------------------------------ > ------------------------ > > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 15 18:52:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsoVw-0003Lx-BR; Thu, 15 Nov 2007 18:52:52 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsoVu-0003Jo-IS for ecrit@ietf.org; Thu, 15 Nov 2007 18:52:50 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsoVt-0007ZO-Kl for ecrit@ietf.org; Thu, 15 Nov 2007 18:52:50 -0500 X-SEF-Processed: 5_0_0_910__2007_11_15_18_03_20 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 15 Nov 2007 18:03:20 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Nov 2007 17:52:44 -0600 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 Subject: RE: [Ecrit] ELIN Date: Thu, 15 Nov 2007 17:52:42 -0600 Message-ID: In-Reply-To: <000d01c827a6$7c049a70$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ELIN Thread-Index: Acgncesme0LLe7hLQ52cEZ0u8FGHwwAHlrTQABSCBeA= References: <000d01c827a6$7c049a70$640fa8c0@cis.neustar.com> From: "Dawson, Martin" To: "Brian Rosen" , "Karl Heinz Wolf" , X-OriginalArrivalTime: 15 Nov 2007 23:52:44.0367 (UTC) FILETIME=[9DCDEDF0:01C827E2] X-Spam-Score: 3.5 (+++) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c 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 agree with this. To be useful there would need to be a scenario where=0D=0A= the ELIN was available but location (or the location represented by the=0D=0A= ERL) was not. How realistic is this=3F=0D=0A=0D=0AThis would also turn the = LoST server into an ALI... which, as Brian=0D=0Asays, is actually the model= which is going away - on the assumption that=0D=0Aphone numbers simply don= 't reliably represent location any more.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D= =0A-----Original Message-----=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.= net]=20=0D=0ASent: Friday, 16 November 2007 3:42 AM=0D=0ATo: 'Karl Heinz Wo= lf'; peter_blatherwick@mitel.com=0D=0ACc: 'ECRIT'=0D=0ASubject: RE: [Ecrit]= ELIN=0D=0A=0D=0AELINs are peculiar to the U.S. Multiple Line Telephone Sys= tems, and=0D=0Areally=0D=0Aare only applicable in the current TDM based eme= rgency calling system.=0D=0AI=0D=0Adon't think it makes any sense to mix cu= rrent generation systems, which=0D=0Awould include ELINs with next generati= on, IP based systems.=0D=0A=0D=0APBX systems today cater to specific countr= ies emergency call systems,=0D=0Awhich=0D=0Ain the U.S. would include suppo= rt for ELINs. I don't think we get=0D=0Aenough=0D=0Amileage out of standar= dizing something that is specific to the U.S., and=0D=0Ais=0D=0Agoing away = in favor of a more general LoST based routing system.=0D=0A=0D=0ABrian=0D=0A=0D= =0A> -----Original Message-----=0D=0A> From: Karl Heinz Wolf [mailto:khwolf= 1@gmail.com]=0D=0A> Sent: Thursday, November 15, 2007 5:25 AM=0D=0A> To: pe= ter_blatherwick@mitel.com=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] ELIN=0D= =0A>=20=0D=0A> Hi Peter,=0D=0A> thanks for your additional information on E= LINs.=0D=0A>=20=0D=0A> > > ... what the client does when its gets the ELIN = from LLDP-MED I=0D=0Ahave=0D=0A> no=0D=0A> > idea=0D=0A> > ELIN was added t= o LLDP-MED for completeness and for compatibility=0D=0Awith=0D=0A> > existi= ng PSTN infrastructure. Since existing E911 systems in N.A.=0D=0Ause=0D=0A= > ELIN=0D=0A> > today, there was no easy way to support it with Civic and G= eo types=0D=0A> only.=0D=0A> > (I am a little surprised ELIN type has not b= een defined in IETF as=0D=0Awell=0D=0A> ...=0D=0A> > but that's another sto= ry.) Thinking was that the device could=0D=0Areceive=0D=0A> ELIN,=0D=0A> >= pass it in SIP signalling towards PSTN GW, that would then insert=0D=0Athe=0D= =0A> ELIN=0D=0A> > into PSTN trunk signalling. I do not know if anyone use= s it this=0D=0Away.=0D=0A> >=0D=0A>=20=0D=0A> How can this gateway be deter= mined=3F=0D=0A> Would it be imaginable to have a LoST location profile for = ELINs, get=0D=0A> the responsible PSAP via LoST for the given ELIN and conv= ey the ELIN=0D=0A> in the SIP message directly to the PSAP (without a gatew= ay) as=0D=0A> location by reference=3F=0D=0A>=20=0D=0A> cheers,=0D=0A> karl= heinz=0D=0A>=20=0D=0A> >=0D=0A> > > To this extent the ELIN is the way in = which LLDP-MED currently=0D=0A> supports=0D=0A> > > location by reference.=0D= =0A> > Yes, ELIN is effectively a form of location-by-reference. LLDP-MED=0D= =0Acan=0D=0A> also=0D=0A> > be readily extended to support LbyR in the sens= e used in Geopriv /=0D=0AECRIT=0D=0A> as=0D=0A> > well. Since location obj= ects are directly supplied by the network=0D=0A> > infrastructure in LLDP-M= ED's case, it is not entirely clear to me=0D=0Awhy=0D=0A> LbyR=0D=0A> > wou= ld really be needed / useful for LLDP-MED deployments.=0D=0A> >=0D=0A> > Ch= eers,=0D=0A> > Peter Blatherwick=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A>= >=0D=0A> >=0D=0A> >=0D=0A> > "Winterbottom, James" =0D=0A> >=0D=0A> > 12.11.07 04:46=0D=0A> > To: "Karl= Heinz Wolf" =0D=0A> > cc: ECRIT =0D=0A> > Subject: RE: [Ecrit] ELIN=0D=0A> >=0D=0A> = >=0D=0A> >=0D=0A> >=0D=0A> > Hi Karl Heinz,=0D=0A> >=0D=0A> > It is the on= ly the extension that actually has the ELIN number that=0D=0A> gets=0D=0A> = > called back. So all extensions with the same ELIN need to be close=0D=0A= to=0D=0A> > one another.=0D=0A> >=0D=0A> > As to what the client does whe= n its gets the ELIN from LLDP-MED I=0D=0Ahave=0D=0A> > no idea... *8)=0D=0A= > >=0D=0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A> >=0D=0A> > > -----Ori= ginal Message-----=0D=0A> > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.= com]=0D=0A> > > Sent: Monday, 12 November 2007 8:31 PM=0D=0A> > > To: Win= terbottom, James=0D=0A> > > Cc: ECRIT=0D=0A> > > Subject: Re: [Ecrit] ELI= N=0D=0A> > >=0D=0A> > > Hi James!=0D=0A> > >=0D=0A> > > Thank you for y= our detailed description of the ELIN.=0D=0A> > > One more question: how do= es the callback from the PSAP work, if=0D=0Athere=0D=0A> > > are multiple = extensions with the same ELIN=3F=0D=0A> > >=0D=0A> > > Anyway, in case a = company uses ELINs, and LLDP-MED location=0D=0A> > > information tells the= client this ELIN, what is the client=0D=0Asupposed=0D=0A> to=0D=0A> > > d= o=3F=0D=0A> > >=0D=0A> > > cheers=0D=0A> > > karl heinz=0D=0A> > >=0D=0A= > > > On Nov 12, 2007 10:03 AM, Winterbottom, James=0D=0A> > > wrote:=0D=0A> > > > Hi Karl Heinz,=0D=0A> > > >=0D=0A= > > > > An ELIN is a specific callback number that represents an area=0D=0A= in an=0D=0A> > MLTS=0D=0A> > > > (Multi-Line Telephone System). As far as= I know they are only=0D=0Aused=0D=0A> > in=0D=0A> > > > the USA. The fol= lowing description may not be 100% right, but=0D=0Ait is=0D=0A> > > > pret= ty close.=0D=0A> > > >=0D=0A> > > > Essentially if you have a company or = campus that occupies a=0D=0Alarge=0D=0A> > area,=0D=0A> > > > you can bre= ak this up into smaller areas to make it easier for=0D=0A> > emergency=0D=0A= > > > > service crews to find people. In some States this is mandated=0D=0A= when=0D=0A> > the=0D=0A> > > > area becomes more than a certain size (800= 0 sqr feet is=0D=0Acommonly=0D=0A> > > > quoted). Generally what happens i= s that all telephone=0D=0Aextensions in=0D=0A> > a=0D=0A> > > > certain a= rea are associated with what is called an ERL=0D=0A(emergency=0D=0A> > > >= resource location), this is done in the PABX provisioning. Each=0D=0AERL=0D= =0A> > is=0D=0A> > > > allocated an ELIN that serves as the presented cal= ling number=0D=0Ato=0D=0A> the=0D=0A> > > > PSAP for any extension provisi= oned against the ERL. The PSAP is=0D=0A> able=0D=0A> > to=0D=0A> > > > us= e the ELIN to get the floor location and area serviced by a=0D=0A> > speci= fic=0D=0A> > > > ELIN. The ELIN also serves as the number that the PSAP wi= ll=0D=0A> callback=0D=0A> > in=0D=0A> > > > the case of the call being dr= opped.=0D=0A> > > >=0D=0A> > > > To this extent the ELIN is the way in wh= ich LLDP-MED currently=0D=0A> > supports=0D=0A> > > > location by referen= ce.=0D=0A> > > >=0D=0A> > > > Please let me know if this isn't clear and = I will try an=0D=0Aclarify=0D=0A> > > > further.=0D=0A> > > >=0D=0A> > >= > Cheers=0D=0A> > > > James=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > > -= ----Original Message-----=0D=0A> > > > > From: Karl Heinz Wolf [mailto:khw= olf1@gmail.com]=0D=0A> > > > > Sent: Monday, 12 November 2007 7:23 PM=0D=0A= > > > > > To: ECRIT=0D=0A> > > > > Subject: [Ecrit] ELIN=0D=0A> > > > >=0D= =0A> > > > > LLDP-MED supports not just civic and coordinate based=0D=0Alo= cation=0D=0A> > > > > information, but also an ELIN. How does this type of= location=0D=0A> > > > > information fit to the IETF Framework=3F Is this = case=0D=0Aconsidered in=0D=0A> > any=0D=0A> > > > > document=3F=0D=0A> > = > > > I couldn't find any information on how to proceed with this=0D=0Atyp= e=0D=0A> > of=0D=0A> > > > > location information.=0D=0A> > > > >=0D=0A>= > > > > cheers=0D=0A> > > > > Karl Heinz=0D=0A> > > > >=0D=0A> > > > >= _______________________________________________=0D=0A> > > > > Ecrit mail= ing list=0D=0A> > > > > Ecrit@ietf.org=0D=0A> > > > > https://www1.ietf.o= rg/mailman/listinfo/ecrit=0D=0A> > > >=0D=0A> > > >=0D=0A> >=0D=0A-------= ----------------------------------------------------------------=0D=0A> -=0D= =0A> > > ------------------------=0D=0A> > > > This message is for the de= signated recipient only and may=0D=0A> > > > contain privileged, proprieta= ry, or otherwise private=0D=0Ainformation.=0D=0A> > > > If you have receiv= ed it in error, please notify the sender=0D=0A> > > > immediately and dele= te the original. Any unauthorized use of=0D=0A> > > > this email is prohi= bited.=0D=0A> > > >=0D=0A> >=0D=0A----------------------------------------= -------------------------------=0D=0A> -=0D=0A> > > ----------------------= --=0D=0A> > > > [mf2]=0D=0A> > > >=0D=0A> > > >=0D=0A> >=0D=0A> >=0D=0A>= >=0D=0A-------------------------------------------------------------------= -----=0D=0A> ------------------------=0D=0A> > This message is for the des= ignated recipient only and may=0D=0A> > contain privileged, proprietary, o= r otherwise private information.=0D=0A> > If you have received it in error= , please notify the sender=0D=0A> > immediately and delete the original. = Any unauthorized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A>= >=0D=0A-------------------------------------------------------------------= -----=0D=0A> ------------------------=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A= > > _______________________________________________=0D=0A> > Ecrit mailin= g list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.ietf.org/mailman/lis= tinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A>=20=0D=0A> ____________________________= ___________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> = https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A=0D=0A_____________= __________________________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.= org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A----------= ---------------------------------------------------------------------------= -----------=0D=0AThis message is for the designated recipient only and may=0D= =0Acontain privileged, proprietary, or otherwise private information. =20=0D= =0AIf you have received it in error, please notify the sender=0D=0Aimmediat= ely and delete the original. Any unauthorized use of=0D=0Athis email is pr= ohibited.=0D=0A------------------------------------------------------------= ------------------------------------=0D=0A[mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 15 21:21:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsqpY-0007pd-UD; Thu, 15 Nov 2007 21:21:16 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IsqpS-0007cA-3h for ecrit@ietf.org; Thu, 15 Nov 2007 21:21:10 -0500 Received: from smtp.mitel.com ([216.191.234.102]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IsqpQ-0007lO-0S for ecrit@ietf.org; Thu, 15 Nov 2007 21:21:10 -0500 Received: from localhost (smtp.mitel.com [127.0.0.1]) by smtp.mitel.com (Postfix) with ESMTP id 7219E2C034; Thu, 15 Nov 2007 21:21:07 -0500 (EST) X-Virus-Scanned: by amavisd-new (virusonly) at mitel.com 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 7JuvqWpfGX+7; Thu, 15 Nov 2007 21:21:05 -0500 (EST) Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by smtp.mitel.com (Postfix) with ESMTP id 981C72C042; Thu, 15 Nov 2007 21:21:05 -0500 (EST) In-Reply-To: To: "Dawson, Martin" Subject: RE: [Ecrit] ELIN MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: peter_blatherwick@mitel.com Date: Thu, 15 Nov 2007 21:21:04 -0500 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 11/15/2007 09:21:05 PM, Serialize complete at 11/15/2007 09:21:05 PM X-Spam-Score: 1.7 (+) X-Scan-Signature: 52b2f07c128fbe337bbf87ebd50cfd46 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="===============0063267655==" Errors-To: ecrit-bounces@ietf.org This is a multipart message in MIME format. --===============0063267655== Content-Type: multipart/alternative; boundary="=_alternative 000CEA9D85257395_=" This is a multipart message in MIME format. --=_alternative 000CEA9D85257395_= Content-Type: text/plain; charset="US-ASCII" Hi, > ... To be useful there would need to be a scenario where > the ELIN was available but location (or the location represented by the > ERL) was not. How realistic is this? Excuse me but... In N.A. at present, for enterprise, this is actually the 99.9% case (choose your number of 9s). ELIN is how it works today, and it is provisioned all over, right now, with large investments involved on all fronts. These are really big numbers. ECRIT all-SIP approach has approximately 0% penetration at this time, since it is not finished or deployed in any large numbers at all (yet). ELIN-based enterprise systems are current reality in N.A. and will take a very long transition time to change over. They need to be supported. This *will* all change of course, and for all the right reasons. I fully support this! But it will just take a really long time to accomplish. Thus, it is twisting reality very drastically to suggest that the case for supporting currently deployed PSTN ECS (E911) systems is not "useful", "realistic" or "available". That's actually exactly where we are today! But, I do agree, for IETF (specifically ECRIT) it probably does not make much sense to standardize anything specific around ELIN at this point in time. As previously stated it is our of scope by definition for ECRIT. Too little, too late, wrong group. -- Peter "Dawson, Martin" 15.11.07 18:52 To: "Brian Rosen" , "Karl Heinz Wolf" , cc: "ECRIT" Subject: RE: [Ecrit] ELIN I agree with this. To be useful there would need to be a scenario where the ELIN was available but location (or the location represented by the ERL) was not. How realistic is this? This would also turn the LoST server into an ALI... which, as Brian says, is actually the model which is going away - on the assumption that phone numbers simply don't reliably represent location any more. Cheers, Martin -----Original Message----- From: Brian Rosen [mailto:br@brianrosen.net] Sent: Friday, 16 November 2007 3:42 AM To: 'Karl Heinz Wolf'; peter_blatherwick@mitel.com Cc: 'ECRIT' Subject: RE: [Ecrit] ELIN ELINs are peculiar to the U.S. Multiple Line Telephone Systems, and really are only applicable in the current TDM based emergency calling system. I don't think it makes any sense to mix current generation systems, which would include ELINs with next generation, IP based systems. PBX systems today cater to specific countries emergency call systems, which in the U.S. would include support for ELINs. I don't think we get enough mileage out of standardizing something that is specific to the U.S., and is going away in favor of a more general LoST based routing system. Brian > -----Original Message----- > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > Sent: Thursday, November 15, 2007 5:25 AM > To: peter_blatherwick@mitel.com > Cc: ECRIT > Subject: Re: [Ecrit] ELIN > > Hi Peter, > thanks for your additional information on ELINs. > > > > ... what the client does when its gets the ELIN from LLDP-MED I have > no > > idea > > ELIN was added to LLDP-MED for completeness and for compatibility with > > existing PSTN infrastructure. Since existing E911 systems in N.A. use > ELIN > > today, there was no easy way to support it with Civic and Geo types > only. > > (I am a little surprised ELIN type has not been defined in IETF as well > ... > > but that's another story.) Thinking was that the device could receive > ELIN, > > pass it in SIP signalling towards PSTN GW, that would then insert the > ELIN > > into PSTN trunk signalling. I do not know if anyone uses it this way. > > > > How can this gateway be determined? > Would it be imaginable to have a LoST location profile for ELINs, get > the responsible PSAP via LoST for the given ELIN and convey the ELIN > in the SIP message directly to the PSAP (without a gateway) as > location by reference? > > cheers, > karl heinz > > > > > > To this extent the ELIN is the way in which LLDP-MED currently > supports > > > location by reference. > > Yes, ELIN is effectively a form of location-by-reference. LLDP-MED can > also > > be readily extended to support LbyR in the sense used in Geopriv / ECRIT > as > > well. Since location objects are directly supplied by the network > > infrastructure in LLDP-MED's case, it is not entirely clear to me why > LbyR > > would really be needed / useful for LLDP-MED deployments. > > > > Cheers, > > Peter Blatherwick > > > > > > > > > > > > > > > > "Winterbottom, James" > > > > 12.11.07 04:46 > > To: "Karl Heinz Wolf" > > cc: ECRIT > > Subject: RE: [Ecrit] ELIN > > > > > > > > > > Hi Karl Heinz, > > > > It is the only the extension that actually has the ELIN number that > gets > > called back. So all extensions with the same ELIN need to be close to > > one another. > > > > As to what the client does when its gets the ELIN from LLDP-MED I have > > no idea... *8) > > > > Cheers > > James > > > > > > > -----Original Message----- > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > Sent: Monday, 12 November 2007 8:31 PM > > > To: Winterbottom, James > > > Cc: ECRIT > > > Subject: Re: [Ecrit] ELIN > > > > > > Hi James! > > > > > > Thank you for your detailed description of the ELIN. > > > One more question: how does the callback from the PSAP work, if there > > > are multiple extensions with the same ELIN? > > > > > > Anyway, in case a company uses ELINs, and LLDP-MED location > > > information tells the client this ELIN, what is the client supposed > to > > > do? > > > > > > cheers > > > karl heinz > > > > > > On Nov 12, 2007 10:03 AM, Winterbottom, James > > > wrote: > > > > Hi Karl Heinz, > > > > > > > > An ELIN is a specific callback number that represents an area in an > > MLTS > > > > (Multi-Line Telephone System). As far as I know they are only used > > in > > > > the USA. The following description may not be 100% right, but it is > > > > pretty close. > > > > > > > > Essentially if you have a company or campus that occupies a large > > area, > > > > you can break this up into smaller areas to make it easier for > > emergency > > > > service crews to find people. In some States this is mandated when > > the > > > > area becomes more than a certain size (8000 sqr feet is commonly > > > > quoted). Generally what happens is that all telephone extensions in > > a > > > > certain area are associated with what is called an ERL (emergency > > > > resource location), this is done in the PABX provisioning. Each ERL > > is > > > > allocated an ELIN that serves as the presented calling number to > the > > > > PSAP for any extension provisioned against the ERL. The PSAP is > able > > to > > > > use the ELIN to get the floor location and area serviced by a > > specific > > > > ELIN. The ELIN also serves as the number that the PSAP will > callback > > in > > > > the case of the call being dropped. > > > > > > > > To this extent the ELIN is the way in which LLDP-MED currently > > supports > > > > location by reference. > > > > > > > > Please let me know if this isn't clear and I will try an clarify > > > > further. > > > > > > > > Cheers > > > > James > > > > > > > > > > > > > -----Original Message----- > > > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com] > > > > > Sent: Monday, 12 November 2007 7:23 PM > > > > > To: ECRIT > > > > > Subject: [Ecrit] ELIN > > > > > > > > > > LLDP-MED supports not just civic and coordinate based location > > > > > information, but also an ELIN. How does this type of location > > > > > information fit to the IETF Framework? Is this case considered in > > any > > > > > document? > > > > > I couldn't find any information on how to proceed with this type > > of > > > > > location information. > > > > > > > > > > cheers > > > > > Karl Heinz > > > > > > > > > > _______________________________________________ > > > > > 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] > > > > > > > > > > > > > > ------------------------------------------------------------------------ > ------------------------ > > 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 _______________________________________________ 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] --=_alternative 000CEA9D85257395_= Content-Type: text/html; charset="US-ASCII"
Hi,

> ... To be useful there would need to be a scenario where
> the ELIN was available but location (or the location represented by the
> ERL) was not. How realistic is this?

Excuse me but...   In N.A. at present, for enterprise, this is actually the 99.9<blah>% case (choose your number of 9s).  ELIN is how it works today, and it is provisioned all over, right now, with large investments involved on all fronts.  These are really big numbers.  ECRIT all-SIP approach has approximately 0% penetration at this time, since it is not finished or deployed in any large numbers at all (yet).  ELIN-based enterprise systems are current reality in N.A. and will take a very long transition time to change over.  They need to be supported.  This *will* all change of course, and for all the right reasons.  I fully support this!  But it will just take a really long time to accomplish.  

Thus, it is twisting reality very drastically to suggest that the case for supporting currently deployed PSTN ECS (E911) systems is not "useful", "realistic" or "available".  That's actually exactly where we are today!  

But, I do agree, for IETF (specifically ECRIT) it probably does not make much sense to standardize anything specific around ELIN at this point in time.  As previously stated it is our of scope by definition for ECRIT.  Too little, too late, wrong group.  

-- Peter


 


"Dawson, Martin" <Martin.Dawson@andrew.com>

15.11.07 18:52

       
        To:        "Brian Rosen" <br@brianrosen.net>, "Karl Heinz Wolf" <khwolf1@gmail.com>, <peter_blatherwick@mitel.com>
        cc:        "ECRIT" <ecrit@ietf.org>
        Subject:        RE: [Ecrit] ELIN



I agree with this. To be useful there would need to be a scenario where
the ELIN was available but location (or the location represented by the
ERL) was not. How realistic is this?

This would also turn the LoST server into an ALI... which, as Brian
says, is actually the model which is going away - on the assumption that
phone numbers simply don't reliably represent location any more.

Cheers,
Martin

-----Original Message-----
From: Brian Rosen [mailto:br@brianrosen.net]
Sent: Friday, 16 November 2007 3:42 AM
To: 'Karl Heinz Wolf'; peter_blatherwick@mitel.com
Cc: 'ECRIT'
Subject: RE: [Ecrit] ELIN

ELINs are peculiar to the U.S. Multiple Line Telephone Systems, and
really
are only applicable in the current TDM based emergency calling system.
I
don't think it makes any sense to mix current generation systems, which
would include ELINs with next generation, IP based systems.

PBX systems today cater to specific countries emergency call systems,
which
in the U.S. would include support for ELINs.  I don't think we get
enough
mileage out of standardizing something that is specific to the U.S., and
is
going away in favor of a more general LoST based routing system.

Brian

> -----Original Message-----
> From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]
> Sent: Thursday, November 15, 2007 5:25 AM
> To: peter_blatherwick@mitel.com
> Cc: ECRIT
> Subject: Re: [Ecrit] ELIN
>
> Hi Peter,
> thanks for your additional information on ELINs.
>
> > > ... what the client does when its gets the ELIN from LLDP-MED I
have
> no
> > idea
> > ELIN was added to LLDP-MED for completeness and for compatibility
with
> > existing PSTN infrastructure.  Since existing E911 systems in N.A.
use
> ELIN
> > today, there was no easy way to support it with Civic and Geo types
> only.
> > (I am a little surprised ELIN type has not been defined in IETF as
well
> ...
> > but that's another story.)  Thinking was that the device could
receive
> ELIN,
> > pass it in SIP signalling towards PSTN GW, that would then insert
the
> ELIN
> > into PSTN trunk signalling.  I do not know if anyone uses it this
way.
> >
>
> How can this gateway be determined?
> Would it be imaginable to have a LoST location profile for ELINs, get
> the responsible PSAP via LoST for the given ELIN and convey the ELIN
> in the SIP message directly to the PSAP (without a gateway) as
> location by reference?
>
> cheers,
> karl heinz
>
> >
> > > To this extent the ELIN is the way in which LLDP-MED currently
> supports
> >  > location by reference.
> > Yes, ELIN is effectively a form of location-by-reference.  LLDP-MED
can
> also
> > be readily extended to support LbyR in the sense used in Geopriv /
ECRIT
> as
> > well.  Since location objects are directly supplied by the network
> > infrastructure in LLDP-MED's case, it is not entirely clear to me
why
> LbyR
> > would really be needed / useful for LLDP-MED deployments.
> >
> > Cheers,
> > Peter Blatherwick
> >
> >
> >
> >
> >
> >
> >
> > "Winterbottom, James" <James.Winterbottom@andrew.com>
> >
> > 12.11.07 04:46
> >         To:        "Karl Heinz Wolf" <khwolf1@gmail.com>
> >         cc:        ECRIT <ecrit@ietf.org>
> >         Subject:        RE: [Ecrit] ELIN
> >
> >
> >
> >
> > Hi Karl Heinz,
> >
> >  It is the only the extension that actually has the ELIN number that
> gets
> >  called back. So all extensions with the same ELIN need to be close
to
> >  one another.
> >
> >  As to what the client does when its gets the ELIN from LLDP-MED I
have
> >  no idea... *8)
> >
> >  Cheers
> >  James
> >
> >
> >  > -----Original Message-----
> >  > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]
> >  > Sent: Monday, 12 November 2007 8:31 PM
> >  > To: Winterbottom, James
> >  > Cc: ECRIT
> >  > Subject: Re: [Ecrit] ELIN
> >  >
> >  > Hi James!
> >  >
> >  > Thank you for your detailed description of the ELIN.
> >  > One more question: how does the callback from the PSAP work, if
there
> >  > are multiple extensions with the same ELIN?
> >  >
> >  > Anyway, in case a company uses ELINs, and LLDP-MED location
> >  > information tells the client this ELIN, what is the client
supposed
> to
> >  > do?
> >  >
> >  > cheers
> >  > karl heinz
> >  >
> >  > On Nov 12, 2007 10:03 AM, Winterbottom, James
> >  > <James.Winterbottom@andrew.com> wrote:
> >  > > Hi Karl Heinz,
> >  > >
> >  > > An ELIN is a specific callback number that represents an area
in an
> >  MLTS
> >  > > (Multi-Line Telephone System). As far as I know they are only
used
> >  in
> >  > > the USA. The following description may not be 100% right, but
it is
> >  > > pretty close.
> >  > >
> >  > > Essentially if you have a company or campus that occupies a
large
> >  area,
> >  > > you can break this up into smaller areas to make it easier for
> >  emergency
> >  > > service crews to find people. In some States this is mandated
when
> >  the
> >  > > area becomes more than a certain size (8000 sqr feet is
commonly
> >  > > quoted). Generally what happens is that all telephone
extensions in
> >  a
> >  > > certain area are associated with what is called an ERL
(emergency
> >  > > resource location), this is done in the PABX provisioning. Each
ERL
> >  is
> >  > > allocated an ELIN that serves as the presented calling number
to
> the
> >  > > PSAP for any extension provisioned against the ERL. The PSAP is
> able
> >  to
> >  > > use the ELIN to get the floor location and area serviced by a
> >  specific
> >  > > ELIN. The ELIN also serves as the number that the PSAP will
> callback
> >  in
> >  > > the case of the call being dropped.
> >  > >
> >  > > To this extent the ELIN is the way in which LLDP-MED currently
> >  supports
> >  > > location by reference.
> >  > >
> >  > > Please let me know if this isn't clear and I will try an
clarify
> >  > > further.
> >  > >
> >  > > Cheers
> >  > > James
> >  > >
> >  > >
> >  > > > -----Original Message-----
> >  > > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.com]
> >  > > > Sent: Monday, 12 November 2007 7:23 PM
> >  > > > To: ECRIT
> >  > > > Subject: [Ecrit] ELIN
> >  > > >
> >  > > > LLDP-MED supports not just civic and coordinate based
location
> >  > > > information, but also an ELIN. How does this type of location
> >  > > > information fit to the IETF Framework? Is this case
considered in
> >  any
> >  > > > document?
> >  > > > I couldn't find any information on how to proceed with this
type
> >  of
> >  > > > location information.
> >  > > >
> >  > > > cheers
> >  > > > Karl Heinz
> >  > > >
> >  > > > _______________________________________________
> >  > > > 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]
> >  > >
> >  > >
> >
> >
> >
------------------------------------------------------------------------
> ------------------------
> >  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


_______________________________________________
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]
--=_alternative 000CEA9D85257395_=-- --===============0063267655== 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 --===============0063267655==-- From ecrit-bounces@ietf.org Fri Nov 16 00:34:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Istqs-0000s0-4r; Fri, 16 Nov 2007 00:34:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Istqr-0000qq-33 for ecrit@ietf.org; Fri, 16 Nov 2007 00:34:49 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Istqq-0005LJ-3i for ecrit@ietf.org; Fri, 16 Nov 2007 00:34:48 -0500 X-SEF-Processed: 5_0_0_910__2007_11_15_23_45_19 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 15 Nov 2007 23:45:17 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Nov 2007 23:34:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] ELIN Date: Thu, 15 Nov 2007 23:34:35 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ELIN Thread-Index: Acgn915KmnCLmoyeSbaPQDRnwt7vMwAGnYMg References: From: "Dawson, Martin" To: X-OriginalArrivalTime: 16 Nov 2007 05:34:41.0346 (UTC) FILETIME=[62E07A20:01C82812] X-Spam-Score: 0.0 (/) X-Scan-Signature: d115f8e98afb84ba4860c5c6ee611921 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="===============0517319497==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0517319497== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82812.62C72732" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82812.62C72732 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't understand the reaction.=0D=0A=0D=0A=20=0D=0A=0D=0AThe question was= whether it would be useful to make ELIN a query key to=0D=0ALoST. I only s= aid I thought it would be unusual in an Internet delivered=0D=0Aemergency c= all to have a system that could pick up an ELIN but not an=0D=0AERL - meani= ng it you'd expect it could use location to make the query=0D=0Aper existin= g LoST semantics. I never suggested ELIN isn't commonly=0D=0Adeployed....=0D= =0A=0D=0A=20=0D=0A=0D=0ARegards,=0D=0A=0D=0AMartin=0D=0A=0D=0A=20=0D=0A=0D=0A= ________________________________=0D=0A=0D=0AFrom: peter_blatherwick@mitel.c= om [mailto:peter_blatherwick@mitel.com]=20=0D=0ASent: Friday, 16 November 2= 007 1:21 PM=0D=0ATo: Dawson, Martin=0D=0ACc: Brian Rosen; ECRIT; Karl Heinz= Wolf=0D=0ASubject: RE: [Ecrit] ELIN=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0AHi, =0D= =0A=0D=0A> ... To be useful there would need to be a scenario where=0D=0A> = the ELIN was available but location (or the location represented by=0D=0Ath= e=0D=0A> ERL) was not. How realistic is this=3F=20=0D=0A=0D=0AExcuse me but= =2E.. In N.A. at present, for enterprise, this is actually=0D=0Athe 99.9<= blah>% case (choose your number of 9s). ELIN is how it works=0D=0Atoday, a= nd it is provisioned all over, right now, with large investments=0D=0Ainvol= ved on all fronts. These are really big numbers. ECRIT all-SIP=0D=0Aappro= ach has approximately 0% penetration at this time, since it is not=0D=0Afin= ished or deployed in any large numbers at all (yet). ELIN-based=0D=0Aenter= prise systems are current reality in N.A. and will take a very long=0D=0Atr= ansition time to change over. They need to be supported. This *will*=0D=0A= all change of course, and for all the right reasons. I fully support=0D=0A= this! But it will just take a really long time to accomplish. =20=0D=0A=0D= =0AThus, it is twisting reality very drastically to suggest that the case=0D= =0Afor supporting currently deployed PSTN ECS (E911) systems is not=0D=0A"u= seful", "realistic" or "available". That's actually exactly where we=0D=0A= are today! =20=0D=0A=0D=0ABut, I do agree, for IETF (specifically ECRIT) i= t probably does not make=0D=0Amuch sense to standardize anything specific a= round ELIN at this point in=0D=0Atime. As previously stated it is our of s= cope by definition for ECRIT.=0D=0AToo little, too late, wrong group. =20=0D= =0A=0D=0A-- Peter=20=0D=0A=0D=0A=0D=0A =20=0D=0A=0D=0A=0D=0A=0D=0A=20=0D=0A=0D= =0A"Dawson, Martin" =20=0D=0A=0D=0A15.11.07 18:52= =20=0D=0A=0D=0A =20=0D=0A To: "Brian Rosen" , "Karl Heinz Wolf"=0D=0A, =20=0D=0A cc: "ECRIT" =20=0D=0A = Subject: RE: [Ecrit] ELIN=0D=0A=0D=0A=0D=0A=0D=0A=0D=0AI agree wit= h this. To be useful there would need to be a scenario where=0D=0Athe ELIN = was available but location (or the location represented by the=0D=0AERL) wa= s not. How realistic is this=3F=0D=0A=0D=0AThis would also turn the LoST se= rver into an ALI... which, as Brian=0D=0Asays, is actually the model which = is going away - on the assumption that=0D=0Aphone numbers simply don't reli= ably represent location any more.=0D=0A=0D=0ACheers,=0D=0AMartin=0D=0A=0D=0A= -----Original Message-----=0D=0AFrom: Brian Rosen [mailto:br@brianrosen.net= ]=20=0D=0ASent: Friday, 16 November 2007 3:42 AM=0D=0ATo: 'Karl Heinz Wolf'= ; peter_blatherwick@mitel.com=0D=0ACc: 'ECRIT'=0D=0ASubject: RE: [Ecrit] EL= IN=0D=0A=0D=0AELINs are peculiar to the U.S. Multiple Line Telephone System= s, and=0D=0Areally=0D=0Aare only applicable in the current TDM based emerge= ncy calling system.=0D=0AI=0D=0Adon't think it makes any sense to mix curre= nt generation systems, which=0D=0Awould include ELINs with next generation,= IP based systems.=0D=0A=0D=0APBX systems today cater to specific countries= emergency call systems,=0D=0Awhich=0D=0Ain the U.S. would include support = for ELINs. I don't think we get=0D=0Aenough=0D=0Amileage out of standardiz= ing something that is specific to the U.S., and=0D=0Ais=0D=0Agoing away in = favor of a more general LoST based routing system.=0D=0A=0D=0ABrian=0D=0A=0D= =0A> -----Original Message-----=0D=0A> From: Karl Heinz Wolf [mailto:khwolf= 1@gmail.com]=0D=0A> Sent: Thursday, November 15, 2007 5:25 AM=0D=0A> To: pe= ter_blatherwick@mitel.com=0D=0A> Cc: ECRIT=0D=0A> Subject: Re: [Ecrit] ELIN=0D= =0A>=20=0D=0A> Hi Peter,=0D=0A> thanks for your additional information on E= LINs.=0D=0A>=20=0D=0A> > > ... what the client does when its gets the ELIN = from LLDP-MED I=0D=0Ahave=0D=0A> no=0D=0A> > idea=0D=0A> > ELIN was added t= o LLDP-MED for completeness and for compatibility=0D=0Awith=0D=0A> > existi= ng PSTN infrastructure. Since existing E911 systems in N.A.=0D=0Ause=0D=0A= > ELIN=0D=0A> > today, there was no easy way to support it with Civic and G= eo types=0D=0A> only.=0D=0A> > (I am a little surprised ELIN type has not b= een defined in IETF as=0D=0Awell=0D=0A> ...=0D=0A> > but that's another sto= ry.) Thinking was that the device could=0D=0Areceive=0D=0A> ELIN,=0D=0A> >= pass it in SIP signalling towards PSTN GW, that would then insert=0D=0Athe=0D= =0A> ELIN=0D=0A> > into PSTN trunk signalling. I do not know if anyone use= s it this=0D=0Away.=0D=0A> >=0D=0A>=20=0D=0A> How can this gateway be deter= mined=3F=0D=0A> Would it be imaginable to have a LoST location profile for = ELINs, get=0D=0A> the responsible PSAP via LoST for the given ELIN and conv= ey the ELIN=0D=0A> in the SIP message directly to the PSAP (without a gatew= ay) as=0D=0A> location by reference=3F=0D=0A>=20=0D=0A> cheers,=0D=0A> karl= heinz=0D=0A>=20=0D=0A> >=0D=0A> > > To this extent the ELIN is the way in = which LLDP-MED currently=0D=0A> supports=0D=0A> > > location by reference.=0D= =0A> > Yes, ELIN is effectively a form of location-by-reference. LLDP-MED=0D= =0Acan=0D=0A> also=0D=0A> > be readily extended to support LbyR in the sens= e used in Geopriv /=0D=0AECRIT=0D=0A> as=0D=0A> > well. Since location obj= ects are directly supplied by the network=0D=0A> > infrastructure in LLDP-M= ED's case, it is not entirely clear to me=0D=0Awhy=0D=0A> LbyR=0D=0A> > wou= ld really be needed / useful for LLDP-MED deployments.=0D=0A> >=0D=0A> > Ch= eers,=0D=0A> > Peter Blatherwick=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A> >=0D=0A>= >=0D=0A> >=0D=0A> >=0D=0A> > "Winterbottom, James" =0D=0A> >=0D=0A> > 12.11.07 04:46=0D=0A> > To: "Karl= Heinz Wolf" =0D=0A> > cc: ECRIT =0D=0A> > Subject: RE: [Ecrit] ELIN=0D=0A> >=0D=0A> = >=0D=0A> >=0D=0A> >=0D=0A> > Hi Karl Heinz,=0D=0A> >=0D=0A> > It is the on= ly the extension that actually has the ELIN number that=0D=0A> gets=0D=0A> = > called back. So all extensions with the same ELIN need to be close=0D=0A= to=0D=0A> > one another.=0D=0A> >=0D=0A> > As to what the client does whe= n its gets the ELIN from LLDP-MED I=0D=0Ahave=0D=0A> > no idea... *8)=0D=0A= > >=0D=0A> > Cheers=0D=0A> > James=0D=0A> >=0D=0A> >=0D=0A> > > -----Ori= ginal Message-----=0D=0A> > > From: Karl Heinz Wolf [mailto:khwolf1@gmail.= com]=0D=0A> > > Sent: Monday, 12 November 2007 8:31 PM=0D=0A> > > To: Win= terbottom, James=0D=0A> > > Cc: ECRIT=0D=0A> > > Subject: Re: [Ecrit] ELI= N=0D=0A> > >=0D=0A> > > Hi James!=0D=0A> > >=0D=0A> > > Thank you for y= our detailed description of the ELIN.=0D=0A> > > One more question: how do= es the callback from the PSAP work, if=0D=0Athere=0D=0A> > > are multiple = extensions with the same ELIN=3F=0D=0A> > >=0D=0A> > > Anyway, in case a = company uses ELINs, and LLDP-MED location=0D=0A> > > information tells the= client this ELIN, what is the client=0D=0Asupposed=0D=0A> to=0D=0A> > > d= o=3F=0D=0A> > >=0D=0A> > > cheers=0D=0A> > > karl heinz=0D=0A> > >=0D=0A= > > > On Nov 12, 2007 10:03 AM, Winterbottom, James=0D=0A> > > wrote:=0D=0A> > > > Hi Karl Heinz,=0D=0A> > > >=0D=0A= > > > > An ELIN is a specific callback number that represents an area=0D=0A= in an=0D=0A> > MLTS=0D=0A> > > > (Multi-Line Telephone System). As far as= I know they are only=0D=0Aused=0D=0A> > in=0D=0A> > > > the USA. The fol= lowing description may not be 100% right, but=0D=0Ait is=0D=0A> > > > pret= ty close.=0D=0A> > > >=0D=0A> > > > Essentially if you have a company or = campus that occupies a=0D=0Alarge=0D=0A> > area,=0D=0A> > > > you can bre= ak this up into smaller areas to make it easier for=0D=0A> > emergency=0D=0A= > > > > service crews to find people. In some States this is mandated=0D=0A= when=0D=0A> > the=0D=0A> > > > area becomes more than a certain size (800= 0 sqr feet is=0D=0Acommonly=0D=0A> > > > quoted). Generally what happens i= s that all telephone=0D=0Aextensions in=0D=0A> > a=0D=0A> > > > certain a= rea are associated with what is called an ERL=0D=0A(emergency=0D=0A> > > >= resource location), this is done in the PABX provisioning. Each=0D=0AERL=0D= =0A> > is=0D=0A> > > > allocated an ELIN that serves as the presented cal= ling number=0D=0Ato=0D=0A> the=0D=0A> > > > PSAP for any extension provisi= oned against the ERL. The PSAP is=0D=0A> able=0D=0A> > to=0D=0A> > > > us= e the ELIN to get the floor location and area serviced by a=0D=0A> > speci= fic=0D=0A> > > > ELIN. The ELIN also serves as the number that the PSAP wi= ll=0D=0A> callback=0D=0A> > in=0D=0A> > > > the case of the call being dr= opped.=0D=0A> > > >=0D=0A> > > > To this extent the ELIN is the way in wh= ich LLDP-MED currently=0D=0A> > supports=0D=0A> > > > location by referen= ce.=0D=0A> > > >=0D=0A> > > > Please let me know if this isn't clear and = I will try an=0D=0Aclarify=0D=0A> > > > further.=0D=0A> > > >=0D=0A> > >= > Cheers=0D=0A> > > > James=0D=0A> > > >=0D=0A> > > >=0D=0A> > > > > -= ----Original Message-----=0D=0A> > > > > From: Karl Heinz Wolf [mailto:khw= olf1@gmail.com]=0D=0A> > > > > Sent: Monday, 12 November 2007 7:23 PM=0D=0A= > > > > > To: ECRIT=0D=0A> > > > > Subject: [Ecrit] ELIN=0D=0A> > > > >=0D= =0A> > > > > LLDP-MED supports not just civic and coordinate based=0D=0Alo= cation=0D=0A> > > > > information, but also an ELIN. How does this type of= location=0D=0A> > > > > information fit to the IETF Framework=3F Is this = case=0D=0Aconsidered in=0D=0A> > any=0D=0A> > > > > document=3F=0D=0A> > = > > > I couldn't find any information on how to proceed with this=0D=0Atyp= e=0D=0A> > of=0D=0A> > > > > location information.=0D=0A> > > > >=0D=0A>= > > > > cheers=0D=0A> > > > > Karl Heinz=0D=0A> > > > >=0D=0A> > > > >= _______________________________________________=0D=0A> > > > > Ecrit mail= ing list=0D=0A> > > > > Ecrit@ietf.org=0D=0A> > > > > https://www1.ietf.o= rg/mailman/listinfo/ecrit=0D=0A> > > >=0D=0A> > > >=0D=0A> >=0D=0A-------= ----------------------------------------------------------------=0D=0A> -=0D= =0A> > > ------------------------=0D=0A> > > > This message is for the de= signated recipient only and may=0D=0A> > > > contain privileged, proprieta= ry, or otherwise private=0D=0Ainformation.=0D=0A> > > > If you have receiv= ed it in error, please notify the sender=0D=0A> > > > immediately and dele= te the original. Any unauthorized use of=0D=0A> > > > this email is prohi= bited.=0D=0A> > > >=0D=0A> >=0D=0A----------------------------------------= -------------------------------=0D=0A> -=0D=0A> > > ----------------------= --=0D=0A> > > > [mf2]=0D=0A> > > >=0D=0A> > > >=0D=0A> >=0D=0A> >=0D=0A>= >=0D=0A-------------------------------------------------------------------= -----=0D=0A> ------------------------=0D=0A> > This message is for the des= ignated recipient only and may=0D=0A> > contain privileged, proprietary, o= r otherwise private information.=0D=0A> > If you have received it in error= , please notify the sender=0D=0A> > immediately and delete the original. = Any unauthorized use of=0D=0A> > this email is prohibited.=0D=0A> >=0D=0A>= >=0D=0A-------------------------------------------------------------------= -----=0D=0A> ------------------------=0D=0A> > [mf2]=0D=0A> >=0D=0A> >=0D=0A= > > _______________________________________________=0D=0A> > Ecrit mailin= g list=0D=0A> > Ecrit@ietf.org=0D=0A> > https://www1.ietf.org/mailman/lis= tinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A>=20=0D=0A> ____________________________= ___________________=0D=0A> Ecrit mailing list=0D=0A> Ecrit@ietf.org=0D=0A> = https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A=0D=0A_____________= __________________________________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.= org=0D=0Ahttps://www1.ietf.org/mailman/listinfo/ecrit=0D=0A=0D=0A----------= --------------------------------------------------------------=0D=0A-------= -----------------=0D=0AThis message is for the designated recipient only an= d may=0D=0Acontain privileged, proprietary, or otherwise private informatio= n. =20=0D=0AIf you have received it in error, please notify the sender=0D=0A= immediately and delete the original. Any unauthorized use of=0D=0Athis ema= il is prohibited.=0D=0A----------------------------------------------------= --------------------=0D=0A------------------------=0D=0A[mf2]=0D=0A=0D=0A=0D= =0A=0D=0A------------------------------------------------------------------= ------------------------------=0D=0AThis message is for the designated reci= pient only and may=0D=0Acontain privileged, proprietary, or otherwise priva= te information. =20=0D=0AIf you have received it in error, please notify th= e sender=0D=0Aimmediately and delete the original. Any unauthorized use of=0D= =0Athis email is prohibited.=0D=0A-----------------------------------------= -------------------------------------------------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C82812.62C72732 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A
=0D=0A=0D=0A

I don’t understand the reacti= on.

=0D=0A=0D=0A

 

=0D=0A=0D=0A

The question was whether= it would be=0D=0Auseful to make ELIN a query key to LoST. I only said I th= ought it would be=0D=0Aunusual in an Internet delivered emergency call to h= ave a system that could=0D=0Apick up an ELIN but not an ERL – meaning= it you’d expect it could=0D=0Ause location to make the query per exi= sting LoST semantics. I never suggested=0D=0AELIN isn’t commonly depl= oyed....

=0D=0A=0D=0A

 

=0D=0A=0D=0A=

Regards,

=0D=0A=0D=0A

Martin

=0D=0A=0D=0A

 

=0D= =0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A

From:=0D=0Apeter_bl= atherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
=0D=0ASent: Friday, 16 November 2007=0D=0A1:21 PM=0D=0ATo: Dawson, Martin=0D=0ACc: Brian Rosen; ECR= IT; Karl Heinz=0D=0AWolf
=0D=0ASubje= ct: RE: [Ecrit] ELIN<= /o:p>

=0D=0A=0D=0A
=0D=0A=0D=0A

 

=0D=0A=0D=0A


=0D=0AHi,
=0D=0A
=0D=0A>=0D=0A... <= font size=3D2 face=3D"Courier New">T= o be useful there would need to be a scenario where
=0D=0A> the ELIN was= available but location (or the=0D=0Alocation represented by the
=0D=0A> ERL) was not. How realistic = is this=3F=0D=0A
=0D=0A
=0D=0AExcuse me=0D=0A= but...   In N.A. at present, for enterprise, this is actually the=0D=0A= 99.9<blah>% case (choose your number of 9s).  ELIN is how it wor= ks=0D=0Atoday, and it is provisioned all over, right now, with large invest= ments=0D=0Ainvolved on all fronts.  These are really big numbers. &nbs= p;ECRIT all-SIP=0D=0Aapproach has approximately 0% penetration at this time= , since it is not=0D=0Afinished or deployed in any large numbers at all (ye= t).  ELIN-based=0D=0Aenterprise systems are current reality in N.A. an= d will take a very long=0D=0Atransition time to change over.  They nee= d to be supported.  This *will*=0D=0Aall change of course, and for all= the right reasons.  I fully support=0D=0Athis!  But it will just= take a really long time to accomplish.  =0D=0A
=0D= =0A
=0D=0AThus, it is=0D=0Atwisting reality very drastically to suggest th= at the case for supporting=0D=0Acurrently deployed PSTN ECS (E911) systems = is not "useful",=0D=0A"realistic" or "available&qu= ot;.  That's actually exactly=0D=0Awhere we are today!  
=0D=0A
=0D=0ABut, I do=0D=0Aagree, for IETF (specifically E= CRIT) it probably does not make much sense to=0D=0Astandardize anything spe= cific around ELIN at this point in time.  As=0D=0Apreviously stated it= is our of scope by definition for ECRIT.  Too little,=0D=0Atoo late, = wrong group.  
=0D=0A
=0D=0A-- Peter=0D=0A
=0D=0A
=0D=0A
=0D=0A =0D=0A=0D=0A
=0D=0A

=0D=0A=0D=0A=0D=0A= =0D=0A =0D=0A =0D=0A =0D=0A
=0D= =0A

 

=0D=0A =0D=0A 		=0D=0A=

"Dawso= n, Martin"=0D=0A <Martin.Dawson@andrew.com> <= o:p>

=0D=0A

15.11.07 18:52 =

=0D=0A 		=0D=0A

    &= nbsp;  
=0D=0A  =0D=0A   &n= bsp;   To:        "Brian Rosen"=0D=0A &= lt;br@brianrosen.net>, "Karl Heinz Wolf"=0D=0A <khwolf1@gm= ail.com>, <peter_blatherwick@mitel.com>=0D=0A
=0D=0A  =0D=0A=       cc:        "ECRIT"=0D=0A= <ecrit@ietf.org>
=0D=0A  =0D=0A=       Subject:        RE: [Ecrit] ELIN=

=0D=0A
=0D=0A=0D= =0A


=0D=0A
=0D= =0A
=0D=0AI=0D=0Aagree with this. To be useful there would n= eed to be a scenario where
=0D= =0Athe ELIN was available but location (or t= he=0D=0Alocation represented by the
=0D=0AERL) was not. How realistic is this=3F
=0D=0A=0D=0AThis would also turn the LoST server= into an=0D=0AALI... which, as Brian
=0D=0Asays, is actually the model which is going away -=0D=0Aon the= assumption that
=0D=0Aphone = numbers simply don't reliably represent=0D=0Alocation any more.=
=0D=0A
=0D=0ACheers,
=0D= =0AMartin
=0D=0A
=0D=0A-----Original Message-----
=0D=0A= From: Brian Rosen [mailto:br@brianrosen.net]=
=0D=0ASent: Friday, 16 Nove= mber 2007 3:42 AM
=0D=0ATo: '= Karl Heinz Wolf'; peter_blatherwick@mitel.com
=0D=0ACc: 'EC= RIT'
=0D=0ASubject: RE: [Ecri= t] ELIN
=0D=0A
=0D=0AELINs= are peculiar to the U.S. Multiple Line=0D=0ATelephone Systems, and<= /tt>
=0D=0Areally
=0D=0Aare only applicable in the current TDM based=0D= =0Aemergency calling system.
=0D=0AI
=0D=0Adon't think it = makes any sense to mix current=0D=0Ageneration systems, which=0D=0Awould include ELINs with next genera= tion, IP based=0D=0Asystems.
=0D=0A
=0D=0APBX systems today cater to specific countries=0D=0Aemergency = call systems,
=0D=0Awhich
=0D=0Ain the U.S. would include support for=0D=0AELINs.  I don't think we get
=0D=0Aenough
=0D=0A= mileage out of standardizing something that = is=0D=0Aspecific to the U.S.,=0D=0Aand
=0D=0Ais
=0D=0Agoing away in favor of a more general LoST based=0D=0Arouting syst= em.
=0D=0A
=0D=0ABrian
=0D=0A
=0D=0A> -----Origin= al Message-----
=0D=0A> Fr= om: Karl Heinz Wolf=0D=0A[mailto:khwolf1@gmail.com]
=0D=0A> Sent: Thursday, November 15, 2007 5:25 AM=
=0D=0A> To: peter_blatherwick@mitel.com
=0D= =0A> Cc: ECRIT
=0D=0A<= font face=3D"Courier New">> Subject: Re: [Ecrit] ELIN
=0D= =0A>
=0D=0A> Hi Peter,
=0D=0A> thanks for your additional information on=0D=0AELINs.<= /tt>
=0D=0A>
=0D=0A> > > ... what the client does when it= s=0D=0Agets the ELIN from LLDP-MED I
=0D=0Ahave
=0D=0A>= no
=0D=0A> > idea
=0D=0A> > ELIN was added to= LLDP-MED for=0D=0Acompleteness and for compatibility
=0D=0A= with
=0D=0A> > existing PSTN infrastructure.=0D=0A Since exist= ing E911 systems in N.A.
=0D=0A> ELIN<= /tt>
=0D=0A> > today, there was no = easy way to support=0D=0Ait with Civic and Geo types
=0D=0A<= tt>> only.
=0D=0A> > (I am a little surprised ELIN type has=0D=0Anot= been defined in IETF as
=0D=0A> ...<= /tt>
=0D=0A> > but that's another s= tory.)=0D=0A Thinking was that the device could
=0D=0A<= tt>receive
=0D=0A> ELIN,
=0D=0Athe=
=0D=0A> ELIN
=0D=0A> > into PSTN trunk signalling.  I d= o=0D=0Anot know if anyone uses it this
=0D=0Away.
=0D=0A>= >
=0D=0A> =
=0D=0A> How can this gateway be deter= mined=3F
=0D=0A> Would it = be imaginable to have a LoST=0D=0Alocation profile for ELINs, get
=0D=0A> the responsible PSAP via Lo= ST for the given=0D=0AELIN and convey the ELIN
=0D=0A> in the SIP message directly to the PSAP=0D=0A(= without a gateway) as
=0D=0A&= gt; location by reference=3F
=0D=0A>
=0D=0A> cheers= ,
=0D=0A> karl heinz
=0D=0A>
=0D=0A<= tt>> >
=0D=0A> > > To this extent the ELIN is the way=0D=0Ain = which LLDP-MED currently
=0D=0A> &g= t;  > location by reference.
=0D=0A> > Yes, ELIN is effectively a form of=0D=0Alocation-by= -reference.  LLDP-MED
=0D=0Acan
=0D=0A> also
=0D=0A> > be readily extende= d to support LbyR in=0D=0Athe sense used in Geopriv /
=0D=0A= ECRIT
=0D=0A> as
=0D=0A&= gt; > well.  Since location objects are=0D=0Adirectly supplied by t= he network
=0D=0A> > in= frastructure in LLDP-MED's case, it is=0D=0Anot entirely clear to me=
=0D=0Awhy
=0D=0A= > LbyR
=0D=0A> > would really be needed / useful for=0D=0ALLDP-MED d= eployments.
=0D=0A> >
=0D=0A> > Cheers,=
=0D=0A> > Peter Blatherwick
=0D=0A> >=0D=0A> >
=0D=0A> >
=0D=0A> >
=0D=0A&= gt; >
=0D=0A> >
=0D=0A> >
=0D= =0A> > "Winterbottom,=0D=0A James" <James.Winterbottom@= andrew.com>
=0D=0A> >= ;
=0D=0A> > 12.11.07 04= :46
=0D=0A> >   &n= bsp;     To:  =0D=0A     "Karl Heinz Wol= f" <khwolf1@gmail.com>
=0D=0A> >         cc:  =0D=0A  &nb= sp;  ECRIT <ecrit@ietf.org>
=0D=0A> >         Subject:=0D=0A  &n= bsp;    RE: [Ecrit] ELIN
=0D=0A> >
=0D=0A&= gt; >
=0D=0A> >
=0D=0A> >
=0D= =0A> > Hi Karl Heinz,
=0D= =0A> >
=0D=0A> >  It is the only the extension that=0D=0A= actually has the ELIN number that
=0D=0A> gets
=0D=0A&g= t; >  called back. So all extensions=0D=0Awith the same ELIN need t= o be close
=0D=0Ato
=0D=0A> >  one another.
=0D=0A> >
=0D= =0A> >  As to what the client doe= s when=0D=0Aits gets the ELIN from LLDP-MED I
=0D=0Ahave
=0D=0A> >  no idea... *8)
=0D=0A> >
=0D=0A= > >  Cheers
=0D=0A= > >  James
=0D=0A&= gt; >
=0D=0A> >
=0D=0A> >  > -----O= riginal Message-----
=0D=0A&g= t; >  > From: Karl Heinz Wolf=0D=0A[mailto:khwolf1@gmail.com]
=0D=0A> >  > Sent= : Monday, 12 November=0D=0A2007 8:31 PM
=0D=0A> >  > To: Winte= rbottom,=0D=0A James
=0D=0A> >  > Cc: ECRIT
=0D=0A> >  > Subject: Re: [Ecrit] ELIN=
=0D=0A> >  >
=0D=0A> >  > Hi James!<= /font>
=0D=0A> >  >
=0D=0A> >  > Than= k you for your detailed=0D=0Adescription of the ELIN.
=0D=0A= > >  > One more question: how = does=0D=0Athe callback from the PSAP work, if
=0D=0Athere
=0D=0A> >  > are multiple extensions with=0D=0Athe same ELIN=3F=
=0D=0A> >  >
=0D=0A> >  > Any= way, in case a company=0D=0Auses ELINs, and LLDP-MED location=0D=0A> >  > information tel= ls the client=0D=0Athis ELIN, what is the client
=0D=0A<= font face=3D"Courier New">supposed
=0D=0A> to
=0D=0A>= ; >  > do=3F
=0D=0A> >  >
=0D=0A&= gt; >  > cheers
=0D=0A> >  > karl heinz
=0D=0A> >  >
=0D=0A> >  > On Nov 12, 2007 10:03 AM, Winterbottom, James
=0D=0A> >  >=0D=0A<James.Winterbott= om@andrew.com> wrote:
=0D=0A> >  > >
=0D=0A> >  > > An ELIN is a specific=0D=0A= callback number that represents an area
=0D=0Ain an
=0D=0A= > >  MLTS
=0D=0A&g= t; >  > > (Multi-Line Telephone=0D=0ASystem). As far as I kno= w they are only
=0D=0Aused
=0D=0A> >  in=
=0D=0A> >  > > the= USA. The=0D=0Afollowing description may not be 100% righ= t, but
=0D=0Ait is
=0D=0A> >  > > pretty = close.
=0D=0A> >  = > >
=0D=0A> > &nb= sp;> > Essentially if you have=0D=0Aa company or campus that occupies= a
=0D=0Alarge=0D=0A> >  area,
=0D= =0A> >  > > you can break t= his up=0D=0Ainto smaller areas to make it easier for
=0D=0A<= tt>> >  emergency
=0D=0A= > >  > > service crews to f= ind=0D=0Apeople. In some States this is mandated
=0D=0A<= font face=3D"Courier New">when
=0D=0A> >  the
=0D=0A> >  > > area becomes more than a=0D=0Acertain size (= 8000 sqr feet is
=0D=0Acommon= ly
=0D=0A> >  >= > quoted). Generally what=0D=0Ahappens is that all telephone
=0D=0Aextensions in
=0D=0A= > >  a
=0D=0A<= font face=3D"Courier New">> >  > > certain area are=0D=0Aa= ssociated with what is called an ERL
=0D=0A(emergency
=0D=0AE= RL
=0D=0A> >  is
=0D=0A> >  > >= ; allocated an ELIN that=0D=0Aserves as the presented calling number=
=0D=0Ato
=0D=0A<= font face=3D"Courier New">> the
=0D=0A> >  > > PSAP for any extension=0D=0Aprovision= ed against the ERL. The PSAP is
=0D=0A> able
=0D=0A>= >  to
=0D=0A> >= ;  > > use the ELIN to get the=0D=0Afloor location and area serv= iced by a
=0D=0A> > &nb= sp;specific
=0D=0A> > &= nbsp;> > ELIN. The ELIN also=0D=0Aserves as the number that the PSAP = will
=0D=0A> callback
=0D=0A> >  in
=0D=0A> >  > > the c= ase of the call=0D=0Abeing dropped.
=0D=0A> >  > >
=0D=0A> >  > > To this extent the ELIN=0D=0Ais the= way in which LLDP-MED currently
=0D=0A> >  supports
=0D=0A> >  > > location by reference.=0D=0A> >  > >=
=0D=0A> >  > > Please l= et me know if=0D=0Athis isn't clear and I will try an
=0D=0A= clarify
=0D=0A> >  > > further.
=0D=0A<= font face=3D"Courier New">> >  > >
=0D=0A> >  > > Cheers=0D=0A> >  > > James
=0D=0A> >  > >
=0D=0A> >  > >= ;
=0D=0A> >  > = > > -----Original=0D=0AMessage-----
=0D=0A> >  > > > From: Karl Heinz=0D=0AWol= f [mailto:khwolf1@gmail.com]
=0D=0A> >  > > > Sent: Monday, 12=0D=0ANovember 2007 7:= 23 PM
=0D=0A> >  &= gt; > > To: ECRIT
=0D=0A> >  > > > Subject: [Ecrit]=0D=0AELIN
=0D= =0A> >  > > >
=0D=0A> >  > > > LL= DP-MED supports=0D=0Anot just civic and coordinate based
=0D= =0Alocation
=0D=0A> >  > > > information, but=0D=0Aal= so an ELIN. How does this type of location
=0D=0A> >  > > > information fit to=0D=0A= the IETF Framework=3F Is this case
=0D=0Aconsidered in
=0D=0A> >  any
=0D=0A= > >  > > > document=3F
=0D=0A> >  > > > I couldn't find any=0D=0A= information on how to proceed with this
=0D=0Atype
=0D=0A&= gt; >  of
=0D=0A> = >  > > > location=0D=0Ainformation.
=0D=0A<= tt>> >  > > >=0D=0A> >  > > > cheers=
=0D=0A> >  > &= gt; > Karl Heinz
=0D=0A>= ; >  > > >
=0D=0A> >  > > >=0D=0A__________________________________= _____________
=0D=0A> >=  > > > Ecrit mailing list
=0D=0A> >  > > > Ecrit@ietf.org=
=0D=0A> >  > > >=0D=0A= https://www1.ietf.org/mailman/listinfo/ecrit
=0D=0A> >  > >
=0D=0A> >  > >
=0D=0A> >
=0D=0A-------------------------------------------------------------= ----------
=0D=0A> -
=0D=0A> >  > -------= -----------------
=0D=0A> = >  > > This message is for the=0D=0Adesignated recipient only= and may
=0D=0A> > &nbs= p;> > contain privileged,=0D=0Aproprietary, or otherwise private
=0D=0Ainformation.=0D=0A> >  > > If you have= received it=0D=0Ain error, please notify the sender
=0D=0A<= tt>> >  > > immediately and del= ete=0D=0Athe original.  Any unauthorized use of
=0D=0A<= tt>> >  > > this email is=0D=0A= prohibited.
=0D=0A> > &= nbsp;> >
=0D=0A> >= ;
=0D=0A---------------------= --------------------------------------------------
=0D=0A> -
=0D=0A> >  > ------------------------
=0D= =0A> >  > > [mf2]
=0D=0A> >  > >=
=0D=0A> >  > >
=0D=0A> >
=0D= =0A> >
=0D=0A> >
=0D=0A-------------------------------------------------------------------= -----
=0D=0A> ------------= ------------
=0D=0A> > =  This message is for the designated=0D=0Arecipient only and may=
=0D=0A> >  contain privi= leged, proprietary,=0D=0Aor otherwise private information.
=0D= =0A> >  If you have received it i= n error,=0D=0Aplease notify the sender
=0D=0A> >  immediately and delete the=0D=0Aoriginal. &nb= sp;Any unauthorized use of
=0D=0A> >  this email is prohibited.
=0D=0A> >
=0D=0A> >
=0D=0A---= ---------------------------------------------------------------------
=0D=0A> -----------------------= -
=0D=0A> >  [mf2]=
=0D=0A> ><= br>=0D=0A> >
=0D=0A= > >=0D=0A ___________________________= ____________________
=0D=0A&g= t; >  Ecrit mailing list
=0D=0A> >  Ecrit@ietf.org
=0D=0A> >  https://www1.ietf.org/mailman/listinfo/ec= rit
=0D=0A> >
=0D=0A> >
=0D=0A<= tt>>
=0D=0A>=0D=0A_______________________________________________
=0D=0A> Ecrit mailing list
=0D=0A> Ecrit@ietf.org=
=0D=0A> https://www1.ietf.org/ma= ilman/listinfo/ecrit
=0D=0A
=0D=0A
=0D=0A_______________________________________________
=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org
=0D=0A= https://www1.ietf.org/mailman/listinfo/ecrit=
=0D=0A
=0D=0A------------= ---------------------------------------------------------------------------= ---------
=0D=0AThis message = is for the designated recipient only=0D=0Aand may
=0D=0A= contain privileged, proprietary, or otherwise=0D= =0Aprivate information.  
=0D=0AIf you have received it in error, please notify=0D=0Athe sender
=0D=0Aimmediately and delete the= original.  Any=0D=0Aunauthorized use of
=0D=0Athis email is prohibited.
=0D=0A<= font face=3D"Courier New">-------------------------------------------------= -----------------------------------------------
=0D=0A[mf2]
=0D=0A
=0D=0A

=0D=0A=0D=0A
=0D=0A=0D=0A


---------------------------------------= ---------------------------------------------------------
=0D=0AThis&nbs= p;message is for the designated recipient onl= y and may
=0D=0Acontain privileged, proprietary,&nbs= p;or otherwise private information.  
=0D=0AIf&= nbsp;you have received it in error, please&nb= sp;notify the sender
=0D=0Aimmediately and delete&nb= sp;the original.  Any unauthorized use of
=0D= =0Athis email is prohibited.
=0D=0A----------------------= --------------------------------------------------------------------------<= br>=0D=0A[mf2]
=0D=0A=0D=0A=0D=0A ------_=_NextPart_001_01C82812.62C72732-- --===============0517319497== 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 --===============0517319497==-- From ecrit-bounces@ietf.org Fri Nov 16 00:36:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Istso-0004bR-St; Fri, 16 Nov 2007 00:36:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Istso-0004Zy-5U for ecrit@ietf.org; Fri, 16 Nov 2007 00:36:50 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IstsZ-0002Xw-Vt for ecrit@ietf.org; Fri, 16 Nov 2007 00:36:50 -0500 X-SEF-Processed: 5_0_0_910__2007_11_15_23_47_11 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 15 Nov 2007 23:47:11 -0600 Received: from AOPEX4.andrew.com ([10.86.20.22]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Nov 2007 23:36:34 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ecrit] ELIN Date: Thu, 15 Nov 2007 23:36:30 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] ELIN Thread-Index: AcglXemnDyxD+ER4TmC+AQnwqXuvAACqtj4g References: <3036F4A94122BD4AAAAB441FE8884528791166@300815ANEX3.global.avaya.com> From: "Dawson, Martin" To: , "Rodrig, Benny (Benny)" X-OriginalArrivalTime: 16 Nov 2007 05:36:34.0549 (UTC) FILETIME=[A659E250:01C82812] X-Spam-Score: 3.5 (+++) X-Scan-Signature: 0634ec58aad05a6aa9ac7d4670be9c6c 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="===============0983734506==" Errors-To: ecrit-bounces@ietf.org This is a multi-part message in MIME format. --===============0983734506== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C82812.A6479F02" This is a multi-part message in MIME format. ------_=_NextPart_001_01C82812.A6479F02 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well - if having an opinion equates to self-serving then "guilty as=0D=0Ach= arged"; it certainly doesn't make me Robinson Crusoe in this forum.=0D=0A=0D= =0A=20=0D=0A=0D=0AAll I mean is that the ELIN, being a fairly North America= n and=0D=0Aapplication specific parameter seems somewhat out of place in a = general=0D=0Alink layer spec. As has been noted, it's pretty much a referen= ce (though=0D=0Anot an invitation to a callback as used with HELD) - and pr= obably not=0D=0Aeven the ELIN the private switch will use since it needs to= consider the=0D=0Adynamics of how many calls are originating. As such, I w= ould have=0D=0Athought that the switch and port identity available through = standard=0D=0ALLDP (sans MED) would have served the same purpose. I didn't = say it=0D=0Aisn't "convenient".=0D=0A=0D=0A=20=0D=0A=0D=0ACheers,=0D=0A=0D=0A= Martin=0D=0A=0D=0A=20=0D=0A=0D=0A________________________________=0D=0A=0D=0A= From: peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]=20=0D= =0ASent: Tuesday, 13 November 2007 5:58 AM=0D=0ATo: Rodrig, Benny (Benny)=0D= =0ACc: ECRIT=0D=0ASubject: RE: [Ecrit] ELIN=0D=0A=0D=0A=20=0D=0A=0D=0A=0D=0A= Hi again, and thanks for the further input Benny,=20=0D=0A=0D=0AYes, I cert= ainly agree (contrary to Martin's obviously inflammatory and=0D=0Aself-serv= ing comments earlier) that LLDP-MED can make a very good,=0D=0Asimple solut= ion in many situations. And many of those scenarios need to=0D=0Aaddress w= orking with traditional E911 systems, hence inclusion of ELIN=0D=0Ain LLDP-= MED. For better or worse, interworking with pre-existing ECS=0D=0Asystems = such as E911 is not a part of ECRIT's mandate, hence is not=0D=0Adescribed = in any ECRIT document, or anywhere in IETF for that matter.=0D=0A=0D=0A=0D=0A= LLDP-MED only defines the protocol and exchange of TLVs. The usage is=0D=0A= defined in other documents.=20=0D=0A=0D=0AFor a bit more background on this= , and how it can play in to the=0D=0Aapplication level, see also TIA's TSB-= 146-A which describes several=0D=0Anetwork topologies and possible solution= s to the emergency call location=0D=0Aproblem, as well as others pieces of = the puzzle. Note that this=0D=0Adocument was not intended to define any pa= rticular solution, but to=0D=0Adiscuss a range of alternatives. Although r= ecently updated (in March=0D=0A07) it is also a second revision with the fi= rst dating several years=0D=0Aback now (2004 I believe). Available at:=20=0D= =0A=20=0D=0Ahttp://www.tiaonline.org/standards/technology/voip/documents/TS= B-146-AFi=0D=0AnalforPublication.pdf=20=0D=0A(You will likely be asked to f= ill in some info and press [I agree]=0D=0Abutton on the way.) =20=0D=0A=0D= =0ASee also DSL Forum draft WT-164 recently posted to this list, which=0D=0A= shows device startup state diagrams including LLDP-MED, DHCP and HELD.=0D=0A=0D= =0A=0D=0ACheers,=20=0D=0APeter Blatherwick=20=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D= =0A=20=0D=0A=0D=0A"Rodrig, Benny (Benny)" =20=0D=0A=0D=0A= 12.11.07 11:47=20=0D=0A=0D=0A =20=0D=0A To: , "Karl Heinz Wolf"=0D=0A, "Winterbott= om, James"=0D=0A=20=0D=0A cc: = "ECRIT" =20=0D=0A Subject: RE: [Ecrit] ELIN=0D= =0A=0D=0A=0D=0A=0D=0A=0D=0AAnother point to add is that when an endpoint mo= ves within the=0D=0Acampus/enterprise, a different ELIN may have to be pass= ed to the PSAP=0D=0Awith the emergency call, depending on the endpoint's lo= cation. To figure=0D=0Athis out automatically, getting the right ELIN direc= tly from the local=0D=0Anetwork via LLDP-MED can be a good solution.=20=0D=0A= =20=0D=0ARegarding the callback point below - I think the ELIN is typicall= y used=0D=0Aas the callback number, and the MLTS can then either forward th= e=0D=0Acallback to the original caller or to a designated responder e.g. th= e=0D=0Asecurity desk.=20=0D=0A =20=0D=0ABenny=20=0D=0A=0D=0A_______________= _________________=0D=0A=0D=0AFrom: peter_blatherwick@mitel.com [mailto:pete= r_blatherwick@mitel.com]=20=0D=0ASent: Monday, November 12, 2007 11:09 AM=0D= =0ATo: Karl Heinz Wolf; Winterbottom, James=0D=0ACc: ECRIT=0D=0ASubject: RE= : [Ecrit] ELIN=0D=0A=0D=0A=0D=0AHi Karl, =20=0D=0AJames' description earli= er on how ELIN works is essentially correct. A=0D=0Acouple of added bits: =0D= =0A=0D=0A- ELIN can also be used for ECS call routing. If the call gets pl= aced=0D=0Aon an out of district GW, it can be used in PSTN to route to the = correct=0D=0A(in district) PSAP. =20=0D=0A=0D=0A- At the PSAP, ELIN is eff= ectively a dB index to look up details on the=0D=0Asource of the call, base= d on ERL data that is provisioned in the PSAP dB=0D=0A(street location, in-= building location, etc etc)=20=0D=0A=0D=0A- I don't *think* ELIN is general= ly used as the callback number. In=0D=0AISDN-based signalling, there is bo= th the ELIN and a callback number. I=0D=0A*think* the PSAP side is (or can= be) provisioned with callback=0D=0Acorresponding to the ELIN in its dB. T= he callback number is typically=0D=0Anot an extension, but a designated res= ponder within the enterprise at=0D=0Athat location, e.g. the security desk.= Perhaps others on the list with=0D=0Adirect experience can comment on thi= s point=3F =20=0D=0A=0D=0A> ... all extensions with the same ELIN need to = be close to one another.=0D=0A=0D=0AYes, all extensions with the same ELIN = *will* be physically close=0D=0Atogether. But this is not directly related= to callback. It is by=0D=0Adefinition of what the ERL is -- it is a small= enough region in a=0D=0Abuilding to allow emergency responders to find som= eone. =20=0D=0A=0D=0A> ... what the client does when its gets the ELIN fro= m LLDP-MED I have=0D=0Ano idea=20=0D=0AELIN was added to LLDP-MED for compl= eteness and for compatibility with=0D=0Aexisting PSTN infrastructure. Sinc= e existing E911 systems in N.A. use=0D=0AELIN today, there was no easy way = to support it with Civic and Geo types=0D=0Aonly. (I am a little surprised= ELIN type has not been defined in IETF=0D=0Aas well ... but that's another= story.) Thinking was that the device=0D=0Acould receive ELIN, pass it in = SIP signalling towards PSTN GW, that=0D=0Awould then insert the ELIN into P= STN trunk signalling. I do not know if=0D=0Aanyone uses it this way. =20=0D= =0A=0D=0A> To this extent the ELIN is the way in which LLDP-MED currently=0D= =0Asupports=0D=0A> location by reference.=20=0D=0AYes, ELIN is effectively = a form of location-by-reference. LLDP-MED can=0D=0Aalso be readily extende= d to support LbyR in the sense used in Geopriv /=0D=0AECRIT as well. Since= location objects are directly supplied by the=0D=0Anetwork infrastructure = in LLDP-MED's case, it is not entirely clear to=0D=0Ame why LbyR would real= ly be needed / useful for LLDP-MED deployments. =20=0D=0A=0D=0ACheers,=20=0D= =0APeter Blatherwick=20=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=20=0D=0A=0D=0A"= Winterbottom, James" =20=0D=0A=0D=0A12.11.07= 04:46=20=0D=0A=0D=0A =20=0D=0A To: "Karl Heinz Wolf" =20=0D=0A cc: ECRIT =20=0D=0A= Subject: RE: [Ecrit] ELIN=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= Hi Karl Heinz,=0D=0A=0D=0AIt is the only the extension that actually has th= e ELIN number that gets=0D=0Acalled back. So all extensions with the same E= LIN need to be close to=0D=0Aone another.=0D=0A=0D=0AAs to what the client = does when its gets the ELIN from LLDP-MED I have=0D=0Ano idea... *8)=0D=0A=0D= =0ACheers=0D=0AJames=0D=0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> F= rom: Karl Heinz Wolf [mailto:khwolf1@gmail.com]=0D=0A> Sent: Monday, 12 Nov= ember 2007 8:31 PM=0D=0A> To: Winterbottom, James=0D=0A> Cc: ECRIT=0D=0A> S= ubject: Re: [Ecrit] ELIN=0D=0A>=20=0D=0A> Hi James!=0D=0A>=20=0D=0A> Thank = you for your detailed description of the ELIN.=0D=0A> One more question: ho= w does the callback from the PSAP work, if there=0D=0A> are multiple extens= ions with the same ELIN=3F=0D=0A>=20=0D=0A> Anyway, in case a company uses = ELINs, and LLDP-MED location=0D=0A> information tells the client this ELIN,= what is the client supposed to=0D=0A> do=3F=0D=0A>=20=0D=0A> cheers=0D=0A>= karl heinz=0D=0A>=20=0D=0A> On Nov 12, 2007 10:03 AM, Winterbottom, James=0D= =0A> wrote:=0D=0A> > Hi Karl Heinz,=0D=0A> = >=0D=0A> > An ELIN is a specific callback number that represents an area in= an=0D=0AMLTS=0D=0A> > (Multi-Line Telephone System). As far as I know they= are only used=0D=0Ain=0D=0A> > the USA. The following description may not = be 100% right, but it is=0D=0A> > pretty close.=0D=0A> >=0D=0A> > Essential= ly if you have a company or campus that occupies a large=0D=0Aarea,=0D=0A> = > you can break this up into smaller areas to make it easier for=0D=0Aemerg= ency=0D=0A> > service crews to find people. In some States this is mandated= when=0D=0Athe=0D=0A> > area becomes more than a certain size (8000 sqr fee= t is commonly=0D=0A> > quoted). Generally what happens is that all telephon= e extensions in=0D=0Aa=0D=0A> > certain area are associated with what is ca= lled an ERL (emergency=0D=0A> > resource location), this is done in the PAB= X provisioning. Each ERL=0D=0Ais=0D=0A> > allocated an ELIN that serves as = the presented calling number to the=0D=0A> > PSAP for any extension provisi= oned against the ERL. The PSAP is able=0D=0Ato=0D=0A> > use the ELIN to get= the floor location and area serviced by a=0D=0Aspecific=0D=0A> > ELIN. The= ELIN also serves as the number that the PSAP will callback=0D=0Ain=0D=0A> = > the case of the call being dropped.=0D=0A> >=0D=0A> > To this extent the = ELIN is the way in which LLDP-MED currently=0D=0Asupports=0D=0A> > location= by reference.=0D=0A> >=0D=0A> > Please let me know if this isn't clear and= I will try an clarify=0D=0A> > further.=0D=0A> >=0D=0A> > Cheers=0D=0A> > = James=0D=0A> >=0D=0A> >=0D=0A> > > -----Original Message-----=0D=0A> > > Fr= om: Karl Heinz Wolf [mailto:khwolf1@gmail.com]=0D=0A> > > Sent: Monday, 12 = November 2007 7:23 PM=0D=0A> > > To: ECRIT=0D=0A> > > Subject: [Ecrit] ELIN=0D= =0A> > >=0D=0A> > > LLDP-MED supports not just civic and coordinate based l= ocation=0D=0A> > > information, but also an ELIN. How does this type of loc= ation=0D=0A> > > information fit to the IETF Framework=3F Is this case cons= idered in=0D=0Aany=0D=0A> > > document=3F=0D=0A> > > I couldn't find any in= formation on how to proceed with this type=0D=0Aof=0D=0A> > > location info= rmation.=0D=0A> > >=0D=0A> > > cheers=0D=0A> > > Karl Heinz=0D=0A> > >=0D=0A= > > > _______________________________________________=0D=0A> > > Ecrit mail= ing list=0D=0A> > > Ecrit@ietf.org=0D=0A> > > https://www1.ietf.org/mailman= /listinfo/ecrit=0D=0A> >=0D=0A> >=0D=0A------------------------------------= ------------------------------------=0D=0A> ------------------------=0D=0A>= > This message is for the designated recipient only and may=0D=0A> > conta= in privileged, proprietary, or otherwise private information.=0D=0A> > If y= ou have received it in error, please notify the sender=0D=0A> > immediately= and delete the original. Any unauthorized use of=0D=0A> > this email is p= rohibited.=0D=0A> >=0D=0A--------------------------------------------------= ----------------------=0D=0A> ------------------------=0D=0A> > [mf2]=0D=0A= > >=0D=0A> >=0D=0A=0D=0A---------------------------------------------------= ---------------------=0D=0A------------------------=0D=0AThis message is fo= r the designated recipient only and may=0D=0Acontain privileged, proprietar= y, or otherwise private information. =20=0D=0AIf you have received it in er= ror, please notify the sender=0D=0Aimmediately and delete the original. An= y unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----------------= -------------------------------------------------------=0D=0A--------------= ----------=0D=0A[mf2]=0D=0A=0D=0A=0D=0A____________________________________= ___________=0D=0AEcrit mailing list=0D=0AEcrit@ietf.org=0D=0Ahttps://www1.i= etf.org/mailman/listinfo/ecrit=0D=0A=0D=0A---------------------------------= ---------------------------------------------------------------=0D=0AThis m= essage is for the designated recipient only and may=0D=0Acontain privileged= , proprietary, or otherwise private information. =20=0D=0AIf you have recei= ved it in error, please notify the sender=0D=0Aimmediately and delete the o= riginal. Any unauthorized use of=0D=0Athis email is prohibited.=0D=0A-----= ---------------------------------------------------------------------------= ----------------=0D=0A[mf2]=0D=0A ------_=_NextPart_001_01C82812.A6479F02 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=0D=0A= =0D=0A=0D=0A=0D=0A=0D=0A=


----------= ---------------------------------------------------------------------------= -----------
=0D=0AThis message is for the desig= nated recipient only and may
=0D=0Acontain priv= ileged, proprietary, or otherwise private informat= ion.  
=0D=0AIf you have received it = in error, please notify the sender
=0D=0Aimmedi= ately and delete the original.  Any unau= thorized use of
=0D=0Athis email is prohibited.=
=0D=0A-----------------------------------------------------------------= -------------------------------
=0D=0A[mf2]
=0D=0A=0D= =0A=0D=0A ------_=_NextPart_001_01C828C9.9F1E11F0-- --===============1832070491== 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 --===============1832070491==-- From ecrit-bounces@ietf.org Sun Nov 18 21:36:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwUm-0007bp-Bu; Sun, 18 Nov 2007 21:36:20 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwUk-0007bj-Fz for ecrit@ietf.org; Sun, 18 Nov 2007 21:36:18 -0500 Received: from ebru.winwebhosting.com ([74.52.236.50]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ItwUj-0006n8-Ka for ecrit@ietf.org; Sun, 18 Nov 2007 21:36:18 -0500 Received: from [209.173.53.233] (helo=BROSLT41xp) by ebru.winwebhosting.com with esmtpa (Exim 4.68) (envelope-from ) id 1ItwUR-0000Fj-Sr; Sun, 18 Nov 2007 20:36:01 -0600 From: "Brian Rosen" To: "'Stark, Barbara'" , "'ECRIT'" References: <7582BC68E4994F4ABF0BD4723975C3FA0654C5F4@crexc41p> Subject: RE: [Ecrit] Additional framework-03 and phonebcp-02 comments Date: Sun, 18 Nov 2007 21:36:08 -0500 Message-ID: <0d9a01c82a54$f59b1520$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 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Thread-Index: AcggwW0S71bAYSoLSpS6udXkqxQHXwJkUkOw In-Reply-To: <7582BC68E4994F4ABF0BD4723975C3FA0654C5F4@crexc41p> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.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: d2b46e3b2dfbff2088e0b72a54104985 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 Barbara Thank you for these suggestions, and especially for proposing text. I have implemented all of them one way or another except the following two: You suggested that devices need their own IP addresses. I don't know what that is for: HELD doesn't have a parameter for the identifier, it uses the IP address in the request. > After ED-27: > New: ED-xx If a location refresh fails (that just attempts to use the > last successful method), the endpoint MUST attempt all location > configuration options. If the location can still not be determined, the > endpoint MUST continue to use its last known location. I don't think that is right. Trying HELD if you got DHCP to work will take MANY seconds to time out. I think you probably just use the cached location. Brian > -----Original Message----- > From: Stark, Barbara [mailto:bs7652@att.com] > Sent: Tuesday, November 06, 2007 5:08 PM > To: ECRIT > Subject: [Ecrit] Additional framework-03 and phonebcp-02 comments > > Brian and I had a little chat at the Emergency Services Workshop, and I > agreed to provide some suggestions for additions to phonebcp, to bring > into it some more of the details that are currently in the DSL Forum > WT-164 text. > > Here's a summary of what the comments in this email are about: > - Address non-SIP intermediary devices (ie, routers) better. AN-12 is > awkward, since the home router isn't really a part of the access > network. Also address case where calling application is distinct from > OS, and cannot control the OS. Need to improve terminology section to > better describe these. > - LIS and LoST server determination > - DHCP INFORM usage > Not included in this email are the detailed flows. If others want them > added to phonebcp, we should discuss. I'm not sure how those would get > translated to an IETF document. > > Terminology > Need to define ED, AN, SP abbreviations: > ED - the User Equipment (UE) of ecrit-requirements > AN - the Access Network of ecrit-framework > SP - the ASP (of which VSP is a subset) of ecrit-requirements > > Add a new device type of "INT" for Intermediary Device > Need to define this uniquely within phonebcp, since it's not defined > elsewhere. Or else define in framework and describe its role in a > subsection of 6.2 Location Determination. It would probably need to be > defined as a device that is in close proximity to the ED (within a > "small area") and provides a NAPT function between the WAN and the LAN > that the ED is in. In general, it will also provide DHCP server > functionality, and may have DHCP client capability on its WAN side. > While it is possible for the emergency framework to work without > upgrading most legacy intermediary devices, the possibility of failure > is decreased when these devices are upgraded to support the > functionality identified in phonebcp. > > The following phonebcp requirements would apply to an INT: > ED-12 through ED-27, AN-1 through AN-3, AN-5, AN-6, AN-11, AN-13, AN-16 > > After ED-21, there needs to be a requirement that defines the > recommended defaults for parameters in a HELD request. My previous email > gave suggestions for responseTime. It may also be useful (but may not be > necessary) to suggest that the default for all other parameters SHOULD > be null. > > New: The device MUST support a random back-off period (between 30 > seconds and 300 seconds) for re-trying the HELD query, when no response > is received. > > New: ED-xx If the device is configured to use DHCP for bootstrapping, > it MUST include both options for location acquisition (civic and > geodetic), the option for LIS discovery, and the option for LoST > discovery as required in [requirement references]. > > New: ED-xx If the device sends a DHCP INFORM message, it MUST include > both options for location acquisition (civic and geodetic), the option > for LIS discovery, and the option for LoST discovery as required in > [requirement references]. > > Change AN-12 to an INT requirement. > > In ED-24, I recommend changing "non-bypassable VPNs" to "VPNs that do > not allow split tunneling" to use more standard jargon. > > --- new section --- Need a section on LIS and LoST Discovery > New: ED-xx Endpoints MUST support one or more mechanisms that allow > them to determine their public IP address. Examples include ICE and HTTP > get. > > New: ED-xx Endpoints MUST support LIS discovery as described in > [LIS-DISCOVERY], and the LoST discovery as described in > [LOST-DISCOVERY]. [need to add these references, see below] > > New: ED-xx The device MUST have a configurable default LoST server > parameter. If the device is provided by or managed by an Application > Service Provider (ASP), such as a Voice Service Provider (VSP), it is > expected that the ASP will configure this option. > ---- end new section--- > > After ED-27: > New: ED-xx If a location refresh fails (that just attempts to use the > last successful method), the endpoint MUST attempt all location > configuration options. If the location can still not be determined, the > endpoint MUST continue to use its last known location. > > --- new section --- Need a section for requirements for OSs, and for > applications running on OSs that provide location to apps. Also, > requirements for apps running on OSs that don't provide location, and > where the app can't control LLDP or DHCP. > > ??-xx If the client that needs the location information is unable to > control Layer 2 and 3 protocols, then that client application MUST > attempt to get location, LIS, and/or LoST information from the OS, > before proceeding with location acquisition using HELD. > > ??-xx In many cases, Operating Systems (OSs) will need to do location > configuration for applications that run on top of them. The following > requirements apply to such OSs: ED-12 through ED-18 and ED-21 through > ED-27. (ED-20 doesn't seem like it applies to an OS?) > > ??-xx OSs that do location configuration operations on behalf of > applications MUST provide a published interface for applications to get > their location information from the OS. > ---- end new section--- > > ED-48: add phrase at end of reqt "...whenever they get an initial or > updated location." > > Additional References > [lost-discovery] Schulzrinne, H., J. Polk, and H. Tschofenig, "A Dynamic > Host Configuration Protocol (DHCP) based Location-to-Service Translation > Protocol (LoST) Discovery Procedure", > draft-ietf-ecrit-dhc-lost-discovery-02, July 2007 > > [lis-discovery] Thomson, M. and J. Winterbottom, "Discovering the Local > Location Information Server (LIS)" > draft-thomson-geopriv-lis-discovery-03 (work in progress), September > 2007) > > _______________________________________________ > 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 Nov 18 21:42:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwaH-0000Yk-4Y; Sun, 18 Nov 2007 21:42:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ItwaF-0000YE-Lq for ecrit@ietf.org; Sun, 18 Nov 2007 21:41:59 -0500 Received: from smtp3.andrew.com ([198.135.207.235] helo=andrew.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ItwaB-0001bI-H5 for ecrit@ietf.org; Sun, 18 Nov 2007 21:41:59 -0500 X-SEF-Processed: 5_0_0_910__2007_11_18_20_52_33 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 18 Nov 2007 20:52:33 -0600 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 18 Nov 2007 20:41:53 -0600 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 Subject: RE: [Ecrit] Additional framework-03 and phonebcp-02 comments Date: Sun, 18 Nov 2007 20:41:51 -0600 Message-ID: In-Reply-To: <0d9a01c82a54$f59b1520$640fa8c0@cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Additional framework-03 and phonebcp-02 comments thread-index: AcggwW0S71bAYSoLSpS6udXkqxQHXwJkUkOwAAC9gIA= References: <7582BC68E4994F4ABF0BD4723975C3FA0654C5F4@crexc41p> <0d9a01c82a54$f59b1520$640fa8c0@cis.neustar.com> From: "Winterbottom, James" To: "Brian Rosen" , "Stark, Barbara" , "ECRIT" X-OriginalArrivalTime: 19 Nov 2007 02:41:53.0534 (UTC) FILETIME=[BE6B29E0:01C82A55] X-Spam-Score: 1.8 (+) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Brian,=0D=0A=0D=0AHELD can use the HELD Identity extensions specification t= hat support=0D=0Aproviding that information.=0D=0A=0D=0ACheers=0D=0AJames=0D= =0A=0D=0A=0D=0A> -----Original Message-----=0D=0A> From: Brian Rosen [mailt= o:br@brianrosen.net]=0D=0A> Sent: Monday, 19 November 2007 1:36 PM=0D=0A> T= o: 'Stark, Barbara'; 'ECRIT'=0D=0A> Subject: RE: [Ecrit] Additional framewo= rk-03 and phonebcp-02 comments=0D=0A>=20=0D=0A> Barbara=0D=0A>=20=0D=0A> Th= ank you for these suggestions, and especially for proposing text. I=0D=0A>= have=0D=0A> implemented all of them one way or another except the followin= g two:=0D=0A>=20=0D=0A> You suggested that devices need their own IP addres= ses. I don't know=0D=0Awhat=0D=0A> that is for: HELD doesn't have a parame= ter for the identifier, it uses=0D=0Athe=0D=0A> IP address in the request.=0D= =0A>=20=0D=0A> > After ED-27:=0D=0A> > New: ED-xx If a location refresh fa= ils (that just attempts to use=0D=0Athe=0D=0A> > last successful method), t= he endpoint MUST attempt all location=0D=0A> > configuration options. If th= e location can still not be determined,=0D=0Athe=0D=0A> > endpoint MUST con= tinue to use its last known location.=0D=0A> I don't think that is right. = Trying HELD if you got DHCP to work will=0D=0A> take=0D=0A> MANY seconds to= time out. I think you probably just use the cached=0D=0A> location.=0D=0A= >=20=0D=0A> Brian=0D=0A>=20=0D=0A> > -----Original Message-----=0D=0A> > Fr= om: Stark, Barbara [mailto:bs7652@att.com]=0D=0A> > Sent: Tuesday, November= 06, 2007 5:08 PM=0D=0A> > To: ECRIT=0D=0A> > Subject: [Ecrit] Additional f= ramework-03 and phonebcp-02 comments=0D=0A> >=0D=0A> > Brian and I had a li= ttle chat at the Emergency Services Workshop,=0D=0Aand I=0D=0A> > agreed to= provide some suggestions for additions to phonebcp, to=0D=0Abring=0D=0A> >= into it some more of the details that are currently in the DSL Forum=0D=0A= > > WT-164 text.=0D=0A> >=0D=0A> > Here's a summary of what the comments in= this email are about:=0D=0A> > - Address non-SIP intermediary devices (ie= , routers) better. AN-12=0D=0Ais=0D=0A> > awkward, since the home router is= n't really a part of the access=0D=0A> > network. Also address case where c= alling application is distinct=0D=0Afrom=0D=0A> > OS, and cannot control th= e OS. Need to improve terminology section=0D=0Ato=0D=0A> > better describe = these.=0D=0A> > - LIS and LoST server determination=0D=0A> > - DHCP INFOR= M usage=0D=0A> > Not included in this email are the detailed flows. If othe= rs want=0D=0Athem=0D=0A> > added to phonebcp, we should discuss. I'm not su= re how those would=0D=0Aget=0D=0A> > translated to an IETF document.=0D=0A>= >=0D=0A> > Terminology=0D=0A> > Need to define ED, AN, SP abbreviations:=0D= =0A> > ED - the User Equipment (UE) of ecrit-requirements=0D=0A> > AN - the= Access Network of ecrit-framework=0D=0A> > SP - the ASP (of which VSP is a= subset) of ecrit-requirements=0D=0A> >=0D=0A> > Add a new device type of "= INT" for Intermediary Device=0D=0A> > Need to define this uniquely within p= honebcp, since it's not defined=0D=0A> > elsewhere. Or else define in frame= work and describe its role in a=0D=0A> > subsection of 6.2 Location Determi= nation. It would probably need to=0D=0Abe=0D=0A> > defined as a device that= is in close proximity to the ED (within a=0D=0A> > "small area") and provi= des a NAPT function between the WAN and the=0D=0ALAN=0D=0A> > that the ED i= s in. In general, it will also provide DHCP server=0D=0A> > functionality, = and may have DHCP client capability on its WAN side.=0D=0A> > While it is p= ossible for the emergency framework to work without=0D=0A> > upgrading most= legacy intermediary devices, the possibility of=0D=0Afailure=0D=0A> > is d= ecreased when these devices are upgraded to support the=0D=0A> > functional= ity identified in phonebcp.=0D=0A> >=0D=0A> > The following phonebcp requir= ements would apply to an INT:=0D=0A> > ED-12 through ED-27, AN-1 through AN= -3, AN-5, AN-6, AN-11, AN-13,=0D=0AAN-16=0D=0A> >=0D=0A> > After ED-21, the= re needs to be a requirement that defines the=0D=0A> > recommended defaults= for parameters in a HELD request. My previous=0D=0Aemail=0D=0A> > gave sug= gestions for responseTime. It may also be useful (but may=0D=0Anot be=0D=0A= > > necessary) to suggest that the default for all other parameters=0D=0ASH= OULD=0D=0A> > be null.=0D=0A> >=0D=0A> > New: The device MUST support a ran= dom back-off period (between 30=0D=0A> > seconds and 300 seconds) for re-tr= ying the HELD query, when no=0D=0Aresponse=0D=0A> > is received.=0D=0A> >=0D= =0A> > New: ED-xx If the device is configured to use DHCP for=0D=0Abootstr= apping,=0D=0A> > it MUST include both options for location acquisition (civ= ic and=0D=0A> > geodetic), the option for LIS discovery, and the option for= LoST=0D=0A> > discovery as required in [requirement references].=0D=0A> >=0D= =0A> > New: ED-xx If the device sends a DHCP INFORM message, it MUST=0D=0A= include=0D=0A> > both options for location acquisition (civic and geodetic)= , the=0D=0Aoption=0D=0A> > for LIS discovery, and the option for LoST disco= very as required in=0D=0A> > [requirement references].=0D=0A> >=0D=0A> > Ch= ange AN-12 to an INT requirement.=0D=0A> >=0D=0A> > In ED-24, I recommend c= hanging "non-bypassable VPNs" to "VPNs that=0D=0Ado=0D=0A> > not allow spli= t tunneling" to use more standard jargon.=0D=0A> >=0D=0A> > --- new section= --- Need a section on LIS and LoST Discovery=0D=0A> > New: ED-xx Endpoint= s MUST support one or more mechanisms that allow=0D=0A> > them to determine= their public IP address. Examples include ICE and=0D=0AHTTP=0D=0A> > get.=0D= =0A> >=0D=0A> > New: ED-xx Endpoints MUST support LIS discovery as describ= ed in=0D=0A> > [LIS-DISCOVERY], and the LoST discovery as described in=0D=0A= > > [LOST-DISCOVERY]. [need to add these references, see below]=0D=0A> >=0D= =0A> > New: ED-xx The device MUST have a configurable default LoST server=0D= =0A> > parameter. If the device is provided by or managed by an Application=0D= =0A> > Service Provider (ASP), such as a Voice Service Provider (VSP), it=0D= =0Ais=0D=0A> > expected that the ASP will configure this option.=0D=0A> > = ---- end new section---=0D=0A> >=0D=0A> > After ED-27:=0D=0A> > New: ED-xx = If a location refresh fails (that just attempts to use=0D=0Athe=0D=0A> > l= ast successful method), the endpoint MUST attempt all location=0D=0A> > con= figuration options. If the location can still not be determined,=0D=0Athe=0D= =0A> > endpoint MUST continue to use its last known location.=0D=0A> >=0D=0A= > > --- new section --- Need a section for requirements for OSs, and for=0D= =0A> > applications running on OSs that provide location to apps. Also,=0D=0A= > > requirements for apps running on OSs that don't provide location,=0D=0A= and=0D=0A> > where the app can't control LLDP or DHCP.=0D=0A> >=0D=0A> > =3F= =3F-xx If the client that needs the location information is unable=0D=0Ato=0D= =0A> > control Layer 2 and 3 protocols, then that client application MUST=0D= =0A> > attempt to get location, LIS, and/or LoST information from the OS,=0D= =0A> > before proceeding with location acquisition using HELD.=0D=0A> >=0D=0A= > > =3F=3F-xx In many cases, Operating Systems (OSs) will need to do=0D=0A= location=0D=0A> > configuration for applications that run on top of them. T= he=0D=0Afollowing=0D=0A> > requirements apply to such OSs: ED-12 through ED= -18 and ED-21=0D=0Athrough=0D=0A> > ED-27. (ED-20 doesn't seem like it appl= ies to an OS=3F)=0D=0A> >=0D=0A> > =3F=3F-xx OSs that do location configura= tion operations on behalf of=0D=0A> > applications MUST provide a published= interface for applications to=0D=0Aget=0D=0A> > their location information= from the OS.=0D=0A> > ---- end new section---=0D=0A> >=0D=0A> > ED-48: ad= d phrase at end of reqt "...whenever they get an initial or=0D=0A> > update= d location."=0D=0A> >=0D=0A> > Additional References=0D=0A> > [lost-discove= ry] Schulzrinne, H., J. Polk, and H. Tschofenig, "A=0D=0ADynamic=0D=0A> > H= ost Configuration Protocol (DHCP) based Location-to-Service=0D=0ATranslatio= n=0D=0A> > Protocol (LoST) Discovery Procedure",=0D=0A> > draft-ietf-ecrit-= dhc-lost-discovery-02, July 2007=0D=0A> >=0D=0A> > [lis-discovery] Thomson,= M. and J. Winterbottom, "Discovering the=0D=0ALocal=0D=0A> > Location Info= rmation Server (LIS)"=0D=0A> > draft-thomson-geopriv-lis-discovery-03 (work= in progress), September=0D=0A> > 2007)=0D=0A> >=0D=0A> > _________________= ______________________________=0D=0A> > Ecrit mailing list=0D=0A> > Ecrit@i= etf.org=0D=0A> > https://www1.ietf.org/mailman/listinfo/ecrit=0D=0A>=20=0D=0A= >=20=0D=0A> _______________________________________________=0D=0A> Ecrit ma= iling list=0D=0A> Ecrit@ietf.org=0D=0A> https://www1.ietf.org/mailman/listi= nfo/ecrit=0D=0A=0D=0A------------------------------------------------------= ------------------------------------------=0D=0AThis message is for the des= ignated recipient only and may=0D=0Acontain privileged, proprietary, or oth= erwise private information. =20=0D=0AIf you have received it in error, plea= se notify the sender=0D=0Aimmediately and delete the original. Any unautho= rized use of=0D=0Athis email is prohibited.=0D=0A--------------------------= ----------------------------------------------------------------------=0D=0A= [mf2]=0D=0A _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 19 01:00:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itzfv-0001Yj-0M; Mon, 19 Nov 2007 01:00:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Itzfu-0001XL-CG; Mon, 19 Nov 2007 01:00:02 -0500 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Itzfu-0007za-0X; Mon, 19 Nov 2007 01:00:02 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id E46E22AB68; Mon, 19 Nov 2007 06:00:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Itzft-0007gF-Qk; Mon, 19 Nov 2007 01:00:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 01:00:01 -0500 X-Spam-Score: -1.4 (-) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-phonebcp-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 : Best Current Practice for Communications Services in support of Emergency Calling Author(s) : B. Rosen, J. Polk Filename : draft-ietf-ecrit-phonebcp-03.txt Pages : 40 Date : 2007-11-19 The IETF and other standards organization have efforts targeted at standardizing various aspects of placing emergency calls on IP networks. This memo describes best current practice on how devices, networks and services should use such standards to make emergency calls. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-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-phonebcp-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-phonebcp-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: <2007-11-19005143.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-phonebcp-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-phonebcp-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19005143.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 Mon Nov 19 01:33:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu0CJ-0007YY-25; Mon, 19 Nov 2007 01:33:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu0CH-0007X4-OV; Mon, 19 Nov 2007 01:33:29 -0500 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu0CF-0000rh-CI; Mon, 19 Nov 2007 01:33:29 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id A9F41328F8; Mon, 19 Nov 2007 06:10:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1ItzpZ-0008RM-FH; Mon, 19 Nov 2007 01:10:01 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 19 Nov 2007 01:10:01 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ecrit@ietf.org Subject: [Ecrit] I-D Action:draft-ietf-ecrit-framework-04.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 : Framework for Emergency Calling using Internet Multimedia Author(s) : B. Rosen, et al. Filename : draft-ietf-ecrit-framework-04.txt Pages : 37 Date : 2007-11-19 The IETF has several efforts targeted at standardizing various aspects of placing emergency calls. This document describes how all of those component parts are used to support emergency calls from citizens and visitors to authorities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-04.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-framework-04.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-framework-04.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: <2007-11-19010941.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ecrit-framework-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ecrit-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-11-19010941.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 Mon Nov 19 09:12:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7Mk-0005do-V3; Mon, 19 Nov 2007 09:12:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7Mj-0005dX-G2 for ecrit@ietf.org; Mon, 19 Nov 2007 09:12:45 -0500 Received: from ns6.neustar.com ([156.154.16.88] helo=neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu7Mg-000452-9h for ecrit@ietf.org; Mon, 19 Nov 2007 09:12:45 -0500 Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.3040599; Mon, 19 Nov 2007 09:12:30 -0500 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: Mon, 19 Nov 2007 09:12:29 -0500 Message-ID: <31D151A3D66E404AACBBB0247ACA54A78BDDED@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New versions of -framework and -phonebcp Thread-Index: AcgqtjhIPBX+fi2rRZiP/TbxqKLuvA== From: "Rosen, Brian" To: "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Ecrit] New versions of -framework and -phonebcp 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 submitted new versions of both -framework and -phonebcp. I have addressed all of the comments I received on phonebcp and most of those against -framework. My day job has been sucking time lately so this was a rush job. Specifically, I did not renumber new requirements added to phonebcp, I did not make the appendix match the main body of the document, and I did not do some of the editorial fixes reported against framework. I did do the change requested by Barbara that creates a new class of entity with requirements: the "Intermediate" device. I'm not thrilled with that change. I await reviews on that particular change. I will do a clean-up edit pass shortly after Vancouver if the work group considers the documents pretty much ready for WGLC. There is one significant missing subject which is "location hiding". Hopefully we can agree on direction in Vancouver and I can add text covering it. Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 19 09:48:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7vD-0004wJ-Ki; Mon, 19 Nov 2007 09:48:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu7vC-0004vD-LL for ecrit@ietf.org; Mon, 19 Nov 2007 09:48:22 -0500 Received: from ns6.neustar.com ([156.154.16.88] helo=neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iu7v9-0006Kh-9Y for ecrit@ietf.org; Mon, 19 Nov 2007 09:48:22 -0500 Received: from ([10.31.13.50]) by stihiron2.va.neustar.com with ESMTP id 5202732.3041943; Mon, 19 Nov 2007 09:48:01 -0500 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: Mon, 19 Nov 2007 09:48:00 -0500 Message-ID: <31D151A3D66E404AACBBB0247ACA54A78BDE17@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Henning's comments on -phonebcp Thread-Index: Acgquy5f/jp/ML/JT+Ca6wQ5EEXMlA== From: "Rosen, Brian" To: , "ECRIT" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: Subject: [Ecrit] Henning's comments on -phonebcp 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 Prof Schulzrinne send me a marked up, scanned in edit of -phonebcp. I made most of the edits requested. There was a couple I did not do: 1. Henning and one or two other commenter's don't like my coarse location (<1KM). First of all, there is no real source for the 1 KM. I made it up. What you want is something with a high enough accuracy that the call will usually route to the right PSAP when you are near a boundary. It will never be 100% accurate. I needed to supply some useful advice. I picked a number. I have modified this text slightly (typically <1km except when hiding location).=20 2. On ED-27, about the frequency of refresh, Henning asked for text discussing that civic location may be an indication that the device is not mobile. Devices can be mobile and report civic. WiFi devices reporting the location of an AP may very well report civic. I did not change the text. 3. Henning raised some questions about default location. I changed the text to refer to -framework which does discuss this. Generally, it's "best you can do" and -framework uses the example of the location of a CMTS in a cable modem system. I'd welcome suggestions to improve this; it's an important area. 4. Notwithstanding Hannes' questioning of un-initialized device text, Henning raised the issue at ED-44 of how an un-initialized device determines if local regulation requires support of emergency calling. I think this is a good question. I suspect we need something returned from LoST that tells it. Discussion on this point is welcome.=20 5. Several commenters have questioned the discussion of proxy determination of local dialstrings. I have improved the text in this area, but suggestions for further improvement would be welcome. A system like IMS with a home/visited network, where the visited network provides the proxy work. Systems where the service provider has a relationship with the access network and thus the service provider always has location available work. This is a severe limitation; many systems can't meet it, which means they should get the endpoint to do the dial plan interpretation. I think the text says that, but improvement is probably useful. 6. Henning added the comment "dubious" to the text "User agents and proxies MUST Support Session Timer [RFC4028] to guard against session corruption." I do think we should have it. Henning, what is the "dubious" part. I can downgrade "guard against" to something milder if you are pointing out that session timers won't reliably determine session corruption. I can change corruption to some other term. 7. I'd ask Henning to expand on the "confusing" comment on ED-64 and the "don't understand" comment on ED-68. On the latter, the prior requirement is disabling of features on call backs. ED-68 is how you determine a call back, which I propose is simply a call from the same domain as the PSAP that answered the original emergency call. 8. I'd also like a little more information on the "check spec" comment on ED-76. Which spec am I checking for what? Brian _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 19 15:20:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuD6u-00039d-Nl; Mon, 19 Nov 2007 15:20:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuD6t-00038H-Aw for ecrit@ietf.org; Mon, 19 Nov 2007 15:20:47 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuD6f-0001vK-Po for ecrit@ietf.org; Mon, 19 Nov 2007 15:20:46 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 19 Nov 2007 12:20:33 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAJKKXCO004001; Mon, 19 Nov 2007 12:20:33 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id lAJKK14I012611; Mon, 19 Nov 2007 20:20:33 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 12:20:30 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.90.248]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Nov 2007 12:20:30 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Nov 2007 14:20:29 -0600 To: "Rosen, Brian" From: "James M. Polk" Subject: Re: [Ecrit] New versions of -framework and -phonebcp In-Reply-To: <31D151A3D66E404AACBBB0247ACA54A78BDDED@STNTEXCH11.cis.neus tar.com> References: <31D151A3D66E404AACBBB0247ACA54A78BDDED@STNTEXCH11.cis.neustar.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 19 Nov 2007 20:20:30.0482 (UTC) FILETIME=[A1784720:01C82AE9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=305; t=1195503633; x=1196367633; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20New=20versions=20of=20-framework=20and=20-p honebcp |Sender:=20; bh=6Yz/N8eUw1KgVVwDf8t0TLIlfecnTd+iGrRDaC8y5G0=; b=H0OvMaIRRP3VqASE60plZYy3KQgdnpzKo0AxdLy4P0kE/70VHYKYTkNScU/aFPyr57yW9x6p lVoGeJ+xUWux6gNgONaAKNkDEar+gDzG6dtuaEZGbbuMonD9RNGOe4F8; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 08:12 AM 11/19/2007, you wrote: >There is one >significant missing subject which is "location hiding". Hopefully we >can agree on direction in Vancouver and I can add text covering it. I thought this was crystal clear in Chicago: leave it for a future effort Many folks said this at the mic _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 19 15:26:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDBy-0004bM-5K; Mon, 19 Nov 2007 15:26:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDBw-0004av-Su for ecrit@ietf.org; Mon, 19 Nov 2007 15:26:00 -0500 Received: from ns7.neustar.com ([156.154.24.88] helo=neustar.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IuDBs-0002AK-ET for ecrit@ietf.org; Mon, 19 Nov 2007 15:26:00 -0500 Received: from ([10.31.13.50]) by chihiron1.nc.neustar.com with ESMTP id 5202942.2631270; Mon, 19 Nov 2007 15:25:44 -0500 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 Subject: RE: [Ecrit] New versions of -framework and -phonebcp Date: Mon, 19 Nov 2007 15:25:44 -0500 Message-ID: <31D151A3D66E404AACBBB0247ACA54A78BDF14@STNTEXCH11.cis.neustar.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New versions of -framework and -phonebcp Thread-Index: Acgq6bG6J6RXh2BbQaytvorILQBBFAAAEyMg References: <31D151A3D66E404AACBBB0247ACA54A78BDDED@STNTEXCH11.cis.neustar.com> From: "Rosen, Brian" To: "James M. Polk" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Won't work. We won't get deployment without it.=20 I've talked to enough access network providers and regulators to figure this out. If we don't do it, then the protocols won't be implemented, period. I wish it were not so, but it is. It's not hard to describe mechanisms that work. Some of them require no new protocol mechanisms. Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, November 19, 2007 3:20 PM > To: Rosen, Brian > Cc: ECRIT > Subject: Re: [Ecrit] New versions of -framework and -phonebcp >=20 > At 08:12 AM 11/19/2007, you wrote: > >There is one > >significant missing subject which is "location hiding". Hopefully we > >can agree on direction in Vancouver and I can add text covering it. >=20 > I thought this was crystal clear in Chicago: leave it for a future effort >=20 > Many folks said this at the mic _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 19 15:45:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDV8-0003QD-E8; Mon, 19 Nov 2007 15:45:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuDV7-0003Kj-Du for ecrit@ietf.org; Mon, 19 Nov 2007 15:45:49 -0500 Received: from aismt07p.bellsouth.com ([139.76.165.213]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuDV7-0001nf-31 for ecrit@ietf.org; Mon, 19 Nov 2007 15:45:49 -0500 Received: from ([139.76.131.87]) by aismt07p.bellsouth.com with ESMTP id KP-AXPTB.189301500; Mon, 19 Nov 2007 15:45:32 -0500 Received: from 01NC27689010626.AD.BLS.COM ([90.144.44.201]) by 01GAF5142010623.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 19 Nov 2007 15:45:32 -0500 Received: from 01NC27689010641.AD.BLS.COM ([90.144.44.103]) by 01NC27689010626.AD.BLS.COM with Microsoft SMTPSVC(6.0.3790.2499); Mon, 19 Nov 2007 15:45:32 -0500 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.2992 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] New versions of -framework and -phonebcp Date: Mon, 19 Nov 2007 15:45:30 -0500 Message-ID: <7582BC68E4994F4ABF0BD4723975C3FA0671584C@crexc41p> In-Reply-To: <31D151A3D66E404AACBBB0247ACA54A78BDF14@STNTEXCH11.cis.neustar.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] New versions of -framework and -phonebcp thread-index: Acgq6bG6J6RXh2BbQaytvorILQBBFAAAEyMgAADC86A= References: <31D151A3D66E404AACBBB0247ACA54A78BDDED@STNTEXCH11.cis.neustar.com> <31D151A3D66E404AACBBB0247ACA54A78BDF14@STNTEXCH11.cis.neustar.com> From: "Stark, Barbara" To: "Rosen, Brian" , "James M. Polk" X-OriginalArrivalTime: 19 Nov 2007 20:45:32.0189 (UTC) FILETIME=[208E94D0:01C82AED] X-Spam-Score: 0.2 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 agree with Brian's statements. Barbara=20 -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@neustar.biz]=20 Sent: Monday, November 19, 2007 3:26 PM To: James M. Polk Cc: ECRIT Subject: RE: [Ecrit] New versions of -framework and -phonebcp Won't work. We won't get deployment without it.=20 I've talked to enough access network providers and regulators to figure this out. If we don't do it, then the protocols won't be implemented, period. I wish it were not so, but it is. It's not hard to describe mechanisms that work. Some of them require no new protocol mechanisms. Brian > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Monday, November 19, 2007 3:20 PM > To: Rosen, Brian > Cc: ECRIT > Subject: Re: [Ecrit] New versions of -framework and -phonebcp >=20 > At 08:12 AM 11/19/2007, you wrote: > >There is one > >significant missing subject which is "location hiding". Hopefully we > >can agree on direction in Vancouver and I can add text covering it. >=20 > I thought this was crystal clear in Chicago: leave it for a future effort >=20 > Many folks said this at the mic _______________________________________________ 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. GA623 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 20 16:00:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuaCm-0006gv-VW; Tue, 20 Nov 2007 16:00:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuaCl-0006ga-86 for ecrit@ietf.org; Tue, 20 Nov 2007 16:00:23 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IuaCk-0003vJ-PB for ecrit@ietf.org; Tue, 20 Nov 2007 16:00:22 -0500 Received: (qmail invoked by alias); 20 Nov 2007 21:00:20 -0000 Received: from p5498411A.dip.t-dialin.net (EHLO [192.168.1.5]) [84.152.65.26] by mail.gmx.net (mp057) with SMTP; 20 Nov 2007 22:00:20 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/rKQcNE4vrBdYsD66r74ztTv2Z3TAYniIXjLLyvO zGP+Le8gdwb2jK Message-ID: <47434AE3.3090106@gmx.net> Date: Tue, 20 Nov 2007 22:00:19 +0100 From: Hannes Tschofenig User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) 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: 2.9 (++) X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 Subject: [Ecrit] Agenda 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 is the agenda for the meeting: http://www3.ietf.org/proceedings/07dec/agenda/ecrit.txt _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Tue Nov 20 16:28:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuadX-00020a-8d; Tue, 20 Nov 2007 16:28:03 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IuadW-0001yK-DJ for ecrit@ietf.org; Tue, 20 Nov 2007 16:28:02 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IuadW-00054X-2t for ecrit@ietf.org; Tue, 20 Nov 2007 16:28:02 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 20 Nov 2007 13:28:01 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAKLS1Ox030800; Tue, 20 Nov 2007 13:28:01 -0800 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 lAKLRuUj010127; Tue, 20 Nov 2007 21:28:01 GMT 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.1830); Tue, 20 Nov 2007 13:27:51 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.148.187]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Nov 2007 13:27:50 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 20 Nov 2007 15:27:49 -0600 To: Hannes Tschofenig , ECRIT From: "James M. Polk" Subject: Re: [Ecrit] Agenda In-Reply-To: <47434AE3.3090106@gmx.net> References: <47434AE3.3090106@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 20 Nov 2007 21:27:50.0756 (UTC) FILETIME=[3412EA40:01C82BBC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=625; t=1195594081; x=1196458081; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Agenda |Sender:=20; bh=wTXwAsuGbnj/KTSTTCPYqYV59LnQMQWxwh4x/sXpvaw=; b=jOW0DZl/gyzOLlGw4QbNMtHi3KL30QSAI0ymdZDZ7FXTJERAly7CAYcEpMF5NStMT/wmaxtP FNxFJG5fK+NEhQiuhMjfxmlFagnWvMJuD33u19MUGKszp6Vgd/JZrgOh; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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:00 PM 11/20/2007, Hannes Tschofenig wrote: >Here is the agenda for the meeting: >http://www3.ietf.org/proceedings/07dec/agenda/ecrit.txt Henning's Forest Guide Exchange Protocol ID or "FORest Guide Exchange proTocol" (FORGET) FORGET - "making sure LoST servers are synchronized..." or FORGET - "making sure LoST servers remember what they need to" (I crack myself up sometimes) yeah, I'm still delirious from writing so many IDs this past weekend... >_______________________________________________ >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 Nov 21 04:50:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IumDx-0004DZ-Go; Wed, 21 Nov 2007 04:50:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IumDw-00045i-3M for ecrit@ietf.org; Wed, 21 Nov 2007 04:50:24 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IumDt-0006k5-Co for ecrit@ietf.org; Wed, 21 Nov 2007 04:50:24 -0500 Received: (qmail 13152 invoked by uid 0); 21 Nov 2007 09:50:20 -0000 Received: from 82.113.106.1 by www043.gmx.net with HTTP; Wed, 21 Nov 2007 10:50:20 +0100 (CET) Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Nov 2007 10:50:19 +0100 From: "Hannes Tschofenig" Message-ID: <20071121095019.70790@gmx.net> MIME-Version: 1.0 To: ecrit@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+LVZpO60OLqVkERGSLb6i1APPvgRCD0PEbwjb+ak +osTQfs67AO1PephIS1oX3bQ+3VJ4qTGogdw== Content-Transfer-Encoding: 7bit X-GMX-UID: E7klLc9taHItIokx5CQl8thiamdhZMRw X-Spam-Score: 1.1 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ecrit] Fwd: AD review of draft-ietf-ecrit-dhc-lost-discovery 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 FYI -------- Original-Nachricht -------- Datum: Wed, 7 Nov 2007 17:15:39 -0500 Von: "Peterson, Jon" An: draft-ietf-ecrit-dhc-lost-discovery@tools.ietf.org CC: ecrit-chairs@tools.ietf.org Betreff: AD review of draft-ietf-ecrit-dhc-lost-discovery This document is basically fine. Two non-blocking comments: Section 1, Nit In order to interact with a LoST server, the LoST client finally needs to know its IP address. I presume here that "finally" means... firstly? Also, because this document deals with DHCP, the "its" is ambiguous - one could read it to signify the LoST client, not the LoST server (as I assume you intend). The text currently in Section 5: A DHCPv4 client MAY request a LoST server domain name in an Parameter Request List option, as described in [RFC2131]. Probably belongs in Section 4. - J _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 21 04:52:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IumGQ-0005rP-OL; Wed, 21 Nov 2007 04:52:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IumGP-0005r0-Kk for ecrit@ietf.org; Wed, 21 Nov 2007 04:52:57 -0500 Received: from mail.gmx.net ([213.165.64.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IumGM-0006oy-1d for ecrit@ietf.org; Wed, 21 Nov 2007 04:52:57 -0500 Received: (qmail 22984 invoked by uid 0); 21 Nov 2007 09:52:53 -0000 Received: from 82.113.106.1 by www133.gmx.net with HTTP; Wed, 21 Nov 2007 10:52:53 +0100 (CET) Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Nov 2007 10:52:52 +0100 From: "Hannes Tschofenig" Message-ID: <20071121095252.70820@gmx.net> MIME-Version: 1.0 To: ecrit@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+xDOdGGAyxdMykvPWzTxTn9Kh+srgqKfCd3xFwj4 FFHoGzLqaA3xAECuCzX4T6Zrhjd5KfIU9J9A== Content-Transfer-Encoding: 7bit X-GMX-UID: kY4qKNgjMydhAaQ2qGtlvdNjaGRhZtrE X-Spam-Score: 1.1 (+) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Subject: [Ecrit] Fwd: AD review of draft-ietf-ecrit-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 FYI -------- Original-Nachricht -------- Datum: Wed, 7 Nov 2007 17:38:37 -0500 Von: "Peterson, Jon" An: draft-ietf-ecrit-lost@tools.ietf.org CC: ecrit-chairs@tools.ietf.org Betreff: AD review of draft-ietf-ecrit-lost I have a number of comments on this doc, but overall this mechanism looks sound to me. First, a question for the chairs: has application/lost+xml gone to the ietf-types list for review yet? I couldn't find it in the ietf-types archive, but that could just be my oversight. As another comment on the proto writeup, the normative dependency on [11] and [12] is something we'll need to note during the last call; effectively, for these cases we follow the same procedures we would for a downref to an Informational. Has there been any external Apps Area review for Sections 14 and 16? Detail comments on the text follow. First sentence of the Intro, NAPTR could use a citation, and perhaps rather than just saying NAPTR is a "protocol", one could instead start that sentence with: "NAPTR records served through the DNS and the Service Location Protocol (SLP)..." Second sentence, what is the "identity of a service"? Is that just a way of saying "type of service", or does it mean something specific? Nit, last sentence of the 1st paragraph of the Intro, "callers location" should be "caller's location". I would also advise breaking up the first sentence of the 2nd paragraph of the Intro a bit; it is so complex it seems to have misplaced a leading paranthesis (the one closed right after [11]). Instead of: This document describes a protocol for mapping a service identifier (service URNs) [9] and location information compatible with PIDF-LO [6], namely revised civic location information [10] and a subset of the PIDF-LO profile [13] and consequently with the Geo-Shapes [12] defined for GML [11]) to one or more service URLs. I might recommend: "This document describes a protocol for mapping a service identifier and location information compatible with PIDF-LO [6] to one or more service URLs. Service identifiers take the form of the service URNs described in [9]. Location information here includes revised civic location information [10] and a subset of the PIDL-LO profile [13] which consequently includes the Geo-Shapes [12] defined for GML [11]." Also, the Introduction in some places suggests that "service URLs" are returned, but in others (like the last paragraph of the Intro) suggests that URIs are returned. It is somewhat unfortunate that both the input (service URNs) and output (service URLs) of LoST use that term "service", because of course the term "service URI" could then seem to encompass both the input and the output. But within the Introduction it should be clear whether what is returned by LoST is just a URL or a URI. This confusion persists throughout the document. 5.8, for example, insists they are URLs, but they appear in a element. It's important that the Intro be readable, for the benefit of lazy persons such as myself who judge whether or not they need to read the rest of documents by the Intro alone. At the start of Section 5, just to give readers a bit of context, it might make sense to discuss which LoST messages the element might appear in. As the text reads now, is introduced in a bit of a vacuum. I'm a bit surprised that in 5.2 the reference to cache expiry behavior is the Overview of Operations (Section 3). That section is not normative, and given that it's the overview it shouldn't be. Is this intended? Also, nit, 5.2 2nd sentence "The contents of this attribute is" should be singular "content" 5.4 - What are the conditions under which a service "approximates" another service? I assume something like "general emergency response" approximates "police" if police is unavailable, but that might not be obvious to all readers. In 5.6: A LoST server may decide, based on local policy, to return the service boundary per value or to omit the element in the response. Presumably if it returned the service boundary by value, there would be no need for a element, so is this "or" supposed to be an "and"? Presumably the server wouldn't want to not return the service boundary by value and also not include the element in the response, so readers shouldn't understand this as an exclusive "or", right? I assume 5.7 is a dialstring that will reach a particular service within a particular boundary; I'm surprised this section makes no mention of the geographical scope of such dialstrings. >From Section 6, I assume that all responses to requests that permit recursion contain a element with at least one element, even if the authoritative response comes from the server that originally received the request from the client. I gather this because: The element is inserted logically on receipt of the request, and, The server that answers the request instead of forwarding it, such as the authoritative server, copies the element verbatim into the response Do I understand correctly? If, hypothetically, the element were logically inserted upon the forwarding of the request to another LoST server, then a one-hop response would contain no elements. Section 7 doesn't really explain why a client might want to include multiple instances of location information, nor why a server would prefer one to another. I assumed on first reading this must mean civic v. geodetic; only much later did I understand that wasn't allowed. In 8.2.2, how realistic is it that a will contain a postal code? I ask this not because I doubt that there are some cases in which a will in fact an encompass a particular postal code or other civic division, but I suspect that it will be totally coincidental, and that the vast majority of s have nothing to do with postal codes. My real question is this: is it really reasonable to express a through civic coordinates, or practically speaking are coordinate systems (and probably complicated polygons) the only way to reflect the actual dimensions of service boundaries to clients? If a client sends a civic address in a request for a mapping (with a 'serviceBoundary' attribute), and the server can't really describe the service boundaries in civic address vocabulary, what gets sent in the response? I didn't really see an applicable error in 13.1. Nit in 8.3, I assume the query includes elements and attributes, not just attributes. 8.3.4, given that it is a subsection of 8.3, seems to suggest that is an element of the request. If you're just using this section to describe the 'serviceBoundary' attribute of , perhaps I'd say that at the start of this subsection. In 8.3.5, is 'validateLocation' an attribute of ? The example certainly illustrates that, but the text in the first paragraph should make it clear. An example in 8.4.2 might help; I had a bit of trouble envisioning what this would look like. In Section 10: Typically, only top-level services are included in the answer, implying support for all sub- services. So if you support any top-level service, that implies support for all possible sub-services? That seems counterintuitive to me - if you support 'sos', do you necessarily support 'marine' (13.2 would have led me to think otherwise)? But moreover, I'm really unsure of the applicability of . I understand why you would want to use , but doesn't seem to give you any information that would be useful in predicting whether or not a query would work, nor what sort of query you should send. If it exists for diagnostic purposes, what sorts of diagnostics does it enable? Also, nit, I note that Figure 12 gives instead of , same in Figure 13, 14 and 15. Nit, first paragraph of Section 11 has no final period. Last sentence of the first paragraph of 12 suggests there are "three baseline profiles", I think you mean "two". In 13.1, the first instance of "Relax NG" in the text could probably use a citation. Section 14 mentions the use of HTTP 3xx messages; what is the applicability of this versus the higher-layer redirection described in 13.3? I would recast the Security Consideration (Section 18) a bit. I'd move the last sentence up to the front, and say that Lost clients and servers MUST implement the security recommendations of [17]. As it stands now, the document doesn't suggest that support for HTTP-over-TLS is mandatory to implement for LoST clients and servers; I suspect a security review will insist on that. The rest of the general summary information about threats and authentication is fine; I think the Sec Cons should just be more defential to [17]. Let me know what you think. - J _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 21 04:53:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IumHH-0000DJ-LM; Wed, 21 Nov 2007 04:53:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IumHG-00005H-8F for ecrit@ietf.org; Wed, 21 Nov 2007 04:53:50 -0500 Received: from mail.gmx.net ([213.165.64.20]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IumHF-00020q-My for ecrit@ietf.org; Wed, 21 Nov 2007 04:53:50 -0500 Received: (qmail 25864 invoked by uid 0); 21 Nov 2007 09:53:48 -0000 Received: from 82.113.106.1 by www094.gmx.net with HTTP; Wed, 21 Nov 2007 10:53:47 +0100 (CET) Content-Type: text/plain; charset="us-ascii" Date: Wed, 21 Nov 2007 10:53:47 +0100 From: "Hannes Tschofenig" Message-ID: <20071121095347.70830@gmx.net> MIME-Version: 1.0 To: ecrit@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX182QzBERto2j6emwPqlr137+gGYhCNP4VVz5/w1u1 f12dtLxPaj0jDgi+2GwFYO3wrfHl89ZaxyNw== Content-Transfer-Encoding: 7bit X-GMX-UID: EjhyDuNcQEV/fMRVq3RpsfBCNzg2NcJV X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ecrit] Fwd: AD review of draft-ietf-ecrit-mapping-arch 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 FYI -------- Original-Nachricht -------- Datum: Wed, 7 Nov 2007 17:15:58 -0500 Von: "Peterson, Jon" An: draft-ietf-ecrit-mapping-arch@tools.ietf.org CC: ecrit-chairs@tools.ietf.org Betreff: AD review of draft-ietf-ecrit-mapping-arch This document is basically fine. A couple notes. 7.1 "(Extensions to extra-terrestrial applications are left for future exploration.)" is cute. I wasn't clear reading the document if the LoST synchronization mechanism [11] was applicable to replicating data throughout clusters, or for nodes to recursively query other nodes (last paragraph of 7.1), or both? I had kind of assumed it was the former, but I was surprised not to see it mentioned in 7.4. I agree with the assertion in 8 that "Forest guides fulfill a similar role to root servers in DNS." Moreover different forest guides may be supportive different logical roots (that is, clusters of forest guides may offer different information based on their policy). This seems to me to give rise to a significant trust issue. I was expecting some sort of example record by the time I got to the end of Section 9, but that's at your discretion. Nit in 10, member of a server population introduces claims a coverage region Should use just "introduces" or "claims", not both. - J _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Wed Nov 21 11:30:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IusSc-0006S9-Ao; Wed, 21 Nov 2007 11:29:58 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IusSb-0006Rn-3i for ecrit@ietf.org; Wed, 21 Nov 2007 11:29:57 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IusSY-00079i-Sc for ecrit@ietf.org; Wed, 21 Nov 2007 11:29:56 -0500 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lALGToas009708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 21 Nov 2007 08:29:50 -0800 Received: from [67.169.50.136] (vpn-10-50-0-181.qualcomm.com [10.50.0.181]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lALGTmVP004265; Wed, 21 Nov 2007 08:29:48 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20071121095252.70820@gmx.net> References: <20071121095252.70820@gmx.net> Date: Wed, 21 Nov 2007 08:29:46 -0800 To: "Hannes Tschofenig" , ecrit@ietf.org From: Ted Hardie Subject: Re: [Ecrit] Fwd: AD review of draft-ietf-ecrit-lost Content-Type: text/plain; charset="us-ascii" X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a4bcf8f67063cac573319207fe3db35 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 Here's the response I sent; I kept Jon's original list of recipients, so it didn't go to the WG. Sorry for any confusion. As a side conversation to another matter, Jon and I talked about this and he agreed that most of these were clarifications that could be folded into updates after Last Call. There have already been some IANA comments that need to be addressed, so I am anticipating a revision right after last Call and then, hopefully, on to the IESG. Nothing from either review (AD or IANA) requires any protocol changes, just new text. The two that seemed particularly important in my reading of the conversation were the clarifications of the "via" header behavior and the serviceBoundary behavior. (Again, no changes were being requested--just updated language). Jon is cc'ed on this message so he can quickly dispel any misunderstandings from me on his intent here. regards, Ted Some of these questions appear to be directed at the chairs, but in the interest of getting some discussion, I'll respond. Any corrections welcome. At 5:38 PM -0500 11/7/07, Peterson, Jon wrote: >I have a number of comments on this doc, but overall this mechanism looks sound to me. > >First, a question for the chairs: has application/lost+xml gone to the ietf-types list for review yet? I couldn't find it in the ietf-types archive, but that could just be my oversight. I also didn't see this at a quick glance, so I sent a request for review. If it has already been requested, someone will no doubt point it out. >As another comment on the proto writeup, the normative dependency on [11] and [12] is something we'll need to note during the last call; effectively, for these cases we follow the same procedures we would for a downref to an Informational. > >Has there been any external Apps Area review for Sections 14 and 16? No formal review, but I have asked for sanity checks on the Internationalization section from some of the usual suspects. Asking for a review from the APPS review team during Last Call would probably be good; either Lisa or Chris could do so (Eric Burger is the point of contact, if you want to do that directly). >Detail comments on the text follow. > >First sentence of the Intro, NAPTR could use a citation, and perhaps rather than just saying NAPTR is a "protocol", one could instead start that sentence with: "NAPTR records served through the DNS and the Service Location Protocol (SLP)..." > >Second sentence, what is the "identity of a service"? Is that just a way of saying "type of service", or does it mean something specific? The full sentence is: However, for an important class of services the appropriate specific service instance depends both on the identity of the service and the geographic location of the entity that needs to reach it. the meaning of "the identity of the service" is the same as a "particular service" in the sentence above. In other words, we're highlighting that getting the right service instance can be important, and that you get that by finding the service instance(s) serving that location. I wouldn't switch that to "type of service", personally. Maybe now that the URN doc is in the RFC ed queue we could adjust this to make an explicit reference to that. At the moment, though, I hope this explanation suffices. >Nit, last sentence of the 1st paragraph of the Intro, "callers location" should be "caller's location". > >I would also advise breaking up the first sentence of the 2nd paragraph of the Intro a bit; it is so complex it seems to have misplaced a leading paranthesis (the one closed right after [11]). Instead of: > > This document describes a protocol for mapping a service identifier > (service URNs) [9] and location information compatible with PIDF-LO > [6], namely revised civic location information [10] and a subset of > the PIDF-LO profile [13] and consequently with the Geo-Shapes [12] > defined for GML [11]) to one or more service URLs. > >I might recommend: "This document describes a protocol for mapping a service identifier and location information compatible with PIDF-LO [6] to one or more service URLs. Service identifiers take the form of the service URNs described in [9]. Location information here includes revised civic location information [10] and a subset of the PIDL-LO profile [13] which consequently includes the Geo-Shapes [12] defined for GML [11]." > >Also, the Introduction in some places suggests that "service URLs" are returned, but in others (like the last paragraph of the Intro) suggests that URIs are returned. It is somewhat unfortunate that both the input (service URNs) and output (service URLs) of LoST use that term "service", because of course the term "service URI" could then seem to encompass both the input and the output. But within the Introduction it should be clear whether what is returned by LoST is just a URL or a URI. This confusion persists throughout the document. 5.8, for example, insists they are URLs, but they appear in a element. > >It's important that the Intro be readable, for the benefit of lazy persons such as myself who judge whether or not they need to read the rest of documents by the Intro alone. Are these editorial changes required before Last Call? If we can bundle last call comments with these, so we can move forward, I think it would be good. >At the start of Section 5, just to give readers a bit of context, it might make sense to discuss which LoST messages the element might appear in. As the text reads now, is introduced in a bit of a vacuum. > >I'm a bit surprised that in 5.2 the reference to cache expiry behavior is the Overview of Operations (Section 3). That section is not normative, and given that it's the overview it shouldn't be. Is this intended? Also, nit, 5.2 2nd sentence "The contents of this attribute is" should be singular "content" > >5.4 - What are the conditions under which a service "approximates" another service? I assume something like "general emergency response" approximates "police" if police is unavailable, but that might not be obvious to all readers. The full section is: If, however, the requested service, identified by the service URN [9] in the element in the request, does not exist for the location indicated, the server can either return an (Section 13.1) error or can provide an alternate service that approximates the desired service for that location. In the latter case, the server MUST include a element with the alternative service URN. The choice of service URN is left to local policy, but the alternate service should be able to satisfy the original service request. So this is explicitly for cases where the requested service is not available. This permits a local authority to use a "default" or approximate service for those cases as a matter of configuration, provided it tells the requester that the substitution was made. If you request Mountain Rescue in Holland, for example, they can return police, provided they tell you it is the police you are getting. >In 5.6: > > A LoST server may decide, based on local policy, to > return the service boundary per value or to omit the > element in the response. > >Presumably if it returned the service boundary by value, there would be no need for a element, so is this "or" supposed to be an "and"? Presumably the server wouldn't want to not return the service boundary by value and also not include the element in the response, so readers shouldn't understand this as an exclusive "or", right? The context is: Since geodetic service boundaries may contain thousands of points and can thus be quite large, clients may wish to conserve bandwidth by requesting a reference to the service boundary instead of the value described in Section 5.5. The identifier of the service boundary is returned as an attribute of the element, along with a LoST application unique string (see Section 4) identifying the server from where it can be retrieved. The actual value of the service boundary is then retrieved with the getServiceBoundary (Section 9) request. A reference to a service boundary is requested by the client (using the 'serviceBoundary' attribute in the request with the value set to "reference"). A LoST server may decide, based on local policy, to return the service boundary per value or to omit the element in the response. This basically gives the server some control over what is returned. If a serviceBoundary with a value of "reference" is requested, this allows the server to reply with a value instead (marked as such) or to omit the element which would normally contain the reply entirely. >I assume 5.7 is a dialstring that will reach a particular service within a particular boundary; I'm surprised this section makes no mention of the geographical scope of such dialstrings. This is entirely within the context of a mapping element, which is entirely tied to a geographical scope (either of the location provided in the request or of the serviceBoundary referenced in the response). Adding another mention here seems redundant, unless I misunderstand what you mean here. If you mean that that the dialstring may be valid other places than in the location request or the serviceBoundary, that's true, but not really something that needs much discussion here. Imagine that we're looking for a time service; I give you my location and get back 767-2676 (popcorn) as a dial string as well as other contact methods. "Popcorn" as a dialstring might work in Alabama as well as northern California, but returning just the northern California serviceBoundary (or skipping the serviceBoundary) isn't wrong and remains useful. I could use a serviceBoundary profile that allowed me to include multiple, additive regions to express both Northern California and Alabama, but that would depending on the other contact methods also being valid, which they might not be. > >From Section 6, I assume that all responses to requests that permit recursion contain a element with at least one element, even if the authoritative response comes from the server that originally received the request from the client. I gather this because: > > The > element is inserted logically on receipt of the request, > >and, > > The server that answers the request instead of forwarding it, such as > the authoritative server, copies the element verbatim into the > response > >Do I understand correctly? If, hypothetically, the element were logically inserted upon the forwarding of the request to another LoST server, then a one-hop response would contain no elements. This is stated explicitly at the start of Section 6: To prevent loops and to allow tracing of request and response paths, all requests that allow recursion include a element that contains one or more elements, each possessing an attribute containing a LoST application unique string (see Section 4). The order of elements corresponds to the order of LoST servers, i.e., the first element identifies the server that initially received the request from the client issuing the request. The element is inserted logically on receipt of the request, so that every server in a recursive query operation is included in the element. Since the initial element is inserted on receipt, there must always be at least one element in a path element. The "inserted logically" means simply that the receiving header doesn't actually have to fiddle the bits of the request to put itself in the queue of elements; it is enough that it do so on next action (forward or reply). >Section 7 doesn't really explain why a client might want to include multiple instances of location information, nor why a server would prefer one to another. I assumed on first reading this must mean civic v. geodetic; only much later did I understand that wasn't allowed. As 8.3.1 states: The query communicates location information using one or more elements, which MUST conform to a location profile (see Section 12). There MUST NOT be more than one location element for each distinct location profile. The order of location elements is significant; the server uses the first location element where it understands the location profile. would a forward reference to 8.3.1 meet the case here? >In 8.2.2, how realistic is it that a will contain a postal code? I ask this not because I doubt that there are some cases in which a will in fact an encompass a particular postal code or other civic division, but I suspect that it will be totally coincidental, and that the vast majority of s have nothing to do with postal codes. My real question is this: is it really reasonable to express a through civic coordinates, or practically speaking are coordinate systems (and probably complicated polygons) the only way to reflect the actual dimensions of service boundaries to clients? It must be possible. It's up to the jurisdictions to determine whether it is reasonable. There are service boundaries which are whole states and/or countries, and it is a heck of a lot easier to say "Valid within Norway" than to come up with the polygons that match all those fiddly bits in the fjords. >If a client sends a civic address in a request for a mapping (with a 'serviceBoundary' attribute), and the server can't really describe the service boundaries in civic address vocabulary, what gets sent in the response? I didn't really see an applicable error in 13.1. That's the case we were discussing above, in reference to 5.6. >Nit in 8.3, I assume the query includes elements and attributes, not just attributes. > >8.3.4, given that it is a subsection of 8.3, seems to suggest that is an element of the request. If you're just using this section to describe the 'serviceBoundary' attribute of , perhaps I'd say that at the start of this subsection. > >In 8.3.5, is 'validateLocation' an attribute of ? The example certainly illustrates that, but the text in the first paragraph should make it clear. > >An example in 8.4.2 might help; I had a bit of trouble envisioning what this would look like. > >In Section 10: > > Typically, only top-level > services are included in the answer, implying support for all sub- > services. > >So if you support any top-level service, that implies support for all possible sub-services? That seems counterintuitive to me - if you support 'sos', do you necessarily support 'marine' (13.2 would have led me to think otherwise)? I think you may have missed this statement: The query does not contain location information, as it simply provides an indication of which services the server can look up, not whether a particular service is offered for a particular area. If a top-level service supports sos, it should be able to look up sos.marine. The answer may always be "ServiceNotImplemented" (or the alternate default service) when a geographic location is specified within a jurisdiction that has no marine services. >But moreover, I'm really unsure of the applicability of . I understand why you would want to use , but doesn't seem to give you any information that would be useful in predicting whether or not a query would work, nor what sort of query you should send. If it exists for diagnostic purposes, what sorts of diagnostics does it enable? If you remember draft-ietf-ecrit-service-urn-07.txt, you'll see that it discusses sub services for both sos and counseling. You can use this to discover whether the LoST server you're talking to works for one, the other, or for some later registration. >Also, nit, I note that Figure 12 gives instead of , same in Figure 13, 14 and 15. > >Nit, first paragraph of Section 11 has no final period. > >Last sentence of the first paragraph of 12 suggests there are "three baseline profiles", I think you mean "two". > >In 13.1, the first instance of "Relax NG" in the text could probably use a citation. > >Section 14 mentions the use of HTTP 3xx messages; what is the applicability of this versus the higher-layer redirection described in 13.3? These are an HTTP-layer redirect; they occur before any processing by a LoST server. The 13.3 redirect occurs after a LoST server processes the request; it might not be redirecting all request but those specific to a particular service (e.g., still acting as authoritative for fire and ambulance services, but redirecting police service mapping requests to some other authority during some temporary event like the Olympics). >I would recast the Security Consideration (Section 18) a bit. I'd move the last sentence up to the front, and say that Lost clients and servers MUST implement the security recommendations of [17]. As it stands now, the document doesn't suggest that support for HTTP-over-TLS is mandatory to implement for LoST clients and servers; I suspect a security review will insist on that. Channel security is currently RECOMMENDED, equivalent to SHOULD. It is certainly a good idea for any deployment that deals with emergency services. If a security review asks that it go from RECOMMENDED to mandatory, we can discuss it further, but there are likely to be some uses LoST where it will amount to bloat. >The rest of the general summary information about threats and authentication is fine; I think the Sec Cons should just be more defential to [17]. > >Let me know what you think. > >- J In general, there are a lot of what appear to be editorial comments or clarification requests here, and some indications on which ones can be considered concurrently with Last Call, which ones you considered blocking, etc. would be useful. thanks, Ted _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Sun Nov 25 05:42:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwEwG-0007pJ-3O; Sun, 25 Nov 2007 05:42:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwEwE-0007pB-46 for ecrit@ietf.org; Sun, 25 Nov 2007 05:42:10 -0500 Received: from demumfd002.nsn-inter.net ([217.115.75.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwEwB-0007AW-FV for ecrit@ietf.org; Sun, 25 Nov 2007 05:42:10 -0500 Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id lAPAg6KQ021189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 25 Nov 2007 11:42:06 +0100 Received: from demuexc022.nsn-intra.net (webmail.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id lAPAg6Tg016343 for ; Sun, 25 Nov 2007 11:42:06 +0100 Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Nov 2007 11:42:06 +0100 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 Date: Sun, 25 Nov 2007 11:41:59 +0100 Message-ID: <5FB585F183235B42A9E70095055136FB56CD98@DEMUEXC012.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Review of draft-ietf-ecrit-dhc-lost-discovery Thread-Index: Acgu8AHOCd6zAgzQT8en5+i4TRRfLwAX8V9w From: "Tschofenig, Hannes (NSN - DE/Munich)" To: "ECRIT" X-OriginalArrivalTime: 25 Nov 2007 10:42:06.0288 (UTC) FILETIME=[D2A30500:01C82F4F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ecrit] WG: Review of draft-ietf-ecrit-dhc-lost-discovery 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 FYI -----Urspr=FCngliche Nachricht----- Von: ext Eric Rescorla [mailto:ekr@networkresonance.com]=20 Gesendet: Samstag, 24. November 2007 23:27 An: secdir@ietf.org; iesg@ietf.org; = draft-ietf-ecrit-dhc-lost-discovery@tools.ietf.org Betreff: Review of draft-ietf-ecrit-dhc-lost-discovery $Id: draft-ietf-ecrit-dhc-lost-discovery-02-rev.txt,v 1.1 2007/11/24 = 22:23:19 ekr Exp $ This document describes a DHCP option to carry the location of a LoST [draft-ietf-ecrit-lost] server. The LoST server can then be used to retrieve one's location. This document is extremely simple, just defining the format of the option and the appropriate code points. The security considerations are minimal but seem adequate. -Ekr _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 26 18:53:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwnlU-0000OE-AL; Mon, 26 Nov 2007 18:53:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwnlT-0000O4-1w for ecrit@ietf.org; Mon, 26 Nov 2007 18:53:23 -0500 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwnlS-0008RF-G7 for ecrit@ietf.org; Mon, 26 Nov 2007 18:53:22 -0500 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lAQNrGtg016347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Nov 2007 15:53:17 -0800 Received: from [10.0.1.199] (carbuncle.qualcomm.com [129.46.226.27]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lAQNrFjt011603; Mon, 26 Nov 2007 15:53:15 -0800 (PST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 26 Nov 2007 15:53:14 -0800 To: "Mark Baker" From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ecrit@ietf.org, ietf-types@alvestrand.no Subject: [Ecrit] Re: Review of application/lost+xml 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 2:46 PM -0500 11/22/07, Mark Baker wrote: >On 11/13/07, Ted Hardie wrote: >> This is a request for review application/lost+xml, which is >> described in http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-06.txt . >> Comments to the authors or the working group mailing list (ecrit@ietf.org) >> would be welcome; cc'ing any comments to the AD (Jon Peterson, >> jon.peterson@neustar.biz) would also be welcome since this is currently >> also in his review queue. > >The media type registration itself is pretty straightforward, though >the security considerations section needs work. > >I have some other comments too, while I'm here. > >It's unfortunate that HTTP continues to be referred to, and used as, a >"transport" protocol. This draft isn't as bad as some others in that >respect, but I have some concerns. Chief amoungst these is that LoST >errors are returned with HTTP success status codes, which they should >not be: even SOAP managed to get this one right 8-). Some further clarification on that will be coming; Jon also pointed out the issue in his AD review. Essentially, the HTTP responses should be set without any reference to LoST server logic. The redirect case is the confusing one, since HTTP provides a redirect which might be used where the LoST service as a whole has moved, and LoST also provides a redirect, invoked after the recipient server has examined the incoming LoST request. >Also, the names >of the root XML elements seem to conflate data and protocol, i.e. >"findService" and "findServiceResponse". It's the application >protocol that determines what constitutes a request and a response, as >well as whether the operation is "find" or not (it's not, it's POST). >If I were doing this, I'd use "serviceDescription" and "service" or >something like that. This is largely aesthetic right now, but in my >experience such a change can prevent problems down the line, such as >suggesting the use of new root elements for new services that might be >added in the future, instead of the proper HTTP-friendly way, new >URIs. > >More generally, I think it would be useful to show evidence that BCP >56 has been consulted in the preparation of the HTTP binding. We'll likely talk about this further in Vancouver; thanks for your review. regards, Ted Hardie >Mark. >-- >Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca >Coactus; Web-inspired integration strategies http://www.coactus.com _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Mon Nov 26 21:51:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwqXQ-0000PP-Hd; Mon, 26 Nov 2007 21:51:04 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwqXO-0000PA-UK for ecrit@ietf.org; Mon, 26 Nov 2007 21:51:02 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwqXO-0001f5-JA for ecrit@ietf.org; Mon, 26 Nov 2007 21:51:02 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Nov 2007 18:51:02 -0800 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 lAR2p1sA014756 for ; Mon, 26 Nov 2007 18:51:01 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAR2p1us027251 for ; Tue, 27 Nov 2007 02:51:01 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 18:51:01 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.113.135]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 18:51:01 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Nov 2007 20:51:00 -0600 To: "'ecrit@ietf.org'" From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 27 Nov 2007 02:51:01.0512 (UTC) FILETIME=[5857F880:01C830A0] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=777; t=1196131861; x=1196995861; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20ECRIT=20RPH=20namespace=20ID=20revved=20(-02) |Sender:=20; bh=pwe3X66jUe96wgQSi0JZB3s5jf6mq0Scg8BrQI6029I=; b=M9kI+7U2YLZi+2iwxTNnxz1N2FLW/pKLfRTT9feAjTZ64aYAD2o6RnlVUx9xafQ/BFqEX58E Tw11OEB7x0DOlrj/oafqnbW8ubLjSQWu6IU1W3bndAAifTj0J9OsynOB; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ecrit] ECRIT RPH namespace ID revved (-02) 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 revved draft-polk-ecrit-local-emergency-rph-namespace to version -02 http://www.ietf.org/internet-drafts/draft-polk-ecrit-local-emergency-rph-namespace-02.txt I added a diagram to this ID (Figure 1), similar to what I presented in Chicago that received positive feedback - along with some text explaining the diagram. This diagram is mostly about where the Resource-Priority header can exist, and where it is intended to exist. I have included how certain SIP entities may or may not trust this SIP header, including where this header may be added or reset to a new value. This text is informative in nature. I do not add any policies to the use of this header or namespace from previous versions. Comments are appreciated and welcome James _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 29 08:36:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxjZa-0002wM-RR; Thu, 29 Nov 2007 08:36:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxjZZ-0002vr-Ko for ecrit@ietf.org; Thu, 29 Nov 2007 08:36:57 -0500 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxjZZ-0007vf-76 for ecrit@ietf.org; Thu, 29 Nov 2007 08:36:57 -0500 Received: by nf-out-0910.google.com with SMTP id d21so1585740nfb for ; Thu, 29 Nov 2007 05:36:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; bh=0Em6/lqs7RrzbX12rSb+WxEws79+8xCeN9/bSIMRUpE=; b=eOd9mmn+ZNJii7GxsWGV+Z/NkXY/4IrXrQBWnYqzJUJD5qXl2fzrHe1V8SrgS+eW7z9Poy6P0YkuEuCUXc/RNxVIdMecwX1ZjrbaAQOsDjKFSsXq09+Mc/5TkSbFt4xCOy0Q6KOOXxRQ4ngJg3Js9irIScR3Xf8RC5baop2wr9s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=bCprkG6rT4UT7aVJJykdrkzjQqoj1rZARFw2PcebbxMLSUA+N6h8BJl1ms16+Qgw2HP4f7UHzg4Tu8FNwtRRa4Msb03VTFiuzeVylgNOh1B605MAvn30gPMOuxU6yaiQksmZ/EmNjA6NrFiljLvejoWPkf2x+1+Hspw5pGAy4Fc= Received: by 10.82.158.12 with SMTP id g12mr3969137bue.1196343412780; Thu, 29 Nov 2007 05:36:52 -0800 (PST) Received: by 10.82.181.5 with HTTP; Thu, 29 Nov 2007 05:36:52 -0800 (PST) Message-ID: Date: Thu, 29 Nov 2007 14:36:52 +0100 From: "Karl Heinz Wolf" To: ecrit@ietf.org Subject: LoST serviceNumber [Re: [Ecrit] Comments on framework-03] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 On Oct 16, 2007 1:12 PM, Henning Schulzrinne wrote: > >> ed. For > >> example, when LoST is used only to validate civic addresses then > >> it is > >> not needed. > >> Another example, when a proxy uses LoST for location based routing > >> then > >> the element will not be helpful. > > > > but it wouldn't harm, would it? > > > Not all services may have dial strings, at least in the long term. > Remember that LoST can be used for things other than emergency calls. > It is a long time ago, I started this discussion because the LoST serviceNumber element is just optional. The response here was that the service number will be returned for an emergency service. Unfortunately, the example of mapping an emergency service in draft-ietf-ecrit-lost-06 on page 34 has NO element! cheers, karl heinz _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 29 16:24:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixqs3-0002Qz-Rw; Thu, 29 Nov 2007 16:24:31 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxqqM-0000cF-OF for ecrit@ietf.org; Thu, 29 Nov 2007 16:22:46 -0500 Received: from agnada.com ([69.36.182.244]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixqm3-0005VM-SE for ecrit@ietf.org; Thu, 29 Nov 2007 16:18:20 -0500 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [24.80.240.54]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id lATLI0Wk020980; Thu, 29 Nov 2007 14:18:01 -0700 Message-ID: <474F2C7E.9010809@ntt-at.com> Date: Thu, 29 Nov 2007 13:17:50 -0800 From: Shida Schubert User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Karl Heinz Wolf Subject: Re: LoST serviceNumber [Re: [Ecrit] Comments on framework-03] References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ecrit@ietf.org 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 think the text for mandating the inclusion of in case of an emergency probably belongs to the phone BCP. Regards Shida Karl Heinz Wolf wrote: > On Oct 16, 2007 1:12 PM, Henning Schulzrinne wrote: > >>>> ed. For >>>> example, when LoST is used only to validate civic addresses then >>>> it is >>>> not needed. >>>> Another example, when a proxy uses LoST for location based routing >>>> then >>>> the element will not be helpful. >>>> >>> but it wouldn't harm, would it? >>> >> Not all services may have dial strings, at least in the long term. >> Remember that LoST can be used for things other than emergency calls. >> >> > > It is a long time ago, I started this discussion because the LoST > serviceNumber element is just optional. The response here was that the > service number will be returned for an emergency service. > > Unfortunately, the example of mapping an emergency service in > draft-ietf-ecrit-lost-06 on page 34 has NO element! > > cheers, > karl heinz > > _______________________________________________ > 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 Nov 29 16:33:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixr0o-0001I8-1b; Thu, 29 Nov 2007 16:33:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixr0m-0001Hr-Vv for ecrit@ietf.org; Thu, 29 Nov 2007 16:33:32 -0500 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixr0l-0004Dv-9k for ecrit@ietf.org; Thu, 29 Nov 2007 16:33:32 -0500 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 lATLXRqQ027387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 29 Nov 2007 13:33:27 -0800 Received: from [10.0.1.199] (vpn-10-50-0-118.qualcomm.com [10.50.0.118]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lATLXQfH009080; Thu, 29 Nov 2007 13:33:26 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <474F2C7E.9010809@ntt-at.com> References: <474F2C7E.9010809@ntt-at.com> Date: Thu, 29 Nov 2007 13:33:25 -0800 To: shida@ntt-at.com, Karl Heinz Wolf From: Ted Hardie Subject: Re: LoST serviceNumber [Re: [Ecrit] Comments on framework-03] Content-Type: text/plain; charset="us-ascii" X-PerlMx: Message inspected by PerlMx X-PerlMx: Message inspected by PerlMx X-Spam-Score: -4.0 (----) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 1:17 PM -0800 11/29/07, Shida Schubert wrote: >I think the text for mandating the inclusion of in case of >an emergency probably belongs to the phone BCP. > >Regards > Shida > The example should clearly include it, no matter where the normative text is, and I have no problem making that fix in the next round (there will need to be one round before IETF Last call for a number of small issues that came up). regards, Ted >Karl Heinz Wolf wrote: >>On Oct 16, 2007 1:12 PM, Henning Schulzrinne wrote: >> >>>>>ed. For >>>>>example, when LoST is used only to validate civic addresses then >>>>>it is >>>>>not needed. >>>>>Another example, when a proxy uses LoST for location based routing >>>>>then >>>>>the element will not be helpful. >>>>> >>>>but it wouldn't harm, would it? >>>> >>>Not all services may have dial strings, at least in the long term. >>>Remember that LoST can be used for things other than emergency calls. >>> >>> >> >>It is a long time ago, I started this discussion because the LoST >>serviceNumber element is just optional. The response here was that the >>service number will be returned for an emergency service. >> >>Unfortunately, the example of mapping an emergency service in >>draft-ietf-ecrit-lost-06 on page 34 has NO element! >> >>cheers, >>karl heinz >> >>_______________________________________________ >>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 Nov 29 22:42:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwkT-0002md-Oi; Thu, 29 Nov 2007 22:41:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwkS-0002m3-SH for ecrit@ietf.org; Thu, 29 Nov 2007 22:41:04 -0500 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 1IxwkS-0002dM-IW for ecrit@ietf.org; Thu, 29 Nov 2007 22:41:04 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 29 Nov 2007 19:41:03 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3f4VL028467 for ; Thu, 29 Nov 2007 19:41:04 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3f376008584 for ; Fri, 30 Nov 2007 03:41:03 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8996D4F9-E7DF-4FFF-BEE1-B85BAD57B6EF@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 29 Nov 2007 19:40:24 -0800 To: ECRIT X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=357; t=1196394064; x=1197258064; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Location=20update=20with=20Re-INVITE=20or=20UPDATE |Sender:=20; bh=INgLfNkC7lkm40s49pOgFRDg9J+P5bBTvg5G31f45u4=; b=AMx5TIiXbItXo10itHI7L7NupFFSa0vb11V+z+ZJviz5Q1LCjR5rdr3fzJdQzFp4u8W1hVaa hZtULKeRNyYnsrHffNnjM6M2u4O7pO7QO3csJ38IkO2ksxkVnkz9SIYA; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ecrit] Location update with Re-INVITE or UPDATE 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 was wondering if there was any reason not to just say it had to be done one way or the other. I have a slight preference for UPDATE because Re-INVITES tent to have lots of interoperability problems around SDP. What we can't have is a PSAP that expects one and a caller that uses the other. Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 29 22:42:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixwkc-0002rs-22; Thu, 29 Nov 2007 22:41:14 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixwka-0002ra-RM for ecrit@ietf.org; Thu, 29 Nov 2007 22:41:12 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixwka-0002fO-Er for ecrit@ietf.org; Thu, 29 Nov 2007 22:41:12 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 29 Nov 2007 19:41:13 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3fBNc026875 for ; Thu, 29 Nov 2007 19:41:11 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3f377008584 for ; Fri, 30 Nov 2007 03:41:11 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E446018-439D-4BFD-8619-93022334DA1B@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 29 Nov 2007 19:40:37 -0800 To: ECRIT X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=324; t=1196394071; x=1197258071; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-schulzrinne-ecrit-unauthenticated-access |Sender:=20; bh=unc9oqTr0k6ELrX/K52yJH8IC86jio08oxhfgglnp/c=; b=eAfJyKq2uTTk8eZ5I+bOTn7JgiAKjsgELfbqQfytdPDza7ezkNzJls1Q2hUmQYNpgRdtEKOz ly6j4L6Y0Yvbg2hGTuN3VWKTNoANO+J2FRsNfkNm03pnOm1vLpYxxc1F; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Ecrit] draft-schulzrinne-ecrit-unauthenticated-access 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 Good to see work on this - one NIT. I really don't have any good recommendation for the definition of an "Un-initialized Device" but I don't think having it be "A device without VoIP client software" is going to turn out to be a particularly useful definition. Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 29 22:43:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixwkt-00038z-NV; Thu, 29 Nov 2007 22:41:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixwkr-00038g-1D for ecrit@ietf.org; Thu, 29 Nov 2007 22:41:29 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixwkp-0007TH-HJ for ecrit@ietf.org; Thu, 29 Nov 2007 22:41:29 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Nov 2007 19:41:27 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3fOfo027103 for ; Thu, 29 Nov 2007 19:41:24 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3f378008584 for ; Fri, 30 Nov 2007 03:41:23 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 29 Nov 2007 19:40:50 -0800 To: ECRIT X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=640; t=1196394084; x=1197258084; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20What=20is=20an=20uninitialized=20device=20-=20draft-ietf-ecri t-phonebcp-03 |Sender:=20; bh=DDJ+DZk2rzXo1lKPjRhsgbMC4SYLenzili4QK+hDwR4=; b=stqrIPq1bzqgLQHUvsEXhzpyq5PUSPIYHapjsPq2DTs6EHJcBZMnkqoD6TMUNyJkTPP9eDox ZKz4FVYtQfT6+cUN0V5pyJJo/Cha7qHjVvs2ux2LbeFnUu/Up8sI7NhX; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ecrit] What is an uninitialized device - draft-ietf-ecrit-phonebcp-03 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 The more I think about this uniitialized device stuff, the less clear I am. I understand about the cell phones use before activation. However, the issue here is that there is no billing set up with the device. I'm not sure that would work as a definition we want. My test case is say I get some phone with 802.11 wireless, set it up with an account on iptel.org, then dial an emergency number. Should this work or not? I can imagine arguments for yes or no and it's not that I have an opinion on which it should be but I think the advice should be clear on this. Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 29 22:43:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwlC-0003dD-3d; Thu, 29 Nov 2007 22:41:50 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwlA-0003Ye-LG for ecrit@ietf.org; Thu, 29 Nov 2007 22:41:48 -0500 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 1IxwlA-0002oH-8d for ecrit@ietf.org; Thu, 29 Nov 2007 22:41:48 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 29 Nov 2007 19:41:47 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3flVj027433 for ; Thu, 29 Nov 2007 19:41:47 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3f379008584 for ; Fri, 30 Nov 2007 03:41:47 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <84FE506C-A3FD-47FC-A125-A28F8D5C6CF8@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 29 Nov 2007 19:41:13 -0800 To: ECRIT X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1378; t=1196394107; x=1197258107; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-ietf-ecrit-framework-04 |Sender:=20; bh=qQlCrgTX2z5Fh9aFwVZn3UCq/oeAg4KkpR2FvZ5JIuw=; b=Tms5u1Mkkwz+x42TXStRop9d/RoyfStaycwtowGh63Eu4E6KOCM4LD8WX8IQ2PnjkQ2tlK5f 5xadtaVWKRPZmhn/4O+9+PKWAgH8xoKo4Uy8X0bcQEk3pfb8FlbpOOM8; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ecrit] draft-ietf-ecrit-framework-04 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 there need to be more explanation about why the design allows multiple location objects and when this should be used (and how). The location validation step seem a bit arm wavy in not clear exactly what you do, how anyone checks, and what happens if it fails. Perhaps I just need to go read other documents more. If you are going to say IPSEC is an acceptable alternative to TLS, I think you need to say what ways it needs to be used to be acceptable. Regardless of if it is TLS or IPSEC, having an encrypted connection to the attacker does not do you much good and you need to stop that somehow. Some trivial NIT stuff. Overall there is a lot of duplicated ideas in here. I understand drafts get like this after years of editing. In the first list in section 3 before figure 1. I think it might help to add a "time passes" type text and make it very clear what happens at boot time and what happens when the call is dialed. There are some section that look a little weird from formatting point of view in the txt version: * title section 4 * Civic list item in 6.1 * list in 6.2.4 * list in 6.5 Should Location beacons be in section 6.2.3 instead of 6.2.4? End of 1st para in 6.13. I think one of these references was meant to point at something else. Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 29 22:43:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwlQ-0003rs-MY; Thu, 29 Nov 2007 22:42:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwlP-0003rO-HE for ecrit@ietf.org; Thu, 29 Nov 2007 22:42:03 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxwlP-0007bl-9G for ecrit@ietf.org; Thu, 29 Nov 2007 22:42:03 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 29 Nov 2007 19:42:02 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3g28k020846 for ; Thu, 29 Nov 2007 19:42:02 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3f37A008584 for ; Fri, 30 Nov 2007 03:41:57 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 29 Nov 2007 19:41:23 -0800 To: ECRIT X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=331; t=1196394122; x=1197258122; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-schulzrinne-ecrit-location-hiding-req |Sender:=20; bh=CGRwNnxyx/cB3TODaoPDZcYJeaPH1Vc6f0OMKflBDvM=; b=LMWNc1A4GHkzzabM01Bd1aH/o7fkCBs2xFv3Oj9pg5R7jviEirRs8Njg1/lnm5aQd1eUJcEH o7f21gI9FhRoJNDWgAoFgJrVwIE4oMmgZ9PeIHM1Okovp0VUzMnotBoMNJ16MZxvberRaQnPbL AHE5FVUEa1+gOCmromXS3eaqA=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ecrit] draft-schulzrinne-ecrit-location-hiding-req 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 could not really understand what you were getting at with Req-5. Might need some clarification. Req-15 was also something that was not obvious what it meant. Is this just an observation, or it's alright if the solution allays does this. I was just confused on it. Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 29 22:43:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwlU-0003ve-To; Thu, 29 Nov 2007 22:42:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwlT-0003v3-Gp for ecrit@ietf.org; Thu, 29 Nov 2007 22:42:07 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxwlT-0002sk-7m for ecrit@ietf.org; Thu, 29 Nov 2007 22:42:07 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Nov 2007 19:42:06 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3g6nd027721 for ; Thu, 29 Nov 2007 19:42:06 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3f37B008584 for ; Fri, 30 Nov 2007 03:42:06 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 29 Nov 2007 19:41:32 -0800 To: ECRIT X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=274; t=1196394126; x=1197258126; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20To=20encrypt=20or=20not=20draft-ietf-ecrit-framework-04 |Sender:=20; bh=zXEsR6EnIERxITZ43LxXT22YNqnQJt4D1rSBYW+JFu4=; b=dzH7gEr2GvE6KWy6QlE+2zV/S428z7fUEGHTIURvrLrEACkjF86KdJUufCRNcfyfz/80hsfd wIKkQb9W8GAwmB4B9up+0QMQxWmKHZSAZGiHU6lOdQJ+GtlO7UOPgJ+y; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Ecrit] To encrypt or not draft-ietf-ecrit-framework-04 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 find section 9 leaves me somewhat confused on when I do or do not use encryption. Who it is encrypted to. What to do when encryption fails. And what can not be sent over unencrypted links. Can someone explain? Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 29 22:43:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixwlf-00040c-6Z; Thu, 29 Nov 2007 22:42:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixwle-00040G-6l for ecrit@ietf.org; Thu, 29 Nov 2007 22:42:18 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixwlc-0007fH-VU for ecrit@ietf.org; Thu, 29 Nov 2007 22:42:18 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 29 Nov 2007 19:42:16 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3gG0u029671 for ; Thu, 29 Nov 2007 19:42:16 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3f37C008584 for ; Fri, 30 Nov 2007 03:42:16 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8925353F-0DB6-48D7-99F0-C09AF7D12808@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 29 Nov 2007 19:41:42 -0800 To: ECRIT X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=213; t=1196394136; x=1197258136; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-schulzrinne-ecrit-lost-sync |Sender:=20; bh=OVz5Au7O2JidBHBL17oiYFtuB504dwOpPo7UZHcjj3s=; b=b3ajYZ6vnDjP4Gl4y/6Nv8bwHnxD1tl1Cbw3k/PbLZoBMx4CWouDLXQeDru551YvxOgzPmCJ C/X48IcRLRuMEdUjKdx8/6CJdOZ2jzXlx/u8zlZLEnGRW3RIorkIVxxM; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Ecrit] draft-schulzrinne-ecrit-lost-sync 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 It would be great if this could have more of the big picture about how the sync worked - particularly for cases where there is contradicting information. Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 29 22:44:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixwlp-00045p-CT; Thu, 29 Nov 2007 22:42:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixwlo-00045T-9h for ecrit@ietf.org; Thu, 29 Nov 2007 22:42:28 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixwln-0002xW-Uw for ecrit@ietf.org; Thu, 29 Nov 2007 22:42:28 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 29 Nov 2007 19:42:28 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3gR3N028150 for ; Thu, 29 Nov 2007 19:42:27 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3f37D008584 for ; Fri, 30 Nov 2007 03:42:27 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 29 Nov 2007 19:41:53 -0800 To: ECRIT X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=801; t=1196394147; x=1197258147; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20thomson-geopriv-lis-discovery-03 |Sender:=20; bh=44n5r+OUmLvq+HiMfskvu74bmZrzuSnT7SbgkxSmG+c=; b=fzLJxLvx4j5R3rRKYF54GEvYyWaOFI//2Bvv8W1TGEaFyh/SGx3ucnhuzV9o/CKoCL4O32YZ hpUOLcyk5aWI4DabYAVN9CzKaL8/HbG5NrUXYLbLsYxTvaGTNJRXEvr0; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ecrit] thomson-geopriv-lis-discovery-03 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 This does a nice job of laying out the options. Few questions ... Section 1.2. Do we really need to discover a URI or would host, port, and type of protocol be enough? If so, SRV would be simpler and more widely supported. Section 4.2.1.1 UPnP would not work in many of the cases we are interested in such as layered NAT and even worse it may not be possible to detect this failure. I would not be in favor of UPnP unless it really was the only solution. It is also very complicated to spec the exact parts of it you would need - UPnP is a lot of things. Do we have any idea how common DHCP without a domain name option is? I'm wondering if people would bother to implement way to get IP for reverse IP approaches. Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 29 22:44:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixwm1-0004H9-QA; Thu, 29 Nov 2007 22:42:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixwm1-0004GU-2D for ecrit@ietf.org; Thu, 29 Nov 2007 22:42:41 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixwm0-00030R-Kc for ecrit@ietf.org; Thu, 29 Nov 2007 22:42:40 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 29 Nov 2007 19:42:40 -0800 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 lAU3ge5k020156 for ; Thu, 29 Nov 2007 19:42:40 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3f37E008584 for ; Fri, 30 Nov 2007 03:42:39 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9E03F0F7-ACD9-400D-A63C-814B585D77A5@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 29 Nov 2007 19:42:05 -0800 To: ECRIT X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2150; t=1196394160; x=1197258160; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20draft-ietf-ecrit-phonebcp-03 |Sender:=20; bh=byFvgzrOOX2ui73N8M06GYi/SHQso2r7kKiRu6zyeew=; b=QkOdRoOlB/zg8cE9meRwWMl9JJ7wCWsqoZZHb2M4m1yvpcoLPGW04TxhhzTgydMs3KeJ5Lei n88rYKzY3I8P8noyewLT0HqkLeNqvZuF56YiCMlx9+HdZWbEWgAKQ4vr; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Subject: [Ecrit] draft-ietf-ecrit-phonebcp-03 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 find things like AN-15 pretty confusing about what they mean I should do AN-15 Placement of NAT devices SHOULD consider the effect of the NAT on the LCP. I don't know what I would do with this - to me it roughly says "Some network configurations will not work, and we can't tell you which ones. Try to avoid them - Good Luck". I have similar feelings about some of the other requirements. I guess all I am saying is have a read over these and see if they can be changed to something an implementation needs to do. Some trivial stuff ... In section 10 SP-37 Unitialized devices SHOULD have a persistent URI in a P-Asserted-Identity: header if there is some way to assign such an identifier to the device. Why bother - I can't imagine that the unitialized device is part of Trust Domain and the first thing the proxy would do would be toss out this information and replace it with authenticated information. When I read this, I suspect this is somewhat confused about when 3325 works. I point out that it is an information RFC because it only worked in fairly limited circumstances - I suspect this is one of the environments where it does not work. ED-40 says that 3118 should be used but I have no idea how you are going to get credentials for this is many of the cases you are interested in. In fact exactly the case where DHCP is most likely to be spoofed. In ED-33, I don't think you want to ref 3118. This mandates that all proxies need to do LOST and the ecrit processing. For some types of deployments, I find it extremely unlikely that they would do this - instead they will make a small subset of the proxies do this and ensure the call goes thorough at least one of these. I think that describing that way might be far more realistic. Is there any particular part of LLDP-MED we need to reference to get this? Section 9.1, point 4. not sure if you mean something specific by "URI of the device". Obviously would would not want this to be misinterpreted as the GRUU. Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 29 22:44:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwmI-0004UR-2F; Thu, 29 Nov 2007 22:42:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxwmG-0004U5-QV for ecrit@ietf.org; Thu, 29 Nov 2007 22:42:56 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxwmG-0007ou-Fl for ecrit@ietf.org; Thu, 29 Nov 2007 22:42:56 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 29 Nov 2007 19:42:55 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3gtMB030271 for ; Thu, 29 Nov 2007 19:42:55 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3f37F008584 for ; Fri, 30 Nov 2007 03:42:55 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <84E42963-3472-47D7-A61E-CD8498252722@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 29 Nov 2007 19:42:22 -0800 To: ECRIT X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=389; t=1196394176; x=1197258176; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=204504=20reference=20in=20draft-ietf-ecrit-phonebcp-03 |Sender:=20; bh=+G1J895oiF3pzbl9Q6UG3uvx1DdX2NX/EyxHxxuE/yQ=; b=Pe9wNBlHEjKaah7dJYCXmWIPvyIGhSyiTvlNxwdLdLN9nI8XwDCqWPbKDjUI6TBNfLBiEx4A E6zNUW2lncPd4cIbjVCggdvw5JBCMWaGbw10x3kSPl8MVDSbOnRBNo1y; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ecrit] 4504 reference in draft-ietf-ecrit-phonebcp-03 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 ED-54 says: Best Current Practice for SIP user agents [RFC4504] including handling of audio, video and real-time text [RFC4103] MUST be applied. This memo can be considered as an addition to [RFC4504] for endpoints. I'd note that 4504 is an informational RFC (not BCP) and I would not be surprised if this downref encountered some push back along the way. _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 29 22:45:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixwmr-0004sg-J9; Thu, 29 Nov 2007 22:43:33 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixwmq-0004sF-MO for ecrit@ietf.org; Thu, 29 Nov 2007 22:43:32 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixwmq-0003CS-CD for ecrit@ietf.org; Thu, 29 Nov 2007 22:43:32 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Nov 2007 19:43:31 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAU3hVRw029176; Thu, 29 Nov 2007 19:43:31 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3f37H008584; Fri, 30 Nov 2007 03:43:31 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <45B3BE9B-7925-43B9-A41C-46E1B2DCA4B3@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 29 Nov 2007 19:42:57 -0800 To: ECRIT X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=575; t=1196394211; x=1197258211; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Number=20of=20DHCP=20options=20a=20voip=20device=20might=20ne ed |Sender:=20; bh=QrC08p/1yU1g5QI1HmQlVpsDE4GL2A3laFkWXV0Xq3s=; b=eAwcmlX9ai7IJktETfZQpyQYX+bT4zAd0OXXZkS9zJW4Z3mmqWQ37AeMqaShvkiqsgoe9++h dOr4DmgLfaCAdYhNKASpObi8TKRTdUeDdNmC7sFSP64/05tb8ze8uqMg; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ecrit-chairs@tools.ietf.org Subject: [Ecrit] Number of DHCP options a voip device might need 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 I've mentioned this before but I am a bit concerned about the maximum size of DHCP responses and the number of options we might have for them. I'm wondering if anyone would be interested in working with on a draft that just tries to list what might turn out to be the large DHCP packet on a reasonable configured network? I only mention it in this group because I think the work here is what runs the risk of causing the most harm if DHCP gets badly broken? Anyone interested in this? Thanks, Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 29 22:45:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixwmk-0004nD-Bn; Thu, 29 Nov 2007 22:43:26 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixwmj-0004mv-LK for ecrit@ietf.org; Thu, 29 Nov 2007 22:43:25 -0500 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 1Ixwmj-0003Ah-Bs for ecrit@ietf.org; Thu, 29 Nov 2007 22:43:25 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 29 Nov 2007 19:43:24 -0800 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 lAU3hNU7020831 for ; Thu, 29 Nov 2007 19:43:23 -0800 Received: from [192.168.4.177] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU3f37G008584 for ; Fri, 30 Nov 2007 03:43:23 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <18DC38A5-199F-4028-859E-A06DC7D8AB92@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Thu, 29 Nov 2007 19:42:49 -0800 To: ECRIT X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=333; t=1196394203; x=1197258203; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Callbacks,=20GRUUs,=20and=20draft-ietf-ecrit-framework-04 |Sender:=20; bh=SHYeXhRIQsADYzVNGrk5tKgBvREozSxPceNG0Ai4ROo=; b=IUXPRvQpvayE8ysrvDDwpU5P+xl5ZrcyPakiiUqYXtThUxSmYHs8MlaOIF9okbHjdJfWGu3k xIkiFeule2/Z7FMkiDdgpRwip0wPMJ35wTjDLqUfL5vKk9zJoTyYP27K; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Ecrit] Callbacks, GRUUs, and draft-ietf-ecrit-framework-04 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 section 10, I'm confused about what goes in the From header. I'm assuming this will support anonymous emergency calls in jurisdiction that want that. I'm also a bit confused about what the 3rd paragraph is trying to get at and the related 2nd paragraph in section 13. Cullen _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit From ecrit-bounces@ietf.org Thu Nov 29 23:23:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxxNi-0007bb-H9; Thu, 29 Nov 2007 23:21:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxxNg-0007bU-Ng for ecrit@ietf.org; Thu, 29 Nov 2007 23:21:36 -0500 Received: from serrano.cc.columbia.edu ([128.59.29.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxxNg-000606-Eh for ecrit@ietf.org; Thu, 29 Nov 2007 23:21:36 -0500 Received: from Henning-Schulzrinnes-Computer (pool-71-250-56-143.nwrknj.east.verizon.net [71.250.56.143]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.1/8.14.1) with ESMTP id lAU4KwhD029921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 29 Nov 2007 23:20:58 -0500 (EST) Message-Id: From: Henning Schulzrinne To: Cullen Jennings In-Reply-To: <45B3BE9B-7925-43B9-A41C-46E1B2DCA4B3@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v915) Subject: Re: [Ecrit] Number of DHCP options a voip device might need Date: Thu, 29 Nov 2007 23:20:58 -0500 References: <45B3BE9B-7925-43B9-A41C-46E1B2DCA4B3@cisco.com> X-Mailer: Apple Mail (2.915) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.48 on 128.59.29.6 X-Spam-Score: -1.0 (-) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ecrit-chairs@tools.ietf.org, 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 Fortunately, you can request individual options with DHCP INFORM, so this doesn't seem a big issue. On Nov 29, 2007, at 10:42 PM, Cullen Jennings wrote: > > I think I've mentioned this before but I am a bit concerned about > the maximum size of DHCP responses and the number of options we > might have for them. I'm wondering if anyone would be interested in > working with on a draft that just tries to list what might turn out > to be the large DHCP packet on a reasonable configured network? I > only mention it in this group because I think the work here is what > runs the risk of causing the most harm if DHCP gets badly broken? > Anyone interested in this? > > Thanks, 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 Fri Nov 30 01:18:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxzCS-00054a-58; Fri, 30 Nov 2007 01:18:08 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxzCQ-00054O-81 for ecrit@ietf.org; Fri, 30 Nov 2007 01:18:06 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxzCP-0000XV-Sb for ecrit@ietf.org; Fri, 30 Nov 2007 01:18:06 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Nov 2007 22:18:05 -0800 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id lAU6I5cb005404; Thu, 29 Nov 2007 22:18:05 -0800 Received: from [192.168.4.2] (sjc-fluffy-vpn2.cisco.com [10.25.236.83]) by sj-core-2.cisco.com (8.12.10/8.12.6) with SMTP id lAU6I476016945; Fri, 30 Nov 2007 06:18:04 GMT In-Reply-To: References: <45B3BE9B-7925-43B9-A41C-46E1B2DCA4B3@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <759C9126-487B-4C5B-8028-90D358DA9E04@cisco.com> Content-Transfer-Encoding: 7bit From: Cullen Jennings Subject: Re: [Ecrit] Number of DHCP options a voip device might need Date: Thu, 29 Nov 2007 22:17:58 -0800 To: Henning Schulzrinne X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1201; t=1196403485; x=1197267485; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[Ecrit]=20Number=20of=20DHCP=20options=20a=20voip=20d evice=20might=20need |Sender:=20; bh=ABbR7ZRiyuo6FPiQtsox6kFsnAMGol9vv7+KYAzT74M=; b=cSPcdWwqThbKcvEbg9Osx65h3w7nS/M0Gpqr2zE9Lap2a2tW/Ek6oZsZ8fuZcciFK8mm7mjd smysUz0mDEJ7tDMtD90urJyOaz2BK120b9pk5qhSCT+wX+0ALrSKvSlg; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Good point - thanks - scratch that previous request. At about the time you were sending this I was reading geopriv-dhcp-lbyr-uri-option and realized that the WG was going to use INFORM to avoid this problem. On Nov 29, 2007, at 8:20 PM, Henning Schulzrinne wrote: > Fortunately, you can request individual options with DHCP INFORM, so > this doesn't seem a big issue. > > On Nov 29, 2007, at 10:42 PM, Cullen Jennings wrote: > > > > > I think I've mentioned this before but I am a bit concerned about > > the maximum size of DHCP responses and the number of options we > > might have for them. I'm wondering if anyone would be interested in > > working with on a draft that just tries to list what might turn out > > to be the large DHCP packet on a reasonable configured network? I > > only mention it in this group because I think the work here is what > > runs the risk of causing the most harm if DHCP gets badly broken? > > Anyone interested in this? > > > > Thanks, 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 Fri Nov 30 02:56:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy0j7-0002SR-GE; Fri, 30 Nov 2007 02:55:57 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy0j5-0002SA-QL for ecrit@ietf.org; Fri, 30 Nov 2007 02:55:55 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy0j5-0004Mj-Fj for ecrit@ietf.org; Fri, 30 Nov 2007 02:55:55 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 29 Nov 2007 23:55:55 -0800 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/8.12.11) with ESMTP id lAU7tsbH024367 for ; Thu, 29 Nov 2007 23:55:54 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lAU7tsqZ003293 for ; Fri, 30 Nov 2007 07:55:54 GMT 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.1830); Thu, 29 Nov 2007 23:55:54 -0800 Received: from jmpolk-wxp.cisco.com ([10.21.117.126]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 23:55:54 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 30 Nov 2007 01:55:53 -0600 To: Cullen Jennings , ECRIT From: "James M. Polk" Subject: Re: [Ecrit] Location update with Re-INVITE or UPDATE In-Reply-To: <8996D4F9-E7DF-4FFF-BEE1-B85BAD57B6EF@cisco.com> References: <8996D4F9-E7DF-4FFF-BEE1-B85BAD57B6EF@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 30 Nov 2007 07:55:54.0727 (UTC) FILETIME=[6F304F70:01C83326] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=747; t=1196409354; x=1197273354; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[Ecrit]=20Location=20update=20with=20Re-INVITE=20or=2 0UPDATE |Sender:=20; bh=FI6NVeWLWIQiDP9XmOZi672DEr18jcUyMP87RFm/dqM=; b=pNjerYNQn5Fpgjq+EVPA3n008w6iPD6xgI0mn5h/2EjbctlaJsdK9QDoqEJW3d8s/5CTyK0F TABlFfzuxzV967Q9CRGgV8vozFoNOVM1b8yb98r/o4ePtFvjtulcoZzz; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 09:40 PM 11/29/2007, Cullen Jennings wrote: >I was wondering if there was any reason not to just say it had to be >done one way or the other. I have a slight preference for UPDATE >because Re-INVITES tent to have lots of interoperability problems >around SDP. What we can't have is a PSAP that expects one and a >caller that uses the other. Cullen, when did this become a doubt or choice? SIP Conveyance has had text stating that updating location changes is only done with an UPDATE. It's been this way in the ID for years (literally). >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 Fri Nov 30 07:09:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy4gw-0005mG-MW; Fri, 30 Nov 2007 07:09:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy4gv-0005lg-FL for ecrit@ietf.org; Fri, 30 Nov 2007 07:09:57 -0500 Received: from ondar.cablelabs.com ([192.160.73.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy4gu-0000ql-V3 for ecrit@ietf.org; Fri, 30 Nov 2007 07:09:57 -0500 Received: from kyzyl.cablelabs.com (kyzyl.cablelabs.com [10.253.0.7]) by ondar.cablelabs.com (8.13.8/8.13.8) with ESMTP id lAUC9S0n029096; Fri, 30 Nov 2007 05:09:28 -0700 Received: from srvxchg3.cablelabs.com (10.5.0.25) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com); Fri, 30 Nov 2007 05:09:29 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/511/kyzyl.cablelabs.com) 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 Subject: RE: [Ecrit] Number of DHCP options a voip device might need Date: Fri, 30 Nov 2007 05:09:22 -0700 Message-ID: <9AAEDF491EF7CA48AB587781B8F5D7C695C36C@srvxchg3.cablelabs.com> In-Reply-To: <759C9126-487B-4C5B-8028-90D358DA9E04@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ecrit] Number of DHCP options a voip device might need Thread-Index: AcgzGNQ0QPjYHFmiTOKoZVLoetzDzwAMCm4w References: <45B3BE9B-7925-43B9-A41C-46E1B2DCA4B3@cisco.com> <759C9126-487B-4C5B-8028-90D358DA9E04@cisco.com> From: "Jean-Francois Mule" To: "Cullen Jennings" , "Henning Schulzrinne" X-Approved: ondar X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 agree this can be solved via the INFORM, DHCPv4 option 55 by having enterprise admins/operators configure the devices with what options they should request. But it is still an area we should not underestimate based on my limited experience with UA and DHCP relay vendors, in particular, in the cases of a NACK to DHCP request, lease renewal, DHCP option value updates, etc. =20 Jean-Francois. > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, November 29, 2007 11:18 PM > To: Henning Schulzrinne > Cc: ECRIT > Subject: Re: [Ecrit] Number of DHCP options a voip device might need >=20 >=20 > Good point - thanks - scratch that previous request. At about the > time you were sending this I was reading geopriv-dhcp-lbyr-uri-option > and realized that the WG was going to use INFORM to avoid this problem. >=20 > On Nov 29, 2007, at 8:20 PM, Henning Schulzrinne wrote: >=20 > > Fortunately, you can request individual options with DHCP INFORM, so > > this doesn't seem a big issue. > > > > On Nov 29, 2007, at 10:42 PM, Cullen Jennings wrote: > > > > > > > > I think I've mentioned this before but I am a bit concerned about > > > the maximum size of DHCP responses and the number of options we > > > might have for them. I'm wondering if anyone would be interested > in > > > working with on a draft that just tries to list what might turn > out > > > to be the large DHCP packet on a reasonable configured network? I > > > only mention it in this group because I think the work here is > what > > > runs the risk of causing the most harm if DHCP gets badly broken? > > > Anyone interested in this? > > > > > > Thanks, Cullen > > > > > > _______________________________________________ > > > 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 _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www1.ietf.org/mailman/listinfo/ecrit
=0D=0A=0D=0A

Hi = Peter,

=0D=0A=0D=0A

 

=0D=0A=0D=0A<= p class=3DMsoNormal>I have no argument wi= th the concept of the=0D=0AELIN per se – it makes perfectly good sens= e on the public (PS-ALI) side of the=0D=0Anetwork. The PABX, it seems to me= , is quite capable of bridging the LAN=0D=0Aconcepts to the emergency netwo= rk side without pulling the ELIN into the layer=0D=0A2 on the LAN side. Nev= ertheless – my terminology wasn’t aimed at anyone in=0D=0Aparti= cular and wasn’t intended to cause offence – I withdraw the=0D=0A= characterization and apologize for any offence caused.

=0D=0A=0D=0A

<= o:p> 

=0D=0A=0D=0A

Cheers,

=0D=0A=0D=0A<= p class=3DMsoNormal>Martin

=0D=0A=0D=0A

 

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D= =0A=0D=0A
=0D=0A=0D= =0A
=0D=0A=0D=0A

From:=0D= =0Apeter_blatherwick@mitel.com= [mailto:peter_blatherwick@mitel.com]
=0D=0ASent:= Saturday, 17 November 2007=0D=0A3:24 AM
=0D=0ATo: Dawson, Martin
=0D=0ACc: Rodrig, Benny (Benny); ECRIT
=0D=0ASubject: RE: [Ecrit] ELIN=

=0D=0A=0D=0A
=0D=0A=0D=0A=

 

=0D=0A=0D=0A


=0D=0A= Martin,
=0D=0AYes,=0D=0A= chassis_id / port_id based location tracking is also quite possible, of cou= rse.=0D=0A And LLDP-MED further tightens this possibility by constrain= ing the id=0D=0Atypes presented by underlying LLDP, making it more predicta= ble exactly what=0D=0Awill be presented.  In practical enterprise syst= ems interfacing to=0D=0Aexisting infrastructure, use of ELIN is also valid,= and equivalent in fact.  But=0D=0Ause of ELIN directly would save a l= ook-up step.  LLDP-MED added ELIN since=0D=0Awas a very easy and obvio= us location type to have available along with the IETF=0D=0Aspecified ones.=  At the time, specifying ELIN was also in line with NENA=0D=0Adirecti= ons for compatibility in N.A.  Since ELIN is really just a string=0D=0A= of digits, it can also be used in lots of other ways too.  Support of=0D= =0Acurrently deployed N.A. E-911 interfacing is simply an absolutely huge u= se=0D=0Acase, so why would it not be added=3F=3F  
=0D= =0A
=0D=0ATo=0D=0Arepeat myself, since IETF ECRIT / Geopri= v does not have support of existing=0D=0APSTN systems in its mandate, I agr= ee use of ELIN likely does not play in there.=0D=0A But, that does not= make it "half baked", to repeat your earlier=0D=0Awords.  S= upport of existing systems, deployed in huge numbers, and highly=0D=0Alikel= y to keep existing for a very long time, just makes pragmatic sense.  = =0D=0A
=0D=0A
=0D=0A--=0D=0APeter<= /font>
=0D=0A
=0D=0A
=0D=0A
=0D=0A

=0D=0A=0D=0A<= table class=3DMsoNormalTable border=3D0 cellpadding=3D0 width=3D"100%"=0D=0A= style=3D'width:100.0%'>=0D=0A =0D=0A =0D=0A

 

=0D=0A =0D=0A =0D=0A

"Dawson, Martin"=0D=0A <Martin.Dawson@an= drew.com>

=0D=0A

16.11.07 00:36

=0D=0A =0D=0A =0D=0A

       
=0D=0A  =0D=0A       To:        = <peter_blatherwick@mitel.com>, "Rodrig,=0D=0A Benny (Benny)" <brodrig@avaya.co= m>
=0D=0A  =0D=0A     &n= bsp; cc:        "ECRIT" <ecrit@ietf.org>= ;=0D=0A
=0D=0A  =0D=0A    =   Subject:        RE: [Ecrit] ELIN<= o:p>

=0D=0A =0D=0A =0D=0A=0D=0A=0D=0A


=0D=0A
=0D=0A
=0D=0AWell – if having an opinion equates to=0D=0Aself-servin= g then “guilty as charged”; it certainly doesn’t make me = Robinson=0D=0ACrusoe in this forum.
=0D=0A 
=0D=0AAll I mean is that the ELIN, being a fairly North American=0D=0Aand= application specific parameter seems somewhat out of place in a general=0D= =0Alink layer spec. As has been noted, it’s pretty much a reference (= though not an=0D=0Ainvitation to a callback as used with HELD) – and = probably not even the ELIN=0D=0Athe private switch will use since it needs = to consider the dynamics of how many=0D=0Acalls are originating. As such, I= would have thought that the switch and port=0D=0Aidentity available throug= h standard LLDP (sans MED) would have served the same=0D=0Apurpose. I didn&= #8217;t say it isn’t “convenient”.
=0D=0A=  
=0D=0ACheers,
=0D=0AMartin
=0D=0A&= nbsp;

=0D=0A=0D=0A

 

=0D= =0A=0D=0A
= =0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A


=0D=0AFrom: peter_blatherwick@mit= el.com [mailto:peter_blat= herwick@mitel.com]
=0D=0ASent: Tuesday, 13 November 2007 5:58 AM
=0D=0ATo: Rodrig, Benny (Benny)=
=0D=0ACc: ECRIT
=0D=0ASubject: RE: [Ecrit] ELIN
=0D=0A 
=0D=0A
=0D=0AHi again, and thanks = for the further input Benny,
=0D=0A
=0D=0AYes, I c= ertainly agree (contrary to Martin's obviously inflammatory and=0D=0Aself-s= erving comments earlier) that LLDP-MED can make a very good, simple=0D=0Aso= lution in many situations.  And many of those scenarios need to addres= s=0D=0Aworking with traditional E911 systems, hence inclusion of ELIN in LL= DP-MED.=0D=0A For better or worse, interworking with pre-existing ECS = systems such as=0D=0AE911 is not a part of ECRIT's mandate, hence is not de= scribed in any ECRIT=0D=0Adocument, or anywhere in IETF for that matter. &n= bsp;  
=0D=0A
=0D=0ALLDP-MED only defines the= protocol and exchange of TLVs.  The usage is=0D=0Adefined in other do= cuments.
=0D=0A
=0D=0AFor a bit more background on= this, and how it can play in to the application=0D=0Alevel, see also TIA's= TSB-146-A which describes several network topologies and=0D=0Apossible sol= utions to the emergency call location problem, as well as others=0D=0Apiece= s of the puzzle.  Note that this document was not intended to define=0D= =0Aany particular solution, but to discuss a range of alternatives.  A= lthough=0D=0Arecently updated (in March 07) it is also a second revision wi= th the first=0D=0Adating several years back now (2004 I believe).  Ava= ilable at:
=0D=0A =0D=0A http://www.tiaonline.org/standards/t= echnology/voip/documents/TSB-146-AFinalforPublication.pdf=0D=0A=
=0D=0A(You will likely be asked to fill in some info and press [I a= gree] button on=0D=0Athe way.)  
=0D=0A
=0D=0A= See also DSL Forum draft WT-164 recently posted to this list, which shows=0D= =0Adevice startup state diagrams including LLDP-MED, DHCP and HELD.   =  =0D=0A
=0D=0A
=0D=0ACheers,
=0D=0APeter B= latherwick
=0D=0A
=0D=0A

=0D=0A=0D=0A=0D=0A =0D=0A =0D=0A

 

=0D=0A =0D=0A =0D= =0A

"Rodrig, Benn= y (Benny)" <brodrig@avaya.com>=0D=0A

=0D=0A

12.11.07=0D=0A 11:47

=0D= =0A =0D=0A =0D=0A

  =      
=0D=0A        To:   &nbs= p;    <peter_blatherwick@mi= tel.com>, "Karl Heinz=0D=0A Wolf" <khwolf= 1@gmail.com>, "Winterbottom,=0D=0A Ja= mes" <James.Winterbottom@andrew.com>=0D=0A
=0D=0A        cc:     &nbs= p;  "ECRIT"=0D=0A <ecrit@ietf.org>
=0D=0A        Subject:       =  RE: [Ecrit]=0D=0A ELIN

=0D=0A =0D=0A= =0D=0A=0D=0A=0D=0A

=
=0D=0A
=0D=0A
=0D=0A
=0D=0AAnother point to add is that whe= n an endpoint moves within the=0D=0Acampus/enterprise, a different ELIN may= have to be passed to the PSAP with the=0D=0Aemergency call, depending on t= he endpoint's location. To figure this out=0D=0Aautomatically, getting the = right ELIN directly from the local network via=0D=0ALLDP-MED can be a good = solution.
=0D=0A <= br>=0D=0ARegarding the callback point below - I think the ELIN is typically= used as the=0D=0Acallback number, and the MLTS can then either forward the= callback to the=0D=0Aoriginal caller or to a designated responder e.g. the= security desk.=0D=0A
=0D=0A 
=0D=0ABenny

=0D=0A=0D=0A

 =

=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A
=0D=0A=0D=0A


=0D=0AFrom: = peter_blatherwick@mitel.com [mailto:peter_blatherwick@mitel.com]
=0D=0ASent: Monday, November 12, 2007= 11:09 AM
=0D=0ATo:= Karl Heinz Wolf; Winterbottom, James
=0D=0ACc: EC= RIT
=0D=0ASubject: RE: [E= crit] ELIN
=0D=0A
=0D=0A
=0D=0AHi Karl,   =0D=0AJames' description earlier on how ELIN works is essentially correct= =2E  A=0D=0Acouple of added bits:
=0D=0A=0D=0A- ELIN can also be used for ECS call routing.  If the call gets= placed on=0D=0Aan out of district GW, it can be used in PSTN to route to t= he correct (in=0D=0Adistrict) PSAP.  
=0D=0A=
=0D=0A- At the PSAP, ELIN is effectively a dB index to look up details = on the source=0D=0Aof the call, based on ERL data that is provisioned in th= e PSAP dB (street=0D=0Alocation, in-building location, etc etc)
=0D=0A
=0D=0A- I don't *think* ELIN is generally used as= the callback number.  In=0D=0AISDN-based signalling, there is both th= e ELIN and a callback number.  I=0D=0A*think* the PSAP side is (or can= be) provisioned with callback corresponding to=0D=0Athe ELIN in its dB. &n= bsp;The callback number is typically not an extension,=0D=0Abut a designate= d responder within the enterprise at that location, e.g. the=0D=0Asecurity = desk.  Perhaps others on the list with direct experience can=0D=0Acomm= ent on this point=3F  
=0D=0A
=0D=0A> ... all extensions with the same ELIN need to be=0D=0Aclo= se to one another.
=0D=0AYes, all extensions wit= h the same ELIN *will* be physically close together.=0D=0A But this is= not directly related to callback.  It is by definition=0D=0Aof what t= he ERL is -- it is a small enough region in a building to allow=0D=0Aemerge= ncy responders to find someone.  
=0D=0A=0D=0A> ... what the client doe= s when its gets the ELIN=0D=0Afrom LLDP-MED I have no idea
=0D=0AELIN was added to LLDP-MED for completeness and for compat= ibility with existing=0D=0APSTN infrastructure.  Since existing E911 s= ystems in N.A. use ELIN today,=0D=0Athere was no easy way to support it wit= h Civic and Geo types only.  (I am=0D=0Aa little surprised ELIN type h= as not been defined in IETF as well ... but=0D=0Athat's another story.) &nb= sp;Thinking was that the device could receive ELIN,=0D=0Apass it in SIP sig= nalling towards PSTN GW, that would then insert the ELIN into=0D=0APSTN tru= nk signalling.  I do not know if anyone uses it this way.  =0D=0A
=0D=0A
=0D=0A> To this extent the ELIN is the way in which LLDP-MED=0D=0Acurrently= supports
=0D=0A> location by reference.
=0D=0AYes, ELI= N is effectively a form of location-by-reference.  LLDP-MED can=0D=0Aa= lso be readily extended to support LbyR in the sense used in Geopriv / ECRI= T=0D=0Aas well.  Since location objects are directly supplied by the n= etwork=0D=0Ainfrastructure in LLDP-MED's case, it is not entirely clear to = me why LbyR would=0D=0Areally be needed / useful for LLDP-MED deployments. =  
=0D=0A
=0D=0ACheers,
=0D=0APeter B= latherwick
=0D=0A
=0D=0A

=0D=0A=0D=0A=0D=0A =0D=0A =0D=0A

 

=0D=0A =0D=0A =0D= =0A

"Winterbottom,=0D=0A James" <Jame= s.Winterbottom@andrew.com>=0D=0A

=0D=0A=

12.11.07=0D=0A 04:46

=0D=0A =0D= =0A =0D=0A

     =  
=0D=0A       To:        &qu= ot;Karl Heinz=0D=0A Wolf" <khwolf1@gmail.com>
=0D=0A       cc:        ECRI= T <ecrit@ietf.org>=0D=0A <= span style=3D'font-size:7.5pt;font-family:Arial'>
=0D=0A     =   Subject:        RE: [Ecrit] ELIN

=0D=0A =0D=0A =0D=0A=0D=0A=0D=0A


=0D=0A=
=0D=0A
=0D=0A
=0D=0A
=0D= =0AHi Karl Heinz,
=0D=0A
=0D=0AIt is the only the extension that actu= ally has the ELIN number that gets
=0D=0Acalled back. So all extensions = with the same ELIN need to be close to
=0D=0Aone another.
=0D=0A
=0D= =0AAs to what the client does when its gets the ELIN from LLDP-MED I have=0D=0Ano idea... *8)
=0D=0A
=0D=0ACheers
=0D=0AJames
=0D=0A=0D=0A
=0D=0A> -----Original Message-----
=0D=0A> From: Karl = Heinz Wolf [mailto:khwolf1@gmail.com]
=0D=0A> Sent: Monday, 12 Novemb= er 2007 8:31 PM
=0D=0A> To: Winterbottom,= James
=0D=0A> Cc: ECRIT
=0D=0A> Subject: Re: = [Ecrit] ELIN
=0D=0A>
=0D=0A> Hi James!
=0D=0A>
=0D=0A= > Thank you for your detailed description of the ELIN.
=0D=0A> One= more question: how does the callback from the PSAP work, if there
=0D=0A= > are multiple extensions with the same ELIN=3F
=0D=0A>
=0D=0A= > Anyway, in case a company uses ELINs, and LLDP-MED location
=0D=0A&= gt; information tells the client this ELIN, what is the client supposed to<= br>=0D=0A> do=3F
=0D=0A>
=0D=0A> cheers
=0D=0A> karl = heinz
=0D=0A>
=0D=0A> On Nov 12, 2007 10:03 AM, Winterbottom, James
=0D=0A> <James.= Winterbottom@andrew.com> wrote:
=0D=0A> > Hi Karl Heinz,
=0D= =0A> >
=0D=0A> > An ELIN is a specific callback number that = represents an area in an
=0D=0AMLTS
=0D=0A> > (Multi-Line Telep= hone System). As far as I know they are only used
=0D=0Ain
=0D=0A>= > the USA.=0D=0AThe following description may not be 100% = right, but it is
=0D=0A> > pretty close.
=0D=0A> >
=0D= =0A> > Essentially if you have a company or campus that occupies a la= rge
=0D=0Aarea,
=0D=0A> > you can break this up into smaller ar= eas to make it easier for
=0D=0Aemergency
=0D=0A> > service cre= ws to find people. In some States this is mandated when
=0D=0Athe
=0D= =0A> > area becomes more than a certain size (8000 sqr feet is common= ly
=0D=0A> > quoted). Generally what happens is that all telephone= extensions in
=0D=0Aa
=0D=0A> > certain area are associated wi= th what is called an ERL (emergency
=0D=0A> > resource location), = this is done in the PABX provisioning. Each ERL
=0D=0Ais
=0D=0A> &= gt; allocated an ELIN that serves as the presented calling number to the=0D=0A> > PSAP for any extension provisioned against the ERL. The PS= AP is able
=0D=0Ato
=0D=0A> > use the ELIN to get the floor loc= ation and area serviced by a
=0D=0Aspecific
=0D=0A> > ELIN. The= ELIN also serves as the number that the PSAP will callback
=0D=0Ain
=0D= =0A> > the case of the call being dropped.
=0D=0A> >
=0D=0A= > > To this extent the ELIN is the way in which LLDP-MED currently=0D=0Asupports
=0D=0A> > location by reference.
=0D=0A> >= ;
=0D=0A> > Please let me know if this isn't clear and I will try = an clarify
=0D=0A> > further.
=0D=0A> >
=0D=0A> >= ; Cheers
=0D=0A> > James
=0D=0A> >
=0D=0A> >
=0D= =0A> > > -----Original Message-----
=0D=0A> > > From: = Karl Heinz Wolf [mailto:khwolf1@gmail.com]
=0D=0A> > > Sent: Mo= nday, 12 November 2007 7:23 PM
=0D=0A> > > To: ECRIT
=0D=0A&= gt; > > Subject: [Ecrit] ELIN
=0D=0A> > >
=0D=0A> &= gt; > LLDP-MED supports not just civic and coordinate based location
=0D= =0A> > > information, but also an ELIN. How does this type of loca= tion
=0D=0A> > > information fit to the IETF Framework=3F Is th= is case considered=0D=0Ain
=0D=0Aany
=0D=0A> > > document=3F=
=0D=0A> > > I couldn't find any information on how to proceed = with this type
=0D=0Aof
=0D=0A> > > location information.=0D=0A> > >
=0D=0A> > > cheers
=0D=0A> > >= ; Karl Heinz
=0D=0A> > >
=0D=0A> > > ______________= _________________________________
=0D=0A> > > Ecrit mailing lis= t
=0D=0A> > > Ecrit@ietf.org
=0D=0A> > > https://ww= w1.ietf.org/mailman/listinfo/ecrit
=0D=0A> >
=0D=0A> >=0D=0A--------------------------------------------------------------------= ----
=0D=0A> ------------------------
=0D=0A> > This message= is for the designated recipient only and may
=0D=0A> > contain pr= ivileged, proprietary, or otherwise private information.
=0D=0A> >= If you have received it in error, please notify the sender
=0D=0A> &= gt; immediately and delete the original.  Any unauthorized use of
=0D= =0A> > this email is prohibited.
=0D=0A> >
=0D=0A--------= ----------------------------------------------------------------
=0D=0A&= gt; ------------------------
=0D=0A> > [mf2]
=0D=0A> >=0D=0A> >
=0D=0A
=0D=0A---------------------------------------= ---------------------------------------------------------
=0D=0AThis mes= sage is for the designated recipient only and may
=0D=0Acontain privileg= ed, proprietary, or otherwise private information.  
=0D=0AIf you h= ave received it in error, please notify the sender
=0D=0Aimmediately and= delete the original.  Any unauthorized use of
=0D=0Athis email is = prohibited.
=0D=0A------------------------------------------------------= ------------------------------------------
=0D=0A[mf2]
=0D=0A
=0D=0A=
=0D=0A_______________________________________________
=0D=0AEcrit ma= iling list
=0D=0AEcrit@ietf.org
=0D=0Ahttps://www1.ietf.org/mailman/l= istinfo/ecrit

=0D=0A=0D=0A

 

=0D=0A=0D=0A=0D=0A =0D=0A =0D=0A

=0D=0A ------------------------------------------------------------------= ------------------------------
=0D=0A This message is for the designate= d recipient only and may
=0D=0A contain privileged, proprietary, or oth= erwise private information.  
=0D=0A If you have received it in er= ror, please notify the sender
=0D=0A immediately and delete the origina= l.  Any unauthorized use of
=0D=0A this email is prohibited.
=0D= =0A ----------------------------------------------------------------------= --------------------------
=0D=0A [mf2]

=0D= =0A =0D=0A =0D=0A
=0D=0A=0D=0A

 

=0D=0A=0D=0A