RE: Subtypes

[Avi Lior <avi@bridgewatersystems.com>]

First and foremost VSAs are subtypes.  RADIUS servers already have the code
to deal with VSAs.

> I agree.  Since RADIUS only allows attributes of 253 octets, 
> subtypes are inherently limited in their functionality.  

I can show you tons of examples of subtypes that are useful with the
limitation of 253 octets.

Not withstanding those examples.  The sterman draft which is already
deployed uses subtypes are we going to force it to change?  (See 2.2
Digest-Attributes attribute)

I don't agree that it breaks RADIUS dictionaries in the following sense:
Only the Client and  Server that is supporting the functionality needs to
decode further than the top level attribute.

And furthermore, one can be argue that there are  efficiency gains at
intermediaries because intermediaries wouldn't have to parse the extra
sub-attributes that would materialize when we flatten the attributes.
   

> it is necessary to support grouping, the grouping mechanism 
> specified in RFC 2867 can be used.  If the issue is attribute 
> space and the need can be proven, we can talk about 
> expansion.  So far I don't see a requirement to change the 
> RADIUS dictionary.
> 
> On Wed, 26 Nov 2003, Jari Arkko wrote:
> 
> > I would personally prefer that we stick to the simple
> > and existing RADIUS AVP scheme. I am not convinced that
> > there is such a large number of subtypes that it would
> > have a big impact on performance if they were carried in separate 
> > AVPs.
> >
> > --Jari
> 

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