As per Relevance of the word identifier, we have this rfc below:
Network Working Group F.
Request for Comments: 1643 FTP Software, Inc
Obsoletes: 1623, 1398 July 1994
STD: 50
Category: Standards
Definitions of Managed Objects
the Ethernet-like Interface
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Table of
Introduction ............................................. 1
1. The SNMP Network Management Framework ................. 2
1.1 Object Definitions ................................... 2
2. Change Log ............................................ 2
3. Overview .............................................. 3
3.1 Relation to RFC 1213 ................................. 4
3.2 Relation to RFC 1573 ................................. 4
3.2.1 Layering Model ..................................... 4
3.2.2 Virtual Circuits ................................... 4
3.2.3 ifTestTable ........................................ 4
3.2.4 ifRcvAddressTable .................................. 5
3.2.5 ifPhysAddress ...................................... 5
3.2.6 ifType ............................................. 6
4. Definitions ........................................... 6
5. Acknowledgements ...................................... 16
6. References ............................................ 17
7. Security Considerations ............................... 19
8. Author's Address ...................................... 19
This memo defines a portion of the Management Information Base (MIB
for use with network management protocols in the Internet community
In particular, it defines objects for managing ethernet-like objects
This memo also includes a MIB module. This MIB module corrects
errors in the earlier versions of this MIB: RFC 1623 [20], and
1398 [15].
Kastenholz [Page 1]
RFC 1643 Ethernet-Like MIB July 1994
1. The SNMP Network Management
The SNMP Network Management Framework consists of three
components. They are
o STD 16/RFC 1155 [3] which defines the SMI, the
used for describing and naming objects for the purpose
management. STD 16/RFC 1212 [13] defines a more
description mechanism, which is wholly consistent
the SMI
o RFC 1156 [4] which defines MIB-I, the core set of
objects for the Internet suite of protocols. STD 17/
1213 [6] defines MIB-II, an evolution of MIB-I based
implementation experience and new
requirements
o STD 15/RFC 1157 [5] which defines the SNMP, the
used for network access to managed objects
The Framework permits new objects to be defined for the purpose
experimentation and evaluation
1.1. Object
Managed objects are accessed via a virtual information store,
the Management Information Base or MIB. Objects in the MIB
defined using the subset of Abstract Syntax Notation One (ASN.1) [7]
defined in the SMI [16]. In particular, each object object type
named by an OBJECT IDENTIFIER, an administratively assigned name
The object type together with an object instance serves to
identify a specific instantiation of the object. For
convenience, we often use a textual string, termed the descriptor,
refer to the object type
2. Change
This section enumerates changes made to RFC 1398 to produce
document
(1) A section describing the applicability of various
of RFC 1573 to ethernet-like interfaces has been added
(2) A minor error in the description of the TDR test
fixed
(3) A loopback test was defined to replace the
loopback test that was defined in RFC 1229.
Kastenholz [Page 2]
RFC 1643 Ethernet-Like MIB July 1994
(4) The description of dot3CollFrequencies was made a
clearer
(5) A new object, EtherChipset, has been added. This
replaces the ifExtnsChipSet object, which has
removed per the Interface MIB Evolution effort
(6) Several minor editorial changes, spelling corrections
grammar and punctuation corrections, and so forth,
made
3.
Instances of these object types represent attributes of an
to an ethernet-like communications medium. At present, ethernet-
media are identified by three values of the ifType object in
Internet-standard MIB
ethernet-csmacd(6)
iso88023-csmacd(7)
starLan(11)
For these interfaces, the value of the ifSpecific variable in
MIB-II [6] has the OBJECT IDENTIFIER value
dot3 OBJECT IDENTIFER ::= { transmission 7 }
The definitions presented here are based on the IEEE 802.3
Management Specification [9], as originally interpreted by
Kastenholz then of Interlan in [10]. Implementors of these
objects should note that the IEEE document explicitly describes (
the form of Pascal pseudocode) when, where, and how various
attributes are measured. The IEEE document also describes
effects of MAC actions that may be invoked by manipulating
of the MIB objects defined here
To the extent that some of the attributes defined in [9]
represented by previously defined objects in the Internet-
MIB or in the Generic Interface Extensions MIB [11], such
are not redundantly represented by objects defined in this memo
Among the attributes represented by objects defined in other
are the number of octets transmitted or received on a
interface, the number of frames transmitted or received on
particular interface, the promiscuous status of an interface, the
address of an interface, and multicast information associated with
interface
Kastenholz [Page 3]
RFC 1643 Ethernet-Like MIB July 1994
3.1. Relation to RFC 1213
This section applies only when this MIB is used in conjunction
the "old" (i.e., pre-RFC 1573) interface group
The relationship between an ethernet-like interface and an
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
identify corresponding instances of the objects defined herein
3.2. Relation to RFC 1573
RFC 1573, the Interface MIB Evolution, requires that any MIB which
an adjunct of the Interface MIB, clarify specific areas within
Interface MIB. These areas were intentionally left vague in RFC 1573
to avoid over constraining the MIB, thereby precluding management
certain media-types
Section 3.3 of RFC 1573 enumerates several areas which a media
specific MIB must clarify. Each of these areas is addressed in
following subsection. The implementor is referred to RFC 1573
order to understand the general intent of these areas
3.2.1. Layering
This MIB does not provide for layering. There are no sublayers
EDITOR'S NOTE
I could forsee the development of an 802.2 and enet-
MIB. They could be higher and lower sublayers, respectively.
that THIS document should do is allude to the possibilities
urge the implementor to be aware of the possibility and that
may have requirements which supersede the requirements in
document
3.2.2. Virtual
This medium does not support virtual circuits and this area is
applicable to this MIB
3.2.3.
This MIB defines two tests for media which are instumented with
MIB; TDR and Loopback. Implementation of these tests is
required. Many common interface chips do not support one or both
these tests
Kastenholz [Page 4]
RFC 1643 Ethernet-Like MIB July 1994
These two tests are provided as a convenience, allowing a
method to invoke the test
Standard MIBs do not include objects in which to return the
of the TDR test. Any needed objects MUST be provided in the
specific MIB
3.2.4.
This table contains all IEEE 802.3 addresses, unicast, multicast,
broadcast, for which this interface will receive packets and
them up to a higher layer entity for local consumption. The
of the address, contained in ifRcvAddressAddress, is the same as
ifPhysAddress
In the event that the interface is part of a MAC bridge, this
does not include unicast addresses which are accepted for
forwarding out some other port. This table is explicitly
intended to provide a bridge address filtering mechanism
3.2.5.
This object contains the IEEE 802.3 address which is placed in
source-address field of any Ethernet, Starlan, or IEEE 802.3
that originate at this interface. Usually this will be kept in
on the interface hardware. Some systems may set this address
software
In a system where there are several such addresses the designer has
tougher choice. The address chosen should be the one most likely
be of use to network management (e.g. the address placed in
responses for systems which are primarily IP systems).
If the designer truly can not chose, use of the factory- provided
address is suggested
If the address can not be determined, an octet string of zero
should be returned
The address is stored in binary in this object. The address
stored in "canonical" bit order, that is, the Group Bit is
as the low-order bit of the first octet. Thus, the first byte of
multicast address would have the bit 0x01 set
Kastenholz [Page 5]
RFC 1643 Ethernet-Like MIB July 1994
3.2.6.
This MIB applies to interfaces which have any of the following
ifType values
ethernet-csmacd(6)
iso88023-csmacd(7)
starLan(11)
Interfaces with any of these ifType values map to the EtherLike-
in the same manner. The EtherLike-MIB applies equally to all
types; there are no implementation differences
4.
EtherLike-MIB DEFINITIONS ::=
Counter, Gauge FROM RFC1155-
ifIndex, transmission FROM RFC1213-
OBJECT-TYPE FROM RFC-1212;
-- This MIB module uses the extended OBJECT-TYPE macro
-- defined in RFC-1212.
dot3 OBJECT IDENTIFIER ::= { transmission 7 }
-- the Ethernet-like Statistics
dot3StatsTable OBJECT-
SYNTAX SEQUENCE OF Dot3
ACCESS not-
STATUS
"Statistics for a collection of ethernet-
interfaces attached to a particular system."
::= { dot3 2 }
dot3StatsEntry OBJECT-
SYNTAX Dot3
ACCESS not-
STATUS
"Statistics for a particular interface to
ethernet-like medium."
INDEX { dot3StatsIndex }
::= { dot3StatsTable 1 }
Kastenholz [Page 6]
RFC 1643 Ethernet-Like MIB July 1994
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
dot3StatsEtherChipSet OBJECT
}
dot3StatsIndex OBJECT-
SYNTAX
ACCESS read-
STATUS
"An index value that uniquely identifies
interface to an ethernet-like medium.
interface identified by a particular value
this index is the same interface as
by the same value of ifIndex."
::= { dot3StatsEntry 1 }
dot3StatsAlignmentErrors OBJECT-
SYNTAX
ACCESS read-
STATUS
"A count of frames received on a
interface that are not an integral number
octets in length and do not pass the FCS check
The count represented by an instance of
object is incremented when the
status is returned by the MAC service to
LLC (or other MAC user). Received frames
which multiple error conditions obtain are
according to the conventions of IEEE 802.3
Layer Management, counted exclusively
to the error status presented to the LLC."
"IEEE 802.3 Layer Management
Kastenholz [Page 7]
RFC 1643 Ethernet-Like MIB July 1994
::= { dot3StatsEntry 2 }
dot3StatsFCSErrors OBJECT-
SYNTAX
ACCESS read-
STATUS
"A count of frames received on a
interface that are an integral number of
in length but do not pass the FCS check
The count represented by an instance of
object is incremented when the
status is returned by the MAC service to
LLC (or other MAC user). Received frames
which multiple error conditions obtain are
according to the conventions of IEEE 802.3
Layer Management, counted exclusively
to the error status presented to the LLC."
"IEEE 802.3 Layer Management
::= { dot3StatsEntry 3 }
dot3StatsSingleCollisionFrames OBJECT-
SYNTAX
ACCESS read-
STATUS
"A count of successfully transmitted frames
a particular interface for which
is inhibited by exactly one collision
A frame that is counted by an instance of
object is also counted by the
instance of either the ifOutUcastPkts
ifOutMulticastPkts, or ifOutBroadcastPkts
and is not counted by the
instance of the dot3
object."
"IEEE 802.3 Layer Management
::= { dot3StatsEntry 4 }
dot3StatsMultipleCollisionFrames OBJECT-
SYNTAX
ACCESS read-
STATUS
Kastenholz [Page 8]
RFC 1643 Ethernet-Like MIB July 1994
"A count of successfully transmitted frames
a particular interface for which
is inhibited by more than one collision
A frame that is counted by an instance of
object is also counted by the
instance of either the ifOutUcastPkts
ifOutMulticastPkts, or ifOutBroadcastPkts
and is not counted by the
instance of the dot3
object."
"IEEE 802.3 Layer Management
::= { dot3StatsEntry 5 }
dot3StatsSQETestErrors OBJECT-
SYNTAX
ACCESS read-
STATUS
"A count of times that the SQE TEST
message is generated by the PLS sublayer for
particular interface. The SQE TEST
message is defined in section 7.2.2.2.4
ANSI/IEEE 802.3-1985 and its generation
described in section 7.2.4.6 of the
document."
"ANSI/IEEE Std 802.3-1985 Carrier
Multiple Access with Collision Detection
Method and Physical Layer Specifications
::= { dot3StatsEntry 6 }
dot3StatsDeferredTransmissions OBJECT-
SYNTAX
ACCESS read-
STATUS
"A count of frames for which the
transmission attempt on a particular
is delayed because the medium is busy
The count represented by an instance of
object does not include frames involved
collisions."
"IEEE 802.3 Layer Management
::= { dot3StatsEntry 7 }
Kastenholz [Page 9]
RFC 1643 Ethernet-Like MIB July 1994
dot3StatsLateCollisions OBJECT-
SYNTAX
ACCESS read-
STATUS
"The number of times that a collision
detected on a particular interface later
512 bit-times into the transmission of
packet
Five hundred and twelve bit-times
to 51.2 microseconds on a 10 Mbit/s system.
(late) collision included in a
represented by an instance of this object
also considered as a (generic) collision
purposes of other collision-
statistics."
"IEEE 802.3 Layer Management
::= { dot3StatsEntry 8 }
dot3StatsExcessiveCollisions OBJECT-
SYNTAX
ACCESS read-
STATUS
"A count of frames for which transmission on
particular interface fails due to
collisions."
"IEEE 802.3 Layer Management
::= { dot3StatsEntry 9 }
dot3StatsInternalMacTransmitErrors OBJECT-
SYNTAX
ACCESS read-
STATUS
"A count of frames for which transmission on
particular interface fails due to an
MAC sublayer transmit error. A frame is
counted by an instance of this object if it
not counted by the corresponding instance
either the dot3StatsLateCollisions object,
dot3StatsExcessiveCollisions object, or
dot3StatsCarrierSenseErrors object
Kastenholz [Page 10]
RFC 1643 Ethernet-Like MIB July 1994
The precise meaning of the count represented
an instance of this object is implementation
specific. In particular, an instance of
object may represent a count of
errors on a particular interface that are
otherwise counted."
"IEEE 802.3 Layer Management
::= { dot3StatsEntry 10 }
dot3StatsCarrierSenseErrors OBJECT-
SYNTAX
ACCESS read-
STATUS
"The number of times that the carrier
condition was lost or never asserted
attempting to transmit a frame on a
interface
The count represented by an instance of
object is incremented at most once
transmission attempt, even if the carrier
condition fluctuates during a
attempt."
"IEEE 802.3 Layer Management
::= { dot3StatsEntry 11 }
-- { dot3StatsEntry 12 } is not
dot3StatsFrameTooLongs OBJECT-
SYNTAX
ACCESS read-
STATUS
"A count of frames received on a
interface that exceed the maximum
frame size
The count represented by an instance of
object is incremented when the
status is returned by the MAC service to
LLC (or other MAC user). Received frames
which multiple error conditions obtain are
according to the conventions of IEEE 802.3
Layer Management, counted exclusively
to the error status presented to the LLC."
Kastenholz [Page 11]
RFC 1643 Ethernet-Like MIB July 1994
"IEEE 802.3 Layer Management
::= { dot3StatsEntry 13 }
-- { dot3StatsEntry 14 } is not
-- { dot3StatsEntry 15 } is not
dot3StatsInternalMacReceiveErrors OBJECT-
SYNTAX
ACCESS read-
STATUS
"A count of frames for which reception on
particular interface fails due to an
MAC sublayer receive error. A frame is
counted by an instance of this object if it
not counted by the corresponding instance
either the dot3StatsFrameTooLongs object,
dot3StatsAlignmentErrors object, or
dot3StatsFCSErrors object
The precise meaning of the count represented
an instance of this object is implementation
specific. In particular, an instance of
object may represent a count of receive
on a particular interface that are
otherwise counted."
"IEEE 802.3 Layer Management
::= { dot3StatsEntry 16 }
dot3StatsEtherChipSet OBJECT-
SYNTAX OBJECT
ACCESS read-
STATUS
"This object contains an OBJECT
which identifies the chipset used
realize the interface. Ethernet-
interfaces are typically built out
several different chips. The MIB
is presented with a decision of which
to identify via this object. The
should identify the chip which is
called the Medium Access Control chip
If no such chip is easily identifiable
the implementor should identify the
Kastenholz [Page 12]
RFC 1643 Ethernet-Like MIB July 1994
which actually gathers the
and receive statistics and
indications. This would allow
manager station to correlate
statistics and the chip
them, giving it the ability to
into account any known
in the chip."
::= { dot3StatsEntry 17 }
-- the Ethernet-like Collision Statistics
-- Implementation of this group is optional; it is
-- for all systems which have the necessary
dot3CollTable OBJECT-
SYNTAX SEQUENCE OF Dot3
ACCESS not-
STATUS
"A collection of collision histograms for
particular set of interfaces."
::= { dot3 5 }
dot3CollEntry OBJECT-
SYNTAX Dot3
ACCESS not-
STATUS
"A cell in the histogram of per-
collisions for a particular interface.
instance of this object represents
frequency of individual MAC frames for
the transmission (successful or otherwise) on
particular interface is accompanied by
particular number of media collisions."
INDEX { ifIndex, dot3CollCount }
::= { dot3CollTable 1 }
Dot3CollEntry ::= SEQUENCE {
dot3CollCount INTEGER
dot3CollFrequencies
}
-- { dot3CollEntry 1 } is no longer in
dot3CollCount OBJECT-
Kastenholz [Page 13]
RFC 1643 Ethernet-Like MIB July 1994
SYNTAX INTEGER (1..16)
ACCESS not-
STATUS
"The number of per-frame media collisions
which a particular collision histogram
represents the frequency on a
interface."
::= { dot3CollEntry 2 }
dot3CollFrequencies OBJECT-
SYNTAX
ACCESS read-
STATUS
"A count of individual MAC frames for which
transmission (successful or otherwise) on
particular interface occurs after
frame has experienced exactly the
of collisions in the
dot3CollCount object
For example, a frame which is
on interface 77 after
exactly 4 collisions would be
by incrementing only dot3CollFrequencies.77.4.
No other instance of dot3CollFrequencies
be incremented in this example."
::= { dot3CollEntry 3 }
-- 802.3
dot3Tests OBJECT IDENTIFIER ::= { dot3 6 }
dot3Errors OBJECT IDENTIFIER ::= { dot3 7 }
-- TDR
-- The Time-Domain Reflectometry (TDR) test is
-- to ethernet-like interfaces with the exception
-- 10BaseT and 10BaseF. The TDR value may be
-- in determining the approximate distance to a cable fault
-- It is advisable to repeat this test to check for
-- consistent resulting TDR value, to verify that
-- is a fault
Kastenholz [Page 14]
RFC 1643 Ethernet-Like MIB July 1994
dot3TestTdr OBJECT IDENTIFIER ::= { dot3Tests 1 }
-- A TDR test returns as its result the time interval
-- measured in 10 MHz ticks or 100 nsec units,
-- the start of TDR test transmission and the
-- detection of a collision or deassertion of carrier.
-- successful completion of a TDR test, the result
-- stored as the value of the appropriate instance of
-- MIB object dot3TestTdrValue, and the OBJECT
-- of that instanceis stored in the corresponding
-- of ifExtnsTestCode (thereby indicating where
-- result has been stored).
-- Loopback
-- Another test is the full-duplex loopback test
-- This test configures the MAC chip and
-- an internal loopback test of memory, data paths
-- and the MAC chip logic. This loopback test
-- only be executed if the interface is offline
-- Once the test has completed, the MAC chip
-- be reinitialized for network operation, but
-- should remain offline
dot3TestLoopBack OBJECT IDENTIFIER ::= { dot3Tests 2 }
-- If an error occurs during a test, the
-- ifTestResult (defined in RFC1573) will be
-- to failed(7). The following two
-- IDENTIFIERs may be used to provided
-- information as values for ifTestCode
-- couldn't initialize MAC chip for
dot3ErrorInitError OBJECT IDENTIFIER ::= { dot3Errors 1 }
-- expected data not received (or
-- received correctly) in loopback
dot3ErrorLoopbackError OBJECT IDENTIFIER ::= { dot3Errors 2 }
-- RFC1573 does away with the interface chipset object
-- The following OBJECT IDENTIFIER definitions
-- retained for purposes of backwards
-- with pre-RFC1573 systems
-- 802.3 Hardware
-- The object ifExtnsChipSet is provided in RFC1229
-- identify the MAC hardware used to communcate on
Kastenholz [Page 15]
RFC 1643 Ethernet-Like MIB July 1994
-- interface. The following hardware chipsets
-- provided for 802.3:
dot3ChipSets OBJECT IDENTIFIER ::= { dot3 8 }
dot3ChipSetAMD OBJECT IDENTIFIER ::= { dot3ChipSets 1 }
dot3ChipSetAMD7990 OBJECT IDENTIFIER ::= { dot3ChipSetAMD 1 }
dot3ChipSetAMD79900 OBJECT IDENTIFIER ::= { dot3ChipSetAMD 2 }
dot3ChipSetAMD79C940 OBJECT IDENTIFIER ::= { dot3ChipSetAMD 3 }
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 }
dot3ChipSetDigital OBJECT IDENTIFIER ::= { dot3ChipSets 6 }
dot3ChipSetDigitalDC21040 OBJECT IDENTIFIER ::=
{ dot3ChipSetDigital 1 }
-- For those chipsets not represented above, OBJECT
-- assignment is required in other documentation, e.g.,
-- within that part of the registration tree delegated
-- individual enterprises (see RFC1155).
5.
This document was produced by the Ethernet MIB Working Group
This document is based on the Proposed Standard Ethernet MIB,
1284 [14], of which Jihn Cook of Chipcom was the editor.
Ethernet MIB Working Group gathered implementation experience of
variables specified in RFC 1284 and used that information to
this revised MIB
RFC 1284, in turn, is based on a document written by Frank
Kastenholz [Page 16]
RFC 1643 Ethernet-Like MIB July 1994
of Interlan entitled IEEE 802.3 Layer Management Draft M
MIB for TCP/IP Networks [10]. This document has been
reworked, initially by the SNMP Working Group, and then by
Transmission Working Group, to reflect the current conventions
defining objects for MIB interfaces. James Davin, of the
Laboratory for Computer Science, and Keith McCloghrie of Hughes
Systems, contributed to later drafts of this memo. Marshall Rose
Performance Systems International, Inc. converted the document
its current concise format. Anil Rijsinghani of DEC contributed
that more adequately describes the TDR test. Thanks to
Kastenholz of Interlan and Louis Steinberg of IBM for
experimentation
6.
[1] Cerf, V., "IAB Recommendations for the Development of
Network Management Standards", RFC 1052, NRI, April 1988.
[2] Cerf, V., "Report of the Second Ad Hoc Network Management
Group", RFC 1109, NRI, August 1989.
[3] Rose M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based internets", STD 16,
1155, Performance Systems International, Hughes LAN Systems,
1990.
[4] McCloghrie K., and M. Rose, "Management Information Base
Network Management of TCP/IP-based internets", RFC 1156,
LAN Systems, Performance Systems International, May 1990.
[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "
Network Management Protocol", STD 15, RFC 1157, SNMP Research
Performance Systems International, Performance
International, MIT Laboratory for Computer Science, May 1990.
[6] McCloghrie K., and M. Rose, Editors, "Management Information
for Network Management of TCP/IP-based internets", STD 17,
1213, Performance Systems International, March 1991.
[7] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization,
Standard 8824, December 1987.
[8] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Notation
(ASN.1), International Organization for Standardization
International Standard 8825, December 1987.
Kastenholz [Page 17]
RFC 1643 Ethernet-Like MIB July 1994
[9] IEEE, "IEEE 802.3 Layer Management", November 1988.
[10] Kastenholz, F., "IEEE 802.3 Layer Management Draft compatible
for TCP/IP Networks", electronic mail message to mib
wg@nnsc.nsf.net, 9 June 1989.
[11] McCloghrie, K., Editor, "Extensions to the Generic-
MIB", RFC 1229, Hughes LAN Systems, Inc., May 1991.
[12] IEEE, "Carrier Sense Multiple Access with Collision
(CSMA/CD) Access Method and Physical Layer Specifications",
ANSI/IEEE Std 802.3-1985.
[13] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
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,
1991.
[15] Kastenholz, F., "Definitions of Managed Objects for
Ethernet-like Interface Types", RFC 1398, FTP Software, Inc.,
January 1993.
[16] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "
of Management Information for version 2 of the Simple
Management Protocol (SNMPv2)", RFC 1442, SNMP Research, Inc.,
Hughes LAN Systems, Dover Beach Consulting, Inc., Carnegie
University, April 1993.
[17] Galvin, J., and K. McCloghrie, "Administrative Model for
2 of the Simple Network Management Protocol (SNMPv2)", RFC 1445,
Trusted Information Systems, Hughes LAN Systems, April 1993.
[18] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "
Operations for version 2 of the Simple Network
Protocol (SNMPv2)", RFC 1448, SNMP Research, Inc., Hughes
Systems, Dover Beach Consulting, Inc., Carnegie
University, April 1993.
[19] McCloghrie, K., and F. Kastenholz, "Evolution of the
Group of MIB-II", RFC 1573, Hughes LAN Systems, FTP Software
January 1994.
[20] Kastenholz, F., "Definitions of Managed Objects for
Ethernet-like Interface Types", STD 50, RFC 1623, FTP Software
Inc., May 1994.
Kastenholz [Page 18]
RFC 1643 Ethernet-Like MIB July 1994
7. Security
Security issues are not discussed in this memo
8. Author's
Frank
FTP Software, Inc
2 High
North Andover, Mass, USA 01845
Phone: 508-685-4000
EMail: kasten@ftp.
Kastenholz [Page 19]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
