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

["Tschofenig, Hannes" <hannes.tschofenig@siemens.com>]

hi bernard, 

i went through your suggestions and i don't think i have a disagreement
with what you say. 

ciao
hannes

> > The radius server might also understand either civic, 
> geospatial or  both. 
> 
> We need to distinguish between the RADIUS Accounting Server 
> and the RADIUS 
> Authentication Server.  The RADIUS Accounting Server can be 
> assumed to 
> "understand" anything (e.g. it just writes AVPs to stable 
> storage).  The 
> RADIUS Server should be thought of as either REQUIRING or NOT 
> REQUIRING an 
> attribute.  If an attribute is REQUIRED the RADIUS Server 
> will request it 
> in an Access-Challenge.  
> 
> > whether the desire to support this functionality justifies 
> the introduction of an avp is subject for discussion. 
> 
> I think there is a need for an attribute to be sent from the 
> RADIUS Server 
> to the NAS to describe what it wants (e.g. Geospatial, Civil),
> what 
> location is to be sent (user or NAS)),
>  and how it 
> wants it.  Presumably this attribute can be sent in an 
> Access-Challenge. 
> 
> There is also a need for location attributes, to be sent from 
> the NAS to 
> the RADIUS server. 
> 
> However, I don't see a need for "Capabilities Announcement" 
> by the NAS. 
> > this was the approach that was suggested to us in previous 
> discussions. 
> > sounds good to me. 
> 
> The Access-Challenge approach is ok only if it is made clear 
> that a NAS 
> that is not expecting an Access-Challenge MUST treat it as a 
> Reject, as 
> mandated in RFC 2865.  And of course, a RADIUS Server MAY 
> send a Reject if 
> the Challenge isn't answered correctly, so you need to 
> support that case 
> or the NAS/RADIUS server exchange could go on indefinitely. 
> 
> > i guess you would suggest to return an access reject if the nas is 
> > unable to understand the returned location information format. 
> 
> The NAS can't send an Access-Reject.  It can only treat the 
> Challenge as 
> an Access-Reject. 
> 
> > this requirement hasn't been presented to me yet. 
> 
> Given that it's the RADIUS server that is determining what is needed, 
> there needs to be a way for the server to actually request 
> what it needs.  A 
> given RADIUS server may require user location (there are 
> installations 
> today that do locatoin-based authorization) in geospatial or 
> civil format. 
> Or it just may need NAS location.  
> 
> > i hope it is simple. 
> 
> From the RADEXT WG discussion so far, it does appear to be 
> quite simple.  
> 

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