RE: Questions on RADIUS Extended attributes

["Nelson, David" <dnelson@enterasys.com>]

Glen Zorn writes...

> > (2) A standard method of encoding "over-size" attributes (those
> > greater than 253 but less than the RADIUS PDU size).
> 
> Didn't we already have that?

Not in a formally specified, generic way.  As a common practice, and for
specific attributes, sure.

> One problem it doesn't solve, though, is that of requiring code
changes in
> servers & clients.  I'm still wondering why we think that 2 bytes are
> really needed for "Extended Type".

One reason is to be very sure that we solve the shortage of standard
attribute IDs for all time.  Let's do this once, and be done with it.
The proposal to define an Extended Type ID of zero as the "continuation"
flag would probably create the need for revised code, even if the
Extended Length field were limited to one octet.

> Also (just to note), the lack of a second Length field means that
> extended attributes can't be packed, unlike VSAs.

Is that a bad thing?  An unreasonable restriction?

> Grouping could be handled w/tags, a la RFC 2868.

Yes, I agree, with the caveat that the tag fields are fixed, and not
optional.  I think you expressed a similar sentiment.



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