y-to-day operation of telecom networks. The NMS is usually sent a copy of the MIB at configuration time, so that it has a defin- ition of the database for all product types that will be managed, such as workstations, OSS for Telecom Networks file servers, routers and multiplexers. The managed device uses a copy of the MIB to provide the managed object information upon request by a management applica- tion such as an NMS. In the case of the managed device, the firmware is coded so that management information collected from different parts of the product is stored in a database whose tables correspond to the MIB definition. The NMS uses an MIB to identify the nature of a managed object within a class, or category of managed device. This information is used to fetch the contents of the managed object from an instance. An "instance" of a managed object is simply an actual device found in the network or a subset of the functionality of a particular device. The device uses the MIB to present the contents of the managed object upon request. Transactions between the NMS and managed device are based upon a master-slave relationship. The device cannot send unsolicited information to the NMS, unless the information is in the form of a trap. Each SNMP agent provides access to objects that are specific to a particular type of device. To enable the SNMP manager, or management application, to operate intelli- gently on the available device-related data, the manager must know the names and types of objects on the managed device. This is made possible by MIB modules. MIB modules are specified in MIB files which are usually provided with managed devices. For example, RFC1213-MIB, also known as MIB-II, is a MIB module which is typ- ically supported by all SNMP agents on Transmission Control Protocol/Internet Protocol (TCP/IP)-enabled devices or systems. This MIB file contains a description of the object hierarchy on the managed device, in addition to the name, or OID, syn- tax and access privileges for each variable in the MIB. For