Network Working Group E. Beili Internet-Draft Actelis Networks Obsoletes: 5066 (if approved) December 25, 2012 Intended status: Standards Track Expires: June 28, 2013 Interface Stack Capability MIB draft-ietf-opsawg-rfc5066bis-00.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 in the Interfaces Group MIB and the Inverted Stack Table MIB modules. This document obsoletes RFC 5066. It amends that specification by moving the entire EFM-CU- MIB module along with the relevant descriptive text, to a separate document, maintained by the Institute of Electrical and Electronics Engineers (IEEE) 802.3.1 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 June 28, 2013. Copyright Notice Copyright (c) 2012 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 Beili Expires June 28, 2013 [Page 1] Internet-Draft If Stack Cap MIB December 2012 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 . . . . . . . . . . . . . . . . 3 3.1. Relation to 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 . . . . . . . . . . . . . . . . . . . . . . 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 Beili Expires June 28, 2013 [Page 2] Internet-Draft If Stack Cap MIB December 2012 1. Introduction This memo defines a Management Information Base (MIB) module for use 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 Standard 802.3 [802.3], as well the xDSL Multi-Pair Bonded 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 EFM-CU-MIB module along with the relevant descriptive text. This version moves the entire EFM-CU-MIB module along with the relevant descriptive text, to a separate document, maintained by the Institute of Electrical and Electronics Engineers (IEEE) 802.3.1 working group. In addition the Security Considerations section was updated to conform to the latest recommended boilerplate text, along with the relevant references. 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", "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) and the Interfaces Group MIB (IF-MIB) module are discussed. Beili Expires June 28, 2013 [Page 3] Internet-Draft If Stack Cap MIB December 2012 3.1. Relation to the EFMCu Interfaces MIB Module The EFM-CU-MIB module defined in the previous version of this document, 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, Beili Expires June 28, 2013 [Page 4] Internet-Draft If Stack Cap MIB December 2012 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 Beili Expires June 28, 2013 [Page 5] Internet-Draft If Stack Cap MIB December 2012 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 "201212250000Z" -- December 25, 2012 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 (2012). This version of this MIB module is part of RFC XXXX; see the RFC itself for full legal notices." Beili Expires June 28, 2013 [Page 6] Internet-Draft If Stack Cap MIB December 2012 REVISION "200711070000Z" -- November 07, 2007 DESCRIPTION "Initial version, published as RFC 5066." REVISION "201212250000Z" -- December 25, 2012 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 Beili Expires June 28, 2013 [Page 7] Internet-Draft If Stack Cap MIB December 2012 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 Beili Expires June 28, 2013 [Page 8] Internet-Draft If Stack Cap MIB December 2012 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 Beili Expires June 28, 2013 [Page 9] Internet-Draft If Stack Cap MIB December 2012 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 { Beili Expires June 28, 2013 [Page 10] Internet-Draft If Stack Cap MIB December 2012 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 STATUS current DESCRIPTION "The compliance statement for SNMP entities, which provide information on the cross-connect capability of multi-layer (stacked) network interfaces, with flexible cross-connect between the sub-layers." MODULE -- this module MANDATORY-GROUPS { ifCapStackGroup } OBJECT ifCapStackStatus SYNTAX TruthValue { true(1) } DESCRIPTION "Support for the false(2) value is OPTIONAL for implementations supporting pluggable interfaces." OBJECT ifInvCapStackStatus SYNTAX TruthValue { true(1) } DESCRIPTION "Support for 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 } Beili Expires June 28, 2013 [Page 11] Internet-Draft If Stack Cap MIB December 2012 ::= { ifCapStackCompliances 1 } END 6. Security Considerations There are no managed objects defined in this MIB module with a 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. IANA Considerations Object identifier 166 for the ifCapStackMIB MODULE-IDENTITY have been allocated by IANA in the MIB-2 sub-tree. Beili Expires June 28, 2013 [Page 12] Internet-Draft If Stack Cap MIB December 2012 8. Acknowledgments This document was produced by the [OPSAWG] working group. 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 [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. 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 Beili Expires June 28, 2013 [Page 13] Internet-Draft If Stack Cap MIB December 2012 Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications", IEEE Std 802.3-2008, December 2008. [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, . [G.998.2] ITU-T, "Ethernet-based multi-pair bonding", ITU-T Recommendation G.998.2, January 2005, . [G.998.3] ITU-T, "Multi-pair bonding using time-division inverse multiplexing", ITU-T Recommendation G.998.3, January 2005, . [HUBMIB] IETF, "Ethernet Interfaces and Hub MIB (hubmib) Charter", . [OPSAWG] IETF, "Operations and Management Area Working Group (opsawg) Charter", . [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for 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. Beili Expires June 28, 2013 [Page 14] Internet-Draft If Stack Cap MIB December 2012 Author's Address Edward Beili Actelis Networks Bazel 25 Petach-Tikva Israel Phone: +972-3-924-3491 EMail: edward.beili@actelis.com Beili Expires June 28, 2013 [Page 15]