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

Re: Object identifier and type spaces in a rationalized RADIUS data model



> I have a concrete suggestion.

This proposal would appear to guarantee compatibility with Diameter, by
unifying the attribute number space as well as data types and to some
extent, attribute format.

Some questions:

a. Since the number spaces are unified, is the IANA allocation
process defined in RFC 3588 used?  Does this imply that *all* AVPs
defined in Diameter are automatically also defined in RADIUS? Some
of those attributes may rely on facilities that are not defined
in RADIUS.

b. Since this format optionally supports a Vendor-Specific format, does
this mean that we now have *two* Vendor-Specific Attribute (VSA) spaces
going forward?  Or do we deprecate one of them (presumably the existing
RADIUS attribute 26 space) for some uses (say SDO-specific attributes)?

c. How do we deal with differences in attribute length between RADIUS and
Diameter?  My assumption is that we would concatenate attributes of the
same code and Vendor-ID.  But this might not work correctly for
all attributes - some can be present more than once.

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