"The options defined in this document can also be used to enable static or nomadic wireless hosts to obtain their location.
The DHCP server typically accomplishes this by determining the Access Point to which the host has attached.
Assuming that the location of the Access Point is known, the DHCP server can utilize this information to provide the
host with its location and an associated uncertainty region."
From: Martin.Thomson@andrew.com
To: bernard_aboba@hotmail.com; mlinsner@cisco.com; geopriv@ietf.org
Date: Wed, 11 Aug 2010 12:56:11 +0800
Subject: RE: [Geopriv] draft-ietf-geopriv-rfc3825bis
I think that the analysis in Ticket #38 is fair. The text is a definite improvement.
More inline below…
From: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Wednesday, 11 August 2010 7:34 AM
To: geopriv@ietf.org; mlinsner@cisco.com
Subject: Re: [Geopriv] draft-ietf-geopriv-rfc3825bis
Marc Linsner said:
"You might want to go back and figure out why this text was removed and suggest that it's put back in, or modified and put back in."
[BA] I've opened Ticket #38 on this. Some questions on the original text:
a. Is the text referring to use of the DHCP option or inclusion of the option format in other standards such as 11k?
11k allows the station knowledge of the location of the AP or itself, depending on the query. My impression was that
3825bis wasn't meant to update 11k though, right?
[MT] Of the two aspects of RFC 3825 (format, DHCP usage), 11k only uses the format. I don't think that we need to worry about the protocol semantics of 11k (or LLDP-MED for that matter).
b. Assuming that we are talking about the DHCP option, would there be an assumption that the AP is acting as a
DHCP relay, or that RADIUS attributes (such as NAS-Identifier or NAS-IP-Adress) were being passed to the DHCP
server? Otherwise, it wasn't clear to me how the DHCP server would be made aware of the location of the AP, so
that it could respond appropriately.
[MT] There are a lot of inherent assumptions in these sorts of statements. As far as DHCP semantics are concerned, the location is the location of the Device. The fact that this might be an uncertainty region centred on the AP is merely a consequence of the location determination process.
c. Assuming that the DHCP server is returning the AP location, why would additional mechanisms like GPS or a
list of APs close to the client be needed? If the host had GPS shouldn't it use that instead? Would the list of
APs be used for triangulation?
[MT] Though the determination process is out of scope, there are a few options. I think that it's safe to assume that the DHCP server is somehow able to identify the AP, however that happens. From here, there are a range of options, the simplest being to ascribe an uncertainty radius to the location of the AP.
[MT] The location of the AP is not what is provided - not directly. It's likely that the AP location is known with a fairly high degree of accuracy.
" Wireless hosts can utilize this option to gain knowledge of the
location of the radio access point used during host configuration,
but would need some more exotic mechanisms, maybe GPS, or maybe a
future DHCP option, which includes a list of geo-locations like that
defined here, containing the locations of the radio access points
that are close to the client"
[MT] This text is at best misleading. Even if we consider the labelling of GPS as "exotic" aside, there are problems with the text. The first is the implied assumption that the subject of the location can change based on some external information. That is, if the host is wireless, then the location doesn't pertain to the host, it instead applies to the AP serving the host. The second is the (rampant and unsupported) speculation on location determination methods.
[MT] We didn't get into this in great detail when we were discussing Ticket #20. I think that we'd already had several comments on this text being strange.
