Thanks! They do return a single Class attribute so they are already impementing that SHOULD aspect of the RFC, just not properly as multiples must be supported if this feature is implemented. "5.44. Table of Attributes The following table provides a guide to which attributes may be found in which kinds of packets, and in what quantity. Request Accept Reject Challenge # Attribute 0 0+ 0 0 25 Class" Nick On Fri, May 30, 2014 at 12:50 PM, Brian Julin <BJulin@clarku.edu> wrote:
Nick Lowe wrote:
This seems obviously incorrect as, to my mind, there is simply no such thing as 'limited RFC' support. Either a product complies with a standard or it does not.
For client behavior, RFC 2865 says specifically:
"This Attribute is available to be sent by the server to the client in an Access-Accept and SHOULD be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported."
RFC2865 cites RFC2119 for common definitions and RFC 2119 defines SHOULD as:
"SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course."
This puts you in the gray area where vendors can mince words. They can claim that they have "valid reasons" even if they refuse to specify them or the offered reasons are tenuous. Unless there is language buried in RFC2865 that says one MUST not treat all instances of the same attribute equally, their behavior can be interpreted as just ignoring that SHOULD.
For behavior as a proxy or forwarder the term MUST is used so there is less wiggle room there.
Their products are documented as complying to RFC 2865 and RFC 2866, so I cannot see how this is in any way whatsoever an enhancement request.
RFC 2865 qualifies its citation of RFC 2119 thusly:
'An implementation is not compliant if it fails to satisfy one or more of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the must and must not requirements but not all the should or should not requirements for its protocols is said to be "conditionally compliant".'
Vendors rarely claim compliance/conformance using those exact words. Often they just list RFCs in a "Features" list or say the product "supports" the RFC, which are meaningless statements, really.
There are a lot of non-compliant RADIUS implementations out there, sold by major vendors, with glaring bugs that never get fixed. Large contracts tend to be the major driver for code improvements, so the small customer is mostly left to subsist on the table scraps left over after the large RFPs have had their needs serviced.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html