idnits 2.17.1 draft-ietf-softwire-map-mib-09.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 (May 27, 2017) is 2525 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) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Y. Fu 3 Internet-Draft CNNIC 4 Intended status: Standards Track S. Jiang 5 Expires: November 28, 2017 B. Liu 6 Huawei Technologies Co., Ltd 7 J. Dong 8 Y. Chen 9 Tsinghua University 10 May 27, 2017 12 Definitions of Managed Objects for MAP-E 13 draft-ietf-softwire-map-mib-09 15 Abstract 17 This memo defines a portion of the Management Information Base (MIB) 18 for using with network management protocols in the Internet 19 community. In particular, it defines managed objects for MAP 20 encapsulation (MAP-E) mode. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on November 28, 2017. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. The Internet-Standard Management Framework . . . . . . . . . 2 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 4. Structure of the MIB Module . . . . . . . . . . . . . . . . . 3 60 4.1. The mapMIBObjects . . . . . . . . . . . . . . . . . . . . 3 61 4.1.1. The mapRule Subtree . . . . . . . . . . . . . . . . . 3 62 4.1.2. The mapSecurityCheck Subtree . . . . . . . . . . . . 3 63 4.2. The mapMIBConformance Subtree . . . . . . . . . . . . . . 4 64 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 70 9.2. Informative References . . . . . . . . . . . . . . . . . 14 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 Mapping of Address and Port (MAP) [RFC7597] is a stateless mechanism 76 for running IPv4 over IPv6-only infrastructure. In particular, it 77 includes two mode, translation mode or encapsulation mode. For the 78 encapsulation mode, it provides an automatic tunnelling mechanism for 79 providing IPv4 connectivity service to end users over a service 80 provider's IPv6 network 82 This document defines a portion of the Management Information Base 83 (MIB) for use with network management protocols in the Internet 84 community. This MIB module would be used for monitoring the devices 85 in the MAP scenario, especially, for the encapsulation mode. 87 2. The Internet-Standard Management Framework 89 For a detailed overview of the documents that describe the current 90 Internet-Standard Management Framework, please refer to section 7 of 91 [RFC3410]. 93 Managed objects are accessed via a virtual information store, termed 94 the Management Information Base or MIB. MIB objects are generally 95 accessed through the Simple Network Management Protocol (SNMP). 96 Objects in the MIB are defined using the mechanisms defined in the 97 Structure of Management Information (SMI). This memo specifies a MIB 98 module that is compliant to the SMIv2, which is described in 99 [RFC2578], [RFC2579] and [RFC2580]. 101 3. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 [RFC2119]. 108 4. Structure of the MIB Module 110 The MAP-E MIB provides a way to manage and monitor the MAP devices in 111 MAP encapsulation mode through SNMP. 113 MAP-E MIB is configurable on a per-interface basis. It depends on 114 several parts of the IF-MIB[RFC2863]. 116 4.1. The mapMIBObjects 118 4.1.1. The mapRule Subtree 120 The mapRule subtree describes managed objects used for managing the 121 multiple mapping rules in the MAP encapsulation mode. 123 According to the MAP specification[RFC7597], the mapping rules are 124 divided into two categories, which are Basic Mapping Rule (BMR), and 125 Forwarding Mapping Rule (FMR). 127 4.1.2. The mapSecurityCheck Subtree 129 The mapSecurityCheck subtree is to statistic the number of invalid 130 packets that have been identified. There are two kind of invalid 131 packets which are defined in the MAP specification [RFC7597]as below. 133 - The Border Relay (BR) will perform a validation of the consistency 134 of the source IPv6 address and source port number for the packet 135 using Basic Mapping Rule (BMR). 137 - The Customer Edge (CE) will check that MAP received packets' 138 transport-layer destination port number is in the range configured by 139 MAP for the CE. 141 4.2. The mapMIBConformance Subtree 143 The mapMIBConformance subtree provides conformance information of MIB 144 objects. 146 5. Definitions 148 The following MIB module imports definitions from [RFC2578], 149 [RFC2579],[RFC2580],[RFC2863], and [RFC4001]. 151 MAP-E-MIB DEFINITIONS ::= BEGIN 153 IMPORTS 154 MODULE-IDENTITY, OBJECT-TYPE, mib-2, 155 Unsigned32, Counter64 156 FROM SNMPv2-SMI --RFC2578 157 TEXTUAL-CONVENTION 158 FROM SNMPv2-TC --RFC2579 159 ifIndex 160 FROM IF-MIB --RFC2863 161 InetAddressIPv6, InetAddressIPv4, 162 InetAddressPrefixLength 163 FROM INET-ADDRESS-MIB --RFC4001 164 OBJECT-GROUP, MODULE-COMPLIANCE 165 FROM SNMPv2-CONF; --RFC2580 167 mapMIB MODULE-IDENTITY 168 LAST-UPDATED "201705270000Z" 169 ORGANIZATION 170 "IETF Softwire Working Group" 171 CONTACT-INFO 172 "Yu Fu 173 CNNIC 174 No.4 South 4th Street, Zhongguancun 175 Beijing, P.R. China 100190 176 EMail: fuyu@cnnic.cn 178 Sheng Jiang 179 Huawei Technologies Co., Ltd 180 Huawei Building, 156 Beiqing Rd., Hai-Dian District 181 Beijing, P.R. China 100095 182 EMail: jiangsheng@huawei.com 184 Bing Liu 185 Huawei Technologies Co., Ltd 186 Huawei Building, 156 Beiqing Rd., Hai-Dian District 187 Beijing, P.R. China 100095 188 EMail: leo.liubing@huawei.com 189 Jiang Dong 190 Tsinghua University 191 Department of Computer Science, Tsinghua University 192 Beijing 100084 193 P.R. China 194 Email: knight.dongjiang@gmail.com 196 Yuchi Chen 197 Tsinghua University 198 Department of Computer Science, Tsinghua University 199 Beijing 100084 200 P.R. China 201 Email: chenycmx@gmail.com" 203 DESCRIPTION 204 "The MIB module is defined for management of objects in the 205 MAP-E BRs or CEs." 206 REVISION "201705270000Z" 207 DESCRIPTION 208 "Initial version. Published as RFC xxxx." 209 --RFC Ed.: RFC-edtitor pls fill in xxxx 210 ::= { mib-2 xxx } 211 --xxx to be replaced withIANA-assigned value 213 mapMIBObjects OBJECT IDENTIFIER ::= {mapMIB 1} 215 mapRule OBJECT IDENTIFIER 216 ::= { mapMIBObjects 1 } 218 mapSecurityCheck OBJECT IDENTIFIER 219 ::= { mapMIBObjects 2 } 221 -- ============================================================== 222 -- Textual Conventions used in this MIB module 223 -- ============================================================== 225 RulePSID ::= TEXTUAL-CONVENTION 226 DISPLAY-HINT "0x:" 227 STATUS current 228 DESCRIPTION 229 "It represents the PSID represented in the hexadecimal version 230 so as to display it more clearly." 231 SYNTAX OCTET STRING (SIZE (4)) 233 RuleType ::= TEXTUAL-CONVENTION 234 STATUS current 235 DESCRIPTION 236 "This enumeration provides the type of the mapping rule. There 237 are two types of mapping rules: Basic Mapping Rule (BMR) and 238 Forwarding Mapping Rule (FMR)." 239 REFERENCE "bmr, fmr: section 5 of RFC 7597" 240 SYNTAX INTEGER { 241 bmr(1), 242 fmr(2) 243 } 245 mapRuleTable OBJECT-TYPE 246 SYNTAX SEQUENCE OF MapRuleEntry 247 MAX-ACCESS not-accessible 248 STATUS current 249 DESCRIPTION 250 "The (conceptual) table containing rule Information of 251 specific mapping rule. It can also be used for row 252 creation." 253 ::= { mapRule 1 } 255 mapRuleEntry OBJECT-TYPE 256 SYNTAX MapRuleEntry 257 MAX-ACCESS not-accessible 258 STATUS current 259 DESCRIPTION 260 "Each entry in this table contains the information on a 261 particular mapping rule." 262 INDEX { mapRuleID } 263 ::= { mapRuleTable 1 } 265 MapRuleEntry ::= 266 SEQUENCE { 267 mapRuleID Unsigned32, 268 mapRuleIPv6Prefix InetAddressIPv6, 269 mapRuleIPv6PrefixLen InetAddressPrefixLength, 270 mapRuleIPv4Prefix InetAddressIPv4, 271 mapRuleIPv4PrefixLen InetAddressPrefixLength, 272 mapRuleBRIPv6Address InetAddressIPv6, 273 mapRulePSID RulePSID, 274 mapRulePSIDLen Unsigned32, 275 mapRuleOffset Unsigned32, 276 mapRuleEALen Unsigned32, 277 mapRuleType RuleType 278 } 280 mapRuleID OBJECT-TYPE 281 SYNTAX Unsigned32 (1..4294967295) 282 MAX-ACCESS not-accessible 283 STATUS current 284 DESCRIPTION 285 "An identifier used to distinguish the multiple mapping 286 rule which is unique with each CE in the same BR." 287 ::= { mapRuleEntry 1 } 289 -- The object mapRuleIPv6Prefix is IPv6 specific and hence it does 290 -- not use the version agnostic InetAddress. 292 mapRuleIPv6Prefix OBJECT-TYPE 293 SYNTAX InetAddressIPv6 294 MAX-ACCESS read-only 295 STATUS current 296 DESCRIPTION 297 "The IPv6 prefix defined in mapping rule which will be 298 assigned to CE. The address type is given by 299 mapRuleIPv6PrefixType." 300 ::= { mapRuleEntry 2 } 302 mapRuleIPv6PrefixLen OBJECT-TYPE 303 SYNTAX InetAddressPrefixLength 304 MAX-ACCESS read-only 305 STATUS current 306 DESCRIPTION 307 "The length of the IPv6 prefix defined in the mapping rule. 308 As a parameter for mapping rule, it will be also assigned 309 to CE." 310 ::= { mapRuleEntry 3 } 312 -- The object mapRuleIPv4Prefix is IPv4 specific and hence it does 313 -- not use the version agnostic InetAddress. 315 mapRuleIPv4Prefix OBJECT-TYPE 316 SYNTAX InetAddressIPv4 317 MAX-ACCESS read-only 318 STATUS current 319 DESCRIPTION 320 " The IPv4 prefix defined in mapping rule which will be 321 assigned to CE. The address type is given by 322 mapRuleIPv4PrefixType." 323 ::= { mapRuleEntry 4 } 325 mapRuleIPv4PrefixLen OBJECT-TYPE 326 SYNTAX InetAddressPrefixLength 327 MAX-ACCESS read-only 328 STATUS current 329 DESCRIPTION 330 "The length of the IPv4 prefix defined in the mapping 331 rule. As a parameter for mapping rule, it will be also 332 assigned to CE." 334 ::= { mapRuleEntry 5 } 336 -- The object mapRuleBRIPv6Address is IPv6 specific and hence it does 337 -- not use the version agnostic InetAddress. 339 mapRuleBRIPv6Address OBJECT-TYPE 340 SYNTAX InetAddressIPv6 341 MAX-ACCESS read-only 342 STATUS current 343 DESCRIPTION 344 "The IPv6 address of the BR which will be 345 conveyed to CE." 346 ::= { mapRuleEntry 6 } 348 mapRulePSID OBJECT-TYPE 349 SYNTAX RulePSID 350 MAX-ACCESS read-only 351 STATUS current 352 DESCRIPTION 353 "The PSID value algorithmically identifies a set of 354 ports assigned to a CE." 355 REFERENCE 356 "PSID: section 5.1 of RFC 7597." 357 ::= { mapRuleEntry 7 } 359 mapRulePSIDLen OBJECT-TYPE 360 SYNTAX Unsigned32(0..16) 361 MAX-ACCESS read-only 362 STATUS current 363 DESCRIPTION 364 "The bit length value of the number of significant bits in 365 the PSID field. When it is set to 0, the PSID 366 field is to be ignored." 367 ::= { mapRuleEntry 8 } 369 mapRuleOffset OBJECT-TYPE 370 SYNTAX Unsigned32(0..15) 371 MAX-ACCESS read-only 372 STATUS current 373 DESCRIPTION 374 "Bit length value of the number of significant bits in 375 the PSID field. When it is set to 0, the PSID 376 field is to be ignored." 377 ::= { mapRuleEntry 9 } 379 mapRuleEALen OBJECT-TYPE 380 SYNTAX Unsigned32 381 MAX-ACCESS read-only 382 STATUS current 383 DESCRIPTION 384 "The length of the Embedded-Address (EA) defined in 385 mapping rule which will be assigned to CE." 386 REFERENCE 387 "EA: section 3 of RFC 7597." 388 ::= { mapRuleEntry 10 } 390 mapRuleType OBJECT-TYPE 391 SYNTAX RuleType 392 MAX-ACCESS read-only 393 STATUS current 394 DESCRIPTION 395 "It represents the type of the mapping rule. the value of 396 1 means it is a bmr; the value 2 means it is a fmr." 397 REFERENCE 398 "bmr, fmr: section 5 of RFC 7597" 399 ::= { mapRuleEntry 11 } 401 mapSecurityCheckTable OBJECT-TYPE 402 SYNTAX SEQUENCE OF MapSecurityCheckEntry 403 MAX-ACCESS not-accessible 404 STATUS current 405 DESCRIPTION 406 "The (conceptual) table containing information on 407 MAP security checks. This table can be used to statistic 408 the number of invalid packets that been identified." 409 ::= { mapSecurityCheck 1 } 411 mapSecurityCheckEntry OBJECT-TYPE 412 SYNTAX MapSecurityCheckEntry 413 MAX-ACCESS not-accessible 414 STATUS current 415 DESCRIPTION 416 "Each entry in this table contains the information on a 417 particular MAP SecurityCheck." 418 INDEX { ifIndex } 419 ::= { mapSecurityCheckTable 1 } 421 MapSecurityCheckEntry ::= 422 SEQUENCE { 423 mapSecurityCheckInvalidv4 Counter64, 424 mapSecurityCheckInvalidv6 Counter64 425 } 427 mapSecurityCheckInvalidv4 OBJECT-TYPE 428 SYNTAX Counter64 429 MAX-ACCESS read-only 430 STATUS current 431 DESCRIPTION 432 "The CE SHOULD check that MAP received packets' 433 transport-layer destination port number is in the range 434 configured by MAP for the CE. So this object indicate 435 the number of the invalid IPv4 packets received by the 436 MAP." 437 ::= { mapSecurityCheckEntry 1 } 439 mapSecurityCheckInvalidv6 OBJECT-TYPE 440 SYNTAX Counter64 441 MAX-ACCESS read-only 442 STATUS current 443 DESCRIPTION 444 "The BR MUST perform a validation of the consistency of 445 the source IPv6 address and source port number for the 446 packet using BMR. So this object indicate the number of 447 the invalid IPv6 packets received by the BR." 448 ::= { mapSecurityCheckEntry 2 } 450 -- Conformance Information 451 mapMIBConformance OBJECT IDENTIFIER ::= {mapMIB 2} 452 mapMIBCompliances OBJECT IDENTIFIER ::= { mapMIBConformance 1 } 453 mapMIBGroups OBJECT IDENTIFIER ::= { mapMIBConformance 2 } 455 -- compliance statements 456 mapMIBCompliance MODULE-COMPLIANCE 457 STATUS current 458 DESCRIPTION 459 " Describes the minimal requirements for conformance 460 to the MAP-E MIB." 461 MODULE -- this module 462 MANDATORY-GROUPS { mapMIBRuleGroup , mapMIBSecurityGroup } 463 ::= { mapMIBCompliances 1 } 465 -- Units of Conformance 466 mapMIBRuleGroup OBJECT-GROUP 467 OBJECTS { 468 mapRuleIPv6Prefix, 469 mapRuleIPv6PrefixLen, 470 mapRuleIPv4Prefix, 471 mapRuleIPv4PrefixLen, 472 mapRuleBRIPv6Address, 473 mapRulePSID, 474 mapRulePSIDLen, 475 mapRuleOffset, 476 mapRuleEALen, 477 mapRuleType } 479 STATUS current 480 DESCRIPTION 481 " The collection of this objects are used to give the 482 information of mapping rules in MAP-E." 483 ::= { mapMIBGroups 1 } 485 mapMIBSecurityGroup OBJECT-GROUP 486 OBJECTS { 487 mapSecurityCheckInvalidv4, 488 mapSecurityCheckInvalidv6 } 489 STATUS current 490 DESCRIPTION 491 " The collection of this objects are used to give the 492 information on MAP security checks." 493 ::= { mapMIBGroups 2 } 495 END 497 6. IANA Considerations 499 The MIB module in this document uses the following IANA-assigned 500 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 502 Descriptor OBJECT IDENTIFIER value 503 ---------- ----------------------- 504 MAP-E-MIB { mib-2 XXX } 506 7. Security Considerations 508 There are no management objects defined in this MIB module that have 509 a MAX-ACCESS clause of read-write and/or read-create. So, if this 510 MIB module is implemented correctly, then there is no risk that an 511 intruder can alter or create any management objects of this MIB 512 module via direct SNMP SET operations. 514 Some of the readable objects in this MIB module (i.e., objects with a 515 MAX-ACCESS other than not-accessible) may be considered sensitive or 516 vulnerable in some network environments. It is thus important to 517 control even GET and/or NOTIFY access to these objects and possibly 518 to even encrypt the values of these objects when sending them over 519 the network via SNMP. 521 The following objects are vulnerable in the sense that when an 522 intruder sees the information in this MIB module, then it might help 523 him/her to set up an attack on the MAP node. Objects that reveal 524 rule information of the MAP Domain: Various objects can reveal the 525 rule information of the map domain. A curious outsider could monitor 526 these to assess the number of rules and the IPv6 prefix performed in 527 this domain. Futher, an intruder could use the information to guess 528 the address-sharing ratios of the ISPs. These are the objects and 529 their sensitivity/ vulnerability: 531 mapRuleIPv6Prefix 533 mapRuleIPv6PrefixLen 535 mapRuleIPv4Prefix 537 mapRuleIPv4PrefixLen 539 mapRuleBRIPv6Address 541 mapRulePSID 543 mapRulePSIDLen 545 mapRuleOffset 547 mapRuleEALen 549 mapRuleType 551 SNMP versions prior to SNMPv3 did not include adequate security. 552 Even if the network itself is secure (for example by using IPSec), 553 even then, there is no control as to who on the secure network is 554 allowed to access and GET/SET (read/change/create/delete) the objects 555 in this MIB module. 557 Implementations SHOULD provide the security features described by the 558 SNMPv3 framework (see [RFC3410]), and implementations claiming 559 compliance to the SNMPv3 standard MUST include full support for 560 authentication and privacy via the User-based Security Model (USM) 561 [RFC3414] with the AES cipher algorithm [RFC3826]. Implementations 562 MAY also provide support for the Transport Security Model (TSM) 563 [RFC5591] in combination with a secure transport such as SSH 564 [RFC5592] or TLS/DTLS [RFC6353]. 566 Further, deployment of SNMP versions prior to SNMPv3 is NOT 567 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 568 enable cryptographic security. It is then a customer/operator 569 responsibility to ensure that the SNMP entity giving access to an 570 instance of this MIB module is properly configured to give access to 571 the objects only to those principals (users) that have legitimate 572 rights to indeed GET or SET (change/create/delete) them. 574 8. Acknowledgements 576 The authors would like to thank for valuable comments from David 577 Harrington, Mark Townsley, Shishio Tsuchiya, Yong Cui, Suresh 578 Krishnan, Bert Wijnen and Juergen Schoenwaelder. 580 This document was produced using the xml2rfc tool [RFC2629]. 582 9. References 584 9.1. Normative References 586 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 587 Requirement Levels", BCP 14, RFC 2119, 588 DOI 10.17487/RFC2119, March 1997, 589 . 591 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 592 Schoenwaelder, Ed., "Structure of Management Information 593 Version 2 (SMIv2)", STD 58, RFC 2578, 594 DOI 10.17487/RFC2578, April 1999, 595 . 597 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 598 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 599 STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 600 . 602 [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. 603 Schoenwaelder, Ed., "Conformance Statements for SMIv2", 604 STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, 605 . 607 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 608 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 609 . 611 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 612 Schoenwaelder, "Textual Conventions for Internet Network 613 Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, 614 . 616 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 617 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 618 Port with Encapsulation (MAP-E)", RFC 7597, 619 DOI 10.17487/RFC7597, July 2015, 620 . 622 9.2. Informative References 624 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 625 DOI 10.17487/RFC2629, June 1999, 626 . 628 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 629 "Introduction and Applicability Statements for Internet- 630 Standard Management Framework", RFC 3410, 631 DOI 10.17487/RFC3410, December 2002, 632 . 634 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 635 (USM) for version 3 of the Simple Network Management 636 Protocol (SNMPv3)", STD 62, RFC 3414, 637 DOI 10.17487/RFC3414, December 2002, 638 . 640 [RFC3826] Blumenthal, U., Maino, F., and K. McCloghrie, "The 641 Advanced Encryption Standard (AES) Cipher Algorithm in the 642 SNMP User-based Security Model", RFC 3826, 643 DOI 10.17487/RFC3826, June 2004, 644 . 646 [RFC5591] Harrington, D. and W. Hardaker, "Transport Security Model 647 for the Simple Network Management Protocol (SNMP)", 648 STD 78, RFC 5591, DOI 10.17487/RFC5591, June 2009, 649 . 651 [RFC5592] Harrington, D., Salowey, J., and W. Hardaker, "Secure 652 Shell Transport Model for the Simple Network Management 653 Protocol (SNMP)", RFC 5592, DOI 10.17487/RFC5592, June 654 2009, . 656 [RFC6353] Hardaker, W., "Transport Layer Security (TLS) Transport 657 Model for the Simple Network Management Protocol (SNMP)", 658 STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, 659 . 661 Authors' Addresses 663 Yu Fu 664 CNNIC 665 No.4 South 4th Street, Zhongguancun 666 Beijing 100190 667 P.R. China 669 Email: fuyu@cnnic.cn 670 Sheng Jiang 671 Huawei Technologies Co., Ltd 672 Q14, Huawei Campus, No.156 Beiqing Road 673 Hai-Dian District, Beijing, 100095 674 P.R. China 676 Email: jiangsheng@huawei.com 678 Bing Liu 679 Huawei Technologies Co., Ltd 680 Q14, Huawei Campus, No.156 Beiqing Road 681 Hai-Dian District, Beijing, 100095 682 P.R. China 684 Email: leo.liubing@huawei.com 686 Jiang Dong 687 Tsinghua University 688 Department of Computer Science, Tsinghua University 689 Beijing 100084 690 P.R. China 692 Email: knight.dongjiang@gmail.com 694 Yuchi Chen 695 Tsinghua University 696 Department of Computer Science, Tsinghua University 697 Beijing 100084 698 P.R. China 700 Email: flashfoxmx@gmail.com