sages. Of course, management communications are most critical at times when the network is NETWORK MANAGEMENT least reliable. A manager's communications with agents is vital. The use of UDP by SNMP means potentially unreliable transport. SNMP leaves the function of recovery from loss to the manager application. The GET-RESPONSE frame confirms respective GET, GET-NEXT, and SET. A network manager can detect the loss of a request when a response does not return. For instance, it can repeat the request. Traps are another matter. Trap messages are generated by the agent and are not confirmed. If a trap is lost, the agent applications would not be aware that there is a problem, nor would the manager for that matter. Since trap messages signal information that is often of great significance, securing their reliable delivery is very important. Accordingly, SNMPv.2 has pursued an improved mechanism to handle event notifica- tions, namely, traps. For example, the trap primitive has been eliminated. It is replaced by an unsolicited GET-RESPONSE frame that is generated by an agent and directed to the trap manager (UDP port 162). Now event notifications can be unified as responses to virtual requests by event managers. In SNMPv.2, a special Trap MIB has been added to unify event handling, subscription by managers to receive events, and repetitions to improve reliable delivery. In the case of SNMP over TCP/IP, we are looking, at what one might call in-band communications. In other words, we are using the same communications channel for network management as we use for "revenue-bearing" communications. This tends to defeat the purpose of network management. The problem can be somewhat alleviated if the access path to agents is somewhat protected from the entities that they manage. Unlike SNMP, SNMPv.2 delivers an array of messaging options that enable agents to communicate more efficiently with management stations. Furthermore, SNMPv.2's bulk retrieval mechanism lets management stations obtain reports from agents about a range 