The MIB File

The first file needed is the MIB file that defines the MIB module to be implemented.
Strictly speaking, this is not absolutely necessary, as the agent itself does not make any direct use of the MIB definitions. However, it is advisable to start with this for three reasons:

It provides an initial specification for what is to be implemented.
Code development is always easier if you know what you are meant to be writing!
If the new MIB file is read in with the other MIB files,
this lets the applications provided with the suite be used to test the new agent, and report (hopefully meaningful) symbolic OIDs and values, rather than the bare numeric forms.
(N.B: Remember to tell the application to load the new MIB. See the relevant question in the FAQ)
The tool mib2c uses this description to produce the two code files. This is by far the easiest way to develop a new module.

If the intention is to implement a 'standard' MIB module, or a vendor-specific one, then the construction of this file will have already been done for you. If the intention is to provide a totally new, private module, then you will need to write this yourself, in addition to the agent code files.
A description of MIB file format and syntax is beyond the scope of this document, and most books on SNMP management should provide some information on this subject. One book which concentrates on this is

Understanding SNMP MIBS
(Perkins & McGinnis, Prentice Hall, ISBN 0-13-437708-7).

This blatant plug is wholly unrelated to the fact that David Perkins is an active member of the development group, and is regarded as our resident "protocol guru and policeman". (In fact, this book concentrates on MIB files in rather more detail than is appropriate in more general SNMP works). Information on other books covering SNMP and Network Management more generally is available on the SimpleWeb site (among other places). See the FAQ for more details.

Assigned OID numbers

One word of advice - even if you are developing a totally private MIB module, you will still need to position this somewhere within the overall MIB tree. Please do NOT simply choose a location "at random". Any such is likely to have either been assigned to some other organisation, or may be so assigned some time in the future. However much you may regard your project as a totally internal affair, such projects have a tendency to exceed their expected scope, both in terms of lifetime and distribution (not to mention the potential OID clash if you subsequently need to use elements from the legitimate owner's tree).
It is simple and cheap (i.e. free!) to obtain your own official segment of the MIB tree (see http://www.iana.org for an application form), and having done so, you then have complete global authority over it. If you have problems with this, it's worth contacting the development team (email: ucd-snmp-coders@ucd-snmp.ucdavis.edu) for advice. Please do think to the future, and be a good Net citizen by using a legitimately assigned OID as the root of your new MIB.

MIB division

The next point to consider, whether writing by hand or using mib2c, implementing an existing MIB, or writing a new one, is whether and how to divide up the MIB tree. This is a purely internal implementation decision, and will not be visible to management applications querying the agent. A sensible choice of partitioning will result in a simpler, clearer implementation, which should ease both the initial development and subsequent maintenance of the module.
Unfortunately, this choice is one of the module-specific decisions, so must be made on a case-by-case basis. For a simple, self-contained module, it may well be reasonable to implement the module as a single block (examples include the SNMP statistics subtree RFC 1907 or the TCP subtree RFC 2011). More complex and diverse modules (such as the Host Resources MIB - RFC 1514) are more naturally considered as a number of individual sub-modules.
Some guidelines to bear in mind when deciding on this division:

A MIB sub-tree consisting purely of scalar objects with a common OID prefix would normally be handled in the same implementation module;
Separate scalar subtrees would normally be in different implementation modules;
A table can either be handled within the same implementation module as related scalar objects in the same subtree, or in a separate implementation module;
Variables that rely on the same underlying data structure to retrieve their values, should probably be in the same implementation module (and conversely, (though less so) those that don't, shouldn't).

As an initial rule of thumb, a good initial division is likely to be obtained by treating each table and each scalar sub-tree separately. This can be seen in the current agent, where most of the MIB-II modules (RFC 1213) are implemented in separate files (see the files under mibgroup/mibII). Note that many of these combine scalar and table handling in the same file, though they are implemented using separate routines.
This is also the approach used by mib2c, which constructs a single pair of code files, but uses a separate routine for each table (and another for all the scalar variables).
Ultimately, the final consideration (concerning the underlying data) is the most important, and should guide the basic division. For example, the Host Resources Running Software and Running Software Performance modules, while separate in the MIB tree, use the same underlying kernel data and so are implemented together.

MIB name

The final requirement at this stage is to choose a name for each implementation module. This should be reasonably short, meaningful, unique and unlikely to clash with other (existing or future) modules. Mib2c uses the label of the root node of the MIB sub-tree as this name, and this is a reasonable choice in most cases.
Recent changes to the agent code organisation have introduced the idea of module groups of related implementation modules. This is used, for example, to identify the constituent modules of a 'split' MIB (such as the Host Resources MIB), or those relating to a particular organisation (such as UCD).
As with the division, this naming and grouping is a purely internal matter, and is really only visible when configuring and compiling the agent.

So much for the MIB file. The next part considers the C header file.