Subject: [AAA-WG]: Mandatory Vendor-specific AVP's

From: "Daniel Warren" <[email-masked]>
Date: Thu, 13 Jun 2002 13:23:48 +0100

All

I would like to just make sure that there is some common understanding about
when a Vendor can define an AVP as being mandatory and what this actually
means.

Case 1 - Extending an IETF defined command by adding a Vendor Specific AVP
In this case, the AVP has to be optional.  Setting the Mandatory AVP bit
would mean that all implementations would have to support this AVP in the
command and so that would no longer be vendor specific, but would rather be
a requirement.

Case 2 - Vendor defines a Vendor Specific Command
Within this command, the vendor is able to set Mandatory AVP's.  That would
indicate that if the Command is supported on an implementation, the AVP has
to be present.  However, the command as a whole has to be optional so that
it does not violate interoperability with other vendor's implementations.

These two points seem obvious to me, but I think the discussions of the last
few days have shown some confusion about what a vendor can and cannot
reasonably define and implement in terms of extensions to Diameter.
Fundamentally, the rule has to be that no peer is obliged to implement any
vendor specific extension, be it an AVP, Command, or entire application.

Dan

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 13 Jun 2002 05:51:54 -0700 (PDT)

> command and so that would no longer be vendor specific, but would rather be

Why is this true? Vendor extensions relating to security need to be
mandatory or security is compromised. We saw this with RADIUS when vendors
added support for explicit filters, and NASes that didn't understand them
did a silent discard, resulting in networks being provisioned without
filters, with no error message to the AAA server.

> Within this command, the vendor is able to set Mandatory AVP's.

No! Vendor Specific Commands are a last resort, since they require new
code on the AAA server, whereas vendor-specific AVPs (mandatory or not)
can often be added to the dictionary. So the result of using a VSC instead
of a mandatory vendor-specific AVP is that only the vendor's Diameter
server can be used with their NAS.

> That would

I don't see how a legitimate VSC can be optional. If it truly represents a
new kind of service, then either the AAA supports that service or not.
However, I can see an unsolicited VSC sent from AAA server to NAS being
optional.

> vendor specific extension, be it an AVP, Command, or entire application.

I don't agree with this interpretation - the spec allows (and even
encourages) use of vendor-specific AVPs instead of vendor-specific
commands and applications. VSAs can be mandatory.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 13 Jun 2002 07:46:00 -0700

> filters, with no error message to the AAA server.

I think that the problem here arose less from the lack of support for the
attribute than from the overly taciturn nature of RADIUS.  This problem
shouldn't arise with Diameter, since it _will_ return an error message.

> new kind of service, then either the AAA supports that service or not.

Exactly; I would call that "optional", as opposed to standard commands which
are by nature mandatory.  If the AAA doesn't support the standard commands,
it doesn't support Diameter, but if it lacks support for some (or any) VSCs
and does support the standard command set, it still supports Diameter.

> commands and applications. VSAs can be mandatory.

I agree.