[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: [Geopriv] RE: Review of draft-ietf-geopriv-radius-lo-04.txt
> 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 firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.