From: "Glen Zorn" <[email-masked]>
Date: Fri, 2 Jul 2004 10:27:17 -0700

Description of issue:  No guarantee of interoperability between CCA implementations
Submitter name: Glen Zorn
Submitter email address: [email-masked] 
Date first submitted: 2 July 2004 
Document: dcca 
Comment type: T
Priority: S
Section: 4.1
Rationale/Explanation of issue: 
In order to interoperate, Diameter peers implementing the 
Diameter Credit Control Application must agree upon both the application and the service (specified in the Service-Identifier AVP).  However, the inclusion of the Service-Identifier in the CCR and CCA messages is optional.

Lengthy description of problem:
Section 4.1, para. 6 states "it is the combination of support of the Diameter Credit Control Application and the service defined in the Service-Identifier AVP, which defines interoperability between any given credit control client and server."  However, the inclusion of the Service-Identifier in the CCR and CCA messages is optional.  This gives rise to a situation where two peers implementing the same application may not interoperate because they do not implement the same "service", and further, refuse to clearly communicate that fact.

Requested change: 
Change section 4.1, paragraph 5 from

   This specification, together with service specific documents, is 
   governing the credit control message. The rule is that service 
   specific documents only define what existing AVPs or new AVPs are 
   used as input to the rating process (i.e. they do not define new 
   credit control applications), and thus need to be included in the 
   Credit-Control-Request command by a Diameter Credit Control Client 
   supporting a given service as *[AVP]. In order to define new AVPs, 
   service specific documents MUST follow the practices defined in 
   [DIAMBASE]. The service SHOULD be identified using the Service- 
   Identifier AVP. The Service-Identifier AVP MUST be a unique 
   identifier for a given service as defined in section 8.28. 

to

   This specification, together with service specific documents, is 
   governing the credit control message. The rule is that service 
   specific documents only define what existing AVPs or new AVPs are 
   used as input to the rating process (i.e. they do not define new 
   credit control applications), and thus need to be included in the 
   Credit-Control-Request command by a Diameter Credit Control Client 
   supporting a given service as *[AVP]. In order to define new AVPs, 
   service specific documents MUST follow the practices defined in 
   [DIAMBASE]. The service MUST be identified using the Service- 
   Identifier AVP. The Service-Identifier AVP MUST be a unique 
   identifier for a given service as defined in section 8.28. 

~gwz

"They that can give up essential liberty to obtain a little temporary safety deserve neither..."
-- Benjamin Franklin, 1759 

"It is forbidden to kill; therefore all murderers are punished unless they kill in large numbers and to the sound of trumpets."
-- Voltaire