doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc1398.txt b/doc/rfc/rfc1398.txt
new file mode 100644
index 0000000..5e38d97
--- /dev/null
+++ b/doc/rfc/rfc1398.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                      F. Kastenholz
+Request for Comments: 1398                            FTP Software, Inc.
+Obsoletes: 1284                                             January 1993
+
+
+                   Definitions of Managed Objects for
+                   the Ethernet-like Interface Types
+
+Status of this Memo
+
+   This RFC specifies an IAB standards track protocol for the Internet
+   community, and requests discussion and suggestions for improvements.
+   Please refer to the current edition of the "IAB Official Protocol
+   Standards" for the standardization state and status of this protocol.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This memo defines a portion of the Management Information Base (MIB)
+   for use with network management protocols in TCP/IP-based internets.
+   In particular, it defines objects for managing ethernet-like objects.
+
+Table of Contents
+
+   1. The Network Management Framework ......................    1
+   2. Objects ...............................................    2
+   2.1 Format of Definitions ................................    2
+   3. Overview ..............................................    3
+   4. Definitions ...........................................    4
+   4.1 The Ethernet-like Statistics Group ...................    4
+   4.2 The Ethernet-like Collision Statistics Group .........   11
+   4.3 802.3 Tests ..........................................   12
+   4.4 802.3 Hardware Chipsets ..............................   14
+   5. Change Log ............................................   14
+   6. Acknowledgements ......................................   16
+   7. References ............................................   16
+   8. Security Considerations ...............................   17
+   9. Author's Address ......................................   17
+
+1.  The Network Management Framework
+
+   The Internet-standard Network Management Framework consists of three
+   components.  They are:
+
+      STD 16/RFC 1155 [3] which defines the SMI, the mechanisms used for
+      describing and naming objects for the purpose of management.  STD
+      16/RFC 1212 [13] defines a more concise description mechanism,
+      which is wholly consistent with the SMI.
+
+
+
+Kastenholz                                                      [Page 1]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+      RFC 1156 [4] which defines MIB-I, the core set of managed objects
+      for the Internet suite of protocols.  STD 17/RFC 1213 [6] defines
+      MIB-II, an evolution of MIB-I based on implementation experience
+      and new operational requirements.
+
+      STD 15/RFC 1157 [5] which defines the SNMP, the protocol used for
+      network access to managed objects.
+
+   The Framework permits new objects to be defined for the purpose of
+   experimentation and evaluation.
+
+2.  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.
+
+2.1.  Format of Definitions
+
+   Section 4 contains contains the specification of all object types
+   contained in this MIB module.  The object types are defined using the
+   conventions defined in the SMI, as amended by the extensions
+   specified in [13].
+
+
+
+
+
+
+
+Kastenholz                                                      [Page 2]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+3.  Overview
+
+   Instances of these object types represent attributes of an interface
+   to an ethernet-like communications medium.  At present, ethernet-like
+   media are identified by three values of the ifType object in the
+   Internet-standard MIB:
+
+          ethernet-csmacd(6)
+          iso88023-csmacd(7)
+          starLan(11)
+
+   For these interfaces, the value of the ifSpecific variable in the
+   MIB-II [6] has the OBJECT IDENTIFIER value:
+
+          dot3    OBJECT IDENTIFER ::= { transmission 7 }
+
+   The definitions presented here are based on the IEEE 802.3 Layer
+   Management Specification [9], as originally interpreted by Frank
+   Kastenholz of Interlan in [10].  Implementors of these MIB objects
+   should note that the IEEE document explicitly describes (in the form
+   of Pascal pseudocode) when, where, and how various MAC attributes are
+   measured.  The IEEE document also describes the effects of MAC
+   actions that may be invoked by manipulating instances of the MIB
+   objects defined here.
+
+   To the extent that some of the attributes defined in [9] are
+   represented by previously defined objects in the Internet- standard
+   MIB or in the Generic Interface Extensions MIB [11], such attributes
+   are not redundantly represented by objects defined in this memo.
+   Among the attributes represented by objects defined in other memos
+   are the number of octets transmitted or received on a particular
+   interface, the number of frames transmitted or received on a
+   particular interface, the promiscuous status of an interface, the MAC
+   address of an interface, and multicast information associated with an
+   interface.
+
+   The relationship between an ethernet-like interface and an interface
+   in the context of the Internet-standard MIB is one-to-one.  As such,
+   the value of an ifIndex object instance can be directly used to
+   identify corresponding instances of the objects defined herein.
+
+
+
+
+
+
+
+
+
+
+
+Kastenholz                                                      [Page 3]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+4.  Definitions
+
+          RFC1398-MIB DEFINITIONS ::= BEGIN
+
+
+               IMPORTS
+                    Counter, Gauge
+                         FROM RFC1155-SMI
+                    transmission
+                         FROM RFC1213-MIB
+                    OBJECT-TYPE
+                         FROM RFC-1212;
+
+          --  This MIB module uses the extended OBJECT-TYPE macro as
+          --  defined in RFC-1212.
+
+          --  this is the MIB module for ethernet-like objects
+
+          dot3    OBJECT IDENTIFIER ::= { transmission 7 }
+
+          -- { dot3 1 } is obsolete and has been deleted.
+
+4.1.  The Ethernet-like Statistics Group
+
+
+          -- the Ethernet-like Statistics group
+
+          -- Implementation of this group is mandatory
+
+          dot3StatsTable   OBJECT-TYPE
+               SYNTAX    SEQUENCE OF Dot3StatsEntry
+               ACCESS    not-accessible
+               STATUS    mandatory
+               DESCRIPTION
+                         "Statistics for a collection of ethernet-like
+                         interfaces attached to a particular system."
+               ::= { dot3 2 }
+
+
+          dot3StatsEntry   OBJECT-TYPE
+               SYNTAX    Dot3StatsEntry
+               ACCESS    not-accessible
+               STATUS    mandatory
+               DESCRIPTION
+                         "Statistics for a particular interface to an
+                         ethernet-like medium."
+               INDEX     { dot3StatsIndex }
+               ::= { dot3StatsTable 1 }
+
+
+
+Kastenholz                                                      [Page 4]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+          Dot3StatsEntry ::= SEQUENCE {
+               dot3StatsIndex
+                    INTEGER,
+               dot3StatsAlignmentErrors
+                    Counter,
+               dot3StatsFCSErrors
+                    Counter,
+               dot3StatsSingleCollisionFrames
+                    Counter,
+               dot3StatsMultipleCollisionFrames
+                    Counter,
+               dot3StatsSQETestErrors
+                    Counter,
+               dot3StatsDeferredTransmissions
+                    Counter,
+               dot3StatsLateCollisions
+                    Counter,
+               dot3StatsExcessiveCollisions
+                    Counter,
+               dot3StatsInternalMacTransmitErrors
+                    Counter,
+               dot3StatsCarrierSenseErrors
+                    Counter,
+               dot3StatsFrameTooLongs
+                    Counter,
+               dot3StatsInternalMacReceiveErrors
+                    Counter
+          }
+
+          dot3StatsIndex   OBJECT-TYPE
+               SYNTAX    INTEGER
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "An index value that uniquely identifies an
+                         interface to an ethernet-like medium.  The
+                         interface identified by a particular value of
+                         this index is the same interface as identified
+                         by the same value of ifIndex."
+               ::= { dot3StatsEntry 1 }
+
+
+          dot3StatsAlignmentErrors   OBJECT-TYPE
+               SYNTAX    Counter
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "A count of frames received on a particular
+
+
+
+Kastenholz                                                      [Page 5]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+                         interface that are not an integral number of
+                         octets in length and do not pass the FCS check.
+
+                         The count represented by an instance of this
+                         object is incremented when the alignmentError
+                         status is returned by the MAC service to the
+                         LLC (or other MAC user). Received frames for
+                         which multiple error conditions obtain are,
+                         according to the conventions of IEEE 802.3
+                         Layer Management, counted exclusively according
+                         to the error status presented to the LLC."
+               REFERENCE
+                         "IEEE 802.3 Layer Management"
+               ::= { dot3StatsEntry 2 }
+
+
+          dot3StatsFCSErrors   OBJECT-TYPE
+               SYNTAX    Counter
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "A count of frames received on a particular
+                         interface that are an integral number of octets
+                         in length but do not pass the FCS check.
+
+                         The count represented by an instance of this
+                         object is incremented when the frameCheckError
+                         status is returned by the MAC service to the
+                         LLC (or other MAC user). Received frames for
+                         which multiple error conditions obtain are,
+                         according to the conventions of IEEE 802.3
+                         Layer Management, counted exclusively according
+                         to the error status presented to the LLC."
+               REFERENCE
+                         "IEEE 802.3 Layer Management"
+               ::= { dot3StatsEntry 3 }
+
+
+          dot3StatsSingleCollisionFrames   OBJECT-TYPE
+               SYNTAX    Counter
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "A count of successfully transmitted frames on
+                         a particular interface for which transmission
+                         is inhibited by exactly one collision.
+
+                         A frame that is counted by an instance of this
+
+
+
+Kastenholz                                                      [Page 6]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+                         object is also counted by the corresponding
+                         instance of either the ifOutUcastPkts or
+                         ifOutNUcastPkts object and is not counted by
+                         the corresponding instance of the
+                         dot3StatsMultipleCollisionFrames object."
+               REFERENCE
+                         "IEEE 802.3 Layer Management"
+               ::= { dot3StatsEntry 4 }
+
+
+          dot3StatsMultipleCollisionFrames   OBJECT-TYPE
+               SYNTAX    Counter
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "A count of successfully transmitted frames on
+                         a particular interface for which transmission
+                         is inhibited by more than one collision.
+
+                         A frame that is counted by an instance of this
+                         object is also counted by the corresponding
+                         instance of either the ifOutUcastPkts or
+                         ifOutNUcastPkts object and is not counted by
+                         the corresponding instance of the
+                         dot3StatsSingleCollisionFrames object."
+               REFERENCE
+                         "IEEE 802.3 Layer Management"
+               ::= { dot3StatsEntry 5 }
+
+
+          dot3StatsSQETestErrors   OBJECT-TYPE
+               SYNTAX    Counter
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "A count of times that the SQE TEST ERROR
+                         message is generated by the PLS sublayer for a
+                         particular interface. The SQE TEST ERROR
+                         message is defined in section 7.2.2.2.4 of
+                         ANSI/IEEE 802.3-1985 and its generation is
+                         described in section 7.2.4.6 of the same
+                         document."
+               REFERENCE
+                         "ANSI/IEEE Std 802.3-1985 Carrier Sense
+                         Multiple Access with Collision Detection Access
+                         Method and Physical Layer Specifications"
+               ::= { dot3StatsEntry 6 }
+
+
+
+
+Kastenholz                                                      [Page 7]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+          dot3StatsDeferredTransmissions   OBJECT-TYPE
+               SYNTAX    Counter
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "A count of frames for which the first
+                         transmission attempt on a particular interface
+                         is delayed because the medium is busy.
+
+                         The count represented by an instance of this
+                         object does not include frames involved in
+                         collisions."
+               REFERENCE
+                         "IEEE 802.3 Layer Management"
+               ::= { dot3StatsEntry 7 }
+
+
+          dot3StatsLateCollisions   OBJECT-TYPE
+               SYNTAX    Counter
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "The number of times that a collision is
+                         detected on a particular interface later than
+                         512 bit-times into the transmission of a
+                         packet.
+
+                         Five hundred and twelve bit-times corresponds
+                         to 51.2 microseconds on a 10 Mbit/s system. A
+                         (late) collision included in a count
+                         represented by an instance of this object is
+                         also considered as a (generic) collision for
+                         purposes of other collision-related
+                         statistics."
+               REFERENCE
+                         "IEEE 802.3 Layer Management"
+               ::= { dot3StatsEntry 8 }
+
+
+          dot3StatsExcessiveCollisions   OBJECT-TYPE
+               SYNTAX    Counter
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "A count of frames for which transmission on a
+                         particular interface fails due to excessive
+                         collisions."
+
+
+
+
+Kastenholz                                                      [Page 8]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+               REFERENCE
+                         "IEEE 802.3 Layer Management"
+               ::= { dot3StatsEntry 9 }
+
+
+          dot3StatsInternalMacTransmitErrors   OBJECT-TYPE
+               SYNTAX    Counter
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "A count of frames for which transmission on a
+                         particular interface fails due to an internal
+                         MAC sublayer transmit error. A frame is only
+                         counted by an instance of this object if it is
+                         not counted by the corresponding instance of
+                         either the dot3StatsLateCollisions object, the
+                         dot3StatsExcessiveCollisions object, or the
+                         dot3StatsCarrierSenseErrors object.
+
+                         The precise meaning of the count represented by
+                         an instance of this object is implementation-
+                         specific.  In particular, an instance of this
+                         object may represent a count of transmission
+                         errors on a particular interface that are not
+                         otherwise counted."
+               REFERENCE
+                         "IEEE 802.3 Layer Management"
+               ::= { dot3StatsEntry 10 }
+
+
+          dot3StatsCarrierSenseErrors   OBJECT-TYPE
+               SYNTAX    Counter
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "The number of times that the carrier sense
+                         condition was lost or never asserted when
+                         attempting to transmit a frame on a particular
+                         interface.
+
+                         The count represented by an instance of this
+                         object is incremented at most once per
+                         transmission attempt, even if the carrier sense
+                         condition fluctuates during a transmission
+                         attempt."
+               REFERENCE
+                         "IEEE 802.3 Layer Management"
+               ::= { dot3StatsEntry 11 }
+
+
+
+Kastenholz                                                      [Page 9]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+          -- { dot3StatsEntry 12 } is not assigned
+
+          dot3StatsFrameTooLongs   OBJECT-TYPE
+               SYNTAX    Counter
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "A count of frames received on a particular
+                         interface that exceed the maximum permitted
+                         frame size.
+
+                         The count represented by an instance of this
+                         object is incremented when the frameTooLong
+                         status is returned by the MAC service to the
+                         LLC (or other MAC user). Received frames for
+                         which multiple error conditions obtain are,
+                         according to the conventions of IEEE 802.3
+                         Layer Management, counted exclusively according
+                         to the error status presented to the LLC."
+               REFERENCE
+                         "IEEE 802.3 Layer Management"
+               ::= { dot3StatsEntry 13 }
+
+
+
+          -- { dot3StatsEntry 14 } is not assigned
+
+
+          -- { dot3StatsEntry 15 } is not assigned
+
+          dot3StatsInternalMacReceiveErrors   OBJECT-TYPE
+               SYNTAX    Counter
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "A count of frames for which reception on a
+                         particular interface fails due to an internal
+                         MAC sublayer receive error. A frame is only
+                         counted by an instance of this object if it is
+                         not counted by the corresponding instance of
+                         either the dot3StatsFrameTooLongs object, the
+                         dot3StatsAlignmentErrors object, or the
+                         dot3StatsFCSErrors object.
+
+                         The precise meaning of the count represented by
+                         an instance of this object is implementation-
+                         specific.  In particular, an instance of this
+                         object may represent a count of receive errors
+
+
+
+Kastenholz                                                     [Page 10]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+                         on a particular interface that are not
+                         otherwise counted."
+               REFERENCE
+                         "IEEE 802.3 Layer Management"
+               ::= { dot3StatsEntry 16 }
+
+4.2.  The Ethernet-like Collision Statistics Group
+
+
+          -- the Ethernet-like Collision Statistics group
+
+          -- Implementation of this group is optional; it is appropriate
+          -- for all systems which have the necessary metering
+
+          dot3CollTable   OBJECT-TYPE
+               SYNTAX    SEQUENCE OF Dot3CollEntry
+               ACCESS    not-accessible
+               STATUS    mandatory
+               DESCRIPTION
+                         "A collection of collision histograms for a
+                         particular set of interfaces."
+               ::= { dot3 5 }
+
+
+          dot3CollEntry   OBJECT-TYPE
+               SYNTAX    Dot3CollEntry
+               ACCESS    not-accessible
+               STATUS    mandatory
+               DESCRIPTION
+                         "A cell in the histogram of per-frame
+                         collisions for a particular interface.  An
+                         instance of this object represents the
+                         frequency of individual MAC frames for which
+                         the transmission (successful or otherwise) on a
+                         particular interface is accompanied by a
+                         particular number of media collisions."
+               INDEX     { dot3CollIndex, dot3CollCount }
+               ::= { dot3CollTable 1 }
+
+
+
+          Dot3CollEntry ::= SEQUENCE {
+               dot3CollIndex
+                    INTEGER,
+               dot3CollCount
+                    INTEGER,
+               dot3CollFrequencies
+                    Counter
+
+
+
+Kastenholz                                                     [Page 11]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+          }
+
+
+          dot3CollIndex   OBJECT-TYPE
+               SYNTAX    INTEGER
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "The index value that uniquely identifies the
+                         interface to which a particular collision
+                         histogram cell pertains.  The interface
+                         identified by a particular value of this index
+                         is the same interface as identified by the same
+                         value of ifIndex."
+               ::= { dot3CollEntry 1 }
+
+
+          dot3CollCount   OBJECT-TYPE
+               SYNTAX    INTEGER (1..16)
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "The number of per-frame media collisions for
+                         which a particular collision histogram cell
+                         represents the frequency on a particular
+                         interface."
+               ::= { dot3CollEntry 2 }
+
+
+          dot3CollFrequencies   OBJECT-TYPE
+               SYNTAX    Counter
+               ACCESS    read-only
+               STATUS    mandatory
+               DESCRIPTION
+                         "A count of individual MAC frames for which the
+                         transmission (successful or otherwise) on a
+                         particular interface is accompanied by a
+                         particular number of media collisions."
+               ::= { dot3CollEntry 3 }
+
+
+4.3.  802.3 Tests
+
+
+      --  802.3 Tests
+
+      -- The ifExtnsTestTable defined in RFC 1229 provides a common
+      -- means for a manager to test any interface corresponding to
+
+
+
+Kastenholz                                                     [Page 12]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+      -- a value of ifIndex.
+
+      -- At this time, one well known test (testFullDuplexLoopBack) is
+      -- defined in RFC 1229.  For ethernet-like interfaces, this test
+      -- configures the MAC chip and executes an internal loopback
+      -- test of memory and the MAC chip logic.  This loopback test can
+      -- only be executed if the interface is offline.  Once the test
+      -- has completed, the MAC chip should be reinitialized for network
+      -- operation, but it should remain offline.
+
+      -- If an error occurs during a test, the object ifExtnsTestResult
+      -- (defined in RFC 1229) will be set to failed(7).  The following
+      -- two OBJECT IDENTIFIERs may be used to provided more
+      -- information as values for the object ifExtnsTestCode in
+      -- RFC 1229:
+
+          dot3Errors             OBJECT IDENTIFIER ::= { dot3 7 }
+
+                               -- couldn't initialize MAC chip for test
+          dot3ErrorInitError     OBJECT IDENTIFIER ::= { dot3Errors 1 }
+
+                                -- expected data not received (or not
+                                -- received correctly) in loopback test
+          dot3ErrorLoopbackError OBJECT IDENTIFIER ::= { dot3Errors 2 }
+
+       -- Tests
+        --  TDR Test
+
+       -- Another test, specific to ethernet-like interfaces with the
+       -- exception of 10BaseT and 10BaseF, is Time-domain Reflectometry
+           (TDR).
+       -- The TDR value may be useful in determining the approximate
+           distance
+       -- to a cable fault.  It is advisable to repeat this test to
+           check for
+       -- a consistent resulting TDR value, to verify that there is a
+          fault.
+
+          dot3Tests   OBJECT IDENTIFIER ::= { dot3 6 }
+          dot3TestTdr OBJECT IDENTIFIER ::= { dot3Tests 1 }
+
+       -- A TDR test returns as its result the time interval, measured
+       -- in 10 MHz ticks or 100 nsec units, between the start of
+       -- TDR test transmission and the subsequent detection of a
+       -- collision or deassertion of carrier.  On successful completion
+       -- of a TDR test, the appropriate instance of ifExtnsTestResult
+       -- contains the OBJECT IDENTIFIER of the MIB object which
+       -- contains the value of this time interval.
+
+
+
+Kastenholz                                                     [Page 13]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+4.4.  802.3 Hardware Chipsets
+
+
+       --  802.3 Hardware Chipsets
+
+       -- The object ifExtnsChipSet is provided in RFC 1229 to identify
+       -- the MAC hardware used to communcate on an interface.  The
+       -- following hardware chipsets are provided for 802.3:
+
+  dot3ChipSets          OBJECT IDENTIFIER ::= { dot3 8 }
+  dot3ChipSetAMD        OBJECT IDENTIFIER ::= { dot3ChipSets 1 }
+  dot3ChipSetAMD7990    OBJECT IDENTIFIER ::= { dot3ChipSetAMD 1 }
+  dot3ChipSetAMD79900   OBJECT IDENTIFIER ::= { dot3ChipSetAMD 2 }
+
+  dot3ChipSetIntel      OBJECT IDENTIFIER ::= { dot3ChipSets 2 }
+  dot3ChipSetIntel82586 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 1 }
+  dot3ChipSetIntel82596 OBJECT IDENTIFIER ::= { dot3ChipSetIntel 2 }
+  dot3ChipSetSeeq       OBJECT IDENTIFIER ::= { dot3ChipSets 3 }
+  dot3ChipSetSeeq8003   OBJECT IDENTIFIER ::= { dot3ChipSetSeeq 1 }
+
+  dot3ChipSetNational      OBJECT IDENTIFIER ::= { dot3ChipSets 4 }
+  dot3ChipSetNational8390  OBJECT IDENTIFIER ::=
+                                           { dot3ChipSetNational 1 }
+  dot3ChipSetNationalSonic OBJECT IDENTIFIER ::=
+                                           { dot3ChipSetNational 2 }
+
+  dot3ChipSetFujitsu       OBJECT IDENTIFIER ::= { dot3ChipSets 5 }
+  dot3ChipSetFujitsu86950  OBJECT IDENTIFIER ::=
+                                           { dot3ChipSetFujitsu 1 }
+  dot3ChipSetFujitsu86960  OBJECT IDENTIFIER ::=
+                                           { dot3ChipSetFujitsu 2 }
+
+       -- For those chipsets not represented above, OBJECT IDENTIFIER
+       -- assignment is required in other documentation, e.g., assignment
+       -- within that part of the registration tree delegated to
+       -- individual enterprises (see RFC 1155).
+
+          END
+
+5.  Change Log
+
+  (1)  Replace old "Historical Perspective" boilerplate with the
+       new "The Network Management Framework" boilerplate.
+
+  (2)  Remove the "slime text".
+
+  (3)  Updated the reference to the Interface Extensions mib to
+       reflect its new RFC status.
+
+
+
+Kastenholz                                                     [Page 14]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+  (4)  Change the status of the memo section to hold the new
+       suggested text.
+
+  (5)  References in ASN.1 comments were changed from the [#]
+       form to name the actual document being referred to. These
+       references are now meaningful when the ASN.1 is read
+       outside of the RFC.
+
+  (6)  The IMPORTS section of the ASN.1 has been updated to
+       reflect that the OBJECT-TYPE macro is imported from RFC-
+       1212.
+
+  (7)  The the Generic Ethernet-like group, containing
+       dot3Index, dot3InitializeMac, dot3MacSubLayerStatus,
+       dot3MulticastReceiveStatus, dot3TxEnabled, and
+       dot3TestTdrValue has been deprecated as a result of the
+       implementation experience presented at the San Diego IETF
+       meeting.
+
+  (8)  dot3StatsInRangeLengthErrors and
+       dot3StatsOutOfRangeLengthFields have been deprecated as a
+       result of the implementation experience presented at the
+       San Diego IETF meeting.
+
+  (9)  Update the acknowledgements section to reflect this
+       document's history, etc.
+
+  (10) REFERENCE clauses have been added to all of the MIB
+       objects which are being retained.
+
+  12 August 1992
+
+  (1)  Removed all deprecated objects.
+
+  (2)  Rephrased the description of the TDR test OID to reflect
+       the fact that dot3TestTdrValue is no more.
+       ifExtnsTestResult still points to the object containing
+       the result, the text simply does not refer to
+       dot3TestTdrValue. I could have deleted the Test, but the
+       OID should then remain reserved. I figured that it would
+       be just as easy to rephrase the definition of the test.
+
+  13 august 1992
+
+  (1)  Add fuji. 86960
+
+
+
+
+
+
+Kastenholz                                                     [Page 15]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+6.  Acknowledgements
+
+   This document was produced by the Ethernet MIB Working Group.
+
+   This document is based on the Proposed Standard Ethernet MIB, RFC
+   1284 [14], of which John Cook of Chipcom was the editor.  The
+   Ethernet MIB Working Group gathered implementation experience of the
+   variables specified in RFC 1284 and used that information to develop
+   this revised MIB.
+
+   RFC 1284, in turn, is based on a document written by Frank Kastenholz
+   of Interlan entitled IEEE 802.3 Layer Management Draft M compatible
+   MIB for TCP/IP Networks [10].  This document has been modestly
+   reworked, initially by the SNMP Working Group, and then by the
+   Transmission Working Group, to reflect the current conventions for
+   defining objects for MIB interfaces.  James Davin, of the MIT
+   Laboratory for Computer Science, and Keith McCloghrie of Hughes LAN
+   Systems, contributed to later drafts of this memo. Marshall Rose of
+   Performance Systems International, Inc. converted the document into
+   its current concise format. Anil Rijsinghani of DEC contributed text
+   that more adequately describes the TDR test.  Thanks to Frank
+   Kastenholz of Interlan and Louis Steinberg of IBM for their
+   experimentation.
+
+7.  References
+
+   [1] Cerf, V., "IAB Recommendations for the Development of Internet
+       Network Management Standards", RFC 1052, NRI, April 1988.
+
+   [2] Cerf, V., "Report of the Second Ad Hoc Network Management Review
+       Group", RFC 1109, NRI, August 1989.
+
+   [3] Rose M., and K. McCloghrie, "Structure and Identification of
+       Management Information for TCP/IP-based internets", STD 16, RFC
+       1155, Performance Systems International, Hughes LAN Systems, May
+       1990.
+
+   [4] McCloghrie K., and M. Rose, "Management Information Base for
+       Network Management of TCP/IP-based internets", RFC 1156, Hughes
+       LAN Systems, Performance Systems International, May 1990.
+
+   [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
+       Network Management Protocol", STD 15, RFC 1157, SNMP Research,
+       Performance Systems International, Performance Systems
+       International, MIT Laboratory for Computer Science, May 1990.
+
+   [6] Rose M., Editor, "Management Information Base for Network
+       Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213,
+
+
+
+Kastenholz                                                     [Page 16]
+
+RFC 1398                   Ethernet-Like MIB                January 1993
+
+
+       Performance Systems International, March 1991.
+
+   [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 Abstract Notation One
+       (ASN.1), International Organization for Standardization,
+       International Standard 8825, December 1987.
+
+   [9] IEEE, "IEEE 802.3 Layer Management", November 1988.
+
+  [10] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible MIB
+       for TCP/IP Networks", electronic mail message to mib-
+       wg@nnsc.nsf.net, 9 June 1989.
+
+  [11] McCloghrie, K., Editor, Extensions to the Generic-Interface MIB,
+       RFC 1229, Hughes LAN Systems, Inc., May 1991.
+
+  [12] IEEE, "Carrier Sense Multiple Access with Collision Detection
+       (CSMA/CD) Access Method and Physical Layer Specifications",
+       ANSI/IEEE Std 802.3-1985.
+
+  [13] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
+       STD 16, RFC 1212, Performance Systems International, Hughes LAN
+       Systems, March 1991.
+
+  [14] Cook, J., Editor, "Definitions of Managed Objects for Ethernet-
+       Like Interface Types", RFC 1284, Chipcom Corporation, December
+       1991.
+
+8.  Security Considerations
+
+   Security issues are not discussed in this memo.
+
+9.  Author's Address
+
+   Frank Kastenholz
+   2 High Street
+   North Andover, MA 01845-2620
+
+   Phone: (508) 685-4000
+   EMail: kasten@ftp.com
+
+
+
+
+
+
+Kastenholz                                                     [Page 17]
+
\ No newline at end of file