Subject: RE: Comments on latest AgentX MIB (march 9 1999)

From: "Harrington, David" <[email-masked]>
Date: Tue, 9 Mar 1999 17:16:19 -0500

Hi all,

Would it make sense to send a trap (duplicate-registration-trap) with the 
OIDs or the oid range or whatever? from the standpoint of a manager (er..
entity
with command generator application) it might be useful to know that someone
is trying to register to support an access control MIB or some such OID
range,
that could somehow be used to violate configured privileges.

A trap would certainly be more useful than knowing that somebody tried to
register
some mib that was a duplication.

An alternative would be to store a row into a table with the duplicate
registration
information.

just my $.02
dbh

----------------
#include <std.disclaimer> 
David Harrington,  Spectrum ATM Services Manager Development
[email-masked] Cabletron Systems Inc. 

> -----Original Message-----
> From: Mike Daniele [mailto:[email-masked]]
> Sent: Tuesday, March 09, 1999 4:33 PM
> To: Bob Natale
> Cc: [email-masked]
> Subject: Re: Comments on latest AgentX MIB (march 9 1999)
> 
> 
> Bob Natale wrote:
> 
> Hi Bob,
> 
> 
> > Right...including informing the cognizant humans (actively (say, via
> > an e-mail message), or passively (say, via a log file entry), or
> > indirectly (say, via a alert to some other piece of software).  The
> > added value here is that the particular sub-agent encountering the
> > "problem" (if it is one) can report it in its own context (not used
> > in the technical sense here).
> >
> > >The counter would be there to illuminate to a human what 
> is happening
> > >or has happened on that system.
> >
> > Perhaps the sub-agent response mechanism is a better one for this
> > purpose.
> >
> 
> But I thought we wanted to provide a MIB?  You know, an SNMP MIB? :-)
> 
> >
> > >"Gee,  1.3.6.1.4.1.232.18.2 has had 5000 duplicate registrations.
> > >I wonder what's going on?"
> > >
> > >To me, that seems useful.  Much more useful than
> > >
> > >"Gee, the master agent has had 5000 duplicate registrations.
> > >I wonder what they were, and what's going on?"
> >
> > Agreed...and (ignoring the 5K case for now :-) the sub-agent
> > response mechanism can provide the precise kind of feedback
> > of your useful case.
> >
> > >So I don't agree that a single global counter would be better.
> >
> > Agreed...I did not mean to imply that we should have a single
> > global counter for this event.  The MIB should not deal with
> > it all.
> >
> > >I also don't see why it's expensive to implement.  A master agent
> > >has to detect that a registration is a duplicate, and so presumably
> > >is then holding a reference of some sort to the existing 
> (duplicated)
> > >registration.  Seems pretty simple to bump that guy's counter...
> >
> > Agreed [and, remember, I'm actually personally in favor of even more
> > extensive error monitoring/reporting via the AgentX 
> MIB...but I'm now
> > supporting what I've come to see as a strong consensus for 
> a very lean
> > AgentX MIB]...however, the sub-agent response mechanism provides an
> > equally unproblematic implementation task, with the possibility
> > of added-value extensions.
> >
> 
> But it
> 
>    - requires subagents to do something
>    - requires a human to be logged on to each machine with 
> AgentX installed and
>       manually do something.
>    - requires a human to understand each implementation's 
> logging mechanism
>       (maybe not a big deal)
>    - is not available via SNMP
> 
> However, if you see emerging consensus to remove this object, 
> no argument here.
> 
> >
> > >And if the registration being processed is a duplicate of more than
> > >one existing registration, pick one!   Still seems useful to me.
> >
> > That could work, although it's a bit frayed at the edges it seems.
> >
> 
> Oh I don't know.  Think about how this would work in practice.
> To be a duplicate of > 1 existing registration you have to be 
> registering
> a range, where at least 2 individual subtrees from that range exactly
> match different existing registrations.  (I think.)
> 
> Example, A registers the first 3 columns of row n in some table
> (foo.[1-3].n)
> 
> B registers the last 4 columns for the same row n 
> (foo.[4-7].n).  And now C
> registers all columns for row n, and is a duplicate of both.  
> Or perhaps
> C registered foo.[3-4].n...
> 
> Is it really a problem that this might be logged as a duplicate of
> either A's or B's registration?
> 
> Mike
> 
>