idnits 2.17.1 draft-ietf-pim-igmp-mld-proxy-yang-05.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 == Line 283 has weird spacing: '...ce-name if:...' == Line 324 has weird spacing: '...ce-name if:...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 20, 2021) is 1072 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 (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 PIM Working Group H. Zhao 2 Internet Draft Ericsson 3 Intended status: Standards Track X. Liu 4 Expires: November 19, 2021 Volta 5 Y. Liu 6 China Mobile 7 M. Panchanathan 8 Cisco 9 M. Sivakumar 10 Juniper 12 May 20, 2021 14 A Yang Data Model for IGMP/MLD Proxy 15 draft-ietf-pim-igmp-mld-proxy-yang-05.txt 17 Abstract 19 This document defines a YANG data model that can be used to 20 configure and manage Internet Group Management Protocol (IGMP) or 21 Multicast Listener Discovery (MLD) proxy devices. The YANG module in 22 this document conforms to Network Management Datastore Architecture 23 (NMDA). 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), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 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 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on November 19, 2021. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction...................................................3 65 1.1. Terminology...............................................3 66 1.2. Conventions Used in This Document.........................3 67 1.3. Tree Diagrams.............................................4 68 1.4. Prefixes in Data Node Names...............................4 69 2. Design of Data Model...........................................4 70 2.1. Overview..................................................5 71 2.2. Optional Capabilities.....................................5 72 2.3. Position of Address Family in Hierarchy...................5 73 3. Module Structure...............................................6 74 3.1. IGMP Proxy Configuration and Operational State............6 75 3.2. MLD Proxy Configuration and Operational State.............7 76 4. IGMP/MLD Proxy YANG Module.....................................8 77 5. Security Considerations.......................................15 78 6. IANA Considerations...........................................16 79 6.1. XML Registry.............................................16 80 6.2. YANG Module Names Registry...............................16 81 7. References....................................................17 82 7.1. Normative References.....................................17 83 7.2. Informative References...................................18 84 Authors' Addresses...............................................19 86 1. Introduction 88 This document defines a YANG [RFC7950] data model for the management of 89 Internet Group Management Protocol (IGMP) or Multicast Listener 90 Discovery (MLD) Proxy [RFC4605] devices. 92 The YANG module in this document conforms to the Network Management 93 Datastore Architecture defined in [RFC8342]. The "Network Management 94 Datastore Architecture" (NMDA) adds the ability to inspect the current 95 operational values for configuration, allowing clients to use identical 96 paths for retrieving the configured values and the operational values. 98 1.1. Terminology 100 The terminology for describing YANG data models is found in [RFC6020] 102 and [RFC7950], including: 104 * augment 106 * data model 108 * data node 110 * identity 112 * module 114 The following abbreviations are used in this document and defined model: 116 IGMP: Internet Group Management Protocol [RFC3376]. 118 MLD: Multicast Listener Discovery [RFC3810]. 120 PIM: Protocol Independent Multicast [RFC7761]. 122 1.2. Conventions Used in This Document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 14 127 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as 128 shown here. 130 1.3. Tree Diagrams 132 Tree diagrams used in this document follow the notation defined in 134 [RFC8340]. 136 1.4. Prefixes in Data Node Names 138 In this document, names of data nodes, and other data model objects are 139 often used without a prefix, as long as it is clear from the context in 140 which YANG module each name is defined. Otherwise, names are prefixed 141 using the standard prefix associated with the corresponding YANG module, 142 as shown in Table 1. 144 +----------+-----------------------+---------------------------------+ 145 | Prefix | YANG module | Reference | 146 +==========+=======================+=================================+ 147 | inet | ietf-inet-types | [RFC6991] | 148 +----------+-----------------------+---------------------------------+ 149 | if | ietf-interfaces | [RFC8343] | 150 +----------+-----------------------+---------------------------------+ 151 | rt | ietf-routing | [RFC8349] | 152 +----------+-----------------------+---------------------------------+ 153 | rt-types | ietf-routing-types | [RFC8294] | 154 +----------+-----------------------+---------------------------------+ 155 | pim-base | ietf-pim-base | [draft-ietf-pim-yang] | 156 +----------+-----------------------+---------------------------------+ 157 Table 1: Prefixes and Corresponding YANG Modules 159 2. Design of Data Model 161 The model covers Considerations for Internet Group Management Protocol 162 (IGMP) / Multicast Listener Discovery (MLD) - Based Multicast Forwarding 163 ("IGMP/MLD Proxying") [RFC4605]. 165 The goal of this document is to define a data model that provides a 166 common user interface to IGMP/MLD Proxy. This document provides freedom 167 for vendors to adapt the data model to their product implementations. 169 2.1. Overview 171 The model defined in this document has all the common building blocks 172 for the IGMP/MLD Proxy devices. It can be used to configure IGMP/MLD 173 Proxy. The operational state data and statistics can also be retrieved 174 by it. 176 The model contains all the basic configuration parameters. The 177 occasionally implemented parameters are modeled as optional features in 178 this model, while the rarely implemented parameters are not included in 179 this model and left for augmentation. 181 2.2. Optional Capabilities 183 This model is designed to represent the basic capability subsets of IGMP 184 / MLD Proxy. The main design goals of this document are that the basic 185 capabilities described in the model are supported by any major now- 186 existing implementation, and that the configuration of all 187 implementations meeting the specifications is easy to express through 188 some combination of the optional features in the model and simple vendor 189 augmentations. 191 There is also value in widely supported features being standardized, to 192 provide a standardized way to access these features, to save work for 193 individual vendors, and so that mapping between different vendors' 194 configuration is not needlessly complicated. Therefore, this model 195 declares a number of features representing capabilities that not all 196 deployed devices support. 198 The extensive use of feature declarations should also substantially 199 simplify the capability negotiation process for a vendor's IGMP / MLD 200 Proxy implementations. 202 2.3. Position of Address Family in Hierarchy 204 IGMP Proxy only supports IPv4, while MLD Proxy only supports IPv6. The 205 data model defined in this document can be used for both IPv4 and IPv6 206 address families. 208 This document defines IGMP Proxy and MLD Proxy as separate schema 209 branches in the structure. The benefits are: 211 * The model can support IGMP Proxy (IPv4), MLD Proxy (IPv6), or both 212 optionally and independently. Such flexibility cannot be achieved 213 cleanly with a combined branch. 215 * The structure is consistent with other YANG data models such as 216 [RFC8652], which uses separate branches for IPv4 and IPv6. 218 * Having separate branches for IGMP Proxy and MLD Proxy allows minor 219 differences in their behavior to be modelled more simply and cleanly. 220 The two branches can better support different features and node types. 222 3. Module Structure 224 This model augments the core routing data model specified in [RFC8349]. 226 +--rw routing 227 +--rw router-id? 228 +--rw control-plane-protocols 229 | +--rw control-plane-protocol* [type name] 230 | +--rw type 231 | +--rw name 232 | +--rw igmp-proxy <= Augmented by this Model 233 ... 234 | +--rw mld-proxy <= Augmented by this Model 236 The "igmp-proxy" container instantiates IGMP Proxy. The "mld-proxy" 237 container instantiates MLD Proxy. 239 The YANG data model defined in this document conforms to the Network 240 Management Datastore Architecture (NMDA) [RFC8342]. The operational 241 state data is combined with the associated configuration data in the 242 same hierarchy [RFC8407]. 244 3.1. IGMP Proxy Configuration and Operational State 246 The YANG module augments /rt:routing/rt:control-plane- 247 protocols/rt:control-plane-protocol to add the igmp-proxy container. 249 All the IGMP Proxy related attributes are defined in the igmp-proxy 250 container. The read-write attributes represent configurable data. The 251 read-only attributes represent state data. 253 The igmp-version represents version of IGMP protocol, and default value 254 is 2. If the value of enable is true, it means IGMP Proxy is enabled. 256 The interface list under igmp-proxy contains upstream interfaces for 257 IGMP proxy. There is also a constraint to make sure the upstream 258 interface for IGMP proxy should not be configured PIM. 260 To configure a downstream interface for IGMP proxy, it is needed to 261 enable IGMP on that interface. This is defined in the YANG Data Model 262 for Internet Group Management Protocol (IGMP) and Multicast Listener 263 Discovery (MLD) [RFC8652]. 265 augment /rt:routing/rt:control-plane-protocols 266 /rt:control-plane-protocol: 267 +--rw igmp-proxy {igmp-proxy}? 268 +--rw interfaces 269 +--rw interface* [interface-name] 270 +--rw interface-name if:interface-ref 271 +--rw igmp-version? uint8 272 +--rw enable? boolean 273 +--rw sender-source-address? inet:ipv4-address 274 +--ro group* [group-address] 275 +--ro group-address 276 | rt-types:ipv4-multicast-group-address 277 +--ro up-time? uint32 278 +--ro filter-mode enumeration 279 +--ro source* [source-address] 280 +--ro source-address inet:ipv4-address 281 +--ro up-time? uint32 282 +--ro downstream-interface* [interface-name] 283 +--ro interface-name if:interface-ref 285 3.2. MLD Proxy Configuration and Operational State 287 The YANG module augments /rt:routing/rt:control-plane- 288 protocols/rt:control-plane-protocol to add the mld-proxy container. 290 All the MLD Proxy related attributes are defined in the mld-proxy 291 container. The read-write attributes represent configurable data. The 292 read-only attributes represent state data. 294 The mld-version represents version of MLD protocol, and default value is 295 2. If the value of enable is true, it means MLD Proxy is enabled. 297 The interface list under mld-proxy contains upstream interfaces for MLD 298 proxy. There is also a constraint to make sure the upstream interface 299 for MLD proxy should not be configured PIM. 301 To configure a downstream interface for MLD proxy, enable MLD on that 302 interface. This is defined in the YANG Data Model for Internet Group 303 Management Protocol (IGMP) and Multicast Listener Discovery (MLD) 304 [RFC8652]. 306 augment /rt:routing/rt:control-plane-protocols 307 /rt:control-plane-protocol: 308 +--rw mld-proxy {mld-proxy}? 309 +--rw interfaces 310 +--rw interface* [interface-name] 311 +--rw interface-name if:interface-ref 312 +--rw mld-version? uint8 313 +--rw enable? boolean 314 +--rw sender-source-address? inet:ipv6-address 315 +--ro group* [group-address] 316 +--ro group-address 317 | rt-types:ipv6-multicast-group-address 318 +--ro up-time? uint32 319 +--ro filter-mode enumeration 320 +--ro source* [source-address] 321 +--ro source-address inet:ipv6-address 322 +--ro up-time? uint32 323 +--ro downstream-interface* [interface-name] 324 +--ro interface-name if:interface-ref 326 4. IGMP/MLD Proxy YANG Module 328 This module references [RFC4605], [RFC6991], [RFC8294], [RFC8343], 329 [RFC8349] and [draft-ietf-pim-yang]. 331 file ietf-igmp-mld-proxy@2021-04-21.yang 332 module ietf-igmp-mld-proxy { 333 yang-version 1.1; 334 namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy"; 335 // replace with IANA namespace when assigned 336 prefix igmp-mld-proxy; 338 import ietf-inet-types { 339 prefix inet; 340 } 341 import ietf-interfaces { 342 prefix if; 343 } 344 import ietf-routing { 345 prefix rt; 346 } 347 import ietf-routing-types { 348 prefix rt-types; 349 } 350 import ietf-pim-base { 351 prefix pim-base; 352 } 354 organization 355 "IETF PIM Working Group"; 357 contact 358 "WG Web: 359 WG List: 360 Editors: Hongji Zhao 361 363 Xufeng Liu 364 366 Yisong Liu 367 369 Mani Panchanathan 370 372 Mahesh Sivakumar 373 375 "; 377 description 378 "The module defines a collection of YANG definitions common for 379 all Internet Group Management Protocol (IGMP) and Multicast 380 Listener Discovery (MLD) Proxy devices. 382 Copyright (c) 2021 IETF Trust and the persons identified as 383 authors of the code. All rights reserved. 385 Redistribution and use in source and binary forms, with or 386 without modification, is permitted pursuant to, and subject to 387 the license terms contained in, the Simplified BSD License set 388 forth in Section 4.c of the IETF Trust's Legal Provisions 389 Relating to IETF Documents 390 (http://trustee.ietf.org/license-info). 392 This version of this YANG module is part of RFC XXXX; see the 393 RFC itself for full legal notices."; 395 revision 2021-04-21 { 396 description 397 "Initial revision."; 398 reference 399 "RFC XXXX: A YANG Data Model for IGMP and MLD Proxy"; 400 } 402 /* 403 * Features 404 */ 406 feature igmp-proxy { 407 description 408 "Support IGMP Proxy protocol."; 409 reference 410 "RFC 4605"; 412 } 414 feature mld-proxy { 415 description 416 "Support MLD Proxy protocol."; 417 reference 418 "RFC 4605"; 419 } 421 /* 422 * Identities 423 */ 425 identity igmp-proxy { 426 base rt:control-plane-protocol; 427 description 428 "IGMP Proxy protocol"; 429 } 431 identity mld-proxy { 432 base rt:control-plane-protocol; 433 description 434 "MLD Proxy protocol"; 435 } 437 /* 438 * Groupings 439 */ 441 grouping per-interface-config-attributes { 442 description "Config attributes under interface view"; 443 leaf enable { 444 type boolean; 445 default false; 446 description 447 "Set the value to true to enable IGMP/MLD proxy"; 448 } 449 } // per-interface-config-attributes 451 grouping state-group-attributes { 452 description 453 "State group attributes"; 454 leaf up-time { 455 type uint32; 456 units seconds; 457 description 458 "The elapsed time for (S,G) or (*,G)."; 459 } 460 leaf filter-mode { 461 type enumeration { 462 enum "include" { 463 description 464 "In include mode, reception of packets sent 465 to the specified multicast address is requested 466 only from those IP source addresses listed in the 467 source-list parameter"; 468 } 469 enum "exclude" { 470 description 471 "In exclude mode, reception of packets sent 472 to the given multicast address is requested 473 from all IP source addresses except those 474 listed in the source-list parameter."; 475 } 476 } 477 mandatory true; 478 description 479 "Filter mode for a multicast group, 480 may be either include or exclude."; 481 } 482 } // state-group-attributes 484 /* augments */ 486 augment "/rt:routing/rt:control-plane-protocols"+ 487 "/rt:control-plane-protocol" { 488 when 489 "derived-from-or-self(rt:type, 'igmp-mld-proxy:igmp-proxy')" { 490 description 491 "This augmentation is only valid for IGMP Proxy."; 492 } 493 description 494 "IGMP Proxy augmentation to routing control plane protocol 495 configuration and state."; 496 container igmp-proxy { 497 if-feature "igmp-proxy"; 498 description "IGMP proxy"; 499 container interfaces { 500 description 501 "Containing a list of upstream interfaces."; 502 list interface { 503 key "interface-name"; 504 description 505 "List of upstream interfaces."; 506 leaf interface-name { 507 type if:interface-ref; 508 must "not( current() = /rt:routing"+ 509 "/rt:control-plane-protocols/pim-base:pim"+ 510 "/pim-base:interfaces/pim-base:interface"+ 511 "/pim-base:name )" { 512 description 513 "The upstream interface for IGMP proxy 514 should not be configured PIM."; 515 } 516 description "The upstream interface name."; 517 } 518 leaf igmp-version { 519 type uint8 { 520 range "1..3"; 521 } 522 default 2; 523 description "IGMP version."; 524 } 525 uses per-interface-config-attributes; 526 leaf sender-source-address { 527 type inet:ipv4-address; 528 description 529 "The sender source address of 530 IGMP memembership report or leave."; 531 } 532 list group { 533 key "group-address"; 534 config false; 535 description 536 "Multicast group membership information 537 that joined on the interface."; 538 leaf group-address { 539 type rt-types:ipv4-multicast-group-address; 540 description 541 "Multicast group address."; 542 } 543 uses state-group-attributes; 544 list source { 545 key "source-address"; 546 description 547 "List of multicast source information 548 of the multicast group."; 549 leaf source-address { 550 type inet:ipv4-address; 551 description 552 "Multicast source address"; 553 } 554 leaf up-time { 555 type uint32; 556 units seconds; 557 description 558 "The elapsed time for (S,G) or (*,G)."; 559 } 560 list downstream-interface { 561 key "interface-name"; 562 description "The downstream interfaces list."; 563 leaf interface-name { 564 type if:interface-ref; 565 description 566 "Downstream interfaces 567 for each upstream-interface"; 568 } 569 } 570 } // list source 571 } // list group 572 } // interface 573 } // interfaces 574 } 575 } 577 augment "/rt:routing/rt:control-plane-protocols"+ 578 "/rt:control-plane-protocol" { 579 when 580 "derived-from-or-self(rt:type, 'igmp-mld-proxy:mld-proxy')" { 581 description 582 "This augmentation is only valid for MLD Proxy."; 583 } 584 description 585 "MLD Proxy augmentation to routing control plane protocol 586 configuration and state."; 587 container mld-proxy { 588 if-feature "mld-proxy"; 589 description "MLD proxy"; 590 container interfaces { 591 description 592 "Containing a list of upstream interfaces."; 593 list interface { 594 key "interface-name"; 595 description 596 "List of upstream interfaces."; 597 leaf interface-name { 598 type if:interface-ref; 599 must "not( current() = /rt:routing"+ 600 "/rt:control-plane-protocols/pim-base:pim"+ 601 "/pim-base:interfaces/pim-base:interface"+ 602 "/pim-base:name )" { 603 description 604 "The upstream interface for MLD proxy 605 should not be configured PIM."; 606 } 607 description "The upstream interface name."; 608 } 609 leaf mld-version { 610 type uint8 { 611 range "1..2"; 612 } 613 default 2; 614 description "MLD version."; 616 } 617 uses per-interface-config-attributes; 618 leaf sender-source-address { 619 type inet:ipv6-address; 620 description 621 "The sender source address of 622 MLD memembership report or leave."; 623 } 624 list group { 625 key "group-address"; 626 config false; 627 description 628 "Multicast group membership information 629 that joined on the interface."; 630 leaf group-address { 631 type rt-types:ipv6-multicast-group-address; 632 description 633 "Multicast group address."; 634 } 635 uses state-group-attributes; 636 list source { 637 key "source-address"; 638 description 639 "List of multicast source information 640 of the multicast group."; 641 leaf source-address { 642 type inet:ipv6-address; 643 description 644 "Multicast source address"; 645 } 646 leaf up-time { 647 type uint32; 648 units seconds; 649 description 650 "The elapsed time for (S,G) or (*,G)."; 651 } 652 list downstream-interface { 653 key "interface-name"; 654 description "The downstream interfaces list."; 655 leaf interface-name { 656 type if:interface-ref; 657 description 658 "Downstream interfaces 659 for each upstream-interface"; 660 } 661 } 662 } // list source 663 } // list group 664 } // interface 665 } // interfaces 666 } 668 } 669 } 670 672 5. Security Considerations 674 The YANG module specified in this document defines a schema for data 675 that is designed to be accessed via network management protocols such as 676 NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the 677 secure transport layer, and the mandatory-to-implement secure transport 678 is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and 679 the mandatory-to-implement secure transport is TLS [RFC8446]. 681 The Network Configuration Access Control Model (NACM) [RFC8341] provides 682 the means to restrict access for particular NETCONF or RESTCONF users to 683 a preconfigured subset of all available NETCONF or RESTCONF protocol 684 operations and content. 686 There are a number of data nodes defined in this YANG module that are 687 writable/creatable/deletable (i.e., config true, which is the default). 688 These data nodes may be considered sensitive or vulnerable in some 689 network environments. Write operations (e.g., edit-config) to these data 690 nodes without proper protection can have a negative effect on network 691 operations. These are the subtrees and data nodes and their 692 sensitivity/vulnerability: 694 Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ 696 igmp-mld-proxy:igmp-proxy 698 igmp-mld-proxy:mld-proxy 700 Unauthorized access to any data node of these subtrees can adversely 701 affect the IGMP / MLD Proxy subsystem of both the local device and the 702 network. This may lead to network malfunctions, delivery of packets to 703 inappropriate destinations, and other problems. 705 Some of the readable data nodes in this YANG module may be considered 706 sensitive or vulnerable in some network environments. It is thus 707 important to control read access (e.g., via get, get-config, or 708 notification) to these data nodes. These are the subtrees and data nodes 709 and their sensitivity/vulnerability: 711 Under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol:/ 713 igmp-mld-proxy:igmp-proxy 715 igmp-mld-proxy:mld-proxy 716 Unauthorized access to any data node of these subtrees can disclose the 717 operational state information of IGMP / MLD Proxy on this device. The 718 group/source information may expose multicast group memberships. 720 6. IANA Considerations 722 RFC Ed.: In this section, replace all occurrences of 'XXXX' with the 723 actual RFC number (and remove this note). 725 6.1. XML Registry 727 This document registers the following namespace URIs in the IETF XML 729 registry [RFC3688]: 731 -------------------------------------------------------------------- 732 URI: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy 733 Registrant Contact: The IETF. 734 XML: N/A, the requested URI is an XML namespace. 735 -------------------------------------------------------------------- 737 6.2. YANG Module Names Registry 739 This document registers the following YANG modules in the YANG Module 740 Names registry [RFC7950]: 741 -------------------------------------------------------------------- 742 name: ietf-igmp-mld-proxy 743 namespace: urn:ietf:params:xml:ns:yang:ietf-igmp-mld-proxy 744 prefix: igmp-mld-proxy 745 reference: RFC XXXX 746 -------------------------------------------------------------------- 747 7. References 749 7.1. Normative References 751 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 752 Requirement Levels", RFC 2119, March 1997. 754 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 755 Thyagarajan, "Internet Group Management Protocol, Version 756 3", RFC 3376, October 2002. 758 [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 759 2004. 761 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 762 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 764 [RFC4605] B. Fenner, H. He, B. Haberman and H. Sandick, "Internet 765 Group Management Protocol (IGMP) / Multicast Listener 766 Discovery (MLD) - Based Multicast Forwarding ("IGMP/MLD 767 Proxying")", RFC 4605, August 2006. 769 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 770 the Network Configuration Protocol (NETCONF)", RFC 6020, 771 October 2010. 773 [RFC6241] R. Enns, Ed., M. Bjorklund, Ed., J. Schoenwaelder, Ed., A. 774 Bierman, Ed., "Network Configuration Protocol (NETCONF)", 775 RFC 6241, June 2011. 777 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 778 Shell (SSH)", RFC 6242, June 2011. 780 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, 781 July 2013. 783 [RFC7950] M. Bjorklund, Ed., "The YANG 1.1 Data Modeling Language", 784 RFC 7950, August 2016. 786 [RFC8040] A. Bierman, M. Bjorklund, K. Watsen, "RESTCONF Protocol", 787 RFC 8040, January 2017. 789 [RFC8174] B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 790 Key Words", RFC 8174, May 2017. 792 [RFC8294] X. Liu, Y. Qu, A. Lindem, C. Hopps, L. Berger, "Common YANG 793 Data Types for the Routing Area", RFC 8294, December 2017. 795 [RFC8340] M. Bjorklund, and L. Berger, Ed., "YANG Tree Diagrams", RFC 796 8340, March 2018. 798 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access 799 Control Model", RFC 8341, March 2018. 801 [RFC8342] M. Bjorklund and J. Schoenwaelder, "Network Management 802 Datastore Architecture (NMDA)", RFC 8342, March 2018. 804 [RFC8343] M. Bjorklund, "A YANG Data Model for Interface Management", 805 RFC 8343, March 2018. 807 [RFC8349] L. Lhotka, A. Lindem, Y. Qu, "A YANG Data Model for Routing 808 Management (NMDA Version)", RFC 8349, March 2018. 810 [RFC8407] A. Bierman, "Guidelines for Authors and Reviewers of 811 Documents Containing YANG Data Models", RFC 8407, October 812 2018. 814 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 815 Version 1.3", RFC 8446, August 2018. 817 [RFC8652] X. Liu, F. Guo, M. Sivakumar, P. McAllister, A. Peter, "A 818 YANG Data Model for the Internet Group Management Protocol 819 (IGMP) and Multicast Listener Discovery (MLD)", RFC 8652, 820 November 2019. 822 [draft-ietf-pim-yang] X. Liu, P. McAllister, A. Peter, M. Sivakumar, 823 Y. Liu, F. Hu, "A YANG Data Model for Protocol Independent 824 Multicast (PIM)", draft-ietf-pim-yang-17 (RFC Editor state 825 is MISSREF), May 2018. 827 7.2. Informative References 829 [RFC7761] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, R. Parekh, 830 Z. Zhang, L. Zheng, "Protocol Independent Multicast - 831 Sparse Mode (PIM-SM): Protocol Specification (Revised)", 832 RFC 7761, March 2016. 834 Authors' Addresses 836 Hongji Zhao 837 Ericsson (China) Communications Company Ltd. 838 Ericsson Tower, No. 5 Lize East Street, 839 Chaoyang District Beijing 100102, P.R. China 840 Email: hongji.zhao@ericsson.com 842 Xufeng Liu 843 Volta Networks 844 USA 845 EMail: Xufeng.liu.ietf@gmail.com 847 Yisong Liu 848 China Mobile 849 China 850 Email: liuyisong@chinamobile.com 852 Mani Panchanathan 853 Cisco 854 India 855 Email: mapancha@cisco.com 857 Mahesh Sivakumar 858 Juniper Networks 859 1133 Innovation Way 860 Sunnyvale, California 861 USA 862 EMail: sivakumar.mahesh@gmail.com