Robert Story <rst...@freesnmp.com> writes: > How about a migration path? Add a warning at startup if rwuser is > specified without a level. i.e. "Warning: no securityLevel > specified for rwuser; defaulting to auth".
I think a warning is a good middle ground. The question you're really asking is: is this default of auth without priv a sensible one or something that is worth breaking running code at some point? Are we willing to cause existing working config systems to break because we believe that encryption is important enough that we're willing to cause them pain? It may be, and I'm not saying otherwise, but it isn't a decision we should take lightly. In the end, which is more important: stability and backward comparability or ensuring people default to "with encryption required". Is it worth *turning off* support for rwuser? Is it better to do that than having two tokens, and switching all docs/etc to the new one and just warning against the old? What's the benefit to deprecation vs obsolesce but still leave it working? As mentioned, this is well documented in the manual page: By default, this will provide access to the full OID tree for authenticated (including encrypted) SNMPv3 requests, using the default context. An alternative minimum security level can be specified using noauth (to allow unauthenticated requests), or priv (to enforce use of encryption). And does derive from a time where encryption was actually impossible for many. We'd certainly make the default different if we wrote that code today. -- Wes Hardaker Please mail all replies to net-snmp-coders@lists.sourceforge.net _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
