RE: : Diameter SIP Application AVP and command codes

Hello all,

The original 'agreement' was that the 3GPP Diameter AVP command codes
(used at the Cx interface) were valid only for Release 5. After Release
5, 3GPP was supposed to develop the SIP application inside of the IETF.
That hasn't really happened, but as far as the IETF is concerned,
the IETF is the place to standardize Diameter applications.

YMMV;
John

> -----Original Message-----
> From: ext German Blanco (E2/EEM) [mailto:[email protected]]
> Sent: 10 August, 2005 12:00
> To: 'Warren, Dan, VF UK - Technology (TS)'; Loughney John
> (Nokia-NRC/Helsinki); Garcia Miguel.An (Nokia-NRC/Helsinki)
> Cc: [email protected]
> Subject: RE: [AAA-WG]: Diameter SIP Application AVP and command codes
> 
> 
> Dan,
> 
> I would be also of that 'old school', only problem is I wasn't there
> when all this started :-)
> 
> All (I hope somebody else apart from the people that are/were in 
> 3GPP reads this),
> 
> could anybody tell me if there was any discussion at all about this
> issue in the last IETF meeting?
> 
> I understand that the initial goal of this draft (please correct me 
> if this is wrong) was to have a *superset* of the Cx application.  
> That is, to have a Diameter application in IETF that allowed several 
> methods for authentication of a SIP user, one of which could be Cx.
> To me that makes perfect sense.
> 
> As it is, and as Dan said, there is a GREAT deal of common things, 
> and that is what I call a "double specification" (the same thing 
> defined in two places).  Not only that, if no effort is done for 
> the alignment, the two specifications will have a lot of differences 
> at protocol level, while being almost identical at a concept level.
> That means that most developers will find themselves building two
> protocol interfaces for their Diameter SIP Authentication nodes.
> 
> In my personal opinion, there should be an effort in making these
> two specifications compatible.  Could it be possible to move in the
> direction of removing common things and reusing existing codes so
> that we end up with that "superset"?
> 
> Cheers,
> 
> German.
> 
> > -----Original Message-----
> > From: Warren, Dan, VF UK - Technology (TS)
> > [mailto:[email protected]]
> > Sent: lunes, 04 de julio de 2005 10:20
> > To: [email protected]; [email protected]; 
> German Blanco
> > (ML/EEM)
> > Cc: [email protected]
> > Subject: RE: [AAA-WG]: Diameter SIP Application AVP and 
> command codes
> > 
> > 
> > John
> > 
> > Difficult to say entirely.  There has been some divergence 
> > between the two specifications but not to the extent where 
> > convergence would be impossible (or even infeasible).  I am 
> > still from the 'old school' that wanted to see the DSA 
> > application (even when it was still DMA!) be adopted by 3GPP, 
> > but the 3GPP CR process does not lend itself comfortably to 
> > referencing an IETF RFC in it's entirety.  
> > 
> > I think the key point is that there is stilla great deal of 
> > common genetic material between DSA and Cx and so if (and it 
> > is a big if) DSA could be used for Cx, then re-using as many 
> > AVP and command codes from the 3GPP spec as possible, albeit 
> > under a new standards track application id can only serve to 
> > facilitate that possibility.  The final decision really lies 
> > in the hands of 3GPP WG CT4 (where German, Mikko and myself 
> > attend) so we probably need to have the discussion there - 
> > maybe in the next meeting of that group at the end of August.
> > 
> > Cheers
> > 
> > Dan
> > 
> > > -----Original Message-----
> > > From: [email protected] [mailto:[email protected]]
> > > Sent: 04 July 2005 06:55
> > > To: Warren, Dan, VF UK - Technology (TS); 
> > [email protected];
> > > [email protected]
> > > Cc: [email protected]
> > > Subject: RE: [AAA-WG]: 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
> > > > > 
> > > > > 
> > > > 
> > > 
> > 
>