[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Rationalizing the RADIUS data model
Barney,
> 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.
Knowing the enforcemant part of the IETF is rather weak, I don't
think you need to worry about this. If the IETF defines a standard
content, and insists upon its use for standard / interoperable usage,
would this be a problem?
> 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 don't have a problem for making it a MUST for standard, interoperable
usage. For non-standard usage, arbatrary format could still be used, IMO.
John
--
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/>