Re: RFC3576bis and Session State

[Alan DeKok <aland@nitros9.org>]

Avi Lior wrote:
>   Which is why I didn't suggest that the server receive accounting
> messages.  What I said was that it should receive a protocol-independent
> session identification key... sometimes called Acct-Session-Id.
> 
> [Avi] Yes but it can only receive one and there can be many Accounting
> Session Ids, and they can change.  

  Then we need a new session identification attribute that doesn't change.

> [Avi] It may want to kill all the "sessions" that are associated with a
> given User Identity.  The po0int of the above is that there are many
> things you can call a "session". You seem to focus on only one of them
> which is a session represented by a Start/Stop record.

  No.  I'm focusing on a session key that is independent of protocol,
NAI, CUI, or anything else.  If you pick an attribute that MAY be used
as a key, I can pick a scenario where that attribute does not exist, and
is therefore useless for CoA.

  We can say that the RADIUS server trolls through it's database,
looking for an attribute that *might* be a session key, or we can say
that the RADIUS server uses the session key sent to it by the NAS.  I
have my belief about which one is simpler to implement, deploy, and be
interoperable.

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