Tom or somebody else from the MIB project,
could you answer some of these questions?
>Return-Path: <papowell at dickory.sdsu.edu>
>Date: Wed, 5 Mar 1997 19:08:29 PST
>From: Patrick Powell <papowell at dickory.sdsu.edu>
>To: cmanros at cp10.es.xerox.com>Subject: Re: MOD - Comments from Patrick Powell
>>Hi, I have just reviewed some of the older stuff on the MIB.
>Where is the latest stuff?
>>I have looked at some of the stuff, and have a sinking feeling that
>the folks who are doing the MIB stuff have never tried to build/monitor
>a printing system with jobs flowing through/around it, make it portable,
>small, and able to be implemented by the lowest bidder :-)
>>I always try to do the simplest thing, on the grounds that the more
>complex you make it the more things you forget.
>>Why not just define some simple MIB objects that haul text strings
>over and parse the text strings? The overhead of implementing a
>SNMP MIB with all of the complexity that they are putting in will be
>a horrific nightmare. The management of the system will be hideous,
>the database alone will be nasty to design and build, and most of the
>information will be of little use.
>>I also note that many of the folks on the MIB team seem to feel an
>need to have enumerated status types/messages. I keep wondering why -
>most of the time the detailed information about a state is being
>supplied in an additional message. Why not just send a text string
>with the state as the first token? It is trivial to parse this.
>And besides, for display purposes you will need to translate/index
>into a table of strings.
>>Perhaps I am missing the point of a lot of this stuff...