Subject: Review of draft-ietf-disman-remops-mib-05.txt

From: Dave Thaler <[email-masked]>
Date: Wed, 23 Jun 1999 13:14:26 -0400 (EDT)

A few questions/comments, and lots of typos...

> ICMP Echo Request packets MUST NOT be used.  Many PC implementations do
> it incorrectly, which, in turn, causes intermediate hops to be invisible
  ^^
What is "it"?  It would be nice to elaborate on this in the text.

Also, it isn't clear to me why ICMP is a MUST NOT for traceroute, 
but is RECOMMENDED for ping.  This seems to be an inconsistency: 
why shouldn't traceroute have the equivalent of pingCtlType?

> milliseconds.  These times can be used as an rough approximation for
s/an/a/

> A local host is the host from which the remote ping, traceroute, or
> Lookup operation is initiated from using an SNMP request.  The remote
s/from using/using/ (from is redundant with "from which")

> command bat files to operate in a similar fashion to the functionality
Maybe ".BAT" or "batch" instead of "bat"?

> The object pingMaxConcurrentRequests enable control of the maximum
s/enable/enables/

> The results of past ping probes can be stored in this table on an per
s/an/a/

> implemented.  For example, an implemented that can't process multiple
s/an implemented/an implementation/

> The results of past traceroute probes can be stored in this table on an
> per traceRouteCtlEntry basis.  This table is initially indexed by
s/an per/a per/
(occurs in 3.2.4 and 3.2.5)

> The object lookupMaxConcurrentRequests enable control of the maximum
s/enable/enables/

>    -- Note: This OID should be reassigned by IANA when the internet-draft
>    --       containing this MIB module is issued as an RFC.
>       ::= { experimental 84 1 }

Are there existing deployments of this MIB in the experimental space?
(If so, then how do you plan to address the module-name collision issue
when moving under mib-2?)

>               ipv4(3),    -- ipv4 address
>               ipv6(4)     -- ipv6 address

This seems like yet another number space for address families, and 
makes me wonder whether the IANA address family numbers would be 
sufficient if dnsName were assigned a number.

>              HostAddressType   OCTETs    ADDRESS TYPE
>                 none(0)         0        not specified
none(0) should be none(1) as specified in the SYNTAX clause
of HostAddressType.

