Subject: [AAA-WG]: Vendor Command Code resolution

From: <[email-masked]>
Date: Mon, 24 Jun 2002 15:35:41 +0300

Hi all,

Here is a summary of the direction taken during a discussion with
3GPP. 

The main issue is that VSCs generally require understanding in an 
implementation.  Currently, we have no way to manage communication
between implementations where there is not support for VSCs that
are sent by a Diameter peer.  There is high-level concern that 
use of VSCs will great interoperability problems.  Standardization of
command codes are prefered.  Standardization bodies using Diameter
extensions are strongly encouraged to standardize these.

In summary, what is needed to the base specification is:

a. Eliminate vendor-specific commands, but keep vendor-specific AVPs.

b. Carve out an "experimental" playpen space within the existing command
   space, where vendors can create experimental commands.

c. Allow use of Application IDs in a broader set of circumstances:
     1. To indicate support for a set of vendor-specific AVPs with the 'M'
        bit set
     2. To indicate support for an "experimental" command

As a result, it will no longer be required that an application have a new
command (standard or vendor-specific) associated with it.

Some implications of this:

d. The CER/CEA exchange should prevent sending of Vendor-Specific AVPs
   with the 'M' bit set to peers that do not support those AVPs. This means
   that the Diameter peers won't need to retry without 'M' bit AVPs after an
   "unrecognized AVP" error.

e. Conflicts between "experimental" commands are avoided as long as the
   application IDs are unique.

f. The Application ID space needs to be partioned between
   "applications with new 'M' bit AVPs, but no new commands" and
   "applications with commands." Reasons for this are described in g.

g. Two types of generic advertisement are needed. Today we have the
   "Relay" advertisement that implies "all applications." But we also need 
   an "any AVPs" advertisement for Accounting Servers. This allows an 
   Accounting Server to advertise that it can accept any AVP, without also 
   implying that it can handle any "experimental" command thrown at it, 
   which is difficult or impossible to support in practice.

Note that if this were not done then we would undermine capabilities
negotiation, since peers could advertise capabilities they didn't really
support.

best regards,
John

PS - thanks to Bernard who wrote down the proposal from our conference call.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 24 Jun 2002 19:09:34 -0700

> Here is a summary of the direction taken during a discussion with

So is this an actual proposal, a meeting report, or the report of a decision
(ordinarily I would never suggest the last, since this is the IETF, but it
has that tone...).

> are sent by a Diameter peer.

That depends upon how you define "manage communication".  At the risk of
becoming tediously repetitive, I pointed out on this list more than two
weeks ago (to thundering silence) that there already exists a well-defined
method to handle unrecognized commands (vendor-specific or otherwise).  For
convenience, I'll quote it here: "...if a vendor-specific request is sent to
a box that doesn't support it, the resulting answer (same command code for
easy identification) will have the E bit set and a result code of
DIAMETER_COMMAND_UNSUPPORTED.  How much simpler (sic) can you get?".  Of
course, that doesn't help to avoid sending the inappropriate command in the
first place.  However, there is an easy way to fix this: simply make the
relationship between application and command code reciprocal.  Right now, I
believe that the creation of a new application requires the creation of a
new command code but not vice-versa please correct me if I'm wrong).  In my
mind, anyway, this relationship has always been reciprocal (i.e., the
introduction of a new command _requires_ the use of a new application ID.
If this is done, then I believe that (presupposing that no lying takes place
during the capabilities exchange process) that it would be impossible to
send a command that is unsupported by the peer.

> There is high-level concern that
> use of VSCs will great interoperability problems.

If by "high-level" you mean the IESG, my understanding is that the concerns
have more to do with the assignation of blame for lack of interoperability
than the interoperability problems themselves (maybe Randy can comment on
this).  Currently, I believe that it would not be a protocol violation to
add a VSC to a standard application (say, NASREQ) and claim that the result
is "Diameter",  This is a problem, but I think that my above proposal closes
that loophole.

> Standardization of

I assume that by "standardize these" you mean "standardize these in the
IETF".  Unfortunately, standardization in the IETF can be a long process and
as we have noticed deadlines of organizations outside the IETF (e.g., 3GPP &
3GPP2) have little effect upon the speed of the process.  For example, 3GPP2
has been waiting for the IETF to standardize Diameter for almost 4 years
now; would they (or 3GPP) be pleased to tie their release to what is
essentially a nondeterministic process?

>    "applications with commands." Reasons for this are described in g.

"g." discusses only accounting; since the "standard" accounting service just
logs stuff, the use of the 'M' bit seems uncessary.  So if 3GPP wants to be
able to set the 'M' bit on VSAs, why?

>    which is difficult or impossible to support in practice.

There is no need for a new advertisement: simply make the
Acct-Application-Id AVP required in all accounting and capabilities exchange
messages, and define a value for it in the base protocol that means
"Standard".

---

From: Tony Johansson <[email-masked]>
Date: Wed, 26 Jun 2002 15:45:54 -0700

Hi John, All,

Okay, so if the conclusion with IESG is that we cannot keep the VSCs and should
instead have an experimental command code space, that to me is still perfectly
find and should cause very little modification to the base. Thus, replacing VSCs
with a "experimental"  command code space, clarifying the relation between
creating new command codes and applications (which to most parts is already in
place) and adding support for applications with or without mandatory VSAs.

Please see further comments embedded.

/Tony

>    space, where vendors can create experimental commands.

So, with bullet a and b, we have replaced the VSCs with an experimental command
code space. So, for this a small section needs to be added that defines the
experimental command code space.

> command (standard or vendor-specific) associated with it.

However, as been mention on the list, to create and use a new experimental
command code you MUST also create a new application in which the new command
code will be run. Thus, make the relationship between application and command
code reciprocal.

>    application IDs are unique.

Since, this will be just a pool of experimental command codes, which means that
the same experimental command code may be reused in several vendor specific
application, we need application IDs and the Vendor ID in the Diameter header
(as of today, i.e. let be as is) to guarantee avoiding conflict.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Jun 2002 16:32:03 -0700 (PDT)

Comments below.

> experimental command code space.

Yes. This is a portion of the existing command code space, no? The
question is how much space is required.

> code will be run. Thus, make the relationship between application and command

Yes. New command codes (experimental or not) require a new application id.
However, I'd also argue that a new application ID can also be used
*without* a new command code (for example, when a bunch of new AVPs with
the 'M' bit set are added to existing commands).

> (as of today, i.e. let be as is) to guarantee avoiding conflict.

Yes.

---

From: Tony Johansson <[email-masked]>
Date: Wed, 26 Jun 2002 18:46:53 -0700

> the 'M' bit set are added to existing commands).

