RE: Glen's proposal for Attribute Extension

["Nelson, David" <dnelson@enterasys.com>]

Bernard Aboba writes...

> One of the motivations for this proposal was that it could be
implemented
> with no change to code on existing RADIUS servers, because a single
octet
> extended type was used, making it compatible with the VSA format
suggested
> in RFC 2865.

I think we need to explore the "no code change" assertion.  If we are
limiting the discussion of changes to the RADIUS attribute parser code
that looks at command code and attribute ID, then it's true that no
changes, are required.  However, once the parser determines that its
type 26, a second level of parsing is required.  The vendor OUI needs to
be recognized as well as any vendor types.  Assuming (and this may be a
big assumption) that your data dictionary driven implementation allows
you to enroll new vendor OUIs and associate them with a list of vendor
types, it may be possible to implement this suggestion without any code
changes.

I think that once you add the tag, some code changes likely to be
required.  We are only discussing servers here.  I think we all agree
that NASes and policy-enforcing proxies need to have code changes to
encompass the semantics of the new attributes.

> Given that, why would the attribute type need to be changed?

One additional reason that I would like to see the VSA ID not used is
that RFC 2865 permits free-format VSAs, notwithstanding the
recommendation to re-use the basic TLV format.  We need to retain that
freedom for VSAs.  I would like to curtail that freedom for the Extended
RADIUS Attributes, and mandate use of the basic TLV format, along with
use of basic RADIUS data types.

I think it's clear from the analysis in the Design Guidelines draft that
the data models for VSA and standard attribute spaces have diverged.  I
thought it was a goal of the WG to bring them back together for the
extended attributes.  I don't think it would be very clear that the
format restrictions apply only to VSAs with a particular OUI value. 


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