ect 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 capabilities of the agent implementation. The macro OBJECT-TYPE is used to provide the syntax and semantics for defining an object. The macro NOTIFICATION-TYPE is used to describe a notification. A notification is issued as confirmation for an event. Some new terms that have been introduced in RFC 1902 for SNMPv2. These include: BITS: Enumeration of named bits Unsigned32: Unsigned integer MAX-ACCESS: Maximum level of access allowed for an object Counter64: For keeping count UNITS: Textual units of measurements associated with an object AUGMENTS: Gives the object instance identification in a table. It is an alternative to the index clause. IMPLIED: For objects with a variable-length syntax In the hierarchy tree SnmpV2 has many subtrees. Some of these subtrees are: snmpDomains(1): It is for the domains used in transport mapping snmpProxys(2): It is used for giving the proxies used in SNMP transport snmpModules(3): It is used for defining the module identities. Under 