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

From: Randy Presuhn <[email-masked]>
Date: Tue, 2 Feb 1999 11:00:05 -0800 (PST)

Hi - 

|From [email-masked] Wed Jan 27 09:39:37 PST 1999
|Date: Wed, 27 Jan 1999 12:39:07 -0500
|To: Randy Presuhn <[email-masked]>, [email-masked]
|From: Bob Stewart <[email-masked]>
|Subject: Re:  <draft-ietf-disman-remops-mib-03.txt> comments
...
|>   pingOwnerIndex OBJECT-TYPE
|
|Mmmpphhhlllggggg.

Care to elaborate?

...
|>   pingResultsResponse OBJECT-TYPE
|>      SYNTAX      Integer32
|>      MAX-ACCESS  read-only
|>      STATUS      current
|>      DESCRIPTION
|>          "The result of the ping operation made by a remote host
|>              >=0  Round-trip response time in milliseconds.
|>              -1   Internal error.
|>              -2   ICMP echo request timed out.
|>              -3   Unknown destination address.
|>              -4   No route to host.
|>              -5   Interface inactive to host.
|>              -6   Failed to resolve host name.
|>              -7   pingMaxConcurrentRequests limit reached."
|>      ::= { pingResultsEntry 2 }
|
|Hmmm.  "Failed to resolve host name."  Part of my suggestion is here.
|Vestigial, but here.
|
|This format for results sort of gives me heartburn.  I'd have a nice, neat
|enumeration for the completion status and a separate object for the
|response time, and perhaps additional objects for more detail.  The Cisco
|Ping MIB, which has been in use for some time, has messages sent, messages
|received, and minimum, average, and maximum round trip time.
|
|As long as we're doing this we might as well do it up right.

I agree that it is useful to know the min and max.

...
|>   traceRouteByPassRouteTable OBJECT-TYPE
|>      SYNTAX TruthValue
|>      MAX-ACCESS  read-create
|>      STATUS      current
|>      DESCRIPTION
|>         "The purpose of this object is optionally enable
|>         bypassing the route table.  If enabled bypass the
|>         normal routing tables and send directly to a
|>         host on an attached network.  If the host
|>         is not on a directly-attached network, an
|>         error is returned.  This option can be
|>         used to ping a local host through an
|>         interface that has no route through it
|>         (e.g., after the interface was dropped by
|>         routed)."
|>      DEFVAL { false }
|>      ::= { traceRouteEntry 3 }
|
|Can we assume that all systems can do this?

We should probably put words in the conformance section to allow systems
that only support "false" for this object.

|I like using UNITS, and these MIBs aren't consistent about it.

Agreed.

|>   traceRouteTos OBJECT-TYPE
|>      SYNTAX      Integer32 (0..255)
|>      MAX-ACCESS  read-create
|>      STATUS      current
|>      DESCRIPTION
|>          "Specifies the value to store in the TOS OCTET in
|>          the IP probe packet that is transmitted as the
|>          traceroute request.  The value must be a decimal
|>          integer in the range 0 to 255.  This option can be
|>          used to see if different types-of-service result
|>          in different paths.  Not all values of TOS are
|>          legal or meaningful.  TOS is often not supported
|>          by IP implementations.  Useful values are probably
|>          '16' (low delay) and '8' (high throughput)."
|>      DEFVAL { 0 }
|>      ::= { traceRouteEntry 9 }
|
|This needs a REFERENCE for the defined values.

I assume would correspond to the traffic class field from RFC 2460.

|>   traceRouteSourceAddress OBJECT-TYPE
|>      SYNTAX      HostAddress
|>      MAX-ACCESS  read-create
|>      STATUS      current
|>      DESCRIPTION
|>          "Use the specified IP address
|>          (which must be given as an IP number, not a hostname)
|>          as the source address in outgoing probe packets. On
|>          hosts with more than one IP address, this option can
|>          be used to force the source address to be something
|>          other than the IP address of the interface the probe
|>          packet is sent on. If the IP address is not one of this
|>          machine's interface addresses, an error is returned and
|>          nothing is sent."
|>      DEFVAL { ''H }
|>      ::= { traceRouteEntry 10 }
|
|Again can we assume this capability?

probably not; I suggest handling it in the conformance section

|>   traceRouteMiscOptions OBJECT-TYPE
|>      SYNTAX      Utf8String (SIZE(0..64))
|>      MAX-ACCESS  read-create
|>      STATUS      current
|>      DESCRIPTION
|>          "Enables an application to specify implementation
|>          dependent options."
|>      DEFVAL { ''H }
|>      ::= { traceRouteEntry 12 }
|
|Eeeeeeeek.  Ummmm.  Maybe.  If we've got this Utf8String to use like this,
|why are we using SnmpAdminString for comments in other MIBs?

The Utf8String from sysappl predates the SnmpAdminString TC.  This
should be SnmpAdminString here.

...
|>   lookupEntry OBJECT-TYPE
|>      SYNTAX      LookupEntry
|>      MAX-ACCESS  not-accessible
|>      STATUS      current
|>      DESCRIPTION
|>          "Defines an entry in the lookupTable."
|>      INDEX {
|>               lookupOwnerIndex
|>            }
|>      ::= { lookupTable 1 }
|
|I tried to be quiet about owner indexing, but now it's gone to the extreme.
| It's not only being used for security purposes but to keep a given owner
|from having more than one outstanding request.  I'm not convinced that's
|good.  Multiple users may share the same named view and legitimately have
|multiple requests at the same time.

I agree that we probably need an additional index here.

|We're using this technique despite not taking the time to understand it and
|write it down as a common reference.

If someone's willing to take the time to write that framework document,
I won't stand in their way!

...
|Functionally the MIBs look pretty good.  Most of what I had to say is for
|simplification or reasonable flexibility and power and for polish.
...

So we'll need at least one more draft before we kick off a last call
on this.

 -----------------------------------------------------------------------
 Randy Presuhn           Email: [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
 -----------------------------------------------------------------------
 In accordance with the BMC Communications Systems Use and Security
 Policy, I explicitly state that although my affiliation with BMC may be
 apparent, implied, or provided, my opinions are not necessarily those
 of BMC Software and that all external representations on behalf of
 BMC must first be cleared with a member of "the top management team."
 -----------------------------------------------------------------------

---

From: Bob Stewart <[email-masked]>
Date: Wed, 03 Feb 1999 12:01:27 -0500

>Care to elaborate?

That was me being strangled so I wouldn't rant about owner indexing.

>I agree that it is useful to know the min and max.

I initiially wondered why have sent and received, but the difference is an
indication of lost messages, or perhaps duplicates.  Those could cancel or
be ambiguous unless the ping process is numbering messages and keeping
track of no responses and duplicate responses.  There's something to be
said for specifying operation to that level of detail.

>I won't stand in their way!

I didn't figure you would.  If we only had time to find someone with time...

>So we'll need at least one more draft before we kick off a last call

Seems to be a lot of that going around.  :-)}

	Bob