[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 RFC 1229

          Internet draft     Interface MIB Extensions       October 1990






                     Extensions to the Generic-Interface MIB

                                 15 October 1990




                                 Keith McCloghrie
                             Hughes LAN Systems, Inc.
                                   kzm@hls.com






          1.  Status of this Memo

          This draft document will be submitted to the RFC editor as an
          experimental extension to the SNMP MIB.  Distribution of this
          memo is unlimited.  Please send comments to the author.


          2.  Abstract

          This memo defines an experimental portion of the Management
          Information Base (MIB) for use with network management
          protocols in TCP/IP-based internets. In particular, it defines
          managed object types as experimental extensions to the generic
          interfaces structure of MIB-II.

          This memo does not specify a standard for the Internet
          community.  However, after experimentation, if sufficient
          consensus is reached in the Internet community, then a
          subsequent revision of this document may be incorporated into
          the Internet-standard MIB.










          McCloghrie                                            [Page 1]

          Internet draft     Interface MIB Extensions       October 1990


          3.  Historical Perspective

          As reported in RFC 1052, IAB Recommendations for the
          Development of Internet Network Management Standards [1], a
          two-prong strategy for network management of TCP/IP-based
          internets was undertaken.  In the short-term, the Simple
          Network Management Protocol (SNMP), defined in RFC 1067, was
          to be used to manage nodes in the Internet community.  In the
          long-term, the use of the OSI network management framework was
          to be examined.  Two documents were produced to define the
          management information: RFC 1065, which defined the Structure
          of Management Information (SMI), and RFC 1066, which defined
          the Management Information Base (MIB).  Both of these
          documents were designed so as to be compatible with both the
          SNMP and the OSI network management framework.

          This strategy was quite successful in the short-term:
          Internet-based network management technology was fielded, by
          both the research and commercial communities, within a few
          months.  As a result of this, portions of the Internet
          community became network manageable in a timely fashion.

          As reported in RFC 1109, Report of the Second Ad Hoc Network
          Management Review Group [2], the requirements of the SNMP and
          the OSI network management frameworks were more different than
          anticipated.  As such, the requirement for compatibility
          between the SMI/MIB and both frameworks was suspended.  This
          action permitted the operational network management framework,
          based on the SNMP, to respond to new operational needs in the
          Internet community by producing MIB-II [6].

          In May of 1990, the core documents were elevated to Standard
          Protocols with Recommended status.  As such, the Internet-
          standard network management framework consists of: Structure
          and Identification of Management Information for TCP/IP-based
          internets, RFC 1155 [3], which describes how managed objects
          contained in the MIB are defined; Management Information Base
          for Network Management of TCP/IP-based internets, which
          describes the managed objects contained in the MIB, RFC 1156
          [4]; and, the Simple Network Management Protocol, RFC 1157
          [5], which defines the protocol used to manage these objects.

          Consistent with the IAB directive to produce simple, workable
          systems in the short-term, the list of managed objects defined
          in the Internet-standard MIB was derived by taking only those





          McCloghrie                                            [Page 2]

          Internet draft     Interface MIB Extensions       October 1990


          elements which are considered essential.  However, the SMI
          defined three extensibility mechanisms: one, the addition of
          new standard objects through the definitions of new versions
          of the MIB; two, the addition of widely-available but non-
          standard objects through the experimental subtree; and three,
          the addition of private objects through the enterprises
          subtree.  Such additional objects can not only be used for
          vendor-specific elements, but also for experimentation as
          required to further the knowledge of which other objects are
          essential.

          This memo defines extensions to the MIB using the second
          method.  It contains definitions of managed objects used as
          experimental extensions to the generic interfaces structure of
          MIB-II.  After experimentation, if sufficient consensus is
          reached in the Internet community, then a subsequent revision
          of this memo may be placed in the Internet-standard MIB.

































          McCloghrie                                            [Page 3]

          Internet draft     Interface MIB Extensions       October 1990


          4.  Objects

          Managed objects are accessed via a virtual information store,
          termed the Management Information Base or MIB.  Objects in the
          MIB are defined using the subset of Abstract Syntax Notation
          One (ASN.1) [7] defined in the SMI.  In particular, each
          object has a name, a syntax, and an encoding.  The name is an
          object identifier, an administratively assigned name, which
          specifies an object type.  The object type together with an
          object instance serves to uniquely identify a specific
          instantiation of the object.  For human convenience, we often
          use a textual string, termed the OBJECT DESCRIPTOR, to also
          refer to the object type.

          The syntax of an object type defines the abstract data
          structure corresponding to that object type.  The ASN.1
          language is used for this purpose.  However, the SMI [3]
          purposely restricts the ASN.1 constructs which may be used.
          These restrictions are explicitly made for simplicity.

          The encoding of an object type is simply how that object type
          is represented using the object type's syntax.  Implicitly
          tied to the notion of an object type's syntax and encoding is
          how the object type is represented when being transmitted on
          the network.

          The SMI specifies the use of the basic encoding rules of ASN.1
          [8], subject to the additional requirements imposed by the
          SNMP.


          4.1.  Format of Definitions

          The next section contains the specification of all object
          types specified in this section of the MIB.  The object types
          are defined using the conventions specified in the SMI, as
          amended by the extensions specified in [10].













          McCloghrie                                            [Page 4]

          Internet draft     Interface MIB Extensions       October 1990


          5.  Overview

          The Internet Standard MIB [4,6] contains a group of management
          objects pertaining to a network device's generic network
          interface(s).  These objects are generic in the sense that
          they apply to all network interfaces, irrespective of the type
          of communication media and protocols used on such interfaces.
          This has proved to be necessary but not sufficient; there are
          efforts underway to define additional MIB objects which are
          specific to particular media and lower-level (subnetwork-layer
          and below) protocol stacks.

          However, some of these efforts have identified objects which
          are required (or at least useful), but are not specific to the
          interface-type on which the effort is focusing.  In order to
          avoid redundancy, it is better that such objects be defined as
          extensions to the generic interface group, rather than defined
          in multiple specific-interface-type MIBs.

          This memo defines the resultant extensions to the generic
          interface group.  These extensions are spread over three
          tables: the generic Interface Extension table, the generic
          Interface Test table, and the generic Receive Address table.


          5.1.  Generic Interface Extension Table

          This table consists of new objects applicable to all types of
          subnetwork interface.


          5.2.  Generic Interface Test Table

          This section defines objects which allow a network manager to
          instruct an agent to test an interface for various faults. A
          few common types of tests are defined in this document but
          most will be defined elsewhere dependent on the particular
          type of interface.  After invoking a test, the object
          ifExtnsTestResult can be read to determine the outcome.  If an
          agent can not perform the test, ifExtnsTestResult is set to so
          indicate. The object ifExtnsTestCode can be used to provide
          further test-specific or interface-specific (or even
          enterprise-specific) information concerning the outcome of the
          test.  Only one test can be in progress on each interface at
          any one time.  If one test is in progress when another test is





          McCloghrie                                            [Page 5]

          Internet draft     Interface MIB Extensions       October 1990


          invoked, the second test is rejected.  Some agents may reject
          a test when a prior test is active on another interface.

          When a test is invoked, the authentication service user
          identity (as defined in [9]) originating the request is saved
          by the agent, in the objects ifExtnsTestUser and
          ifExtnsTestCommunity.  These values remain set until the next
          test is invoked.  In the (rare) event that the invocation of
          tests by two network managers were to overlap, then there is a
          possibility that the first test's results might be overwritten
          by the second test's results prior to the first results being
          read.  This unlikely circumstance can be detected by a network
          manager retrieving the test-invoking authentication service
          user identity at the same time as the test results are
          retrieved, and ensuring that the results are for the desired
          user identity.

          In general, a Management station must not retransmit a request
          to invoke a test for which it does not receive a response;
          instead, it properly inspects an agent's MIB to determine if
          the invocation was successful.  Only if the invocation was
          unsuccessful, is the invocation request retransmitted.

          Some tests may require the interface to be taken off-line in
          order to execute them, or may even require the agent to reboot
          after completion of the test.  In these circumstances,
          communication with the management station invoking the test
          may be lost until after completion of the test.  The agent
          should make every effort to transmit a response to the request
          which invoked the test prior to losing communication.  When
          the agent is restored to normal service, the results of the
          test are properly made available in the appropriate objects.
          An agent which cannot, perhaps due to resource constraints,
          retain even the minimum amount of information in these
          situations, must reject any test which can cause one of these
          situations to occur.


          5.3.  Generic Receive Address Table

          This table of objects contains objects relating to an
          interface's support for receiving packets/frames at more than
          one address on the same interface.







          McCloghrie                                            [Page 6]

          Internet draft     Interface MIB Extensions       October 1990


          6.  Definitions


          RFCxxxx-MIB DEFINITIONS ::= BEGIN


          --        Extensions to MIB-II's Generic Interface Table

          IMPORTS
                  experimental, Counter FROM RFC1155-SMI
                  DisplayString         FROM RFC1158-MIB
                  PhysAddress           FROM RFC-mmmm-MIB-II
                  OBJECT-TYPE           FROM RFC-oooo;


          --  This MIB Module uses the extended OBJECT-TYPE macro as
          --  defined in [10]


          ifExtensions  OBJECT IDENTIFIER ::= { experimental 6 }



          --   Generic Interface Extension Table
          --
          --  This group of objects is mandatory for all types of
          --  subnetwork interface.

          ifExtnsTable  OBJECT-TYPE
                        SYNTAX SEQUENCE OF IfExtnsEntry
                        ACCESS not-accessible
                        STATUS mandatory
                        DESCRIPTION
                               "A list of interfaces extension entries.
                                The number of entries is given by the value
                                of ifNumber, defined in [4,6]."
                        ::= { ifExtensions 1 }

          ifExtnsEntry  OBJECT-TYPE
                        SYNTAX IfExtnsEntry
                        ACCESS not-accessible
                        STATUS mandatory
                        DESCRIPTION
                               "An extension to the interfaces entry,
                                defined in [4,6], containing additional





          McCloghrie                                            [Page 7]

          Internet draft     Interface MIB Extensions       October 1990


                                objects at the subnetwork layer and below
                                for a particular interface."
                        INDEX  { ifExtnsIfIndex }
                        ::= { ifExtnsTable 1 }

          IfExtnsEntry ::= SEQUENCE {
                               ifExtnsIfIndex
                                       INTEGER,
                               ifExtnsChipSet
                                       OBJECT IDENTIFIER,
                               ifExtnsRevWare
                                       DisplayString,
                               ifExtnsMulticastsTransmittedOks
                                       Counter,
                               ifExtnsBroadcastsTransmittedOks
                                       Counter,
                               ifExtnsMulticastsReceivedOks
                                       Counter,
                               ifExtnsBroadcastsReceivedOks
                                       Counter,
                               ifExtnsPromiscuous
                                       INTEGER
                           }

          ifExtnsIfIndex  OBJECT-TYPE
                        SYNTAX INTEGER
                        ACCESS read-only
                        STATUS mandatory
                        DESCRIPTION
                               "The value of this object identifies the
                                interface for which this entry contains
                                extended management information.  The value
                                of this object for a particular interface
                                has the same value as the ifIndex object,
                                defined in [4,6], for the same interface."
                        ::= { ifExtnsEntry 1 }

          ifExtnsChipSet  OBJECT-TYPE
                        SYNTAX OBJECT IDENTIFIER
                        ACCESS read-only
                        STATUS mandatory
                        DESCRIPTION
                               "This object identifies the hardware chip
                                set being used in the interface.  The
                                assignment of OBJECT IDENTIFIERs to various





          McCloghrie                                            [Page 8]

          Internet draft     Interface MIB Extensions       October 1990


                                types of hardware chip sets is defined
                                elsewhere.  This document assigns only the
                                value: unknownChipSet for use if the chip
                                set in use is unknown.
                                    Note that unknownChipSet is a
                                syntactically valid object identifier, and
                                any conformant implementation of ASN.1 and
                                the BER must be able to generate and
                                recognize this value."
                        ::= { ifExtnsEntry 2 }

          --  for unknown hardware chip set
          unknownChipSet  OBJECT IDENTIFIER ::= { 0 0 }

          ifExtnsRevWare  OBJECT-TYPE
                        SYNTAX DisplayString (SIZE (0..255))
                        ACCESS read-only
                        STATUS mandatory
                        DESCRIPTION
                               "An arbitrary octet string that describes
                                the firmware version of this interface.
                                It is intended that this should be human
                                readable.  It must only contain ASCII
                                printable characters.  Typically this
                                will be the firmware version of the main
                                interface software."
                        ::= { ifExtnsEntry 3 }

          ifExtnsMulticastsTransmittedOks OBJECT-TYPE
                        SYNTAX Counter
                        ACCESS read-only
                        STATUS mandatory
                        DESCRIPTION
                               "The count of frames successfully
                                transmitted to a subnetwork or link-layer
                                multicast destination address other than a
                                broadcast address.  For a MAC layer protocol,
                                this includes both Group and Functional
                                addresses."
                        ::= { ifExtnsEntry 4 }

          ifExtnsBroadcastsTransmittedOks OBJECT-TYPE
                        SYNTAX Counter
                        ACCESS read-only
                        STATUS mandatory





          McCloghrie                                            [Page 9]

          Internet draft     Interface MIB Extensions       October 1990


                        DESCRIPTION
                               "The count of frames successfully
                                transmitted to a subnetwork or link-layer
                                broadcast addresses.  It does not include
                                frames sent to a multicast address."
                        ::= { ifExtnsEntry 5 }

          ifExtnsMulticastsReceivedOks OBJECT-TYPE
                        SYNTAX Counter
                        ACCESS read-only
                        STATUS mandatory
                        DESCRIPTION
                               "The count of frames successfully received
                                that are directed to an active subnetwork
                                or link-layer multicast address (for a MAC
                                layer protocol, this includes both Group and
                                Functional addresses). This does not include
                                frames directed to a broadcast address, nor
                                frames received with errors."
                        ::= { ifExtnsEntry 6 }

          ifExtnsBroadcastsReceivedOks OBJECT-TYPE
                        SYNTAX Counter
                        ACCESS read-only
                        STATUS mandatory
                        DESCRIPTION
                               "The count of frames successfully received
                                that are directed to a subnetwork or
                                link-layer broadcast address."
                        ::= { ifExtnsEntry 7 }

          ifExtnsPromiscuous  OBJECT-TYPE
                        SYNTAX INTEGER {
                                    true(1),
                                    false(2)
                               }
                        ACCESS read-only  -- Note: agent implementors are
                                          -- encouraged to extend this
                                          -- access to read-write if that
                                          -- makes sense in their agent.
                        STATUS mandatory
                        DESCRIPTION
                               "This object has a value of false(2) if
                                this interface only accepts packets/frames
                                that are addressed to this station. This





          McCloghrie                                           [Page 10]

          Internet draft     Interface MIB Extensions       October 1990


                                object has a value of true(1) when the
                                station accepts all packets/frames
                                transmitted on the media.  The value
                                true(1) is only legal on certain types of
                                media.  If legal, setting this object to a
                                value of true(1) may require the interface
                                to be reset before becoming effective."
                        ::= { ifExtnsEntry 8 }

          --
          --    Generic Interface Test Table
          --
          -- This group of objects is optional, but if the table is
          -- implemented, all objects in the table must be implemented.

          ifExtnsTestTable   OBJECT-TYPE
                        SYNTAX  SEQUENCE OF IfExtnsTestEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "This table contains one entry per
                                interface."
                        ::= { ifExtensions 2 }

          ifExtnsTestEntry OBJECT-TYPE
                        SYNTAX  IfExtnsTestEntry
                        ACCESS  not-accessible
                        STATUS  mandatory
                        DESCRIPTION
                                "An entry containing objects for
                                invoking tests on an interface."
                        INDEX   { ifExtnsTestIfIndex }
                        ::= { ifExtnsTestTable 1 }

          IfExtnsTestEntry ::= SEQUENCE {
                                   ifExtnsTestIfIndex
                                       INTEGER,
                                   ifExtnsTestUser
                                       OCTET STRING,
                                   ifExtnsTestCommunity
                                       OCTET STRING,
                                   ifExtnsTestType
                                       OBJECT IDENTIFIER,
                                   ifExtnsTestResult
                                       INTEGER,





          McCloghrie                                           [Page 11]

          Internet draft     Interface MIB Extensions       October 1990


                                   ifExtnsTestCode
                                       OBJECT IDENTIFIER
                               }

          ifExtnsTestUser  OBJECT-TYPE
                        SYNTAX  OCTET STRING
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                               "This object contains the name of the
                                authentication service user [9] who
                                originated the SNMP Message which invoked
                                the current or most recent test on this
                                interface.  If the authentication service
                                user is unknown or undefined, this value
                                contains the zero-length string."
                        ::= { ifExtnsTestEntry 1 }

          ifExtnsTestCommunity  OBJECT-TYPE
                        SYNTAX  OCTET STRING
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                               "This object contains the name of the
                                SNMP authentication community [9] which
                                was used to authenticate the SNMP Message
                                which invoked the current or most recent
                                test on this interface.  If the
                                authentication community is unknown or
                                undefined, this value contains the
                                zero-length string."
                        ::= { ifExtnsTestEntry 2 }

          ifExtnsTestIfIndex  OBJECT-TYPE
                        SYNTAX  INTEGER
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                               "The value of this object identifies the
                                interface for which this entry contains
                                information on interface tests.  The value
                                of this object for a particular interface
                                has the same value as the ifIndex object,
                                defined in [4,6], for the same interface."
                        ::= { ifExtnsTestEntry 3 }





          McCloghrie                                           [Page 12]

          Internet draft     Interface MIB Extensions       October 1990



          ifExtnsTestType  OBJECT-TYPE
                        SYNTAX  OBJECT IDENTIFIER
                        ACCESS  read-write
                        STATUS  mandatory
                        DESCRIPTION
                               "A control variable used to start and stop
                                operator-initiated interface tests.  If
                                the value noTest is written, then this
                                aborts any test in progress, or if no test
                                is in progress, acts as a no-operation.
                                If any other value is used, writing to
                                this object is only valid when no test is
                                currently in progress, in which case the
                                indicated test is initiated.
                                    Most OBJECT IDENTIFIER values assigned
                                to tests are defined elsewhere, in associ-
                                ation with specific types of interface.
                                However, this document does assign a value
                                for a full-duplex loopback test.  Also,
                                the subject identifier, noTest, is defined
                                here.
                                    Note that noTest is a syntactically
                                valid object identifier, and any conformant
                                implementation of ASN.1 and BER must be able
                                to generate and recognize this value.
                                    When read, this object always returns
                                the most recent value that ifExtnsTestType
                                was set to.  If it has not been set since
                                the last initialization of the network
                                management subsystem on the node, it returns
                                a value of noTest."
                        ::= { ifExtnsTestEntry 4 }

          --  abort Test in progress/ no Test in progress
          noTest OBJECT IDENTIFIER ::= { 0 0 }

          wellKnownTests OBJECT IDENTIFIER ::= { ifExtensions 4 }

          --  full-duplex loopback test
          testFullDuplexLoopBack OBJECT IDENTIFIER ::= { wellKnownTests 1 }

          ifExtnsTestResult  OBJECT-TYPE
                        SYNTAX  INTEGER {
                                    none(1),  -- no test yet requested





          McCloghrie                                           [Page 13]

          Internet draft     Interface MIB Extensions       October 1990


                                    success(2),
                                    inProgress(3),
                                    notSupported(4),
                                    unAbleToRun(5), -- due to state of system
                                    aborted(6),
                                    failed(7)
                                }
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                               "This object contains the result of the most
                                recently requested test, or the value
                                none(1) if no tests have been requested since
                                the last reset.  Note that this facility
                                provides no provision for saving the results
                                of one test when starting another, as could
                                be required if used by multiple managers
                                concurrently."
                        ::= { ifExtnsTestEntry 5 }

          ifExtnsTestCode  OBJECT-TYPE
                        SYNTAX  OBJECT IDENTIFIER
                        ACCESS  read-only
                        STATUS  mandatory
                        DESCRIPTION
                               "This object contains a code which contains
                                more specific information on the test result,
                                for example an error-code after a failed
                                test.  Error codes and other values this
                                object may take are specific to the type of
                                interface and/or test.  However, one subject
                                identifier, testCodeUnknown, is defined here
                                for use if no additional result code is
                                available.
                                    Note that testCodeUnknown is a
                                syntactically valid object identifier, and
                                any conformant implementation of ASN.1 and
                                the BER must be able to generate and
                                recognize this value."
                        ::= { ifExtnsTestEntry 6 }

          --  no additional result code available
          testCodeUnknown  OBJECT IDENTIFIER ::= { 0 0 }







          McCloghrie                                           [Page 14]

          Internet draft     Interface MIB Extensions       October 1990


          --   Generic Receive Address Table
          --
          -- This group of objects is mandatory for all types of
          -- interfaces which can receive packets/frames addressed to
          -- more than one address.

          ifExtnsRcvAddrTable  OBJECT-TYPE
                        SYNTAX SEQUENCE OF IfExtnsRcvAddrEntry
                        ACCESS not-accessible
                        STATUS mandatory
                        DESCRIPTION
                               "This table contains an entry for each
                                address (broadcast, multicast, or uni-cast)
                                for which the system will receive packets/
                                frames on a particular interface.  When an
                                interface is operating in promiscuous mode,
                                entries are only required for those
                                addresses for which the system would receive
                                frames were it not operating in promiscuous
                                mode."
                        ::= { ifExtensions 3 }

          ifExtnsRcvAddrEntry  OBJECT-TYPE
                        SYNTAX IfExtnsRcvAddrEntry
                        ACCESS not-accessible
                        STATUS mandatory
                        DESCRIPTION
                               "A list of objects identifying an address
                                for which the system will accept packets/
                                frames on a particular interface."
                        INDEX  { ifExtnsRcvAddrIfIndex, ifExtnsRcvAddress }
                        ::= { ifExtnsRcvAddrTable 1 }

          IfExtnsRcvAddrEntry ::= SEQUENCE {
                                      ifExtnsRcvAddrIfIndex
                                          INTEGER,
                                      ifExtnsRcvAddress
                                          PhysAddress,
                                      ifExtnsRcvAddrStatus
                                          INTEGER
                                  }

          ifExtnsRcvAddrIfIndex  OBJECT-TYPE
                        SYNTAX INTEGER
                        ACCESS read-only





          McCloghrie                                           [Page 15]

          Internet draft     Interface MIB Extensions       October 1990


                        STATUS mandatory
                        DESCRIPTION
                               "The value of ifIndex, defined in [4,6],
                                of an interface which recognizes this
                                entry's address."
                        ::= { ifExtnsRcvAddrEntry 1 }

          ifExtnsRcvAddress OBJECT-TYPE
                        SYNTAX PhysAddress
                        ACCESS read-only
                        STATUS mandatory
                        DESCRIPTION
                               "An address for which the system will
                                accept packets/frames on this entry's
                                interface."
                        ::= { ifExtnsRcvAddrEntry 2 }

          ifExtnsRcvAddrStatus OBJECT-TYPE
                        SYNTAX INTEGER {
                                   other(1),
                                   invalid(2),
                                   volatile(3),
                                   nonVolatile(4)
                               }
                        ACCESS read-write
                        STATUS mandatory
                        DESCRIPTION
                               "This object has the value nonVolatile(4)
                                for those entries in the table which are
                                valid and will not be deleted by the next
                                restart of the managed system.  Entries
                                having the value volatile(3) are valid
                                and exist, but have not been saved, so
                                that will not exist after the next
                                restart of the managed system.  Entries
                                having the value other(1) are valid and
                                exist but are not classified as to whether
                                they will continue to exist after the next
                                restart.  Entries having the value invalid(2)
                                are invalid and do not represent an address
                                for which an interface accepts frames.
                                    Setting an object instance to one of
                                the values other(1), volatile(3), or
                                nonVolatile(4) causes the corresponding
                                entry to exist or continue to exist, and





          McCloghrie                                           [Page 16]

          Internet draft     Interface MIB Extensions       October 1990


                                to take on the respective status as regards
                                the next restart of the managed system.
                                    Setting an object instance to the value
                                invalid(2) causes the corresponding entry
                                to become invalid or cease to exist.
                                    It is an implementation-specific matter
                                as to whether the agent removes an
                                invalidated entry from the table.
                                Accordingly, management stations must be
                                prepared to receive tabular information
                                from agents that corresponds to entries not
                                currently in use.  Proper interpretation of
                                such entries requires examination of the
                                relevant ifExtnsRcvAddrStatus object
                                instance."
                        DEFVAL  { volatile }
                        ::= { ifExtnsRcvAddrEntry 3 }

          END































          McCloghrie                                           [Page 17]

          Internet draft     Interface MIB Extensions       October 1990


          7.  Acknowledgements

          Most of the MIB objects defined in this document were
          originally proposed as a part of the IEEE 802.5 MIB, as
          prepared by:

               Eric B. Decker, cisco Systems, Inc., and
               Richard Fox, Synoptics Inc.

          In addition, the comments of the following individuals are
          acknowledged:

               James R. Davin, MIT-LCS,
               Stan Froyd, ACC,
               Frank Kastenholz, Racal Interlan
               Marshall T. Rose, PSI,
               Bob Stewart, Xyplex,
               David Waitzman, BBN,
               Wengyik Yeong, PSI,































          McCloghrie                                           [Page 18]

          Internet draft     Interface MIB Extensions       October 1990


          8.  References

          [1]  V. Cerf, IAB Recommendations for the Development of
               Internet Network Management Standards.  Internet Working
               Group Request for Comments 1052.  Network Information
               Center, SRI International, Menlo Park, California,
               (April, 1988).

          [2]  V. Cerf, Report of the Second Ad Hoc Network Management
               Review Group, Internet Working Group Request for Comments
               1109.  Network Information Center, SRI International,
               Menlo Park, California, (August, 1989).

          [3]  M.T. Rose and K. McCloghrie, Structure and Identification
               of Management Information for TCP/IP-based internets,
               Internet Working Group Request for Comments 1155.
               Network Information Center, SRI International, Menlo
               Park, California, (May, 1990).

          [4]  K. McCloghrie and M.T. Rose, Management Information Base
               for Network Management of TCP/IP-based internets,
               Internet Working Group Request for Comments 1156.
               Network Information Center, SRI International, Menlo
               Park, California, (May, 1990).

          [5]  J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
               Simple Network Management Protocol, Internet Working
               Group Request for Comments 1157.  Network Information
               Center, SRI International, Menlo Park, California, (May,
               1990).

          [6]  M.T. Rose (editor), Management Information Base for
               Network Management of TCP/IP-based internets, Internet
               Working Group Request for Comments 1158.  Network
               Information Center, SRI International, Menlo Park,
               California, (May, 1990).

          [7]  Information processing systems Open Systems
               Interconnection Specification of Abstract Syntax Notation
               One (ASN.1), International Organization for
               Standardization.  International Standard 8824, (December,
               1987).

          [8]  Information processing systems Open Systems
               Interconnection Specification of Basic Encoding Rules for





          McCloghrie                                           [Page 19]

          Internet draft     Interface MIB Extensions       October 1990


               Abstract Notation One (ASN.1), International Organization
               for Standardization.  International Standard 8825,
               (December, 1987).

          [9]  J.M. Galvin, K. McCloghrie, J.R. Davin, Authentication
               and Privacy in the SNMP, Internet Working Group, Request
               for Comments (in preparation), Network Information
               Center, SRI International, Menlo Park, California,
               (September, 1990).

          [10] M.T. Rose, K. McCloghrie (editors), Towards Concise MIB
               Definitions, Internet Draft, Internet Engineering Task
               Force, (September, 1990).





































          McCloghrie                                           [Page 20]

          Internet draft     Interface MIB Extensions       October 1990


          Table of Contents


          1 Status of this Memo ...................................    1
          2 Abstract ..............................................    1
          3 Historical Perspective ................................    2
          4 Objects ...............................................    4
          4.1 Format of Definitions ...............................    4
          5 Overview ..............................................    5
          5.1 Generic Interface Extension Table ...................    5
          5.2 Generic Interface Test Table ........................    5
          5.3 Generic Receive Address Table .......................    6
          6 Definitions ...........................................    7
          7 Acknowledgements ......................................   18
          8 References ............................................   19



































          McCloghrie                                           [Page 21]
------- End of Forwarded Message


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/