The “authorize”, etc. sections are increasingly mis-named. After some discussion with Arran, we’ve come up with what seems like a better approach. I’d like to get other peoples feedback on the suggested design. The idea is to get rid of the randomly named “authorize”, “authenticate”, etc. sections. Instead, we will have a standard set of names. These names are predictable, which is good. The new names can be mapped (hand-waving here) to the old methods, so upgrading from 3.0 to 3.1 won’t require major changes to the config. The idea is to use the following naming scheme: recv foo — run this section when receiving a packet “foo”. process foo - run this section to process a packet “foo” send foo - run this section before sending a packet “foo” The mapping between the new types and old is as follows: recv Access-Request == authorize process Access-Request == authenticate (mostly) send Access-Accept == post-auth send Access-Challenge == no matching section send Access-Reject == Post-Auth-Type Reject recv Accounting-Request == preacct process Accounting-Request == accounting send Accounting-Request == no matching section For proxying, we no longer have pre-proxy and post-proxy, instead we have: send Access-Request == pre-proxy recv Access-Accept == post-proxy recv Access-Reject == post-proxy (oops, that’s probably not a good idea) recv Access-Challenge == post-proxy (oops again) send Accounting-Request = pre-proxy recv Accounting-Reply == post-proxy This suggestion isn’t entirely perfect. The “authenticate” section is really a wrapper for each Auth-Type section. We need to find a way to address that. There’s also the Autz-Type section, which exists, but is very weird. Can it just go away? Does anyone use it? There’s also the “session” section. It doesn’t match the above naming scheme. Maybe we need something else? And what about fail and timeouts? e.g. “no reply to proxied request” should probably be: timeout Access-Request ??? Or “no live home server” could be: fail Access-Request? I’m leaning towards that method, instead of the existing Post-Proxy-Type Fail, etc. That method is confusing for end users, and hard to code. e.g. Why is “fail” inside of post-proxy? Is Post-Proxy-Type Fail run for normal proxying, because it’s inside of the post-proxy section? It not, why not? These things are hard to explain. If, instead, we had consistent names, it becomes trivial to know what to do. It becomes trivial to know what the names are, and what each section does. I *believe* we can set up aliases, etc. which will map the new method to the old one. So no one has to butcher their configuration for 3.1. BUT the benefit of using the new naming scheme is legion. The code becomes MUCH simpler, as does the configuration. Comments? Stones? Alan DeKok.