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

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Mon, 1 Mar 2004 13:18:26 +0100

assigned issue 25.

/ harri

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: 1. maaliskuuta 2004 14:13
> To: [email-masked]
> Subject: [AAA-WG]: DCC Issue: addition of *[AVP] notation in 
> the M-S-C-C
> AVP structure
> 
> 
> 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 ]
> 

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

---

From: "Mark Watson" <[email-masked]>
Date: Wed, 3 Mar 2004 12:14:01 -0000

Marco,

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 so, what about all the other Grouped AVPs in the protocol and, for that
matter, the commands ?

Regards...Mark

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 01 March 2004 12:13
To: [email-masked]
Subject: [AAA-WG]: DCC Issue: addition of *[AVP] notation in the M-S-C-C AVP
structure

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

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

       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: "Mark Watson" <[email-masked]>
Date: Wed, 3 Mar 2004 14:02:35 -0000

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,

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*. 

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: "Mark Watson" <[email-masked]>
Date: Wed, 3 Mar 2004 14:49:17 -0000

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,
 
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

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