RE: MIB EDU training in Montreal

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

First, I may not be present on Sunday of the IETF meeting.
If I was definitely going to be present, I would commit
to help out.

On the document...
There are many separate isssue that are covered by the document
and include:
 1) a little background on SNMP and management info
 2) guidance for when and why development of MIB documents
    should occur in a WG
 3) guidance on the scope of the content of a MIB module
 4) the process and tools for writting MIB modules and the
    I-Ds that contain them

Here are my suggestions:
1) I'd include just a little more background on SNMP and
   management information. This is needed because of the
   constraints of the protocol have a major affect on the
   design of the MIB module definitions. Also, since there
   are many different approaches to management, each with
   different terminologies, it would be good to define
   the key terms to help reduce confusion.
2) On the "when and why", the key points are:
   a) Until you have deployment experience, it is difficult
      to predict with great accuracy what management
      information is needed to efficiently manage the technology.
      Thus, the WG should try to get early prototype developments
      implemented to provide feedback.
   b) What management information is needed may affect the
      protocol development, and thus, definition of the
      management information must start before the protcol
      work is completed. However, there is no need to
      start definition of management information until
      work on the managed protocol is well under way.
3) On the scope, this goes back to time/cost tradeoffs.
   Monitoring of status and statistics is a must, and
   providing notifications to reduce the latency and
   to increase the scaling are desirable. Actions and
   configuration is typically a large increase in
   time and development. 
4) I hope that we can strongly encourage use of XML and
   a standard XML template for the MIB document.

Hope this helps.

Regards,
/david t. perkins



On Wed, 17 May 2006, Wijnen, Bert (Bert) wrote:
> Thanks for the input from Juergen, Dan and DbH.
> Other pls chime in if possible. 
> I am willing to do an update of the slides that takes input
> into consideration. But I need that input rather sooner than later,
> becuase the 3 weeks prior to the IETF meeting I will be on vacation.
> 
> Bert
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@iu-bremen.de]
> > Sent: Wednesday, May 17, 2006 08:13
> > To: Wijnen, Bert (Bert)
> > Cc: Romascanu, Dan (Dan); mreview@ops.ietf.org
> > Subject: Re: MIB EDU training in Montreal
> > 
> > 
> > On Wed, May 17, 2006 at 06:35:44AM +0200, Wijnen, Bert (Bert) wrote:
> > 
> > > OK, My material that I have is the slides that I presented to
> > > the IETF WG chairs training session at IETF60.
> > 
> > I think this is a very good start.
> > 
> > I believe it is important to add some slides which point out that it
> > is very helpful to have an information model which explains how things
> > are related before writing MIB modules. Perhaps it helps to show some
> > examples to illustrate the point.
> > 
> > A simple to understand example perhaps is the Printer-MIB (RFC 3805)
> > since everybody knows what a printer is. Figure 2 in RFC 3805 defines
> > a conceptual block diagram for a printer and the MIB tables are
> > organized according to this block diagram.
> > 
> > /js
> > 
> > -- 
> > Juergen Schoenwaelder		    International University Bremen
> > <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> > 28725 Bremen, Germany
> > 
>