Re: RFC3576bis and Session State

[Alan DeKok <aland@nitros9.org>]

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] 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.

  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
mid-session.

> 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
> only."

  Pretty much, yes.

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