[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Extending RADIUS Attribute Space

> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com] 
> Sent: Friday, August 22, 2003 12:44 PM
> To: radiusext@ops.ietf.org
> Subject: RE: Extending RADIUS Attribute Space
> Avi Lior writes...
> > If we want to interoperate with Diameter for example, how would we
> address
> > the fact that the length of a diameter attribute is 3 octets?
> > 
> > Is this enough of a justification to allow RADIUS Extended 
> attributes
> to
> > 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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>