Network Working Group                                           E. Beili
Internet-Draft                                          Actelis Networks
Obsoletes:
Updates: 5066 (if approved)                           January 07,                                 May 02, 2013
Intended status: Standards Track
Expires: July 11, November 3, 2013

                     Interface Stack Capability MIB
                  draft-ietf-opsawg-rfc5066bis-01.txt

Abstract

   This document defines Management Information Base (MIB) module for
   use with network management protocols in TCP/IP-based internets.
   This document defines a set of objects, describing cross-connect
   capability of a managed device with multi-layer (stacked) interfaces,
   extending the stack management objects

        Ethernet in the First Mile Copper (EFMCu) Interfaces Group MIB
   and the Inverted Stack Table MIB modules.
                  draft-ietf-opsawg-rfc5066bis-02.txt

Abstract

   This document obsoletes updates RFC 5066.  It amends that specification by taking out
   informing the entire EFM-
   CU-MIB module along with internet community about the transition of the relevant descriptive text.  That EFM-CU-
   MIB module will be part of a separate document, maintained by from the IETF Ethernet Interfaces and Hub MIB Working
   Group to the Institute of Electrical and Electronics Engineers (IEEE)
   802.3 working group.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on July 11, November 3, 2013.

Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  The Internet-Standard Management Framework  . . . . . . . . . . 3
   3.  Relation to Other MIB Modules  . . . . . . . . . .  Mapping between EFM-CU-MIB and IEEE8023-EFM-CU-MIB  . . . . . . 3
     3.1.  Relation to
   4.  Updating the EFMCu Interfaces MIB Module  . . . . . . .  4
     3.2.  Relation to Interfaces Group MIB Module  . . . . . . . . .  4
       3.2.1.  ifCapStackTable usage example for bonded xDSL
               interfaces . . . Modules  . . . . . . . . . . . . . . . . . . . 4
   4.  MIB Structure  . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Interface Stack Capability MIB Overview  . . . . . . . . .  5
   5.  Interface Stack Capability MIB Definitions . . . . . . . . . .  5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . 12
   7. . 4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
   8. . 5
   7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
   9. . 5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     9.1. 5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 13
     9.2. 5
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 14 6

1.  Introduction

   This memo

   RFC 5066 [RFC5066] defines two MIB modules:

      EFM-CU-MIB, with a Management Information Base (MIB) module set of objects for use
   with network management protocols managing 10PASS-TS and
      2BASE-TL Ethernet in the Internet community, First Mile Copper (EFMCu) interfaces;

      IF-CAP-STACK-MIB, with a set of objects describing the cross-connect
      capability of a stacked interface.

   2BASE-TL and 10PASS-TS physical managed device with multi-layer (stacked)
      interfaces, defined in the IEEE
   Standard 802.3 [802.3], as well extending the xDSL Multi-Pair Bonded interfaces
   defined stack management objects in ITU-T recommendations G.998.1 [G.998.1], G.998.2 [G.998.2] the
      Interfaces Group MIB and G.998.3 [G.998.3] are prime examples of the stacked interfaces,
   which MAY require the management information about Inverted Stack Table MIB modules.

   With the cross-connect
   capability.

   The previous version conclusion of this document, RFC 5066 [RFC5066], defined
   EFM-CU-MIB module along with the relevant descriptive text.  This
   version removes [HUBMIB] working group, the entire EFM-CU-MIB module along with responsibility
   for the relevant
   descriptive text.  That MIB module will be part maintenance and further development of a separate
   document, maintained by the EFM-CU-MIB module
   has been transfered to the Institute of Electrical and Electronics
   Engineers (IEEE) 802.3 [802.3] working group.  In addition 2011 the Security
   Considerations section 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 updated to conform not transfered to the latest
   recommended boilerplate text, along with the relevant references. 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

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   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",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

3.  Relation to Other MIB Modules

   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)  Mapping between EFM-CU-MIB and the Interfaces Group MIB (IF-MIB)
   module are discussed.

