Subject: RE: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt

From: "Carolina Canales Valenzuela (ECE)" <[email-masked]>
Date: Tue, 19 Feb 2002 16:05:16 +0100

>* Is it technically OK to use a message in both directions
>  (client->server and server->client)?  I think the answer is yes,
>  although most existing Diameter applications don't do this.
>  Are there any other considerations of which we should be aware?

My main concern regarding this is : why do we need to do such thing?
Why not implementing two different commands for each direction, as it has been always done so far?

I think it more useful having more simple commands for each specific functionality, rather than merging every functionality in the same command, and, apart from that, making that command bi-directional.....I don't really see a reason for having bi-directional commands....(there is no shortage of command-codes). 
Could you please explain?

BR,
Carolina

>[email-masked] writes:
> > Hi,
> > 
> > > So we would have three commands:
> > > - One (AAA->SSP) to update user data (Push-Profile-Request, PPR?).
> > > - One (AAA->SSP) to de-register the user from AAA to SSP 
> > > (Registration-Termination-Request, RTR?).
> > > - One (SSP->AAA) to update registration information and to 
> > > pull user data.
> > 
> > Right, this was what I had in mind. The 
>SIP-Profile-Update-Type AVP could be changed in such  a way 
>that at least the UPDATE_PROFILE value is removed and the name 
>of the AVP could be something else e.g. SIP-Server-Assignment-Type.
> > 
> > What about the RETRIEVE_PROFILE value of the 
>SIP-Profile-Update-Type AVP? Should we keep it or remove it? 
>The difference of the RETRIEVE_PROFILE to the NO_ASSIGNMENT 
>value is not clear.
> > 
> > Best Regards, Jaakko
> > 
> > > -----Original Message-----
> > > From: ext Miguel-Angel Pallares-Lopez (ECE)
> > > [mailto:[email-masked]]
> > > Sent: 15 February, 2002 12:37
> > > To: [email-masked]
> > > Subject: [AAA-WG]: RE: draft-johansson-aaa-diameter-mm-app-01.txt
> > > 
> > > 
> > > Hi,
> > > 
> > > So we would have three commands:
> > > - One (AAA->SSP) to update user data (Push-Profile-Request, PPR?).
> > > - One (AAA->SSP) to de-register the user from AAA to SSP 
> > > (Registration-Termination-Request, RTR?).
> > > - One (SSP->AAA) to update registration information and to 
> > > pull user data.
> > > 
> > > It seems sensible to me. I agree that their semantic is 
> > > different and we are not going to run out of commands codes.
> > > 
> > > Best regards,
> > > Miguel
> > > 
> > > > -----Original Message-----
> > > > From: [email-masked] 
>[mailto:[email-masked]]
> > > > Sent: Friday, February 15, 2002 10:56 AM
> > > > To: [email-masked]; 
>[email-masked]
> > > > Cc: [email-masked]; [email-masked]; 
>[email-masked];
> > > > [email-masked]; [email-masked];
> > > > [email-masked]; 
>[email-masked]
> > > > Subject: RE: draft-johansson-aaa-diameter-mm-app-01.txt
> > > > 
> > > > 
> > > > Hi,
> > > > 
> > > > In addition, PUR/PUA command is also used in the 
> > > > draft-johansson-aaa-diameter-mm-app-01.txt for (-/re/de-) 
> > > > registering the user, either from the AAAH or the client. 
> > > > From the logical point of view the profile updating and 
> > > > (-/re/de-) registration are different operations and 
> > > > therefore it would be quite natural to separate the profile 
> > > > updating from the registration. 
> > > > 
> > > > This could be done by specifying different command codes for 
> > > > the profile and the registration related operations.
> > > > 
> > > > Best Regards, Jaakko
> > > > 
> > > > > -----Original Message-----
> > > > > From: ext [email-masked]
> > > > > [mailto:[email-masked]]
> > > > > Sent: 13 February, 2002 19:42
> > > > > To: [email-masked]'
> > > > > Cc: Carolina Canales Valenzuela (ECE); 
> > > [email-masked]'; Rajaniemi
> > > > > Jaakko (NET/Espoo); [email-masked]'; 
> > > > [email-masked]';
> > > > > [email-masked]'; 
> > > > [email-masked]'; Aittola
> > > > > Mikko (NET/Helsinki); Miguel-Angel Pallares-Lopez (ECE)
> > > > > Subject: RE:draft-johansson-aaa-diameter-mm-app-01.txt
> > > > > 
> > > > > 
> > > > > Hello,
> > > > > taking in account the requirements draft 
> > > > > "draft-calhoun-sip-aaa-reqs-03" 
> > > > > (http://search.ietf.org/internet-drafts/draft-calhoun-sip-aaa-
> > > > > reqs-03.txt), in section 3.0, bullet 4, I can see there's a 
> > > > > requirement for the AAA infrastructure  to distribute (*push 
> > > > > or pull*)subscriber/service/security profiles to the relevant 
> > > > > SIP servers.
> > > > > 
> > > > > In "draft-johansson-aaa-diameter-mm-app-01" this has been 
> > > > > implemented as an only, bi-directional command, PUR (section 
> > > > > 3.5). This command might be issued either by the AAA or by 
> > > > > the SIP server, in order to update the user profile in the 
> > > > > corresponding node.
> > > > > 
> > > > > However, I think it could be useful to split this command in 
> > > > > 2 uni-directional commands, one issued from the AAA and 
> > > > > another one issued by the SIP server.
> > > > > 
> > > > > The fact that such a command can be issued from the same node 
> > > > > as a request and as a reply, adds a lot of complexity in the 
> > > > > implementation part. Why not using two different commands? I 
> > > > > think there is no shortage of command codes, right? ;-).
> > > > > 
> > > > > BR,
> > > > > Carolina
> > > > > 
> > > > > 
> > > > > >-----Original Message-----
> > > > > >From: [email-masked] 
>[mailto:[email-masked]]
> > > > > >Sent: Tuesday, February 12, 2002 1:02 PM
> > > > > >Cc: [email-masked]
> > > > > >Subject: I-D 
>ACTION:draft-johansson-aaa-diameter-mm-app-01.txt
> > > > > >
> > > > > >
> > > > > >A New Internet-Draft is available from the on-line 
> > > > > >Internet-Drafts directories.
> > > > > >
> > > > > >
> > > > > >	Title		: Diameter Multimedia Application
> > > > > >	Author(s)	: T. Johansson et al.
> > > > > >	Filename	: 
>draft-johansson-aaa-diameter-mm-app-01.txt
> > > > > >	Pages		: 31
> > > > > >	Date		: 11-Feb-02
> > > > > >	
> > > > > >This document specifies a Diameter application that allows 
> > > > a Diameter
> > > > > >server to authenticate, authorize, and collect accounting 
> > > > information
> > > > > >for Session Initiation Protocol (SIP) services rendered 
> > > to a client
> > > > > >node.  This application, combined with the base Diameter 
> > > > protocol and
> > > > > >appropriate SIP extensions, allows SIP User Agents (UAs) 
> > > to obtain
> > > > > >services from SIP servers that are connected to a Diameter
> > > > > >infrastructure.  When combined with the Inter-Domain 
> > > capability of
> > > > > >the base protocol, service may even be obtained from SIP 
> > > > servers that
> > > > > >belong to foreign domains, as would be encountered by 
> > > > roaming mobile
> > > > > >nodes.
> > > > > >
> > > > > >A URL for this Internet-Draft is:
> > > > > 
>>http://www.ietf.org/internet-drafts/draft-johansson-aaa-diamete
> > > > > r-mm-app-01.txt
> > > > > 
> > > > > To remove yourself from the IETF Announcement list, send a 
> > > > message to 
> > > > > ietf-announce-request with the word unsubscribe in the body 
> > > > > of the message.
> > > > > 
> > > > > Internet-Drafts are also available by anonymous FTP. Login 
> > > > > with the username
> > > > > "anonymous" and a password of your e-mail address. After 
> > > logging in,
> > > > > type "cd internet-drafts" and then
> > > > > 	"get draft-johansson-aaa-diameter-mm-app-01.txt".
> > > > > 
> > > > > A list of Internet-Drafts directories can be found in
> > > > > http://www.ietf.org/shadow.html 
> > > > > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > > > > 
> > > > > 
> > > > > Internet-Drafts can also be obtained by e-mail.
> > > > > 
> > > > > Send a message to:
> > > > > 	[email-masked].
> > > > > In the body type:
> > > > > 	"FILE 
> > > > > /internet-drafts/draft-johansson-aaa-diameter-mm-app-01.txt".
> > > > > 	
> > > > > NOTE:	The mail server at ietf.org can return the document in
> > > > > 	MIME-encoded form by using the "mpack" utility. 
> To use this
> > > > > 	feature, insert the command "ENCODING mime" 
>before the "FILE"
> > > > > 	command.  To decode the response(s), you will 
>need "munpack" or
> > > > > 	a MIME-compliant mail reader.  Different MIME-compliant 
> > > > > mail readers
> > > > > 	exhibit different behavior, especially when dealing with
> > > > > 	"multipart" MIME messages (i.e. documents which 
>have been split
> > > > > 	up into multiple messages), so check your local 
>documentation on
> > > > > 	how to manipulate these messages.
> > > > > 		
> > > > > 		
> > > > > Below is the data which will enable a MIME compliant 
>mail reader
> > > > > implementation to automatically retrieve the ASCII 
>version of the
> > > > > Internet-Draft.
> > > > > 
> > > > 
> > > 
> > 
>

---

From: Pete McCann <[email-masked]>
Date: Tue, 19 Feb 2002 10:52:20 -0600 (CST)

Hi, Carolina,

I agree, we should split PUR into two messges.

-Pete