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

From: <[email-masked]>
Date: Fri, 15 Feb 2002 14:33:10 +0200

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: Fri, 15 Feb 2002 10:47:37 -0600 (CST)

A couple of questions for the working group:

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

* Couldn't we use ASR for terminating registration sessions?

-Pete

---

From: "Jari Arkko" <[email-masked]>
Date: Fri, 15 Feb 2002 20:04:28 +0200

>   Are there any other considerations of which we should be aware?

Do you mean the *same* message in two directions? Hmm...
might be better to have two different ones just for clarity.

> * Couldn't we use ASR for terminating registration sessions?

Yes, why not.

Jari