Re: RADIUS-GEOPRIV and Capabilities

[Bernard Aboba <aboba@internaut.com>]

> draft-lior-radext-end-to-end-caps-01.txt document) i would like to
> confirm that 
> a) it is ok to define a registry in the radius-geopriv document and 
> b) to register two values (require for radius-geopriv)

BTW, does the current GEOPRIV-RADIUS location document address the issues 
that were raised in RADEXT WG review? 

It is not clear to me that the kind of capability  negotiation you are 
proposing makes sense in this application.  RADIUS accounting servers can 
handle unknown attributes. Since a RADIUS server may be doing 
location-based authorization, a RADIUS client may need to send location 
or its Access-Request will be rejected.  In that situation, the RADIUS 
client needs to send location before negotiation is possible. 

It seems like the issue could be handled without having the client 
announce capabilities at all.  The client is set up by default to either 
send or not send location information.  If the server has a problem with this, 
it rejects the request and indicates that location data is needed.  Since 
Access-Reject messages cannot request a service, this probably needs to be 
accomplished via an error-message, rather than inclusion of a location 
attribute. 



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