[Geopriv] Terms on this thread

["James M. Polk" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf Of
>Michael Hammer (mhammer)
>Sent: Wednesday, April 20, 2005 12:00 PM
>To: Brian Rosen; [e-mail]
>Cc: GEOPRIV WG; [e-mail]
>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:[e-mail]]
> >Sent: Wednesday, April 20, 2005 10:47 AM
> >To: Michael Hammer (mhammer); [e-mail]
> >Cc: 'GEOPRIV WG'; [e-mail]
> >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:[e-mail]]
> >> Sent: Wednesday, April 20, 2005 10:14 AM
> >> To: Brian Rosen; [e-mail]
> >> Cc: GEOPRIV WG; [e-mail]
> >> 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: [e-mail] [mailto:[e-mail]] On
> >> >Behalf Of Brian Rosen
> >> >Sent: Wednesday, April 20, 2005 9:54 AM
> >> >To: [e-mail]
> >> >Cc: 'GEOPRIV WG'; [e-mail]
> >> >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: [e-mail] [mailto:[e-mail]] On
> >> >Behalf Of [e-mail]
> >> >Sent: Wednesday, April 20, 2005 9:30 AM
> >> >To: Andrew Newton
> >> >Cc: GEOPRIV WG; [e-mail]
> >> >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 <[e-mail]>
> >> >Sent by: [e-mail]
> >> >13.04.05 16:34
> >> >
> >> >        To:        GEOPRIV WG <[e-mail]>
> >> >        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
> >> >[e-mail] https://www1.ietf.org/mailman/listinfo/geopriv
> >> >
> >> >
> >> >
> >> >
> >> >_______________________________________________
> >> >Ecrit mailing list
> >> >[e-mail]
> >> >https://www1.ietf.org/mailman/listinfo/ecrit
> >> >
> >>
> >
> >
>
>_______________________________________________
>Ecrit mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/ecrit
>
>_______________________________________________
>Geopriv mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/geopriv


cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

_______________________________________________
Geopriv mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/geopriv