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

From: [email-masked]
Date: Tue, 16 Feb 1999 21:31:03 -0500

Bob,

I have been working on a new draft that addresses many of the comments that
where raised. I have taken another look at the Cisco ping MIB and would
like to make the following suggestion to combine the approaches:

o Add the following objects to an pingEntry:
    - pingMinRtt (Unsigned32)
    - pingMaxRtt (Unsigned32)
    - pingAverageRtt (Unsigned32)
    - pingProbeResponses (Counter32)
    - pingSentProbes (Counter32)
    - pingRttSumOfSquares (Unsigned32)
   ProbeResponses, MinRtt, MaxRtt, and RttSumOfSquares are
   incremented when a "good"  response is received to a probe.
   Keeping a sum of the RTTs squared allows calculation of a
   standard deviation.
o Add pingFrequency (Integer32). Basically, elapsed time to wait before
   restarting a ping operation in seconds, not milliseconds.
o Add an object, pingResultsControl, that could be used to determine
  if entries in the pingResultsTable where added.

Questions:

1. Do we want to add a pingRttType object to allow an agent to report its
    implementation method? If we do this, and I'm not sure we should, then
    perhaps we agree on an initial list defined in a TC in a separate MIB
    that IANA could administer.
2.Do we want to add back having a DNS name as a target address in
   both the ping and traceroute MIBs? If yes then I would like to remove
   the lookupTable completely. I prefer this approach and as I said before
   removed it as the result of working group session.
3.Do we want to eliminate the spinLock objects? They are trivial to
   implement. Other MIBs use them. For example the snmpTargetMIB
   (RFC 2273). Given that these MIBs could be used by many managers
   at the same time I think they are worth the cost.
4.Do we need to add DateAndTime objects:
   - Time stamp in an pingResultsEntry when a probe result was added to
      the results table
   - Time stamp in an pingEntry when the last "good" probe response was
      received
5. Change the pingResultsTable to keep the last n probe responses.

Some more specific responses to your last set of comments:

>>As I said I had the capability in a prior version of the MIB(s). I
removed
>>it
>>based on the consensus of the mentioned working group session.

>As you may have noticed on other threads, I don't consider a working group
>show of hands the last word.  We don't work by voting.  We use straw polls
>to get a sense of pervasiveness of opinion.  Then the responsible
>individuals decide what to do.

>In this case I believe the technical guidance of the straw poll went the
>wrong direction and it's perfectly reasonable for our
>application-instrumenting MIBs to support DNS lookups intrinsically, or at
>least to be allowed to do so.

>I've implemented MIBs that way.  If you have DNS services it's neither
>expensive nor complicated and it makes life considerably easier for users
>of the MIB.

I would prefer to put it back in. I would like to hear what some other
folks think first.

>>I think that the MIB(s) should be simple and that the intelligence should
>>be
>>in the management application layer. Each management application could
have
>>its own
>>ownerIndex so the current approach limits one active ping request per
>>management
>>application per destination. Why isn't this enough?

>This is pretty strict enforcement of one concept of how to assign owner
>strings.  I imagine hundreds of operators using the same application and a
>few wizards who know how to set things up.  We have to be very sure our
MIB
>structures can support that.

>>I would hope that the
>>management application was keeping track of what it was doing and would
>>know that it already had an active ping request going before starting
>>another.

>You're taking a very centralized view of "management application."  In my
>mind a management application is anything from a major, coordinated, big,
>expensive gadget run from one place to a script or a program thrown
>together on the spur of the moment to put out the present fire.  In the
>latter case I'd expect to use it with my personal credentials.  Somewhere
>in between I'd expect to use the wizards and elves model of delegating
>limited ability.

>>Perhaps Randy can speak up here. I still don't see how a RowStatus object
>>can be manipulated to synchronize access to simple objects.

>RowStatus controls access to table rows, not scalars.  Did I miss
something
>again?  I understood the spin lock was supposed to be used when working
>with table entries, and that's what I considered redundant.

OK, but I think the spinLock objects should still remain.

>>On systems that support multiple users, use of ping and traceroute isn't
>>shared.

>Huh?  If 14 people all use the same Unix system to do ping and traceroute
>what does it mean to say the use isn't shared?