Agree.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 26 Jun 2002 21:35:01 -0700

> > the 'M' bit set are added to existing commands).

The restriction that a new application must include a new command code
resulted from conversations with the IESG (a _long_ time ago).  I believe
that the concern was that there would be a flood of new "applications" which
simply used existing AVPs in some non-standard way, or were created to get
around restrictions in the standard protocol that for whatever reason were
viewed as unpalatable.  Since it seems to me that that is exactly what
Bernard is suggesting, maybe they were right.  On the other hand, it's a new
IESG, so maybe they won't mind...

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Jun 2002 22:49:42 -0700 (PDT)

> simply used existing AVPs in some non-standard way, or were created to get

Can you give an example of this? If you are merely adding some optional
AVPs, as long as the ABNF isn't violated, I wouldn't think that a new
application ID is required. However, if vendor-specific AVPs with the 'M'
bit set are included, then you might as well know whether the peer will be
able to handle them before sending them, no? This doesn't affect
interoperability because presumably the 'M' bit AVPs wouldn't be supported
on the peer anyway.

---

From: "Fredrik Johansson" <[email-masked]>
Date: Thu, 27 Jun 2002 08:46:09 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Bernard Aboba
> Sent: den 27 juni 2002 07:50
> To: Glen Zorn
> Cc: Tony Johansson; [email-masked]; [email-masked]
> Subject: RE: [AAA-WG]: Vendor Command Code resolution
>
>

But does this realy help, the capability negotiation is not end-to-end
anyway. in many cases when adding VSA they are intended for the end node, so
what does it help to know what the next hop can do?

/fredrik

---

From: Randy Bush <[email-masked]>
Date: Wed, 26 Jun 2002 23:42:23 -0700

> Okay, so if the conclusion with IESG is that we cannot keep the VSCs and
> should instead have an experimental command code space
                        ^ temmporary
that will go away in a year or so.  it's just a kindness to help release
5

randy

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Jun 2002 23:08:44 -0700 (PDT)

> what does it help to know what the next hop can do?

The next hop is either a relay (in which case it will pass everything) or it is
a proxy that needs to understand semantics. If it needs to understand
semantics then it will need to understand the 'M' bit AVPs, too, no? If it
is a relay then based on the capabilities negotiation, it can look for a
downstream server with the capabilities supported by the upstream NAS.

So while Diameter supports hop-by-hop capabilities negotiation, it is also
capable of ensuring compatible capabilities along the path.