Re: RFC3576bis and Session State

[Alan DeKok <aland@nitros9.org>]

Glen Zorn (gwz) wrote:
> I think the point is that there may be multiple accounting sessions
> (either serial or parallel) authorized by a single
> Access-Request/-Reply, all with different session IDs and maybe even
> members of different groups (so different Acct-Multi-Session-IDs, so
> unless the RADIUS server receives _all_ the stop and stop records it
> can't know about those.

  Then we need a new session key, independent of other keys.

>  Are we saying then, that _only_ the original
> session may be affected by CoA?  If so, maybe it would be better to have
> a session-ID specifically for that instead of overloading the
> Acct-Session-ID attribute.  

  I want CoA to be as flexible as possible.  i.e. Contain many
attributes to define what it is changing.

  I want CoA to be inter-operable, and implementable.  i.e. Define a key
for CoA that does not involve guessing what the NAS might think is a
unique session identifier.

> So is using the accounting session ID, for the reasons outlined above.

  Then we define a new session identification attribute.  Maybe
Acct-Multi-Session-Id can be used, as it appears to be defined as an
aggregation point for multiple sessions.

  Alan DeKok.

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