[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: the future of SNMP

Title: Re: the future of SNMP
I guess this as good a place as any to jump into this thread.
#1 For any solution to work effectively, it will need to be supported by both the agent and the manager. Fixing it on one side only is not an option.
#2 It isn't enough to deliver a large blob of data to an NMS; the NMS needs to be able to break it out and process it to display and/or convert the raw data into information to make the blob of data meaningful to an operator. Without that step it is not a useful solution.
#3 using another protocol to transport gathered data requires defining some mappings to coordinate that usage. It is not as simple as defining a mib and then just saying "send it over FTP". What are the possible error conditions that could occur, and how should they be handled? There have been earlier attempts to send file of gathered data, such as RFC2513, and these have not been widely deployed to my knowledge. I would assume that if this design brought great beneift to the SNMP community, the approach would have been extended for use in other scenrios. Do we know why this never gained much acceptance?
#4 As Juergen pointed out, the security mapping between FTP and SNMPv3 will be non-trivial. As a vendor, it is difficult for me to convince a customer they should buy our products because we have SNMPv3-strength security and then suggest they should use a non-secure protocol like FTP to ship bulk data. Even if the file could be transported over SSH or SSL or a VPN or IPSec, no mappings have been proposed about how to do that in a standardized manner, or what rules need to be followed to balance the security between the two. Which security precautions must be follwoed sending bulk responses to a noAuthNoPriv request? which are acceptable for an authPriv response? Can they be mixed into the same buffer?
#5 Even if the file can be transported securely using the correct message security level, a file-based transfer does not have user-specific access control like VACM. I haven't read the mib recently; have mechanisms been defined for coexistence with VACM? 
#6 As Juergen pointed out, adding new protocol additions may require nothing more than a recompile, because many agents and applications use a toolkit and if the toolkit has the extra functionality the agent and manager will get it by default. However, I will point out that #2 still applies. Even if I can add a protocol extension with no work, I still need to modify my code to take advantage of the feature. For an NMS, this will include probing to determine whether the functionality is supported by different agents. If the SNMP stack provides the feature if a developer calls the appropriate API, then the developers need to be educated about the relative benefits of the new solution so they will call the new API rather than just continuing to call the getNext() API for all devices. It is easier to just call the same API for all tables rather than having to test and debug conditional branches of code. I am not convinced that GetBulk has seen wide usage by major NMS vendors yet, for similar reasons.
 -----Original Message-----
From: Wes Hardaker [mailto:hardaker@tislabs.com]
Sent: Friday, February 28, 2003 10:43 AM
To: B. Levin
Cc: Glenn Waters; eos@ops.ietf.org
Subject: Re: the future of SNMP

>>>>> On Fri, 28 Feb 2003 07:00:45 -0800 (PST), "B. Levin" <bryan_levin@yahoo.com> said:

B> the MIB solution that I proposed could be implemented
B> (at the NMS side) even on a 10 yr antique NMS.

I'm confused at why there is an argument over what the NMS could
support.  That is hardly what I think needs to be optimized for in
this case (certainly it's impacted, but I'm much more concerned about
the 10000 agents that it's speaking with than the 1 NMS box).

Wes Hardaker
Network Associates Laboratories