Subject: [Dime] [3588-bis] Auth/Acct-Application-Id redundant?

From: "Mark Jones" <[email-masked]>
Date: Mon, 10 Sep 2007 15:27:02 -0400

Section 6.8 of the 3588-bis-06 draft states that the
"Auth-Application-Id MUST also be present in all Authentication and/or
Authorization messages that are defined in a separate Diameter
specification and have an Application ID assigned." A similar statement
appears in section 6.9 for the Acct-Application-Id.

However, the application ID is already present in the message header and
sections 6.8/6.9 state that "the value of the Auth/Acct-Application-Id
AVP MUST match the application id present in the diameter message header
except when used in a CER or CEA messages".

I understand the usage of these AVPs in CER/CEA but what is the reason
for their mandatory (and apparently redundant) inclusion in the other
message types?  The draft also has statements about command routing
based on these fields but why would one ever dig them out of the message
body when an identical value appears in the header?

I looked back through the DIME mailing list archive and it appears that
the previous threads sought to clarify the content of these AVPs rather
than question their mandatory presence. 

I'd like to see this cleaned up in the bis because the current text
results in IETF commands that can not be re-used in vendor-specific
applications without ABNF conflicts. I will provide cleanup text for the
bis if the list agrees that this is worthwhile.

Regards
Mark

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

---

From: Victor Fajardo <[email-masked]>
Date: Mon, 10 Sep 2007 15:40:05 -0400

Hi Mark,

> than question their mandatory presence. 

You may also want to take a look at 
http://www.tschofenig.priv.at:8080/diameter-interop/issue13 which discusses 
this issue and what resolution we currently came up with.

> bis if the list agrees that this is worthwhile.

What conflicts ? I suggest we should be very careful with this issue. 
Changing the rules/semantics on application id (especially in the 
header) is very dramatic at this stage of the game.

regards,
victor

---

From: "Mark Jones" <[email-masked]>
Date: Tue, 11 Sep 2007 10:59:51 -0400

<snip>
> this issue and what resolution we currently came up with.

Thanks for the URL, Victor. I have updated the subject of this email to
refer to the original issue.

I've reviewed the issue comments and I'm in agreement with Jan
Nordqvist's analysis (posted 2006-09-07.13:22:13). The
Auth/Acct-Application-ID AVPs are redundant except in CER/CEA commands
and should not be mandatory for all new commands. As Jan suggests, we
can eliminate a lot of confusion by redefining these AVPs as optional
outside CER/CEA messages.

> What conflicts ? I suggest we should be very careful with this issue. 

The conflict comes when a vendor designing a new application finds an
IETF-defined command that is a candidate for reuse. When the vendor
reuses the command, the application id in the command header will be the
vendor-specific application id assigned to the vendor's new application.
The IETF-defined command contains the required Auth-Application-Id AVP
and 3588-bis states that the Auth-Application-Id AVP value MUST match
the header so it will also contain the vendor-specific application id.
However, the grouped Vendor-Specific-Application-Id AVP is used to
advertise a vendor-specific application and not the Auth-Application-Id
AVP. The vendor can't use the Vendor-Specific-Application-Id AVP instead
of the Auth-Application-Id AVP because the resulting command would not
comply with the original command ABNF.

> header) is very dramatic at this stage of the game.

I agree we should be cautious. However, by relaxing the "MUST be
present" requirement to a "MAY be present", we free new applications
from this obligation to create redundancy without breaking existing
applications that have already included the AVPs in their ABNF. I think
the changes to the bis are relatively minor.

Regards
Mark

---

From: Victor Fajardo <[email-masked]>
Date: Tue, 11 Sep 2007 17:22:27 -0400

> outside CER/CEA messages.

For new commands this maybe possible but I do not suggest redefining 
these AVPs for existing commands. You can easily create backward 
compatibility issues if we modify any existing comm

> the header so it will also contain the vendor-specific application id.

Mmmm ... maybe I missed something but I specifically remember that the 
solution for clarifying the original issue was that only one of the 
auth, acct or vendor app id MUST be present in the message and MUST 
match the app id in the header (6.1.1). Perhaps allowing more that one 
app id AVP in the message causes more confusion ....

> the changes to the bis are relatively minor.

