RE: [Dime] [AAA-DOCTORS] RADIUS / Diameter compatibilityboilerplate?

["Dave Nelson" <d.b.nelson@comcast.net>]

Hannes Tschofenig writes...
 
> There isn't too much space left in the <255 ID space and hence
> that consideration might not be too relevant in the future.

But it's another reason to restrict it right now -- to conserve such space
for RADIUS applications.  Unless, of course, the issues you've enumerated do
not apply in a specific use case, for example when no new Diameter
application is required and simple RADIUS data types suffice to the use
case.

> I would not restrict the possibility to allocate RADIUS attributes
> (for example from the extended attribute space) in a Diameter 
> document or todo Diameter AVP code allocation in a RADIUS document.

Well, RADIUS Extended Attributes is a different case to consider.  Given the
impedance mismatch between the Diameter AVP data model and the more
restricted RADIUS Extended Attribute data model, there are some serious
design issues.  For example, to share these EAs/APVs the Diameter solution
must be designed to fit within the RADIUS data model restrictions.

> The problem is that a more detailed investigation about this
> subject will take some time.

Correct.

> Do you have that time?

Probably not.  Nor do I have the required Diameter expertise.  That's why I
suggested a stop-gap "fix" in the form "just don't do that".  :-)



--
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/>