RE: Some thoughts

[Bernard Aboba <aboba@internaut.com>]

> If you look at prepaid for example you will see that that approach taken was
> to use subtypes.

RADIUS [RFC2865] is explicit about the data types that are allowable.
"Sub-types" are not something that can be supported in most RADIUS
implementations without code changes.  So I'd argue that such an
approach is not backward compatible with RADIUS.

> One of the reason for doing so was due to the lack of
> attributes space.  If we were to expand these attributes then we would run
> out of space (maybe not within the two features we are considering now but
> pretty soon.)  Note that using subtypes also increases the size of the
> attribute.

How many attributes do you need?

> Furthermore, you still have a potential issue about the size of the
> attributes.
>
> Nobody addressed the problem I have put forward.  How do you map a (3 octet)
> length Diameter attribute to a (one Octet) length Radius attribute?

You presumably break up the Diameter attribute into multiple RADIUS
attributes which cannot be reordered.


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