RE: RFC3576bis and Session State

["Avi Lior" <avi@bridgewatersystems.com>]

See inline.... 

-----Original Message-----
From: Alan DeKok [mailto:aland@nitros9.org] 
Sent: Monday, May 28, 2007 11:37 AM
To: Avi Lior
Cc: David B. Nelson; radiusext@ops.ietf.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
mid-session.

[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
generated.


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

[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
Access-Request either.

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