Re: Review of draft-ietf-geopriv-radius-lo-04.txt

[Bernard Aboba <aboba@internaut.com>]

> > > Am I missing something, or is the problem really this simple? 
> > 
> >   It would appear so.

The "server-driven" approach also provides a mechanism to address RADEXT 
Issue 27 (Who's Location). 

One of the major problems with the RADIUS-GEOPRIV document is that it 
does not support user location determination, only  NAS location. 

This is a problem for vendors who are shipping APs with built-in 
location support that enables APs to pinpint the location of associated 
stations.  At least one RADIUS server implementation now supports 
"location-based access control".  Why can't the RADIUS-GEOPRIV 
specification be used to send user as well as NAS location? 

This basic problem with the document was pointed out in November 2004, but 
has still not been fixed in August 2005, 9 months later.  

However, using the "server-driven" approach, the problem would  
not be hard to address.  In the "send location" attribute included by the 
server, the server can specify what type of location data it is looking 
for - user or NAS.  

Note that layer 2 standards such as IEEE 802.11k already enable this 
distinction.  In IEEE 802.11k a station can ask either for its own 
location or the location of the AP.  

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>