RE: Questions on RADIUS Extended attributes

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

Nelson, David <> supposedly scribbled:

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

IIRC, it was one of the major reasons for specifying that attributes may not be re-ordered by proxies.  How formal and generic do you want it to be?

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

Just one more reason that it's not that good of an idea.

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

It's a useful feature that is not lost w/my proposal.

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

Yup.


Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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