[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RFC3576bis and Session State
From: Alan DeKok [mailto:email@example.com]
Sent: Monday, May 28, 2007 11:37 AM
To: Avi Lior
Cc: David B. Nelson; firstname.lastname@example.org
Subject: Re: RFC3576bis and Session State
Avi Lior wrote:
> I suggest we can request that they implement it now, *if* they also
> support CoA or Disconnect request.
> [Avi] I strongly disagree. Requiring that a RADIUS server that will
> issue a COA or DM receive accounting messages is inappropriate.
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.
> [Avi] A session id for what? Accounting Session ID identifies a An
> accounting session delineated by a Start Record and a Stop Record.
> Including Acct-Session-Id in a DM or COA means you want to effect that
> session that is being represented by that Accounting Session. That
> session could be:
> 1) The entire session;
> 2) An IP session;
> 3) An IP flow;
> 4) Something else that generates an Accounting Record.
If the the CoA client doesn't know what session it's trying to change,
it shouldn't be sending a CoA request.
[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.
If it does know what session it's trying to change, it should inform
the NAS that the *session* needs changing. Using IP
address/port/whatever as session identification keys is unacceptable.
It may work sometimes, but it has the problem of being protocol
specific, in addition to making impossible to change protocol parameters
[Avi] We are building a toolkit. There are many different kinds of
sessions. Even Acct-Session-Id is ambiguous at best. What session is it
representing? The only thing you can say it that it is representing a
particular Start/Stop accounting segment. Beyond that you cant say
anything unless you know when an accounting start/stop segement is being
> So I am okay with including Accounting Session Id. But we need some
> clarification text. Something like:
> "If Acct-Session-Id is included in the COA or DM, then that message
> SHALL effect the session that is identified by the Acct-Session-Id
Pretty much, yes.
[Avi] Good. But note that I am not mandating its includsion. So I am
glad you agree. And it should not be mandate to include in an
to unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.