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

[<[e-mail]>]

Hi Ahmad,
 
it seems you didn't get my point.  What is indicated in the draft is that SLA is expected to cover bla bla bla...., and this should be enough
other options are not needed.
 
Finally, the only changes allowed at this point are major bug fixing and your proposal doesn't fall within this category. So, new termination
causes will not be added in this DCC version unless explicitely requested by IESG.
 
Regards
Marco

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of ext Ahmad Muhanna
Sent: 09 June, 2004 15:10
To: Stura Marco (Nokia-NET/Helsinki); Satheesh Maddireddi; [e-mail]
Cc: [e-mail]; [e-mail]; Koskinen Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); [e-mail]; [e-mail]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change


Hi,
Please see comments inline.

Regards, 
Ahmad 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Wednesday, June 09, 2004 5:26 AM
To: Maddireddi, Satheesh [RICH2:2Q40:EXCH]; Muhanna, Ahmad [RICH2:2Q30:EXCH]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change


Hi,
 
I think what really happen is that the user signs a contract with a service provider, often referred as subscription. 
The contract typically states the pricing structure for the services, including tariff time changes, when and where 
certain conditions are  applicable etc. Therefore, whether tariff time changes are applicable when roaming to a 
given visited network, should be known as well since this may have legal implications (i.e. you cannot sell to
a user that the access costs $1/MB from 6am to 6 pm and $0.5/MB from 6pm to 6 am if not sure that
tariff change is supported. Presumably you cannot sell that the effective cost of the service has dependencies
on whether tariff change is supported in the visited network either. So, you have to know it beforehand.). Introducing
additional protocol functionalities such as new termination cause etc. won't help in that respect, since in most
cases the server won't accept to change the billing model agreed beforehand with the user, the service will most 
likely be denied in any case.
 
[A.M.]
I agree.
Please see comments below.
 
We have a paragraph in section 4.1 that is supposed to cover this interoperability issues, basically the option 2
listed by Ahmad.
 
Clip

   It is reasonable to expect that there will exist a service level 
   agreement between providers of the credit control client and the 
   credit control server covering the charging, services offered, 
   roaming agreements, agreed rating input, etc. 
     
[A.M.]
I think this probably enough to cover the static configuration portion of it.
 
"covering the charging" basically refers to the charging model, therefore includes such things as the tariff changes and
charging type (e.g. volume, time etc.) too. We thought that it was better choice to group all this interoperability stuff in 
one section rather than repeating the same text for all the optional features along the document, there is nothing left to 
individual interpretation or assumptions as Ahmad appears to believe.
 
That said, the draft passed couple of WG last calls, the AD review and is now in the IESG review. So, IESG officially frowns 
upon changes except in extreme cases (i.e. major bugs). What you are pointing out, as discussed above, I don't believe 
is a bug at all and that is reasonable to expect SLA is mentioned in section 4.1. 
 
[A.M.]
Agreed.
I believe the cause value should be changed to a specific one and not so generic. 
I do not think it is too late to propose a new cause value as "tariff change not supported". 
It is more descriptive and much more helpful for collecting proper OM at both ends; the server and client. 
 
Mark Grayson wrote
 
>well at least there seems to be some inconsistency with optional MSCC which then has support explicitly indicated by the client.
 
The MSCC is a bit different case. Who decide at the origin to multiplex services in the same credit control session is actually
the client, while the tariff-change is server driven. The reason of indicating MSCC support in the initial CCR, is to indicate to
the server "I want to multiplex services that may be subject to different cost in the same session". The server may reject the
request because it doesn't support the feature (Failed AVP included in the response), in such a case the client still have the
option to open a credit control session for each of the requested services. As discussed above this won't be effective in case
of tariff-changes, all would happen is that the server would reject the request if the client indicates "tariff change not supported"
since you cannot change the beforehand agreed charging model with the user. 
 
[A.M.]
please see comments above. 
 
