Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request)

From: "Harri Hakala (TU/LMF)" <[email-masked]>
Date: Mon, 3 Nov 2003 08:44:21 +0100

Hi Christopher,

>[Chris Richards] Great. Since the mechanisms for one approach are described, it makes sense to describe the mirror approach >- just for consistency and clarity. It is still completely up to vendors/implementers to choose which mechanism to provide. >What we're aiming for is a good, flexible and efficient protocol definition that can accommodate future requirements.

The cca draft describes mechanisms for credit authorization only. This mirror approach would
mean that credit control messages would be used to request service specific authentication 
and/or authorization, which are not in scope of cca draft. AA messages explicitly indicates,
which AA mechanisms shall be used for authentication & authorization. If the CCR message 
carries AA AVPs, it would be more complex task to server to find out what authentication &
authorization should be used.

Note that there is one to many relationship between credit control authorization
and service specific authentication&authorization, i.e. there is only one credit control
application (that could be added on top of existing auth commands) but many AA applications
that could be included in the credit control messages.

regards........Harri

-----Original Message-----
From: Christopher Richards [mailto:[email-masked]]
Sent: 31. lokakuuta 2003 16:53
To: Harri Hakala (TU/LMF); 'Mark Grayson (mgrayson)'; [email-masked]; [email-masked]
Cc: Leena Mattila (TU/LMF); [email-masked]; [email-masked]; [email-masked]; Patrik Teppo (KA/EAB)
Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request)

-----Original Message----- 
From: Harri Hakala (TU/LMF) [mailto:[email-masked]] 
Sent: Friday, October 31, 2003 5:34 AM 
To: Richards, Christopher [RICH2:2Q40:EXCH]; 'Mark Grayson (mgrayson)'; [email-masked]; [email-masked] 
Cc: Leena Mattila (TU/LMF); [email-masked]; [email-masked]; [email-masked]; Patrik Teppo (KA/EAB)
Subject: RE: [AAA-WG]: Diam CC (AA interrogation in initial CC request) 

Hi Christopher, 
>Mixing applications is already described in the Diam CC draft (Adding 
>DCC AVPs to the AA messages). 
>I'm only proposing the >logical mirror of the existing mixing. 
>To me, it seems cleaner than impacting an already existing protocol with new features. Better to build 
>existing features & functionality into the new protocol. 
We have defined a scenario, as you said, where the initial credit control request is performed as part of the authentication/authorization for the sake of protocol efficiency. After the initial request, 
following credit control requests are done with credit control messages, likewise following 
(re-)authentication & authorization requests are done with AA messages. 
It is true that some credit control specific AVPs (e.g. Requested-Service-Unit or some Rating Input AVPs) may be added to initial service specific AA message, but I assume that *[AVP] notation makes this possible without any major impact to the existing protocols. But also vice versa approach, i.e. AA AVPs added to the CCR message causes some impacts to existing AA implementations, since then AA servers shall support initial authentication and authorisation with the CCR message.
[Chris Richards] Great. Since the mechanisms for one approach are described, it makes sense to describe the mirror approach - just for consistency and clarity. It is still completely up to vendors/implementers to choose which mechanism to provide. What we're aiming for is a good, flexible and efficient protocol definition that can accommodate future requirements.
Cheers, Chris. 

Regards........Harri

---

From: <[email-masked]>
Date: Mon, 3 Nov 2003 10:30:53 +0200

Hi Chris,

> I'll take a look at the thread. 

Please do, if you find problems with it, please try to address the problems
you see.

> I'm not saying that the current proposal is broken - just lacking 
> and inefficient. 
> Since we're at the draft stage now, it seems like a good time to 
> propose making improvements to the existing mechanism. It's not too late 
> for that I trust?

As there has been discussion on the topic, I don't want to go back
and forth too much, but if you can find improvements, that's OK.

John