Re: Problems with notifications

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "David T. Perkins" <dperkins@dsperkins.com>
> To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
> Cc: <mreview@ops.ietf.org>
> Sent: Monday, January 10, 2005 5:38 PM
> Subject: RE: Problems with notifications
...
> Thus, a dummy noAuth/noPriv inform must be sent to

"must" is far too strong a word.  It would be better to
use a get/getnext request.

> discover the engineID (and boots and time). With
> the discovered engineID and the security name from
> the parm table, now table usmUserTable can be accessed.
> But to send an inform, the engineBoots and engineTime
> must be available, and it is retrieved from the
> "remote engineID" table. In summary, to use informs,
> there must be a table that maps between transport
> address and engineID, and another table that is
> indexed by "remote engine ID" that provides boots
> and time. (If one is really paranoid and doesn't
> want to every do noAuth/noPriv engineID, boots, and
> time discovery, then things are a little bit
> trickier.)
...

This is information an SNMP engine needs to keep track
of anyway, if, for example, the engine is being used by
a command generator application, it needs to gather the
same bits of information.  This shouldn't surprise anyone,
since the protocol similarities between sending an inform
and sending a request are deliberate.

Now if SNMPv3 had been built atop something like HIP,
things might be different, but that's not how history played out.

In any case, I don't see why every last bit of internal
implementation state should be exposed as management
information.  An implementation's mechanisms for collecting,
and its policies for caching, EngineIDs are its own business.
This "problem" is no more a problem for applications sending
informs than it is for command generators.

Randy