Single RADIUS Class attribute supported by HP's Comware - Bug or Enhancement?
Brian Julin
BJulin at clarku.edu
Fri May 30 06:50:09 CEST 2014
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.
More information about the Freeradius-Users
mailing list