home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1300s / rfc1303.txt < prev    next >
Text File  |  1992-02-24  |  23KB  |  675 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                      K. McCloghrie
  8. Request For Comments: 1303                            Hughes LAN Systems
  9.                                                                  M. Rose
  10.                                                   Dover Beach Consulting
  11.                                                            February 1992
  12.  
  13.  
  14.              A Convention for Describing SNMP-based Agents
  15.  
  16. Status of This Memo
  17.  
  18.    This memo provides information for the Internet community.  It does
  19.    not specify an Internet standard.  Distribution of this memo is
  20.    unlimited.
  21.  
  22. Abstract
  23.  
  24.    This memo suggests a straight-forward approach towards describing
  25.    SNMP-based agents.
  26.  
  27. Table of Contents
  28.  
  29.    1. The Network Management Framework ............................    2
  30.    2. Objects .....................................................    2
  31.    3. Describing Agents ...........................................    3
  32.    3.1 Definitions ................................................    4
  33.    3.2 Mapping of the MODULE-CONFORMANCE macro ....................    5
  34.    3.2.1 Mapping of the LAST-UPDATED clause .......................    6
  35.    3.2.2 Mapping of the PRODUCT-RELEASE clause ....................    6
  36.    3.2.3 Mapping of the DESCRIPTION clause ........................    6
  37.    3.2.4 Mapping of the SUPPORTS clause ...........................    6
  38.    3.2.4.1 Mapping of the INCLUDES clause .........................    6
  39.    3.2.4.2 Mapping of the VARIATION clause ........................    6
  40.    3.2.4.2.1 Mapping of the SYNTAX clause .........................    6
  41.    3.2.4.2.2 Mapping of the WRITE-SYNTAX clause ...................    7
  42.    3.2.4.2.3 Mapping of the ACCESS clause .........................    7
  43.    3.2.4.2.4 Mapping of the CREATION-REQUIRES clause ..............    7
  44.    3.2.4.2.5 Mapping of the DEFVAL clause .........................    7
  45.    3.2.4.2.6 Mapping of the DESCRIPTION clause ....................    7
  46.    3.3 Refined Syntax .............................................    7
  47.    3.4 Usage Example ..............................................    8
  48.    4. Acknowledgements ............................................   11
  49.    5. References ..................................................   11
  50.    6. Security Considerations......................................   12
  51.    7. Authors' Addresses...........................................   12
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. McCloghrie & Rose                                               [Page 1]
  59.  
  60. RFC 1303         Convention for Describing SNMP Agents     February 1992
  61.  
  62.  
  63. 1.  The Network Management Framework
  64.  
  65.    The Internet-standard Network Management Framework consists of
  66.    three components.  They are:
  67.  
  68.    RFC 1155 [1] which defines the SMI, the mechanisms used for
  69.    describing and naming objects for the purpose of management.
  70.    RFC 1212 [2] defines a more concise description mechanism,
  71.    which is wholly consistent with the SMI.
  72.  
  73.    RFC 1213 [3] which defines MIB-II, the core set of managed
  74.    objects for the Internet suite of protocols.
  75.  
  76.    RFC 1157 [4] which defines the SNMP, the protocol used for
  77.    network access to managed objects.
  78.  
  79.    The Framework permits new objects to be defined for the
  80.    purpose of experimentation and evaluation.
  81.  
  82. 2.  Objects
  83.  
  84.    Managed objects are accessed via a virtual information store,
  85.    termed the Management Information Base or MIB.  Within a given
  86.    MIB module, objects are defined using RFC 1212's OBJECT-TYPE
  87.    macro.  At a minimum, each object has a name, a syntax, an
  88.    access-level, and an implementation-status.
  89.  
  90.    The name is an object identifier, an administratively assigned
  91.    name, which specifies an object type.  The object type
  92.    together with an object instance serves to uniquely identify a
  93.    specific instantiation of the object.  For human convenience,
  94.    we often use a textual string, termed the OBJECT DESCRIPTOR,
  95.    to also refer to the object type.
  96.  
  97.    The syntax of an object type defines the abstract data
  98.    structure corresponding to that object type.  The ASN.1[5]
  99.    language is used for this purpose.  However, RFC 1155
  100.    purposely restricts the ASN.1 constructs which may be used.
  101.    These restrictions are explicitly made for simplicity.
  102.  
  103.    The access-level of an object type defines whether it makes
  104.    "protocol sense" to read and/or write the value of an instance
  105.    of the object type.  (This access-level is independent of any
  106.    administrative authorization policy.)
  107.  
  108.    The implementation-status of an object type indicates whether
  109.    the object is mandatory, optional, obsolete, or deprecated.
  110.  
  111.  
  112.  
  113.  
  114. McCloghrie & Rose                                               [Page 2]
  115.  
  116. RFC 1303         Convention for Describing SNMP Agents     February 1992
  117.  
  118.  
  119. 3.  Describing Agents
  120.  
  121.    When a MIB module is written, it is divided into units of
  122.    conformance termed groups.  If an agent claims conformance to
  123.    a group, then it must implement each and every object within
  124.    that group.  Of course, for whatever reason, an agent may
  125.    implement only a subset of the groups within a MIB module.  In
  126.    addition, the definition of some MIB objects leave some
  127.    aspects of the definition to the discretion of an implementor.
  128.  
  129.    Practical experience has demonstrated a need for concisely
  130.    describing the capabilities of an agent with regards to the
  131.    MIB groups that it implements.  This memo defines a new macro,
  132.    MODULE-CONFORMANCE, which allows an agent implementor to
  133.    describe the precise level of support which an agent claims in
  134.    regards to a MIB group, and to bind that description to the
  135.    sysObjectID associated with the agent.  In particular, some
  136.    objects may have restricted or augmented syntax or access-
  137.    levels.
  138.  
  139.    If the MODULE-CONFORMANCE invocation is given to a
  140.    management-station implementor, then that implementor can
  141.    build management applications which optimize themselves when
  142.    communicating with a particular agent.  For example, the
  143.    management-station can maintain a database of these
  144.    invocations.  When a management-station interacts with an
  145.    agent, it retrieves the agent's sysObjectID.  Based on this,
  146.    it consults the database.  If an entry is found, then the
  147.    management application can optimize its behavior accordingly.
  148.  
  149.    This binding to sysObjectId may not always suffice to define
  150.    all MIB objects to which an agent can provide access. In
  151.    particular, this situation occurs where the agent dynamically
  152.    learns of the objects it supports, for example, an agent
  153.    supporting SMUX peers via the SMUX protocol [6]. In these
  154.    situations, additional MIB objects beyond sysObjectID must be
  155.    used to name other invocations of the MODULE-CONFORMANCE macro
  156.    to augment the description of MIB support provided by the
  157.    agent. For example, if an agent's sysObjectID indicates that
  158.    it supports the SMUX MIB, then each instance of smuxPidentity
  159.    will indicate another MODULE-CONFORMANCE invocation which is
  160.    dynamically being supported by the agent.
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. McCloghrie & Rose                                               [Page 3]
  171.  
  172. RFC 1303         Convention for Describing SNMP Agents     February 1992
  173.  
  174.  
  175. 3.1.  Definitions
  176.  
  177.    RFC-1303 DEFINITIONS ::= BEGIN
  178.  
  179.        IMPORTS
  180.            ObjectName, ObjectSyntax
  181.                FROM RFC1155-SMI
  182.            DisplayString
  183.                FROM RFC1213-MIB;
  184.  
  185.        MODULE-CONFORMANCE MACRO ::=
  186.        BEGIN
  187.            TYPE NOTATION ::=
  188.                              "LAST-UPDATED"
  189.                                  value(update      UTCTime)
  190.                              "PRODUCT-RELEASE"
  191.                                  value(release     DisplayString)
  192.                              "DESCRIPTION"
  193.                                  value(description DisplayString)
  194.                              ModulePart
  195.  
  196.            VALUE NOTATION ::=      -- agent's sysObjectID --
  197.                              value(VALUE ObjectName)
  198.  
  199.            ModulePart ::=    Modules
  200.                            | empty
  201.  
  202.            Modules ::=       Module
  203.                            | Modules Module
  204.  
  205.            Module ::=                   -- name of module --
  206.                              "SUPPORTS" ModuleName
  207.                              "INCLUDES" "{" Groups "}"
  208.                              VariationPart
  209.  
  210.            ModuleName ::=    identifier ModuleIdentifier
  211.  
  212.            ModuleIdentifier ::=
  213.                              value (moduleID OBJECT IDENTIFIER)
  214.                            | empty
  215.  
  216.            Groups ::=        Group
  217.                            | Groups "," Group
  218.  
  219.            Group ::=         value(group OBJECT IDENTIFIER)
  220.  
  221.            VariationPart ::= Variations
  222.                            | empty
  223.  
  224.  
  225.  
  226. McCloghrie & Rose                                               [Page 4]
  227.  
  228. RFC 1303         Convention for Describing SNMP Agents     February 1992
  229.  
  230.  
  231.            Variations ::=    Variation
  232.                            | Variations Variation
  233.  
  234.            Variation ::=     "VARIATION" value(object ObjectName)
  235.                              Syntax WriteSyntax Access
  236.                              Creation DefaultValue
  237.                              "DESCRIPTION"
  238.                                  value(limitext DisplayString)
  239.  
  240.            -- must be a refinement for object's SYNTAX
  241.            Syntax ::=        "SYNTAX" type(SYNTAX)
  242.                            | empty
  243.  
  244.            -- must be a refinement for object's SYNTAX
  245.            WriteSyntax ::=   "WRITE-SYNTAX" type(WriteSYNTAX)
  246.                            | empty
  247.  
  248.            Access ::=        "ACCESS" AccessValue
  249.                            | empty
  250.  
  251.            AccessValue ::=   "read-only"
  252.                            | "read-write"
  253.                            | "write-only"
  254.                            | "not-accessible"
  255.  
  256.            Creation ::=      "CREATION-REQUIRES" "{" Cells "}"
  257.  
  258.            Cells ::=         Cell
  259.                            | Cells "," Cell
  260.  
  261.            Cell ::=          value(cell ObjectName)
  262.  
  263.            DefaultValue ::=  "DEFVAL"
  264.                              "{" value (defval ObjectSyntax) "}"
  265.                            | empty
  266.  
  267.        END
  268.  
  269.    END
  270.  
  271. 3.2.  Mapping of the MODULE-CONFORMANCE macro
  272.  
  273.    It should be noted that the expansion of the MODULE-CONFORMANCE macro
  274.    is something which conceptually happens during implementation and not
  275.    during run-time.
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. McCloghrie & Rose                                               [Page 5]
  283.  
  284. RFC 1303         Convention for Describing SNMP Agents     February 1992
  285.  
  286.  
  287. 3.2.1.  Mapping of the LAST-UPDATED clause
  288.  
  289.    The LAST-UPDATED clause, which must be present, contains the date and
  290.    time that this definition was last edited.
  291.  
  292. 3.2.2.  Mapping of the PRODUCT-RELEASE clause
  293.  
  294.    The PRODUCT-RELEASE clause, which must be present, contains a textual
  295.    description of the product release which includes this agent.
  296.  
  297. 3.2.3.  Mapping of the DESCRIPTION clause
  298.  
  299.    The DESCRIPTION clause, which must be present, contains a textual
  300.    description of this agent.
  301.  
  302. 3.2.4.  Mapping of the SUPPORTS clause
  303.  
  304.    The SUPPORTS clause, which need not be present, is repeatedly used to
  305.    name each MIB module for which the agent claims a complete or partial
  306.    implementation.  Each MIB module is named by its module name, and
  307.    optionally, by its associated OBJECT IDENTIFIER as well.  (Note that
  308.    only a few MIB modules have had OBJECT IDENTIFIERs assigned to them.)
  309.  
  310. 3.2.4.1.  Mapping of the INCLUDES clause
  311.  
  312.    The INCLUDES clause, which must be present for each use of the
  313.    SUPPORTS clause, is used to name each MIB group associated with the
  314.    SUPPORT clause, which the agent claims to implement.
  315.  
  316. 3.2.4.2.  Mapping of the VARIATION clause
  317.  
  318.    The VARIATION clause, which need not be present, is repeatedly used
  319.    to name each MIB object which the agent implements in some variant or
  320.    refined fashion.
  321.  
  322. 3.2.4.2.1.  Mapping of the SYNTAX clause
  323.  
  324.    The SYNTAX clause, which need not be present, is used to provide a
  325.    refined SYNTAX for the object named in the correspondent VARIATION
  326.    clause.  Note that if this clause and a WRITE-SYNTAX clause are both
  327.    present, then this clause only applies when instances of the object
  328.    named in the correspondent VARIATION clause are read.
  329.  
  330.    Consult Section 3.3 for more information on refined syntax.
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. McCloghrie & Rose                                               [Page 6]
  339.  
  340. RFC 1303         Convention for Describing SNMP Agents     February 1992
  341.  
  342.  
  343. 3.2.4.2.2.  Mapping of the WRITE-SYNTAX clause
  344.  
  345.    The WRITE-SYNTAX clause, which need not be present, is used to
  346.    provide a refined SYNTAX for the object named in the correspondent
  347.    VARIATION clause when instances of that object are written.
  348.  
  349.    Consult Section 3.3 for more information on refined syntax.
  350.  
  351. 3.2.4.2.3.  Mapping of the ACCESS clause
  352.  
  353.    The ACCESS clause, which need not be present, is used to provide a
  354.    refined ACCESS for the object named in the correspondent VARIATION
  355.    clause.
  356.  
  357. 3.2.4.2.4.  Mapping of the CREATION-REQUIRES clause
  358.  
  359.    The CREATION-REQUIRES clause, which need not be present, is used to
  360.    name the columnar objects of a conceptual row to which values must be
  361.    explicitly assigned, by a SNMP Set operation, before the agent will
  362.    create new instances of objects in that row.  This clause must not be
  363.    present unless the object named in the correspondent VARIATION clause
  364.    is a conceptual row, i.e., has a syntax which resolves to a SEQUENCE
  365.    containing columnar objects.  The objects named in the value of this
  366.    clause usually will refer to columnar objects in that row.  However,
  367.    objects unrelated to the conceptual row may also be specified.
  368.  
  369.    The absence of this clause for a particular conceptual row indicates
  370.    that the agent does not support the creation, via SNMP operations, of
  371.    new object instances in that row.
  372.  
  373. 3.2.4.2.5.  Mapping of the DEFVAL clause
  374.  
  375.    The DEFVAL clause, which need not be present, is used to provide a
  376.    refined DEFVAL value for the object named in the correspondent
  377.    VARIATION clause.  The semantics of this value are identical to those
  378.    of the OBJECT-TYPE macro's DEFVAL clause [2].
  379.  
  380. 3.2.4.2.6.  Mapping of the DESCRIPTION clause
  381.  
  382.    The DESCRIPTION clause, which must be present for each use of the
  383.    VARIATION clause, contains a textual description of the variant or
  384.    refined implementation.
  385.  
  386. 3.3.  Refined Syntax
  387.  
  388.    The SYNTAX and WRITE-SYNTAX clauses allow an object's Syntax to be
  389.    refined.  However, not all refinements of syntax are appropriate.  In
  390.    particular,
  391.  
  392.  
  393.  
  394. McCloghrie & Rose                                               [Page 7]
  395.  
  396. RFC 1303         Convention for Describing SNMP Agents     February 1992
  397.  
  398.  
  399.    (1)  the object's primitive or application type (as defined in
  400.         the SMI [1]) must not be changed;
  401.  
  402.    (2)  an object defined with an SMI type of OBJECT IDENTIFIER,
  403.         IpAddress, Counter, or TimeTicks cannot be refined; and,
  404.  
  405.    (3)  an object defined to have a specific set of values (e.g.,
  406.         an INTEGER with named values) cannot have additional
  407.         values defined for it.
  408.  
  409. 3.4.  Usage Example
  410.  
  411.    Consider how one might document the 4BSD/ISODE "Secure" SNMP
  412.    agent:
  413.  
  414.    FourBSD-ISODE   DEFINITIONS ::= BEGIN
  415.  
  416.    IMPORTS
  417.        MODULE-CONFORMANCE
  418.            FROM RFC-1303
  419.        -- everything --
  420.            FROM RFCxxxx-MIB
  421.        -- everything --
  422.            FROM RFC1213-MIB
  423.        -- everything --
  424.            FROM UNIX-MIB
  425.        -- everything --
  426.            FROM EVAL-MIB;
  427.  
  428.    fourBSD-isode-support MODULE-CONFORMANCE
  429.        LAST-UPDATED        "9201252354Z"
  430.        PRODUCT-RELEASE     "ISODE 7.0 + 'Secure' SNMP
  431.                             upgrade for SunOS 4.1"
  432.        DESCRIPTION         "4BSD/ISODE 'Secure' SNMP"
  433.  
  434.        SUPPORTS            RFCxxxx-MIB -- SNMP Party MIB --
  435.            INCLUDES        { partyPublic, partyPrivate }
  436.  
  437.        SUPPORTS            RFC1213-MIB
  438.            INCLUDES        { system, interfaces, at, ip, icmp,
  439.                              tcp, udp, snmp }
  440.  
  441.            VARIATION       atEntry
  442.                CREATION-REQUIRES { atPhysAddress }
  443.                DESCRIPTION "Address mappings on 4BSD require
  444.                             both protocol and media addresses"
  445.  
  446.            VARIATION       ifAdminStatus
  447.  
  448.  
  449.  
  450. McCloghrie & Rose                                               [Page 8]
  451.  
  452. RFC 1303         Convention for Describing SNMP Agents     February 1992
  453.  
  454.  
  455.                SYNTAX      INTEGER { up(1), down(2) }
  456.                DESCRIPTION "Unable to set test mode on 4BSD"
  457.  
  458.            VARIATION       ifOperStatus
  459.                SYNTAX      INTEGER { up(1), down(2) }
  460.                DESCRIPTION "Information limited on 4BSD"
  461.  
  462.            VARIATION       ipDefaultTTL
  463.                SYNTAX      INTEGER { maxttl(255) }
  464.                DESCRIPTION "Hard-wired on 4BSD"
  465.  
  466.            VARIATION       ipInAddrErrors
  467.                ACCESS      not-accessible
  468.                DESCRIPTION "Information not available on 4BSD"
  469.  
  470.            VARIATION       ipInDiscards
  471.                ACCESS      not-accessible
  472.                DESCRIPTION "Information not available on 4BSD"
  473.  
  474.            VARIATION       ipRouteEntry
  475.                CREATION-REQUIRES { ipRouteNextHop }
  476.                DESCRIPTION "Routes on 4BSD require both
  477.                             destination and next-hop"
  478.  
  479.            VARIATION       ipRouteType
  480.                SYNTAX       INTEGER { direct(3), indirect(4) }
  481.                WRITE-SYNTAX INTEGER { invalid(2), direct(3),
  482.                                       indirect(4) }
  483.                DESCRIPTION "Information limited on 4BSD"
  484.  
  485.            VARIATION       ipRouteProto
  486.                SYNTAX      INTEGER { other(1), icmp (4) }
  487.                DESCRIPTION "Information limited on 4BSD"
  488.  
  489.            VARIATION       ipRouteAge
  490.                ACCESS      not-accessible
  491.                DESCRIPTION "Information not available on 4BSD"
  492.  
  493.            VARIATION       ipNetToMediaEntry
  494.                CREATION-REQUIRES { ipNetToMediaPhysAddress }
  495.                DESCRIPTION "Address mappings on 4BSD require
  496.                             both protocol and media addresses"
  497.  
  498.            VARIATION       ipNetToMediaType
  499.                SYNTAX       INTEGER { dynamic(3), static(4) }
  500.                WRITE-SYNTAX INTEGER { invalid(2), dynamic(3),
  501.                                       static(4) }
  502.                DESCRIPTION "Information limited on 4BSD"
  503.  
  504.  
  505.  
  506. McCloghrie & Rose                                               [Page 9]
  507.  
  508. RFC 1303         Convention for Describing SNMP Agents     February 1992
  509.  
  510.  
  511.            VARIATION       tcpConnState
  512.                ACCESS      read-only
  513.                DESCRIPTION "Unable to set this on 4BSD"
  514.  
  515.            VARIATION       tcpInErrs
  516.                ACCESS      not-accessible
  517.                DESCRIPTION "Information not available on 4BSD"
  518.  
  519.            VARIATION       tcpOutRsts
  520.                ACCESS      not-accessible
  521.                DESCRIPTION "Information not available on 4BSD"
  522.  
  523.        SUPPORTS            UNIX-MIB
  524.            INCLUDES        { agents, mbuf, netstat }
  525.  
  526.        SUPPORTS            EVAL-MIB
  527.            INCLUDES        { functions, expressions }
  528.  
  529.        ::= { fourBSD-isode 6 6 }
  530.  
  531.    END
  532.  
  533.    According to this invocation, an agent with a sysObjectID of
  534.  
  535.         { fourBSD-isode 6 6 }
  536.  
  537.    supports four MIB modules.
  538.  
  539.    From the SNMP Party MIB, all the objects contained in the partyPublic
  540.    and partyPrivate groups are supported, without variation.
  541.  
  542.    From MIB-II, all groups except the egp group are supported.  However,
  543.    the objects
  544.  
  545.         ipInAddrErrors
  546.         ipInDiscards
  547.         ipRouteAge
  548.         tcpInErrs
  549.         tcpOutRsts
  550.  
  551.    are not available, whilst the objects
  552.  
  553.         ifAdminStatus
  554.         ifOperStatus
  555.         ipDefaultTTL
  556.         ipRouteType
  557.         ipRouteProto
  558.         ipNetToMediaType
  559.  
  560.  
  561.  
  562. McCloghrie & Rose                                              [Page 10]
  563.  
  564. RFC 1303         Convention for Describing SNMP Agents     February 1992
  565.  
  566.  
  567.    have a restricted syntax, and the object
  568.  
  569.         tcpConnState
  570.  
  571.    is available only for reading.  Note that in the case of the objects
  572.  
  573.         ipRouteType
  574.         ipNetToMediaType
  575.  
  576.    the set of values which may be read is different than the set of
  577.    values which may be written.  Finally, when creating a new row in the
  578.    atTable, the set-request must create an instance of atPhysAddress.
  579.    Similarly, when creating a new row in the ipRouteTable, the set-
  580.    request must create an instance of ipRouteNextHop.  Similarly, when
  581.    creating a new row in the ipNetToMediaTable, the set-request must
  582.    create an instance of ipNetToMediaPhysAddress.
  583.  
  584.    From the UNIX-MIB, all the objects contained in the agents, mbuf, and
  585.    netstat groups are supported, without variation.
  586.  
  587.    From the EVAL-MIB, all the objects contained in the functions and
  588.    expressions groups are supported, without variation.
  589.  
  590. 4.  Acknowledgements
  591.  
  592.    The authors gratefully acknowledge the comments of Mark van der Pol
  593.    of Hughes LAN Systems, and David T. Perkins of SynOptics
  594.    Communications.
  595.  
  596. 5.  References
  597.  
  598.    [1]  Rose M., and K. McCloghrie, "Structure and Identification of
  599.         Management Information for TCP/IP-based internets", RFC 1155,
  600.         Performance Systems International, Hughes LAN Systems, May 1990.
  601.  
  602.    [2]  Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
  603.         RFC 1212, Performance Systems International, Hughes LAN Systems,
  604.         March 1991.
  605.  
  606.    [3]  McCloghrie K., and M. Rose, Editors, "Management Information
  607.         Base forNetwork Management of TCP/IP-based internets", RFC 1213,
  608.         Performance Systems International, March 1991.
  609.  
  610.    [4]  Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
  611.         Network Management Protocol (SNMP), RFC 1157, SNMP Research,
  612.         Performance Systems International, Performance Systems
  613.         International, MIT Laboratory for Computer Science, May 1990.
  614.  
  615.  
  616.  
  617.  
  618. McCloghrie & Rose                                              [Page 11]
  619.  
  620. RFC 1303         Convention for Describing SNMP Agents     February 1992
  621.  
  622.  
  623.    [5]  Information processing systems - Open Systems Interconnection -
  624.         Specification of Abstract Syntax Notation One (ASN.1),
  625.         International Organization for Standardization, International
  626.         Standard 8824, December 1987.
  627.  
  628.    [6]  Rose, M., "SNMP MUX Protocol and MIB", RFC 1227, Performance
  629.         Systems International, May 1991.
  630.  
  631. 6.  Security Considerations
  632.  
  633.    Security issues are not discussed in this memo.
  634.  
  635. 7.  Authors' Addresses
  636.  
  637.    Keith McCloghrie
  638.    Hughes LAN Systems
  639.    1225 Charleston Road
  640.    Mountain View, CA 94043
  641.  
  642.    Phone: (415) 966-7934
  643.    EMail: kzm@hls.com
  644.  
  645.  
  646.    Marshall T. Rose
  647.    Dover Beach Consulting, Inc.
  648.    420 Whisman Court
  649.    Mountain View, CA  94043-2112
  650.  
  651.    Phone: (415) 968-1052
  652.    EMail: mrose@dbc.mtview.ca.us
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. McCloghrie & Rose                                              [Page 12]
  675.