Support more (all) RADIUS attributes

[Bairdo]

will currently throw an error if receive an radius attribute we don't know about.

[samrussell]

this should be driven by use cases - what servers are we peering with? what attributes are they currently sending? the goal isn't 100% compatibility or RFC implementation, but rather usability - what's stopping us from deploying this at e.g. VUW

[Bairdo]

I'm not aware of anyone actually using (Faucet & 802.1X), only interest.

I don't really think someone should have to send a request for a particular RADIUS attribute to be supported before they are able to use it (Faucet & 802.1X), IMO it would be a reason not to (use Faucet & 802.1X).
Implementing 200 isn't proportionally more work than 20.

[samrussell]

There's a couple of things here, one is code rot and another is opportunity cost.

Code that isn't in use is where bugs turn up, so the best way to make sure the app is in good shape is to make sure all of the code is in use. Tests go a long way, but still don't quite substitute for the real thing.

Opportunity cost is the other one - time spent on implementing the full standard is time that could be spent elsewhere today. Faucet currently has "experimental" 802.1x support, how do we get from there to "working but limited" support? What features are missing that would stop someone trialling it on a small scale today - let's get it stable and get some users and build only the features we need for their use case.