Hal Murray <hmur...@megapathdsl.net>: > I don't know of any reason not to remove it, especially if it is broken. > > I think we need a plan to support SNMP if anybody gets interested. I assume > we will do that with some translation code running as a separate job.
Agreed. I think this can and should be accomplished by plugging together three components: (1) the Mode 6 Python client code I wrote to replace ntpq with. (2) The Python SNMP library (3) The Python socketserver library I don't think this will be difficult - I'd actually be surprised if a basic SNMP daemon made from these pieces runs much over 100 LOC and I'm pretty sure I could write and test it in a day. Data flow: when you access an SNMP resource at the daemon, this gets translated to a Mode 6 query, with the response updating the MIB and posted back to your SNMP client. > I assume we will want traps. We could either do that by polling at some TBD > rate, or by re-implementing a trap feature that the translation job could use. > > Traps are slightly ugly. We probably don't want to process them when they > happen due to opportunities for traps within traps and such. I think it > would work to set a flag and process traps later similar to the way we > process flags from signals. There's an SNMP trap feature. I could speculate further but I don't think there's much point to doing so before we have evidence of some user demand. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel