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