It may not be as minor. If a very recent implementation decides that it 
will follow the "MAY" specification and therefore possibly not include 
these AVPs the way the older implementation does then obviously there 
will be backward compatibility problems. I'm not sure I totally 
understand the problem you mentioned but my suggestion would be to use 
the rules in 6.1.1 to keep things simple. If a new application where to 
inherit from an older app, they can easily apply for a new vendor app id 
and use that scheme instead of having more than one app id indicator 
present in the message.

regards,
victor

---

From: <[email-masked]>
Date: Wed, 12 Sep 2007 12:41:35 +0300

Hi,

> The vendor can't use the Vendor-Specific-Application-Id AVP
> instead of the Auth-Application-Id AVP because the resulting
> command would not comply with the original command ABNF. 

Perhaps it would be useful allow that "original" command ABNF
can be modified if the application-id changes.

Command-code and application-id should be used together
to identify the applicable command ABNF.

Best Regards,
Mikko

>-----Original Message-----
>From: ext Mark Jones [mailto:[email-masked]] 
>Sent: 11 September, 2007 18:00
>To: Victor Fajardo
>Cc: [email-masked]
>Subject: RE: [Dime] Issue 13: Duplication of application ID in 
>header and avps
>
><snip>
>>

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 12 Sep 2007 09:46:27 -0400

> can be modified if the application-id changes.

Mikko, I'd rather we address the root cause than risk creating
additional confusion with these types of exceptions in 3588-bis. For
conflicts in existing commands, I think we can document the preferred
workaround in the Design Guidelines draft but lets not propagate the
issue into new commands.

I am not suggesting that we redefine the application id AVPs or remove
them from existing commands. I am proposing that we relax the rule that
they MUST appear in every new command ABNF.

> to identify the applicable command ABNF.

Agreed and since both are in the command header there is no need to
duplicate application ids in the message body. All the Diameter
implementations I'm aware of are using the header fields to locate the
command ABNF. I don't see any advantage to digging the application id
out of AVPs in the message body rather using the one in the command
header.

Regards
Mark

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 12 Sep 2007 09:47:32 -0400

Hi Mikko,

[..snip..]
> to identify the applicable command ABNF.
[TOLGA]My understanding is that this is against what we currently have.
Each command is the same for all applications and if there is a need to
add mandatory AVPs etc... one needs to create a new command.

---

From: "Mark Jones" <[email-masked]>
Date: Wed, 12 Sep 2007 16:42:53 -0400

Now that 3588-bis requires the application id AVP value to match the id
in the diameter message header (except CER/CEA), I propose a cleanup of
the following sections (in 3588bis-07) to avoid any confusion around
request routing:

1st Change: Remove the following text from Section 6.1: 

   Request messages that may be forwarded by Diameter agents
   (proxies, redirects or relays) MUST also contain an Acct-
   Application-Id AVP, an Auth-Application-Id AVP or a Vendor-
   Specific-Application-Id AVP.

2nd Change: Remove the following bullet from Section 6.1.1:

   o  an Acct-Application-Id AVP, an Auth-Application-Id or
      a Vendor-Specific-Application-Id AVP must be included 
      if the request is proxiable. The application id present
      in one of these relevant AVPs must match the application
      id present in the diameter message header.

3rd Change: Remove the following text from section 6.1.6:

   It MAY also rely on the application identification AVPs 
   Auth-Application-Id, Acct-Application-Id or Vendor-Specific-
   Application-Id instead of the application id in the message
   header as a secondary measure.

I'm also proposing the following changes which relax the requirement to
include an application id AVP in every new command. This does not impact
existing commands or backwards compatibility.

4th Change: Update text in section 6.8:

   The Auth-Application-Id AVP (AVP Code 258) is of type 
   Unsigned32 and is used in CER or CEA messages in order to 
   advertise support of the Authentication and Authorization 
   portion of an application (see Section 2.4).  If present 
   in a message other than CER/CEA, the value of the Auth-
   Application-Id AVP MUST match the application id present
   in the diameter message header.

5th Change: Update text in section 6.9:

   The Acct-Application-Id AVP (AVP Code 259) is of type
   Unsigned32 and is used in CER or CEA messages in order to
   advertise support of the Accounting portion of an 
   application (see Section 2.4). If present in a message
   other than CER/CEA, the value of the Acct-Application-Id 
   AVP MUST match the application id present in the diameter
   message header.

Regards
Mark

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 12 Sep 2007 18:06:40 -0400

Hi Mark,

I'm ok with the changes. If anybody else have some additional comments 
on the text pls provide them ASAP.

regards,
victor