Subject: RE: [AAA-WG]: [issue] Bug in Acct state machine + Split State Machines into Client vs. Server

From: <[email-masked]>
Date: Wed, 3 Apr 2002 16:21:23 +0300

Hi,

> > >I'm not sure what you are missing, can you clarify?
> > >The state machine does have Open-> PendingI and then
> > >5 different actions on what to do there.
> > >
> > What do the I, B, E, S and L  letters denote anyway? I could try to
> > guess but I'd rather not.
> 
> PendingI=Interim/B=Buffer/E=Event/S=Start/L=Stop

I guess those should be added to the text ...

John

---

From: <[email-masked]>
Date: Fri, 5 Apr 2002 07:28:05 +0300

Hi all,

From my current reading of the Accounting State Machine,  It looks
like the state machine is actually stateless.  I mean that an 
Accounting Server can recieve messages at any time.  I think
the current discussion is comes from a different perspective
(or misunderstanding) of what the accounting server will do.

If we consider the accounting server to be stateless, then we
may want to clarify it.  If we think that it should be 
stateful, then Marco's text is probably good - however,
we will need more text to handle failure cases.

So, the question is: should the accounting server
be stateful or stateless?

John

> -----Original Message-----
> From: ext Pete McCann [mailto:[email-masked]]
> Sent: 04 April, 2002 19:39
> To: Jari Arkko
> Cc: Lialiamou Elena (NET-IMN/Helsinki); [email-masked];
> [email-masked]
> Subject: Re: [AAA-WG]: [issue] Bug in Acct state machine + Split State
> Machines into Client vs. Server
> 
> 
> 
> Hi,
> 
> Jari Arkko writes:
>  > Perhaps this is our way to a compromise. Why don't we state
>  > the situation about the potential immediate use or just
>  > storage of the records in the document. For instance:
>  > 
>  > "Note that the server side state machines requires the
>  > reception of accounting records and does not place any
>  > standards requirement on the processing of these records.
>  > Implementations of Diameter MAY perform checking, ordering,
>  > correlation, fraud detection, and other tasks based on 
> these records.
>  > Both base Diameter AVPs as well as application specific
>  > AVPs MAY be inspected as a part of these tasks.
>  > The tasks can happen either immediately after record
>  > reception or in a post-processing phase. However, as these
>  > tasks are typically application or even policy dependent,
>  > they are not standardized by the Diameter specifications."
> 
> I think this text is quite reasonable, and I would even support
> removing the state machine entirely and replacing it with this text
> and a bit of explanation.  The only reason my original proposal had an
> "Open" state was because it was a cut-and-paste of what was already
> there.  However, after reading the discussion on the issue, I don't
> think we should place any requirements on the order in which
> accounting records arrive at the accounting server, which is what a
> state machine would essentially do.  State machines define sets of
> acceptable event strings, and by definition other strings are not
> acceptable.  I think the discussion has shown that there is no
> reasonable way to react differently to an "unacceptable" string of
> events because there may not be any connection to the authorization
> state machine.  The server might throw away the entire string, but
> personally I think it's better to keep it so you can try to 
> figure out 
> what happened later.
> 
> -Pete
>

---

From: <[email-masked]>
Date: Fri, 5 Apr 2002 07:30:20 +0300

Hi All,

I've added this text to 8.2, as the last paragraph before the state
machines.

John