RE: http://www.ietf.org/internet-drafts/draft-mitton-diameter-radius-vsas-00.txt

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Alan DeKok <> supposedly scribbled:

> "Glen Zorn (gwz)" <gwz@cisco.com> wrote:
>>> People try to send
>>> 100's of long string attributes via RADIUS, and it doesn't work.
>> 
>> I think that the standard answer would be that that is perfectly
>> acceptable RADIUS behavior, and to use Diameter;
> 
>   In existing deployments, where clients don't support Diameter?

That's the point: if you have an application that RADIUS can't support, you must transition to Diameter.

> 
>   Are there *any* diameter clients built into equipment from major
> networking vendors?  I don't recall any off-hand. 

Yes.

> 
>>  what we were talking about was a bug that makes transitioning
>> gracefully from RADIUS to Diameter extremely painful, if not
>> impossible.
> 
>   I agree.  My point was that RADIUS already has this issue,
> independent of Diameter.  

I understand that.

> If we solve the issue for RADIUS, then we
> should also get better Diameter interoperability for free.  

How can you solve it w/o either changing the RADIUS packet format or transport?

> 
>   Alan DeKok.

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