 is identified by concatenat- ing 0 to the OBJECT IDENTIFIER of snmpInMsgs. This instance will be repre- sented as 1.3.6.1.2.1.11.8.0. Tables in SNMP are two-dimensional in nature and only the objects in a table, known as columnar objects, can be manipulated by SNMP. Instances of objects in tables are identified by the INDEX clause in SNMPvl where this clause refers to a row in a table. Instances of objects in tables can also be identified using the AUGMENTS clause, which is an addition in SNMPv2. They retrieve values from a table and the length of each column are traversed completely before moving to the next column. To add the value of an object instance to the table, the value is entered in a row using the SetRequest operation and to delete an entry the value is set to invalid using SetRequest operation. A specific set of rules is followed in defining new MIBs. This is required because multiple versions of MIB can coexist. Some of the rules are: Old object types are only deprecated, they are not deleted. The semantics of old object types are not changed between versions. Instead of changing the semantics of an old object, a new object type is formed. Only essential objects are defined to keep SNMP simple. There is enough flexibility to define implementation specific objects. 16.5 SNMPv2 MIB The structure of management information (SMI) for SNMPv2-RFC 1902 describes rules for defining modules, objects, and traps. Some of the definitions articulated in this document are: Fundamentals of EMS, NMS and OSS/BSS The macro MODULE-IDENTITY is used to provide the syntax and seman- tics for defining a module. Information module is an example of a module identified by a MODULE-IDENTITY macro. There are three types of infor- mation modules and it is not mandatory that an information module should have all these three modules. The three types are: - MIB modules that contain information on objects. Compliance statements that provide compliance requirements for - Capability statements that contain information on the capabilit