doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc1369.txt b/doc/rfc/rfc1369.txt
new file mode 100644
index 0000000..d5979b5
--- /dev/null
+++ b/doc/rfc/rfc1369.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                      F. Kastenholz
+Request for Comments: 1369                                  FTP Software
+                                                            October 1992
+
+
+                  Implementation Notes and Experience for
+                         The Internet Ethernet MIB
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard.  Distribution of this memo is
+   unlimited.
+
+Table of Contents
+
+   1. Introduction ................................................    1
+   2. Observations ................................................    2
+   3. Conclusions .................................................    3
+   4. Final Action ................................................    4
+   5. Implementation Data .........................................    5
+   6. Security Considerations .....................................    7
+   7. Author's Address ............................................    7
+
+1.  Introduction
+
+   The Ethernet MIB Working group has been tasked with the following two
+   work items:
+
+   1)  Develop a document explaining the rationale for assigning
+       MANDATORY status to MIB variables which are optional in
+       the relevant IEEE 802.3 specification (the technical
+       basis for the Internet Ethernet MIB). This shall not be a
+       standards-track document.
+
+   (2) Develop an implementation report on the Ethernet MIB.
+       This report shall cover MIB variables which are
+       implemented in both Ethernet interface chips, and in
+       software (i.e., drivers), and discuss the issues
+       pertaining to both.  This report shall also summarize
+       field experience with the MIB variables, especially
+       concentrating on those variables which are in dispute.
+       This document shall not be a standards-track document.
+       While the Ethernet MIB is progressing through the
+       standardization process, this document shall be
+       periodically updated to reflect the latest implementation
+       and operational experience.
+
+
+
+
+Kastenholz                                                      [Page 1]
+
+RFC 1369              Ethernet MIB Implementations          October 1992
+
+
+   This document reflects the currently known status of 11 different
+   implementations of the MIB by 7 different vendors on 7 different
+   Ethernet interface chips.
+
+2.  Observations
+
+   There are some interesting points to be noted from this information:
+
+   1)  Only 4 variables are actually implemented in all
+       implementations: AlignmentErrors, FCSErrors,
+       ExcessiveCollisions and InternalMacTransmitErrors.
+
+   2)  There were another five variables implemented in all but
+       one of the reported implementations,
+       SingleCollisionFrames, MultipleCollisionFrames,
+       LateCollisions, FrameTooLongs, and CarrierSenseErrors.
+
+       Three of these variables exist in implementations that
+       use the same chip as the implementation that does not
+       contain the variable.  Specifically:
+
+    A)   SingleCollisionFrames is not implemented in
+         implementation number 3, which uses the AMD LANCE.
+         However, other AMD LANCE implementations (7, 8, and 10)
+         do implement the variable, implying that it is
+         available on the LANCE.
+
+    B)   MultipleCollisionFrames is not implemented in
+         implementation number 3, which uses the AMD LANCE.
+         However, other AMD LANCE implementations (7, 8, and 10)
+         do implement the variable, implying that it is
+         available on the LANCE.
+
+    C)   LateCollisions is not implemented in implementation
+         number 1, which uses the Intel 82586. However, another
+         Intel 82586 based implementation (11) does implement
+         the variable, implying that it is available on the
+         Intel 82586.
+
+    D)   CarrierSenseErrors is not implemented on implementation
+         number 2, which is based on the Fujitsu 86950 chip.
+         However, there is only one implementation based on this
+         chip and I have not been able to locate a data sheet on
+         this part so no conclusion can be drawn at this time.
+
+    E)   FrameTooLongs is not implemented on implementation
+         number 5, which is based on the National NIC 8390 chip.
+         However, there is only one implementation based on this
+
+
+
+Kastenholz                                                      [Page 2]
+
+RFC 1369              Ethernet MIB Implementations          October 1992
+
+
+         chip and I have not been able to locate a data sheet on
+         this part. It should also be noted that this variable
+         is easily maintained by software as a "driver-level"
+         function.
+
+   (3)  Of the 22 variables in the MIB, 11, or 1/2 of the
+        variables, were implemented in about 1/2 or less of the
+        implementations.
+
+   4)   The number of variables implemented per implementation
+        ranges from a low of 11 to a high of 16. The average
+        number of variables truly implemented is 12.8.
+
+   5)   The IEEE 802.3 encapsulation-specific variables
+        (InRangeLengthErrors, and OutOfRangeLengthFields) are in
+        2 and 0 implementations respectively.
+
+3.  Conclusions
+
+   From this, the author concludes that:
+
+   The control variables (IntializeMAC, etc.) are not widely
+   implemented, but this may be due to an aversion to implementing
+   writable variables until security is in place.
+
+   One vendor has stated that the reason that these variables were not
+   implemented was that the vendor did not believe the variables to be
+   useful, and that they were hard to implement.  Furthermore, this
+   vendor has recommended dropping the variables entirely.
+
+   The two IEEE 802.3 encapsulation variables (InRangeLengthErrors and
+   OutOfRangeLengthFields) are barely implemented. In Santa Fe, the
+   Working group discussed moving them to an optional, 802.3 specific,
+   group. The author believes that this is justified by this
+   implementation data.
+
+   The collision histogram variables are also barely implemented.  They
+   should be in their own optional group -- and they are.
+
+   Of the remaining 13 statistical variables, 9 of them are in 10 or 11
+   implementations. This is good.
+
+   Two of them (SQETestErrors and ExcessiveDeferrals) are in 3 and 1
+   implementations, respectively. This is bad.
+
+   The remaining variables (DeferredTransmissions and
+   InternalMacReceiveErrors) are in 8 or 9 implementations.
+
+
+
+
+Kastenholz                                                      [Page 3]
+
+RFC 1369              Ethernet MIB Implementations          October 1992
+
+
+   It should be noted that one of the two systems that do not implement
+   DeferredTransmissions is based on the AMD LANCE, and other AMD LANCE
+   based systems do implement this counter, leading to the conclusion
+   that DeferredTransmissions could easily be on all but one of the
+   implementations.
+
+   The other such variable, InternalMacReceiveErrors, is a general
+   catchall for all other errors. If no other errors are detected by the
+   hardware or software then returning 0 for the counter is perfectly
+   acceptable.
+
+   This all seems to imply either:
+
+   1)  Splitting the statistics group into two groups, one of
+       which is optional and contains SQETestErrors and
+       ExcessiveDeferrals, or
+
+   2)  Eliminating SQETestErrors and ExcessiveDeferrals) from
+       the MIB.
+
+   The variables with 8 or 9 implementations are a bit more problematic.
+   They are implemented in more than 2/3s of the implementations, but it
+   may not be appropriate to call this widespread implementation.
+   However, it seems to be safe to conclude that the non-implementations
+   of these variables is due to local implementation considerations
+   rather than a fundamental lack of support for the variable.
+
+4.  Final Action
+
+   After consideration at the San Diego IETF Meeting on 17 March 1992,
+   the Ethernet MIB Working Group made the following recommendations:
+
+   1)  The dot3TestTdrValue object will be deprecated from the
+       standard mib.  There are effectively no implementations
+       of this object, and some chips were reported to return an
+       incorrect value for the TDR count.
+
+   2)  The dot3StatsInRangeLengthErrors object and the
+       dot3StatsOutOfRangeLengthFields object will be deprecated
+       from the MIB. These objects were not widely implemented
+       and their utility in diagnosing network problems was
+       strongly questioned.
+
+   3)  The dot3InitializeMac object, the dot3MacSubLayerStatus
+       object, the dot3MulticastReceiveStatus object, and the
+       dot3TxEnabled object will be deprecated from the MIB.
+       These objects were not widely implemented and their
+       utility in diagnosing network problems was strongly
+
+
+
+Kastenholz                                                      [Page 4]
+
+RFC 1369              Ethernet MIB Implementations          October 1992
+
+
+       questioned.
+
+   4)  The dot3StatsExcessiveDeferrals object will be deprecated
+       from the MIB.  Only one system implemented this object.
+       Furthermore, its exact definition was called into question.
+
+   5)  The dot3StatsSQETestErrors object received few
+       implementations.  However, the working group strongly
+       supported its retention in the MIB on the basis that
+       certain forms of transceiver and cable errors that are
+       not uncommon can only be detected with this counter.
+
+   6)  The collision histogram table (dot3CollTable) will be
+       kept as an optional group, even though the objects are
+       not widely implemented nor is there hardware support on
+       all reported chips.
+
+5.  Implementation Data
+
+   The following raw data has been provided by vendors, each developing
+   an implementation of the Ethernet MIB.  Each reported implementation
+   has a separate column in the following table. For each
+   implementation/MIB Variable, a single character code has been entered
+   indicating the rough implementation status of the variable.  These
+   codes are:
+
+   Y    Fully implemented, reports a truthful count, or
+        indication of state. All values may be written to the
+        variable with the expected action occurring.
+
+   N    Not implemented at all. Would return a noSuchName error
+        if accessed.
+
+   C    Implemented but returns a constant value for gets and
+        returns a badValue error for any set attempt to set the
+        variable to a value other than this constant (writable
+        variables only).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kastenholz                                                      [Page 5]
+
+RFC 1369              Ethernet MIB Implementations          October 1992
+
+
+                         MIB           Implementation
+                    Variable 1  2  3  4  5  6  7  8  9  10 11 Yesses
+
+               InitializeMac C  C  Y  Y  Y  Y  Y  C7 C7 N  Y   6
+           MacSubLayerStatus C  C  Y  Y  Y  Y  Y  C7 C7 N  C   5
+      MulticastReceiveStatus C  C  Y  C3 Y  C  C  C7 C7 N  C   2
+                   TxEnabled C  C  Y  Y  Y  Y  Y  C7 C7 N  C   5
+                TestTdrValue C  1  C  C4 C  C  C  C4 C4 N  C   1
+
+             AlignmentErrors Y  Y  Y  Y  Y  Y  Y  Y  Y  Y  Y  11
+                   FCSErrors Y  Y  Y  Y  Y  Y  Y  Y  Y  Y  Y  11
+       SingleCollisionFrames Y  Y  Y  N  Y  Y  Y  Y  Y  Y  Y  10
+     MultipleCollisionFrames Y  Y  Y  N  Y  Y  Y  Y  Y  Y  Y  10
+               SQETestErrors Y  C  C  C  Y  C  C  C  C  Y  C   3
+       DeferredTransmissions Y  C  Y  N  Y  Y  Y  Y  Y  Y  Y   9
+              LateCollisions C  Y  Y  Y  Y  Y  Y  Y  Y  Y  Y  10
+         ExcessiveCollisions Y  Y  Y  Y  Y  Y  Y  Y  Y  Y  Y  11
+   InternalMacTransmitErrors Y  Y  Y  Y  Y  Y  Y  Y  Y  Y  Y  11
+          CarrierSenseErrors Y  C  Y  Y  Y  Y  Y  Y  Y  Y  Y  10
+          ExcessiveDeferrals C  C  Y  C  C  C  C  C  C  N  C   1
+               FrameTooLongs Y  Y2 Y  Y  C  Y  Y  Y  Y  Y  Y  10
+         InRangeLengthErrors C  C  C  N5 C  Y  Y  C  C  N  C   2
+      OutOfRangeLengthFields C  C  C  C6 C  C  C  C  C  N  C   0
+    InternalMacReceiveErrors Y  Y  Y  Y  Y  C  C  Y  Y  Y  C   8
+
+                   CollCount Y  Y  C  N  N  N  N  C  C  N  Y   3
+             CollFrequencies Y  Y  C  N  N  N  N  C  C  N  Y   3
+                      Yesses 13 11 16 11 15 14 14 11 11 12 13
+
+
+   Notes:
+
+   1    does not implement TDR test, but reports TDR from last
+        collision!
+
+   2    Not supported by the chip, detected solely in software.
+
+   3    But set to disabled(2) -> badValue
+
+   4    Underlying TDR function not implemented on this chip.
+
+   5    Only counts frames too short though.
+
+   6    Due to Ethernet encapsulation
+
+   7    Implementation does not support set operations but
+        reports the correct value for these.
+
+
+
+
+Kastenholz                                                      [Page 6]
+
+RFC 1369              Ethernet MIB Implementations          October 1992
+
+
+   The implementations are:
+
+            Implementation   Vendor   Chip
+                         1   1        Intel 82586
+                         2   1        Fujitsu 86950
+                         3   2        Sonic
+                         4   3        AMD Lance
+                         5   4        National NIC 8390C
+                         6   4        Intel 82596
+                         7   4        AMD Lance
+                         8   5        AMD Lance
+                         9   5        AMD ILACC
+                        10   6        AMD Lance
+                        11   7        Intel 82586
+
+6. Security Considerations
+
+   Security issues are not discussed in this memo.
+
+7. Author's Address
+
+   Frank J. Kastenholz
+   FTP Software
+   2 High Street
+   North Andover Mass 01845
+
+   Phone:  508-685-4000
+   EMail:  kasten@ftp.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kastenholz                                                      [Page 7]
+
\ No newline at end of file