Re: [Geopriv] On behalf of - OBO

["Winterbottom, James" <[e-mail]>]

Hi Barbara,

LIS to LIS can be achieved using HELD with measurements (http://tools.ietf.org/html/draft-thomson-geopriv-held-measurements-02) and/or HELD with identity extensions (http://tools.ietf.org/html/draft-winterbottom-geopriv-held-identity-extensions-05)

I think all we need is a BCP around these two drafts saying how this is done. I had a draft some time ago saying how this could be done, it needs some modifications now, but is basically still sound.

This was given as much support to go forward with as the location URI in DHCP if you check the meeting minutes from Prague last year. Consequently it should already be supported in the charter. I didn't push it further because nobody seemed to be asking for it, since they are now I will resurrect it.

Cheers
James


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Stark, Barbara
> Sent: Thursday, 26 June 2008 12:49 AM
> To: Matt Lepinski
> Cc: [e-mail]; Dawson, Martin; Marc Linsner
> Subject: Re: [Geopriv] On behalf of - OBO
> 
> I agree that if an OBO mechanism is defined, then it can be used for LIS-
> LIS. But we also, in the past, I think, decided to consider LIS-LIS and
> OBO as distinct use cases.
> 
> Anyway, I need a LIS-LIS solution for this whole thing to work, because
> the ISP is so often not the same as the access provider. When the end user
> discovers a LIS, it will be the ISP LIS, because access providers
> frequently do not "see" or have access to the IP layer, and isn't
> responsible for IP connectivity. But the ISP doesn't know what physical
> circuit the target is on. The ISP LIS in such a case will need to send the
> access provider LIS a query for location.
> 
> I agree absolutely that the requesting LIS must be authenticated by the
> requested LIS. And, I think, the requesting LIS should also be able to
> trust the requested LIS.
> 
> I'm not sure how you would expect the target to control use of LIS-LIS
> communication. The target has no ability to communicate with the access
> provider LIS to express preferences, because there is no direct
> relationship. Or should the target tell the ISP LIS to relay a message to
> the access provider LIS, that it shouldn't talk to the ISP LIS? If the
> access provider isn't supposed to trust the ISP LIS, then that relayed
> message can't be trusted, either. I'm having a hard time understanding the
> idea that the target can control LIS-LIS.
> Barbara
> 
> -----Original Message-----
> From: Matt Lepinski [mailto:[e-mail]]
> Sent: Wednesday, June 25, 2008 9:57 AM
> To: Stark, Barbara
> Cc: Francois Menard; Dawson, Martin; [e-mail]; Marc Linsner
> Subject: Re: [Geopriv] On behalf of - OBO
> 
> Barbara,
> 
> I belive that HELD identity extensions (the OBO mechanism discussed at
> the Interim) would work as a mechanism for LIS-LIS as well.
> 
> As written, HELD identity extensions allows the HELD requestor (the
> proxy for the legacy device in the OBO use-case, but potentially a LIS
> in the LIS-LIS use-case) to attach identity information about the target
> (e.g. IP address, MAC address, etc). In response to such a requrest the
> HELD responder (the LIS who knows the target's location) could then
> respond with the location of the target.
> 
> Clearly, for the LIS-LIS use-case (as with the OBO use-case) there would
> need to be authentication of the requestor to ensure the request came
> from a trusted LIS, and the target would need to have ultimate control
> over when this mechanism could be used, as should always be the case in
> Geopriv (with the ussual caveat that if this mechanism is used to
> provide location for emergency calls, in most jurisdications a user will
> not be allowed to opt-out of providing location in the event of an
> emergency).
> 
> There's still significant work to be done to draft suitable text on when
> (in what network scenarios) the OBO use-case of Identity Extensions can
> and cannot be reasonably deployed, and what privacy safe-guards must be
> put in place to ensure that only trusted entities (as defined by the
> target) gain access to the target's location. However, it seems to me
> that there's no reason we could not also draft similar text for the
> LIS-LIS use-case if we wished to use HELD w/Identity Extensions as a
> LIS-LIS mechanism
> 
> - Matt Lepinski
> 
> Stark, Barbara wrote:
> 
> >Please drop the rhetoric and name-calling. It's really not necessary.
> >
> >I never heard OBO being proposed as a mechanism to prevent SIP location
> conveyance. In my discussions with service providers, many would prefer
> not to ever do OBO for emergency services, because of potential liability
> if they get it wrong. Others agree, but are concerned that regulators in
> their countries will insist on the capability as part of a transition
> (when few end devices are deployed that support location), and that lack
> of a standard will make it more difficult to meet such a regulatory
> requirement.
> >
> >With that said, I don't give a flip if IETF does anything about OBO. I
> certainly won't be trying to fight for it if means weathering attacks,
> accusing me of wanting to damage the Internet. [But I do still want a LIS-
> LIS mechanism, which I assume is now completely separate from OBO?]
> >Barbara
> >
> >-----Original Message-----
> >From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Francois Menard
> >Sent: Wednesday, June 25, 2008 7:12 AM
> >To: Dawson, Martin
> >Cc: [e-mail]; Marc Linsner
> >Subject: Re: [Geopriv] On behalf of - OBO
> >
> >
> >OBO is by design 'intelligence in the network' rather than end-to-end.
> >
> >OBO is all about NOT being allowed to do 'SIP Location Conveyance' for
> >E-9-1-1.
> >
> >It would be a disservice to the market to allow the big telcos to get
> >OBO standardized at the IETF, such that this become imposed in the end
> >by the CRTC and the FCC.
> >
> >Given the opportunity, they'll scrap the Internet in a few seconds.
> >
> >OBO is out of scope of Geopriv.
> >
> >F.
> >
> >
> >On 24-Jun-08, at 9:51 PM, Dawson, Martin wrote:
> >
> >
> >
> >>Hey Marc,
> >>
> >>Not that I see these goals being expressed in this fashion in
> >>RFC3935 but nevertheless:
> >>
> >>(1) enhancing the end user experience
> >>
> >>Having the location of their emergency call delivered through the
> >>Asterisk server likely qualifies as an enhanced experience for a
> >>user I should think. As does having their call for the janitorial
> >>officer being routed to the guy who works their actual building for
> >>that matter.
> >>
> >>(2) making the network work better.
> >>
> >>Comparing the situation above where, on the one hand, the enterprise
> >>VoIP services don't work and, on the other, they do work - I think
> >>we can consider the latter as "better".
> >>
> >>Cheers,
> >>Martin
> >>
> >>From: Marc Linsner [mailto:[e-mail]]
> >>Sent: Wednesday, 25 June 2008 4:16 AM
> >>To: Dawson, Martin; [e-mail]
> >>Subject: Re: [Geopriv] On behalf of - OBO
> >>
> >>Martin,
> >>
> >>Here is my viewpoint.
> >>
> >>The IETF is about:
> >>
> >>(1) enhancing the end user experience
> >>(2) making the network work better.
> >>
> >>GeoPriv is about providing the end user tools to assist with the
> >>privacy/security of his/her location information.
> >>
> >>I don't find a fit for OBO in the above.
> >>
> >>-Marc-
> >>
> >>
> >>
> >>
> >>On 6/21/08 6:59 AM, "Dawson, Martin" <[e-mail]> wrote:
> >>Hi Marc,
> >>
> >>Which clause(s) in the charter do you consider to prohibit OBO?
> >>
> >>Do you favour changing the charter? Do we need a different WG to
> >>define useful location service protocols? Can we do these things
> >>without slowing down practical progress? There are forums out there
> >>- e.g. OMA, WiMAX forum - who are continuing to define technology-
> >>specific location protocols that don't observe the Internet model
> >>for consistent service definitions and which will ultimately impede
> >>the reliable deployment of emergency services amongst other things.
> >>A routine objection when IETF protocols are proposed is that the
> >>specifications don't exist yet.
> >>
> >>Saying that people are running amuck (sic) is emotive language - I
> >>don't believe it is an accurate representation of what is going on.
> >>
> >>Cheers,
> >>Martin
> >>
> >>From: [e-mail] [mailto:[e-mail]] On
> >>Behalf Of Marc Linsner
> >>Sent: Saturday, 21 June 2008 7:31 AM
> >>To: [e-mail]
> >>Subject: [Geopriv] On behalf of - OBO
> >>
> >>Looking through the draft minutes and thinking about the discussion
> >>at the Interim meeting, I want to bring the discussion of OBO to the
> >>list.  As I stated at the meeting, IMO, GeoPriv was created for the
> >>purpose of providing mechanisms for the end-user to protect the
> >>privacy of his/her location information.   To date, this wg has
> >>created two location configuration protocols, modified SIP Presence
> >>to carry location information, and location conveyance via SIP
> >>appears imminent.
> >>
> >>IMO, there appears to be a strong desire to solve all the world
> >>problems wrt location, regardless if the solutions to these problems
> >>run amuck with the charter/intention of the GeoPriv work group.  OBO
> >>runs amuck with the end-user being able to protect the privacy of
> >>his/her location information.  I understand there are desires to
> >>support any/all use cases, some of which can only be solved by using
> >>solutions like OBO.  Not all requirements have solutions.  I think
> >>GeoPriv needs to acknowledge/accept this fact, or change it's charter.
> >>
> >>-Marc-
> >>
> >>
> >>
> >>------------------------------------------------------------------------
> ------------------------
> >>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]
> >>
> >>_______________________________________________
> >>Geopriv mailing list
> >>[e-mail]
> >>https://www.ietf.org/mailman/listinfo/geopriv
> >>
> >>
> >>
> >>------------------------------------------------------------------------
> ------------------------
> >>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]
> >>_______________________________________________
> >>Geopriv mailing list
> >>[e-mail]
> >>https://www.ietf.org/mailman/listinfo/geopriv
> >>
> >>
> >
> >--
> >François D. Ménard
> >[e-mail]
> >
> >
> >
> >--
> >Francois Menard
> >[e-mail]
> >
> >
> >
> >_______________________________________________
> >Geopriv mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/geopriv
> >_______________________________________________
> >Geopriv mailing list
> >[e-mail]
> >https://www.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. GA621
> 
> 
> _______________________________________________
> Geopriv mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
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]

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