RE: [Geopriv] Terms on this thread

["Abbott, Nadine B." <[e-mail]>]

Thanks for the reminder, James, I think that will help.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of James M. Polk
Sent: Wednesday, April 20, 2005 11:44 PM
To: GEOPRIV WG; [e-mail]
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: [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

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