Spent almost the whole day today on investigations for how to handle creating a Cinemon SNMP Agent (particularly an HMTS-like entity). There are a few major approaches:

* Extend the existing Agent support in TwistedSNMP to cover just that part of the Agent we need (mostly trap configuration). This already handles the basics of setting/getting, but has no knowledge of RowStatus or similar types for creating new rows. It also has no security or structure-limitation code.

* Extend TwistedSNMP's Agent significantly with the ability to use smidump-style descriptions to handle fairly generic setup. Effectively duplicating much of PySNMP 4.x's effort

* Use PySNMP 4.x directly, with a channel from Cinemon to the PySNMP agent communicating the information necessary to make the agent respond properly and/or to communicate to Cinemon what the Manager is suggesting.

* Adapt TwistedSNMP to work with PySNMP 4.x, work out the Agent mechanisms with Ilya.

Obviously the best solution would be to get PySNMP and TwistedSNMP working on the same code-base, but PySNMP 4.x seems a little too unstable at the moment to do that. It's also advertised as being much slower than PySNMP 3.x, and we have to use PySNMP-se 3.5.x just to get barely-acceptable performance. There also doesn't seem to be all that much machinery for handling the Agent-side operations, though that may just be that the examples don't yet reflect the internal capabilities. Have to do a lot of optimisations to make it work, likely.

Using PySNMP over a channel might work, but I'd really prefer an integrated solution. No reason to make the whole system more complex just to get an Agent running IMO.

Just hacking together that part of the Agent operations I need is doable I suppose, but I'd really rather not. Too many little bits and pieces that follow the "turtles all the way down" philosophy of ASN.1/SNMP so that coding individual pieces is going to be heavily redundant.

Which leaves the 'teach TwistedSNMP how to read and expose MIBs with decent hooking/observing mechanism for the agents' path. But that somehow feels wrong too. Surely 90% of that work is just going to duplicate PySNMP 4.x code. I really don't want to duplicate all that work Ilya has done.

So maybe the solution really is to try to integrate with the new version, helping stabilise and optimise it as we did with PySNMP-se. For tonight I'm tired of thinking about it.