Regards
Marco

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]On Behalf Of ext Satheesh Maddireddi
Sent: 09 June, 2004 05:40
To: Ahmad Muhanna; Stura Marco (Nokia-NET/Helsinki); [e-mail]
Cc: [e-mail]; [e-mail]; Koskinen Juha-Pekka (Nokia-NET/Tampere); Loughney John (Nokia-NRC/Helsinki); [e-mail]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change


Hi,
 
I agree with Ahmad we should have a specific reason for the failing the MSCC in case if the client doesn't support the Tariff-Time-Change AVP
as the the server will not be able to interpret the failure as it may be because of  the GSU unit types OR the tariff change AVP will have to retry
at most 2 times to understand the meaning of failure reason. (Need a new failure cause). Regarding mandating the Tariff-Time-Change AVP
server always has an option to include a mandatory AVP Validity-Time for the client to trigger reauth as the server wants.
 
Regards,
Satheesh 


 -----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH] 
Sent: Tuesday, June 08, 2004 9:08 AM
To: '[e-mail]'; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change



Hi,
please see comments inline.

Regards, 
Ahmad 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: Tuesday, June 08, 2004 8:35 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change


Hi,
 
I think the Peter answer indicated that this is not a problem. 
 
[A.M.]
Apparently and based on my comment to Peter, I disagree. 
 
Indeed, who decide the billing model is the server in the home network and not the client in the
visited network, this was already discussed in the mailing list a while ago.
If the server sent a tariff-time-change in the answer is because it requires this model, perhaps 
it has also contractual implications with the user if the model is broken, and therefore it is correct for 
the client to reject the answer if it doesn't support the tariff-time-change mechanism.
 
It is up to the server to eventually track that the origin-host X rejected an answer with Tariff-Time-Change AVP
and at the next attempt change the billing model if possible. However, typically an agreement between
DCC-Client and server exist and the server can control whether to send the tariff-time-change or not. 
 
[A.M.] 
I think we are drafting a standard that needs not to leave anything for individual interpretation or assumptions. Also, to avoid any IOT problem, we need to make this clear in the standard.
I see you just proposed a couple of options:
1. Some sort of dynamic configuration based on DCC Server tracking DCC clients support for Tariff-Time-Change. 

The only problem I see here is how the server would know that the client does not support Tariff-Time-Change while the cause value in the Temination-Cause AVP is set to a generic one "DIAMETER_BAD_ANSWER"


2. Static configuration at the DCC Server based on "agreement between DCC-Client and DCC Server"
 
I may also add another straight forward one, 
3. Mandate the support for the Tariff-Time-Change mechanism on the DCC server and DCC Client.
 
Is there any other options that the group may think applicable to this issue?
 
Ahmad
 
Marco
 

-----Original Message-----
From: ext Ahmad Muhanna [mailto:[e-mail]]
Sent: 08 June, 2004 15:51
To: 'Peter Zackrisson (KA/EAB)'; [e-mail]
Cc: '[e-mail]'; '[e-mail]'; Koskinen Juha-Pekka (Nokia-NET/Tampere); Stura Marco (Nokia-NET/Helsinki); Loughney John (Nokia-NRC/Helsinki); Ahmad Muhanna
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change


So far the only comment received is from Peter. 
Does this mean that every one agrees that this is a problem that needs to be fixed.
If so, what do you think the solution should be?

Regards, 
Ahmad 

-----Original Message-----
From: Muhanna, Ahmad [RICH2:2Q30:EXCH] 
Sent: Friday, June 04, 2004 8:59 AM
To: 'Peter Zackrisson (KA/EAB)'; [e-mail]
Subject: RE: [AAA-WG]: DCCA Draft 05: Tariff-Time-Change


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:[e-mail]] 
Sent: Friday, June 04, 2004 8:48 AM
To: Muhanna, Ahmad [RICH2:2Q30:EXCH]; [e-mail]
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: [e-mail] [mailto:[e-mail]]On Behalf Of Ahmad Muhanna
Sent: den 4 juni 2004 15:15
To: [e-mail]
Cc: Harri Hakala (JO/LMF); Leena Mattila (TU/LMF); '[e-mail]'; '[e-mail]'; '[e-mail]'
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