Subject: [Dime] application identifiers

From: Anders Kristensen <[email-masked]>
Date: Wed, 01 Mar 2006 22:54:00 -0500

All,

I have some questions on application IDs. This is all pretty fundamental 
stuff so hopefully I didn't get it completely wrong ;)

Applications are identified by the combination of vendor ID and 
application ID with IETF defined apps having vendor ID 0 (3588, 2.7). My 
understanding is that with the exception of CER and CEA which are 
special the following is true for all messages:

  - Messages belonging to IETF defined apps will never have a 
Vendor-Specific-Application-Id (VSAI) AVP.

  - Messages belonging to IETF defined apps may have either an 
Auth-Application-Id or an Acct-Application-Id AVP. If it does have one 
of those AVPs, the value will equal that of the Application-ID field in 
the message header.

  - Messages belonging to non-IETF defined apps must have exactly one 
VSAI AVP. This AVP must contain either an Auth-Application-Id or an 
Acct-Application-Id whose value must equal that of the Application-ID 
field in the message header. [This is not actually what I get from 
reading 3588 (see below) but it's what makes sense, I think.]

Are these statements correct?

If they're correct it follows that a vendor specific application cannot 
reuse commands defined in the base spec or at least that such messages 
cannot contain a Vendor-Specific-Application-Id and hence must be 
considered part of the base app, not the vendor specific app.

Some questions on specific section of 3588:

Section 2.4:

    Each Diameter application MUST have an IANA assigned Application
    Identifier (see Section 11.3).  The base protocol does not require an
    Application Identifier since its support is mandatory.

All Diameter nodes have to understand CER, DWR and DPR requests but 
clearly not all Diameter nodes will know what to do with, say, an ACR so 
this seems wrong.

6.11:

    The Vendor-Specific-Application-Id AVP (AVP Code 260) is of type
    Grouped and is used to advertise support of a vendor-specific
    Diameter Application.  Exactly one of the Auth-Application-Id and
    Acct-Application-Id AVPs MAY be present.
    ...
    <Vendor-Specific-Application-Id> ::= < AVP Header: 260 >
                                      1* [ Vendor-Id ]
                                      0*1{ Auth-Application-Id }
                                      0*1{ Acct-Application-Id }

The sentence "Exactly one of the Auth-Application-Id and 
Acct-Application-Id AVPs MAY be present" seems odd. Should't it be a 
requirement that exactly one of the AVPs be present? As it stands a 
Vendor-Specific-Application-Id containing just a Vendor-Id would seem to 
be OK.

And why are multiple Vendor-Ids allowed here? Are there any known 
situations where messages contain a Vendor-Specific-Application-Id with 
more than one Vendor-Id?

Also, the text seems to rule out inclusion of both Auth-Application-Id 
and Acct-Application-Id but wouldn't it be possible for an app to have 
both an accounting and an authentication portion or is that just 
disallowed? (The base app has both, right?)

Section 11.3:

    Both Application-Id and Acct-Application-Id AVPs use the same
    Application Identifier space.

and Auth-Application-Id too, right?

Comments much appreciated.

Thanks,
Anders

_______________________________________________
DiME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dime

---

From: "Tolga Asveren" <[email-masked]>
Date: Thu, 2 Mar 2006 09:57:12 -0500

Anders,

I am also confused based on seemingly confusing -at least to me-
statement/procedured in RFC3588.

I guess/believe/think ApplicationId is globally unique based on:
a)11.3 Application Identifiers
It seems like ApplicationIds for all types of applications are assigned from
the same pool

b)Message header has ApplicationId but no other field to further identify
the application the message is belonging to.

OTOH, espacially 2.7 seems to contradict the above view. If a global pool is
used for ApplicationIds, I don't see the reason why vendorId is necessary to
identify them uniquely.

Please see for more comments/questions below.

   Thanks,
   Tolga

> -----Original Message-----
> From: Anders Kristensen [mailto:[email-masked]]
> Sent: Wednesday, March 01, 2006 10:54 PM
> To: [email-masked]
> Subject: [Dime] application identifiers
>
>
> All,
>
[TOLGA]I am wondering, what is the use of those AVPs except when advertising
support during capability exchange procedure -eem then, why do we
distinguish between different types of applications, considering that
ApplicationId are assigned from a global pool-? Don't we have the
ApplicationId already in the message header -or am I missing something
fundamental-?
> Vendor-Specific-Application-Id containing just a Vendor-Id would seem to
[TOLGA]I think your understanding is correct.
> and Auth-Application-Id too, right?
[TOLGA]Yes, I think so, even vendor specific application Id use the same
identifier pool.

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 02 Mar 2006 11:16:50 -0500

