[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Rationalizing the RADIUS data model
> I would strongly protest any move to make arbitrarily-formatted vendor-
> specific attributes retroactively prohibited.
I thought the problem was with *standardizing* arbitrarily formatted
vendor-specific attributes, not with allowing them to continue to exist.
> If you wish to constrain future
> vendor-specific attributes, you MUST define a new Type code for that
> and confine the restriction to users of the new code.
Personally, I'm not clear about the benefits of defining yet another
vendor-specific attribute space. I do see the benefits of expanding the
capabilities of the standard space -- though I suppose that leaving the
vendor specific space alone might make it difficult to ensure that the
capabilities of the two spaces were identical. But it might be a
situation in which we strive for "good enough" along that dimension, as
well as Diameter compatibility, and call it a day.
> The suggested VSA content format has never been more than a SHOULD.
> Are you really proposing to make it retroactively a MUST?
That seems unnecessary, to these eyes anyway.
--
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/>