idnits 2.17.1 draft-ietf-opsawg-rfc5066bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 07, 2013) is 4121 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Beili 3 Internet-Draft Actelis Networks 4 Obsoletes: 5066 (if approved) January 07, 2013 5 Intended status: Standards Track 6 Expires: July 11, 2013 8 Interface Stack Capability MIB 9 draft-ietf-opsawg-rfc5066bis-01.txt 11 Abstract 13 This document defines Management Information Base (MIB) module for 14 use with network management protocols in TCP/IP-based internets. 15 This document defines a set of objects, describing cross-connect 16 capability of a managed device with multi-layer (stacked) interfaces, 17 extending the stack management objects in the Interfaces Group MIB 18 and the Inverted Stack Table MIB modules. This document obsoletes 19 RFC 5066. It amends that specification by taking out the entire EFM- 20 CU-MIB module along with the relevant descriptive text. That MIB 21 module will be part of a separate document, maintained by the 22 Institute of Electrical and Electronics Engineers (IEEE) 802.3 23 working group. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 11, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. The Internet-Standard Management Framework . . . . . . . . . . 3 61 3. Relation to Other MIB Modules . . . . . . . . . . . . . . . . 3 62 3.1. Relation to the EFMCu Interfaces MIB Module . . . . . . . 4 63 3.2. Relation to Interfaces Group MIB Module . . . . . . . . . 4 64 3.2.1. ifCapStackTable usage example for bonded xDSL 65 interfaces . . . . . . . . . . . . . . . . . . . . . . 4 66 4. MIB Structure . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.1. Interface Stack Capability MIB Overview . . . . . . . . . 5 68 5. Interface Stack Capability MIB Definitions . . . . . . . . . . 5 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 This memo defines a Management Information Base (MIB) module for use 79 with network management protocols in the Internet community, 80 describing the cross-connect capability of a stacked interface. 82 2BASE-TL and 10PASS-TS physical interfaces, defined in the IEEE 83 Standard 802.3 [802.3], as well the xDSL Multi-Pair Bonded interfaces 84 defined in ITU-T recommendations G.998.1 [G.998.1], G.998.2 [G.998.2] 85 and G.998.3 [G.998.3] are prime examples of the stacked interfaces, 86 which MAY require the management information about the cross-connect 87 capability. 89 The previous version of this document, RFC 5066 [RFC5066], defined 90 EFM-CU-MIB module along with the relevant descriptive text. This 91 version removes the entire EFM-CU-MIB module along with the relevant 92 descriptive text. That MIB module will be part of a separate 93 document, maintained by the Institute of Electrical and Electronics 94 Engineers (IEEE) 802.3 working group. In addition the Security 95 Considerations section was updated to conform to the latest 96 recommended boilerplate text, along with the relevant references. 98 2. The Internet-Standard Management Framework 100 For a detailed overview of the documents that describe the current 101 Internet-Standard Management Framework, please refer to section 7 of 102 RFC 3410 [RFC3410]. 104 Managed objects are accessed via a virtual information store, termed 105 the Management Information Base or MIB. MIB objects are generally 106 accessed through the Simple Network Management Protocol (SNMP). 107 Objects in the MIB are defined using the mechanisms defined in the 108 Structure of Management Information (SMI). This memo specifies MIB 109 modules that are compliant to the SMIv2, which is described in STD 110 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 111 2580 [RFC2580]. 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in RFC 116 2119 [RFC2119]. 118 3. Relation to Other MIB Modules 120 This section outlines the relationship of the MIB modules defined in 121 this document with other MIB modules described in the relevant RFCs. 122 Specifically, the Ethernet in the First Mile Copper (EFMCu) 123 Interfaces MIB (EFM-CU-MIB) and the Interfaces Group MIB (IF-MIB) 124 module are discussed. 126 3.1. Relation to the EFMCu Interfaces MIB Module 128 The EFM-CU-MIB module defined in [RFC5066], along with the relevant 129 descriptive text, is now moved to a separate, IEEE maintained 130 document, IEEE Std 802.3.1-2011 [802.3.1], which also renamed the 131 EFM-CU-MIB to IEEE8023-EFM-CU-MIB. 133 3.2. Relation to Interfaces Group MIB Module 135 Stacked (a.k.a. aggregated or bonded) interfaces are managed using 136 generic interface management objects defined in the IF-MIB [RFC2863]. 138 The stack management (i.e., actual connection of the sub-layers to 139 the top-layer interface) is done via the ifStackTable, as defined in 140 the IF-MIB [RFC2863], and its inverse ifInvStackTable, as defined in 141 the IF-INVERTED-STACK-MIB [RFC2864]. 143 The new tables ifCapStackTable and its inverse ifInvCapStackTable 144 defined in the IF-CAP-STACK-MIB module below, extend the stack 145 management with an ability to describe possible connections or cross- 146 connect capability, when a flexible cross-connect matrix is present 147 between the interface layers. 149 3.2.1. ifCapStackTable usage example for bonded xDSL interfaces 151 An bonded xDSL interface, for example IEEE 2BASE-TL or 10PASS-TS or 152 ITU-T G.998.2 interface, can aggregate or bond a number of individual 153 xDSL interfaces, referred to as Physical Medium Entity (PME) sub- 154 layer devices in IEEE 802.3 or Bonding Channel Entity (BCE) in ITU-T 155 G.998. 157 A generic bonded xDSL multiport device can have a number of bonded 158 xDSL interfaces, referred to as Physical Coding Sublayer (PCS) in 159 IEEE 802.3 or Generic Bonding Sublayer (GBS) in ITU-T G.998, cross- 160 connected, via a configurable cross-connect fabric, to a number of 161 underlying PMEs/BCEs, with a single PCS/GBS per PME/GBE relationship. 163 The ifStackTable is indexed by the ifIndex values of the bonded PCS/ 164 GBS interface and the PMEs/BCEs connected to it. The ifStackTable 165 allows a Network Management application to determine which PMEs/BCEs 166 are connected to a particular PCS/GBS and change connections (if 167 supported by the application). The ifInvStackTable, being an 168 inverted version of the ifStackTable, provides an efficient means for 169 a Network Management application to read a subset of the ifStackTable 170 and thereby determine which PCS/GBS runs on top of a particular PME/ 171 GBE. 173 A new table ifCapStackTable, defined in the IF-CAP-STACK-MIB module, 174 specifies for each higher-layer interface (e.g., PCS/GBS port) a list 175 of lower-layer interfaces (e.g., PMEs/BCEs), which can possibly be 176 cross-connected to that higher-layer interface, determined by the 177 cross-connect capability of the device. This table, modeled after 178 ifStackTable, is read-only, reflecting current cross-connect 179 capability of stacked interface, which can be dynamic in some 180 implementations (e.g., if PMEs/BCEs are located on a pluggable module 181 and the module is pulled out). Note that PME/BCE availability per 182 PCS/GBS, described by ifCapStackTable, can be constrained by other 183 parameters, for example, by aggregation capacity of a PCS/GBS or by 184 the PME/BCE in question being already connected to another PCS/GBS. 185 So, in order to ensure that a particular PME/BCE can be connected to 186 the PCS/GBS, all objects related to interface stacking (e.g., the 187 objects in ifCapStackTable and ifStackTable) SHALL be inspected. 189 The ifInvCapStackTable, also defined in the IF-CAP-STACK-MIB module, 190 describes which higher-layer interfaces (e.g., PCS/GPS) can possibly 191 be connected to a particular lower-layer interface (e.g., PME/BCE), 192 providing an inverted mapping of the ifCapStackTable. While it 193 contains no additional information beyond that already contained in 194 the ifCapStackTable, the ifInvCapStackTable has the ifIndex values in 195 its INDEX clause in the reverse order, i.e., the lower-layer 196 interface first, and the higher-layer interface second, providing an 197 efficient means for a Network Management application to read a subset 198 of the ifCapStackTable and thereby determine which interfaces can be 199 connected to run on top of a particular interface. 201 4. MIB Structure 203 4.1. Interface Stack Capability MIB Overview 205 The IF-CAP-STACK-MIB module contains 2 tables: 207 o ifCapStackTable - containing objects that define possible 208 relationships among the sub-layers of an interface with flexible 209 cross-connect (cross-connect capability). 211 o ifInvCapStackTable - an inverse of the ifCapstackTable. 213 5. Interface Stack Capability MIB Definitions 215 The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], 216 SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], IF-MIB [RFC2863], and IF- 217 INVERTED-STACK-MIB [RFC2864]. 219 Additionally, this MIB module makes reference to [RFC4181]. 221 IF-CAP-STACK-MIB DEFINITIONS ::= BEGIN 223 IMPORTS 224 MODULE-IDENTITY, OBJECT-TYPE, mib-2 225 FROM SNMPv2-SMI -- [RFC2578] 226 TruthValue 227 FROM SNMPv2-TC -- [RFC2579] 228 MODULE-COMPLIANCE, OBJECT-GROUP 229 FROM SNMPv2-CONF -- [RFC2580] 230 ifStackGroup2, ifStackHigherLayer, ifStackLowerLayer 231 FROM IF-MIB -- [RFC2863] 232 ifInvStackGroup 233 FROM IF-INVERTED-STACK-MIB -- [RFC2864] 234 ; 236 ifCapStackMIB MODULE-IDENTITY 237 LAST-UPDATED "201301070000Z" -- January 07, 2013 238 ORGANIZATION "IETF Operations and Management Area Working Group" 239 CONTACT-INFO 240 "WG charter: 241 http://datatracker.ietf.org/wg/opsawg/charter/ 243 Mailing Lists: 244 General Discussion: opsawg@ietf.org 245 To Subscribe: https://www.ietf.org/mailman/listinfo/opsawg 247 Chair: Scott Bradner 248 EMail: sob@harvard.edu 249 Chair: Chris Liljenstolpe 250 EMail: christopher.liljenstolpe@bigswitch.com 251 Chair: Melinda Shore 252 EMail: melinda.shore@gmail.com 254 Editor: Edward Beili 255 Postal: Actelis Networks Inc. 256 25 Bazel St., P.O.B. 10173 257 Petach-Tikva 10173 258 Israel 259 Phone: +972-3-924-3491 260 EMail: edward.beili@actelis.com" 262 DESCRIPTION 263 "The objects in this MIB module are used to describe 264 cross-connect capabilities of stacked (layered) interfaces, 265 complementing ifStackTable and ifInvStackTable defined in 266 IF-MIB and IF-INVERTED-STACK-MIB, respectively. 268 Copyright (C) The IETF Trust (2013). This version 269 of this MIB module is part of RFC XXXX; see the RFC 270 itself for full legal notices." 272 REVISION "200711070000Z" -- November 07, 2007 273 DESCRIPTION "Initial version, published as RFC 5066." 275 REVISION "201301070000Z" -- January 07, 2013 276 DESCRIPTION "Re-published as RFC XXXX. EFM-CU-MIB has been 277 relocated to IEEE Std. 802.3.1. Since HUBMIB 278 WG has been concluded, the IF-CAP-STACK-MIB 279 is now maintained by OPSAWG." 281 -- EdNote: Replace XXXX with the actual RFC number & 282 -- remove this note 284 ::= { mib-2 166 } 286 -- Sections of the module 287 -- Structured as recommended by [RFC4181], see 288 -- Appendix D: Suggested OID Layout 290 ifCapStackObjects OBJECT IDENTIFIER ::= { ifCapStackMIB 1 } 292 ifCapStackConformance OBJECT IDENTIFIER ::= { ifCapStackMIB 2 } 294 -- Groups in the module 296 -- 297 -- ifCapStackTable group 298 -- 300 ifCapStackTable OBJECT-TYPE 301 SYNTAX SEQUENCE OF IfCapStackEntry 302 MAX-ACCESS not-accessible 303 STATUS current 304 DESCRIPTION 305 "This table, modeled after ifStackTable from IF-MIB, 306 contains information on the possible 'on-top-of' 307 relationships between the multiple sub-layers of network 308 interfaces (as opposed to actual relationships described in 309 ifStackTable). In particular, it contains information on 310 which sub-layers MAY possibly run 'on top of' which other 311 sub-layers, as determined by cross-connect capability of the 312 device, where each sub-layer corresponds to a conceptual row 313 in the ifTable. For example, when the sub-layer with ifIndex 314 value x can be connected to run on top of the sub-layer with 315 ifIndex value y, then this table contains: 317 ifCapStackStatus.x.y=true 319 The ifCapStackStatus.x.y row does not exist if it is 320 impossible to connect between the sub-layers x and y. 322 Note that for most stacked interfaces (e.g., 2BASE-TL) 323 there's always at least one higher-level interface (e.g., PCS 324 port) for each lower-level interface (e.g., PME) and at 325 least one lower-level interface for each higher-level 326 interface, that is, there is at least a single row with a 327 'true' status for any such existing value of x or y. 329 This table is read-only as it describes device capabilities." 330 REFERENCE 331 "IF-MIB, ifStackTable" 332 ::= { ifCapStackObjects 1 } 334 ifCapStackEntry OBJECT-TYPE 335 SYNTAX IfCapStackEntry 336 MAX-ACCESS not-accessible 337 STATUS current 338 DESCRIPTION 339 "Information on a particular relationship between two 340 sub-layers, specifying that one sub-layer MAY possibly run 341 on 'top' of the other sub-layer. Each sub-layer corresponds 342 to a conceptual row in the ifTable (interface index for 343 lower and higher layer, respectively)." 344 INDEX { 345 ifStackHigherLayer, 346 ifStackLowerLayer 347 } 348 ::= { ifCapStackTable 1 } 350 IfCapStackEntry ::= SEQUENCE { 351 ifCapStackStatus TruthValue 352 } 354 ifCapStackStatus OBJECT-TYPE 355 SYNTAX TruthValue 356 MAX-ACCESS read-only 357 STATUS current 358 DESCRIPTION 359 "The status of the 'cross-connect capability' relationship 360 between two sub-layers. The following values can be returned: 361 true(1) - indicates that the sub-layer interface, 362 identified by the ifStackLowerLayer MAY 363 be connected to run 'below' the sub-layer 364 interface, identified by the 365 ifStackHigherLayer index. 366 false(2) - the sub-layer interfaces cannot be 367 connected temporarily due to 368 unavailability of the interface(s), e.g., 369 one of the interfaces is located on an 370 absent pluggable module. 372 Note that lower-layer interface availability per higher-layer, 373 indicated by the value of 'true', can be constrained by 374 other parameters, for example, by the aggregation capacity of 375 a higher-layer interface or by the lower-layer interface in 376 question being already connected to another higher-layer 377 interface. In order to ensure that a particular sub-layer can 378 be connected to another sub-layer, all respective objects 379 (e.g., ifCapStackTable, ifStackTable, and efmCuPAFCapacity for 380 for EFMCu interfaces) SHALL be inspected. 382 This object is read-only, unlike ifStackStatus, as it 383 describes a cross-connect capability." 384 ::= { ifCapStackEntry 1 } 386 ifInvCapStackTable OBJECT-TYPE 387 SYNTAX SEQUENCE OF IfInvCapStackEntry 388 MAX-ACCESS not-accessible 389 STATUS current 390 DESCRIPTION 391 "A table containing information on the possible relationships 392 between the multiple sub-layers of network interfaces. This 393 table, modeled after ifInvStackTable from 394 IF-INVERTED-STACK-MIB, is an inverse of the ifCapStackTable 395 defined in this MIB module. 396 In particular, this table contains information on which 397 sub-layers MAY run 'underneath' which other sub-layers, where 398 each sub-layer corresponds to a conceptual row in the ifTable. 399 For example, when the sub-layer with ifIndex value x MAY be 400 connected to run underneath the sub-layer with ifIndex value 401 y, then this table contains: 403 ifInvCapStackStatus.x.y=true 405 This table contains exactly the same number of rows as the 406 ifCapStackTable, but the rows appear in a different order. 408 This table is read-only as it describes a cross-connect 409 capability." 410 REFERENCE 411 "IF-INVERTED-STACK-MIB, ifInvStackTable" 412 ::= { ifCapStackObjects 2 } 414 ifInvCapStackEntry OBJECT-TYPE 415 SYNTAX IfInvCapStackEntry 416 MAX-ACCESS not-accessible 417 STATUS current 418 DESCRIPTION 419 "Information on a particular relationship between two sub- 420 layers, specifying that one sub-layer MAY run underneath the 421 other sub-layer. Each sub-layer corresponds to a conceptual 422 row in the ifTable." 423 INDEX { ifStackLowerLayer, ifStackHigherLayer } 424 ::= { ifInvCapStackTable 1 } 426 IfInvCapStackEntry ::= SEQUENCE { 427 ifInvCapStackStatus TruthValue 428 } 430 ifInvCapStackStatus OBJECT-TYPE 431 SYNTAX TruthValue 432 MAX-ACCESS read-only 433 STATUS current 434 DESCRIPTION 435 "The status of the possible 'cross-connect capability' 436 relationship between two sub-layers. 438 An instance of this object exists for each instance of the 439 ifCapStackStatus object, and vice versa. For example, if the 440 variable ifCapStackStatus.H.L exists, then the variable 441 ifInvCapStackStatus.L.H must also exist, and vice versa. In 442 addition, the two variables always have the same value. 444 The ifInvCapStackStatus object is read-only, as it describes 445 a cross-connect capability." 446 REFERENCE 447 "ifCapStackStatus" 448 ::= { ifInvCapStackEntry 1 } 450 -- 451 -- Conformance Statements 452 -- 454 ifCapStackGroups OBJECT IDENTIFIER ::= 455 { ifCapStackConformance 1 } 457 ifCapStackCompliances OBJECT IDENTIFIER ::= 458 { ifCapStackConformance 2 } 460 -- Units of Conformance 461 ifCapStackGroup OBJECT-GROUP 462 OBJECTS { 463 ifCapStackStatus, 464 ifInvCapStackStatus 465 } 466 STATUS current 467 DESCRIPTION 468 "A collection of objects providing information on the 469 cross-connect capability of multi-layer (stacked) network 470 interfaces." 471 ::= { ifCapStackGroups 1 } 473 -- Compliance Statements 475 ifCapStackCompliance MODULE-COMPLIANCE 476 STATUS current 477 DESCRIPTION 478 "The compliance statement for SNMP entities, which provide 479 information on the cross-connect capability of multi-layer 480 (stacked) network interfaces, with flexible cross-connect 481 between the sub-layers." 483 MODULE -- this module 484 MANDATORY-GROUPS { 485 ifCapStackGroup 486 } 488 OBJECT ifCapStackStatus 489 SYNTAX TruthValue { true(1) } 490 DESCRIPTION 491 "Support for the false(2) value is OPTIONAL for 492 implementations supporting pluggable interfaces." 494 OBJECT ifInvCapStackStatus 495 SYNTAX TruthValue { true(1) } 496 DESCRIPTION 497 "Support for the false(2) value is OPTIONAL for 498 implementations supporting pluggable interfaces." 500 MODULE IF-MIB 501 MANDATORY-GROUPS { 502 ifStackGroup2 503 } 505 MODULE IF-INVERTED-STACK-MIB 506 MANDATORY-GROUPS { 507 ifInvStackGroup 508 } 510 ::= { ifCapStackCompliances 1 } 511 END 513 6. Security Considerations 515 There are no managed objects defined in this MIB module with a MAX- 516 ACCESS clause of read-write and/or read-create. 518 Some of the readable objects in this MIB module (i.e., those with 519 MAX-ACCESS other than not-accessible) may be considered sensitive or 520 vulnerable in some network environments since they can reveal some 521 configuration aspects of the network interfaces. 523 In particular, ifCapStackStatus and ifInvCapStackStatus can identify 524 cross-connect capability of multi-layer (stacked) network interfaces, 525 potentially revealing the underlying hardware architecture of the 526 managed device. 528 It is thus important to control even GET access to these objects and 529 possibly even encrypt the values of these objects when sending them 530 over the network via SNMP. 532 SNMP versions prior to SNMPv3 did not include adequate security. 533 Even if the network itself is secure (for example by using IPSec), 534 there is no control as to who on the secure network is allowed to 535 access and GET/SET (read/change/create/delete) the objects in this 536 MIB module. 538 Implementations MUST provide the security features described by the 539 SNMPv3 framework (see [RFC3410]), including full support for 540 authentication and privacy via the User-based Security Model (USM) 541 [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations 542 MAY also provide support for the Transport Security Model (TSM) 543 [RFC5591] in combination with a secure transport such as SSH 544 [RFC5592] or TLS/DTLS [RFC6353]. 546 Further, deployment of SNMP versions prior to SNMPv3 is NOT 547 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 548 enable cryptographic security. It is then a customer/operator 549 responsibility to ensure that the SNMP entity giving access to an 550 instance of this MIB module is properly configured to give access to 551 the objects only to those principals (users) that have legitimate 552 rights to indeed GET or SET (change/create/delete) them. 554 7. IANA Considerations 556 No action is required from IANA as the OID for ifCapStackMIB MODULE- 557 IDENTITY was already allocated in [RFC5066]. 559 8. Acknowledgments 561 This document was produced by the [OPSAWG] working group, whose 562 efforts were greatly advanced by the contributions of the following 563 people (in alphabetical order): 565 Dan Romascanu (Avaya) 567 This document is based on the RFC 5066, authored by Edward Beili of 568 Actelis Networks, and produced by the, now concluded, [HUBMIB] 569 working group. 571 9. References 573 9.1. Normative References 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 579 Schoenwaelder, Ed., "Structure of Management Information 580 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 582 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 583 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 584 STD 58, RFC 2579, April 1999. 586 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 587 "Conformance Statements for SMIv2", STD 58, RFC 2580, 588 April 1999. 590 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 591 MIB", RFC 2863, June 2000. 593 [RFC2864] McCloghrie, K. and G. Hanson, "The Inverted Stack Table 594 Extension to the Interfaces Group MIB", RFC 2864, 595 June 2000. 597 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 598 (USM) for version 3 of the Simple Network Management 599 Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. 601 [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The 602 Advanced Encryption Standard (AES) Cipher Algorithm in the 603 SNMP User-based Security Model", RFC 3826, June 2004. 605 9.2. Informative References 607 [802.3] IEEE, "IEEE Standard for Information technology - 608 Telecommunications and information exchange between 609 systems - Local and metropolitan area networks - Specific 610 requirements - Part 3: Carrier Sense Multiple Access with 611 Collision Detection (CSMA/CD) Access Method and Physical 612 Layer Specifications", IEEE Std 802.3-2008, December 2008. 614 [802.3.1] IEEE, "IEEE Standard for Management Information Base (MIB) 615 Definitions for Ethernet", IEEE Std 802.3.1-2011, 616 July 2011. 618 [G.998.1] ITU-T, "ATM-based multi-pair bonding", ITU-T 619 Recommendation G.998.1, January 2005, 620 . 622 [G.998.2] ITU-T, "Ethernet-based multi-pair bonding", ITU-T 623 Recommendation G.998.2, January 2005, 624 . 626 [G.998.3] ITU-T, "Multi-pair bonding using time-division inverse 627 multiplexing", ITU-T Recommendation G.998.3, January 2005, 628 . 630 [HUBMIB] IETF, "Ethernet Interfaces and Hub MIB (hubmib) Charter", 631 . 633 [OPSAWG] IETF, "Operations and Management Area Working Group 634 (opsawg) Charter", 635 . 637 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 638 "Introduction and Applicability Statements for Internet- 639 Standard Management Framework", RFC 3410, December 2002. 641 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 642 Documents", BCP 111, RFC 4181, September 2005. 644 [RFC5066] Beili, E., "Ethernet in the First Mile Copper (EFMCu) 645 Interfaces MIB", RFC 5066, November 2007. 647 [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model 648 for the Simple Network Management Protocol (SNMP)", 649 RFC 5591, June 2009. 651 [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure 652 Shell Transport Model for the Simple Network Management 653 Protocol (SNMP)", RFC 5592, June 2009. 655 [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport 656 Model for the Simple Network Management Protocol (SNMP)", 657 RFC 6353, July 2011. 659 Author's Address 661 Edward Beili 662 Actelis Networks 663 Bazel 25 664 Petach-Tikva 665 Israel 667 Phone: +972-3-924-3491 668 EMail: edward.beili@actelis.com