Re: Object identifier and type spaces in a rationalized RADIUS data model

[Barney Wolff <barney@databus.com>]

On Thu, Jun 10, 2004 at 10:19:23AM -0400, Nelson, David wrote:
> Bernard Aboba writes...
> 
> > It *might* even obsolete the need for new RADIUS work in some areas --
> > some existing Diameter applications might be reusable.  That
> > is a huge win if it is possible.
> 
> This *is* an attractive concept.  I'm vaguely concerned, however, that
> we not take this to the next step and attempt to retrofit RADIUS with
> some|many|all of the features of Diameter.  That used to be an explicit
> prohibition in an earlier charter draft.  I think that we need to focus
> on the unified data model issue and the Diameter compatibility issue,
> without falling into the trap of creating a RADIUS-Plus protocol.

Agreed.  However I think it's useful to think separately about (to use
ASN.1 terms) abstract syntax and transfer syntax when thinking about the
data model.  That is, the same "thing" in client & server storage may look
different when transferred in the value field(s) of RADIUS & Diameter,
without introducing unendurable complexity on a protocol gateway between
them.  Obviously it would be easier, when possible, for the transfer
syntax to be the same, but (to me) it's not a showstopper if not.  One
could take the opposite view, that the protocol gateway MUST NOT need to
alter an attribute's value field in order to do its work.  That's a
decision that ought to be standardized.

Do we have any guidelines on what characteristics of an application would
make it ill-suited to RADIUS, restricting it to Diameter?

Conversely, would any Diameter application proposer ever be willing to limit
its functionality or data model in order to achieve RADIUS compatibility?
Can there be guidelines for this, or should it be separately decided for
each new application?

Barney

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>