RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change

"Ahmad Muhanna" <amuhanna@nortelnetworks.com> Fri, 04 June 2004 13:59 UTC

Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10071 for <aaa-archive@lists.ietf.org>; Fri, 4 Jun 2004 09:59:42 -0400 (EDT)
Received: by trapdoor.merit.edu (Postfix) id 58FC4912B8; Fri, 4 Jun 2004 09:59:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id 265F6912B9; Fri, 4 Jun 2004 09:59:29 -0400 (EDT)
Delivered-To: aaa-wg@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9C1D912B8 for <aaa-wg@trapdoor.merit.edu>; Fri, 4 Jun 2004 09:59:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix) id A6E9059D22; Fri, 4 Jun 2004 09:59:27 -0400 (EDT)
Delivered-To: aaa-wg@merit.edu
Received: from zrtps0kn.nortelnetworks.com (zrtps0kn.nortelnetworks.com [47.140.192.55]) by segue.merit.edu (Postfix) with ESMTP id 406B859C5D for <aaa-wg@merit.edu>; Fri, 4 Jun 2004 09:59:27 -0400 (EDT)
Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zrtps0kn.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i54DxMe11836; Fri, 4 Jun 2004 09:59:23 -0400 (EDT)
Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id <JCQ2FFKQ>; Fri, 4 Jun 2004 09:59:23 -0400
Message-ID: <6FC4416DDE56C44DA0AEE67BC7CA43711D6BDA@zrc2hxm2.corp.nortel.com>
From: Ahmad Muhanna <amuhanna@nortelnetworks.com>
To: "'Peter Zackrisson (KA/EAB)'" <peter.zackrisson@ericsson.com>, aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change
Date: Fri, 04 Jun 2004 09:59:11 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C44A3C.1CBC2728"
Sender: owner-aaa-wg@merit.edu
Precedence: bulk

Thanks Peter,
 
Is it fair to say that your argument is based on the assumption that all DCC
Servers are always aware of all DCC clients capabilities with respect to
Tariff-Time-Change mechanism support.
 
Thanks again.

Regards, 
Ahmad 

-----Original Message-----
From: Peter Zackrisson (KA/EAB) [mailto:peter.zackrisson@ericsson.com] 
Sent: Friday, June 04, 2004 8:48 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change


I think the DCC specification is correct regarding the tariff change
mechanism.
 
If a DCC client does not support the tariff change mechanism the DCC server
must use a charging model towards that client that is not based on time,
which means that Tariff-Time-Change is not to be sent.
This means that it is up to the DCC server to be able to control if
Tariff-Time-Change should be sent or not.
If you have a charging model saying that the price for e.g. volume will be
different between 8 and 18 o'clock the clients will have to support
tariff change mechanism.
It is a very bad idea if some clients are allowed to break the charging
model (instead the charging model should be changed).
 
/ Peter

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu]On Behalf Of
Ahmad Muhanna
Sent: den 4 juni 2004 15:15
To: aaa-wg@merit.edu
Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF);
'juha-pekka.koskinen@nokia.com'; 'marco.stura@nokia.com';
'John.Loughney@nokia.com'
Subject: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change



Hi all, 

According to the DCC draft under section 5.1, support of Tariff-Time-Change
is optional by the DCC client and Server. 

" 
   The Diameter credit-control server and client MAY optionally support 
   a tariff change mechanism. The Diameter credit-control server may 
   include a Tariff-Time-Change AVP in the answer message. 
" 

On the other hand and under the same section, it mandates the DCC client
which does not support this functionality to terminate the DCC session if it
receives a CCA with Tariff-Time-Change AVP included.

Under section 5.1, it reads: 
" 
   If a client does not support the tariff change mechanism, and it 
   receives a CCA message carrying the Tariff-Time-Change AVP, it MUST 
   terminate the credit control session, giving a reason of 
   DIAMETER_BAD_ANSWER in the Termination-Cause AVP. 
" 

The problem I see is the following: 
There is a very good possibility that a DCC server supports
Tariff-Time-Change and DCC Client does not. 
This may cause a denial of service for an end-user which home Diameter CC
server supports Tariff-Time-Change mechanism while it is at an access where
DCC client does not.

Am I making sense here? 
Your thoughts please. 


Thanks, 
Ahmad