[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: RE : Issue 74: RFC 3576 behavior



Is there any "send-location" attribute defined in the current draft?
No, there isn't yet.  But my understanding was that one will be added in the 
next version.
For me, there is nothing in the COA "instructing" the client to sed the location. I think that the >COA procedure is a way to retrieve once again location information received in a previous Access->Request (e.g. to check if the previous location is still up-to-date).
The problem is that RFC 3576 CoA-Requests don't have that semantic.  If no 
authorization was sent in the Access-Accept indicating that the NAS was to 
send location in all Access-Requests during a session, there is no reason 
for the NAS to send location in an Access-Request resulting from a 
CoA-Request.
In any case, if there is a desire for ongoing location information, RFC 3576 
shouldn't be used, rather the information should be sent in an Interim 
Accounting request.  So the "send-location" attribute needs to be clear 
exactly *when* location gets sent.  Is this in a single Access-Request, all 
Access-Request,  Access-Requests + Accounting Start/STOP,  also 
Accounting-Interim, etc.
The COA here just means "send a new access-Request". If during the previous exchange the NAS >has provided the location info, it is likely that the NAS will provide it once again. But there is no >way to mandate it through the COA request.
Actually, I would say that unless an authorization explicitly mandated 
location in an Access-Request, then the NAS should not send location, since 
its default behavior would not have changed (and the default is not to send 
location unless asked for it by the server).


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