Re: Review of draft-ietf-geopriv-http-location-delivery-07

At Sun, 25 May 2008 15:54:16 -0700,
Eric Rescorla wrote:
> 
> At Sun, 25 May 2008 22:39:24 +0300,
> Hannes Tschofenig wrote:
> > 
> > Hi Ekr,
> > 
> > Eric Rescorla wrote:
> > > At Sun, 25 May 2008 19:19:58 +0300,
> > > Hannes Tschofenig wrote:
> > >   
> > >> Hi Ekr,
> > >>
> > >> Eric Rescorla wrote:
> > >>     
> > >>> $Id: draft-ietf-geopriv-http-location-delivery-07-rev.txt,v 1.1 2008/05/24 15:03:19 ekr Exp $
> > >>>
> > >>> TECHNICAL
> > >>>
> > >>>
> > >>> S 4.2.
> > >>>    which a Location Recipient (LR) can use to retrieve LI.  A location
> > >>>    URI provided by a LIS can be assumed to be globally-addressable; that
> > >>>    is, anyone in possession of the URI can access the LIS.  However,
> > >>>    this does not in any way suggest that the LIS is bound to reveal the
> > >>>    location associated with the location URI.  This issue is deemed out
> > >>>
> > >>> I don't understand this point. anyone in possession of the URI can
> > >>> access the URI but the LIS isn't required to reveal it? Those
> > >>> seem kind of contradictory.
> > >>>
> > >>>   
> > >>>       
> > >> Compare this with a HTTP URL where you might know it but still there are 
> > >> access policies that control access.
> > >> Possession does not necessarily mean that you can always get the location.
> > >>     
> > >
> > > OK. That makes sense. Perhaps rewrite:
> > > "access the LIS and request the location associated with the URI. 
> > > However, this this does not imply that the LIS is bound to service
> > > the request. For instance, the LIS might reject the request for
> > > access control reasons."
> > >
> > >   
> > Sounds good.
> > 
> > 
> > >   
> > >>> S 4.3.1.
> > >>>    Devices that establish VPN connections for use by other devices
> > >>>    inside a LAN or other closed network could serve as a LIS, that
> > >>>    implements the HELD protocol, for those other Devices.  Devices
> > >>>    within the closed network are not necessarily able to detect the
> > >>>    presence of the VPN and rely on the VPN device.  To this end, a VPN
> > >>>    device should provide the address of the LIS server it provides, in
> > >>>    response to discovery queries, rather than passing such queries
> > >>>    through the VPN tunnel.
> > >>>
> > >>> How do you envision this happening? Isn't this going to require 
> > >>> changing every VPN protocol? I think some more text would be 
> > >>> appropriate here...
> > >>>
> > >>>   
> > >>>       
> > >> It requires location information to be obtained before the tunnel is setup.
> > >>     
> > >
> > > OK, but I still don't understand how this is going to work. Say that
> > > I'm on a local network with a DHCP server and the VPN server is a couple
> > > of hops away. How does the VPN device "provide the address of the LIS
> > > server" to me?
> > >
> > >
> > >   
> > When you operate a network and you want this stuff to work then you have 
> > to consider this aspect.
> > In the past a few folks have suggested to write a BCP about how 
> > different deployments may deal with this aspect but I believe it is far 
> > too early todo so for a BCP.
> 
> The problem is that I'm not sure that this is an issue that can be solved 
> by the network operator. In the example I described, it sounds to
> me like new protocol work may be required.
> 
> 
> > >> The reference points to the device. What the Target uses this reference 
> > >> either for itself (if it wants to learn it's own location) or (more 
> > >> likely) it forwards that URI to someone else, for example to a PSAP.
> > >>     
> > >
> > > OK, but then what protocol is spoken over that URI? (see my 
> > > comments on S 8 below).
> > >
> > >
> > >   
> > The answer is:
> > http://tools.ietf.org/id/draft-winterbottom-geopriv-deref-protocol-00.txt
> 
> What's the status of that document?

Oh, and doesn't this need to be a normative ref, then?

-Ekr
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf