RE: clarification on extensibility rules

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

I will be curious to see all AAA_doctors' opinions.

W.r.t. the question if we should review other SDO AAA documents,
my take is that I think such would be beneficial to the community.
But we can only do so if we all (AAA-doctors on this list) agree
to indeed put cycles to that when we actually do get such
requests.

Bert


> -----Original Message-----
> From: owner-aaa-doctors@ops.ietf.org
> [mailto:owner-aaa-doctors@ops.ietf.org]On Behalf Of Jari Arkko
> Sent: Friday, April 15, 2005 14:31
> To: AAA Doctors
> Subject: clarification on extensibility rules
> 
> 
> 
> Hello folks,
> 
> I have a question that relates to some of the ongoing work in 3GPP
> to use Diameter for some of their interfaces.
> 
> This is basically the re-use of a standard application, but with some
> additional attributes that are mandatory in the given context. I'd
> like to advice our people on what the right way to go about this is,
> but its not easy. Perhaps you can help. I'll use the credit control
> application as an example and provide a couple of potential ways
> to do what is needed, along with the implications for interoperability
> of our protocols:
> 
> 1. Define the additional information as an optional attribute, but
> take a "policy level" decision that when this information does not
> come, you reject access.
> + this has the least impact on the protocols, can use existing
>    applications as is
> - could be used to circumvent extensibility rules
> - what exact error code to return?
> 
> 2. Allocate a new vendor-specific application identifier.
> + This seems most in line with the intent of RFC 3588. It
>     says that adding mandatory AVPs requires a new application
>     identifier
> -   Here's where we get to the problem. Since we are using
>     a standard command, the syntax is of the form:
> 
>               { Auth-Application-Id }
> 
>     and not
> 
>                [ Acct-Application-Id ]
>                [ Vendor-Specific-Application-Id ]
> 
>     as in accounting application, for instance. As a result,
>     if the application identifier is vendor-specific this would
>     break the original command ABNF.
> 
> 3. Allocate a new vendor-specific application identifier,
>     and use Vendor-Specific-Application-Id in the ABNF
>     instead of Auth-Application-Id.
> + Seems reasonable
> - Does this change of the ABNF require a new command code?
>   The rules on how to add new command codes are not
>   crystal clear.
> - Are there issues in passing these through proxies?
> 
> 4. Allocate a new vendor-specific application identifier,
>     but place it in Auth-Application-Id in order to avoid
>     the problem above.
> + The syntactic changes are minor, as in alt #1.
> - Placing a vendor specific application identifier to this
>   AVP seems incorrect.
> 
> In short, there are a number of approaches all of which seem
> to suffer from at least some problems. I think alt #3 is the
> most "correct", but it appeals to me only if it doesn't imply
> command code allocation.
> 
> Overall, there are two meta-issues in this problem. The first
> one is that when people attempt to use Diameter in a new
> context, they are running into extensibility rules that, imho,
> force them to diverge more from the original applications
> that would really be necessary. It looks like the extensibility
> rules may, in some cases, be working in favor of divergence
> rather than against it as originally intended. If it were up to
> me, I'd recommend alt #1.
> 
> The second meta-issue is how could we better instruct the
> community on what the right approach is. Is there an interest
> in taking on "aaa doctor reviews" of other SDO documents?
> 
> --Jari
> 
>