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

From: [email-masked]
Date: Tue, 1 Jun 1999 11:25:26 -0400 (EDT)

Hello,

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

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)

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

Renaming:

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

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

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?

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.

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
     pingCtlDataSize
     pingCtlTimeOut
     pingCtlProbeCount
     pingCtlFrequency
     pingCtlMaxRows
     pingCtlTrapFilter

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

     pingMaxConcurrentRequests
     pingCtlTimeout
     pingCtlProbeCount
     pingCtlTrapFilter

Would it make sense to eliminate the subranges?

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

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?

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?

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

Regards,
--Alan
 
 -----------------------------------------------------------------------------
 Alan Luchuk       SNMP Research, Inc.                 Voice:  +1 423 573 1434
 Software Engineer 3001 Kimberlin Heights Road         FAX:    +1 423 573 9197
 [email-masked]   Knoxville, TN  37920-9716  U.S.A.   http://www.int.snmp.com/
 -----------------------------------------------------------------------------