Re: Suggestions for MIB browsers

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "David T. Perkins" <dperkins@dsperkins.com>
> To: <mreview@ops.ietf.org>
> Sent: Thursday, April 08, 2004 10:54 AM
> Subject: Suggestions for MIB browsers
...
> How do you think MIB browsers should display info about objects,
> notifications, variables, etc.

I depends on what it's being used for.  What's good for use in a
shell script isn't necessarily optimal for a human trouble-shooter.
What's good for a management application isn't necessarily
good for a regression test.

> For example, the vast majority of MIB browers show an "OID tree" for
> selecting objects to be used in retrieval and modification operations,
> and show identification of returned variables in dotted OID format
> for GETNEXT walks. Is this format a poor choice? Would a better choice
> be like the following: <module-name>"::"<descriptor> (for example,
> TCP-MIB::tcpConnState)?  Also, last I looked, there was not standard

There are times when this format is useful; there are times when it just
gets in the way.

> way to show the index values of a variable, other than an OID fragement,
> such as tcpConnState.10.23.45.5.22.10.23.45.6.45012. Would a standard
> approach add value, such as
> tcpConnState[10.23.45.5][22][10.23.45.6][45012] or
> tcpConnState[10.23.45.5, 22, 10.23.45.6, 45012]

There are times where it makes sense to convert
string indexes to hex or to their character values.
There are times when binary would make sense.

Another question to consider would be the compatibility of the
format with output from trace/dump tools, and debugging cases.
There's the possibility of "extra" stuff after the indexes, as well as
"missing" (trailing) indexes.  If the tool is used for debugging or
testing, then the ability to generate and display ill-formed indexes
is needed as well.

For example, if it weren't for bugs in some popular agents,
a GetNext query for tcpConnState[localAddr][localPort]
(leaving off the trailing tcpConnRemAddress and tcpConnRemPort
indexes) would be quite useful.

> And, if a MIB browser was prompting for the index values it would
> be in a format like the following (where the "..." is a place
> to enter a value):
>  --------------------------------------------------------------
>  |  tcpConnState[                                             |
>  |     tcpConnLocalAddress {IpAddress},      ..............   |
>  |     tcpConnLocalPort {INTEGER(0..65535)}, ..............   |
>  |     tcpConnRemAddress {IpAddress},        ..............   |
>  |     tcpConnRemPort {INTEGER(0..65535)}]   ..............   |
>  --------------------------------------------------------------

I'd hate to have to figure out how to use this in a command pipeline.  :-)
Seriously, I think OCTET STRING cases are the most difficult, followed
by the question of whether enumeration labels should be used.

Randy