Subject: [Dime] Application Id AVPs in message bodies

From: Mark Jones <[email-masked]>
Date: Thu, 9 Oct 2008 12:16:14 -0400

The 3588bis still has requirements for application ids to be present in non-CER/CEA messages:

6.11.  Vendor-Specific-Application-Id AVP
...

   This AVP MUST also be present as the first AVP in all experimental
   commands defined in the vendor-specific application.
---

9.7.1.  Accounting-Request
...
   One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs
   MUST be present.  If the Vendor-Specific-Application-Id grouped AVP
   is present, it MUST include an Acct-Application-Id AVP.

---

9.7.2.  Accounting-Answer
...
   One of Acct-Application-Id and Vendor-Specific-Application-Id AVPs
   MUST be present.  If the Vendor-Specific-Application-Id grouped AVP
   is present, it MUST contain an Acct-Application-Id AVP.
---

The draft already states that an application id AVP in the message body (non-CER/CEA) MUST match the Application Id present in the Diameter message header so I propose the above requirements be removed from 3588bis. Objections?

Regards
Mark

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

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 14 Oct 2008 16:22:14 -0400

Hi Mark,

Changes looks ok to me.

-- victor

---

From: Rajith R <[email-masked]>
Date: Wed, 15 Oct 2008 10:43:55 +0530

Hi
1. Why these requirements should be removed?
2. <quote> The draft already states that an application id AVP in the
message body (non-CER/CEA) MUST match the Application Id present in the
Diameter message header </quote>
Is not this an altogether different requirement than the ones you are
suggesting to remove? I cannot understand how they are related or am I
missing something here?

regards
Rajith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark
Jones
Sent: Thursday, October 09, 2008 9:46 PM
To: [email-masked]
Subject: [Dime] Application Id AVPs in message bodies

The 3588bis still has requirements for application ids to be present in
non-CER/CEA messages:

---

9.7.2.  Accounting-Answer
...

The draft already states that an application id AVP in the message body
(non-CER/CEA) MUST match the Application Id present in the Diameter message
header so I propose the above requirements be removed from 3588bis.
Objections?

Regards
Mark

---

From: Mark Jones <[email-masked]>
Date: Wed, 15 Oct 2008 08:59:39 -0400

Hi Rajith,

The application ID is always present in the Diameter command header. These requirements are mandating the presence of redundant application ID AVPs in the message body. Do you see any reason to keep these requirements?

Regards
Mark

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Rajith R
> Sent: October 15, 2008 01:14
> To: Mark Jones
> Cc: [email-masked]
> Subject: Re: [Dime] Application Id AVPs in message bodies
>
> Hi

---

From: Rajith R <[email-masked]>
Date: Wed, 15 Oct 2008 19:51:23 +0530

Hi
	I know of some Diameter applications that share the same application
Id value b/w an Auth. & Accounting application, for e.g. 3GPP Rel-6 Cx &
Accounting (see 32.299 v6.0.0) share the same application Id viz. 16777216.
An explicit Auth- or Acct-Application-Id AVP in the message is needed in
this case.
	Also, if 2 vendors provide the implementation of the same Diameter
application, would not the Vendor Specific Application Id be useful in
request routing?

Regards
Rajith

-----Original Message-----
From: Mark Jones [mailto:[email-masked]] 
Sent: Wednesday, October 15, 2008 6:30 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Dime] Application Id AVPs in message bodies

Hi Rajith,

The application ID is always present in the Diameter command header. These
requirements are mandating the presence of redundant application ID AVPs in
the message body. Do you see any reason to keep these requirements?

Regards
Mark

> Behalf Of Mark

---

From: Mark Jones <[email-masked]>
Date: Wed, 15 Oct 2008 11:15:43 -0400

Hi Rajith,

Answers inline...

> From: Rajith R [mailto:[email-masked]]
> Sent: October 15, 2008 10:21
> To: Mark Jones
> Cc: [email-masked]

The Diameter command header contains an application id and a command code. That is sufficient to uniquely identify a command type without parsing the message for additional AVPs.

> application, would not the Vendor Specific Application Id be useful in

The Vendor-Specific-Application-Id AVP in the message body MUST contain the same value as the Diameter command header so I don't see how the AVP can be useful for request routing. You may want to review section 6.11 in 3588bis because I think you may be misusing the Vendor-Id in the Vendor-Specific-Application-Id AVP.

Regards
Mark

---

From: Rajith R <[email-masked]>
Date: Thu, 16 Oct 2008 09:34:42 +0530

Hi
	Some comments inline.
> Sent: Wednesday, October 15, 2008 8:46 PM
> To: [email-masked]
> Cc: [email-masked]
> The Diameter command header contains an application id and a command
> code. That is sufficient to uniquely identify a command type without
> parsing the message for additional AVPs.
[Rajith R] This is ok for the server application handling the command.
However the relay, to route it to the correct server, viz. the HSS or the
OCS, will use only the Application Id (& of course the Destination Realm),
not the command code. In this case, the specific Application Id AVP in the
message may have a use.
> The Vendor-Specific-Application-Id AVP in the message body MUST
> contain the same value as the Diameter command header so I don't see
> how the AVP can be useful for request routing. You may want to review
> section 6.11 in 3588bis because I think you may be misusing the
> Vendor-Id in the Vendor-Specific-Application-Id AVP.
> 
[Rajith R] I would like to retain this AVP also because I think it will help
relays to route the Diameter message to an appropriate server, if there are
2 vendor specific implementations of the same application in a realm.

---

From: Mark Jones <[email-masked]>
Date: Thu, 16 Oct 2008 09:54:55 -0400

Comments inline...

> Sent: October 16, 2008 00:05
> To: Mark Jones
> Cc: [email-masked]

[MJ] You can not have one application id in the command header and a different one in the message body. This is explicitly forbidden by 3588bis sections 6.8/6.9/6.11. Are you requesting this text be removed from 3588bis? If you have a vendor-specific implementation that has its own vendor-specific Application Id then you would put that Id in the Diameter command header and proxies/relays would route based on it.

> > > application, would not the Vendor Specific Application Id
> be useful
> > in
> > > request routing?
> > >
> >

[MJ] The Vendor-Id in the Vendor-Specific-Application-Id is that of the application author. It is not the Id assigned to the vendor of the Diameter device so I don't see how it helps in message routing.