RE: : Diameter SIP Application AVP and command codes

I have two observations here.  The first is that the Diameter-SIP-Application was actually originated to be the IETF acceptable description of the Cx interface application, and as such the original intention of 3GPP was that once Diameter-SIP-Application ( which was originally the Diameter-Multimedia-Application some may recall) had achieved RFC status, 3GPP would work on evolving Cx towards the RFC so that a direct reference could be made.  Therefore it is not surprising that a lot of the AVP's that are used in DSA are common to those in Cx.

Second, in 3GPP we are being very conscientious in the way we are using AVP codes.  3GPP TS 29.230 records all the AVP's that 3GPP has defined and where commonality in AVP content is found, AVP codes are reused across multiple applications.  This works perfectly well for AVP's that are static in the nature of their content (such as User Identities or legacy variables from other protocols that are interworked) and so it should be possible for these AVP codes to be reused in DSA.  Other's which are aligned now but may become more transient, 3GPP would have to accept that an RFC'ed Application is set in stone and then define a new AVP and hence AVP code for the iteration of the code included in the DSA RFC.  Since the request for re-use comes for 3GPP, and the resulting inconvenience would also be 3GPP's if the 3GPP CR process resultant in divergence, I see little reason for IETF in general to object.

Cheers

Dan



> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]]On Behalf Of
> Miguel Garcia
> Sent: 21 June 2005 12:22
> To: German Blanco (ML/EEM)
> Cc: '[email protected]'
> Subject: Re: [AAA-WG]: Diameter SIP Application AVP and command codes
> 
> 
> German:
> 
> I have concerns with your proposal.
> 
> Starting with, it is not a good idea to do a double 
> specification, and 
> this is exactly what you are proposing. 3GPP has defined a number of 
> AVPs in the Diameter Cx application. These AVPs are allocated 
> AVP codes 
> 600 and upwards (see 3GPP TS 29.229 Section 6.3).
> 
> If we now allocate the same AVP codes to a number of AVPs, and we 
> publish the Diameter SIP application as an RFC, what we get 
> is that the 
> same AVP is specified twice, one in the future RFC and the other in 
> 29.229. If both specifications specify the same thing, so far 
> so good. 
> But if one specification indicates something slightly 
> different from the 
> other (imagine, because of an oversight, or because a change request 
> approved by 3GPP), which one will win?
> 
> In this situation, if you receive one of those double-specified AVPs, 
> you will need then to check the Application-ID, which is 
> different for 
> DSA and Cx applications. So if you need to look at the 
> application ID to 
> understand the syntax or semantics of a given AVP, then your 
> main goal 
> falls apart and we have failed.
> 
> In order to avoid these sorts of things, I would highly 
> recommend not to 
> even try to share any code. These are two applications (quite 
> similar, 
> yes), with different AVPs and different AVP codes. This grants some 
> independendance of the two documents.
> 
> On the other hand, I haven't found what will be the benefit on doing 
> your proposal. If it is to save programming code, then you 
> won't at the 
> time you diverge some AVP, and it will be a matter of time until that 
> thing happens. Is there any other advantage?
> 
> For the sake of interoperable implementations I would 
> recommend that the 
> Diameter SIP application keeps on using its own set of AVP codes.
> 
> Regards,
> 
>           Miguel
> 
> German Blanco (ML/EEM) wrote:
> 
> > Hi all,
> > 
> > in the set of AVPs and commands used in the draft there are 
> some that have been already reserved in 3GPP for the same 
> purpose, with the same type and in some cases with the same 
> name as in the draft.
> > Are there any plans of reusing the AVP and command codes of 
> the Cx Application?
> > 
> > This is the list of similar AVPs:
> > + 3GPP Vendor AVP           + in the draft
> > Server-Name                 SIP-Server-URI
> > Server-Capabilities         SIP-Server-Capabilities
> > Mandatory-Capability	    SIP-Mandatory-Capability
> > Optional-Capability	    SIP-Optional-Capability
> > SIP-Number-Auth-Items	    SIP-Number-Auth-Items
> > SIP-Authentication-Context  SIP-Authentication-Context
> > SIP-Item-Number	          SIP-Item-Number
> > SIP-Auth-Data-Item	    SIP-Auth-Data-Item
> > Server-Assignment-Type	    SIP-Server-Assignment-Type
> > Deregistration-Reason	    SIP-Deregistration-Reason
> > Reason-Code	                SIP-Reason-Code
> > Reason-Info	                SIP-Reason-Info
> > User-Authorization-Type	    SIP-User-Authorization-Type
> > User-Data-Already-Available SIP-User-Data-Already-Available
> > 
> > The command values could all be reused as far as I can see.
> > 
> > Cheers,
> > 
> > German Blanco.
> > 
> > 
> > 
> 
> -- 
> Miguel A. Garcia           tel:+358-50-4804586
> sip:[email protected]
> Nokia Research Center      Helsinki, Finland
> 
>