>    PingCtlEntry ::=
>       SEQUENCE {

Why are there traceRouteCtlSourceAddress and traceRouteCtlIfIndex
objects, but not pingCtlSourceAddress and pingCtlIfIndex objects?
I can imagine that they'd be useful for similar reasons.  For
example the RTT seen by pings may depend on which source interface
is used, and whether or not the remote system responds to pings
may depend on the source IP address (e.g. whether it has any route
to it).

>    pingCtlDataSize OBJECT-TYPE
...
>           request is usually an ICMP message encoded
>           into an IP packet.  An IP packet has a maximum size
>           of 65535 octets.  Subtracting the size of the ICMP
>           header (8 octets) and the size of the IP header
>           (20 octets) yields a maximum size of 65507 octets."

Might be helpful to say "Subtracting the size of the ICMP or
UDP header (both 8 octets)..." since both are allowed.

>    pingCtlTimeOut OBJECT-TYPE
...
>           "Specifies the time-out value, in seconds, for an
>           remote ping operation."
s/an remote/a remote/
Similarly under traceRouteResultsCurHopCount and
traceRouteResultsCurProbeCount

>    pingCtlType OBJECT-TYPE
...
>           calculating a ping response time.  The value
>           of this object MUST be selected from
>           pingImplementationTypeDomains."

The last sentence above is confusing when compared with the
earlier comment:
>   -- 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.

If pingCtlType MUST be under pingImplementationTypeDomains, then
what's the point of allocating additional types under enterprise space?

>    pingCtlRowStatus OBJECT-TYPE
...
>           The operational state of an ping operation
s/an ping/a ping/
>           can be determined by examination of it's
s/it's/its/

>    pingResultsTable OBJECT-TYPE
...
>           its associating pingCtlEntry is deleted."
Perhaps replace "associating" with "associated" or "corresponding"?
(occurs several times throughout)

>    pingResultsEntry OBJECT-TYPE
...
>           pingCtlTable in order for an pingResultsEntry to
s/an pingResultsEntry/a pingResultsEntry/
Also in description of pingResultsOperStatus.

>    pingResultsLastGoodProbe OBJECT-TYPE
...
>           "Date and time was the last response was received for a probe."
s/was//

>    pingProbeHistoryTable OBJECT-TYPE
...
>           operation.  Entries in this table is limited by
s/is/are/

>    traceRouteCtlByPassRouteTable OBJECT-TYPE
>          "The purpose of this object is optionally enable
>          bypassing the route table.  If enabled bypass the
s/is optionally/is to optionally/
s/If enabled/If enabled, the remote host will/

>          error is returned.  This option can be
>          used to ping a local host through an
Do you really mean "ping" here in the traceroute MIB?

>    traceRouteCtlPort OBJECT-TYPE
...
>           "Specifies the UDP port to sent the traceroute
s/sent/send/

>    traceRouteCtlSourceAddress OBJECT-TYPE
...
>           "Use the specified an IP address
s/an//
>           other than the IP address of the interface the probe
s/the IP/the primary IP/
(since the interface may be unnumbered, or it may have multiple
addresses)

>    traceRouteCtlRowStatus OBJECT-TYPE
...
>           The operational state of an traceroute operation
>           can be determined by examination of associating
>           traceRouteResultsOperStatus object."
s/associating/the associated/

>    traceRouteResultsTable OBJECT-TYPE
...
>           keeping track of the status of an traceRouteCtlEntry.
s/an traceRouteCtlEntry/a traceRouteCtlEntry/
Similarly in traceRouteResultsEntry description.

>    traceRouteProbeHistoryEntry OBJECT-TYPE
...
>           operation.  Entries in this table is limited by
s/is/are/

>    traceRouteProbeHistoryHopIndex OBJECT-TYPE
...
>          "Indicates which hop in a traceroute path that the probe's
> 
>          results is for."
s/results is/results are/

>    traceRouteHopsHopIndex OBJECT-TYPE
...
>           operation completes.  Care needs to be applied when either
>           a path changes or can't be determined.  The portion of
>           a path that remains the same MUST retain the same
>           traceRouteHopsHopIndex values.  The remaining portion of the
>           path SHOULD be assigned new traceRouteHopsHopIndex values."

The description could be more clear.  For example, if the
path changes from A-B-C-D-E to A-B-X-D-E, then one could interpret
the above to say that A,B,D,E still have hop index values of 1,2,4, and 5,
but X has to be something new like 6, in which case the order of entries
doesn't match the order in the path and you may not be able to tell what
the actual order was.

>    traceRouteHopsIpTargetAddress OBJECT-TYPE
...
>           "This objects reports the IP address associated with the hop."
s/objects/object/

>    traceRouteHopsAverageRtt OBJECT-TYPE
...
>           "The current average traceroute round-trip-time (RTT) for this
> hop."
Indentation

>    traceRouteNotificationsGroup NOTIFICATION-GROUP
...
>          implemenations of this MIB."
s/implemenations/implementations/

>    lookupCtlTable OBJECT-TYPE
...
>           "Defines the Lookup Control Table for provide
s/for provide/for providing/

>    lookupCtlRowStatus OBJECT-TYPE
...
>           can be determined by examination of it's
s/it's/its/

>    lookupResultsTable OBJECT-TYPE
...
>           lookCtlEntry is deleted.
s/lookCtlEntry/lookupCtlEntry/
>           host name return.  The official host name MUST
s/return/returned/

> 5.0  Security Considerations
...
> attempting  to  connect  to  what is suppose to be an unused port can be
s/suppose/supposed/
> ping negatively effect system performance.  In insecure environments  it
s/effect/affect/

-Dave

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 23 Jun 1999 11:12:28 -0700 (PDT)

Hi -

Thanks for the thorough review.  The editor will fix the typos
you identified.  It looks like there are nine technical issues
raised.

I believe issue REMOPS-3 is a non-issue, see below for my comments.
It looks like issue REMOPS-8 results from incomplete application of
a WG decision, and shouldn't require further debate.

In order to simplify follow-ups, I will re-post each of these 
nine technical issues separately.

> From: Dave Thaler <[email-masked]>
> Subject: Review of draft-ietf-disman-remops-mib-05.txt
> To: [email-masked]
> Date: Wed, 23 Jun 1999 13:14:26 -0400 (EDT)
...

> why shouldn't traceroute have the equivalent of pingCtlType?

Issue REMOPS-3:
...
> when moving under mib-2?)

No issue.  Anyone deploying something at the I-D stage does so at their
own risk.  See RFC 2026, clause 2.2, which makes this quite clear.
I-D circulation is NOT publication of a specification; see paragraph
three of that clause in particular.

...
> what's the point of allocating additional types under enterprise space?

I believe ths "MUST" text is incorrect, and that the words of the 
ASN.1 comment should move into the DESCRIPTION text.  This issue
was discussed at the Minneapolis meeting.

...
...

 -----------------------------------------------------------------------
 Randy Presuhn           [email-masked]     http://www.bmc.com
 Voice: +1 408 616-3100  BMC Software, Inc.           965 Stewart Drive
 Fax:   +1 408 616-3101  Sunnyvale, California 94086  USA
 -----------------------------------------------------------------------
 Any relationship between my opinions and BMC's is coincidental.
 -----------------------------------------------------------------------

---

From: [email-masked]
Date: Thu, 24 Jun 1999 04:37:32 -0400

Dave,

Thanks for the comments.  I have taken care of the typos and will address your
other
comments via the issue notes that Randy has sent.

Ken