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

Re: Subtypes

 I'm not sure how long the RADIUS will be? I guess we are somewhere
around Type-100.   It is reasonable to expect future applications that
need handful of attributes.  We wish,  we would NOT like to invent what
AAA supports. What if the market still want to use RADIUS and need
new RADIUS types?

Then, Do we say -

   i) No, we don't support
   ii) Be defensive and the question the need of support in RADIUS.

Unless we are sure that we never run out of the attribute space, I think,
we better introduce the sub-types now.

Folks might be interested to know that IS-IS protocol adopts sub-TLVs
without interoperability problems.


Comments?

-Nagi.




Otherwise
I don't really have any problems if that is decided if people really
think

Bernard Aboba wrote:

> I agree.  Since RADIUS only allows attributes of 253 octets, subtypes are
> inherently limited in their functionality.  If 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/>


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