Subject: Re: [Geopriv] draft-ietf-geopriv-rfc3825bis

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Aug 2010 14:33:37 -0700

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?

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. 

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? 

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 11 Aug 2010 12:56:11 +0800

I think that the analysis in Ticket #38 is fair.  The text is a definite improvement.

More inline below…

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Wednesday, 11 August 2010 7:34 AM
To: [email-masked]; [email-masked]
Subject: Re: [Geopriv] draft-ietf-geopriv-rfc3825bis

Marc Linsner said:

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.

[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.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 10 Aug 2010 22:19:04 -0700

Given the analysis you've provided below, where do we go from here?   Would something along these lines make sense?

"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: [email-masked]
To: [email-masked]; [email-masked]; [email-masked]
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: [email-masked]
[mailto:[email-masked]] On Behalf Of Bernard Aboba

 

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."

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

[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

[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

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Wed, 11 Aug 2010 14:48:42 +0800

If anything, I would advocate the retention of the existing text (-11).  I don’t really think that you can get into too much more detail without ending up in the location determination rathole.

Stating that location determination is out of scope would be the only sort of addition that I would support.  There is some text on location determination at the moment, but it’s after a “For example,” so I don’t care if it stays.

--Martin

From: Bernard Aboba [mailto:[email-masked]]
Sent: Wednesday, 11 August 2010 3:19 PM
To: Thomson, Martin; [email-masked]
Subject: RE: [Geopriv] draft-ietf-geopriv-rfc3825bis

________________________________

More inline below…

Marc Linsner said: