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

From: "Heintz, Lauren" <[email-masked]>
Date: Tue, 9 Mar 1999 13:33:12 -0600

Hi Shawn,

Thanks for your comments.

> -----Original Message-----
> From: Shawn A. Routhier [mailto:[email-masked]]
> Sent: Tuesday, March 09, 1999 10:33 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Comments on latest AgentX MIB (march 9 1999)
> 
> 
> 
> 1) agentxRegDuplicate:
>    I think adding this to the table is not a good idea.
>    By keeping it in a registration entry any information it contains
>    will be lost if the sub agent de-registers that region or
>    if the sub agent goes away.  If we are going to have it as part
>    of a table then it needs to be described more tightly.  What does
>    "duplicated the registration in this entry" mean?  For example what
>    should happen if there are two registrations foo.1 and foo.2 and a
>    sub agent tries to register foo.[1-2]?  Do the counters for both
>    entries get updated?  If so the registration code must check all
>    objects in the range and not stop at the first duplicate detected,
>    this seems wasteful.
> 
>    Note: I would just as soon get rid of the counter completely but
>    think having a single counter rather than one per region is better.

I personally agree with the above note, but I know some others -- they know
who they are :-) -- who asked for this object to be included in the table.
What do you others think?  Is it worth keeping this in the table and making
its use more clear (even though it is expensive to implement), and if not,
keeping it at all?  I say let's axe it all together.

> 2) agentxRegIndex:
>    Is this unique per connection, session or globally?

I think the first sentence of the description...

	"agentxRegIndex uniquely identifies a registration entry."

...implies this is global despite the fact there are two other indices.

-------------------------------------------------------------------------
Lauren Heintz                 BMC Software, Inc. (Formerly PEER Networks) 
Voice: +1 408 616-3169        Silicon Valley Division 
Fax:   +1 408 616-3339        965 Stewart Drive 
Email: [email-masked]  Sunnyvale, California 94086 USA 
-------------------------------------------------------------------------

---

From: Bob Natale <[email-masked]>
Date: Tue, 09 Mar 1999 15:12:33 -0500

>At 3/9/99:02:33 PM, Heintz, Lauren wrote:

Hi Lauren,

>keeping it at all?  I say let's axe it all together.

I think that now that we have the duplicateRegistration error code which
the master agent returns to a sub-agent in this eventuality we no longer
need it in the AgentX MIB.  A sub-agent might utilize the information in
some manner deemed useful in its context...or it might simply accept the
fact that some other entity is managing that range and attempt to register
others or exist if it has no others.  So, we can drop this object from
the AgentX MIB, IMHO.

>...implies this is global despite the fact there are two other indices.

Yes, I agree with that interpretation...if I recall correctly, the
feeling was that the additional indices would facilitate certain
queries that would otherwise require the manage app to do some work
to associate registrations with sessions and/or connections.

Cordially,

BobN
------------ ISO 9001 Registered Quality Supplier -----------
Bob Natale         | ACE*COMM              | 301-721-3000 [v]
Dir, Net Mgmt Prod | 704 Quince Orchard Rd | 301-721-3001 [f]
[email-masked]| Gaithersburg MD 20878 | www.acecomm.com
------------- Free downloads at www.winsnmp.com -------------

---

From: Mike Daniele <[email-masked]>
Date: Tue, 09 Mar 1999 15:25:03 -0500

> others or exist if it has no others.  So, we can drop this object from

Well, I'm not arguing hard to keep it.  but I think we're missing its purpose.

This counter isn't there to help any subagents.  Subagents don't ever need
to read its value or anything, they know if their registration was rejected
and can do whatever they like.

The counter would be there to illuminate to a human what is happening
or has happened on that system.

"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?"

So I don't agree that a single global counter would be better.

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...

And if the registration being processed is a duplicate of more than
one existing registration, pick one!   Still seems useful to me.

Regards,
Mike

---

From: Bob Natale <[email-masked]>
Date: Tue, 09 Mar 1999 16:01:51 -0500

>At 3/9/99:03:25 PM, Mike Daniele wrote:

Hi Mike,

<...>
>Well, I'm not arguing hard to keep it.

Ok...but this is still a useful technical discussion, it seems.

>but I think we're missing its purpose.

Ok...let's analyze that a bit further.

>and can do whatever they like.

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).

>or has happened on that system.

Perhaps the sub-agent response mechanism is a better one for this
purpose.

>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.

>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.

>one existing registration, pick one!   Still seems useful to me.

That could work, although it's a bit frayed at the edges it seems.

Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------

---

From: Mike Daniele <[email-masked]>
Date: Tue, 09 Mar 1999 16:32:41 -0500

Bob Natale wrote:

Hi Bob,

> Perhaps the sub-agent response mechanism is a better one for this

But I thought we wanted to provide a MIB?  You know, an SNMP MIB? :-)

> 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.

> 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

---

From: Bob Natale <[email-masked]>
Date: Tue, 09 Mar 1999 17:17:25 -0500

>At 3/9/99:04:32 PM, Mike Daniele wrote:

Hi Mike,

I've changed the Subject: header (way belatedly, I'm sure!)
to better reflect the content of this thread.

<...>
>But I thought we wanted to provide a MIB?  You know, an SNMP MIB? :-)

You're preaching to the choir...my personal view is that every
AgentX error state should be represented in the MIB...that's
clearly a minority view (perhaps a minority of one) and is not
even on the table...it looks like we're aiming for a truly
minimalist AgentX MIB.  So, continuing in that spirit:

>> ...however, the sub-agent response mechanism provides an

Not in all cases.  In some cases, ignoring a duplicateRegistration
message might be perfectly acceptable to a sub-agent which is willing
to make the assumption as long as something is handling the object(s),
that's good enough.  In other cases, yes, the sub-agent would do
something to record and/or report the error...this may be a good
thing from the perspective of the goal you stated to assist the
human operators.

>   - requires a human to be logged on to each machine with AgentX
> installed and manually do something.

Not necessarily...I gave a brief outline of active, passive, and
indirect responses a sub-agent might take.  It may be rare, indeed,
that a human will need to react to a duplicateRegistration report.
[Whereas that other new error code one we added in this category
for "registrationFailure"...I forget the exact name at the moment...
may be much more important to the human operator and, presumably,
will *require* some sort of sub-agent notification response up
the food chain...however, that's strictly an implementation matter.]

>   - requires a human to understand each implementation's logging
>mechanism (maybe not a big deal)

True...(on both counts)...although one should expect the sub-agent
response mechanisms to be generally familiar ones...however, again,
I guess that's strictly an implementation matter.

>   - is not available via SNMP

True...unless the sub-agent is configured to issue an SNMP
notification for it...or pumps data into some direct method
of generating an SNMP notification (e.g., a log file monitored
by some external notification originator app).

>However, if you see emerging consensus to remove this object,

I think we are seeing such consensus...the rest of you can
monitor and comment on that as well as I can too...so please
feel free to do so.

<...>
<...>
>either A's or B's registration?

No, it's not a major problem...just not as "tidy" as one might wish
...just a nit on my part.

Cordially,

BobN
------------- Free downloads at www.winsnmp.com -------------