Re: the future of SNMP
"B. Levin" <[email protected]> Mon, 3 Mar 2003 09:10:37 -0800 (PST)
| Newsgroups | gmane.ietf.eos |
|---|---|
| Message-ID | <[email protected]> |
--- Juergen Schoenwaelder <[email protected]> wrote: > > [I did not want to respond but I just have to since > I see lots of > IMHO stupid arguments.] please, no need for that. agreeing to disagree is fine, but please don't call people names. > Fact #1: An AgentX subagent will not work. without seeing the implementation, that's a pretty sweeping statement. saying 'fact' does not necessarily make it so. yes, no _direct_ call mechanism via var_mumble will work with the loosely coupled agent-x. for .so-style subagents (in net-snmp, for example) this will work; but for agent-x, an indirect call will have to be used. so what? fetching data from the agent to itself is far far better than fetching data from the remote NMS to agent. taking the network out of the loop is a big gain, especially for lossy networks, unreliable (at times) networks or times when the NMS (or some router in between) is down. > Fact #2: Initiating the bulk transfer is not the > same as using it in > an application. Having some encoded data in > a file is IMHO > far away from using the data in a > management application. my assumption (maybe I'm wrong here) is that the hard work is getting the data across in a parse-friendly (ascii CSV) format. CSV files are the most importable format I know of. most serious NMS shops (that would do billing/accounting, for example; one of the main motivations for a bulk xfer arrangement) do their billing based on some database, perhaps even an sql database. the raw mib data, as gotton via standard snmp, is one such source of data import. CSV files would be another. its not rocket science (nor would it even require C programming) to import a CSV file into a database so that a billing app can chomp on it. > Fact #3: Security mappings between SNMP and FTP will > be non-trivial. this doesn't seem to have stopped many vendors. at my previous company, I was told that there was a bunch of vendors that are using the 'push' model (storing usernames/passwords for remote file login/xfer) on their agent. and while this was seen as a security issue; and while I basically agree with that, my MIB does provide a 'pull' model which solves that concern. there was the issue raised of which username or permission-set the file transfer job would run as. ie, once the snmp SET occurs and the data collection begins, which 'account' does it run under (at the agent side)? this is a detail that the last published MIB didn't deal with but after some email with someone more in-the-know about security, we put some patches together that addresses this better. perhaps not perfectly, but better. I'll try to revise the current MIB to reflect that. but I believe the security issues can be folded into the implementation after the initial proof-of-concept is done. I'm more interested in seeing the speed gain, at first, and then adding refinements to the mib as a 2nd pass. I don't think the security implications are a show-stopper and nothing really major has to be done to the mib to satisfy the security-minded. > Fact #4: Deploying new protocol operations (if done > right) boils down > in most cases to the cost of getting an > update of the SNMP > engine and recompiling the agent. oh really? some mgmt code that does an 'snmp_get(varbind, varbind, varbind)' will Just Plain Work by linking to libsnmp_new instead of libsnmp? somehow I just don't believe that. > Fact #5: A 10 year old closed-source > no-compilers-exist unix box will > probably not do much more than some basic > RFC 1213 stuff and > we probably do not need protocol extensions > for that. > its my assertion that to setup a bulk file transfer using my mib would require only the most basic varbind creation. a few SET pdu's is all that it will take in order to get a csv.txt file to be placed on the NMS. it might take all of 5 shell lines, calling net-snmp's snmpset utility (for example) to define a transfer profile. then when its time to request a snapshot/file-transfer, a single snmp set with a handful of varbinds is all that's needed. that's hardly a complex operation and I'm willing to bet that 10yr old NMS would easily be able to handle that. __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - forms, calculators, tips, more http://taxes.yahoo.com/