3.1.  Relation to the EFMCu Interfaces MIB Module IEEE8023-EFM-CU-MIB

   The EFM-CU-MIB module initial version of IEEE8023-EFM-CU-MIB, 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
   802.3.1-2011, has MODULE-IDENTITY of ieee8023efmCuMIB with an object
   identifier allocated under the IF-MIB [RFC2863]. { org ieee standards-association-
   numbers-series-standards lan-man-stds ieee802dot3 ieee802dot3dot1mibs
   } sub-tree.

   The stack management (i.e., actual connection EFM-CU-MIB has MODULE-IDENTITY of efmCuMIB with an object
   identifier allocated under 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. mib-2 sub-tree.

   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 names of the possible 'cross-connect capability'
           relationship between two sub-layers.

           An instance objects in IEEE8023-EFM-CU-MIB are identical to
   those in EFM-CU-MIB.  However, since both MIB modules have different
   OID values, they can coexist, allowing the management of this object exists for each instance the newer
   IEEE MIB-based devices, alongside the legacy IETF MIB-based devices.

4.  Updating the MIB Modules

   With the transfer of the
           ifCapStackStatus object, responsibility for maintenance and vice versa. For example, if further
   development of the
           variable ifCapStackStatus.H.L exists, then EFM-CU-MIB module to the variable
           ifInvCapStackStatus.L.H must also exist, and vice versa.  In
           addition, IEEE 802.3 working group,
   the two variables always have EFM-CU-MIB defined in RFC 5066 becomes 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 last valid version of Conformance
      ifCapStackGroup OBJECT-GROUP
        OBJECTS {
          ifCapStackStatus,
          ifInvCapStackStatus
        }
        STATUS  current
        DESCRIPTION
          "A collection
   that MIB.

   All further development of objects providing information on the
          cross-connect capability of multi-layer (stacked) network
          interfaces."
        ::= { ifCapStackGroups 1 }

     -- Compliance Statements

      ifCapStackCompliance MODULE-COMPLIANCE
        STATUS      current
        DESCRIPTION
          "The compliance statement for SNMP entities, which provide
          information on EFM Copper Interfaces MIB will be done
   by the cross-connect capability of multi-layer
          (stacked) network interfaces, with flexible cross-connect
          between IEEE 802.3 working group in the sub-layers."

        MODULE  -- this module
          MANDATORY-GROUPS {
            ifCapStackGroup
          }

          OBJECT       ifCapStackStatus
          SYNTAX       TruthValue { true(1) }
          DESCRIPTION
            "Support for IEEE8023-EFM-CU-MIB module.
   Requests and comments pertaining to EFM Copper Interfaces MIB SHOULD
   be sent to the false(2) value IEEE 803.3.1 task force mailing list:
   [stds-802-3-mib@listserv.ieee.org].

   The IF-CAP-STACK-MIB remains under IETF jurisdiction and is OPTIONAL for
            implementations supporting pluggable interfaces."

          OBJECT       ifInvCapStackStatus
          SYNTAX       TruthValue { true(1) }
          DESCRIPTION
            "Support for
   maintained by the false(2) value is OPTIONAL for
            implementations supporting pluggable interfaces."

        MODULE  IF-MIB
          MANDATORY-GROUPS {
            ifStackGroup2
          }

        MODULE  IF-INVERTED-STACK-MIB
          MANDATORY-GROUPS {
            ifInvStackGroup
          }

        ::= { ifCapStackCompliances 1 }
   END

6. [OPSAWG] working group.

5.  Security Considerations

   There are no managed objects defined in this MIB IF-CAP-STACK-MIB module with
   a MAX-
   ACCESS MAX-ACCESS clause of read-write and/or read-create.

   Some of the readable objects in this MIB module (i.e., those with
   MAX-ACCESS other than not-accessible) may be considered sensitive or
   vulnerable in some network environments since they can reveal some
   configuration aspects of the network interfaces.

   In particular, ifCapStackStatus and ifInvCapStackStatus can identify
   cross-connect capability of multi-layer (stacked) network interfaces,
   potentially revealing the underlying hardware architecture of the
   managed device.

   It is thus important to control even GET access to these objects and
   possibly even encrypt the values of these objects when sending them
   over the network via SNMP.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPSec),
   there is no control as to who on the secure network is allowed to
   access and GET/SET (read/change/create/delete) the objects in this
   MIB module.

   Implementations MUST provide the security features described by the
   SNMPv3 framework (see [RFC3410]), including full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].  Implementations
   MAY also provide support for the Transport Security Model (TSM)
   [RFC5591] in combination with a secure transport such as SSH
   [RFC5592] or TLS/DTLS [RFC6353].

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

7.

6.  IANA Considerations

   No action is required from IANA as the OID for ifCapStackMIB MODULE-
   IDENTITY was already allocated in [RFC5066].

8. IANA.

7.  Acknowledgments

   This document was produced by the [OPSAWG] OPSAWG working group, whose efforts
   were greatly advanced by the contributions of the following people (in
   alphabetical order):

      Dan Romascanu (Avaya)

      David Harrington

      Michael MacFaden

   This document is based on the updates RFC 5066, authored by Edward Beili of Actelis
   Networks, and produced by the, now concluded, [HUBMIB] HUBMIB working group.

