[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: clarification on extensibility rules


By the way, if we want I could ask my colleagues in 3GPP
to request a "review request" liason statement to be sent from the
relevant 3GPP group to the IETF. Would that be useful, or would
it create more process than you want?

--Jari

Wijnen, Bert (Bert) wrote:

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