Return to rfc1157.txt CVS log

Up to [CSRG BSD Unix] / 43BSDReno / contrib / isode-beta / doc / rfcs

Annotation of 43BSDReno/contrib/isode-beta/doc/rfcs/rfc1157.txt, revision 1.1

1.1     ! root        1: 
        !             2: 
        !             3: 
        !             4: 
        !             5: 
        !             6: 
        !             7: Network Working Group                                            J. Case
        !             8: Request for Comments:  1157                                SNMP Research
        !             9: Obsoletes:  RFC 1098                                            M. Fedor
        !            10:                                        Performance Systems International
        !            11:                                                           M. Schoffstall
        !            12:                                        Performance Systems International
        !            13:                                                                 J. Davin
        !            14:                                      MIT Laboratory for Computer Science
        !            15:                                                                 May 1990
        !            16: 
        !            17: 
        !            18:               A Simple Network Management Protocol (SNMP)
        !            19: 
        !            20:                            Table of Contents
        !            21: 
        !            22:    1. Status of this Memo ...................................    2
        !            23:    2. Introduction ..........................................    2
        !            24:    3. The SNMP Architecture .................................    5
        !            25:    3.1 Goals of the Architecture ............................    5
        !            26:    3.2 Elements of the Architecture .........................    5
        !            27:    3.2.1 Scope of Management Information ....................    6
        !            28:    3.2.2 Representation of Management Information ...........    6
        !            29:    3.2.3 Operations Supported on Management Information .....    7
        !            30:    3.2.4 Form and Meaning of Protocol Exchanges .............    8
        !            31:    3.2.5 Definition of Administrative Relationships .........    8
        !            32:    3.2.6 Form and Meaning of References to Managed Objects ..   12
        !            33:    3.2.6.1 Resolution of Ambiguous MIB References ...........   12
        !            34:    3.2.6.2 Resolution of References across MIB Versions......   12
        !            35:    3.2.6.3 Identification of Object Instances ...............   12
        !            36:    3.2.6.3.1 ifTable Object Type Names ......................   13
        !            37:    3.2.6.3.2 atTable Object Type Names ......................   13
        !            38:    3.2.6.3.3 ipAddrTable Object Type Names ..................   14
        !            39:    3.2.6.3.4 ipRoutingTable Object Type Names ...............   14
        !            40:    3.2.6.3.5 tcpConnTable Object Type Names .................   14
        !            41:    3.2.6.3.6 egpNeighTable Object Type Names ................   15
        !            42:    4. Protocol Specification ................................   16
        !            43:    4.1 Elements of Procedure ................................   17
        !            44:    4.1.1 Common Constructs ..................................   19
        !            45:    4.1.2 The GetRequest-PDU .................................   20
        !            46:    4.1.3 The GetNextRequest-PDU .............................   21
        !            47:    4.1.3.1 Example of Table Traversal .......................   23
        !            48:    4.1.4 The GetResponse-PDU ................................   24
        !            49:    4.1.5 The SetRequest-PDU .................................   25
        !            50:    4.1.6 The Trap-PDU .......................................   27
        !            51:    4.1.6.1 The coldStart Trap ...............................   28
        !            52:    4.1.6.2 The warmStart Trap ...............................   28
        !            53:    4.1.6.3 The linkDown Trap ................................   28
        !            54:    4.1.6.4 The linkUp Trap ..................................   28
        !            55: 
        !            56: 
        !            57: 
        !            58: Case, Fedor, Schoffstall, & Davin                               [Page 1]
        !            59: 
        !            60: RFC 1157                          SNMP                          May 1990
        !            61: 
        !            62: 
        !            63:    4.1.6.5 The authenticationFailure Trap ...................   28
        !            64:    4.1.6.6 The egpNeighborLoss Trap .........................   28
        !            65:    4.1.6.7 The enterpriseSpecific Trap ......................   29
        !            66:    5. Definitions ...........................................   30
        !            67:    6. Acknowledgements ......................................   33
        !            68:    7. References ............................................   34
        !            69:    8. Security Considerations................................   35
        !            70:    9. Authors' Addresses.....................................   35
        !            71: 
        !            72: 1.  Status of this Memo
        !            73: 
        !            74:    This RFC is a re-release of RFC 1098, with a changed "Status of this
        !            75:    Memo" section plus a few minor typographical corrections.  This memo
        !            76:    defines a simple protocol by which management information for a
        !            77:    network element may be inspected or altered by logically remote
        !            78:    users.  In particular, together with its companion memos which
        !            79:    describe the structure of management information along with the
        !            80:    management information base, these documents provide a simple,
        !            81:    workable architecture and system for managing TCP/IP-based internets
        !            82:    and in particular the Internet.
        !            83: 
        !            84:    The Internet Activities Board recommends that all IP and TCP
        !            85:    implementations be network manageable.  This implies implementation
        !            86:    of the Internet MIB (RFC-1156) and at least one of the two
        !            87:    recommended management protocols SNMP (RFC-1157) or CMOT (RFC-1095).
        !            88:    It should be noted that, at this time, SNMP is a full Internet
        !            89:    standard and CMOT is a draft standard.  See also the Host and Gateway
        !            90:    Requirements RFCs for more specific information on the applicability
        !            91:    of this standard.
        !            92: 
        !            93:    Please refer to the latest edition of the "IAB Official Protocol
        !            94:    Standards" RFC for current information on the state and status of
        !            95:    standard Internet protocols.
        !            96: 
        !            97:    Distribution of this memo is unlimited.
        !            98: 
        !            99: 2.  Introduction
        !           100: 
        !           101:    As reported in RFC 1052, IAB Recommendations for the Development of
        !           102:    Internet Network Management Standards [1], a two-prong strategy for
        !           103:    network management of TCP/IP-based internets was undertaken.  In the
        !           104:    short-term, the Simple Network Management Protocol (SNMP) was to be
        !           105:    used to manage nodes in the Internet community.  In the long-term,
        !           106:    the use of the OSI network management framework was to be examined.
        !           107:    Two documents were produced to define the management information: RFC
        !           108:    1065, which defined the Structure of Management Information (SMI)
        !           109:    [2], and RFC 1066, which defined the Management Information Base
        !           110:    (MIB) [3].  Both of these documents were designed so as to be
        !           111: 
        !           112: 
        !           113: 
        !           114: Case, Fedor, Schoffstall, & Davin                               [Page 2]
        !           115: 
        !           116: RFC 1157                          SNMP                          May 1990
        !           117: 
        !           118: 
        !           119:    compatible with both the SNMP and the OSI network management
        !           120:    framework.
        !           121: 
        !           122:    This strategy was quite successful in the short-term: Internet-based
        !           123:    network management technology was fielded, by both the research and
        !           124:    commercial communities, within a few months.  As a result of this,
        !           125:    portions of the Internet community became network manageable in a
        !           126:    timely fashion.
        !           127: 
        !           128:    As reported in RFC 1109, Report of the Second Ad Hoc Network
        !           129:    Management Review Group [4], the requirements of the SNMP and the OSI
        !           130:    network management frameworks were more different than anticipated.
        !           131:    As such, the requirement for compatibility between the SMI/MIB and
        !           132:    both frameworks was suspended.  This action permitted the operational
        !           133:    network management framework, the SNMP, to respond to new operational
        !           134:    needs in the Internet community by producing documents defining new
        !           135:    MIB items.
        !           136: 
        !           137:    The IAB has designated the SNMP, SMI, and the initial Internet MIB to
        !           138:    be full "Standard Protocols" with "Recommended" status.  By this
        !           139:    action, the IAB recommends that all IP and TCP implementations be
        !           140:    network manageable and that the implementations that are network
        !           141:    manageable are expected to adopt and implement the SMI, MIB, and
        !           142:    SNMP.
        !           143: 
        !           144:    As such, the current network management framework for TCP/IP- based
        !           145:    internets consists of:  Structure and Identification of Management
        !           146:    Information for TCP/IP-based Internets, which describes how managed
        !           147:    objects contained in the MIB are defined as set forth in RFC 1155
        !           148:    [5]; Management Information Base for Network Management of TCP/IP-
        !           149:    based Internets, which describes the managed objects contained in the
        !           150:    MIB as set forth in RFC 1156 [6]; and, the Simple Network Management
        !           151:    Protocol, which defines the protocol used to manage these objects, as
        !           152:    set forth in this memo.
        !           153: 
        !           154:    As reported in RFC 1052, IAB Recommendations for the Development of
        !           155:    Internet Network Management Standards [1], the Internet Activities
        !           156:    Board has directed the Internet Engineering Task Force (IETF) to
        !           157:    create two new working groups in the area of network management.  One
        !           158:    group was charged with the further specification and definition of
        !           159:    elements to be included in the Management Information Base (MIB).
        !           160:    The other was charged with defining the modifications to the Simple
        !           161:    Network Management Protocol (SNMP) to accommodate the short-term
        !           162:    needs of the network vendor and operations communities, and to align
        !           163:    with the output of the MIB working group.
        !           164: 
        !           165:    The MIB working group produced two memos, one which defines a
        !           166:    Structure for Management Information (SMI) [2] for use by the managed
        !           167: 
        !           168: 
        !           169: 
        !           170: Case, Fedor, Schoffstall, & Davin                               [Page 3]
        !           171: 
        !           172: RFC 1157                          SNMP                          May 1990
        !           173: 
        !           174: 
        !           175:    objects contained in the MIB.  A second memo [3] defines the list of
        !           176:    managed objects.
        !           177: 
        !           178:    The output of the SNMP Extensions working group is this memo, which
        !           179:    incorporates changes to the initial SNMP definition [7] required to
        !           180:    attain alignment with the output of the MIB working group.  The
        !           181:    changes should be minimal in order to be consistent with the IAB's
        !           182:    directive that the working groups be "extremely sensitive to the need
        !           183:    to keep the SNMP simple."  Although considerable care and debate has
        !           184:    gone into the changes to the SNMP which are reflected in this memo,
        !           185:    the resulting protocol is not backwardly-compatible with its
        !           186:    predecessor, the Simple Gateway Monitoring Protocol (SGMP) [8].
        !           187:    Although the syntax of the protocol has been altered, the original
        !           188:    philosophy, design decisions, and architecture remain intact.  In
        !           189:    order to avoid confusion, new UDP ports have been allocated for use
        !           190:    by the protocol described in this memo.
        !           191: 
        !           192: 
        !           193: 
        !           194: 
        !           195: 
        !           196: 
        !           197: 
        !           198: 
        !           199: 
        !           200: 
        !           201: 
        !           202: 
        !           203: 
        !           204: 
        !           205: 
        !           206: 
        !           207: 
        !           208: 
        !           209: 
        !           210: 
        !           211: 
        !           212: 
        !           213: 
        !           214: 
        !           215: 
        !           216: 
        !           217: 
        !           218: 
        !           219: 
        !           220: 
        !           221: 
        !           222: 
        !           223: 
        !           224: 
        !           225: 
        !           226: Case, Fedor, Schoffstall, & Davin                               [Page 4]
        !           227: 
        !           228: RFC 1157                          SNMP                          May 1990
        !           229: 
        !           230: 
        !           231: 3.  The SNMP Architecture
        !           232: 
        !           233:    Implicit in the SNMP architectural model is a collection of network
        !           234:    management stations and network elements.  Network management
        !           235:    stations execute management applications which monitor and control
        !           236:    network elements.  Network elements are devices such as hosts,
        !           237:    gateways, terminal servers, and the like, which have management
        !           238:    agents responsible for performing the network management functions
        !           239:    requested by the network management stations.  The Simple Network
        !           240:    Management Protocol (SNMP) is used to communicate management
        !           241:    information between the network management stations and the agents in
        !           242:    the network elements.
        !           243: 
        !           244: 3.1.  Goals of the Architecture
        !           245: 
        !           246:    The SNMP explicitly minimizes the number and complexity of management
        !           247:    functions realized by the management agent itself.  This goal is
        !           248:    attractive in at least four respects:
        !           249: 
        !           250:       (1)  The development cost for management agent software
        !           251:            necessary to support the protocol is accordingly reduced.
        !           252: 
        !           253:       (2)  The degree of management function that is remotely
        !           254:            supported is accordingly increased, thereby admitting
        !           255:            fullest use of internet resources in the management task.
        !           256: 
        !           257:       (3)  The degree of management function that is remotely
        !           258:            supported is accordingly increased, thereby imposing the
        !           259:            fewest possible restrictions on the form and
        !           260:            sophistication of management tools.
        !           261: 
        !           262:       (4)  Simplified sets of management functions are easily
        !           263:            understood and used by developers of network management
        !           264:            tools.
        !           265: 
        !           266:    A second goal of the protocol is that the functional paradigm for
        !           267:    monitoring and control be sufficiently extensible to accommodate
        !           268:    additional, possibly unanticipated aspects of network operation and
        !           269:    management.
        !           270: 
        !           271:    A third goal is that the architecture be, as much as possible,
        !           272:    independent of the architecture and mechanisms of particular hosts or
        !           273:    particular gateways.
        !           274: 
        !           275: 3.2.  Elements of the Architecture
        !           276: 
        !           277:    The SNMP architecture articulates a solution to the network
        !           278:    management problem in terms of:
        !           279: 
        !           280: 
        !           281: 
        !           282: Case, Fedor, Schoffstall, & Davin                               [Page 5]
        !           283: 
        !           284: RFC 1157                          SNMP                          May 1990
        !           285: 
        !           286: 
        !           287:       (1)  the scope of the management information communicated by
        !           288:            the protocol,
        !           289: 
        !           290:       (2)  the representation of the management information
        !           291:            communicated by the protocol,
        !           292: 
        !           293:       (3)  operations on management information supported by the
        !           294:            protocol,
        !           295: 
        !           296:       (4)  the form and meaning of exchanges among management
        !           297:            entities,
        !           298: 
        !           299:       (5)  the definition of administrative relationships among
        !           300:            management entities, and
        !           301: 
        !           302:       (6)  the form and meaning of references to management
        !           303:            information.
        !           304: 
        !           305: 3.2.1.  Scope of Management Information
        !           306: 
        !           307:    The scope of the management information communicated by operation of
        !           308:    the SNMP is exactly that represented by instances of all non-
        !           309:    aggregate object types either defined in Internet-standard MIB or
        !           310:    defined elsewhere according to the conventions set forth in
        !           311:    Internet-standard SMI [5].
        !           312: 
        !           313:    Support for aggregate object types in the MIB is neither required for
        !           314:    conformance with the SMI nor realized by the SNMP.
        !           315: 
        !           316: 3.2.2.  Representation of Management Information
        !           317: 
        !           318:    Management information communicated by operation of the SNMP is
        !           319:    represented according to the subset of the ASN.1 language [9] that is
        !           320:    specified for the definition of non-aggregate types in the SMI.
        !           321: 
        !           322:    The SGMP adopted the convention of using a well-defined subset of the
        !           323:    ASN.1 language [9].  The SNMP continues and extends this tradition by
        !           324:    utilizing a moderately more complex subset of ASN.1 for describing
        !           325:    managed objects and for describing the protocol data units used for
        !           326:    managing those objects.  In addition, the desire to ease eventual
        !           327:    transition to OSI-based network management protocols led to the
        !           328:    definition in the ASN.1 language of an Internet-standard Structure of
        !           329:    Management Information (SMI) [5] and Management Information Base
        !           330:    (MIB) [6].  The use of the ASN.1 language, was, in part, encouraged
        !           331:    by the successful use of ASN.1 in earlier efforts, in particular, the
        !           332:    SGMP.  The restrictions on the use of ASN.1 that are part of the SMI
        !           333:    contribute to the simplicity espoused and validated by experience
        !           334:    with the SGMP.
        !           335: 
        !           336: 
        !           337: 
        !           338: Case, Fedor, Schoffstall, & Davin                               [Page 6]
        !           339: 
        !           340: RFC 1157                          SNMP                          May 1990
        !           341: 
        !           342: 
        !           343:    Also for the sake of simplicity, the SNMP uses only a subset of the
        !           344:    basic encoding rules of ASN.1 [10].  Namely, all encodings use the
        !           345:    definite-length form.  Further, whenever permissible, non-constructor
        !           346:    encodings are used rather than constructor encodings.  This
        !           347:    restriction applies to all aspects of ASN.1 encoding, both for the
        !           348:    top-level protocol data units and the data objects they contain.
        !           349: 
        !           350: 3.2.3.  Operations Supported on Management Information
        !           351: 
        !           352:    The SNMP models all management agent functions as alterations or
        !           353:    inspections of variables.  Thus, a protocol entity on a logically
        !           354:    remote host (possibly the network element itself) interacts with the
        !           355:    management agent resident on the network element in order to retrieve
        !           356:    (get) or alter (set) variables.  This strategy has at least two
        !           357:    positive consequences:
        !           358: 
        !           359:       (1)  It has the effect of limiting the number of essential
        !           360:            management functions realized by the management agent to
        !           361:            two:  one operation to assign a value to a specified
        !           362:            configuration or other parameter and another to retrieve
        !           363:            such a value.
        !           364: 
        !           365:       (2)  A second effect of this decision is to avoid introducing
        !           366:            into the protocol definition support for imperative
        !           367:            management commands:  the number of such commands is in
        !           368:            practice ever-increasing, and the semantics of such
        !           369:            commands are in general arbitrarily complex.
        !           370: 
        !           371:    The strategy implicit in the SNMP is that the monitoring of network
        !           372:    state at any significant level of detail is accomplished primarily by
        !           373:    polling for appropriate information on the part of the monitoring
        !           374:    center(s).  A limited number of unsolicited messages (traps) guide
        !           375:    the timing and focus of the polling.  Limiting the number of
        !           376:    unsolicited messages is consistent with the goal of simplicity and
        !           377:    minimizing the amount of traffic generated by the network management
        !           378:    function.
        !           379: 
        !           380:    The exclusion of imperative commands from the set of explicitly
        !           381:    supported management functions is unlikely to preclude any desirable
        !           382:    management agent operation.  Currently, most commands are requests
        !           383:    either to set the value of some parameter or to retrieve such a
        !           384:    value, and the function of the few imperative commands currently
        !           385:    supported is easily accommodated in an asynchronous mode by this
        !           386:    management model.  In this scheme, an imperative command might be
        !           387:    realized as the setting of a parameter value that subsequently
        !           388:    triggers the desired action.  For example, rather than implementing a
        !           389:    "reboot command," this action might be invoked by simply setting a
        !           390:    parameter indicating the number of seconds until system reboot.
        !           391: 
        !           392: 
        !           393: 
        !           394: Case, Fedor, Schoffstall, & Davin                               [Page 7]
        !           395: 
        !           396: RFC 1157                          SNMP                          May 1990
        !           397: 
        !           398: 
        !           399: 3.2.4.  Form and Meaning of Protocol Exchanges
        !           400: 
        !           401:    The communication of management information among management entities
        !           402:    is realized in the SNMP through the exchange of protocol messages.
        !           403:    The form and meaning of those messages is defined below in Section 4.
        !           404: 
        !           405:    Consistent with the goal of minimizing complexity of the management
        !           406:    agent, the exchange of SNMP messages requires only an unreliable
        !           407:    datagram service, and every message is entirely and independently
        !           408:    represented by a single transport datagram.  While this document
        !           409:    specifies the exchange of messages via the UDP protocol [11], the
        !           410:    mechanisms of the SNMP are generally suitable for use with a wide
        !           411:    variety of transport services.
        !           412: 
        !           413: 3.2.5.  Definition of Administrative Relationships
        !           414: 
        !           415:    The SNMP architecture admits a variety of administrative
        !           416:    relationships among entities that participate in the protocol.  The
        !           417:    entities residing at management stations and network elements which
        !           418:    communicate with one another using the SNMP are termed SNMP
        !           419:    application entities.  The peer processes which implement the SNMP,
        !           420:    and thus support the SNMP application entities, are termed protocol
        !           421:    entities.
        !           422: 
        !           423:    A pairing of an SNMP agent with some arbitrary set of SNMP
        !           424:    application entities is called an SNMP community.  Each SNMP
        !           425:    community is named by a string of octets, that is called the
        !           426:    community name for said community.
        !           427: 
        !           428:    An SNMP message originated by an SNMP application entity that in fact
        !           429:    belongs to the SNMP community named by the community component of
        !           430:    said message is called an authentic SNMP message.  The set of rules
        !           431:    by which an SNMP message is identified as an authentic SNMP message
        !           432:    for a particular SNMP community is called an authentication scheme.
        !           433:    An implementation of a function that identifies authentic SNMP
        !           434:    messages according to one or more authentication schemes is called an
        !           435:    authentication service.
        !           436: 
        !           437:    Clearly, effective management of administrative relationships among
        !           438:    SNMP application entities requires authentication services that (by
        !           439:    the use of encryption or other techniques) are able to identify
        !           440:    authentic SNMP messages with a high degree of certainty.  Some SNMP
        !           441:    implementations may wish to support only a trivial authentication
        !           442:    service that identifies all SNMP messages as authentic SNMP messages.
        !           443: 
        !           444:    For any network element, a subset of objects in the MIB that pertain
        !           445:    to that element is called a SNMP MIB view.  Note that the names of
        !           446:    the object types represented in a SNMP MIB view need not belong to a
        !           447: 
        !           448: 
        !           449: 
        !           450: Case, Fedor, Schoffstall, & Davin                               [Page 8]
        !           451: 
        !           452: RFC 1157                          SNMP                          May 1990
        !           453: 
        !           454: 
        !           455:    single sub-tree of the object type name space.
        !           456: 
        !           457:    An element of the set { READ-ONLY, READ-WRITE } is called an SNMP
        !           458:    access mode.
        !           459: 
        !           460:    A pairing of a SNMP access mode with a SNMP MIB view is called an
        !           461:    SNMP community profile.  A SNMP community profile represents
        !           462:    specified access privileges to variables in a specified MIB view. For
        !           463:    every variable in the MIB view in a given SNMP community profile,
        !           464:    access to that variable is represented by the profile according to
        !           465:    the following conventions:
        !           466: 
        !           467:       (1)  if said variable is defined in the MIB with "Access:" of
        !           468:            "none," it is unavailable as an operand for any operator;
        !           469: 
        !           470:       (2)  if said variable is defined in the MIB with "Access:" of
        !           471:            "read-write" or "write-only" and the access mode of the
        !           472:            given profile is READ-WRITE, that variable is available
        !           473:            as an operand for the get, set, and trap operations;
        !           474: 
        !           475:       (3)  otherwise, the variable is available as an operand for
        !           476:            the get and trap operations.
        !           477: 
        !           478:       (4)  In those cases where a "write-only" variable is an
        !           479:            operand used for the get or trap operations, the value
        !           480:            given for the variable is implementation-specific.
        !           481: 
        !           482:    A pairing of a SNMP community with a SNMP community profile is called
        !           483:    a SNMP access policy. An access policy represents a specified
        !           484:    community profile afforded by the SNMP agent of a specified SNMP
        !           485:    community to other members of that community.  All administrative
        !           486:    relationships among SNMP application entities are architecturally
        !           487:    defined in terms of SNMP access policies.
        !           488: 
        !           489:    For every SNMP access policy, if the network element on which the
        !           490:    SNMP agent for the specified SNMP community resides is not that to
        !           491:    which the MIB view for the specified profile pertains, then that
        !           492:    policy is called a SNMP proxy access policy. The SNMP agent
        !           493:    associated with a proxy access policy is called a SNMP proxy agent.
        !           494:    While careless definition of proxy access policies can result in
        !           495:    management loops, prudent definition of proxy policies is useful in
        !           496:    at least two ways:
        !           497: 
        !           498:       (1)  It permits the monitoring and control of network elements
        !           499:            which are otherwise not addressable using the management
        !           500:            protocol and the transport protocol.  That is, a proxy
        !           501:            agent may provide a protocol conversion function allowing
        !           502:            a management station to apply a consistent management
        !           503: 
        !           504: 
        !           505: 
        !           506: Case, Fedor, Schoffstall, & Davin                               [Page 9]
        !           507: 
        !           508: RFC 1157                          SNMP                          May 1990
        !           509: 
        !           510: 
        !           511:            framework to all network elements, including devices such
        !           512:            as modems, multiplexors, and other devices which support
        !           513:            different management frameworks.
        !           514: 
        !           515:       (2)  It potentially shields network elements from elaborate
        !           516:            access control policies.  For example, a proxy agent may
        !           517:            implement sophisticated access control whereby diverse
        !           518:            subsets of variables within the MIB are made accessible
        !           519:            to different management stations without increasing the
        !           520:            complexity of the network element.
        !           521: 
        !           522:    By way of example, Figure 1 illustrates the relationship between
        !           523:    management stations, proxy agents, and management agents.  In this
        !           524:    example, the proxy agent is envisioned to be a normal Internet
        !           525:    Network Operations Center (INOC) of some administrative domain which
        !           526:    has a standard managerial relationship with a set of management
        !           527:    agents.
        !           528: 
        !           529: 
        !           530: 
        !           531: 
        !           532: 
        !           533: 
        !           534: 
        !           535: 
        !           536: 
        !           537: 
        !           538: 
        !           539: 
        !           540: 
        !           541: 
        !           542: 
        !           543: 
        !           544: 
        !           545: 
        !           546: 
        !           547: 
        !           548: 
        !           549: 
        !           550: 
        !           551: 
        !           552: 
        !           553: 
        !           554: 
        !           555: 
        !           556: 
        !           557: 
        !           558: 
        !           559: 
        !           560: 
        !           561: 
        !           562: Case, Fedor, Schoffstall, & Davin                              [Page 10]
        !           563: 
        !           564: RFC 1157                          SNMP                          May 1990
        !           565: 
        !           566: 
        !           567:    +------------------+       +----------------+      +----------------+
        !           568:    |  Region #1 INOC  |       |Region #2 INOC  |      |PC in Region #3 |
        !           569:    |                  |       |                |      |                |
        !           570:    |Domain=Region #1  |       |Domain=Region #2|      |Domain=Region #3|
        !           571:    |CPU=super-mini-1  |       |CPU=super-mini-1|      |CPU=Clone-1     |
        !           572:    |PCommunity=pub    |       |PCommunity=pub  |      |PCommunity=slate|
        !           573:    |                  |       |                |      |                |
        !           574:    +------------------+       +----------------+      +----------------+
        !           575:           /|\                      /|\                     /|\
        !           576:            |                        |                       |
        !           577:            |                        |                       |
        !           578:            |                       \|/                      |
        !           579:            |               +-----------------+              |
        !           580:            +-------------->| Region #3 INOC  |<-------------+
        !           581:                            |                 |
        !           582:                            |Domain=Region #3 |
        !           583:                            |CPU=super-mini-2 |
        !           584:                            |PCommunity=pub,  |
        !           585:                            |         slate   |
        !           586:                            |DCommunity=secret|
        !           587:            +-------------->|                 |<-------------+
        !           588:            |               +-----------------+              |
        !           589:            |                       /|\                      |
        !           590:            |                        |                       |
        !           591:            |                        |                       |
        !           592:           \|/                      \|/                     \|/
        !           593:    +-----------------+     +-----------------+       +-----------------+
        !           594:    |Domain=Region#3  |     |Domain=Region#3  |       |Domain=Region#3  |
        !           595:    |CPU=router-1     |     |CPU=mainframe-1  |       |CPU=modem-1      |
        !           596:    |DCommunity=secret|     |DCommunity=secret|       |DCommunity=secret|
        !           597:    +-----------------+     +-----------------+       +-----------------+
        !           598: 
        !           599: 
        !           600:    Domain:  the administrative domain of the element
        !           601:    PCommunity:  the name of a community utilizing a proxy agent
        !           602:    DCommunity:  the name of a direct community
        !           603: 
        !           604: 
        !           605:                                  Figure 1
        !           606:                  Example Network Management Configuration
        !           607: 
        !           608: 
        !           609: 
        !           610: 
        !           611: 
        !           612: 
        !           613: 
        !           614: 
        !           615: 
        !           616: 
        !           617: 
        !           618: Case, Fedor, Schoffstall, & Davin                              [Page 11]
        !           619: 
        !           620: RFC 1157                          SNMP                          May 1990
        !           621: 
        !           622: 
        !           623: 3.2.6.  Form and Meaning of References to Managed Objects
        !           624: 
        !           625:    The SMI requires that the definition of a conformant management
        !           626:    protocol address:
        !           627: 
        !           628:       (1)  the resolution of ambiguous MIB references,
        !           629: 
        !           630:       (2)  the resolution of MIB references in the presence multiple
        !           631:            MIB versions, and
        !           632: 
        !           633:       (3)  the identification of particular instances of object
        !           634:            types defined in the MIB.
        !           635: 
        !           636: 3.2.6.1.  Resolution of Ambiguous MIB References
        !           637: 
        !           638:    Because the scope of any SNMP operation is conceptually confined to
        !           639:    objects relevant to a single network element, and because all SNMP
        !           640:    references to MIB objects are (implicitly or explicitly) by unique
        !           641:    variable names, there is no possibility that any SNMP reference to
        !           642:    any object type defined in the MIB could resolve to multiple
        !           643:    instances of that type.
        !           644: 
        !           645: 3.2.6.2.  Resolution of References across MIB Versions
        !           646: 
        !           647:    The object instance referred to by any SNMP operation is exactly that
        !           648:    specified as part of the operation request or (in the case of a get-
        !           649:    next operation) its immediate successor in the MIB as a whole.  In
        !           650:    particular, a reference to an object as part of some version of the
        !           651:    Internet-standard MIB does not resolve to any object that is not part
        !           652:    of said version of the Internet-standard MIB, except in the case that
        !           653:    the requested operation is get-next and the specified object name is
        !           654:    lexicographically last among the names of all objects presented as
        !           655:    part of said version of the Internet-Standard MIB.
        !           656: 
        !           657: 3.2.6.3.  Identification of Object Instances
        !           658: 
        !           659:    The names for all object types in the MIB are defined explicitly
        !           660:    either in the Internet-standard MIB or in other documents which
        !           661:    conform to the naming conventions of the SMI.  The SMI requires that
        !           662:    conformant management protocols define mechanisms for identifying
        !           663:    individual instances of those object types for a particular network
        !           664:    element.
        !           665: 
        !           666:    Each instance of any object type defined in the MIB is identified in
        !           667:    SNMP operations by a unique name called its "variable name." In
        !           668:    general, the name of an SNMP variable is an OBJECT IDENTIFIER of the
        !           669:    form x.y, where x is the name of a non-aggregate object type defined
        !           670:    in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way
        !           671: 
        !           672: 
        !           673: 
        !           674: Case, Fedor, Schoffstall, & Davin                              [Page 12]
        !           675: 
        !           676: RFC 1157                          SNMP                          May 1990
        !           677: 
        !           678: 
        !           679:    specific to the named object type, identifies the desired instance.
        !           680: 
        !           681:    This naming strategy admits the fullest exploitation of the semantics
        !           682:    of the GetNextRequest-PDU (see Section 4), because it assigns names
        !           683:    for related variables so as to be contiguous in the lexicographical
        !           684:    ordering of all variable names known in the MIB.
        !           685: 
        !           686:    The type-specific naming of object instances is defined below for a
        !           687:    number of classes of object types.  Instances of an object type to
        !           688:    which none of the following naming conventions are applicable are
        !           689:    named by OBJECT IDENTIFIERs of the form x.0, where x is the name of
        !           690:    said object type in the MIB definition.
        !           691: 
        !           692:    For example, suppose one wanted to identify an instance of the
        !           693:    variable sysDescr The object class for sysDescr is:
        !           694: 
        !           695:              iso org dod internet mgmt mib system sysDescr
        !           696:               1   3   6     1      2    1    1       1
        !           697: 
        !           698:    Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is
        !           699:    appended an instance sub-identifier of 0.  That is, 1.3.6.1.2.1.1.1.0
        !           700:    identifies the one and only instance of sysDescr.
        !           701: 
        !           702: 3.2.6.3.1.  ifTable Object Type Names
        !           703: 
        !           704:    The name of a subnet interface, s, is the OBJECT IDENTIFIER value of
        !           705:    the form i, where i has the value of that instance of the ifIndex
        !           706:    object type associated with s.
        !           707: 
        !           708:    For each object type, t, for which the defined name, n, has a prefix
        !           709:    of ifEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
        !           710:    the form n.s, where s is the name of the subnet interface about which
        !           711:    i represents information.
        !           712: 
        !           713:    For example, suppose one wanted to identify the instance of the
        !           714:    variable ifType associated with interface 2.  Accordingly, ifType.2
        !           715:    would identify the desired instance.
        !           716: 
        !           717: 3.2.6.3.2.  atTable Object Type Names
        !           718: 
        !           719:    The name of an AT-cached network address, x, is an OBJECT IDENTIFIER
        !           720:    of the form 1.a.b.c.d, where a.b.c.d is the value (in the familiar
        !           721:    "dot" notation) of the atNetAddress object type associated with x.
        !           722: 
        !           723:    The name of an address translation equivalence e is an OBJECT
        !           724:    IDENTIFIER value of the form s.w, such that s is the value of that
        !           725:    instance of the atIndex object type associated with e and such that w
        !           726:    is the name of the AT-cached network address associated with e.
        !           727: 
        !           728: 
        !           729: 
        !           730: Case, Fedor, Schoffstall, & Davin                              [Page 13]
        !           731: 
        !           732: RFC 1157                          SNMP                          May 1990
        !           733: 
        !           734: 
        !           735:    For each object type, t, for which the defined name, n, has a prefix
        !           736:    of atEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
        !           737:    the form n.y, where y is the name of the address translation
        !           738:    equivalence about which i represents information.
        !           739: 
        !           740:    For example, suppose one wanted to find the physical address of an
        !           741:    entry in the address translation table (ARP cache) associated with an
        !           742:    IP address of 89.1.1.42 and interface 3.  Accordingly,
        !           743:    atPhysAddress.3.1.89.1.1.42 would identify the desired instance.
        !           744: 
        !           745: 3.2.6.3.3.  ipAddrTable Object Type Names
        !           746: 
        !           747:    The name of an IP-addressable network element, x, is the OBJECT
        !           748:    IDENTIFIER of the form a.b.c.d such that a.b.c.d is the value (in the
        !           749:    familiar "dot" notation) of that instance of the ipAdEntAddr object
        !           750:    type associated with x.
        !           751: 
        !           752:    For each object type, t, for which the defined name, n, has a prefix
        !           753:    of ipAddrEntry, an instance, i, of t is named by an OBJECT IDENTIFIER
        !           754:    of the form n.y, where y is the name of the IP-addressable network
        !           755:    element about which i represents information.
        !           756: 
        !           757:    For example, suppose one wanted to find the network mask of an entry
        !           758:    in the IP interface table associated with an IP address of 89.1.1.42.
        !           759:    Accordingly, ipAdEntNetMask.89.1.1.42 would identify the desired
        !           760:    instance.
        !           761: 
        !           762: 3.2.6.3.4.  ipRoutingTable Object Type Names
        !           763: 
        !           764:    The name of an IP route, x, is the OBJECT IDENTIFIER of the form
        !           765:    a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
        !           766:    notation) of that instance of the ipRouteDest object type associated
        !           767:    with x.
        !           768: 
        !           769:    For each object type, t, for which the defined name, n, has a prefix
        !           770:    of ipRoutingEntry, an instance, i, of t is named by an OBJECT
        !           771:    IDENTIFIER of the form n.y, where y is the name of the IP route about
        !           772:    which i represents information.
        !           773: 
        !           774:    For example, suppose one wanted to find the next hop of an entry in
        !           775:    the IP routing table associated  with the destination of 89.1.1.42.
        !           776:    Accordingly, ipRouteNextHop.89.1.1.42 would identify the desired
        !           777:    instance.
        !           778: 
        !           779: 3.2.6.3.5.  tcpConnTable Object Type Names
        !           780: 
        !           781:    The name of a TCP connection, x, is the OBJECT IDENTIFIER of the form
        !           782:    a.b.c.d.e.f.g.h.i.j such that a.b.c.d is the value (in the familiar
        !           783: 
        !           784: 
        !           785: 
        !           786: Case, Fedor, Schoffstall, & Davin                              [Page 14]
        !           787: 
        !           788: RFC 1157                          SNMP                          May 1990
        !           789: 
        !           790: 
        !           791:    "dot" notation) of that instance of the tcpConnLocalAddress object
        !           792:    type associated with x and such that f.g.h.i is the value (in the
        !           793:    familiar "dot" notation) of that instance of the tcpConnRemoteAddress
        !           794:    object type associated with x and such that e is the value of that
        !           795:    instance of the tcpConnLocalPort object type associated with x and
        !           796:    such that j is the value of that instance of the tcpConnRemotePort
        !           797:    object type associated with x.
        !           798: 
        !           799:    For each object type, t, for which the defined name, n, has a prefix
        !           800:    of  tcpConnEntry, an instance, i, of t is named by an OBJECT
        !           801:    IDENTIFIER of the form n.y, where y is the name of the TCP connection
        !           802:    about which i represents information.
        !           803: 
        !           804:    For example, suppose one wanted to find the state of a TCP connection
        !           805:    between the local address of 89.1.1.42 on TCP port 21 and the remote
        !           806:    address of 10.0.0.51 on TCP port 2059.  Accordingly,
        !           807:    tcpConnState.89.1.1.42.21.10.0.0.51.2059 would identify the desired
        !           808:    instance.
        !           809: 
        !           810: 3.2.6.3.6.  egpNeighTable Object Type Names
        !           811: 
        !           812:    The name of an EGP neighbor, x, is the OBJECT IDENTIFIER of the form
        !           813:    a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
        !           814:    notation) of that instance of the egpNeighAddr object type associated
        !           815:    with x.
        !           816: 
        !           817:    For each object type, t, for which the defined name, n, has a prefix
        !           818:    of egpNeighEntry, an instance, i, of t is named by an OBJECT
        !           819:    IDENTIFIER of the form n.y, where y is the name of the EGP neighbor
        !           820:    about which i represents information.
        !           821: 
        !           822:    For example, suppose one wanted to find the neighbor state for the IP
        !           823:    address of 89.1.1.42.  Accordingly, egpNeighState.89.1.1.42 would
        !           824:    identify the desired instance.
        !           825: 
        !           826: 
        !           827: 
        !           828: 
        !           829: 
        !           830: 
        !           831: 
        !           832: 
        !           833: 
        !           834: 
        !           835: 
        !           836: 
        !           837: 
        !           838: 
        !           839: 
        !           840: 
        !           841: 
        !           842: Case, Fedor, Schoffstall, & Davin                              [Page 15]
        !           843: 
        !           844: RFC 1157                          SNMP                          May 1990
        !           845: 
        !           846: 
        !           847: 4.  Protocol Specification
        !           848: 
        !           849:    The network management protocol is an application protocol by which
        !           850:    the variables of an agent's MIB may be inspected or altered.
        !           851: 
        !           852:    Communication among protocol entities is accomplished by the exchange
        !           853:    of messages, each of which is entirely and independently represented
        !           854:    within a single UDP datagram using the basic encoding rules of ASN.1
        !           855:    (as discussed in Section 3.2.2).  A message consists of a version
        !           856:    identifier, an SNMP community name, and a protocol data unit (PDU).
        !           857:    A protocol entity receives messages at UDP port 161 on the host with
        !           858:    which it is associated for all messages except for those which report
        !           859:    traps (i.e., all messages except those which contain the Trap-PDU).
        !           860:    Messages which report traps should be received on UDP port 162 for
        !           861:    further processing.  An implementation of this protocol need not
        !           862:    accept messages whose length exceeds 484 octets.  However, it is
        !           863:    recommended that implementations support larger datagrams whenever
        !           864:    feasible.
        !           865: 
        !           866:    It is mandatory that all implementations of the SNMP support the five
        !           867:    PDUs:  GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU,
        !           868:    SetRequest-PDU, and Trap-PDU.
        !           869: 
        !           870:     RFC1157-SNMP DEFINITIONS ::= BEGIN
        !           871: 
        !           872:      IMPORTS
        !           873:           ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
        !           874:                   FROM RFC1155-SMI;
        !           875: 
        !           876: 
        !           877:      -- top-level message
        !           878: 
        !           879:              Message ::=
        !           880:                      SEQUENCE {
        !           881:                           version        -- version-1 for this RFC
        !           882:                              INTEGER {
        !           883:                                  version-1(0)
        !           884:                              },
        !           885: 
        !           886:                          community      -- community name
        !           887:                              OCTET STRING,
        !           888: 
        !           889:                          data           -- e.g., PDUs if trivial
        !           890:                              ANY        -- authentication is being used
        !           891:                      }
        !           892: 
        !           893: 
        !           894: 
        !           895: 
        !           896: 
        !           897: 
        !           898: Case, Fedor, Schoffstall, & Davin                              [Page 16]
        !           899: 
        !           900: RFC 1157                          SNMP                          May 1990
        !           901: 
        !           902: 
        !           903:      -- protocol data units
        !           904: 
        !           905:              PDUs ::=
        !           906:                      CHOICE {
        !           907:                          get-request
        !           908:                              GetRequest-PDU,
        !           909: 
        !           910:                          get-next-request
        !           911:                              GetNextRequest-PDU,
        !           912: 
        !           913:                          get-response
        !           914:                              GetResponse-PDU,
        !           915: 
        !           916:                          set-request
        !           917:                              SetRequest-PDU,
        !           918: 
        !           919:                          trap
        !           920:                              Trap-PDU
        !           921:                           }
        !           922: 
        !           923:      -- the individual PDUs and commonly used
        !           924:      -- data types will be defined later
        !           925: 
        !           926:      END
        !           927: 
        !           928: 
        !           929: 4.1.  Elements of Procedure
        !           930: 
        !           931:    This section describes the actions of a protocol entity implementing
        !           932:    the SNMP. Note, however, that it is not intended to constrain the
        !           933:    internal architecture of any conformant implementation.
        !           934: 
        !           935:    In the text that follows, the term transport address is used.  In the
        !           936:    case of the UDP, a transport address consists of an IP address along
        !           937:    with a UDP port.  Other transport services may be used to support the
        !           938:    SNMP.  In these cases, the definition of a transport address should
        !           939:    be made accordingly.
        !           940: 
        !           941:    The top-level actions of a protocol entity which generates a message
        !           942:    are as follows:
        !           943: 
        !           944:         (1)  It first constructs the appropriate PDU, e.g., the
        !           945:              GetRequest-PDU, as an ASN.1 object.
        !           946: 
        !           947:         (2)  It then passes this ASN.1 object along with a community
        !           948:              name its source transport address and the destination
        !           949:              transport address, to the service which implements the
        !           950:              desired authentication scheme.  This authentication
        !           951: 
        !           952: 
        !           953: 
        !           954: Case, Fedor, Schoffstall, & Davin                              [Page 17]
        !           955: 
        !           956: RFC 1157                          SNMP                          May 1990
        !           957: 
        !           958: 
        !           959:              service returns another ASN.1 object.
        !           960: 
        !           961:         (3)  The protocol entity then constructs an ASN.1 Message
        !           962:              object, using the community name and the resulting ASN.1
        !           963:              object.
        !           964: 
        !           965:         (4)  This new ASN.1 object is then serialized, using the basic
        !           966:              encoding rules of ASN.1, and then sent using a transport
        !           967:              service to the peer protocol entity.
        !           968: 
        !           969:    Similarly, the top-level actions of a protocol entity which receives
        !           970:    a message are as follows:
        !           971: 
        !           972:         (1)  It performs a rudimentary parse of the incoming datagram
        !           973:              to build an ASN.1 object corresponding to an ASN.1
        !           974:              Message object. If the parse fails, it discards the
        !           975:              datagram and performs no further actions.
        !           976: 
        !           977:         (2)  It then verifies the version number of the SNMP message.
        !           978:              If there is a mismatch, it discards the datagram and
        !           979:              performs no further actions.
        !           980: 
        !           981:         (3)  The protocol entity then passes the community name and
        !           982:              user data found in the ASN.1 Message object, along with
        !           983:              the datagram's source and destination transport addresses
        !           984:              to the service which implements the desired
        !           985:              authentication scheme.  This entity returns another ASN.1
        !           986:              object, or signals an authentication failure.  In the
        !           987:              latter case, the protocol entity notes this failure,
        !           988:              (possibly) generates a trap, and discards the datagram
        !           989:              and performs no further actions.
        !           990: 
        !           991:         (4)  The protocol entity then performs a rudimentary parse on
        !           992:              the ASN.1 object returned from the authentication service
        !           993:              to build an ASN.1 object corresponding to an ASN.1 PDUs
        !           994:              object.  If the parse fails, it discards the datagram and
        !           995:              performs no further actions.  Otherwise, using the named
        !           996:              SNMP community, the appropriate profile is selected, and
        !           997:              the PDU is processed accordingly.  If, as a result of
        !           998:              this processing, a message is returned then the source
        !           999:              transport address that the response message is sent from
        !          1000:              shall be identical to the destination transport address
        !          1001:              that the original request message was sent to.
        !          1002: 
        !          1003: 
        !          1004: 
        !          1005: 
        !          1006: 
        !          1007: 
        !          1008: 
        !          1009: 
        !          1010: Case, Fedor, Schoffstall, & Davin                              [Page 18]
        !          1011: 
        !          1012: RFC 1157                          SNMP                          May 1990
        !          1013: 
        !          1014: 
        !          1015: 4.1.1.  Common Constructs
        !          1016: 
        !          1017:    Before introducing the six PDU types of the protocol, it is
        !          1018:    appropriate to consider some of the ASN.1 constructs used frequently:
        !          1019: 
        !          1020:                   -- request/response information
        !          1021: 
        !          1022:                   RequestID ::=
        !          1023:                           INTEGER
        !          1024: 
        !          1025:                   ErrorStatus ::=
        !          1026:                           INTEGER {
        !          1027:                               noError(0),
        !          1028:                               tooBig(1),
        !          1029:                               noSuchName(2),
        !          1030:                               badValue(3),
        !          1031:                               readOnly(4)
        !          1032:                               genErr(5)
        !          1033:                           }
        !          1034: 
        !          1035:                   ErrorIndex ::=
        !          1036:                           INTEGER
        !          1037: 
        !          1038: 
        !          1039:                   -- variable bindings
        !          1040: 
        !          1041:                   VarBind ::=
        !          1042:                           SEQUENCE {
        !          1043:                               name
        !          1044:                                   ObjectName,
        !          1045: 
        !          1046:                               value
        !          1047:                                   ObjectSyntax
        !          1048:                           }
        !          1049: 
        !          1050:                   VarBindList ::=
        !          1051:                           SEQUENCE OF
        !          1052:                               VarBind
        !          1053: 
        !          1054: 
        !          1055:    RequestIDs are used to distinguish among outstanding requests.  By
        !          1056:    use of the RequestID, an SNMP application entity can correlate
        !          1057:    incoming responses with outstanding requests.  In cases where an
        !          1058:    unreliable datagram service is being used, the RequestID also
        !          1059:    provides a simple means of identifying messages duplicated by the
        !          1060:    network.
        !          1061: 
        !          1062:    A non-zero instance of ErrorStatus is used to indicate that an
        !          1063: 
        !          1064: 
        !          1065: 
        !          1066: Case, Fedor, Schoffstall, & Davin                              [Page 19]
        !          1067: 
        !          1068: RFC 1157                          SNMP                          May 1990
        !          1069: 
        !          1070: 
        !          1071:    exception occurred while processing a request.  In these cases,
        !          1072:    ErrorIndex may provide additional information by indicating which
        !          1073:    variable in a list caused the exception.
        !          1074: 
        !          1075:    The term variable refers to an instance of a managed object.  A
        !          1076:    variable binding, or VarBind, refers to the pairing of the name of a
        !          1077:    variable to the variable's value.  A VarBindList is a simple list of
        !          1078:    variable names and corresponding values.  Some PDUs are concerned
        !          1079:    only with the name of a variable and not its value (e.g., the
        !          1080:    GetRequest-PDU).  In this case, the value portion of the binding is
        !          1081:    ignored by the protocol entity.  However, the value portion must
        !          1082:    still have valid ASN.1 syntax and encoding.  It is recommended that
        !          1083:    the ASN.1 value NULL be used for the value portion of such bindings.
        !          1084: 
        !          1085: 4.1.2.  The GetRequest-PDU
        !          1086: 
        !          1087:              The form of the GetRequest-PDU is:
        !          1088:                   GetRequest-PDU ::=
        !          1089:                       [0]
        !          1090:                           IMPLICIT SEQUENCE {
        !          1091:                               request-id
        !          1092:                                   RequestID,
        !          1093: 
        !          1094:                               error-status        -- always 0
        !          1095:                                   ErrorStatus,
        !          1096: 
        !          1097:                               error-index         -- always 0
        !          1098:                                   ErrorIndex,
        !          1099: 
        !          1100:                               variable-bindings
        !          1101:                                   VarBindList
        !          1102:                           }
        !          1103: 
        !          1104: 
        !          1105:    The GetRequest-PDU is generated by a protocol entity only at the
        !          1106:    request of its SNMP application entity.
        !          1107: 
        !          1108:    Upon receipt of the GetRequest-PDU, the receiving protocol entity
        !          1109:    responds according to any applicable rule in the list below:
        !          1110: 
        !          1111:         (1)  If, for any object named in the variable-bindings field,
        !          1112:              the object's name does not exactly match the name of some
        !          1113:              object available for get operations in the relevant MIB
        !          1114:              view, then the receiving entity sends to the originator
        !          1115:              of the received message the GetResponse-PDU of identical
        !          1116:              form, except that the value of the error-status field is
        !          1117:              noSuchName, and the value of the error-index field is the
        !          1118:              index of said object name component in the received
        !          1119: 
        !          1120: 
        !          1121: 
        !          1122: Case, Fedor, Schoffstall, & Davin                              [Page 20]
        !          1123: 
        !          1124: RFC 1157                          SNMP                          May 1990
        !          1125: 
        !          1126: 
        !          1127:              message.
        !          1128: 
        !          1129:         (2)  If, for any object named in the variable-bindings field,
        !          1130:              the object is an aggregate type (as defined in the SMI),
        !          1131:              then the receiving entity sends to the originator of the
        !          1132:              received message the GetResponse-PDU of identical form,
        !          1133:              except that the value of the error-status field is
        !          1134:              noSuchName, and the value of the error-index field is the
        !          1135:              index of said object name component in the received
        !          1136:              message.
        !          1137: 
        !          1138:         (3)  If the size of the GetResponse-PDU generated as described
        !          1139:              below would exceed a local limitation, then the receiving
        !          1140:              entity sends to the originator of the received message
        !          1141:              the GetResponse-PDU of identical form, except that the
        !          1142:              value of the error-status field is tooBig, and the value
        !          1143:              of the error-index field is zero.
        !          1144: 
        !          1145:         (4)  If, for any object named in the variable-bindings field,
        !          1146:              the value of the object cannot be retrieved for reasons
        !          1147:              not covered by any of the foregoing rules, then the
        !          1148:              receiving entity sends to the originator of the received
        !          1149:              message the GetResponse-PDU of identical form, except
        !          1150:              that the value of the error-status field is genErr and
        !          1151:              the value of the error-index field is the index of said
        !          1152:              object name component in the received message.
        !          1153: 
        !          1154:    If none of the foregoing rules apply, then the receiving protocol
        !          1155:    entity sends to the originator of the received message the
        !          1156:    GetResponse-PDU such that, for each object named in the variable-
        !          1157:    bindings field of the received message, the corresponding component
        !          1158:    of the GetResponse-PDU represents the name and value of that
        !          1159:    variable.  The value of the error- status field of the GetResponse-
        !          1160:    PDU is noError and the value of the error-index field is zero.  The
        !          1161:    value of the request-id field of the GetResponse-PDU is that of the
        !          1162:    received message.
        !          1163: 
        !          1164: 4.1.3.  The GetNextRequest-PDU
        !          1165: 
        !          1166:    The form of the GetNextRequest-PDU is identical to that of the
        !          1167:    GetRequest-PDU except for the indication of the PDU type.  In the
        !          1168:    ASN.1 language:
        !          1169: 
        !          1170:                   GetNextRequest-PDU ::=
        !          1171:                       [1]
        !          1172:                           IMPLICIT SEQUENCE {
        !          1173:                               request-id
        !          1174:                                   RequestID,
        !          1175: 
        !          1176: 
        !          1177: 
        !          1178: Case, Fedor, Schoffstall, & Davin                              [Page 21]
        !          1179: 
        !          1180: RFC 1157                          SNMP                          May 1990
        !          1181: 
        !          1182: 
        !          1183:                               error-status        -- always 0
        !          1184:                                   ErrorStatus,
        !          1185: 
        !          1186:                               error-index         -- always 0
        !          1187:                                   ErrorIndex,
        !          1188: 
        !          1189:                               variable-bindings
        !          1190:                                   VarBindList
        !          1191:                           }
        !          1192: 
        !          1193: 
        !          1194:    The GetNextRequest-PDU is generated by a protocol entity only at the
        !          1195:    request of its SNMP application entity.
        !          1196: 
        !          1197:    Upon receipt of the GetNextRequest-PDU, the receiving protocol entity
        !          1198:    responds according to any applicable rule in the list below:
        !          1199: 
        !          1200:         (1)  If, for any object name in the variable-bindings field,
        !          1201:              that name does not lexicographically precede the name of
        !          1202:              some object available for get operations in the relevant
        !          1203:              MIB view, then the receiving entity sends to the
        !          1204:              originator of the received message the GetResponse-PDU of
        !          1205:              identical form, except that the value of the error-status
        !          1206:              field is noSuchName, and the value of the error-index
        !          1207:              field is the index of said object name component in the
        !          1208:              received message.
        !          1209: 
        !          1210:         (2)  If the size of the GetResponse-PDU generated as described
        !          1211:              below would exceed a local limitation, then the receiving
        !          1212:              entity sends to the originator of the received message
        !          1213:              the GetResponse-PDU of identical form, except that the
        !          1214:              value of the error-status field is tooBig, and the value
        !          1215:              of the error-index field is zero.
        !          1216: 
        !          1217:         (3)  If, for any object named in the variable-bindings field,
        !          1218:              the value of the lexicographical successor to the named
        !          1219:              object cannot be retrieved for reasons not covered by any
        !          1220:              of the foregoing rules, then the receiving entity sends
        !          1221:              to the originator of the received message the
        !          1222:              GetResponse-PDU of identical form, except that the value
        !          1223:              of the error-status field is genErr and the value of the
        !          1224:              error-index field is the index of said object name
        !          1225:              component in the received message.
        !          1226: 
        !          1227:    If none of the foregoing rules apply, then the receiving protocol
        !          1228:    entity sends to the originator of the received message the
        !          1229:    GetResponse-PDU such that, for each name in the variable-bindings
        !          1230:    field of the received message, the corresponding component of the
        !          1231: 
        !          1232: 
        !          1233: 
        !          1234: Case, Fedor, Schoffstall, & Davin                              [Page 22]
        !          1235: 
        !          1236: RFC 1157                          SNMP                          May 1990
        !          1237: 
        !          1238: 
        !          1239:    GetResponse-PDU represents the name and value of that object whose
        !          1240:    name is, in the lexicographical ordering of the names of all objects
        !          1241:    available for get operations in the relevant MIB view, together with
        !          1242:    the value of the name field of the given component, the immediate
        !          1243:    successor to that value.  The value of the error-status field of the
        !          1244:    GetResponse-PDU is noError and the value of the errorindex field is
        !          1245:    zero.  The value of the request-id field of the GetResponse-PDU is
        !          1246:    that of the received message.
        !          1247: 
        !          1248: 4.1.3.1.  Example of Table Traversal
        !          1249: 
        !          1250:    One important use of the GetNextRequest-PDU is the traversal of
        !          1251:    conceptual tables of information within the MIB. The semantics of
        !          1252:    this type of SNMP message, together with the protocol-specific
        !          1253:    mechanisms for identifying individual instances of object types in
        !          1254:    the MIB, affords  access to related objects in the MIB as if they
        !          1255:    enjoyed a tabular organization.
        !          1256: 
        !          1257:    By the SNMP exchange sketched below, an SNMP application entity might
        !          1258:    extract the destination address and next hop gateway for each entry
        !          1259:    in the routing table of a particular network element. Suppose that
        !          1260:    this routing table has three entries:
        !          1261: 
        !          1262:          Destination                     NextHop         Metric
        !          1263: 
        !          1264:          10.0.0.99                       89.1.1.42       5
        !          1265:          9.1.2.3                         99.0.0.3        3
        !          1266:          10.0.0.51                       89.1.1.42       5
        !          1267: 
        !          1268: 
        !          1269:    The management station sends to the SNMP agent a GetNextRequest-PDU
        !          1270:    containing the indicated OBJECT IDENTIFIER values as the requested
        !          1271:    variable names:
        !          1272: 
        !          1273:    GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )
        !          1274: 
        !          1275: 
        !          1276:    The SNMP agent responds with a GetResponse-PDU:
        !          1277: 
        !          1278:                  GetResponse (( ipRouteDest.9.1.2.3 =  "9.1.2.3" ),
        !          1279:                          ( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
        !          1280:                          ( ipRouteMetric1.9.1.2.3 = 3 ))
        !          1281: 
        !          1282: 
        !          1283:    The management station continues with:
        !          1284: 
        !          1285:                  GetNextRequest ( ipRouteDest.9.1.2.3,
        !          1286:                          ipRouteNextHop.9.1.2.3,
        !          1287: 
        !          1288: 
        !          1289: 
        !          1290: Case, Fedor, Schoffstall, & Davin                              [Page 23]
        !          1291: 
        !          1292: RFC 1157                          SNMP                          May 1990
        !          1293: 
        !          1294: 
        !          1295:                          ipRouteMetric1.9.1.2.3 )
        !          1296: 
        !          1297: 
        !          1298:    The SNMP agent responds:
        !          1299: 
        !          1300:                  GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
        !          1301:                          ( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
        !          1302:                          ( ipRouteMetric1.10.0.0.51 = 5 ))
        !          1303: 
        !          1304: 
        !          1305:    The management station continues with:
        !          1306: 
        !          1307:                  GetNextRequest ( ipRouteDest.10.0.0.51,
        !          1308:                          ipRouteNextHop.10.0.0.51,
        !          1309:                          ipRouteMetric1.10.0.0.51 )
        !          1310: 
        !          1311: 
        !          1312:    The SNMP agent responds:
        !          1313: 
        !          1314:                  GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
        !          1315:                          ( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
        !          1316:                          ( ipRouteMetric1.10.0.0.99 = 5 ))
        !          1317: 
        !          1318: 
        !          1319:    The management station continues with:
        !          1320: 
        !          1321:                  GetNextRequest ( ipRouteDest.10.0.0.99,
        !          1322:                          ipRouteNextHop.10.0.0.99,
        !          1323:                          ipRouteMetric1.10.0.0.99 )
        !          1324: 
        !          1325: 
        !          1326:    As there are no further entries in the table, the SNMP agent returns
        !          1327:    those objects that are next in the lexicographical ordering of the
        !          1328:    known object names.  This response signals the end of the routing
        !          1329:    table to the management station.
        !          1330: 
        !          1331: 4.1.4.  The GetResponse-PDU
        !          1332: 
        !          1333:    The form of the GetResponse-PDU is identical to that of the
        !          1334:    GetRequest-PDU except for the indication of the PDU type.  In the
        !          1335:    ASN.1 language:
        !          1336: 
        !          1337:                   GetResponse-PDU ::=
        !          1338:                       [2]
        !          1339:                           IMPLICIT SEQUENCE {
        !          1340:                               request-id
        !          1341:                                   RequestID,
        !          1342: 
        !          1343: 
        !          1344: 
        !          1345: 
        !          1346: Case, Fedor, Schoffstall, & Davin                              [Page 24]
        !          1347: 
        !          1348: RFC 1157                          SNMP                          May 1990
        !          1349: 
        !          1350: 
        !          1351:                               error-status
        !          1352:                                   ErrorStatus,
        !          1353: 
        !          1354:                               error-index
        !          1355:                                   ErrorIndex,
        !          1356: 
        !          1357:                               variable-bindings
        !          1358:                                   VarBindList
        !          1359:                           }
        !          1360: 
        !          1361: 
        !          1362:    The GetResponse-PDU is generated by a protocol entity only upon
        !          1363:    receipt of the GetRequest-PDU, GetNextRequest-PDU, or SetRequest-PDU,
        !          1364:    as described elsewhere in this document.
        !          1365: 
        !          1366:    Upon receipt of the GetResponse-PDU, the receiving protocol entity
        !          1367:    presents its contents to its SNMP application entity.
        !          1368: 
        !          1369: 4.1.5.  The SetRequest-PDU
        !          1370: 
        !          1371:    The form of the SetRequest-PDU is identical to that of the
        !          1372:    GetRequest-PDU except for the indication of the PDU type.  In the
        !          1373:    ASN.1 language:
        !          1374: 
        !          1375:                   SetRequest-PDU ::=
        !          1376:                       [3]
        !          1377:                           IMPLICIT SEQUENCE {
        !          1378:                               request-id
        !          1379:                                   RequestID,
        !          1380: 
        !          1381:                               error-status        -- always 0
        !          1382:                                   ErrorStatus,
        !          1383: 
        !          1384:                               error-index         -- always 0
        !          1385:                                   ErrorIndex,
        !          1386: 
        !          1387:                               variable-bindings
        !          1388:                                   VarBindList
        !          1389:                           }
        !          1390: 
        !          1391: 
        !          1392:    The SetRequest-PDU is generated by a protocol entity only at the
        !          1393:    request of its SNMP application entity.
        !          1394: 
        !          1395:    Upon receipt of the SetRequest-PDU, the receiving entity responds
        !          1396:    according to any applicable rule in the list below:
        !          1397: 
        !          1398:         (1)  If, for any object named in the variable-bindings field,
        !          1399: 
        !          1400: 
        !          1401: 
        !          1402: Case, Fedor, Schoffstall, & Davin                              [Page 25]
        !          1403: 
        !          1404: RFC 1157                          SNMP                          May 1990
        !          1405: 
        !          1406: 
        !          1407:              the object is not available for set operations in the
        !          1408:              relevant MIB view, then the receiving entity sends to the
        !          1409:              originator of the received message the GetResponse-PDU of
        !          1410:              identical form, except that the value of the error-status
        !          1411:              field is noSuchName, and the value of the error-index
        !          1412:              field is the index of said object name component in the
        !          1413:              received message.
        !          1414: 
        !          1415:         (2)  If, for any object named in the variable-bindings field,
        !          1416:              the contents of the value field does not, according to
        !          1417:              the ASN.1 language, manifest a type, length, and value
        !          1418:              that is consistent with that required for the variable,
        !          1419:              then the receiving entity sends to the originator of the
        !          1420:              received message the GetResponse-PDU of identical form,
        !          1421:              except that the value of the error-status field is
        !          1422:              badValue, and the value of the error-index field is the
        !          1423:              index of said object name in the received message.
        !          1424: 
        !          1425:         (3)  If the size of the Get Response type message generated as
        !          1426:              described below would exceed a local limitation, then the
        !          1427:              receiving entity sends to the originator of the received
        !          1428:              message the GetResponse-PDU of identical form, except
        !          1429:              that the value of the error-status field is tooBig, and
        !          1430:              the value of the error-index field is zero.
        !          1431: 
        !          1432:         (4)  If, for any object named in the variable-bindings field,
        !          1433:              the value of the named object cannot be altered for
        !          1434:              reasons not covered by any of the foregoing rules, then
        !          1435:              the receiving entity sends to the originator of the
        !          1436:              received message the GetResponse-PDU of identical form,
        !          1437:              except that the value of the error-status field is genErr
        !          1438:              and the value of the error-index field is the index of
        !          1439:              said object name component in the received message.
        !          1440: 
        !          1441:    If none of the foregoing rules apply, then for each object named in
        !          1442:    the variable-bindings field of the received message, the
        !          1443:    corresponding value is assigned to the variable.  Each variable
        !          1444:    assignment specified by the SetRequest-PDU should be effected as if
        !          1445:    simultaneously set with respect to all other assignments specified in
        !          1446:    the same message.
        !          1447: 
        !          1448:    The receiving entity then sends to the originator of the received
        !          1449:    message the GetResponse-PDU of identical form except that the value
        !          1450:    of the error-status field of the generated message is noError and the
        !          1451:    value of the error-index field is zero.
        !          1452: 
        !          1453: 
        !          1454: 
        !          1455: 
        !          1456: 
        !          1457: 
        !          1458: Case, Fedor, Schoffstall, & Davin                              [Page 26]
        !          1459: 
        !          1460: RFC 1157                          SNMP                          May 1990
        !          1461: 
        !          1462: 
        !          1463: 4.1.6.  The Trap-PDU
        !          1464: 
        !          1465:    The form of the Trap-PDU is:
        !          1466: 
        !          1467:      Trap-PDU ::=
        !          1468:          [4]
        !          1469: 
        !          1470:               IMPLICIT SEQUENCE {
        !          1471:                  enterprise          -- type of object generating
        !          1472:                                      -- trap, see sysObjectID in [5]
        !          1473:                      OBJECT IDENTIFIER,
        !          1474: 
        !          1475:                  agent-addr          -- address of object generating
        !          1476:                      NetworkAddress, -- trap
        !          1477: 
        !          1478:                  generic-trap        -- generic trap type
        !          1479:                      INTEGER {
        !          1480:                          coldStart(0),
        !          1481:                          warmStart(1),
        !          1482:                          linkDown(2),
        !          1483:                          linkUp(3),
        !          1484:                          authenticationFailure(4),
        !          1485:                          egpNeighborLoss(5),
        !          1486:                          enterpriseSpecific(6)
        !          1487:                      },
        !          1488: 
        !          1489:                  specific-trap     -- specific code, present even
        !          1490:                      INTEGER,      -- if generic-trap is not
        !          1491:                                    -- enterpriseSpecific
        !          1492: 
        !          1493:                  time-stamp        -- time elapsed between the last
        !          1494:                    TimeTicks,      -- (re)initialization of the network
        !          1495:                                    -- entity and the generation of the
        !          1496:                                       trap
        !          1497: 
        !          1498:                  variable-bindings   -- "interesting" information
        !          1499:                       VarBindList
        !          1500:              }
        !          1501: 
        !          1502: 
        !          1503:    The Trap-PDU is generated by a protocol entity only at the request of
        !          1504:    the SNMP application entity.  The means by which an SNMP application
        !          1505:    entity selects the destination addresses of the SNMP application
        !          1506:    entities is implementation-specific.
        !          1507: 
        !          1508:    Upon receipt of the Trap-PDU, the receiving protocol entity presents
        !          1509:    its contents to its SNMP application entity.
        !          1510: 
        !          1511: 
        !          1512: 
        !          1513: 
        !          1514: Case, Fedor, Schoffstall, & Davin                              [Page 27]
        !          1515: 
        !          1516: RFC 1157                          SNMP                          May 1990
        !          1517: 
        !          1518: 
        !          1519:    The significance of the variable-bindings component of the Trap-PDU
        !          1520:    is implementation-specific.
        !          1521: 
        !          1522:    Interpretations of the value of the generic-trap field are:
        !          1523: 
        !          1524: 4.1.6.1.  The coldStart Trap
        !          1525: 
        !          1526:    A coldStart(0) trap signifies that the sending protocol entity is
        !          1527:    reinitializing itself such that the agent's configuration or the
        !          1528:    protocol entity implementation may be altered.
        !          1529: 
        !          1530: 4.1.6.2.  The warmStart Trap
        !          1531: 
        !          1532:    A warmStart(1) trap signifies that the sending protocol entity is
        !          1533:    reinitializing itself such that neither the agent configuration nor
        !          1534:    the protocol entity implementation is altered.
        !          1535: 
        !          1536: 4.1.6.3.  The linkDown Trap
        !          1537: 
        !          1538:    A linkDown(2) trap signifies that the sending protocol entity
        !          1539:    recognizes a failure in one of the communication links represented in
        !          1540:    the agent's configuration.
        !          1541: 
        !          1542:    The Trap-PDU of type linkDown contains as the first element of its
        !          1543:    variable-bindings, the name and value of the ifIndex instance for the
        !          1544:    affected interface.
        !          1545: 
        !          1546: 4.1.6.4.  The linkUp Trap
        !          1547: 
        !          1548:    A linkUp(3) trap signifies that the sending protocol entity
        !          1549:    recognizes that one of the communication links represented in the
        !          1550:    agent's configuration has come up.
        !          1551: 
        !          1552:    The Trap-PDU of type linkUp contains as the first element of its
        !          1553:    variable-bindings, the name and value of the ifIndex instance for the
        !          1554:    affected interface.
        !          1555: 
        !          1556: 4.1.6.5.  The authenticationFailure Trap
        !          1557: 
        !          1558:    An authenticationFailure(4) trap signifies that the sending protocol
        !          1559:    entity is the addressee of a protocol message that is not properly
        !          1560:    authenticated.  While implementations of the SNMP must be capable of
        !          1561:    generating this trap, they must also be capable of suppressing the
        !          1562:    emission of such traps via an implementation-specific mechanism.
        !          1563: 
        !          1564: 4.1.6.6.  The egpNeighborLoss Trap
        !          1565: 
        !          1566:    An egpNeighborLoss(5) trap signifies that an EGP neighbor for whom
        !          1567: 
        !          1568: 
        !          1569: 
        !          1570: Case, Fedor, Schoffstall, & Davin                              [Page 28]
        !          1571: 
        !          1572: RFC 1157                          SNMP                          May 1990
        !          1573: 
        !          1574: 
        !          1575:    the sending protocol entity was an EGP peer has been marked down and
        !          1576:    the peer relationship no longer obtains.
        !          1577: 
        !          1578:    The Trap-PDU of type egpNeighborLoss contains as the first element of
        !          1579:    its variable-bindings, the name and value of the egpNeighAddr
        !          1580:    instance for the affected neighbor.
        !          1581: 
        !          1582: 4.1.6.7.  The enterpriseSpecific Trap
        !          1583: 
        !          1584:    A enterpriseSpecific(6) trap signifies that the sending protocol
        !          1585:    entity recognizes that some enterprise-specific event has occurred.
        !          1586:    The specific-trap field identifies the particular trap which
        !          1587:    occurred.
        !          1588: 
        !          1589: 
        !          1590: 
        !          1591: 
        !          1592: 
        !          1593: 
        !          1594: 
        !          1595: 
        !          1596: 
        !          1597: 
        !          1598: 
        !          1599: 
        !          1600: 
        !          1601: 
        !          1602: 
        !          1603: 
        !          1604: 
        !          1605: 
        !          1606: 
        !          1607: 
        !          1608: 
        !          1609: 
        !          1610: 
        !          1611: 
        !          1612: 
        !          1613: 
        !          1614: 
        !          1615: 
        !          1616: 
        !          1617: 
        !          1618: 
        !          1619: 
        !          1620: 
        !          1621: 
        !          1622: 
        !          1623: 
        !          1624: 
        !          1625: 
        !          1626: Case, Fedor, Schoffstall, & Davin                              [Page 29]
        !          1627: 
        !          1628: RFC 1157                          SNMP                          May 1990
        !          1629: 
        !          1630: 
        !          1631: 5.  Definitions
        !          1632: 
        !          1633:      RFC1157-SNMP DEFINITIONS ::= BEGIN
        !          1634: 
        !          1635:       IMPORTS
        !          1636:           ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
        !          1637:               FROM RFC1155-SMI;
        !          1638: 
        !          1639: 
        !          1640:           -- top-level message
        !          1641: 
        !          1642:           Message ::=
        !          1643:                   SEQUENCE {
        !          1644:                       version          -- version-1 for this RFC
        !          1645:                           INTEGER {
        !          1646:                               version-1(0)
        !          1647:                           },
        !          1648: 
        !          1649:                       community        -- community name
        !          1650:                           OCTET STRING,
        !          1651: 
        !          1652:                       data             -- e.g., PDUs if trivial
        !          1653:                           ANY          -- authentication is being used
        !          1654:                   }
        !          1655: 
        !          1656: 
        !          1657:           -- protocol data units
        !          1658: 
        !          1659:           PDUs ::=
        !          1660:                   CHOICE {
        !          1661:                               get-request
        !          1662:                                   GetRequest-PDU,
        !          1663: 
        !          1664:                               get-next-request
        !          1665:                                   GetNextRequest-PDU,
        !          1666: 
        !          1667:                               get-response
        !          1668:                                   GetResponse-PDU,
        !          1669: 
        !          1670:                               set-request
        !          1671:                                   SetRequest-PDU,
        !          1672: 
        !          1673:                               trap
        !          1674:                                   Trap-PDU
        !          1675:                           }
        !          1676: 
        !          1677: 
        !          1678: 
        !          1679: 
        !          1680: 
        !          1681: 
        !          1682: Case, Fedor, Schoffstall, & Davin                              [Page 30]
        !          1683: 
        !          1684: RFC 1157                          SNMP                          May 1990
        !          1685: 
        !          1686: 
        !          1687:           -- PDUs
        !          1688: 
        !          1689:           GetRequest-PDU ::=
        !          1690:               [0]
        !          1691:                   IMPLICIT PDU
        !          1692: 
        !          1693:           GetNextRequest-PDU ::=
        !          1694:               [1]
        !          1695:                   IMPLICIT PDU
        !          1696: 
        !          1697:           GetResponse-PDU ::=
        !          1698:               [2]
        !          1699:                   IMPLICIT PDU
        !          1700: 
        !          1701:           SetRequest-PDU ::=
        !          1702:               [3]
        !          1703:                   IMPLICIT PDU
        !          1704: 
        !          1705:           PDU ::=
        !          1706:                   SEQUENCE {
        !          1707:                      request-id
        !          1708:                           INTEGER,
        !          1709: 
        !          1710:                       error-status      -- sometimes ignored
        !          1711:                           INTEGER {
        !          1712:                               noError(0),
        !          1713:                               tooBig(1),
        !          1714:                               noSuchName(2),
        !          1715:                               badValue(3),
        !          1716:                               readOnly(4),
        !          1717:                               genErr(5)
        !          1718:                           },
        !          1719: 
        !          1720:                       error-index       -- sometimes ignored
        !          1721:                          INTEGER,
        !          1722: 
        !          1723:                       variable-bindings -- values are sometimes ignored
        !          1724:                           VarBindList
        !          1725:                   }
        !          1726: 
        !          1727:           Trap-PDU ::=
        !          1728:               [4]
        !          1729:                  IMPLICIT SEQUENCE {
        !          1730:                       enterprise        -- type of object generating
        !          1731:                                         -- trap, see sysObjectID in [5]
        !          1732: 
        !          1733: 
        !          1734:                           OBJECT IDENTIFIER,
        !          1735: 
        !          1736: 
        !          1737: 
        !          1738: Case, Fedor, Schoffstall, & Davin                              [Page 31]
        !          1739: 
        !          1740: RFC 1157                          SNMP                          May 1990
        !          1741: 
        !          1742: 
        !          1743:                       agent-addr        -- address of object generating
        !          1744:                           NetworkAddress, -- trap
        !          1745: 
        !          1746:                       generic-trap      -- generic trap type
        !          1747:                           INTEGER {
        !          1748:                               coldStart(0),
        !          1749:                               warmStart(1),
        !          1750:                               linkDown(2),
        !          1751:                               linkUp(3),
        !          1752:                               authenticationFailure(4),
        !          1753:                               egpNeighborLoss(5),
        !          1754:                               enterpriseSpecific(6)
        !          1755:                           },
        !          1756: 
        !          1757:                       specific-trap  -- specific code, present even
        !          1758:                           INTEGER,   -- if generic-trap is not
        !          1759:                                      -- enterpriseSpecific
        !          1760: 
        !          1761:                       time-stamp     -- time elapsed between the last
        !          1762:                           TimeTicks, -- (re)initialization of the
        !          1763:                                         network
        !          1764:                                      -- entity and the generation of the
        !          1765:                                         trap
        !          1766: 
        !          1767:                        variable-bindings -- "interesting" information
        !          1768:                           VarBindList
        !          1769:                   }
        !          1770: 
        !          1771: 
        !          1772:           -- variable bindings
        !          1773: 
        !          1774:           VarBind ::=
        !          1775:                   SEQUENCE {
        !          1776:                       name
        !          1777:                           ObjectName,
        !          1778: 
        !          1779:                       value
        !          1780:                           ObjectSyntax
        !          1781:                   }
        !          1782: 
        !          1783:          VarBindList ::=
        !          1784:                   SEQUENCE OF
        !          1785:                      VarBind
        !          1786: 
        !          1787:          END
        !          1788: 
        !          1789: 
        !          1790: 
        !          1791: 
        !          1792: 
        !          1793: 
        !          1794: Case, Fedor, Schoffstall, & Davin                              [Page 32]
        !          1795: 
        !          1796: RFC 1157                          SNMP                          May 1990
        !          1797: 
        !          1798: 
        !          1799: 6.  Acknowledgements
        !          1800: 
        !          1801:    This memo was influenced by the IETF SNMP Extensions working
        !          1802:    group:
        !          1803: 
        !          1804:              Karl Auerbach, Epilogue Technology
        !          1805:              K. Ramesh Babu, Excelan
        !          1806:              Amatzia Ben-Artzi, 3Com/Bridge
        !          1807:              Lawrence Besaw, Hewlett-Packard
        !          1808:              Jeffrey D. Case, University of Tennessee at Knoxville
        !          1809:              Anthony Chung, Sytek
        !          1810:              James Davidson, The Wollongong Group
        !          1811:              James R. Davin, MIT Laboratory for Computer Science
        !          1812:              Mark S. Fedor, NYSERNet
        !          1813:              Phill Gross, The MITRE Corporation
        !          1814:              Satish Joshi, ACC
        !          1815:              Dan Lynch, Advanced Computing Environments
        !          1816:              Keith McCloghrie, The Wollongong Group
        !          1817:              Marshall T. Rose, The Wollongong Group (chair)
        !          1818:              Greg Satz, cisco
        !          1819:              Martin Lee Schoffstall, Rensselaer Polytechnic Institute
        !          1820:              Wengyik Yeong, NYSERNet
        !          1821: 
        !          1822: 
        !          1823: 
        !          1824: 
        !          1825: 
        !          1826: 
        !          1827: 
        !          1828: 
        !          1829: 
        !          1830: 
        !          1831: 
        !          1832: 
        !          1833: 
        !          1834: 
        !          1835: 
        !          1836: 
        !          1837: 
        !          1838: 
        !          1839: 
        !          1840: 
        !          1841: 
        !          1842: 
        !          1843: 
        !          1844: 
        !          1845: 
        !          1846: 
        !          1847: 
        !          1848: 
        !          1849: 
        !          1850: Case, Fedor, Schoffstall, & Davin                              [Page 33]
        !          1851: 
        !          1852: RFC 1157                          SNMP                          May 1990
        !          1853: 
        !          1854: 
        !          1855: 7.  References
        !          1856: 
        !          1857:    [1] Cerf, V., "IAB Recommendations for the Development of
        !          1858:        Internet Network Management Standards", RFC 1052, IAB,
        !          1859:        April 1988.
        !          1860: 
        !          1861:    [2] Rose, M., and K. McCloghrie, "Structure and Identification
        !          1862:        of Management Information for TCP/IP-based internets",
        !          1863:        RFC 1065, TWG, August 1988.
        !          1864: 
        !          1865:    [3] McCloghrie, K., and M. Rose, "Management Information Base
        !          1866:        for Network Management of TCP/IP-based internets",
        !          1867:        RFC 1066, TWG, August 1988.
        !          1868: 
        !          1869:    [4] Cerf, V., "Report of the Second Ad Hoc Network Management
        !          1870:        Review Group", RFC 1109, IAB, August 1989.
        !          1871: 
        !          1872:    [5] Rose, M., and K. McCloghrie, "Structure and Identification
        !          1873:        of Management Information for TCP/IP-based Internets",
        !          1874:        RFC 1155, Performance Systems International and Hughes LAN
        !          1875:        Systems, May 1990.
        !          1876: 
        !          1877:    [6] McCloghrie, K., and M. Rose, "Management Information Base
        !          1878:        for Network Management of TCP/IP-based Internets",
        !          1879:        RFC 1156, Hughes LAN Systems and Performance Systems
        !          1880:        International, May 1990.
        !          1881: 
        !          1882:    [7] Case, J., M. Fedor, M. Schoffstall, and J. Davin,
        !          1883:        "A Simple Network Management Protocol", Internet
        !          1884:        Engineering Task Force working note, Network Information
        !          1885:        Center, SRI International, Menlo Park, California,
        !          1886:        March 1988.
        !          1887: 
        !          1888:    [8] Davin, J., J. Case, M. Fedor, and M. Schoffstall,
        !          1889:        "A Simple Gateway Monitoring Protocol", RFC 1028,
        !          1890:        Proteon, University of Tennessee at Knoxville,
        !          1891:        Cornell University, and Rensselaer Polytechnic
        !          1892:        Institute, November 1987.
        !          1893: 
        !          1894:    [9] Information processing systems - Open Systems
        !          1895:        Interconnection, "Specification of Abstract Syntax
        !          1896:        Notation One (ASN.1)", International Organization for
        !          1897:        Standardization, International Standard 8824,
        !          1898:        December 1987.
        !          1899: 
        !          1900:   [10] Information processing systems - Open Systems
        !          1901:        Interconnection, "Specification of Basic Encoding Rules
        !          1902:        for Abstract Notation One (ASN.1)", International
        !          1903: 
        !          1904: 
        !          1905: 
        !          1906: Case, Fedor, Schoffstall, & Davin                              [Page 34]
        !          1907: 
        !          1908: RFC 1157                          SNMP                          May 1990
        !          1909: 
        !          1910: 
        !          1911:        Organization for Standardization, International Standard
        !          1912:        8825, December 1987.
        !          1913: 
        !          1914:   [11] Postel, J., "User Datagram Protocol", RFC 768,
        !          1915:        USC/Information Sciences Institute, November 1980.
        !          1916: 
        !          1917: Security Considerations
        !          1918: 
        !          1919:    Security issues are not discussed in this memo.
        !          1920: 
        !          1921: Authors' Addresses
        !          1922: 
        !          1923:    Jeffrey D. Case
        !          1924:    SNMP Research
        !          1925:    P.O. Box 8593
        !          1926:    Knoxville, TN 37996-4800
        !          1927: 
        !          1928:    Phone:  (615) 573-1434
        !          1929: 
        !          1930:    Email:  [email protected]
        !          1931: 
        !          1932: 
        !          1933:    Mark Fedor
        !          1934:    Performance Systems International
        !          1935:    Rensselaer Technology Park
        !          1936:    125 Jordan Road
        !          1937:    Troy, NY 12180
        !          1938: 
        !          1939:    Phone:  (518) 283-8860
        !          1940: 
        !          1941:    Email:  [email protected]
        !          1942: 
        !          1943: 
        !          1944:    Martin Lee Schoffstall
        !          1945:    Performance Systems International
        !          1946:    Rensselaer Technology Park
        !          1947:    165 Jordan Road
        !          1948:    Troy, NY 12180
        !          1949: 
        !          1950:    Phone:  (518) 283-8860
        !          1951: 
        !          1952:    Email:  [email protected]
        !          1953: 
        !          1954: 
        !          1955: 
        !          1956: 
        !          1957: 
        !          1958: 
        !          1959: 
        !          1960: 
        !          1961: 
        !          1962: Case, Fedor, Schoffstall, & Davin                              [Page 35]
        !          1963: 
        !          1964: RFC 1157                          SNMP                          May 1990
        !          1965: 
        !          1966: 
        !          1967:    James R. Davin
        !          1968:    MIT Laboratory for Computer Science, NE43-507
        !          1969:    545 Technology Square
        !          1970:    Cambridge, MA 02139
        !          1971: 
        !          1972:    Phone:  (617) 253-6020
        !          1973: 
        !          1974:    EMail:  [email protected]
        !          1975: 
        !          1976: 
        !          1977: 
        !          1978: 
        !          1979: 
        !          1980: 
        !          1981: 
        !          1982: 
        !          1983: 
        !          1984: 
        !          1985: 
        !          1986: 
        !          1987: 
        !          1988: 
        !          1989: 
        !          1990: 
        !          1991: 
        !          1992: 
        !          1993: 
        !          1994: 
        !          1995: 
        !          1996: 
        !          1997: 
        !          1998: 
        !          1999: 
        !          2000: 
        !          2001: 
        !          2002: 
        !          2003: 
        !          2004: 
        !          2005: 
        !          2006: 
        !          2007: 
        !          2008: 
        !          2009: 
        !          2010: 
        !          2011: 
        !          2012: 
        !          2013: 
        !          2014: 
        !          2015: 
        !          2016: 
        !          2017: 
        !          2018: Case, Fedor, Schoffstall, & Davin                              [Page 36]
        !          2019: 

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.