Subject: Clarification of discussion on Data Models

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 14 Jan 2001 00:39:33 -0800

There seems to be some confusion about what exactly we are trying to do with
Data Modelling.

I would like to try to clarify one or two things.

It seems to me that DIAMETER, in its present form, can be used to transmit
attributes containing SPPI, SMIng, SMI, XML or any other chosen format by
defining an octet-string attribute to encapsulate these formats.

As a result I don't think the discussion is about whether we can encode
SPPI, SMIng, SMI, XML or anything else in attributes. We can do this.

Secondly, I don't think this debate is about the DIAMETER wire protocol. I
say this because I haven't noticed anyone suggesting that we change the wire
protocol to make it more compatible with any of the above formats.

So what are we discussing, exactly?

The design team discussion took off from some observations made about
difficulties encountered in RADIUS.
The RADIUS Tunnel attributes, though they constituted only a relatively
modest departure from the previous attribute set, could not easily be
accomodated by many implementations. UI code had to be re-written;
dictionary formats had to be extended; packet sniffers had to be updated,
etc. Since the whole idea of the RADIUS dictionary was to enable addition of
new attributes without such code changes, this seemed to expose a RADIUS
limitation that was likely to only get worse with time. The issue was deemed
serious enough to be worth fixing in DIAMETER.

So a problem that the design team took on was to find a way of increasing
the flexiblity of the DIAMETER dictionary so that you really could add
attributes, even more complicated ones, without having to change code. Note
that the goal wasn't to be able to express attributes of infinite
complexity, but merely to be able to express the most complicated attributes
that we believed would appear within the problem domain.

Secondly, there was a discussion of how the DIAMETER protocol itself should
be defined. The BNF notation introduced in the drafts didn't seem entirely
satisfactory, so the question was how this could be improved. Note that the
goal wasn't to change the protocol, merely to more rigourously define the
protocol as it exists.

Erik Guttman, Juergen Schoenwaelder, and David Spence have taken on these
problems and come up with potential solutions. So in evaluating these
solutions it's worthwhile to compare them against the problem space.

To my mind, in this exercise, as in everything else we do, our goal is NOT
to figure out how much functionality we can cram into DIAMETER. It is to
figure out the simplest, most elegant solution that can get the job done.

RADIUS, as limited as it is, is very widely deployed because of its
simplicity, and as a result may prove exceedingly difficult to dislodge. You
cannot defeat a lightweight, highly mobile guerilla army during monsoon
season by bringing in heavy armour -- you'll just get stuck in the mud.
You've got to be lightweight and mobile yourself.