RE: the future of SNMP

#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