Subject: RE: [AAA-WG]: types of experimental command

From: <[email-masked]>
Date: Mon, 8 Jul 2002 10:51:58 +0300

Hi Bernard,

> Vendor-specific AVPs and Vendor-Specific commands are 
> separable issues.
> 
> Since there has been no IESG objection to vendor-specific AVPs, and since
> these have a long history (they are supported in RADIUS), and there is WG
> consensus on keeping vendor-specific AVPs, we should assume that support
> for vendor-specific AVPs will remain in Diameter, and we don't need to
> revisit the issue.
> 
> Similarly, I don't believe that it makes sense to forbid VSAs within
> standard commands. This is also something that has been supported in
> RADIUS for a long time, and so I'd like to take that issue 
> off the table as well.

I agree.

[text clipped]

> The problem comes in interpretting the meaning of the command. A new
> command could be essentially the same as a standard command with a
> slightly different ABNF for a new access type; or it could imply
> dramatically different functionality. In the latter case, a code change is
> required on *both* the NAS and Diameter Server in order to support it. In
> the former case, only the NAS requires a code change.
> 
> Thus, it seems to me that it would be valuable to define the 
> two types of experimental command:
> 
> 1) One type of "experimental" command which implies "this
> command is essentially the same as an existing standard command, but with
> a new ABNF", and perhaps some new (or vendor-specific AVPs). 
> With such a command, the Diameter server can look for the ABNF 
> corresponding to the command code and know what to do with no code changes. 
> The NAS will typically need a code change though.
> 
> 2) Another type of "experimental" command which implies "this command is a
> new animal, and if you don't understand it, send an error message." This
> kind of command requires new code on both the Diameter server and NAS.
> 
> Does this make sense?

The issue I would have with this, is can we make a clear division
between the two.  At what point does a experimental command, which
is based upon an existing command become a new animial? 

One thing we could do is to suggest that experimental commands that
are based on existing commands, include the command code in its ABNF.
This would give a clue to server on how to process the command.

Would this be reasonable?
John