RFC 8519
YANG Data Model for Network Access Control Lists (ACLs)
4.2. IETF Packet Fields Module
The packet fields module defines the necessary groups for matching on fields in the packet including Ethernet, IPv4, IPv6, and transport- layer fields. The "type" node determines which of these fields get included for any given ACL with the exception of TCP, UDP, and ICMP header fields. Those fields can be used in conjunction with any of the above Layer 2 or Layer 3 fields. Since the number of match criteria are very large, the base specification does not include these directly but references them by the 'uses' statement to keep the base module simple. In case more match conditions are needed, those can be added by augmenting choices within container "matches" in the ietf-access-control-list.yang data model. This module imports definitions from "Common YANG Data Types" [RFC6991] and references "Internet Protocol" [RFC791], "Internet Control Message Protocol" [RFC792], "Transmission Control Protocol" [RFC793], "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers" [RFC2474], "The Addition of Explicit Congestion Notification (ECN) to IP" [RFC3168], "IPv6 Scoped Address
Architecture" [RFC4007], "IP Version 6 Addressing Architecture" [RFC4291], "A Recommendation for IPv6 Address Text Representation" [RFC5952], and "Internet Protocol, Version 6 (IPv6) Specification" [RFC8200]. <CODE BEGINS> file "ietf-packet-fields@2019-03-04.yang" module ietf-packet-fields { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-packet-fields"; prefix packet-fields; import ietf-inet-types { prefix inet; reference "RFC 6991 - Common YANG Data Types."; } import ietf-yang-types { prefix yang; reference "RFC 6991 - Common YANG Data Types."; } import ietf-ethertypes { prefix eth; reference "RFC 8519 - YANG Data Model for Network Access Control Lists (ACLs)."; } organization "IETF NETMOD (Network Modeling) Working Group."; contact "WG Web: <https://datatracker.ietf.org/wg/netmod/> WG List: netmod@ietf.org Editor: Mahesh Jethanandani mjethanandani@gmail.com Editor: Lisa Huang huangyi_99@yahoo.com Editor: Sonal Agarwal sagarwal12@gmail.com Editor: Dana Blair dana@blairhome.com";
description
"This YANG module defines groupings that are used by
the ietf-access-control-list YANG module. Their usage
is not limited to ietf-access-control-list and can be
used anywhere as applicable.
Copyright (c) 2019 IETF Trust and the persons identified as
the document authors. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Simplified BSD
License set forth in Section 4.c of the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC 8519; see
the RFC itself for full legal notices.";
revision 2019-03-04 {
description
"Initial version.";
reference
"RFC 8519: YANG Data Model for Network Access Control
Lists (ACLs).";
}
/*
* Typedefs
*/
typedef operator {
type enumeration {
enum lte {
description
"Less than or equal to.";
}
enum gte {
description
"Greater than or equal to.";
}
enum eq {
description
"Equal to.";
}
enum neq {
description
"Not equal to.";
}
}
description
"The source and destination port range definitions
can be further qualified using an operator. An
operator is needed only if the lower-port is specified
and the upper-port is not specified. The operator
therefore further qualifies the lower-port only.";
}
/*
* Groupings
*/
grouping port-range-or-operator {
choice port-range-or-operator {
case range {
leaf lower-port {
type inet:port-number;
must '. <= ../upper-port' {
error-message
"The lower-port must be less than or equal to
the upper-port.";
}
mandatory true;
description
"Lower boundary for a port.";
}
leaf upper-port {
type inet:port-number;
mandatory true;
description
"Upper boundary for a port.";
}
}
case operator {
leaf operator {
type operator;
default "eq";
description
"Operator to be applied on the port below.";
}
leaf port {
type inet:port-number;
mandatory true;
description
"Port number along with the operator on which to
match.";
}
}
description
"Choice of specifying a port range or a single
port along with an operator.";
}
description
"Grouping for port definitions in the form of a
choice statement.";
}
grouping acl-ip-header-fields {
description
"IP header fields common to IPv4 and IPv6";
reference
"RFC 791: Internet Protocol.";
leaf dscp {
type inet:dscp;
description
"Differentiated Services Code Point.";
reference
"RFC 2474: Definition of the Differentiated Services
Field (DS Field) in the IPv4 and IPv6
Headers.";
}
leaf ecn {
type uint8 {
range "0..3";
}
description
"Explicit Congestion Notification.";
reference
"RFC 3168: The Addition of Explicit Congestion
Notification (ECN) to IP.";
}
leaf length {
type uint16;
description
"In the IPv4 header field, this field is known as the Total
Length. Total Length is the length of the datagram, measured
in octets, including internet header and data.
In the IPv6 header field, this field is known as the Payload
Length, which is the length of the IPv6 payload, i.e., the rest
of the packet following the IPv6 header, in octets.";
reference
"RFC 791: Internet Protocol
RFC 8200: Internet Protocol, Version 6 (IPv6) Specification.";
}
leaf ttl {
type uint8;
description
"This field indicates the maximum time the datagram is allowed
to remain in the internet system. If this field contains the
value zero, then the datagram must be dropped.
In IPv6, this field is known as the Hop Limit.";
reference
"RFC 791: Internet Protocol
RFC 8200: Internet Protocol, Version 6 (IPv6) Specification.";
}
leaf protocol {
type uint8;
description
"Internet Protocol number. Refers to the protocol of the
payload. In IPv6, this field is known as 'next-header',
and if extension headers are present, the protocol is
present in the 'upper-layer' header.";
reference
"RFC 791: Internet Protocol
RFC 8200: Internet Protocol, Version 6 (IPv6) Specification.";
}
}
grouping acl-ipv4-header-fields {
description
"Fields in the IPv4 header.";
leaf ihl {
type uint8 {
range "5..60";
}
description
"In an IPv4 header field, the Internet Header Length (IHL) is
the length of the internet header in 32-bit words and
thus points to the beginning of the data. Note that the
minimum value for a correct header is 5.";
}
leaf flags {
type bits {
bit reserved {
position 0;
description
"Reserved. Must be zero.";
}
bit fragment {
position 1;
description
"Setting the value to 0 indicates may fragment, while
setting the value to 1 indicates do not fragment.";
}
bit more {
position 2;
description
"Setting the value to 0 indicates this is the last fragment,
and setting the value to 1 indicates more fragments are
coming.";
}
}
description
"Bit definitions for the Flags field in the IPv4 header.";
}
leaf offset {
type uint16 {
range "20..65535";
}
description
"The fragment offset is measured in units of 8 octets (64 bits).
The first fragment has offset zero. The length is 13 bits";
}
leaf identification {
type uint16;
description
"An identifying value assigned by the sender to aid in
assembling the fragments of a datagram.";
}
choice destination-network {
case destination-ipv4-network {
leaf destination-ipv4-network {
type inet:ipv4-prefix;
description
"Destination IPv4 address prefix.";
}
}
description
"Choice of specifying a destination IPv4 address or
referring to a group of IPv4 destination addresses.";
}
choice source-network {
case source-ipv4-network {
leaf source-ipv4-network {
type inet:ipv4-prefix;
description
"Source IPv4 address prefix.";
}
}
description
"Choice of specifying a source IPv4 address or
referring to a group of IPv4 source addresses.";
}
}
grouping acl-ipv6-header-fields {
description
"Fields in the IPv6 header.";
choice destination-network {
case destination-ipv6-network {
leaf destination-ipv6-network {
type inet:ipv6-prefix;
description
"Destination IPv6 address prefix.";
}
}
description
"Choice of specifying a destination IPv6 address
or referring to a group of IPv6 destination
addresses.";
}
choice source-network {
case source-ipv6-network {
leaf source-ipv6-network {
type inet:ipv6-prefix;
description
"Source IPv6 address prefix.";
}
}
description
"Choice of specifying a source IPv6 address or
referring to a group of IPv6 source addresses.";
}
leaf flow-label {
type inet:ipv6-flow-label;
description
"IPv6 Flow label.";
}
reference
"RFC 4291: IP Version 6 Addressing Architecture
RFC 4007: IPv6 Scoped Address Architecture
RFC 5952: A Recommendation for IPv6 Address Text
Representation.";
}
grouping acl-eth-header-fields {
description
"Fields in the Ethernet header.";
leaf destination-mac-address {
type yang:mac-address;
description
"Destination IEEE 802 Media Access Control (MAC)
address.";
}
leaf destination-mac-address-mask {
type yang:mac-address;
description
"Destination IEEE 802 MAC address mask.";
}
leaf source-mac-address {
type yang:mac-address;
description
"Source IEEE 802 MAC address.";
}
leaf source-mac-address-mask {
type yang:mac-address;
description
"Source IEEE 802 MAC address mask.";
}
leaf ethertype {
type eth:ethertype;
description
"The Ethernet Type (or Length) value represented
in the canonical order defined by IEEE 802.
The canonical representation uses lowercase
characters.";
reference
"IEEE 802-2014, Clause 9.2.";
}
reference
"IEEE 802: IEEE Standard for Local and Metropolitan
Area Networks: Overview and Architecture.";
}
grouping acl-tcp-header-fields {
description
"Collection of TCP header fields that can be used to
set up a match filter.";
leaf sequence-number {
type uint32;
description
"Sequence number that appears in the packet.";
}
leaf acknowledgement-number {
type uint32;
description
"The acknowledgement number that appears in the
packet.";
}
leaf data-offset {
type uint8 {
range "5..15";
}
description
"Specifies the size of the TCP header in 32-bit
words. The minimum size header is 5 words and
the maximum is 15 words; thus, this gives a
minimum size of 20 bytes and a maximum of 60
bytes, allowing for up to 40 bytes of options
in the header.";
}
leaf reserved {
type uint8;
description
"Reserved for future use.";
}
leaf flags {
type bits {
bit cwr {
position 1;
description
"The Congestion Window Reduced (CWR) flag is set
by the sending host to indicate that it received
a TCP segment with the ECN-Echo (ECE) flag set
and had responded in the congestion control
mechanism.";
reference
"RFC 3168: The Addition of Explicit Congestion
Notification (ECN) to IP.";
}
bit ece {
position 2;
description
"ECN-Echo has a dual role, depending on the value
of the SYN flag. It indicates the following: if
the SYN flag is set (1), the TCP peer is ECN
capable, and if the SYN flag is clear (0), a packet
with the Congestion Experienced flag set (ECN=11)
in the IP header was received during normal
transmission (added to the header by RFC 3168).
This serves as an indication of network congestion
(or impending congestion) to the TCP sender.";
reference
"RFC 3168: The Addition of Explicit Congestion
Notification (ECN) to IP.";
}
bit urg {
position 3;
description
"Indicates that the Urgent Pointer field is significant.";
}
bit ack {
position 4;
description
"Indicates that the Acknowledgement field is significant.
All packets after the initial SYN packet sent by the
client should have this flag set.";
}
bit psh {
position 5;
description
"Push function. Asks to push the buffered data to the
receiving application.";
}
bit rst {
position 6;
description
"Reset the connection.";
}
bit syn {
position 7;
description
"Synchronize sequence numbers. Only the first packet
sent from each end should have this flag set. Some
other flags and fields change meaning based on this
flag, and some are only valid for when it is set,
and others when it is clear.";
}
bit fin {
position 8;
description
"Last package from the sender.";
}
}
description
"Also known as Control Bits. Contains nine 1-bit flags.";
reference
"RFC 793: Transmission Control Protocol.";
}
leaf window-size {
type uint16;
units "bytes";
description
"The size of the receive window, which specifies
the number of window size units beyond the segment
identified by the sequence number in the Acknowledgement
field that the sender of this segment is currently
willing to receive.";
}
leaf urgent-pointer {
type uint16;
description
"This field is an offset from the sequence number
indicating the last urgent data byte.";
}
leaf options {
type binary {
length "1..40";
}
description
"The length of this field is determined by the
Data Offset field. Options have up to three
fields: Option-Kind (1 byte), Option-Length
(1 byte), and Option-Data (variable). The Option-Kind
field indicates the type of option and is the
only field that is not optional. Depending on
what kind of option we are dealing with,
the next two fields may be set: the Option-Length
field indicates the total length of the option,
and the Option-Data field contains the value of
the option, if applicable.";
}
}
grouping acl-udp-header-fields {
description
"Collection of UDP header fields that can be used
to set up a match filter.";
leaf length {
type uint16;
description
"A field that specifies the length in bytes of
the UDP header and UDP data. The minimum
length is 8 bytes because that is the length of
the header. The field size sets a theoretical
limit of 65,535 bytes (8-byte header plus 65,527
bytes of data) for a UDP datagram. However, the
actual limit for the data length, which is
imposed by the underlying IPv4 protocol, is
65,507 bytes (65,535 minus 8-byte UDP header
minus 20-byte IP header).
In IPv6 jumbograms, it is possible to have
UDP packets of a size greater than 65,535 bytes.
RFC 2675 specifies that the Length field is set
to zero if the length of the UDP header plus
UDP data is greater than 65,535.";
}
}
grouping acl-icmp-header-fields {
description
"Collection of ICMP header fields that can be
used to set up a match filter.";
leaf type {
type uint8;
description
"Also known as control messages.";
reference
"RFC 792: Internet Control Message Protocol
RFC 4443: Internet Control Message Protocol (ICMPv6)
for Internet Protocol Version 6 (IPv6)
Specification.";
}
leaf code {
type uint8;
description
"ICMP subtype. Also known as control messages.";
reference
"RFC 792: Internet Control Message Protocol
RFC 4443: Internet Control Message Protocol (ICMPv6)
for Internet Protocol Version 6 (IPv6)
Specification.";
}
leaf rest-of-header {
type binary;
description
"Unbounded in length, the contents vary based on the
ICMP type and code. Also referred to as 'Message Body'
in ICMPv6.";
reference
"RFC 792: Internet Control Message Protocol
RFC 4443: Internet Control Message Protocol (ICMPv6)
for Internet Protocol Version 6 (IPv6)
Specification.";
}
}
}
<CODE ENDS>
4.3. ACL Examples
Requirement: Deny tcp traffic from 192.0.2.0/24, destined to
198.51.100.0/24.
Here is the ACL configuration xml for this Access Control List:
[note: '\' line wrapping for formatting only]
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<acls
xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
<acl>
<name>sample-ipv4-acl</name>
<type>ipv4-acl-type</type>
<aces>
<ace>
<name>rule1</name>
<matches>
<ipv4>
<protocol>6</protocol>
<destination-ipv4-network>198.51.100.0/24</destination\
-ipv4-network>
<source-ipv4-network>192.0.2.0/24</source-ipv4-network>
</ipv4>
</matches>
<actions>
<forwarding>drop</forwarding>
</actions>
</ace>
</aces>
</acl>
</acls>
</config>
The ACL and ACEs can be described in the command-line interface (CLI)
as the following:
acl ipv4 sample-ipv4-acl
deny tcp 192.0.2.0/24 198.51.100.0/24
Requirement: Accept all DNS traffic destined for 2001:db8::/32 on
port 53.
[note: '\' line wrapping for formatting only]
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<acls
xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
<acl>
<name>allow-dns-packets</name>
<type>ipv6-acl-type</type>
<aces>
<ace>
<name>rule1</name>
<matches>
<ipv6>
<destination-ipv6-network>2001:db8::/32</destination-i\
pv6-network>
</ipv6>
<udp>
<destination-port>
<operator>eq</operator>
<port>53</port>
</destination-port>
</udp>
</matches>
<actions>
<forwarding>accept</forwarding>
</actions>
</ace>
</aces>
</acl>
</acls>
</config>
4.4. Port Range Usage and Other Examples
When a lower-port and an upper-port are both present, it represents a range between the lower-port and upper-port with both the lower-port and upper-port included. When only a port is present, it represents a port, with the operator specifying the range. The following XML example represents a configuration where TCP traffic from source ports 16384, 16385, 16386, and 16387 is dropped. <?xml version="1.0" encoding="UTF-8"?> <config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <acls xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list"> <acl> <name>sample-port-acl</name> <type>ipv4-acl-type</type> <aces> <ace> <name>rule1</name> <matches> <tcp> <source-port> <lower-port>16384</lower-port> <upper-port>16387</upper-port> </source-port> </tcp> </matches> <actions> <forwarding>drop</forwarding> </actions> </ace> </aces> </acl> </acls> </config>
The following XML example represents a configuration where all IPv4
ICMP echo requests are dropped.
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<acls
xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
<acl>
<name>sample-icmp-acl</name>
<aces>
<ace>
<name>rule1</name>
<matches>
<ipv4>
<protocol>1</protocol>
</ipv4>
<icmp>
<type>8</type>
<code>0</code>
</icmp>
</matches>
<actions>
<forwarding>drop</forwarding>
</actions>
</ace>
</aces>
</acl>
</acls>
</config>
The following XML example represents a configuration of a single
port, port 21, that accepts TCP traffic.
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<acls
xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
<acl>
<name>sample-ipv4-acl</name>
<type>ipv4-acl-type</type>
<aces>
<ace>
<name>rule1</name>
<matches>
<tcp>
<destination-port>
<operator>eq</operator>
<port>21</port>
</destination-port>
</tcp>
</matches>
<actions>
<forwarding>accept</forwarding>
</actions>
</ace>
</aces>
</acl>
</acls>
</config>
The following XML example represents a configuration specifying all
ports that are not equal to 21 that will drop TCP packets destined
for those ports.
<?xml version="1.0" encoding="UTF-8"?>
<config xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<acls
xmlns="urn:ietf:params:xml:ns:yang:ietf-access-control-list">
<acl>
<name>sample-ipv4-acl</name>
<type>ipv4-acl-type</type>
<aces>
<ace>
<name>rule1</name>
<matches>
<tcp>
<destination-port>
<operator>neq</operator>
<port>21</port>
</destination-port>
</tcp>
</matches>
<actions>
<forwarding>drop</forwarding>
</actions>
</ace>
</aces>
</acl>
</acls>
</config>
5. Security Considerations
The YANG modules specified in this document define a schema for data
that is designed to be accessed via network management protocol such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The NETCONF Access Control Model (NACM) [RFC8341] provides the means
to restrict access for particular NETCONF or RESTCONF users to a
preconfigured subset of all available NETCONF or RESTCONF protocol
operations and content.
There are a number of data nodes defined in these YANG modules that
are writable/creatable/deletable (i.e., config true, which is the
default). These data nodes may be considered sensitive or vulnerable
in some network environments. Write operations (e.g., edit-config)
to these data nodes without proper protection can have a negative
effect on network operations. These are the subtrees and data nodes
and their sensitivity/vulnerability:
/acls/acl/aces: This list specifies all the configured access
control entries on the device. Unauthorized write access to this
list can allow intruders to modify the entries so as to permit
traffic that should not be permitted, or deny traffic that should
be permitted. The former may result in a DoS attack, or
compromise the device. The latter may result in a DoS attack.
The impact of an unauthorized read access of the list will allow
the attacker to determine which rules are in effect, to better
craft an attack.
/acls/acl/aces/ace/actions/logging: This node specifies ability to
log packets that match this ace entry. Unauthorized write access
to this node can allow intruders to enable logging on one or many
ace entries, overwhelming the server in the process. Unauthorized
read access of this node can allow intruders to access logging
information, which could be used to craft an attack the server.
6. IANA Considerations
This document registers three URIs and three YANG modules.
6.1. URI Registration
This document registers three URIs in the "IETF XML Registry"
[RFC3688] as follows:
URI: urn:ietf:params:xml:ns:yang:ietf-access-control-list
URI: urn:ietf:params:xml:ns:yang:ietf-packet-fields
URI: urn:ietf:params:xml:ns:yang:ietf-ethertypes
Registrant Contact: The IESG.
XML: N/A; the requested URI is an XML namespace.
6.2. YANG Module Name Registration
This document registers three YANG modules in the "YANG Module Names" registry [RFC6020]. Name: ietf-access-control-list Namespace: urn:ietf:params:xml:ns:yang:ietf-access-control-list Prefix: acl Reference: RFC 8519 Name: ietf-packet-fields Namespace: urn:ietf:params:xml:ns:yang:ietf-packet-fields Prefix: packet-fields Reference: RFC 8519 Name: ietf-ethertypes Namespace: urn:ietf:params:xml:ns:yang:ietf-ethertypes Prefix: ethertypes Reference: RFC 85197. References
7.1. Normative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>. [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <https://www.rfc-editor.org/info/rfc792>. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>. [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 10.17487/RFC4007, March 2005, <https://www.rfc-editor.org/info/rfc4007>. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>. [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>. [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>. [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.
7.2. Informative References
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>. [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>. [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>. [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information", STD 77, RFC 7011, DOI 10.17487/RFC7011, September 2013, <https://www.rfc-editor.org/info/rfc7011>. [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>. [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>. [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>. [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
(next page on part 3)
