Hi,
The way I read the RFC, you either implement Class attribute support completely or not at all in a NAS.
The SHOULD part therefore applies to supporting the Class attribute in the first place, not to implementing it in a broken, non-standard way that breaks the RFC.
No, the text is: "[Class] SHOULD be sent unmodified by the client to the accounting server as part of the Accounting-Request packet if accounting is supported. " Say it gets six Class attributes, and returns one only. -> It did modify the reply, which it SHOULD NOT, but at least it does send a reply. You could even go further and say that even if it does not send any of those Class attributes back, it would still be compliant. Not sending any is "modifying by truncating to the length of 0" :-) So really, the only solid argument to be made would be if sending Class once or more times would make the product crash. So long as it can successfully "absorb" the information, the SHOULD-only in the spec text makes for an argument for the equipment manufacturer why this could be seen as an enhancement, not a bug. I'm not saying that I like or support that kind of attitude. Of course "the right thing" for the box to do would be to return all those attributes. But it's difficult to enforce, and if you are talking to unwilling people on the other end, then that's tough. You can of course re-think if you want to continue buying stuff from that vendor. Just saying. Vote-by-wallet is pretty much the only solid argument that counts in the commercial world.
The issue becomes a bug when Class support has been implemented and it does not work as the standard says it should.
That's the point; there are some things the standard says MUST be done - if you do those not or incorrectly, then it's violating the standard. If the standard merely advises implementations that they SHOULD do something, they are by no means obliged to. They can do other things, arguing that "circumstance" requires them to do so.
The RFC is very clear on the expected quantities for a particular attribute type.
Yes, but it's also very clear in that modifications of the reply for any given input in the attribute are possible, even if frowned upon.
Clearly it cannot be unbounded due to resource constraints, but not offering even a minimum of two Class attibutes cannot be right.
"Unbounded" sounds much more threatening than it is in reality anyway. The maximum length of a RADIUS packet is 4096 bytes; meaning 16 attributes of 253 each are the maximum you need to cater for. Given that the same equipment needs to have large-enough buffers for other length-hungry attributes such as multiple occurences of EAP-Message, I don't think there is much of an argument to be made about unbearable implementation cost. Greetings, Stefan Winter
Nick - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66