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