(CFO = call for opinions) While testing one of the features of the dtls trap configurations it has become obvious that we made a poor choice in naming the config tokens for configuring certificates. Also, there is a disconnect between the config tokens and the command line transport config options. Currently we have serverCert and clientCert. Unfortunately, snmpd acts as both a client and a server. In the absence of an explicitly configured certificate for a peer, the client connection code in snmplib looks up default (serverCert). This works as expected for a client, but results in the agent expecting the peer to have its own cert!
The new command-line transport config options are 'our_identity' and 'their_identity'. So, what I'd like to do is deprecate the existing tokens and introduce new ones, and use the same token for the command-line transport config. I would like to get this in 5.6.1, because if we are going to change the config tokens, it's better to do it now while they are still a new option and not used by many people. There are, of course, some issues. - backwards compatibility. The current patch I have will, in the absence of the new tokens, fallback and use the old ones. This means existing config files will continue to work. - what should the new tokens be? I don't think the command line tokens are quite right for two reasons. One, they use '_', which is only used by two other snmpd.conf config tokens. I think we should stick with the more common camel case or all lowercase smushed together. We also need to decide between 'identity' and 'cert'. So I suggest either "ourCert/theirCert" or "ourIdentity/theirIdentity". I haven't attached a patch, because I know that this really isn't the type of change that is usually made in a release branch. But I think that the ambiguity of the current tokens and the disconnect with the command line transport tokens is something we should fix sooner rather than later. Most of the code change is for backwards compatibility and a deprecated warning. Simply renaming tokens, obviously, is trivial. Thoughts? Objections? Suggestions? Unfortunately, Wes is on vacation this week. We did discuss this issue next week, and he agreed we needed to fix the current issue, and I'm pretty sure he agreed that sooner is better than later. Robert ------------------------------------------------------------------------------ Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
