Single RADIUS Class attribute supported by HP's Comware - Bug or Enhancement?

[Nick Lowe]

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 at 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