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

From: [email-masked]
Date: Sun, 6 Jun 1999 00:54:21 -0400

Hi Alan,

Thanks for the comments.

>I've been reading (and re-reading) <draft-ietf-disman-remops-mib-04.txt>
>as well as re-reading subsequent E-mail about it.  As promised, here are
>my comments about the DISMAN-PING-MIB.

>General comments
>----------------

>I believe the comments on the previous drafts have added a lot of
>constructive feedback about the DISMAN-PING-MIB, and that Ken's
>done a great job of digesting these into a new draft revision.

>I believe the utility of this latest revision of the ping MIB is
>greater than previous versions of the ping MIB.   Thus, I believe
>this latest version will better satisfy a range of real-world
>network management problems than the previous version.  Consequently,
>I believe this latest draft is an improvement over the previous
>version.

>I believe that fact that the pingCtlTable now can be saved in non-
>volatile storage and triggered by the schedule MIB adds utility
>(as does the addition of the min/max/avg and sum-of-squares values.)
>I also believe the specifying DEFVALs and units in the MIB adds pre-
>cision to the specification.

>I were forced to vote today, I could align with the DISMAN-PING-MIB
>as written.  Many of my comments might be considered nits, but here
>goes:

>Page 6, Section 3.1.1
>---------------------

>before>   number of concurrent requests that an
>after>    number of concurrent active requests that an

OK. I added active several places in the draft.

>Page 6, Section 3.1.2
>---------------------

>after>    delete the third paragraph, which discusses the 3rd
>          and 4th indices of the pingCtlTable (these indices
>          don't appear in the table itself)

Yes. I caught this myself a few days ago.

>In the DISMAN-PING-MIB itself
>-----------------------------

>There appears to be no mechanism within the MIB to report (or
>specify) how the ping is implemented (ICMP, UDP echo, etc.)

You probably haven't completely caught up on the email addressing
Randy's comments. Randy brought this up and as a result I have added:

 -- The registration node (point) for ping implementation types

 pingImplementationTypeDomains     OBJECT IDENTIFIER ::= { pingMIB 3 }
 -- Note: Additional implementation types SHOULD be allocated as
 -- required by implementers of the DISMAN-PING-MIB under their
 -- enterprise specific registration point and not beneath
 -- pingImplementationTypeDomains.

 pingIcmpEcho OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION
        "Indicates that an implementation is using the InterNet
        Control Message Protocol (ICMP) 'ECHO' facility."
    ::= { pingImplementationTypeDomains 1 }

 pingUdpEcho OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION
        "Indicates that an implementation is using the udp echo
        port (7)."
    REFERENCE
        "RFC 862, 'Echo Protocol'."
    ::= { pingImplementationTypeDomains 2 }

 pingSnmpQuery OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION
        "Indicates that an implementation is an SNMP query to
        calculate a round trip time."
    ::= { pingImplementationTypeDomains 3 }

 pingTcpConnectionAttempt OBJECT-IDENTITY
    STATUS      current
    DESCRIPTION
        "Indicates that an implementation is attempting to
        connect to a TCP port in order to calculate a round
        trip time."
    ::= { pingImplementationTypeDomains 4 }

>Renaming:

>      pingCtlHostAddressType  --->  pingCtlTargetAddressType
>      pingCtlHostAddress      --->  pingCtlTargetAddress

>might clarify these slightly given the block diagram shown at the
>top of page 4 in the draft.

OK. I also changed:

 pingResultsIpHostAddress       to pingResultsIpTargetAddress
 traceRouteCtlHostAddressType   to traceRouteCtlTargetAddressType
 traceRouteCtlTargetAddress     to traceRouteCtlTargetAddress
 traceRouteResultsIpHostAddress to traceRouteResultsIpTargetAddress

>Because I've been absent from the DISMAN meetings, would someone
>please fill me in on the rationale about why the second index in
>the ping table is an  SnmpAdminString  instead of something either

>1)  easier to implement like an integer; or
>2)  something a bit more meaningful like an IP address (perhaps
>    encoded into an octet string, if needed?

>It's not clear to me why someone would want to name a ping test with
>an 32-octet SnmpAdminString.   32-octets is too long to manipulate
>conveniently with command-line ad-hoc management tools, and seems too
>short to convey meaningful descriptions.  Would someone help me
>understand?

Copying from Rob Frye's minutes of the last meeting:

   "As indicated above, the topic of indexing to support VACM (owner
   indexes) was initially brought up during the discussion of the
   Expression MIB.  The implications of the remote operations MIB
   using owner indices defined as VACM groups was explained better while
   discussing the Remote Operations document.  The problem is that an
   owner (as defined by pingOwnerIndex) can only have one outstanding
   ping at a time to a particular destination (pingHostAddress).
   If an owner is a VACM groupName, then all individuals defined
   in the VACM group together can share a single outstanding ping
   to a particular destination.  The final group decision on this
   matter was that it needed further discussion on the list, but
   that indexing of the form "table.owner.dest.testid" was probably
   the right approach.  The additional "testid" index could be
   specified as either testAndIncrement or RowStatus objects.  The
   reason for "dest" as an index is to limit access to certain tests
   for certain destinations."

