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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf