Subject: Re: <draft-ietf-disman-remops-mib-03.txt> comments

From: [email-masked]
Date: Wed, 17 Feb 1999 15:03:28 -0500 (EST)

Hello again,

I notice the text of the draft specifically states that agents that
implement the remops MIBs specifically states:

   "An implementation SHOULD NOT retain the SNMP-created entries
    in the pingTable and pingResultsTable across reIPLs (Initial
    Program Loads) of its agent, since management applications need
    to see consistent behavior with respect to the persistence of
    the table entries that they create."

There is similar specifications for the trace route and lookup MIBs.

If the "proactive" periodic-ping and trap-on-failure capability is 
added to the pingMIB, the usefulness of the agent would be diminished 
if the agent's pingMIB configuration must be reset if the agent crashes.
If the pingMIB agent died, the network management staff might have no
clue it needs to reload the (volatile) pingMIB configuration.  Would 
it make sense to have a storageType object in the pingTable that would 
save the configuration across reIPLs?

Changing the subject from the pingMIB to the tracerouteMIB, I believe
objects similar to the ones we've been discussing for the pingMIB
would be useful in the traceroute MIB.  That is, be able to trace the
route to a destination host at periodic intervals, and send a notif-
ication if either  1) one of the intermediate nodes no longer responds,
or  2) if the path to the destination changes.  This capability would 
not only let a network analyst determine that a network connectivity 
problem exists, but automatically determine WHERE the problem is.
Consequently, the network operations staff could almost immediately 
call their ISP and tell them where to look.   If the min/max/avg times
to a network hop could be shoehorned into the tracerouteMIB also, I
believe this would be useful also.  And if possible or practical, 
the icing on the cake would be some kind of threshold so that if the 
traceroute response time to a network hop exceeds one or two standard 
deviations longer than the average, a notification would be generated.

At least, as a network analyst, these are what I wanted -- tools that 
I could "set 'n forget" until they notified me there's a network problem.
And I have recently had customers asking for tools similar to these.
I'm suggesting these ideas because I believe they reflect real needs
of network operators and network analysts, not because I'm personally
attached to them.  But please, those of you more experienced than I, 
please temper these suggestions with your accumulated wisdom and insight.

Thanks again for your thoughtful consideration.

Regards,
--Alan

---

From: Bob Stewart <[email-masked]>
Date: Wed, 17 Feb 1999 16:36:32 -0500

At 03:03 PM 2/17/99 -0500, [email-masked] wrote:
>Would 

StorageType is a kluge and is not sufficient.  It doesn't apply to scalars
and having to put it on every row of every read-write or read-create table
is intrusive.  We've fallen into a bad habit of throwing it at the problem.

Whether or not the entries remain across reboots should be left entirely up
to the implementation and not specified via a row-by-row object.

Perhaps it would be best to separate the configuration objects into a
separate table from the control and result objects.  Then you could say
retention of the configuration table is up to the implementation and
retention of results is not expected but allowed.

>I could "set 'n forget" until they notified me there's a network problem.

Note that being notified via traps is not reliable.  Informs are better.

Set and forget is indeed nice, but you have to be careful of it's
limitations as the path between you and the "setee" gets more complicated
and has more opportunities to block that notification.

This kind of a tool could indeed give you that sort of connectivity testing
and make it pretty reliable with Informs and careful choosing of what's
doing the testing and it's path back for the notification.

But then tools that do a background poll for information you want anyway
might well piggyback functions and they could easily provide the same
connectivity test if they were designed to do so.

Having a ping or traceroute power tool can easily lead to network abuse.
That doesn't mean we shouldn't have the tools but we should put decent
warning labels on them.

	Bob