Subject: RE: [AAA-WG]: Issue 464: Application-Id Usage

From: <[email-masked]>
Date: Wed, 7 Jul 2004 14:59:39 +0300

Hi,

> The question is whether it should also advertise the 
> application that it inherited command C1 from, even though it doesn't
> support command C2.
> 
> If the application-Id in question is Diameter Base (Application-ID 0)
> I think there is no issue, since this is mandatory-to-implement for all
> Diameter peers.
> 
> However, if we are talking about multiple inheritance (e.g. inheriting
> commands from an Application-Id other than Base authentication and
> accounting) I think we have a problem.

Here's how I interpret RFC3588 regarding this:

Application X defines commands: C1 and C2
Application Y defines command:  C3 and also re-uses C1

First of all, if application Y re-uses C1 it must be stated
in the specification of application Y.

If a DiameterIdentity advertises support for application X,
it must support C1 and C2. C1 is used with app-id X.

If a DiameterIdentity advertises support for application Y,
it must support C1 and C3. C1 is used with app-id Y.

If a DiameterIdentity advertises support for application X and Y,
it must support C1, C2, and C3. C1 can be used with app-id X and Y.

BR,
Mikko

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of
> ext Bernard Aboba
> Sent: 06 July, 2004 03:56
> To: [email-masked]
> Cc: Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: [AAA-WG]: Issue 464: Application-Id Usage
> 
> 
> Pasi Eronen noted:
> 
> >This seems to imply that a new application can't borrow only
> >a subset of mandatory commands from an existing application..?
> >
> >Otherwise we could get a conflict. Let's assume that application
> >X has commands C1 and C2, and application Y defines a new
> >command C3 and borrows C1 from X (without any new mandatory
> >AVPs).
> 
> >It seems that a Diameter server implementing only Y can't
> >advertise support for X, since it does not implement C2.
> >But using application identifier of X for C1 is not allowed
> >either, since this seems to contradict the text saying that
> >"When a request is routed, the target server MUST have
> >advertised the Application Identifier (see Section 2.4) for
> >the given message.
> 
> >Another related issue is whether two different applications
> >could use the same AVP (in the same command and with the same
> >application ID) for slightly different purposes.  At least this
> >happens all the time with RADIUS, but perhaps the different uses
> >can be distinguished even if the application ID is the same..."
> 
> If application Y defines a new command C3, then it needs to advertise
> application Y, since otherwise it can't be guaranteed that 
> Diameter peers
> will select a path that will allow command C3 to be sent from Diameter
> client to server.
> 
> The question is whether it should also advertise the 
> application that it
> inherited command C1 from, even though it doesn't support command C2.
> 
> If the application-Id in question is Diameter Base 
> (Application-ID 0) I
> think there is no issue, since this is mandatory-to-implement for all
> Diameter peers.
> 
> However, if we are talking about multiple inheritance (e.g. inheriting
> commands from an Application-Id other than Base authentication and
> accounting) I think we have a problem.  I'd interpret RFC 
> 3588 as allowing
> an out for this, since the number of round-trips is changed (e.g. the
> common is disallowed altogether).
> 
> Does this make sense?
> 
> In this particular case, is there any issue with advertising 
> Diameter Base
> Common Messages as well as EAP?  I think there isn't because 
> EAP supports
> all Base commands.  However, there might be an issue with advertising
> NASREQ where the NAS or server doesn't support PAP/CHAP (AAR/AAA).
>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 7 Jul 2004 06:50:10 -0700 (PDT)

> in the specification of application Y.

Agreed.

> it must support C1 and C2. C1 is used with app-id X.

Yes.

> it must support C1 and C3. C1 is used with app-id Y.

This is where we disagree.  C1 cannot use app-id Y unless application Y
changes the nature of the command by adding a requirement for a new
mandatory AVP.  Otherwise it needs to use application X, as described in
RFC 3588.

> If a DiameterIdentity advertises support for application X and Y, it
> must support C1, C2, and C3. C1 can be used with app-id X and Y.

I disagree.  C1 can only be used with app-id Y if another mandatory AVP is
defined.  Otherwise, C1 can only be used with app-id X.