Subject: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure

From: <[email-masked]>
Date: Mon, 1 Mar 2004 14:13:22 +0200

Description of issue: addition of *[AVP] notation in the M-S-C-C AVP structure
Submitter name:  Marco Stura
Date first submitted: 1.03.2004 
Reference: 
Document: draft-ietf-aaa-diameter-cc-03.txt 
Comment type: T
Priority: 1 
Section: 8.16

Rationale/Explanation of issues: 

In order to define a more future proof structure I propose to add the *[AVP] notation
to the M-S-C-C AVP structure. According to the Base (section 4.4.1) the Grouped AVP can contain *[AVP].

Requested change:

-Section 8.16

ADD the *[ AVP ] notation to the AVP structure

       Multiple-Services-Credit-Control ::= < AVP Header: 456 >  
                                            [ Granted-Service-Unit ] 
                                            [ Requested-Service-Units ]  
                                           *[ Used-Service-Units ] 
                                            [ Tariff-Change-Usage ]  
                                           *[ Service-Identifier ]  
                                            [ Rating-Group ]  
                                           *[ G-S-U-Pool-Reference ]  
                                            [ Validity-Time ]  
                                            [ Result-Code ]  
                                            [ Final-Unit-Indication ] 
                                           *[ AVP ]

---

From: <[email-masked]>
Date: Wed, 3 Mar 2004 15:39:42 +0200

Hi Mark,
 
Just for my understanding, am I right in thinking that, without this, the M-S-C-C AVP cannot be extended with future optional AVPs in a backwards compatible way ?
 
If you want the ability to define new optional AVPs in a grouped structure you do need the *[ AVP ] notation. Since the scope of the M-S-C-C AVP is to implement a functionality for which we may not see all the future needs and requirements, it may be necessary to add optional AVPs in the future. In a way the M-S-C-C can be abstracted as a *command*, and we don't know what are all the future needs for that *command*. 
 
If so, what about all the other Grouped AVPs in the protocol and, for that matter, the commands ?
 
The semantic of other grouped AVPs defined in DCC do not require the *[ AVP ] notation, at least I cannot see any other grouped AVP that would need this. Note that the CCR/CCA already have *[AVP],  you can add AVPs to the command in the future if you need. 
 
Regards
Marco

---

From: <[email-masked]>
Date: Wed, 3 Mar 2004 16:37:56 +0200

Mark,
 
I though the CC-Service-Specific-Unit AVP would be enough. The Service-Id defines what is the resource indicated in 
CC-Service-Specific-Unit AVP as defined in section 8.26.
 
Do you see the need of  *[ AVP ] in R-S-U, U-S-U and G-S-U? 
 
Regards
Marco

-----Original Message-----
From: ext Mark Watson [mailto:[email-masked]]
Sent: 03 March, 2004 16:03
To: Stura Marco (Nokia-NET/Helsinki)
Cc: [email-masked]'
Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure

Ok, but what if we want to add new types of resource units to G-S-U and U-S-U ?
 
Straightforward time and octet volume may not be the only way to measure usage in future. If I remember rightly, then the previous draft of DIAMETER credit control, which is unfortunately embedded in 3GPP TS 32.225, defined an enumerated 'Unit-Type AVP' which would have been easy to extend. Switching to explicit AVPs for each unit type is fine, but do we want to lose extensibility here ?

Regards,
 
Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 03 March 2004 13:40
To: Watson, Mark [MOP:EP10:EXCH]
Cc: [email-masked]
Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure

Hi Mark,

 

Regards
Marco

---

From: <[email-masked]>
Date: Wed, 3 Mar 2004 16:57:25 +0200

I agree.
 
I'll update the issue to add *[ AVP ] in the R-S-U, U-S-U and G-S-U as well.
 
Regards
Marco

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of ext Mark Watson
Sent: 03 March, 2004 16:49
To: Stura Marco (Nokia-NET/Helsinki)
Cc: [email-masked]'
Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure

I would not think that new ways of measuring usage would necessarily be service-specific, but I don't have a big list of new ways to measure things in front of me (I do have a small list, though!)
 
However, adding extensibility now is free, wheras adding it later costs (you would need a new AVPs to replace R-S-U, U-S-U and G-S-U). Even if you only see a 10% chance of needing such extensions, then the expected cost (10% times that future cost) is still greater than zero.
 
So, I would suggest adding * [ AVP ] to those AVPs too. 
 
Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 03 March 2004 14:38
To: Watson, Mark [MOP:EP10:EXCH]
Cc: [email-masked]
Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure

Mark,

 
Regards
Marco

-----Original Message-----
From: ext Mark Watson [mailto:[email-masked]]
Sent: 03 March, 2004 16:03
To: Stura Marco (Nokia-NET/Helsinki)
Cc: [email-masked]'
Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure

Regards,
 
Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 03 March 2004 13:40
To: Watson, Mark [MOP:EP10:EXCH]
Cc: [email-masked]
Subject: RE: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP structure

Hi Mark,

 

Regards
Marco