RE: : Diameter SIP Application AVP and command codes

Dan,

What is the current status in 3GPP, is 3GPP likely to
adopt & reuse the Diameter SIP command codes once we are
done with it?  If so, I think making the editorial changes
should be OK.

John

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