Subject: Extended Attributes and Diameter Compatibility

From: Bernard Aboba <[email-masked]>
Date: Sun, 28 Jun 2009 13:56:50 -0700

During the Virtual Interim, we discussed the issue of translation of RADIUS Extended Attributes to Diameter.  Some of the following points arose during the discussion:

a. Even if RADIUS Extended attributes could be automatically translated to Diameter, does this make sense?  Diameter has more sophisticated grouping facilities than are possible with Extended Attributes.  So if an attribute was defined as Extended that used grouping, wouldn't it make more sense to use the Diameter grouping facilities in defining the Diameter version of the attribute? 

b. Status of RFC 4005bis in DIME.  David Mitton's original proposal for enabling translation of *any* RADIUS VSA to Diameter is not currently on the (revised) DIME WG charter.  It is not clear that there is interest within DIME to pursue this. 

c. Need for RADIUS/Diameter translation.  While RADEXT WG documents need a Diameter considerations section, and so far this section has typically relied on translation, it is not clear whether translation really makes sense.  Few deployments appear to make use of this currently.  If RADIUS support is needed, then a "dual stack" approach can be taken -- run both a RADIUS and a Diameter server against a common backend database.  So is there really a need to support RAIDUS attributes within Diameter itself?

---

From: Alan DeKok <[email-masked]>
Date: Mon, 29 Jun 2009 08:36:50 +0200

Bernard Aboba wrote:
> b. Status of RFC 4005bis in DIME.  David Mitton's original proposal for
> enabling translation of *any* RADIUS VSA to Diameter is not currently on
> the (revised) DIME WG charter.  It is not clear that there is interest
> within DIME to pursue this.

  Not being a Diameter person, I would prefer (c), followed by (b).

> c. Need for RADIUS/Diameter translation.  While RADEXT WG documents need
> a Diameter considerations section, and so far this section has typically
> relied on translation, it is not clear whether translation really makes
> sense.  Few deployments appear to make use of this currently.  If RADIUS
> support is needed, then a "dual stack" approach can be taken -- run both
> a RADIUS and a Diameter server against a common backend database.  So is
> there really a need to support RAIDUS attributes within Diameter itself? 

  My discussions with people indicate that the in-use cases for Diameter
and RADIUS are very different, and have little overlap.  This indicates
to me that (c) is the current, and likely best approach.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>