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

From: <[email-masked]>
Date: Thu, 28 Feb 2002 08:52:58 +0200

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:21:26 +0200

Ok so for the most part 271 solves 272 issues as well.
(271 also does some additional things, such as handle the
buffering of acct messages.)

As for the spontanous updating, I think the intent at least
of the spec has been that the base provides you exactly one
mandatory situation to update: the interim production per
the interval. When - not if - there is a need to have updates
at other situations, the design allows for a new AVP to be
designed in a specific application document. This AVP could
be sent by the accounting server in the start answer to
instruct the client to produce accounting interim records
in some application specific way, e.g. every time the QoS
of a link is modified. This would enable you to provide
spontaneous records, for instance, by having the accounting
server indicate in the start answer that by Accounting-Spontaneous
AVP. The part about the semantics of your specific proposal e.g.
more credit is needed -- I think that too can be handled by
an application specific AVPs in the accounting requests. (Note
that when the first application is designed that does this,
it is perfectly OK for other apps to refer to these AVPs and
require their use, so work doesn't have to be duplicated.)

In conclusion I think 271 solution is sufficient for base, and
the approach outlined above can be provided in a new apps document.
However, we discussed modifying 271 proposed text to allow the
acct server control the realtime flag. I propose modifying
start of 9.8.x by adding " or in the Accounting-Answer from
the accounting server" just before the first ".".

Jari