 an address the query should be 1.1.0. For the example in Figure 15.4, the request/query 1.2 or 1.2.0 will lead to an error as the response. For SNMP MIB query/request a GET command can be used. In the routing table, for the sake of simplicity let us consider that "dest" col- umn is a unique identifier for that table and the elements in "dest" do not repeat and hence can be used as an index for query. A query on the index 1.3.1.5 will get response of "5" while a query on 1.3.2.5 will give the value "3" corresponding to index value of "5." Address (1) Info (2) Routing (3) Status (1) Connection (2) Dest (1) Next (2) Figure 15.4 Tree diagram for switch entity data in a MIB. Information Handling Some of the important fields in scalar and table definition are discussed next. It should be understood that this list does not handle all the fields defined in SMI. The explanation is also supplemented with examples on usage. 1. The fields that appear in object definition of leaf objects are: OBJECT-TYPE: This field is used after the name of the object and encapsulates the remaining structure of the object. In short this tag is for a composite object type definition. SYNTAX: The primary type associated with the definition is specified with SYNTAX. It can take values like INTEGER, BITS, IpAddress, Intger32, and SO on. Example, the SYNTAX of "address" will be IpAddress. MAX-ACCESS: This tag is not to signify the access rights. As the name suggests it gives the maximum access operation that can be per- formed. It can take values read-only, read-write, read-create, nonac- cessible, and accessible-for-notify. Example "Info" in Figure 15.4 will be nonaccessible, while "status" updated dynamically is read-only. STATUS: This tag is used to show the current status of the object. It can take values current, deprecated, and obsolete. Current should always be implemented, deprecated should be implemented but it will become outdated, and obsolete is used when the object is outdated. DESCRIPTION: A description on the object can be given a