of the vendor. To solve this issue vendors develop MIB extensions called enter- prise or vendor specific MIB that should satisfy a specific set of requirements. Companies like Cisco and Juniper have an extensive list of enterprise specific MIBs. Some of the RFC documents that fall in this category are: - RFC 1742: MIB for Appletalk (this is for Apple) - RFC1559: DECnet phase IV MIB extensions (this is for Digital Equipment Corporation) Miscellaneous MIBs: This is a general catch all category to capture the MIBs that does not fall in the master groups discussed. Some RFCs that fall in this category include: - RFC 2758: Definitions of managed objects for service level agreements performance monitoring RFC 2513: This document deals with definition of managed objects for controlling the collection and storage of accounting information for con- nection-oriented networks 16.3 MIB-II This section details MIB-II, which is one of the most frequently updated modules in the MIB tree. SNMP is covered under MIB-II and is handled in more detail in subse- quent sections. There was a MIB-I document defined in RFC1156, which is obsolete now and was replaced with MIB-II defined in RFC 1213. This RFC is about man- agement information base for network management of TCP/IP-based internets. So Management Information Base (MIB) it defines the variables to manage TCP/IP protocol stack. Only a limited number of these variables can be modified as most of them are read-only. There are several groups in MIB-II that are detailed in separate RFCs. Some of the groups include TCP (RFC 2012), UDP (RFC 2013), IP (RFC 2011), SNMP (RFC 1907), and SO on. A significant difference between MIB-I and MIB-II, is the presence of CMOT (value 9) in MIB-I that was removed in MIB-II, and the introduction of SNMP (value 11) in 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 doe