[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Extending RADIUS Attribute Space
> -----Original Message-----
> From: Nelson, David [mailto:firstname.lastname@example.org]
> Sent: Friday, August 22, 2003 12:44 PM
> To: email@example.com
> Subject: RE: Extending RADIUS Attribute Space
> Avi Lior writes...
> > If we want to interoperate with Diameter for example, how would we
> > the fact that the length of a diameter attribute is 3 octets?
> > Is this enough of a justification to allow RADIUS Extended
> > be longer than 1 octet in length?
> Well, I don't know. I think it once again depends on the
> actual attributes and applications under consideration. If
> RADIUS has a well-defined mechanism for achieving
> application-level fragmentation and re-assembly of "oversize"
> attributes, why isn't it sufficient for a RADIUS-Diameter
> gateway function to utilize that fragmentation and
> re-assembly when translating between RADIUS and Diameter?
RADIUS does not have a scheme for doing this. So EAP has a mechanism for
dealing with big attributes but it would be wrong to use EAP messages to
implement something like prepaid or any other application that is not an EAP
I don't think it would be a good idea to create a situation where every
RADIUS application RFC comes up with its own way of dealing with big
> Making the translation simple and straightforward is
> important, but I think that requirement can be met with
> fragmentation and re-assembly.
I don't understand what you mean here. If you meant "requirment can be met
with frametation and re-assembly that exists in RADIUS" then I have answered
>Execution efficiency is another matter, of course...
> -- Dave
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.