9.

8.  References

9.1.

8.1.  Normative References

   [RFC2119]                           Bradner, S., "Key words for use
                                       in RFCs to Indicate Requirement
                                       Levels", BCP 14, RFC 2119,
                                       March 1997.

   [RFC2578]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Structure of Management Information
              Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [RFC2579]  McCloghrie, K., Ed., Perkins, D., Ed., and J.
              Schoenwaelder, Ed., "Textual Conventions for SMIv2",
              STD 58, RFC 2579, April 1999.

   [RFC2580]  McCloghrie, K., Perkins, D., and J. Schoenwaelder,
              "Conformance Statements for SMIv2", STD 58, RFC 2580,
              April 1999.

   [RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
              MIB", RFC 2863, June 2000.

   [RFC2864]  McCloghrie, K. and G. Hanson, "The Inverted Stack Table
              Extension to the Interfaces Group MIB", RFC 2864,
              June 2000.

   [RFC3414]                           Blumenthal, U. and B. Wijnen,
                                       "User-based Security Model (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 Advanced
                                       Encryption Standard (AES) Cipher
                                       Algorithm in the SNMP User-based
                                       Security Model", RFC 3826,
                                       June 2004.

9.2.

8.2.  Informative References

   [802.3]                             IEEE, "IEEE Standard for Information technology -
              Telecommunications and information exchange between
              systems - Local and metropolitan area networks - Specific
              requirements - Part 3: Carrier Sense Multiple Access with
              Collision Detection (CSMA/CD) Access Method and Physical
              Layer Specifications", IEEE Std 802.3-2008, December 2008. "802.3 Ethernet Working
                                       Group",
                                       <http://www.ieee802.org/3>.

   [802.3.1]                           IEEE, "IEEE Standard for
                                       Management Information Base (MIB)
                                       Definitions for Ethernet", IEEE
                                       Std 802.3.1-2011, July 2011.

   [G.998.1]  ITU-T, "ATM-based multi-pair bonding", ITU-T
              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
              Recommendation G.998.2, January 2005,
              <http://www.itu.int/rec/T-REC-G.998.2/en>.

   [G.998.3]  ITU-T, "Multi-pair bonding using time-division inverse
              multiplexing", ITU-T Recommendation G.998.3, January 2005,
              <http://www.itu.int/rec/T-REC-G.998.3/en>.

   [HUBMIB]                            IETF, "Ethernet Interfaces and
                                       Hub MIB (hubmib) Charter",
              <http://datatracker.ietf.org/wg/hubmib/charter/>. <http:
                                       //datatracker.ietf.org/wg/hubmib/
                                       charter/>.

   [OPSAWG]                            IETF, "Operations and Management
                                       Area Working Group (opsawg)
                                       Charter",
              <http://datatracker.ietf.org/wg/opsawg/charter/>. <http://
                                       datatracker.ietf.org/wg/opsawg/
                                       charter/>.

   [RFC3410]                           Case, J., Mundy, R., Partain, D.,
                                       and B. Stewart, "Introduction and
                                       Applicability Statements for Internet-
              Standard
                                       Internet-Standard Management
                                       Framework", RFC 3410,
                                       December 2002.

   [RFC4181]  Heard, C., "Guidelines for Authors and Reviewers of MIB
              Documents", BCP 111, RFC 4181, September 2005.

   [RFC5066]                           Beili, E., "Ethernet in the First
                                       Mile Copper (EFMCu) Interfaces
                                       MIB", RFC 5066, November 2007.

   [RFC5591]                           Harrington, D. and W. Hardaker,
                                       "Transport Security Model for the
                                       Simple Network Management
                                       Protocol (SNMP)", RFC 5591,
                                       June 2009.

   [RFC5592]                           Harrington, D., Salowey, J., and
                                       W. Hardaker, "Secure Shell
                                       Transport Model for the Simple
                                       Network Management Protocol
                                       (SNMP)", RFC 5592, June 2009.

   [RFC6353]                           Hardaker, W., "Transport Layer
                                       Security (TLS) Transport Model
                                       for the Simple Network Management
                                       Protocol (SNMP)", RFC 6353,
                                       July 2011.

   [stds-802-3-mib@listserv.ieee.org]  IEEE, "802.3 MIB Email
                                       Reflector", <http://
                                       www.ieee802.org/3/be/
                                       reflector.html>.

Author's Address

   Edward Beili
   Actelis Networks
   Bazel 25
   Petach-Tikva
   Israel

   Phone: +972-3-924-3491
   EMail: edward.beili@actelis.com