Subject: RE: [AAA-WG]: Issue 271: comments needed

From: <[email-masked]>
Date: Thu, 28 Feb 2002 11:55:32 +0200

Hi,

Harri wrote:
>What do you mean by 'granted threshold' and 
>how do you define it ?
>Is it time ? data volume ? number of events ? Monetary unit ?

I simply mean that threshold is some value (e.g. Interim-Interval 
in seconds in basic cases) which client can decrease before the new
ACR must be sent. The type of the threshold could be anything
as long as it is measurable and understanable to client (and server).

br,
JPK   
-----Original Message-----
From: ext Harri Hakala (LMF) [mailto:[email-masked]]
Sent: 28. February 2002 9:44
To: Koskinen Juha-Pekka (NET/Tampere); [email-masked]
Cc: Loughney John (NRC/Helsinki); [email-masked]
Subject: RE: [AAA-WG]: Issue 271: comments needed

Hi,

I agree with Jukka-Pekka that the spontaneous
updating (from client to server) would be helpful.
There are events in the client side that needs to be
reported before the Accounting-Interim-Interval expires.
These events might contain information which affects the
current rating of the service.
In my opinion this is really needed to be able to fulfill
the statement in section 9.1 "real-time transfer of accounting
records is a requirement, such as the need to perform credit limit
check and fraud detection".

What do you mean by 'granted threshold' and 
how do you define it ?
Is it time ? data volume ? number of events ? Monetary unit ?

Regards.......Harri

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: 28. helmikuuta 2002 8:53
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [AAA-WG]: Issue 271: comments needed

Hi,

The 272 includes also one item which has not been discussed yet.
Among the new Accounting-Record-Type(s) introduced in 272 
there is also value for record which could be used when spontaneous
updating (from client to server) of ongoing acc session is needed. 
I think this is also needed even in basic acc sessions. 

How/should this be included in base?

Anyway, I think that basic idea of 271 and this 
updating_possibility_from _client_to_server
are both needed.

br,
JPK

-------- inc. --------------------
>UPDATE_PREPAID		7
> 	An Accounting Update Prepaid record is used to indicate
> that a prepaid service will need more credit to continue. It is
> also used when service (client) need to update itself tariff of
> the ongoing accounting session. This record contains all
> information that is relevant to determine cost of the service and
> granted threshold.
-------- inc. ---------------------

-----Original Message-----
From: ext Jari Arkko [mailto:[email-masked]]
Sent: 27. February 2002 17:18
To: Koskinen Juha-Pekka (NET/Tampere)
Cc: Loughney John (NRC/Helsinki); [email-masked]
Subject: Re: [AAA-WG]: Issue 271: comments needed

Ah, now I see that 272 is also discussed under this thread. Sorry
for the confusion. Anyway, to answer Juha-Pekka first: The new
AVP design was actually that it would be sent from the auth server
to the NAS. Additionally, we could allow also it come from the acct
server in the responses. In any case, if you are not using
authentication and didn't get any response from the acct server,
then there's theoretically no way to figure out what to do with
the service, unless local configuration knows. So, it would seem
to me that providing both auth server and acct server responses
with this new AVP where needed would satisfy all needs.

However, my proposal for realtime-required avp was actually
a bit different than what I understood issue 272 to want to have.
Basically, there are two things:

  - Whether you want to give service if you can't send in acct data
  - Priority order between queued records at an accounting server or
    proxy

The realtime-required AVP deals with the first issue. The new AVP
I was talking about in issue 272 deals with the second issue. If you
think we're fine with just the first service then we could just agree
on 271 and reject 272. If not, we need to do something also for
272. I believe 271 needs to be done in any case, because the current
spec is inconsistent.

Jari

[email-masked] wrote:

> Hi,
> 
> Well what I wonder here is if this
>  
> 9.8.x. Accounting-Realtime-Required AVP
> 
> is supposed to be sent to the client in the very first ACA from accounting server but the server doesn't response at all? Or how this will work, I might be lost...
> 
> The new Accounting-Record-Types 5-8 might work more flexible in this case but maybe Jari can give us some comments.
> 
> br,
> JPK     
> 
> -----Original Message-----
> From: Loughney John (NRC/Helsinki) 
> Sent: 27. February 2002 13:34
> To: Koskinen Juha-Pekka (NET/Tampere); [email-masked]'
> Cc: [email-masked]'
> Subject: RE: [AAA-WG]: Issue 271: comments needed
> 
> 
> Hi Juha,
> 
> 
>>As Jari has stated: 
>>"..in some cases we would like to stop services if we can't 
>>provide real-time accounting, while in some other cases we would like
>>to continue."
>>
>>That was also in my mind when I suggested issue 272. There is 
>>cases where the accounting records could simply be stored by 
>>the client if the accounting server doesn't response even to 
>>intial ACR but in some cases the services must be stopped if 
>>ACA is not received. That was the reason I proposed new 
>>Accounting-Record-Type values 5-8. When these values (5-8) is 
>>sent in ACR, the service must be stopped if ACA is not received. 
>>
> 
> Do you think that Jari's comments are enough for both issues (271 & 272)?
> Or do you have other text?
> 
> John
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 28 Feb 2002 22:28:07 +0200

> as long as it is measurable and understanable to client (and server).

Exactly, and this confirms what I just said to Harri about
INTERIM_RECORD being suitable for this new purpose and just
new triggers are needed. So, if in your application the generic
periodic update is not sufficient, you can define a new update
trigger. For instance, Accounting-Interim-Chicken-Interval AVP
defines the interval as the number of eggs a chicken may have produced
before an INTERIM_RECORD must be sent.

Jari