Hi,

>used for ApplicationIds, I don't see the reason why vendorId is necessary to
I think Sec 2.7 has a bug. Only application id (which is/can be a vendor 
id) is relevant for routing.

[snipet]

>ApplicationId already in the message header -or am I missing something
We can add more to this confusion by looking at Sec 6.1 where an app id 
avp is mandatory for relayed messages. This implies that those avp's are 
used for routing instead of the id in the message header. OTOH, app-id 
definition in Sec 3 says that the app-id avp and the app-id in the 
header header must be the same but this is duplicated info as you 
pointed out. For routing, only the id in the header is relevant so you 
dont have to parse the entire message and look for an id.

victor

---

From: Anders Kristensen <[email-masked]>
Date: Thu, 02 Mar 2006 15:44:13 -0500

>> It seems like ApplicationIds for all types of applications are 

Yes, that's clearly the case. There's a single IANA registry for IDs of 
all types of apps.

>> used for ApplicationIds, I don't see the reason why vendorId is 

Agreed.

> header header must be the same

Would make sense if Vendor-Id was also needed for routing but I agree 
that given that app IDs come out of a single flat space apps are 
uniquely identified by the app id alone.

Anders

> but this is duplicated info as you

---

From: David Connelly <[email-masked]>
Date: Sun, 5 Mar 2006 00:52:07 -0800

My interpretation is that the Vendor-Ids within a Vendor-Specific- 
Application-ID are merely used to indicate which vendor-specific AVPs  
are required by the application. Perhaps some implementations could  
use this information to determine which AVP tables to use when  
interpreting the message.

However, looking at OpenDiameter is even more confusing as OD appears  
to allow routing of Diameter requests based on the VSAID vendor id(s)  
as well as the application id, implying that vendor id may be part of  
the application identity. This does not seem correct at all, but  
since OD is a popular implementation I wonder how many others may be  
based on this interpretation as well.

- David

---

From: <[email-masked]>
Date: Tue, 14 Mar 2006 15:52:07 +0200

Hi,

> If they're correct it follows that a vendor specific 
> application cannot reuse commands defined in the base spec or at
> least that such messages cannot contain a
Vendor-Specific-Application-Id
> and hence must be considered part of the base app, not the vendor
> specific app.
 
I think it is possible to re-use IETF defined command-code in vendor
specific Diameter application.

If the vendor specific application mandates that
Vendor-Specific-Application-Id AVP has to be used with the command in
the context of that application then it can be used (and must be used).

When new Diameter applications are defined it should be
considered whether to add application-id AVPs to ABNFs defined
in the application or if it is enough to have the id as part of
Diameter header. I think in most cases it is enough to have it
in the header only.

BR,
Mikko Aittola

> From: ext Anders Kristensen [mailto:[email-masked]] 
> Sent: 02 March, 2006 05:54
> To: [email-masked]

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 14 Mar 2006 09:18:29 -0500

Hi Mikko,

>specific Diameter application.
depends on which message and how you use it. session maintenance is one 
example (STR/STA, ASR/ASA) but generally one reason you define a vendor 
application is because your defining new message(s). i.e. new command-code.

regards,
victor

>>application cannot

---

From: "Tolga Asveren" <[email-masked]>
Date: Tue, 14 Mar 2006 14:08:46 -0500

Hi Mikko,

[.. snip ..]
> Diameter header. I think in most cases it is enough to have it
[TOLGA]Considering that all application Ids are assigned from a gloabal
pool, what would be the criteria to include/exclude application-Id AVPs for
new messages?

---

From: <[email-masked]>
Date: Wed, 15 Mar 2006 12:37:24 +0200

Hi,

> [TOLGA]Considering that all application Ids are assigned from 
> a gloabal pool, what would be the criteria to include/exclude 
> application-Id AVPs for new messages? 

I don't have any specific criteria in mind. Designers of
new application should consider the issue and if they don't
see any need for the separate app-id AVP then I think it
can be left out of the ABNF defined by the application.

BR,
Mikko

> From: ext Tolga Asveren [mailto:[email-masked]] 
> Sent: 14 March, 2006 21:09
> To: [email-masked]
> Subject: RE: [Dime] application identifiers
> 
> Hi Mikko,
> 
> [.. snip ..]