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