[AAA-WG]: Application ID collision for MIPv4 and DCC

["Christopher Richards" <[e-mail]>]

Hi All,
 
I was just comparing some text in the MIPv4 draft spec
(http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-18.txt
<http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-mobileip-18.txt
> ) and the DCCA draft spec
(http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-05.txt
<http://www.ietf.org/internet-drafts/draft-ietf-aaa-diameter-cc-05.txt> )
and noticed that both drafts have been assigned the same application-id (4).
 
The MIPv4 draft has expired so I presume that it is no longer valid and it's
application-id can be re-assigned to DCCA without issue. Is that right?


Cheers,
Chris 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: June 28, 2004 12:18 PM
To: Bernard Aboba
Cc: [e-mail]; Richards, Christopher [RICH2:2Q40:EXCH];
'[e-mail]'; '[e-mail]'
Subject: RE: [AAA-WG]: Application IDs for EAP




Hi Bernard, 

Thanks.  I think your answer is clear, but if you don't mind I'll just try
to put it into my own words.  Please let me know if I've got anything wrong.


I think the key point is that the application definition must explicitly
state which application ID is to be used for inherited commands (and newly
defined commands). 

If I understand your answer correctly, if a new application defines a new
command and re-uses a number of existing commands without significant
change, the only option is for those re-used commands to be used with their
original application ID. 

So, in the example below, any implementation of application y is going to
include commands with an application ID of x, so a capabilities exchange
using just an application ID of y is not a practical proposition. 

Regards, 

John. 

  




	Bernard Aboba <[e-mail]> 


28/06/2004 16:57 


        
        To:        Christopher Richards <[e-mail]> 
        cc:        "'[e-mail]'"
<[e-mail]>, [e-mail], "'[e-mail]'"
<[e-mail]> 
        Subject:        RE: [AAA-WG]: Application IDs for EAP



> The big question I think you have all been discussing is what application
ID
> is used within application y for the commands inherited.  My first
thoughts
> were that the original commands should use an application ID of x.  Your
> proposal, as I understand it, is that they should include an application
ID
> of y.

RFC 3588 is fairly clear on what is required.  Changing the application ID
of existing commands and AVPs to "y" from "x" unecessarily will break
interoperability with existing implementations of those commands.

> An initial assumption is that if the capabilities exchange is completed
> only for application y, then the recipient shouldn't acept commands with
> an application ID of x.

A Diameter peer should advertise *all* applications that it supports.  So
if commands with application X and commands with application Y are being
used, then *both* should be advertised.

> On the otherhand, if application y doesn't define those commands an
> application y client or server wouldn't necessarily implement support for
> them.

That's also true -- a Diameter application document needs to explicitly
state what commands MUST, SHOULD or MAY be implemented for that
application.  It also needs to state what application-IDs must be used for
those commands.

> The rules in RFC 3588 that cause new applications to be created lead me to
> believe that there will eventually be a number of applications that
inherit
> commands from earlier applications, however there doesn't seem to be a
clear
> definition of how an application should inherit commands.

RFC 3588 is very explicit on this point -- new application IDs can only be
used if the command is fundamentally changed, such as by changing the
round-trips, or adding a new mandatory AVP.  Otherwise the existing
command definition (and application ID) is used.  Doing anything else
breaks Diameter interoperability.





****************************************************************************
**

The content of this e-mail may be confidential or legally 
privileged. If you are not the named addressee or the intended
recipient please do not copy it or forward it to anyone. If you have 
received this email in error please destroy it and kindly notify the 
sender and [e-mail]. Email cannot be
guaranteed to be secure or error-free, it is your responsibility
to ensure that the message (including attachments) is safe
and authorised for use in your environment.
Vodafone Ireland Limited. Directors: Peter Bamford Chairman (UK), 
Pauline Best (UK), Paul Donovan Chief Executive (UK), 
Gerry Fahy, Dermot Griffin, David Boorman (UK),
David Smithwhite (UK), Patrick Teahon, Alfred Kane.
Registered in Ireland at MountainView, Leopardstown, Dublin 18. 
Co Reg No.: 326967 VAT Reg No. IE6346967G

****************************************************************************
**