What I mean is that the results are not shared.

>>As long as the MIB(s) are structured to enable retrieval of the results
of
>>an operation and not along the lines of an availability tool then the
>>current
>>method is sufficient.

>What do you mean by an "availability tool?"

A tool that periodically check to see if some network reason is available.

>>I can add a zero to the range and add text that states use of zero
disables
>>the
>>function. 255 is not arbitrary as a max. It is the maximum TTL value in a
>>probe.

>What does the maximum TTL in a probe have to do with how many times I
retry
>a single failed ping attempt?

TTL has nothing to do with ping. Its a traceroute attribute. In the
traceroute
MIB the object I think we are discussing is traceRouteMaxTtl. The value of
this object determines how long to continue sending probes out with
increasing
TTL values hoping that some router rejects it with a ICMP reply that
enables
the issuer to discover the next part of the path. In the BSD version of
traceroute I think this is the -m option, on NT its the -h option.
Different
implementations have different defaults.

>Are we intentionally limiting this to IP-like protocols?  If maximum TTL
is
>interesting who's to say 255 is the hard limit for all protocols?

I was limiting the MIBs to IP. traceroute is harder to generalize across
different protocols then ping is. I would like to continue limiting the
current
traceroute MIB to being IP specific.

>I have a disturbing sense that the MIB is designed for one very specific
>method and management of tests and that not working from the same model is
>going to lead to major surprises and mis-implementations.

Ken

---

From: Bob Stewart <[email-masked]>
Date: Wed, 17 Feb 1999 11:01:33 -0500

>    - pingRttSumOfSquares (Unsigned32)

Those sound good.

>   restarting a ping operation in seconds, not milliseconds.

This is the trick to make the test repeat unendingly with a gap between tests?

This is an interesting addition that seriously impacts the assumptions
about how many tests a given owner can have, since it makes tests
persistant over a long time.  It sounds like a reasonable idea for ongoing
connectivity checks to vital systems, but now I think you'll really have to
go to an indexing structure where tests are named within the scope of a
given owner, that is, a test specification and result is indexed by owner
and test name.

Of course having added this the world of results gets a lot more complex.
Do I want results kept for every repetition of the test?  For how long?

Again, this is probably a reasonable addition, but it's a major new
capability and needs to be cleanly integrated.

>  if entries in the pingResultsTable where added.

Guess I should have read further ahead.  :-)}

>    that IANA could administer.

What implementation method are we talking about here?

>   removed it as the result of working group session.

I'm strongly in favor of putting it back.  I would allow minimal
implementations to refuse domain names.

Even with built-in lookup I might leave the lookup capability as a separate
MIB, but I wouldn't insist on the separate lookup function.

>   at the same time I think they are worth the cost.

I'd leave them out.

I don't remember if the Target MIB has them for a unique reason.  Perhaps
someone can remind us?

>   - Time stamp in an pingEntry when the last "good" probe response was

Those sound useful.

As usual I'm concerned about DateAndTime on systems that don't know the
date and time.  If we can come up with a common convention for filling in
useful information in that case I'll shut up.

>5. Change the pingResultsTable to keep the last n probe responses.

It should probably have options for keeping all, none, or last n.

>OK, but I think the spinLock objects should still remain.

If the spin locks remain I'd want to see a warning that applications MUST
use them.  If using them is not a MUST they're no good.

	Bob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 17 Feb 1999 17:35:50 +0100

>>>>> Bob Stewart writes:

Bob> As usual I'm concerned about DateAndTime on systems that don't
Bob> know the date and time.  If we can come up with a common
Bob> convention for filling in useful information in that case I'll
Bob> shut up.

I made a proposal in <draft-schoenw-snmpv2-mib-ext-00.txt> in order to
solve this problem once for all MIBs. It was submitted as a "newsnmp"
work item - no idea if we can expect that this will be worked on in a
reasonable time frame.
							Juergen
-- 
Juergen Schoenwaelder  [email-masked] http://www.cs.tu-bs.de/~schoenw
Technical University Braunschweig, Dept. Operating Systems & Computer Networks
Bueltenweg 74/75, 38106 Braunschweig, Germany.        (Tel. +49 531 / 391 3289)