Of course right after the meeting I realized that having a target
address as an index introduces a problem when the target address is
a symbolic name. Symbolic addresses can be up to 255 octets. The
DNS MIBs address this by defining a TC that states even though the
255 octets are possible when it appears as an index element then
you have to live with the 128 subid limit.

With 32 octets for OwnerIndex and another for TestName and then 10 or
so for table indexing we are looking at very large indexes. I discussed
this with several folks after the meeting and recommended dropping the
target address as an index element.

DISMAN-LOOKUP-MIB still has it. I am thinking about dropping it as
an index and making it work like the other two MIBs. Does anyone
have an objection to this?

There was a discussing on what the 2nd index should be. I don't remember
exactly the discussing. I prefer an octet string over an arbitrary
integer. If you want to use an integer then use a 2 octet string where
the length is 1 and the integer appears as the 2nd octet.

>The last paragraph being said, would it make sense to add an
>octet-string  pingCtlDescr  object to the pingCtlTable to simply
>document the ping test?  Presumably an octet string not limited
>to 32 octets.

I have no problem with this and will do so unless someone speaks up.
I will also add to the traceroute MIB.

>The following objects are Integer32 objects, when the reasonable
>range of values they would contain would be 0 or positive.  I
>believe an Unsigned32 type would be more semantically correct.
>(There may be other objects I've missed)

>     pingMaxConcurrentRequests

Already changed.

>     pingCtlDataSize
>     pingCtlTimeOut
>     pingCtlProbeCount
>     pingCtlFrequency
>     pingCtlMaxRows
>     pingCtlTrapFilter

Changed.

>Many of the objects have subranges specified, but no obvious
>justification for the specified subrange.  These include:

>     pingMaxConcurrentRequests

Removed per Randy's comment.

>     pingCtlTimeout

Do you really want to be able to specify more than a 60
second timeout?

>     pingCtlProbeCount
>     pingCtlTrapFilter

>Would it make sense to eliminate the subranges?

probeCount has a max of 15 right now. I would be willing to
remove it, but lets consider the negative impacts on remote
and target host performance. Issuing too many pings in
sequence can hurt a stack's performance. I think its
reasonable to have some limit on the number of successive
pings that are issued. 15 is a lot. The test can repeat.

The range on trapFilters goes along with that of the probeCount.

>Would it make sense to add an object to the pingCtlTable to
>specify the IP type-of-service value for the ping packets?

With the ICMP version of ping you don't build the IP packet.
There are probably others ways of selecting this. Before adding
such an object I would like to hear from some folks that would
actually use it. The DISMAN-TRACEROUTE-MIB has one,
traceRouteCtlTos, because in implementing the function you
have to build the IP packet.

>The pingCtlDataFill object has a specified maximum size of 1024
>octets and the pingCtlDataSize object has a specified maximum
>size of 65507 octets.   This implies that in some cases, the data
>fill octet string would need to be repeated in the ping packet.
>Was this intended?

Yes. Text added.

>The function of the pingCtlFrequency object is unclear to me.
>Is it the time between individual pings when retries are required?
>(I suspect not, because of the pingCtlTimeout object)  Or does it
>specify the time period between when  pingCtlProbeCount  pings
>(with pingCtlTimeout between each ping) is done?   Is the
>pingCtlFrequency object the mechanism for doing the periodic
>ping polling?

Your second guess is correct. I will clarify the text.

>I believe that changing the pingCtlTrapGeneration object from an
>INTEGER type to a BITS type would make it more versatile.

Good suggestion. I have made the change as well to the traceroute
MIB. When doing this I added the following statement:

  "The none(0) option can't be selected if any of the
  other BITS options are selected."

Ken