Thanks for the reminder, James, I think that will help.
-----Original Message-----
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf
Of James M. Polk
Sent: Wednesday, April 20, 2005 11:44 PM
To: GEOPRIV WG; ecrit@ietf.org
Subject: [Geopriv] Terms on this thread
Suggesting term changes:
"Location Delivery" is to the endpoint (the first time or a refresh)
"Location Conveyance" is from the endpoint (to the LIS, the Proxy or to the
PSAP)
"Location Conveyance" is already the term/phrase used in SIP(PING) for a UA
to convey its location to another UA or Proxy, per:
http://www.ietf.org/internet-drafts/draft-ietf-sipping-location-requirements
-02.txt
so the term/phrase seems to be appropriate here
Delivery IN
Conveyance OUT
both from the endpoint's point of view
agreed?
we can worry about non-proxy server to server lateral movement when that
issue comes up
At 01:03 PM 4/20/2005 -0400, Abbott, Nadine B. wrote:
>Mike,
>You are right--it is being used in two different contexts. Delivery of
>location to the endpoint and delivery of location to the PSAP. We need
>different terms or we need to qualify the term when we use it (as
>above). Nadine
>
>-----Original Message-----
>From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On Behalf
>Of Michael Hammer (mhammer)
>Sent: Wednesday, April 20, 2005 12:00 PM
>To: Brian Rosen; peter_blatherwick@mitel.com
>Cc: GEOPRIV WG; ecrit@ietf.org
>Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
>InterimMeeting
>
>
>I still get the feeling that "delivery" is being used in two different
>contexts:
>
> (1) (2)
>Local node---?---->endpoint-----/many hops/----->PSAP
> ---------------------/many hops/----->
> (2)
>
>How can "delivery" be L2 dependent, when it must reach a PSAP many hops
>away? Color me confused.
>
>Mike
>
>
> >-----Original Message-----
> >From: Brian Rosen [mailto:br@brianrosen.net]
> >Sent: Wednesday, April 20, 2005 10:47 AM
> >To: Michael Hammer (mhammer); peter_blatherwick@mitel.com
> >Cc: 'GEOPRIV WG'; ecrit@ietf.org
> >Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint
> >GEOPRIV/ECRIT InterimMeeting
> >
> >The idea is that, say, you are in your home, served by a DSL
> >provider. The domain is then that of the DSL vendor. Your phone asks
> >for its location from the server in the DSL domain. It would be
> >given the location corresponding to the IP address of the request.
> >Note that this would be pretty good for the requested case, even in
> >the presence of a NATed local area network in your home. The phone
> >would do this on boot, before any VPN tunnels were established.
> >
> >I get the idea that a single delivery mechanism is desirable. I'm
> >skeptical we can do that because of the security issues. When you
> >make the delivery mechanism L2 dependent, you can control the
> >possible attacks to a finer grain than the L7 local domain.
> >
> >Please keep in mind that some of the folks wishing to use the L7
> >mechanism don't really want to just return location to the endpoint;
> >they want to retain the location and give it out to authorized
> >entities upon presentation of the IP address of the endpoint. That
> >is a business decision. They can charge for such a service. I think
> >the privacy implications of that are dicey, but the reality is that's
> >the model that will probably be implemented if we do this.
> >
> >Brian
> >
> >
> >
> >
> >
> >> -----Original Message-----
> >> From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> >> Sent: Wednesday, April 20, 2005 10:14 AM
> >> To: Brian Rosen; peter_blatherwick@mitel.com
> >> Cc: GEOPRIV WG; ecrit@ietf.org
> >> Subject: RE: [Ecrit] RE: [Geopriv] Announcement of Joint
> >GEOPRIV/ECRIT
> >> InterimMeeting
> >>
> >> Brian,
> >>
> >> Could you clarify the domain statement. Given nomadicity, it would
> >> seem that location delivery would need to be cross-domain. The
> >> E911 PSAP will not always be the same domain as the roaming
> >> endpoint.
> >>
> >> My impression is that Location discovery is a L2 issue, tied to the
> >> fact that L2 is supposed to be a single physical hop at most
> >> between the end- user terminal and an adjacent location-determining
> >> network node. (Of course those trying to make L2 protocols a
> >replacement for
> >> IP sort of screw this assumption up.)
> >>
> >> The location delivery mechanism is an application-layer or
> >L7 service.
> >> The argument there is that since multiple applications will need to
> >> rely on location information, a general purpose delivery mechanism
> >> will provide consistency and generality that is so often sought in
> >> IETF work. Security can be built-in to the chosen delivery
> >mechanism.
> >> Note, that delivery could be a choice of an existing transfer
> >> mechanism. This does not preclude other L7 protocols from
> >defining a
> >> place in their messages that could also carry location information.
> >>
> >> So, I believe:
> >> Location discovery is local, with associated security being local,
> >> Location delivery is global, with associated security being global.
> >>
> >> The real issues are making those happen.
> >>
> >> Mike
> >>
> >> >-----Original Message-----
> >> >From: ecrit-bounces@ietf.org [mailto:ecrit-bounces@ietf.org] On
> >> >Behalf Of Brian Rosen
> >> >Sent: Wednesday, April 20, 2005 9:54 AM
> >> >To: peter_blatherwick@mitel.com
> >> >Cc: 'GEOPRIV WG'; ecrit@ietf.org
> >> >Subject: [Ecrit] RE: [Geopriv] Announcement of Joint GEOPRIV/ECRIT
> >> >InterimMeeting
> >> >
> >> >There turns out to be a large set of issues around this problem,
> >> >which I fear is leading to Balkanization. There are two really
> >> >important problems we need to solve.
> >> >
> >> >One fundamental problem is that every client needs to
> >implement every
> >> >possible LI transfer mechanism that its environment could provide.
> >> >
> >> >We have DHCP. You guys are working on LLDP-MED. The DSL
> >> >guys reject both
> >> >of these and want a something else. Every phone has to implement
> >> >every protocol.
> >> >
> >> >There are some who have observed that the mechanisms at hand are
> >> >L2 specific. They claim as long as you have an L2 specific
> >> >mechanism, you need one or more for each L2. To get out of that,
> >> >they propose that we use an L7 mechanism (think some version of
> >> >HTTP, although that might not fly). They would say, lets do that
> >> >once,
> >and every L2
> >> >can use it. The problem is that you then have to deal with the
> >> >security issues of an L7 mechanism, and in particular, you have to
> >> >use IP address as the "key" for what location to return.
> >If you can
> >> >spoof IP address, you can get someone else's location.
> >> >
> >> >Those advocating L7 mechanisms claim that the mechanism
> >would only be
> >> >implemented within a domain, and the domain would have to take
> >> >anti-spoofing steps. They note that the mechanism would need at
> >> >least a complete round trip, and probably more than one, so
> >spoofing
> >> >requires the ability to
> >> >intercept packets not addressed to the attacker. The
> >> >returned data could
> >> >be precisely a PIDF-LO.
> >> >
> >> >Then on top of that, we turn out to need some more security,
> >> >especially for emergency calls. We need to prevent forged
> >locations.
> >> >That means we need to sign the PIDF-LO. If you get location via
> >> >DHCP, or LLDP-MED, and the endpoint constructs a PIDF-LO from
> >> >that, how do we construct a signature from the entity that
> >> >actually determined location?
> >> >
> >> >Brian
> >> >
> >> >
> >> >________________________________________
> >> >From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org]
> >> >On Behalf Of peter_blatherwick@mitel.com
> >> >Sent: Wednesday, April 20, 2005 9:30 AM
> >> >To: Andrew Newton
> >> >Cc: GEOPRIV WG; ecrit@ietf.org
> >> >Subject: Re: [Geopriv] Announcement of Joint GEOPRIV/ECRIT Interim
> >> >Meeting
> >> >
> >> >
> >> >Hi Andrew, lists,
> >> >
> >> >I'd like to better understand the meaning of the following agenda
> >> >items:
> >> > "
> >> > 2) Properties of network elements in transferring LI from layer
> >> >2 upward to PIDF-LO.
> >> > 3) Proposed enhancements to PIDF-LO to support #2.
> >> > "
> >> >
> >> >Is there a summary of what these really mean, or examples
> >of what the
> >> >outcome could be in terms of protocol or layer interactions?
> >> >
> >> >Reason I'm asking is I am deeply involved in a layer 2
> >approach which
> >> >would be able to deliver location information to endpoints from
> >> >the L2 LAN infrastructure they are connected to. The work is
> >going on in
> >> >TIA and is called Link Layer Discovery Protocol - Media Endpoint
> >> >Discovery (LLDP-MED), which is an extension of IEEE
> >802.1AB, specific
> >> >to VoIP systems. In LLDP-MED, among several other things, we have
> >> >specified ways to pass equivalent data to the DHCP
> >> >coordinate-based LCI (RFC 3825) and civic location LCI
> >> >(draft-ietf-geopriv-dhcp-civil-05, in Last Call process I
> >believe).
> >> >We see this method of delivery as a non-competing
> >alternative to the
> >> >DHCP-based approach, with the same end result to the overall ECS
> >> >system (the endpoint receives the exact same data), which has some
> >> >advantages particularly in enterprise deployment scenarios. (The
> >> >DHCP-based method has advantages in different scenarios.) I am
> >> >Editor of thi s document, and it is now in ballot process in TIA
> >> >(more or less equivalent to Last Call in IETF).
> >> >
> >> >Sorry, I expect I am suffering lack of context here, since I only
> >> >joined the list relatively recently.
> >> >
> >> >BTW, what is the state of geopriv-dhcp-civil? Is it now past Last
> >> >Call and in the RFC Editor's queue? It seemed to have been
> >> >settled on the list, and waiting on AD action.
> >> >
> >> >-- Peter Blatherwick
> >> >
> >> >
> >> >
> >> >
> >> >Andrew Newton <andy@hxr.us>
> >> >Sent by: geopriv-bounces@ietf.org
> >> >13.04.05 16:34
> >> >
> >> > To: GEOPRIV WG <geopriv@ietf.org>
> >> > cc:
> >> > Subject: [Geopriv] Announcement of Joint
> >GEOPRIV/ECRIT
> >> >Interim Meeting
> >> >
> >> >
> >> >
> >> >
> >> >The GEOPRIV and ECRIT working groups will be holding a
> >joint interim
> >> >meeting.
> >> >
> >> > What: Interim GEOPRIV/ECRIT meeting
> >> > When: 2005 May 16 08:30-17:30
> >> > 2005 May 17 08:30-17:30
> >> > 2005 May 18 08:30-17:30
> >> > Where: Columbia University
> >> > Dept. of Computer Science
> >> > 450 Computer Science Bldg.
> >> > 1214 Amsterdam Avenue (close to 120th St.)
> >> > New York, NY 10027
> >> >Directions: http://www.cs.columbia.edu/directions.html
> >> > Also: WiFi provided.
> >> > Teleconference to be provided.
> >> > Hotel: http://www.cs.columbia.edu/~hgs/etc/hotels.html
> >> > Early bookings recommended.
> >> >
> >> >Proposed GEOPRIV Agenda:
> >> > 2005 May 16 08:30-17:30, 2005 May 17 08:30-12:30
> >> >1) Role of HTTP as a transfer protocol for PIDF-LO vs. the
> >use of LI
> >> >in HTTP/HTML for web browsing.
> >> >2) Properties of network elements in transferring LI from layer 2
> >> >upward to PIDF-LO.
> >> >3) Proposed enhancements to PIDF-LO to support #2.
> >> >
> >> >Proposed ECRIT Agenda:
> >> > 2005 May 17 13:30-17:30, 2005 May 18 08:30-17:30
> >> >1) Emergency Call Routing Requirements
> >> >2) Security and Threats Analysis
> >> >
> >> >_______________________________________________
> >> >Geopriv mailing list
> >> >Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv
> >> >
> >> >
> >> >
> >> >
> >> >_______________________________________________
> >> >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
>
>_______________________________________________
>Geopriv mailing list
>Geopriv@ietf.org https://www1.ietf.org/mailman/listinfo/geopriv
cheers,
James
*******************
Truth is not to be argued... it is to be presented
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 21 Apr 2005 08:21:04 -0400
This archive was generated by hypermail 2.1.8 : Thu Apr 21 2005 - 08:43:41 EDT