Re: AW: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt

[Bernard Aboba <aboba@internaut.com>]

> we tried to respect the fact that people indicated that there might be a
> scenario where the nas does not know the location of the end host. if
> this is the case then the nas can only send its own location
> information. if it can include the location information of the end host
> (in case it is known) then the more precise info is sent. 

Right, but if the RADIUS server *requires* user location, that is what it 
will ask for in the Access-Challenge, and if the NAS doesn't supply it, it 
will send an Access-Reject eventually.   If the RADIUS server only wants 
NAS location, it can ask for that, or I suppose it could say "send me 
either one".  But the point is that it is the RADIUS server that is 
driving this conversation. 

> you seem to suggest that we add functionality to allow the radius server
> to request what information (end host vs. nas) it would like to see. we
> haven't yet heard this requirement and hence we haven't added it. 

Several of the high end 802.11 switches support location today, and there 
are location-based authorization servers on the market that are being 
deployed.   Typically, the APs utilize ToA processing to estimate location 
within a few feet.  So this is a real need and probably will garner at 
least as much (if not more) deployment than NAS location.  

In any case, since the document already supports an "Entity" field it is 
already possible for a NAS to send user location using the existing 
attributes.  What is missing is the ability of the RADIUS server to 
request the "entity" that it is interested in. 


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