draft-ietf-opsawg-rfc5066bis-01.txt   draft-ietf-opsawg-rfc5066bis-02.txt 
Network Working Group E. Beili Network Working Group E. Beili
Internet-Draft Actelis Networks Internet-Draft Actelis Networks
Obsoletes: 5066 (if approved) January 07, 2013 Updates: 5066 (if approved) May 02, 2013
Intended status: Standards Track Intended status: Standards Track
Expires: July 11, 2013 Expires: November 3, 2013
Interface Stack Capability MIB Ethernet in the First Mile Copper (EFMCu) Interfaces MIB
draft-ietf-opsawg-rfc5066bis-01.txt draft-ietf-opsawg-rfc5066bis-02.txt
Abstract Abstract
This document defines Management Information Base (MIB) module for This document updates RFC 5066. It amends that specification by
use with network management protocols in TCP/IP-based internets. informing the internet community about the transition of the EFM-CU-
This document defines a set of objects, describing cross-connect MIB module from the IETF Ethernet Interfaces and Hub MIB Working
capability of a managed device with multi-layer (stacked) interfaces, Group to the Institute of Electrical and Electronics Engineers (IEEE)
extending the stack management objects in the Interfaces Group MIB 802.3 working group.
and the Inverted Stack Table MIB modules. This document obsoletes
RFC 5066. It amends that specification by taking out the entire EFM-
CU-MIB module along with the relevant descriptive text. That MIB
module will be part of a separate document, maintained by the
Institute of Electrical and Electronics Engineers (IEEE) 802.3
working group.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 11, 2013. This Internet-Draft will expire on November 3, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Internet-Standard Management Framework . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 3
3. Relation to Other MIB Modules . . . . . . . . . . . . . . . . 3 3. Mapping between EFM-CU-MIB and IEEE8023-EFM-CU-MIB . . . . . . 3
3.1. Relation to the EFMCu Interfaces MIB Module . . . . . . . 4 4. Updating the MIB Modules . . . . . . . . . . . . . . . . . . . 4
3.2. Relation to Interfaces Group MIB Module . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
3.2.1. ifCapStackTable usage example for bonded xDSL 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
interfaces . . . . . . . . . . . . . . . . . . . . . . 4 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
4. MIB Structure . . . . . . . . . . . . . . . . . . . . . . . . 5 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Interface Stack Capability MIB Overview . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5
5. Interface Stack Capability MIB Definitions . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This memo defines a Management Information Base (MIB) module for use RFC 5066 [RFC5066] defines two MIB modules:
with network management protocols in the Internet community,
describing the cross-connect capability of a stacked interface.
2BASE-TL and 10PASS-TS physical interfaces, defined in the IEEE EFM-CU-MIB, with a set of objects for managing 10PASS-TS and
Standard 802.3 [802.3], as well the xDSL Multi-Pair Bonded interfaces 2BASE-TL Ethernet in the First Mile Copper (EFMCu) interfaces;
defined in ITU-T recommendations G.998.1 [G.998.1], G.998.2 [G.998.2]
and G.998.3 [G.998.3] are prime examples of the stacked interfaces,
which MAY require the management information about the cross-connect
capability.
The previous version of this document, RFC 5066 [RFC5066], defined IF-CAP-STACK-MIB, with a set of objects describing cross-connect
EFM-CU-MIB module along with the relevant descriptive text. This capability of a managed device with multi-layer (stacked)
version removes the entire EFM-CU-MIB module along with the relevant interfaces, extending the stack management objects in the
descriptive text. That MIB module will be part of a separate Interfaces Group MIB and the Inverted Stack Table MIB modules.
document, maintained by the Institute of Electrical and Electronics
Engineers (IEEE) 802.3 working group. In addition the Security With the conclusion of the [HUBMIB] working group, the responsibility
Considerations section was updated to conform to the latest for the maintenance and further development of the EFM-CU-MIB module
recommended boilerplate text, along with the relevant references. has been transfered to the Institute of Electrical and Electronics
Engineers (IEEE) [802.3] working group. In 2011 the IEEE developed
IEEE8023-EFM-CU-MIB module, defined in IEEE Std 802.3.1-2011
[802.3.1] and based on the EFM-CU-MIB, defined in RFC 5066.
The IEEE8023-EFM-CU-MIB and EFM-CU-MIB are both valid MIB modules,
which can coexist.
Please note that IF-CAP-STACK-MIB module was not transfered to IEEE
and remains as defined in RFC 5066. This memo provides an updated
security considerations section for that module.
2. The Internet-Standard Management Framework 2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410]. RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies MIB
modules that are compliant to the SMIv2, which is described in STD
58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC
2580 [RFC2580].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
3. Relation to Other MIB Modules 3. Mapping between EFM-CU-MIB and IEEE8023-EFM-CU-MIB
This section outlines the relationship of the MIB modules defined in
this document with other MIB modules described in the relevant RFCs.
Specifically, the Ethernet in the First Mile Copper (EFMCu)
Interfaces MIB (EFM-CU-MIB) and the Interfaces Group MIB (IF-MIB)
module are discussed.
3.1. Relation to the EFMCu Interfaces MIB Module
The EFM-CU-MIB module defined in [RFC5066], along with the relevant
descriptive text, is now moved to a separate, IEEE maintained
document, IEEE Std 802.3.1-2011 [802.3.1], which also renamed the
EFM-CU-MIB to IEEE8023-EFM-CU-MIB.
3.2. Relation to Interfaces Group MIB Module
Stacked (a.k.a. aggregated or bonded) interfaces are managed using
generic interface management objects defined in the IF-MIB [RFC2863].
The stack management (i.e., actual connection of the sub-layers to
the top-layer interface) is done via the ifStackTable, as defined in
the IF-MIB [RFC2863], and its inverse ifInvStackTable, as defined in
the IF-INVERTED-STACK-MIB [RFC2864].
The new tables ifCapStackTable and its inverse ifInvCapStackTable
defined in the IF-CAP-STACK-MIB module below, extend the stack
management with an ability to describe possible connections or cross-
connect capability, when a flexible cross-connect matrix is present
between the interface layers.
3.2.1. ifCapStackTable usage example for bonded xDSL interfaces
An bonded xDSL interface, for example IEEE 2BASE-TL or 10PASS-TS or
ITU-T G.998.2 interface, can aggregate or bond a number of individual
xDSL interfaces, referred to as Physical Medium Entity (PME) sub-
layer devices in IEEE 802.3 or Bonding Channel Entity (BCE) in ITU-T
G.998.
A generic bonded xDSL multiport device can have a number of bonded
xDSL interfaces, referred to as Physical Coding Sublayer (PCS) in
IEEE 802.3 or Generic Bonding Sublayer (GBS) in ITU-T G.998, cross-
connected, via a configurable cross-connect fabric, to a number of
underlying PMEs/BCEs, with a single PCS/GBS per PME/GBE relationship.
The ifStackTable is indexed by the ifIndex values of the bonded PCS/
GBS interface and the PMEs/BCEs connected to it. The ifStackTable
allows a Network Management application to determine which PMEs/BCEs
are connected to a particular PCS/GBS and change connections (if
supported by the application). The ifInvStackTable, being an
inverted version of the ifStackTable, provides an efficient means for
a Network Management application to read a subset of the ifStackTable
and thereby determine which PCS/GBS runs on top of a particular PME/
GBE.
A new table ifCapStackTable, defined in the IF-CAP-STACK-MIB module,
specifies for each higher-layer interface (e.g., PCS/GBS port) a list
of lower-layer interfaces (e.g., PMEs/BCEs), which can possibly be
cross-connected to that higher-layer interface, determined by the
cross-connect capability of the device. This table, modeled after
ifStackTable, is read-only, reflecting current cross-connect
capability of stacked interface, which can be dynamic in some
implementations (e.g., if PMEs/BCEs are located on a pluggable module
and the module is pulled out). Note that PME/BCE availability per
PCS/GBS, described by ifCapStackTable, can be constrained by other
parameters, for example, by aggregation capacity of a PCS/GBS or by
the PME/BCE in question being already connected to another PCS/GBS.
So, in order to ensure that a particular PME/BCE can be connected to
the PCS/GBS, all objects related to interface stacking (e.g., the
objects in ifCapStackTable and ifStackTable) SHALL be inspected.
The ifInvCapStackTable, also defined in the IF-CAP-STACK-MIB module,
describes which higher-layer interfaces (e.g., PCS/GPS) can possibly
be connected to a particular lower-layer interface (e.g., PME/BCE),
providing an inverted mapping of the ifCapStackTable. While it
contains no additional information beyond that already contained in
the ifCapStackTable, the ifInvCapStackTable has the ifIndex values in
its INDEX clause in the reverse order, i.e., the lower-layer
interface first, and the higher-layer interface second, providing an
efficient means for a Network Management application to read a subset
of the ifCapStackTable and thereby determine which interfaces can be
connected to run on top of a particular interface.
4. MIB Structure
4.1. Interface Stack Capability MIB Overview
The IF-CAP-STACK-MIB module contains 2 tables:
o ifCapStackTable - containing objects that define possible
relationships among the sub-layers of an interface with flexible
cross-connect (cross-connect capability).
o ifInvCapStackTable - an inverse of the ifCapstackTable.
5. Interface Stack Capability MIB Definitions
The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578],
SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], and IF-
INVERTED-STACK-MIB [RFC2864].
Additionally, this MIB module makes reference to [RFC4181].
IF-CAP-STACK-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, mib-2
FROM SNMPv2-SMI -- [RFC2578]
TruthValue
FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE, OBJECT-GROUP
FROM SNMPv2-CONF -- [RFC2580]
ifStackGroup2, ifStackHigherLayer, ifStackLowerLayer
FROM IF-MIB -- [RFC2863]
ifInvStackGroup
FROM IF-INVERTED-STACK-MIB -- [RFC2864]
;
ifCapStackMIB MODULE-IDENTITY
LAST-UPDATED "201301070000Z" -- January 07, 2013
ORGANIZATION "IETF Operations and Management Area Working Group"
CONTACT-INFO
"WG charter:
http://datatracker.ietf.org/wg/opsawg/charter/
Mailing Lists:
General Discussion: opsawg@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/opsawg
Chair: Scott Bradner
EMail: sob@harvard.edu
Chair: Chris Liljenstolpe
EMail: christopher.liljenstolpe@bigswitch.com
Chair: Melinda Shore
EMail: melinda.shore@gmail.com
Editor: Edward Beili
Postal: Actelis Networks Inc.
25 Bazel St., P.O.B. 10173
Petach-Tikva 10173
Israel
Phone: +972-3-924-3491
EMail: edward.beili@actelis.com"
DESCRIPTION
"The objects in this MIB module are used to describe
cross-connect capabilities of stacked (layered) interfaces,
complementing ifStackTable and ifInvStackTable defined in
IF-MIB and IF-INVERTED-STACK-MIB, respectively.
Copyright (C) The IETF Trust (2013). This version
of this MIB module is part of RFC XXXX; see the RFC
itself for full legal notices."
REVISION "200711070000Z" -- November 07, 2007
DESCRIPTION "Initial version, published as RFC 5066."
REVISION "201301070000Z" -- January 07, 2013
DESCRIPTION "Re-published as RFC XXXX. EFM-CU-MIB has been
relocated to IEEE Std. 802.3.1. Since HUBMIB
WG has been concluded, the IF-CAP-STACK-MIB
is now maintained by OPSAWG."
-- EdNote: Replace XXXX with the actual RFC number &
-- remove this note
::= { mib-2 166 }
-- Sections of the module
-- Structured as recommended by [RFC4181], see
-- Appendix D: Suggested OID Layout
ifCapStackObjects OBJECT IDENTIFIER ::= { ifCapStackMIB 1 }
ifCapStackConformance OBJECT IDENTIFIER ::= { ifCapStackMIB 2 }
-- Groups in the module
--
-- ifCapStackTable group
--
ifCapStackTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfCapStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table, modeled after ifStackTable from IF-MIB,
contains information on the possible 'on-top-of'
relationships between the multiple sub-layers of network
interfaces (as opposed to actual relationships described in
ifStackTable). In particular, it contains information on
which sub-layers MAY possibly run 'on top of' which other
sub-layers, as determined by cross-connect capability of the
device, where each sub-layer corresponds to a conceptual row
in the ifTable. For example, when the sub-layer with ifIndex
value x can be connected to run on top of the sub-layer with
ifIndex value y, then this table contains:
ifCapStackStatus.x.y=true
The ifCapStackStatus.x.y row does not exist if it is
impossible to connect between the sub-layers x and y.
Note that for most stacked interfaces (e.g., 2BASE-TL)
there's always at least one higher-level interface (e.g., PCS
port) for each lower-level interface (e.g., PME) and at
least one lower-level interface for each higher-level
interface, that is, there is at least a single row with a
'true' status for any such existing value of x or y.
This table is read-only as it describes device capabilities."
REFERENCE
"IF-MIB, ifStackTable"
::= { ifCapStackObjects 1 }
ifCapStackEntry OBJECT-TYPE
SYNTAX IfCapStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a particular relationship between two
sub-layers, specifying that one sub-layer MAY possibly run
on 'top' of the other sub-layer. Each sub-layer corresponds
to a conceptual row in the ifTable (interface index for
lower and higher layer, respectively)."
INDEX {
ifStackHigherLayer,
ifStackLowerLayer
}
::= { ifCapStackTable 1 }
IfCapStackEntry ::= SEQUENCE {
ifCapStackStatus TruthValue
}
ifCapStackStatus OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The status of the 'cross-connect capability' relationship
between two sub-layers. The following values can be returned:
true(1) - indicates that the sub-layer interface,
identified by the ifStackLowerLayer MAY
be connected to run 'below' the sub-layer
interface, identified by the
ifStackHigherLayer index.
false(2) - the sub-layer interfaces cannot be
connected temporarily due to
unavailability of the interface(s), e.g.,
one of the interfaces is located on an
absent pluggable module.
Note that lower-layer interface availability per higher-layer,
indicated by the value of 'true', can be constrained by
other parameters, for example, by the aggregation capacity of
a higher-layer interface or by the lower-layer interface in
question being already connected to another higher-layer
interface. In order to ensure that a particular sub-layer can
be connected to another sub-layer, all respective objects
(e.g., ifCapStackTable, ifStackTable, and efmCuPAFCapacity for
for EFMCu interfaces) SHALL be inspected.
This object is read-only, unlike ifStackStatus, as it
describes a cross-connect capability."
::= { ifCapStackEntry 1 }
ifInvCapStackTable OBJECT-TYPE
SYNTAX SEQUENCE OF IfInvCapStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A table containing information on the possible relationships
between the multiple sub-layers of network interfaces. This
table, modeled after ifInvStackTable from
IF-INVERTED-STACK-MIB, is an inverse of the ifCapStackTable
defined in this MIB module.
In particular, this table contains information on which
sub-layers MAY run 'underneath' which other sub-layers, where
each sub-layer corresponds to a conceptual row in the ifTable.
For example, when the sub-layer with ifIndex value x MAY be
connected to run underneath the sub-layer with ifIndex value
y, then this table contains:
ifInvCapStackStatus.x.y=true
This table contains exactly the same number of rows as the
ifCapStackTable, but the rows appear in a different order.
This table is read-only as it describes a cross-connect
capability."
REFERENCE
"IF-INVERTED-STACK-MIB, ifInvStackTable"
::= { ifCapStackObjects 2 }
ifInvCapStackEntry OBJECT-TYPE
SYNTAX IfInvCapStackEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Information on a particular relationship between two sub-
layers, specifying that one sub-layer MAY run underneath the
other sub-layer. Each sub-layer corresponds to a conceptual
row in the ifTable."
INDEX { ifStackLowerLayer, ifStackHigherLayer }
::= { ifInvCapStackTable 1 }
IfInvCapStackEntry ::= SEQUENCE {
ifInvCapStackStatus TruthValue
}
ifInvCapStackStatus OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The status of the possible 'cross-connect capability'
relationship between two sub-layers.
An instance of this object exists for each instance of the
ifCapStackStatus object, and vice versa. For example, if the
variable ifCapStackStatus.H.L exists, then the variable
ifInvCapStackStatus.L.H must also exist, and vice versa. In
addition, the two variables always have the same value.
The ifInvCapStackStatus object is read-only, as it describes
a cross-connect capability."
REFERENCE
"ifCapStackStatus"
::= { ifInvCapStackEntry 1 }
--
-- Conformance Statements
--
ifCapStackGroups OBJECT IDENTIFIER ::=
{ ifCapStackConformance 1 }
ifCapStackCompliances OBJECT IDENTIFIER ::=
{ ifCapStackConformance 2 }
-- Units of Conformance
ifCapStackGroup OBJECT-GROUP
OBJECTS {
ifCapStackStatus,
ifInvCapStackStatus
}
STATUS current
DESCRIPTION
"A collection of objects providing information on the
cross-connect capability of multi-layer (stacked) network
interfaces."
::= { ifCapStackGroups 1 }
-- Compliance Statements
ifCapStackCompliance MODULE-COMPLIANCE The initial version of IEEE8023-EFM-CU-MIB, defined in IEEE Std
STATUS current 802.3.1-2011, has MODULE-IDENTITY of ieee8023efmCuMIB with an object
DESCRIPTION identifier allocated under the { org ieee standards-association-
"The compliance statement for SNMP entities, which provide numbers-series-standards lan-man-stds ieee802dot3 ieee802dot3dot1mibs
information on the cross-connect capability of multi-layer } sub-tree.
(stacked) network interfaces, with flexible cross-connect
between the sub-layers."
MODULE -- this module The EFM-CU-MIB has MODULE-IDENTITY of efmCuMIB with an object
MANDATORY-GROUPS { identifier allocated under the mib-2 sub-tree.
ifCapStackGroup
}
OBJECT ifCapStackStatus The names of the objects in IEEE8023-EFM-CU-MIB are identical to
SYNTAX TruthValue { true(1) } those in EFM-CU-MIB. However, since both MIB modules have different
DESCRIPTION OID values, they can coexist, allowing the management of the newer
"Support for the false(2) value is OPTIONAL for IEEE MIB-based devices, alongside the legacy IETF MIB-based devices.
implementations supporting pluggable interfaces."
OBJECT ifInvCapStackStatus 4. Updating the MIB Modules
SYNTAX TruthValue { true(1) }
DESCRIPTION
"Support for the false(2) value is OPTIONAL for
implementations supporting pluggable interfaces."
MODULE IF-MIB With the transfer of the responsibility for maintenance and further
MANDATORY-GROUPS { development of the EFM-CU-MIB module to the IEEE 802.3 working group,
ifStackGroup2 the EFM-CU-MIB defined in RFC 5066 becomes the last valid version of
} that MIB.
MODULE IF-INVERTED-STACK-MIB All further development of the EFM Copper Interfaces MIB will be done
MANDATORY-GROUPS { by the IEEE 802.3 working group in the IEEE8023-EFM-CU-MIB module.
ifInvStackGroup Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD
} be sent to the IEEE 803.3.1 task force mailing list:
[stds-802-3-mib@listserv.ieee.org].
::= { ifCapStackCompliances 1 } The IF-CAP-STACK-MIB remains under IETF jurisdiction and is
END maintained by the [OPSAWG] working group.
6. Security Considerations 5. Security Considerations
There are no managed objects defined in this MIB module with a MAX- There are no managed objects defined in IF-CAP-STACK-MIB module with
ACCESS clause of read-write and/or read-create. a MAX-ACCESS clause of read-write and/or read-create.
Some of the readable objects in this MIB module (i.e., those with Some of the readable objects in this MIB module (i.e., those with
MAX-ACCESS other than not-accessible) may be considered sensitive or MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments since they can reveal some vulnerable in some network environments since they can reveal some
configuration aspects of the network interfaces. configuration aspects of the network interfaces.
In particular, ifCapStackStatus and ifInvCapStackStatus can identify In particular, ifCapStackStatus and ifInvCapStackStatus can identify
cross-connect capability of multi-layer (stacked) network interfaces, cross-connect capability of multi-layer (stacked) network interfaces,
potentially revealing the underlying hardware architecture of the potentially revealing the underlying hardware architecture of the
managed device. managed device.
skipping to change at page 13, line 5 skipping to change at page 5, line 18
[RFC5592] or TLS/DTLS [RFC6353]. [RFC5592] or TLS/DTLS [RFC6353].
Further, deployment of SNMP versions prior to SNMPv3 is NOT Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them. rights to indeed GET or SET (change/create/delete) them.
7. IANA Considerations 6. IANA Considerations
No action is required from IANA as the OID for ifCapStackMIB MODULE-
IDENTITY was already allocated in [RFC5066].
8. Acknowledgments
This document was produced by the [OPSAWG] working group, whose
efforts were greatly advanced by the contributions of the following
people (in alphabetical order):
Dan Romascanu (Avaya)
This document is based on the RFC 5066, authored by Edward Beili of
Actelis Networks, and produced by the, now concluded, [HUBMIB]
working group.
9. References
9.1. Normative References No action is required from IANA.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 7. Acknowledgments
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. This document was produced by the OPSAWG working group, whose efforts
Schoenwaelder, Ed., "Structure of Management Information were advanced by the contributions of the following people (in
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. alphabetical order):
[RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. Dan Romascanu
Schoenwaelder, Ed., "Textual Conventions for SMIv2",
STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, David Harrington
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group Michael MacFaden
MIB", RFC 2863, June 2000.
[RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table This document updates RFC 5066, authored by Edward Beili of Actelis
Extension to the Interfaces Group MIB", RFC 2864, Networks, and produced by the, now concluded, HUBMIB working group.
June 2000.
[RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 8. References
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The 8.1. Normative References
Advanced Encryption Standard (AES) Cipher Algorithm in the
SNMP User-based Security Model", RFC 3826, June 2004.
9.2. Informative References [RFC2119] Bradner, S., "Key words for use
in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
[802.3] IEEE, "IEEE Standard for Information technology - [RFC3414] Blumenthal, U. and B. Wijnen,
Telecommunications and information exchange between "User-based Security Model (USM)
systems - Local and metropolitan area networks - Specific for version 3 of the Simple
requirements - Part 3: Carrier Sense Multiple Access with Network Management Protocol
Collision Detection (CSMA/CD) Access Method and Physical (SNMPv3)", STD 62, RFC 3414,
Layer Specifications", IEEE Std 802.3-2008, December 2008. December 2002.
[802.3.1] IEEE, "IEEE Standard for Management Information Base (MIB) [RFC3826] Blumenthal, U., Maino, F., and K.
Definitions for Ethernet", IEEE Std 802.3.1-2011, McCloghrie, "The Advanced
July 2011. Encryption Standard (AES) Cipher
Algorithm in the SNMP User-based
Security Model", RFC 3826,
June 2004.
[G.998.1] ITU-T, "ATM-based multi-pair bonding", ITU-T 8.2. Informative References
Recommendation G.998.1, January 2005,
<http://www.itu.int/rec/T-REC-G.998.1/en>.
[G.998.2] ITU-T, "Ethernet-based multi-pair bonding", ITU-T [802.3] IEEE, "802.3 Ethernet Working
Recommendation G.998.2, January 2005, Group",
<http://www.itu.int/rec/T-REC-G.998.2/en>. <http://www.ieee802.org/3>.
[G.998.3] ITU-T, "Multi-pair bonding using time-division inverse [802.3.1] IEEE, "IEEE Standard for
multiplexing", ITU-T Recommendation G.998.3, January 2005, Management Information Base (MIB)
<http://www.itu.int/rec/T-REC-G.998.3/en>. Definitions for Ethernet", IEEE
Std 802.3.1-2011, July 2011.
[HUBMIB] IETF, "Ethernet Interfaces and Hub MIB (hubmib) Charter", [HUBMIB] IETF, "Ethernet Interfaces and
<http://datatracker.ietf.org/wg/hubmib/charter/>. Hub MIB (hubmib) Charter", <http:
//datatracker.ietf.org/wg/hubmib/
charter/>.
[OPSAWG] IETF, "Operations and Management Area Working Group [OPSAWG] IETF, "Operations and Management
(opsawg) Charter", Area Working Group (opsawg)
<http://datatracker.ietf.org/wg/opsawg/charter/>. Charter", <http://
datatracker.ietf.org/wg/opsawg/
charter/>.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, [RFC3410] Case, J., Mundy, R., Partain, D.,
"Introduction and Applicability Statements for Internet- and B. Stewart, "Introduction and
Standard Management Framework", RFC 3410, December 2002. Applicability Statements for
Internet-Standard Management
Framework", RFC 3410,
December 2002.
[RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB [RFC5066] Beili, E., "Ethernet in the First
Documents", BCP 111, RFC 4181, September 2005. Mile Copper (EFMCu) Interfaces
MIB", RFC 5066, November 2007.
[RFC5066] Beili, E., "Ethernet in the First Mile Copper (EFMCu) [RFC5591] Harrington, D. and W. Hardaker,
Interfaces MIB", RFC 5066, November 2007. "Transport Security Model for the
Simple Network Management
Protocol (SNMP)", RFC 5591,
June 2009.
[RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model [RFC5592] Harrington, D., Salowey, J., and
for the Simple Network Management Protocol (SNMP)", W. Hardaker, "Secure Shell
RFC 5591, June 2009. Transport Model for the Simple
Network Management Protocol
(SNMP)", RFC 5592, June 2009.
[RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure [RFC6353] Hardaker, W., "Transport Layer
Shell Transport Model for the Simple Network Management Security (TLS) Transport Model
Protocol (SNMP)", RFC 5592, June 2009. for the Simple Network Management
Protocol (SNMP)", RFC 6353,
July 2011.
[RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport [stds-802-3-mib@listserv.ieee.org] IEEE, "802.3 MIB Email
Model for the Simple Network Management Protocol (SNMP)", Reflector", <http://
RFC 6353, July 2011. www.ieee802.org/3/be/
reflector.html>.
Author's Address Author's Address
Edward Beili Edward Beili
Actelis Networks Actelis Networks
Bazel 25 Bazel 25
Petach-Tikva Petach-Tikva
Israel Israel
Phone: +972-3-924-3491 Phone: +972-3-924-3491
 End of changes. 44 change blocks. 
529 lines changed or deleted 142 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/