Removing traps feature

Mark Atwood fallenpegasus at
Thu Sep 8 13:23:01 UTC 2016

Ok.  Thank you Hal and Eric.

Eric, remove the existing traps code from NTPsec.

We will build a snmp subagent later, when we see user need..


On Thu, Sep 8, 2016 at 4:23 AM Eric S. Raymond <esr at> wrote:

> Hal Murray <hmurray at>:
> > 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
> > 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="">Eric S. Raymond</a>
> _______________________________________________
> devel mailing list
> devel at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the devel mailing list