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