RE: Rationalizing the RADIUS data model

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

Barney Wolff writes...

> I would strongly protest any move to make arbitrarily-formatted
vendor-
> specific attributes retroactively prohibited.  There is absolutely no
> justification for any such move.  If you wish to contrain future
> vendor-specific attributes, you MUST define a new Type code for that
> and confine the restriction to users of the new code.
> 
> As for "extended RADIUS in 'non-interoperable' ways" the RFCs have
> always said that a robust implementation SHOULD support the content
> of a VSA as undistinguished octets.
> 
> The suggested VSA content format has never been more than a SHOULD.
> Are you really proposing to make it retroactively a MUST?

I was observing that a single, rationalized, "universal" data model for
all attributes, including VSAs, would have that effect (or some similar
effect).  We could retain the traditional (free-format) VSAs and
introduce a new type code for unified data model VSAs.  But that still
begs the question of when to use the traditional VSA or the rationalized
data model VSA?

-- Dave



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