draft-ietf-pim-igmp-mld-yang-11.txt   draft-ietf-pim-igmp-mld-yang-12.txt 
PIM Working Group X. Liu PIM Working Group X. Liu
Internet-Draft Volta Networks Internet-Draft Volta Networks
Intended Status: Standard Track F. Guo Intended Status: Standard Track F. Guo
Expires: October 26, 2019 Huawei Expires: November 9, 2019 Huawei
M. Sivakumar M. Sivakumar
Juniper Juniper
P. McAllister P. McAllister
Metaswitch Networks Metaswitch Networks
A. Peter A. Peter
Individual Individual
April 26, 2019 May 9, 2019
A YANG data model for Internet Group Management Protocol (IGMP) and A YANG Data Model for Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) Multicast Listener Discovery (MLD)
draft-ietf-pim-igmp-mld-yang-11 draft-ietf-pim-igmp-mld-yang-12
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 26, 2019. This Internet-Draft will expire on November 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Multicast Listener Discovery (MLD) devices. Multicast Listener Discovery (MLD) devices.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
1.1. Terminology...............................................3 1.1. Terminology...............................................3
1.2. Tree Diagrams.............................................3 1.2. Tree Diagrams.............................................3
1.3. Prefixes in Data Node Names...............................3 1.3. Prefixes in Data Node Names...............................3
2. Design of Data model...........................................4 2. Design of Data model...........................................4
2.1. Scope of Model............................................4 2.1. Scope of Model............................................4
2.1.1. Parameters Not Covered at Global Level..................4 2.1.1. Parameters Not Covered at Global Level..................5
2.1.2. Parameters Not Covered at Interface Level...............5 2.1.2. Parameters Not Covered at Interface Level...............5
2.2. Optional Capabilities.....................................5 2.2. Optional Capabilities.....................................5
2.3. Position of Address Family in Hierarchy...................6 2.3. Position of Address Family in Hierarchy...................6
3. Module Structure...............................................6 3. Module Structure...............................................6
3.1. IGMP Configuration and Operational State..................7 3.1. IGMP Configuration and Operational State..................7
3.2. MLD Configuration and Operational State...................9 3.2. MLD Configuration and Operational State..................10
3.3. IGMP and MLD RPC.........................................12 3.3. IGMP and MLD Actions.....................................13
4. IGMP and MLD YANG Module......................................13 4. IGMP and MLD YANG Module......................................13
5. Security Considerations.......................................38 5. Security Considerations.......................................39
6. IANA Considerations...........................................40 6. IANA Considerations...........................................41
7. Acknowledgments...............................................40 7. Acknowledgments...............................................42
8. Contributing Authors..........................................41 8. Contributing Authors..........................................42
9. References....................................................41 9. References....................................................42
9.1. Normative References.....................................41 9.1. Normative References.....................................42
9.2. Informative References...................................42 9.2. Informative References...................................44
1. Introduction 1. Introduction
YANG [RFC6020] [RFC7950] is a data definition language that was YANG [RFC6020] [RFC7950] is a data definition language that was
introduced to model the configuration and running state of a device introduced to model the configuration and running state of a device
managed using network management protocols such as NETCONF [RFC6241] managed using network management protocols such as NETCONF [RFC6241]
or RESTCONF [RFC8040]. YANG is now also being used as a component of or RESTCONF [RFC8040]. YANG is now also being used as a component of
wider management interfaces, such as CLIs. wider management interfaces, such as CLIs.
This document defines a YANG data model that can be used to This document defines a YANG data model that can be used to
skipping to change at page 3, line 15 skipping to change at page 3, line 15
[RFC2710], and MLDv2 [RFC3810]. The core features of the IGMP and [RFC2710], and MLDv2 [RFC3810]. The core features of the IGMP and
MLD protocols are defined as required. Non-core features are MLD protocols are defined as required. Non-core features are
defined as optional in the provided data model. defined as optional in the provided data model.
The YANG model in this document conforms to the Network Management The YANG model in this document conforms to the Network Management
Datastore Architecture (NMDA). Datastore Architecture (NMDA).
1.1. Terminology 1.1. Terminology
The terminology for describing YANG data models is found in The terminology for describing YANG data models is found in
[RFC6020] and [RFC7950]. [RFC6020] and [RFC7950], including:
o augment
o data model
o data node
o identity
o module
The following abbreviations are used in this document and the The following abbreviations are used in this document and the
defined model: defined model:
IGMP: IGMP:
Internet Group Management Protocol [RFC3376]. Internet Group Management Protocol [RFC3376].
MLD: MLD:
skipping to change at page 7, line 21 skipping to change at page 7, line 30
must be provided by the user. Where nodes are not essential to must be provided by the user. Where nodes are not essential to
protocol operation, they are marked as optional. Some other nodes protocol operation, they are marked as optional. Some other nodes
are essential but have a default specified, so that they are also are essential but have a default specified, so that they are also
optional and need not be configured explicitly. optional and need not be configured explicitly.
3.1. IGMP Configuration and Operational State 3.1. IGMP Configuration and Operational State
The IGMP data is modeled as a schema subtree augmenting the The IGMP data is modeled as a schema subtree augmenting the
"control-plane-protocol" data node under "/rt:routing/rt:control- "control-plane-protocol" data node under "/rt:routing/rt:control-
plane-protocols" in the module ietf-routing, following the plane-protocols" in the module ietf-routing, following the
convention described in [RFC8349]. The identity "igmp" derived from convention described in [RFC8349]. The augmentation to the module
the "rt:control-plane-protocol" base identity is defined to indicate ietf-routing allows this model to support multiple instances of
a control-plane-protocol instance is for IGMP. IGMP, but a restriction MAY be added depending on the implementation
and the device. The identity "igmp" is derived from the "rt:control-
plane-protocol" base identity and indicates that a control-plane-
protocol instance is IGMP.
The IGMP subtree is a three-level hierarchy structure as listed The IGMP subtree is a three-level hierarchy structure as listed
below: below:
Global level: Including IGMP configuration and operational state Global level: Including IGMP configuration and operational state
attributes for the entire IGMP protocol instance in this router. attributes for the entire IGMP protocol instance in this router.
Interface-global level: Including configuration data nodes that Interface-global level: Including configuration data nodes that
are applicable to all the interfaces whose corresponding nodes are are applicable to all the interfaces whose corresponding nodes are
not defined or not configured at the interface level. For such a not defined or not configured at the interface level. For such a
skipping to change at page 10, line 5 skipping to change at page 10, line 18
+--ro host* [host-address] +--ro host* [host-address]
{intf-explicit-tracking}? {intf-explicit-tracking}?
+--ro host-address inet:ipv4-address +--ro host-address inet:ipv4-address
+--ro host-filter-mode enumeration +--ro host-filter-mode enumeration
3.2. MLD Configuration and Operational State 3.2. MLD Configuration and Operational State
The MLD data is modeled as a schema subtree augmenting the "control- The MLD data is modeled as a schema subtree augmenting the "control-
plane-protocol" data node under "/rt:routing/rt:control-plane- plane-protocol" data node under "/rt:routing/rt:control-plane-
protocols" in the module ietf-routing, following the convention protocols" in the module ietf-routing, following the convention
described in [RFC8349]. The identity "mld" derived from the described in [RFC8349]. The augmentation to the module ietf-routing
"rt:control-plane-protocol" base identity is defined to indicate a allows this model to support multiple instances of MLD, but a
control-plane-protocol instance is for MLD. restriction MAY be added depending on the implementation and the
device. The identity "mld" is derived from the "rt:control-plane-
protocol" base identity and indicates that a control-plane-protocol
instance is MLD.
The MLD subtree is a three-level hierarchy structure as listed The MLD subtree is a three-level hierarchy structure as listed
below: below:
Global level: Including MLD configuration and operational state Global level: Including MLD configuration and operational state
attributes for the entire MLD protocol instance in this router. attributes for the entire MLD protocol instance in this router.
Interface-global level: Including configuration data nodes that Interface-global level: Including configuration data nodes that
are applicable to all the interfaces whose corresponding nodes are are applicable to all the interfaces whose corresponding nodes are
not defined or not configured at the interface level. For such a not defined or not configured at the interface level. For such a
skipping to change at page 12, line 34 skipping to change at page 13, line 5
+--ro expire uint32 +--ro expire uint32
+--ro up-time uint32 +--ro up-time uint32
+--ro host-count? uint32 +--ro host-count? uint32
| {intf-explicit-tracking}? | {intf-explicit-tracking}?
+--ro last-reporter? inet:ipv6-address +--ro last-reporter? inet:ipv6-address
+--ro host* [host-address] +--ro host* [host-address]
{intf-explicit-tracking}? {intf-explicit-tracking}?
+--ro host-address inet:ipv6-address +--ro host-address inet:ipv6-address
+--ro host-filter-mode enumeration +--ro host-filter-mode enumeration
3.3. IGMP and MLD RPC 3.3. IGMP and MLD Actions
IGMP and MLD each have one RPC which clears the group membership IGMP and MLD each have one action which clears the group membership
cache entries for that protocol. cache entries for that protocol.
rpcs: augment /rt:routing/rt:control-plane-protocols
+---x clear-igmp-groups {feature-igmp,rpc-clear-groups}? /rt:control-plane-protocol:
| +---w input +--rw igmp {feature-igmp}?
| +---w interface-name? leafref +---x clear-groups {action-clear-groups}?
| +---w group-address? +---w input
| | rt-types:ipv4-multicast-group-address +---w (interface)
| +---w source-address? | +--:(name)
| rt-types:ipv4-multicast-source-address | | +---w interface-name? leafref
+---x clear-mld-groups {feature-mld,rpc-clear-groups}? | +--:(all)
+---w input | +---w all-interfaces? empty
+---w interface-name? leafref {feature-mld}? +---w group-address union
+---w group-address? +---w source-address
| rt-types:ipv6-multicast-group-address rt-types:ipv4-multicast-source-address
+---w source-address?
rt-types:ipv6-multicast-source-address augment /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol:
+--rw mld {feature-mld}?
+---x clear-groups {action-clear-groups}?
+---w input
+---w (interface)
| +--:(name)
| | +---w interface-name? leafref
| +--:(all)
| +---w all-interfaces? empty
+---w group-address? union
+---w source-address?
rt-types:ipv6-multicast-source-address
4. IGMP and MLD YANG Module 4. IGMP and MLD YANG Module
<CODE BEGINS> file "ietf-igmp-mld@2019-04-03.yang" <CODE BEGINS> file "ietf-igmp-mld@2019-05-08.yang"
module ietf-igmp-mld { module ietf-igmp-mld {
yang-version 1.1; yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld"; namespace "urn:ietf:params:xml:ns:yang:ietf-igmp-mld";
prefix igmp-mld; prefix igmp-mld;
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
reference "RFC 6991: Common YANG Data Types"; reference "RFC 6991: Common YANG Data Types";
} }
skipping to change at page 15, line 4 skipping to change at page 15, line 35
the license terms contained in, the Simplified BSD License set the license terms contained in, the Simplified BSD License set
forth in Section 4.c of the IETF Trust's Legal Provisions forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents Relating to IETF Documents
(http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX; see the This version of this YANG module is part of RFC XXXX; see the
RFC itself for full legal notices."; RFC itself for full legal notices.";
// RFC Ed.: replace XXXX with actual RFC number and remove // RFC Ed.: replace XXXX with actual RFC number and remove
// this note // this note
revision 2019-04-03 { revision 2019-05-08 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A YANG Data Model for IGMP and MLD"; "RFC XXXX: A YANG Data Model for IGMP and MLD";
} }
/* /*
* Features * Features
*/ */
feature feature-igmp { feature feature-igmp {
skipping to change at page 17, line 4 skipping to change at page 17, line 35
} }
feature intf-explicit-tracking { feature intf-explicit-tracking {
description description
"Support configuration of interface explicit-tracking hosts."; "Support configuration of interface explicit-tracking hosts.";
} }
feature intf-exclude-lite { feature intf-exclude-lite {
description description
"Support configuration of interface exclude-lite."; "Support configuration of interface exclude-lite.";
} }
feature per-interface-config { feature per-interface-config {
description description
"Support per interface configuration."; "Support per interface configuration.";
} }
feature rpc-clear-groups { feature action-clear-groups {
description description
"Support rpc's to clear groups."; "Support actions to clear groups.";
} }
/* /*
* Typedefs * Typedefs
*/ */
typedef ssm-map-ipv4-addr-type { typedef ssm-map-ipv4-addr-type {
type union { type union {
type enumeration { type enumeration {
enum 'policy' { enum 'policy' {
description description
skipping to change at page 24, line 37 skipping to change at page 25, line 20
type leafref { type leafref {
path "/acl:acls/acl:acl/acl:name"; path "/acl:acls/acl:acl/acl:name";
} }
description description
"When this grouping is used for IGMP, this leaf specifies "When this grouping is used for IGMP, this leaf specifies
the name of the access policy used to filter the the name of the access policy used to filter the
IGMP membership. IGMP membership.
When this grouping is used for MLD, this leaf specifies When this grouping is used for MLD, this leaf specifies
the name of the access policy used to filter the the name of the access policy used to filter the
MLD membership. MLD membership.
A device can restrict the length and value of this name, The value space of this leaf is restricted to the existing
with the possibility that space and certain special policy instances defined by the refered schema [RFC8519].
characters are not allowed. As specified by [RFC8519], the length of the name is between
1 and 64; a device MAY further restrict the length of this
name; space and special characters are not allowed.
If this leaf is not specified, no policy is applied, and If this leaf is not specified, no policy is applied, and
all packets received from this interface are accepted."; all packets received from this interface are accepted.";
reference
"RFC 8519: YANG Data Model for Network Access Control Lists
(ACLs)";
} }
leaf immediate-leave { leaf immediate-leave {
if-feature intf-immediate-leave; if-feature intf-immediate-leave;
type empty; type empty;
description description
"When this grouping is used for IGMP, the presence of this "When this grouping is used for IGMP, the presence of this
leaf requests IGMP to perform an immediate leave upon leaf requests IGMP to perform an immediate leave upon
receiving an IGMPv2 leave message. receiving an IGMPv2 leave message.
If the router is IGMP-enabled, it sends an IGMP last member If the router is IGMP-enabled, it sends an IGMP last member
query with a last member query response time. However, the query with a last member query response time. However, the
skipping to change at page 35, line 15 skipping to change at page 35, line 51
} }
description description
"Reference to an entry in the global interface list."; "Reference to an entry in the global interface list.";
} }
uses interface-config-attributes-igmp { uses interface-config-attributes-igmp {
if-feature per-interface-config; if-feature per-interface-config;
} }
uses interface-state-attributes-igmp; uses interface-state-attributes-igmp;
} // interface } // interface
} // interfaces } // interfaces
/*
* Actions
*/
action clear-groups {
if-feature action-clear-groups;
description
"Clears the specified IGMP cache entries.";
input {
choice interface {
mandatory true;
description
"Indicates the interface(s) from which the cache
entries are cleared.";
case name {
leaf interface-name {
type leafref {
path "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/"
+ "igmp-mld:igmp/igmp-mld:interfaces/"
+ "igmp-mld:interface/igmp-mld:interface-name";
}
description
"Name of the IGMP interface.";
}
}
case all {
leaf all-interfaces {
type empty;
description
"IGMP groups from all interfaces are cleared.";
}
}
}
leaf group-address {
type union {
type enumeration {
enum '*' {
description
"Any group address.";
}
}
type rt-types:ipv4-multicast-group-address;
}
mandatory true;
description
"Multicast group IPv4 address.
If the value '*' is specified, all IGMP group entries
are cleared.";
}
leaf source-address {
type rt-types:ipv4-multicast-source-address;
mandatory true;
description
"Multicast source IPv4 address.
If the value '*' is specified, all IGMP source-group
entries are cleared.";
}
}
} // action clear-groups
} // igmp } // igmp
} //augment } //augment
augment "/rt:routing/rt:control-plane-protocols/" augment "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol" { + "rt:control-plane-protocol" {
when "derived-from-or-self(rt:type, 'igmp-mld:mld')" { when "derived-from-or-self(rt:type, 'igmp-mld:mld')" {
description description
"This augmentation is only valid for a control-plane "This augmentation is only valid for a control-plane
protocol instance of IGMP (type 'mld')."; protocol instance of IGMP (type 'mld').";
} }
skipping to change at page 36, line 20 skipping to change at page 38, line 19
} }
description description
"Reference to an entry in the global interface list."; "Reference to an entry in the global interface list.";
} }
uses interface-config-attributes-mld { uses interface-config-attributes-mld {
if-feature per-interface-config; if-feature per-interface-config;
} }
uses interface-state-attributes-mld; uses interface-state-attributes-mld;
} // interface } // interface
} // interfaces } // interfaces
} // mld
} // augment
/* /*
* RPCs * Actions
*/ */
rpc clear-igmp-groups { action clear-groups {
if-feature feature-igmp; if-feature action-clear-groups;
if-feature rpc-clear-groups;
description
"Clears the specified IGMP cache entries.";
input {
leaf interface-name {
type leafref {
path "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/"
+ "igmp-mld:igmp/igmp-mld:interfaces/"
+ "igmp-mld:interface/igmp-mld:interface-name";
}
description
"Name of the IGMP interface.
If it is not specified, IGMP groups from all interfaces
are cleared.";
}
leaf group-address {
type rt-types:ipv4-multicast-group-address;
description
"Multicast group IPv4 address.
If it is not specified, all IGMP group entries are
cleared.";
}
leaf source-address {
type rt-types:ipv4-multicast-source-address;
description description
"Multicast source IPv4 address. "Clears the specified MLD cache entries.";
If it is not specified, all IGMP source-group entries are
cleared.";
}
}
} // rpc clear-igmp-groups
rpc clear-mld-groups { input {
if-feature feature-mld; choice interface {
if-feature rpc-clear-groups; mandatory true;
description description
"Clears the specified MLD cache entries."; "Indicates the interface(s) from which the cache
entries are cleared.";
case name {
leaf interface-name {
type leafref {
path "/rt:routing/rt:control-plane-protocols/"
+ "rt:control-plane-protocol/"
+ "igmp-mld:mld/igmp-mld:interfaces/"
+ "igmp-mld:interface/igmp-mld:interface-name";
}
description
"Name of the MLD interface.";
}
}
case all {
leaf all-interfaces {
type empty;
description
"MLD groups from all interfaces are cleared.";
}
}
input { }
leaf interface-name { leaf group-address {
if-feature feature-mld; type union {
type leafref { type enumeration {
path "/rt:routing/rt:control-plane-protocols/" enum '*' {
+ "rt:control-plane-protocol/" description
+ "igmp-mld:mld/igmp-mld:interfaces/" "Any group address.";
+ "igmp-mld:interface/igmp-mld:interface-name"; }
}
type rt-types:ipv6-multicast-group-address;
}
description
"Multicast group IPv6 address.
If the value '*' is specified, all MLD group entries
are cleared.";
}
leaf source-address {
type rt-types:ipv6-multicast-source-address;
description
"Multicast source IPv6 address.
If the value '*' is specified, all MLD source-group
entries are cleared.";
}
} }
description } // action clear-mld-groups
"Name of the MLD interface. } // mld
If it is not specified, MLD groups from all interfaces } // augment
are cleared.";
}
leaf group-address {
type rt-types:ipv6-multicast-group-address;
description
"Multicast group IPv6 address.
If it is not specified, all MLD group entries are
cleared.";
}
leaf source-address {
type rt-types:ipv6-multicast-source-address;
description
"Multicast source IPv6 address.
If it is not specified, all MLD source-group entries are
cleared.";
}
}
} // rpc clear-mld-groups
} }
<CODE ENDS> <CODE ENDS>
5. Security Considerations 5. Security Considerations
The YANG module specified in this document defines a schema for data The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols that is designed to be accessed via network management protocols
such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF
layer is the secure transport layer, and the mandatory-to-implement layer is the secure transport layer, and the mandatory-to-implement
secure transport is Secure Shell (SSH) [RFC6242]. The lowest secure transport is Secure Shell (SSH) [RFC6242]. The lowest
skipping to change at page 39, line 46 skipping to change at page 41, line 28
/rt:routing/rt:control-plane-protocols /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/igmmp-mld:igmp /rt:control-plane-protocol/igmmp-mld:igmp
/rt:routing/rt:control-plane-protocols /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/igmp-mld:mld /rt:control-plane-protocol/igmp-mld:mld
Unauthorized access to any data node of the above subtree can Unauthorized access to any data node of the above subtree can
disclose the operational state information of IGMP or MLD on this disclose the operational state information of IGMP or MLD on this
device. device.
Some of the RPC operations in this YANG module may be considered Some of the action operations in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus sensitive or vulnerable in some network environments. It is thus
important to control access to these operations. These are the important to control access to these operations. These are the
operations and their sensitivity/vulnerability: operations and their sensitivity/vulnerability:
clear-igmp-groups /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/igmmp-mld:igmp/igmmp-mld:clear-groups
clear-mld-groups /rt:routing/rt:control-plane-protocols
/rt:control-plane-protocol/igmp-mld:mld/igmp-mld:clear-groups
Unauthorized access to any of the above RPC operations can delete Unauthorized access to any of the above action operations can delete
the IGMP or MLD membership records on this device. the IGMP or MLD membership records on this device.
6. IANA Considerations 6. IANA Considerations
RFC Ed.: In this section, replace all occurrences of 'XXXX' with the RFC Ed.: In this section, replace all occurrences of 'XXXX' with the
actual RFC number (and remove this note). actual RFC number (and remove this note).
This document registers the following namespace URIs in the IETF XML This document registers the following namespace URIs in the IETF XML
registry [RFC3688]: registry [RFC3688]:
skipping to change at page 42, line 42 skipping to change at page 44, line 22
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface [RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, March 2018. Management", RFC 8343, March 2018.
[RFC8344] M. Bjorklund, "A YANG Data Model for IP Management", [RFC8344] M. Bjorklund, "A YANG Data Model for IP Management",
RFC8344, March 2018. RFC8344, March 2018.
[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for
Routing Management (NMDA Version)", RFC 8349, March 2018. Routing Management (NMDA Version)", RFC 8349, March 2018.
[I-D.ietf-acl-yang] M. Jethanandani, L. Huang, S. Agarwal and D. [RFC8519] M. Jethanandani, S. Agarwal, L. Huang and D. Blair, "YANG
Blair, "Network Access Control List (ACL) YANG Data Data Model for Network Access Control Lists (ACLs)", RFC
Model", draft-ietf-netmod-acl-model-19(work in progress), 8519, March 2019.
April 2018.
9.2. Informative References 9.2. Informative References
[RFC4541] M. Christensen, K. Kimball and F. Solensky, [RFC4541] M. Christensen, K. Kimball and F. Solensky,
"Considerations for Internet Group Management Protocol "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping (IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC 4541, May 2006. Switches", RFC 4541, May 2006.
[RFC4605] B. Fenner, H. He, B. Haberman, and H. Sandick, "Internet [RFC4605] B. Fenner, H. He, B. Haberman, and H. Sandick, "Internet
Group Management Protocol (IGMP) / Multicast Listener Group Management Protocol (IGMP) / Multicast Listener
skipping to change at page 43, line 18 skipping to change at page 44, line 46
Proxying")", RFC 4605, August 2006. Proxying")", RFC 4605, August 2006.
[RFC5790] H. Liu, W. Cao and H. Asaeda, "Lightweight Internet Group [RFC5790] H. Liu, W. Cao and H. Asaeda, "Lightweight Internet Group
Management Protocol Version 3 (IGMPv3) and Multicast Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790, Listener Discovery Version 2 (MLDv2) Protocols", RFC 5790,
February 2010. February 2010.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, March 2018 BCP 215, RFC 8340, March 2018
[RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of YANG [RFC8407] Bierman, A., "Guidelines for Authors and Reviewers of
Data Model Documents", draft-ietf-netmod-rfc6087bis- Documents Containing YANG Data Models", RFC 8407, October
20(work in progress), March 2018. 2018.
Authors' Addresses Authors' Addresses
Xufeng Liu Xufeng Liu
Volta Networks Volta Networks
Email: xufeng.liu.ietf@gmail.com Email: xufeng.liu.ietf@gmail.com
Feng Guo Feng Guo
Huawei Technologies Huawei Technologies
 End of changes. 34 change blocks. 
131 lines changed or deleted 209 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/