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

From: [email-masked]
Date: Tue, 9 Feb 1999 22:34:45 -0500

Bob,

>>The consensus was to remove the capability of using a DNS name for either
>>ping
>>or traceroute directly.
 ...
>>The current approach is what I believe we agreed to during
>>the
>>August '98 DISMAN IETF meeting.

>That does sound familiar, now that you mention it.

>Can anyone remember why we didn't allow the more powerful name or number
>form of input?  I've put it in some of my more recent MIBs (and some from
a
>long time ago) and expect to keep doing so.

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. I remember
poising
the question and asking for a show of hands. I believe the thought was that
the
increased complexity wasn't worth the benefit. The lookup table approach
was what
was agreed to. Not that we discussed the structure of the lookup table at
the meeting,
just its existence. I prefer the prior approach but when with the current
approach
based on the consensus that was reached.

>>>Why not use the standard TDomain and TAddress textual conventions?
>>Some folks, especially me, do not like to use OIDs as part of instance
IDs.

>Hmmm.  I'd forgotten that TDomain was an OID.  Yuck.

>I understand somewhat, but it's not clear that's a good enough reason.  So
>I'll go down a different path.

To me its more than enough reason not to use.

>I wondered whether I should push for TDomain and TAddress anyway, but then
>began to wonder whether indexing by host address is the right index.  That
>limits a given owner to one entry per destination.  I can imagine a setup
>where I'd have, say, a short test and a long test preconfigured for given
>destinations and start the one I wanted at a particular time.  With this
>arrangement I can't do that.

Good. The intent of the MIB(s) is to provide a simple mechanism to perform
a
remote ping or traceroute request. Not to provide a network availability
tool directly. Network administrators use ping heavily to insure their
network
components are available. They use tools or have scripts that issue ping
requests periodically and then issue a message or active an alternate route
is something is detected as being unavailable.

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

>So maybe the indexing should be based on an entry number or name within
the
>owner's space, and TDomain and TAddress would then be appropriate for
>values that are simply parameters of the test and not index objects.

>In fact, if you used entry names they could contain the owner name for
>those who want such access control, and you'd have fewer index fields.
But
>I won't mention that.

>>>>   pingSpinLock OBJECT-TYPE
 ...
>>>Why is this necessary?  That's supposed to be covered by RowStatus.
>>
>>I don't think so. A RowStatus object isn't of TestAndIncr syntax. There
is
>>no check for current
>>value. There are simple objects.

>RowStatus was intended to be sufficient and has been considered so in
other
>MIBs.  I don't see why this one is different.

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

>>>This form of indexing requires the use of OwnerIndex to distinguish
>>>different users pinging the same place and precludes an individual user
>>>with only one Owner name from having multiple entries for the same
place.
>>>Is that intentional?
>>Yes.

>Why have such a limit?

On systems that support multiple users, use of ping and traceroute isn't
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.

>>I was imaging that an entry would be created, activated, its
>>results
>>retrieved and then automatically deleted within a fairly small time
period.
>>I also wanted a way for the subagent to remove table entries in the case
>>that
>>the management application never removed the entry itself.

>Hmmm.  As I mentioned earlier, I can imagine wanting entries to be
>persistent, perhaps configured by a more knowledgable user.  If we're
going
>to preclude that I just want to make sure we're doing it on purpose.

Again, the function you are talking about I think belongs in a higher
layer.

>>>>   traceRouteByPassRouteTable OBJECT-TYPE
 ...
>>>Can we assume that all systems can do this?
>
>>No. I think this is implementable if the setsockopt SOL_SOCKET
>>SO_DONTROUTE option is available. The BSD version of traceroute
>>provides this option via the -r parameter. I prefer to leave it in.

>I don't generally design MIBs in terms of Unix calls...

>I'm not suggesting you should leave this out of the MIB.  I'm suggesting
>that a reasonable implementation may not be able to support it.  So in the
>compliance statements I'd say you implement this object if the underlying
>system can support the function.

OK.

>>>>   traceRouteSourceAddress OBJECT-TYPE
 ...
>>>Again can we assume this capability?
>
>>Its implemented by issuing a bind() on the send socket (udp) with the
>>source address. Think this is widely supported. Comments?

>Same comment as on previous similar issue.

OK.

>>>>   traceRouteMaxFailures OBJECT-TYPE
>>>>      SYNTAX      Integer32 (1..255)
>>>>      MAX-ACCESS  read-create
>>>>      STATUS      current
>>>>      DESCRIPTION
>>>>          "The value of this object indicates the maximum number
>>>>          of consecutive timeouts allowed before terminating
>>>>          a remote traceroute request.  A value of 255 (maximum
>>>>          hop count) indicate that the function of terminating
>>>>          a remote traceroute request when a number of successive
>>>>          timeouts are detected is disabled."
>>>>      DEFVAL { 5 }
>>>>      ::= { traceRouteEntry 13 }
>>
>>>Does a value of 1 mean that it fails on the first timeout?  If so, then
>>>that number wasn't allowed before terminating.  It caused termination.
So
>>>it seems the DESCRIPTION needs to be more clear and the number range
from
>>>0..255.  Is 255 not a usable number for some reason?  If it is usable, I
>>>suggest -1 as the indicator not to count timeouts.
>>
>>Its used to terminate an operation after a specific number of consecutive
>>timeouts.
>>A value of 1 would cause an operation to end after 1 timeout. Default is
5,
>>which
>>is reasonsible, I'm missing something here. A value of 1 is a series of 1
>>thus
>>the text is correct. I will change the text but please point out the
>>problem
>>again.

>OK. It's more clear now.  I was thinking in terms of retries.  A 1 here
>means 1 failure/timeout and no retries.

>I'd still consider something other than a high value to indicate no limit.
>Using 0 would work.  The value 255 seems like a fairly arbitrary point to
>define as special (if you don't think in bits).

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.

Regards,

Ken

---

From: Mike Daniele <[email-masked]>
Date: Wed, 10 Feb 1999 11:10:48 -0500

> To me its more than enough reason not to use.

This is a common complaint about TDomain.

For what it's worth,  draft-daniele-iana-address-mib-00.txt includes

--
-- Enumerated integer version of previous registrations.
--
-- This TC can be used to represent transport domains in situations
-- where a syntax of TDomain is unwieldy (for example, when
-- used as an index).
--
-- Currently the enumerated values of this object are identical to the
-- last sub-identifier of the OID registered for the same domain.
--

IanaAddrDomainType ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d"
    STATUS       current
    DESCRIPTION
            "A value that represents a transport domain."
    SYNTAX      INTEGER {
                        other(0),
                        ianaAddrIPv4Domain(1),
                        ianaAddrIPv6Domain(2),
                        ianaAddrUDPIPv4Domain(3),
                        ianaAddrUDPIPv6Domain(4),
                        ianaAddrTCPIPv4Domain(5),
                        ianaAddrTCPIPv6Domain(6),
                        ianaAddrUNIXDomain(7),
                        ianaAddrCLNSDomain(8),
                        ianaAddrCONSDomain(9),
                        ianaAddrDDPDomain(10),
                        ianaAddrIPXDomain(11)
                        }

Regards,
Mike

---

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

At 10:34 PM 2/9/99 -0500, [email-masked] wrote:
>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.

>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

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.

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

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

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?

>an operation and not along the lines of an availability tool then the

What do you mean by an "availability tool?"

>function. 255 is not arbitrary as a max. It is the maximum TTL value in a

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

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

	Bob