Wes,
I think it's fair enough for different authentication mechanisms to provide structure to names. I don't like the idea of glomming on the actual authentication mechanism name. If you really want to go that route, I would rather a separate field and if we really need to standardize that name, ok. SASL already covers most if not all of this ground.It must be handled in some sense only to make authorization decisions based upon it. Tying it to opaque strings is a good way to go. The trick is tying it carefully such that given an opaque string you know enough about it to make decisions. EG, I'd use a different naming construct for users authenticated via Kerberos than those authenticated via a local password file. (the easiest being append @realm.com for the kerberos users).
I think we'll need to look again at this assumption. AES performance is dramatically better than 3DES, for instance. I would feel differently if we were talking about transporting sflow/netflow records. Today, however, how many people even know how to configure SNMP to use authPriv for some operations and authNoPriv for others? Furthermore, why does the difference need to be expressed as a base level protocol operation?Certainly no one listens to insecure ports anymore. Certainly no one accepts poorly-encrypted (eg, DES) packets anymore. For scalability reasons, there are times you want to use the more expensive encryption routines for the most important data and fall back to the lighter weight algorithms and mechanisms for everything else. Ever noticed how sites that support https *don't* use https for everything? They only protect the data that requires the heavier protection. That way their servers scale a whole lot better.
Just to be clear, I was talking about authorization and not authentication. We already have several different means to handle authentication: Radius, TACACS+, client-side certificates in SSL. Take your pick. The only real question is how these functions tie into XMLConf, and it seems to me that occurs on the implementation back end. I'd be happy to provide ASCII art if you would like.One option is to certainly let each vendor do their own thing with respect to authentication. It makes it harder to securely distribute and configure access policies across multi-vendor deployments, of course.