n MIB-II. Some of the design criteria that were used in defining MIB-II are: Every variable on fault and configuration management needs to be imple- mented unless it is not applicable to that specific device. For example, a device that does not have a TCP implementation will not require these variables. In most cases it will not contain variables on items like security and accounting. The number of control objects that can set the behavior of a system should be minimal and these objects should not make significant changes in the behav- ior of the system. This is mainly because of security concerns with protocols like initial versions of SNMP. Have a small number of objects that are divided between groups. If a variable can be derived from some other variable, then avoid redundancy by creating a new variable. For example if there is a variable for "packets received" and another variable for "packets lost," then a separate variable is not required for capturing "total packets sent." Only the variables everyone agreed upon were used while others were elimi- nated. This ensures that every variable that is defined will serve an actual business purpose for management data collection. Since the maintenance of the variable will be an issue when the number of variables increases, it was decided to focus more on variables to capture abnormal behavior rather than defining variables that are associated with normal operation. Another major criterion was to ensure that the MIB is not for a specific imple- mentation and is more of a functional MIB. Host resource MIB handles device specific variables. There are multiple sections under MIB-II, like System (1), Interface (2), AT (3), and SO on (see Figure 16.3). Each of these sections has a further subsection attribute to describe it. Let us look into these objects in a little more detail. a. System (1) This group has the following variables under it: sysDescr: This is the system description. sysObjectID: This is the object identifier that points to enterprise spe- cific MIB. sysU