<?xml version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.27 (Ruby 3.3.6) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-netmod-acl-extensions-17" number="9899" updates="" obsoletes="" xml:lang="en" category="std" consensus="true" submissionType="IETF" tocInclude="true" sortRefs="true" symRefs="true" version="3">

<!-- xml2rfc v2v3 conversion 3.28.1 [rfced] May we update the title of this document as follows? We
have received guidance from Benoit Claise and the YANG Doctors
that "YANG module" and "YANG data model" are preferred, and our
suggested text more closely matches the title of RFC 8519.

Note that if the document title is updated, we will also update the
references to this document within the YANG module (Section 4).

Original:

   Extensions to the Access Control Lists (ACLs) YANG Model

Perhaps:

   Extensions to the YANG Data Model for Access Control Lists (ACLs)
-->

  <front>
    <title abbrev="Enhanced ACLs">Extensions to the Access Control Lists (ACLs) YANG Model</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-acl-extensions-17"/> name="RFC" value="9899"/>
    <author fullname="Oscar Gonzalez de Dios" initials="O" surname="Gonzalez de Dios">
      <organization>Telefonica</organization>
      <address>
        <email>oscar.gonzalezdedios@telefonica.com</email>
      </address>
    </author>
    <author fullname="Samier Barguil"> Barguil" initials="S" surname="Barguil">
      <organization>Nokia</organization>
      <address>
        <email>samier.barguil_giraldo@nokia.com</email>
      </address>
    </author>
    <author fullname="Mohamed Boucadair"> Boucadair" initials="M" surname="Boucadair">
      <organization>Orange</organization>
      <address>
        <email>mohamed.boucadair@orange.com</email>
      </address>
   </author>
    <author fullname="Qin Wu"> Wu" initials="Q" surname="Wu">
      <organization>Huawei</organization>
      <address>
        <email>bill.wu@huawei.com</email>
      </address>
    </author>
    <date year="2025" month="April" day="04"/>
    <area>Operations and Management</area> month="November"/>
    <area>OPS</area>
    <workgroup>netmod</workgroup>
    <keyword>Internet-Draft</keyword>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

    <abstract>
      <?line 92?>
<t>RFC 8519 defines a YANG data model for Access Control Lists
(ACLs). This document specifies a set of extensions that fix many of
the limitations of the ACL model as initially defined in RFC 8519.
Specifically, it introduces augmentations to the ACL base model to enhance its functionality and applicability.</t>
      <t>The document also defines IANA-maintained modules for ICMP types and IPv6 extension headers.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    Network Modeling Working Group mailing list (netmod@ietf.org),
    which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/netmod/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/boucadair/enhanced-acl-netmod"/>.</t>
    </note>
  </front>
  <middle>
    <?line 101?>

<section anchor="introduction">
      <name>Introduction</name>
      <t><xref target="RFC8519"/> defines Access Control Lists (ACLs) as a
user-ordered set of filtering rules. The model targets the
configuration of the filtering behavior of a device. However, the
model structure, as defined in <xref target="RFC8519"/>, suffers from a set of limitations.
This document identifies these limitations and specifies an enhanced ACL structure,
introducing augmentations to the ACL base model (<xref target="sec-module"/>).
The motivation of such an enhanced ACL structure is discussed in detail in <xref target="ps"/>.</t>
      <t>When managing ACLs, it is common for network operators to group
match elements in pre-defined predefined sets. The consolidation into group matches
allows for reducing the number of rules, especially in large scale large-scale
networks. If, for For example, it is needed to find if finding a match against 100
IP addresses (or prefixes), prefixes) is needed, a single rule will suffice rather than creating
individual Access Control Entries (ACEs) for each IP address (or prefix). In
doing so, implementations would optimize the performance of matching
lists vs versus multiple rules matching.</t>
      <t>The enhanced ACL structure ("ietf-acl-enh", (see "ietf-acl-enh" in <xref target="sec-module"/>) is also meant to facilitate the management of
network operators. Instead of entering the IP address or port number
literals, using user-named lists decouples the creation of the rule
from the management of the sets. Hence, it is possible to remove/add
 entries to the list without redefining the (parent) ACL rule.</t>
      <t>In addition, the notion of ACL and defined sets
is generalized so that it is not device-specific device specific as per <xref target="RFC8519"/>.  ACLs
and defined sets may be defined at the network/administrative domain level
and associated to devices. This approach facilitates the reusability across multiple
network elements. For example, managing the IP prefix sets from a network
level makes it easier to maintain by the security groups.</t>
      <t>Network operators maintain sets of IP prefixes that are related to each other,
e.g., deny-lists or accept-lists that are associated with those provided by a
 VPN customer. These lists are maintained and manipulated by security expert teams of the network operators.</t>
      <t>Note that ACLs are used locally in devices but are triggered by other
      tools such as DDoS mitigation <xref target="RFC9132"/> or BGP Flow Spec
      <xref target="RFC8955"/> <xref target="RFC8956"/>. Therefore, it is
      valuable from a network operation standpoint to support the means to
      easily map to the filtering rules conveyed in messages triggered by
      these tools.</t>
      <t>The enhanced ACL module (<xref target="sec-module"/>) conforms to the Network
Management Datastore Architecture (NMDA) defined in <xref target="RFC8342"/>.</t>
      <t>A set of examples to illustrate the use of the enhanced ACL module are is provided in <xref target="sec-examples"/>.</t>
      <t>The
      <t>This document also defines IANA-maintained modules for ICMP types and IPv6 extension headers. The design of the modules adheres to the recommendations in <xref section="4.30.2" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>. Readers should refer to the IANA websites <xref target="IANA_ICMPv4_YANG_URL"/>, <xref target="IANA_ICMPv6_YANG_URL"/>, and <xref target="IANA_IPV6_YANG_URL"/> to retrieve the The latest version of these IANA-maintained modules.</t>
      <section anchor="editorial-note-to-be-removed-by-rfc-editor">
        <name>Editorial Note (To be removed by RFC Editor)</name>
        <t>Note to the RFC Editor: This section is to be removed prior to publication.</t>
        <t>This document contains placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed.</t>
        <t>(1) Please apply the following replacements:</t>
        <ul spacing="normal">
          <li>
            <t>XXXX --&gt; the assigned RFC number for this I-D</t>
          </li>
          <li>
            <t>2024-05-16 --&gt; the actual date of the publication of this document</t>
          </li>
        </ul>
        <t>(2) The modules are provided in <xref target="iana-icmp"/>, <xref target="iana-icmpv6"/>, and <xref target="iana-ipv6-ext"/> for the users convenience before publication as RFC. Please remove these appendices can
   be retrieved from the final RFC.</t>
        <t>(3) Please update  the following references:</t>
        <ul spacing="normal">
          <li>
            <t>IANA_ICMPv4_YANG_URL --&gt; The URL to retrieve the latest version of the IANA-maintained ICMPv4 module.</t>
          </li>
          <li>
            <t>IANA_ICMPv6_YANG_URL --&gt; The URL to retrieve the latest version of the IANA-maintained ICMPv6 module.</t>
          </li>
          <li>
            <t>IANA_IPV6_YANG_URL --&gt; The URL to retrieve the latest version of the IPv6 Extension Header Types IANA module.</t>
          </li>
        </ul>
      </section> "YANG Parameters" registry group <xref target="IANA-YANG-PARAMETERS"/>.</t>
</section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>The
        <t>
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119"/> <xref
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t>
      <?line -18?> here.
        </t>
<t>The terminology for describing YANG modules is defined in <xref target="RFC7950"/>.
The meaning of the symbols in the tree diagrams is defined in
<xref target="RFC8340"/>.</t>
      <t>In addition to the terms defined in <xref target="RFC8519"/>, this document makes use of the following term:</t>
      <dl>
        <dt>Defined set:</dt>
        <dd>
          <t>Elements in a defined set typically share a logical purpose or function, such as IP addresses, IP prefixes, port numbers, or ICMP types.</t>
        </dd>
      </dl>
    </section>
    <section anchor="overall-structure-of-the-enhanced-acl-module">
      <name>Overall Structure of the Enhanced ACL Module</name>
      <section anchor="tree-structure">
        <name>Tree Structure</name>
        <t><xref target="enh-acl-tree"/> shows the full tree of the enhanced ACL module (<xref target="sec-module"/>):</t>
        <figure anchor="enh-acl-tree">
          <name>Enhanced ACL Tree Structure</name>
          <artwork><![CDATA[
          <sourcecode type="yangtree"><![CDATA[
module: ietf-acl-enh

  augment /acl:acls:
    +--rw defined-sets
       +---u defined-sets
  augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches:
    +--rw (payload)?
    |  +--:(pattern)
    |     +--rw pattern {match-on-payload}?
    |        +---u payload-match
    +--rw (alias)?
    |  +--:(alias-name)
    |     +--rw alias-name*       alias-ref
    +--rw (mpls)?
       +--:(mpls-values)
          +--rw mpls-values {match-on-mpls}?
             +---u mpls-match-parameters-config
  augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/acl:l2:
    +--rw vlan-filter {match-on-vlan-filter}?
    |  +--rw frame-type?         string
    |  +--rw (vlan-type)?
    |     +--:(range)
    |     |  +--rw lower-vlan    uint16
    |     |  +--rw upper-vlan    uint16
    |     +--:(operator)
    |        +--rw operator?     packet-fields:operator
    |        +--rw vlan*         uint16
    +--rw isid-filter {match-on-isid-filter}?
       +--rw (isid-type)?
          +--:(range)
          |  +--rw lower-isid    uint16
          |  +--rw upper-isid    uint16
          +--:(operator)
             +--rw operator?     packet-fields:operator
             +--rw isid*         uint16
  augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/acl:l3
            /acl:ipv4/acl:ipv4:
    +--rw ipv4-fragment
    |  +---u fragment-fields
    +--rw source-ipv4-prefix-list?        ipv4-prefix-set-ref
    +--rw destination-ipv4-prefix-list?   ipv4-prefix-set-ref
    +--rw protocol-set?                   protocol-set-ref
  augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/acl:l3
            /acl:ipv6/acl:ipv6:
    +--rw ipv6-fragment
    |  +---u fragment-fields
    +--rw source-ipv6-prefix-list?        ipv6-prefix-set-ref
    +--rw destination-ipv6-prefix-list?   ipv6-prefix-set-ref
    +--rw protocol-set?                   protocol-set-ref
    +--rw extension-header?
            iana-ipv6-ext-types:ipv6-extension-header-type
  augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/acl:l4
            /acl:tcp/acl:tcp:
    +--rw flags-bitmask
    |  +---u tcp-flags
    +--rw source-tcp-port-set?        port-set-ref
    +--rw destination-tcp-port-set?   port-set-ref
  augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/acl:l4
            /acl:udp/acl:udp:
    +--rw source-udp-port-set?        port-set-ref
    +--rw destination-udp-port-set?   port-set-ref
  augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:matches/acl:l4
            /acl:icmp/acl:icmp:
    +--rw icmpv4-set?   icmpv4-type-set-ref
    +--rw icmpv6-set?   icmpv6-type-set-ref
  augment /acl:acls/acl:acl/acl:aces/acl:ace/acl:actions:
    +---u acl-complementary-actions
    +--rw rate-limit?                  decimal64
]]></artwork>
]]></sourcecode>
        </figure>
        <t><xref target="enh-acl-grp"/> shows the reusable groupings that are defined in the enhanced ACL module:</t>
        <figure anchor="enh-acl-grp">
          <name>Enhanced ACL Groupings</name>
          <artwork><![CDATA[
          <sourcecode type="yangtree"><![CDATA[
  grouping tcp-flags:
    +--rw operator?                  operator
    +-- (mode)?
       +--:(explicit)
       |  +-- explicit-tcp-flag*   identityref
       +--:(builtin)
          +-- bitmask?             uint16
  grouping fragment-fields:
    +-- operator?   operator
    +-- type?       fragment-type
  grouping mpls-match-parameters-config:
    +-- traffic-class?       uint8
    +-- label-position?      identityref
    +-- upper-label-range?   rt-types:mpls-label
    +-- lower-label-range?   rt-types:mpls-label
    +-- label-block-name?    string
    +-- ttl-value?           uint8
  grouping payload-match:
    +-- offset?       identityref
    +-- length?   uint16
    +-- operator?     operator
    +-- pattern?       binary
  grouping alias:
    +-- vlan*         uint16
    +-- prefix*       inet:ip-prefix
    +-- port-range* [lower-port]
    |  +-- lower-port    inet:port-number
    |  +-- upper-port?   inet:port-number
    +-- protocol*     uint8
    +-- fqdn*         inet:domain-name
    +-- uri*          inet:uri
  grouping icmpv4-header-fields:
    +-- type?             iana-icmpv4-types:icmpv4-type
    +-- code?             uint8
    +-- rest-of-header?   binary
  grouping icmpv6-header-fields:
    +-- type?             iana-icmpv6-types:icmpv6-type
    +-- code?             uint8
    +-- rest-of-header?   binary
  grouping acl-complementary-actions:
    +-- log-action
    |  +-- log-type?   identityref
    |  +-- log-id?     string
    +-- counter-action
       +-- counter-type?   identityref
       +-- counter-name*   string
  grouping ipv4-prefix-sets:
    +-- prefix-set* [name]
       +-- name           string
       +-- description?   string
       +-- prefix*        inet:ipv4-prefix
  grouping ipv6-prefix-sets:
    +-- prefix-set* [name]
       +-- name           string
       +-- description?   string
       +-- prefix*        inet:ipv6-prefix
  grouping port-sets:
    +-- port-set* [name]
       +-- name    string
       +-- port* [id]
          +-- id                              string
          +-- (port)?
             +--:(port-range-or-operator)
                +-- port-range-or-operator
                   +---u packet-fields:port-range-or-operator
  grouping protocol-sets:
    +-- protocol-set* [name]
       +-- name        string
       +-- protocol*   union
  grouping icmpv4-type-sets:
    +-- set* [name]
       +-- name           string
       +-- icmpv4-type* [type]
          +---u icmpv4-header-fields
  grouping icmpv6-type-sets:
    +-- set* [name]
       +-- name           string
       +-- icmpv6-type* [type]
          +---u icmpv6-header-fields
  grouping aliases:
    +-- alias* [name]
       +-- name     string
       +---u alias
  grouping defined-sets:
    +-- ipv4-prefix-sets
    |  +---u ipv4-prefix-sets
    +-- ipv6-prefix-sets
    |  +---u ipv6-prefix-sets
    +-- port-sets
    |  +---u port-sets
    +-- protocol-sets
    |  +---u protocol-sets
    +-- icmpv4-type-sets
    |  +---u icmpv4-type-sets
    +-- icmpv6-type-sets
    |  +---u icmpv6-type-sets
    +-- aliases
       +---u aliases
]]></artwork>
]]></sourcecode>
        </figure>
      </section>
      <section anchor="defined-sets">
        <name>Defined Sets</name>
        <t>The augmented ACL structure includes several containers to manage reusable sets of elements that can be matched in an ACL entry.
Each set is uniquely identified by a name and can be called from the relevant entry. The following sets (seen in <xref target="enh-acl-tree"/>) are defined (<xref target="enh-acl-tree"/>):</t> defined:</t>
        <dl>
          <dt>IPv4 prefix sets:</dt>
          <dd>
            <t>An IPv4 prefix set contains a list of IPv4 prefixes. A match will be considered if the IP address (source or destination, depending on the ACL entry) is contained in any of the prefixes in the set.</t>
          </dd>
          <dt>IPv6 prefix sets:</dt>
          <dd>
            <t>An IPv6 prefix contains a list of IPv6 prefixes. A match will be considered if the IP address (source or destination, depending on the ACL entry) is contained in any of the prefixes in the set.</t>
          </dd>
          <dt>Port sets:</dt>
          <dd>
            <t>A port set contains a list of port numbers to be used in transport protocol entries (e.g., TCP and UDP).</t>
          </dd>
          <dt/>
          <dd>
            <t>A port number can be a port range or a single port number along with an operator (equal to, greater than or equal to, etc.).</t>
          </dd>
          <dt>Protocol sets:</dt>
          <dd>
            <t>A protocol set contains a list of protocol values. A protocol can be identified either by either a number (e.g., 17) or a name (e.g., UDP).</t>
          </dd>

<!-- [rfced] Would option A or B below clarify how "optionally the
code and the rest of the header" relates to the rest of the
sentence?

Original:

   ICMP sets:  An ICMP set contains a list of ICMPv4 [RFC0792] or ICMPv6
      [RFC4443] types, each of them identified by a type value,
      optionally the code and the rest of the header.

Perhaps A:

   ICMP sets:  An ICMP set contains a list of ICMPv4 [RFC0792] or ICMPv6
      [RFC4443] types, and each type is identified by a type value,
      the code (optionally), and the rest of the header.

or
Perhaps B:

   ICMP sets:  An ICMP set contains a list of ICMPv4 [RFC0792] or ICMPv6
      [RFC4443] types, and each type is identified by a type value and is
      optionally identified by the code and the rest of the header.
-->

          <dt>ICMP sets:</dt>
          <dd>
            <t>An ICMP set contains a list of ICMPv4 <xref target="RFC0792"/> or ICMPv6 <xref target="RFC4443"/> types, each of them identified by a type value, optionally the code and the rest of the header.</t>
          </dd>
          <dt/>
          <dd>
            <t>IANA-maintained modules for ICMP types are defined in this document.</t>
          </dd>
          <dt>Aliases:</dt>
          <dd>
            <t>An alias is defined by a combination of various parameters (e.g., IP prefix, protocol, port number, or VLAN <xref target="IEEE802.1Qcp"/>). When only sets of one parameter (e.g., protocol) are handled, then the relevant parameter sets should be used (e.g., protocol set) rather than an alias.</t>
          </dd>
          <dt/>
          <dd>
            <t>For example, an alias can be defined to apply ACL policies bound to a set of HTTPS servers. Such an alias will typically include these HTTPS server addresses (e.g., "prefix": ["2001:db8:6401::1/128","2001:db8:6401::2/128"]) and the TCP port number 443 (i.e., "protocol": [6] and "lower-port": 443).</t>
          </dd>
          <dt/>
          <dd>
            <t>Sets of aliases can be defined and referred to in ACL match criteria.</t>
          </dd>
          <dt>Payload-based filtering:</dt>
          <dd>
            <t>Network
            <t>A network traffic filtering technique that examines the data payload of packets, beyond just the header information, to identify, allow, or block traffic based on specific content or patterns within the payload. An offset type (e.g., layer Layer 2 or layer Layer 3) is used to indicates indicate the position of the data in the packet to use for the match.</t>
          </dd>
        </dl>
      </section>
      <section anchor="ipv6-extension-headers">
        <name>IPv6 Extension Headers</name>
        <t>The enhanced ACL module can be used to manage ACLs that require matching against IPv6 extension headers <xref target="RFC8200"/>. To that aim, a new IANA-maintained module for IPv6 extension header types "iana-ipv6-ext-types" types, "iana-ipv6-ext-types", is defined in this document.</t>
      </section>
      <section anchor="tcp-flags-handling">
        <name>TCP Flags Handling</name>
        <t>The augmented ACL module includes a new container 'flags-bitmask' to better handle TCP flags (<xref section="3.1" sectionFormat="of" target="RFC9293"/>). Assigned TCP flags are maintained in the "TCP Header Flags" registry under the "Transmission Control Protocol (TCP) Parameters" registry group <xref target="IANA-TCP-FLAGS"/>.</t>
        <t>Clients that support both 'flags-bitmask' and 'flags' <xref target="RFC8519"/> matching fields <bcp14>MUST NOT</bcp14> set these fields in the same request.</t>
      </section>
      <section anchor="fragments-handling">
        <name>Fragments Handling</name>
        <t>The augmented ACL module includes new leafs 'ipv4-fragment' and 'ipv6-fragment' to better handle fragments.</t>
        <t>Clients that support both 'ipv4-fragment' and 'flags' <xref target="RFC8519"/> matching fields <bcp14>MUST NOT</bcp14> set these fields in the same request.</t>
      </section>

      <section anchor="payload-based-filtering">
        <name>Payload-based
        <name>Payload-Based Filtering</name>

        <t>Some transport protocols use existing protocols (e.g., TCP or UDP) as substrate. The match criteria for such protocols may rely upon the 'protocol' under 'l3', TCP/UDP match criteria, part of the TCP/UDP payload, or a combination thereof.</t>
        <t>A new feature, called 'match-on-payload', is defined in the document. This can be used, for example, for QUIC <xref target="RFC9000"/> or for tunneling protocols. This feature requires configuring a data offset, a length, and a binary pattern to match data against using a specified operator. The data offset indicates the position to look at in a packet (e.g., it starts at the beginning of the IP header or transport header).</t>
      </section>
      <section anchor="match-on-mpls-headers">
        <name>Match on MPLS Headers</name>
        <t>The enhanced ACL module (<xref target="sec-module"/>) can be used to create rules to match against the MPLS fields of a packet. The MPLS header defined in <xref target="RFC3032"/> and <xref target="RFC5462"/> contains the following fields:</t>
        <ul spacing="normal">
          <li>
            <t>Traffic Class: The 3-bit "Exp" field <xref target="RFC3032"/> target="RFC3032"/>, which is renamed to "Traffic Class field" ("TC field") <xref target="RFC5462"/>.</t>
          </li>
          <li>
            <t>Label Value: A 20-bit field that carries the actual value of the MPLS label.</t>
          </li>
          <li>
            <t>TTL: A An 8-bit field used to encode Time to Live the Time-to-Live (TTL) value.</t>
          </li>
        </ul>
        <t>The augmented ACL module can be used by an operator to configure ACLs that match based upon the following data nodes:</t>
        <ul spacing="normal">
          <li>
            <t>'traffic-class'</t>
          </li>
          <li>
            <t>'label-position' (e.g., top or bottom)</t>
          </li>
          <li>
            <t>'upper-label-range'</t>
          </li>
          <li>
            <t>'lower-label-range'</t>
          </li>
          <li>
            <t>'label-block-name'</t>
          </li>
          <li>
            <t>'ttl-value'</t>
          </li>
        </ul>
      </section>
      <section anchor="vlan-filtering">
        <name>VLAN Filtering</name>
        <t>Being able to filter all packets that are bridged within a VLAN or that
are routed into or out of a bridge domain is part of the VPN control
requirements for Ethernet VPN (EVPN) <xref target="RFC7209"/>.</t>
        <t>All packets that are bridged within a VLAN or that are routed into or
out of a VLAN can be captured, forwarded, translated, or discarded based
on the network policy.</t>
      </section>
      <section anchor="instance-service-identifier-i-sid-filtering">
        <name>Instance Service Identifier (I-SID) Filtering</name>

        <t>Provider backbone bridging Backbone Bridging (PBB) was originally defined as a Virtual
Bridged Local Area Networks standard <xref target="IEEE-802-1ah"/>
standard. target="IEEE-802-1ah"/>.
However, instead of multiplexing VLANs, PBB
duplicates the MAC Media Access Control (MAC) layer of the customer frame and separates it from
the provider domain, by encapsulating it in a 24-bit instance service
identifier Instance Service
Identifier (I-SID). This provides more transparency between the
customer network and the provider network.</t>
        <t>The I-component forms the customer customer- or access facing access-facing interface or
routing instance. The I-component is responsible for mapping customer
Ethernet traffic to the appropriate I-SID. It is
mandatory to configure the default service identifier in the network.</t>
        <t>Being

<!-- [rfced] FYI - We have updated "EVNP-PBB" to "EVPN-PBB" in the text
below. Please review.

Original:

   Being able to filter by I-component Service identifier is a feature
   of the EVNP-PBB configuration.

Current:

   Being able to filter by I-component service identifier is a feature
   of the EVPN-PBB configuration.
-->

        <t>Being able to filter by I-component service identifier is a feature of
the EVPN-PBB configuration.</t>
      </section>
      <section anchor="additional-actions">
        <name>Additional Actions</name>

        <t>In order to support rate-limiting (see <xref target="ps-rate"/>), a new action called 'rate-limit' is defined in this document.</t>
        <t>Also, the "ietf-acl-enh" module supports new actions to complement existing ones: Log log ('log-action') and write a counter ('counter-action'). The version of the module defined in this document supports only local actions.</t>
      </section>
    </section>
    <section anchor="sec-module">
      <name>Enhanced ACL YANG Module</name>
      <t>This

<!-- [rfced] Questions about Section 4

a) The following sentence does not mention RFC 8341, but RFC 8341 is
referenced in the YANG module. May we update this sentence to include
RFC 8341 as well?

Original:

   This model imports types from [RFC6991], [RFC8519], and [RFC8294].

Perhaps:

   This Yang module imports types from [RFC6991], [RFC8341], [RFC8519],
   and [RFC8294].

b) Should Qin Wu be added to the list of authors in the YANG module in
this section?

c) May we add the IANA reference information for the IANA URL listed in
this reference entry?

Original:

  reference
    "RFC 9293: Transmission Control Protocol (TCP),
               Section 3.1
     https://www.iana.org/assignments/tcp-parameters";

Perhaps:

  reference
    "RFC 9293: Transmission Control Protocol (TCP),
               Section 3.1
     IANA: Transmission Control Protocol (TCP) Parameters,
     <https://www.iana.org/assignments/tcp-parameters>";
-->

      <t>This Yang module imports types from <xref target="RFC6991"/>, <xref target="RFC8519"/>, and <xref target="RFC8294"/>.</t>
      <sourcecode markers="true" name="ietf-acl-enh@2024-05-16.yang"><![CDATA[ name="ietf-acl-enh@2025-11-07.yang" type="yang"><![CDATA[
module ietf-acl-enh {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:ietf-acl-enh";
  prefix acl-enh;

  import ietf-inet-types {
    prefix inet;
    reference
      "RFC 6991: Common YANG Data Types";
  }
  import ietf-netconf-acm {
    prefix nacm;
    reference
      "RFC 8341: Network Configuration Access Control Model";
  }
  import ietf-access-control-list {
    prefix acl;
    reference
      "RFC 8519: YANG Data Model for Network Access
                 Control Lists (ACLs), Section 4.1";
  }
  import ietf-packet-fields {
    prefix packet-fields;
    reference
      "RFC 8519: YANG Data Model for Network Access
                 Control Lists (ACLs), Section 4.2";
  }
  import ietf-routing-types {
    prefix rt-types;
    reference
      "RFC 8294: Common YANG Data Types for the Routing Area";
  }
  import iana-icmpv4-types {
    prefix iana-icmpv4-types;
    reference
      "RFC XXXX: 9899: Extensions to the Access Control Lists (ACLs)
                 YANG Model";
  }
  import iana-icmpv6-types {
    prefix iana-icmpv6-types;
    reference
      "RFC XXXX: 9899: Extensions to the Access Control Lists (ACLs)
                 YANG Model";
  }
  import iana-ipv6-ext-types {
    prefix iana-ipv6-ext-types;
    reference
      "RFC XXXX: 9899: Extensions to the Access Control Lists (ACLs)
                 YANG Model";
  }

  organization
    "IETF NETMOD Working Group";
  contact
    "WG Web:   https://datatracker.ietf.org/wg/netmod/   <https://datatracker.ietf.org/wg/netmod/>
     WG List:  mailto:netmod@ietf.org  <mailto:netmod@ietf.org>

     Author:   Mohamed Boucadair
               mailto:mohamed.boucadair@orange.com
               <mailto:mohamed.boucadair@orange.com>
     Author:   Samier Barguil
               mailto:samier.barguil_giraldo@nokia.com
               <mailto:samier.barguil_giraldo@nokia.com>
     Author:   Oscar Gonzalez de Dios
               mailto:oscar.gonzalezdedios@telefonica.com";
               <mailto:oscar.gonzalezdedios@telefonica.com>";
  description

    "This module contains YANG definitions for enhanced ACLs.

     Copyright (c) 2025 IETF Trust and the persons identified as
     authors of the code.  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 Revised 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).
     (https://trustee.ietf.org/license-info).

     This version of this YANG module is part of RFC XXXX; 9899; see the
     RFC itself for full legal notices.";

  revision 2024-05-16 2025-11-07 {
    description
      "Initial revision.";
    reference
      "RFC XXXX: 9899: Extensions to the Access Control Lists (ACLs)
                 YANG Model";
  }

  feature match-on-payload {
    description
      "Match based on a pattern is supported.";
  }

  feature match-on-vlan-filter {
    description
      "Match based on a VLAN range of vlan a VLAN list is supported.";
  }

  feature match-on-isid-filter {
    description
      "Match based on an I-SID range of a VLAN list is supported.";
  }

  feature match-on-alias {
    description
      "Match based on aliases.";
  }

  feature match-on-mpls {
    description
      "Match based on MPLS headers.";
  }

  identity offset-type {
    description
      "Base identity for payload offset type.";
  }

  identity layer2 {
    base offset-type;
    description
      "The offset starts at the beginning of the Data Link layer Layer
       header.";
  }

  identity layer3 {
    base offset-type;
    description
      "The offset starts at the beginning of the IP header.";
  }

  identity layer4 {
    base offset-type;
    description
      "The offset starts right after the IP header (including
       any options or headers pertaining to that IP layer, e.g.,
       IPv6 Extension Headers and the Authentication Header (AH)).

       This can be typically the beginning of transport header
       (e.g., UDP, TCP, SCTP, the Stream Control Transmission Protocol
       (SCTP), and DCCP) the Datagram Congestion Control Protocol (DCCP))
       or any encapsulation scheme over IP such as IP-in-IP.";
  }

  identity payload {
    base offset-type;
    description
      "The offset starts right after the end of the transport
       header.  For example, this represents the beginning of the
       TCP data right after any TCP options or the beginning of
       the UDP payload right after the UDP header.

       This type may be used for matches against any data in
       the transport payload and/or any surplus area (if any,
       such as in UDP).";
  }

  identity tcp-flag {
    description
      "Base Identity identity for the TCP Flags.";
    reference
      "RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
  }

  identity ack {
    base tcp-flag;
    description
      "Acknowledgment TCP flag bit.";
    reference
      "RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
  }

  identity syn {
    base tcp-flag;
    description
      "Synchronize sequence numbers.";
    reference
      "RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
  }

  identity fin {
    base tcp-flag;
    description
      "No more data from the sender.";
    reference
      "RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
  }

  identity urg {
    base tcp-flag;
    description
      "Urgent pointer TCP flag bit.";
    reference
      "RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
  }

  identity psh {
    base tcp-flag;
    description
      "The Push function flag is similar to the URG flag and tells
       the receiver to process these packets as they are received
       instead of buffering them.";
    reference
      "RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
  }

  identity rst {
    base tcp-flag;
    description
      "Reset TCP flag bit.";
    reference
      "RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
  }

  identity ece {
    base tcp-flag;
    description
      "ECN-Echo TCP flag bit.";
    reference
      "RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
  }

  identity cwr {
    base tcp-flag;
    description
      "Congestion Window Reduced flag bit.";
    reference
      "RFC 9293: Transmission Control Protocol (TCP), Section 3.1";
  }

  identity ae {
    base tcp-flag;
    description
      "Accurate ECN. Explicit Congestion Notification (ECN).

       Previously used as NS (Nonce Sum), Nonce Sum (NS), which is now
       historic.";
  }

  identity mpls-acl-type {
    base acl:acl-base;
    description
      "An ACL that matches on fields from the MPLS header.";
  }

  identity label-position {
    description
      "Base identity for deriving MPLS label position.";
  }

  identity top {
    base label-position;
    description
      "Top of the label stack.";
  }

  identity bottom {
    base label-position;
    description
      "Bottom of the label stack.";
  }

  identity log-types {
    description
      "Base identity for deriving the Log log actions.";
  }

  identity local-log {
    base log-types;
    description
      "A local log is used to record the ACL results.";
  }

  identity counter-type {
    description
      "Base identity for deriving the counter actions.";
  }

  identity counter-name {
    base counter-type;
    description
      "Identity for counter name to be updated based on
        the ACL match actions.";
  }

  typedef operator {
    type bits {
      bit not {
        position 0;
        description
          "If set, the logical negation of operation.";
      }
      bit match {
        position 1;
        description
          "Match bit.  This is a bitwise match operation defined as
           '(data & value) == value'.";
      }
      bit any {
        position 2;
        description
          "Any bit.  This is a match on any of the bits in bitmask.
           It evaluates to 'true' if any of the bits in the
           value mask are set in the data, i.e.,
           '(data & value) != 0'.";
      }
    }
    description
      "Specifies how to apply the defined bitmask.  The
       'any' and 'match' bits must not be set simultaneously.";
  }

  typedef fragment-type {
    type bits {
      bit df {
        position 0;
        description
          "Don't fragment bit for IPv4.  Must be set to 0 when it
           appears in an IPv6 filter.";
      }
      bit isf {
        position 1;
        description
          "Is a fragment.";
      }
      bit ff {
        position 2;
        description
          "First fragment.";
      }
      bit lf {
        position 3;
        description
          "Last fragment.";
      }
    }
    description
      "Different fragment types to match against.";
  }

  typedef ipv4-prefix-set-ref {
    type leafref {
      path "/acl:acls/acl-enh:defined-sets/acl-enh:ipv4-prefix-sets"
         + "/acl-enh:prefix-set/acl-enh:name";
    }
    description
      "Defines a reference to an IPv4 prefix set.";
  }

  typedef ipv6-prefix-set-ref {
    type leafref {
      path "/acl:acls/acl-enh:defined-sets/acl-enh:ipv6-prefix-sets"
         + "/acl-enh:prefix-set/acl-enh:name";
    }
    description
      "Defines a reference to an IPv6 prefix set.";
  }

  typedef port-set-ref {
    type leafref {
      path "/acl:acls/acl-enh:defined-sets/acl-enh:port-sets"
         + "/acl-enh:port-set/acl-enh:name";
    }
    description
      "Defines a reference to a port set.";
  }

  typedef protocol-set-ref {
    type leafref {
      path "/acl:acls/acl-enh:defined-sets/acl-enh:protocol-sets"
         + "/acl-enh:protocol-set/acl-enh:name";
    }
    description
      "Defines a reference to a protocol set.";
  }

  typedef icmpv4-type-set-ref {
    type leafref {
      path "/acl:acls/acl-enh:defined-sets/acl-enh:icmpv4-type-sets"
         + "/acl-enh:set/acl-enh:name";
    }
    description
      "Defines a reference to an ICMPv4 type set.";
  }

  typedef icmpv6-type-set-ref {
    type leafref {
      path "/acl:acls/acl-enh:defined-sets/acl-enh:icmpv6-type-sets"
         + "/acl-enh:set/acl-enh:name";
    }
    description
      "Defines a reference to an ICMPv6 type set.";
  }

  typedef alias-ref {
    type leafref {
      path "/acl:acls/acl-enh:defined-sets/acl-enh:aliases"
         + "/acl-enh:alias/acl-enh:name";
    }
    description
      "Defines a reference to an alias.";
  }

  grouping tcp-flags {
    description
      "Operations on TCP flags.";
    leaf operator {
      type operator;
      description
        "How to interpret the TCP flags.";
    }
    choice mode {
      description
        "Choice of how flags are indicated.";
      case explicit {
        leaf-list explicit-tcp-flag {
          type identityref {
            base acl-enh:tcp-flag;
          }
          description
            "An explicit list of the TCP flags that are to be
             matched.";
        }
      }
      case builtin {
        leaf bitmask {
          type uint16;
          description
            "The bitmask matches the last 4 bits of byte 13
             and byte 14 of the TCP header.
             For clarity, the 4 bits of byte 12
             corresponding to the TCP data offset field are not
             included in any matching.  Assigned TCP flags
             and their position are maintained in the IANA'Transmission IANA
             'Transmission Control Protocol (TCP) Parameters'
             registry group.";
          reference
            "RFC 9293: Transmission Control Protocol (TCP),
                       Section 3.1
             https://www.iana.org/assignments/tcp-parameters";
             <https://www.iana.org/assignments/tcp-parameters>";
        }
      }
    }
  }

  grouping fragment-fields {
    description
      "Operations on fragment types.";
    leaf operator {
      type operator;
      default "match";
      description
        "How to interpret the fragment type.";
    }
    leaf type {
      type fragment-type;
      description
        "Specifies what fragment type to look for.";
    }
  }

  grouping mpls-match-parameters-config {
    description
      "Parameters for the configuration of MPLS match rules.";
    leaf traffic-class {
      type uint8 {
        range "0..7";
      }
      description
        "The value of the MPLS traffic class Traffic Class (TC) bits,
         formerly known as the EXP bits.";
    }
    leaf label-position {
      type identityref {
        base acl-enh:label-position;
      }
      description
        "Position of the label.";
    }
    leaf upper-label-range {
      type rt-types:mpls-label;
      description
        "Match MPLS label value on the MPLS header.
         The usage of this field indicated indicates the upper
         range value in the top of the stack.  This
         label value does not include the encodings
         of Traffic Class and TTL.";
      reference
        "RFC 3032: MPLS Label Stack Encoding";
    }
    leaf lower-label-range {
      type rt-types:mpls-label;
      description
        "Match MPLS label value on the MPLS header.
         The usage of this field indicated indicates the lower
         range value in the top of the stack.
         This label value does not include the
         encodings of Traffic Class and TTL.";
      reference
        "RFC 3032: MPLS Label Stack Encoding";
    }
    leaf label-block-name {
      type string;
      description
        "Reference to a label block predefiend predefined in the
         implementation.";
    }
    leaf ttl-value {
      type uint8;
      description
        "Time-to-live MPLS packet value match.";
      reference
        "RFC 3032: MPLS Label Stack Encoding";
    }
  }

  grouping payload-match {
    description
      "Operations on payload match.";
    leaf offset {
      type identityref {
        base acl-enh:offset-type;
      }
      description
        "Indicates the payload offset.  This will indicate
         the position of the data in the packet to use for
         the match.";
    }
    leaf length {
      type uint16;
      units "bytes";
      description
        "Indicates the number of bytes to ignore, starting from
         the offset, to perform the pattern match.";
    }
    leaf operator {
      type operator;
      default "match";
      description
        "How to interpret the pattern match.";
    }
    leaf pattern {
      type binary;
      description
        "The binary pattern to match against starting.
         The match starts from the byte indicated by
         'offset' + length'.";
    }
  }

  grouping alias {
    description
      "Specifies an alias.";
    leaf-list vlan {
      type uint16;
      description
        "VLAN of the alias.";
      reference
        "IEEE Std 802.1Q: Bridges and Bridged Networks";
    }
    leaf-list prefix {
      type inet:ip-prefix;
      description
        "IPv4 or IPv6 prefix of the alias.";
    }
    list port-range {
      key "lower-port";
      description
        "Port range.  When only lower-port is
         present, it represents a single port number.";
      leaf lower-port {
        type inet:port-number;
        mandatory true;
        description
          "Lower port number of the port range.";
      }
      leaf upper-port {
        type inet:port-number;
        must '. >= ../lower-port' {
          error-message
            "The upper-port number must be greater than
             or equal to the lower-port number.";
        }
        description
          "Upper port number of the port range.";
      }
    }
    leaf-list protocol {
      type uint8;
      description
        "Identifies the target protocol number.
         For example, 6 for TCP or 17 for UDP.";
    }
    leaf-list fqdn {
      type inet:domain-name;
      description
        "FQDN
        "Fully Qualified Domain Name (FQDN) identifying the target.";
    }
    leaf-list uri {
      type inet:uri;
      description
        "URI identifying the target.";
    }
  }

  grouping icmpv4-header-fields {
    description
      "Collection of ICMPv4 header fields that can be
       used to set up a match filter.";
    leaf type {
      type iana-icmpv4-types:icmpv4-type;
      description
        "Also known as control messages.";
      reference
        "RFC 792: Internet Control Message Protocol.";
    }
    leaf code {
      type uint8;
      description
        "ICMP subtype.";
      reference
        "RFC 792: Internet Control Message Protocol.";
    }
    leaf rest-of-header {
      type binary;
      description
        "Unbounded in length, the contents vary based on the
         ICMP type and code.";
      reference
        "RFC 792: Internet Control Message Protocol";
    }
  }

  grouping icmpv6-header-fields {
    description
      "Collection of ICMPv6 header fields that can be
       used to set up a match filter.";
    leaf type {
      type iana-icmpv6-types:icmpv6-type;
      description
        "Also known as control messages.";
      reference
        "RFC 4443: Internet Control Message Protocol (ICMPv6)
                   for Internet Protocol Version 6 (IPv6)
                   Specification.";
    }
    leaf code {
      type uint8;
      description
        "ICMP code.";
      reference
        "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 4443: Internet Control Message Protocol (ICMPv6)
                   for Internet Protocol Version 6 (IPv6)
                   Specification.";
    }
  }

  grouping acl-complementary-actions {
    description
      "Collection of complementary ACL actions.";
    container log-action {
      description
        "Container for defining log actions.";
      leaf log-type {
        type identityref {
          base acl-enh:log-types;
        }
        description
          "The type of log action to be performed.";
      }
      leaf log-id {
        when "derived-from-or-self(../log-type, "
           + "'acl-enh:local-log')" {
          description
            "Name of the log file updated when type is 'local-log'.";
        }
        type string;
        description
          "The name of the counter action.";
      }
    }
    container counter-action {
      description
        "Container for defining counter actions.";
      leaf counter-type {
        type identityref {
          base acl-enh:counter-type;
        }
        description
          "The type of counter action to be performed.";
      }
      leaf-list counter-name {
        when "derived-from-or-self(../counter-type, "
           + "'acl-enh:counter-name')" {
          description
            "Name for the counter or variable to update when
             'counter-type' is 'counter-name'.";
        }
        type string;
        description
          "List of possible variables or counter names to
           update based on match critieria."; criteria.";
      }
    }
  }

  grouping ipv4-prefix-sets {
    description
      "Data definitions for a list of IPv4 prefixes
       prefixes prefixes,
       which are matched as part of a policy.";
    list prefix-set {
      key "name";
      description
        "List of the defined prefix sets.";
      leaf name {
        type string;
        description
          "Name of the prefix set -- this is used as a label to
           reference the set in match conditions.";
      }
      leaf description {
        type string;
        description
          "Defined Set set description.";
      }
      leaf-list prefix {
        type inet:ipv4-prefix;
        description
          "List of IPv4 prefixes to be used in match
           conditions.";
      }
    }
  }

  grouping ipv6-prefix-sets {
    description
      "Data definitions for a list of IPv6 prefixes prefixes, which are
       matched as part of a policy.";
    list prefix-set {
      key "name";
      description
        "List of the defined prefix sets.";
      leaf name {
        type string;
        description
          "Name of the prefix set -- this is used as a label to
           reference the set in match conditions.";
      }
      leaf description {
        type string;
        description
          "A textual description of the prefix list.";
      }
      leaf-list prefix {
        type inet:ipv6-prefix;
        description
          "List of IPv6 prefixes to be used in match conditions.";
      }
    }
  }

  grouping port-sets {
    description
      "Data definitions for a list of ports ports, which can
       be matched in policies.";
    list port-set {
      key "name";
      description
        "List of port set definitions.";
      leaf name {
        type string;
        description
          "Name of the port set -- this is used as a label to
           reference the set in match conditions.";
      }
      list port {
        key "id";
        description
          "Port numbers along with the operator on which to
           match.";
        leaf id {
          type string;
          description
            "Identifier of the list of port numbers.";
        }
        choice port {
          description
            "Choice of specifying the port number or referring to a
             group of port numbers.";
          container port-range-or-operator {
            description
              "Indicates a set of ports.";
            uses packet-fields:port-range-or-operator;
          }
        }
      }
    }
  }

  grouping protocol-sets {
    description
      "Data definitions for a list of protocols protocols, which can be
       matched in policies.";
    list protocol-set {
      key "name";
      description
        "List of protocol set definitions.";
      leaf name {
        type string;
        description
          "Name of the protocols set -- this is used as a
           label to reference the set in match conditions.";
      }
      leaf-list protocol {
        type union {
          type uint8;
          type string;
        }
        description
          "Value of the protocol set.";
      }
    }
  }

  grouping icmpv4-type-sets {
    description
      "Data definitions for a list of ICMPv4 types types, which can be
       matched in policies.";
    list set {
      key "name";
      description
        "List of ICMPv4 type set definitions.";
      leaf name {
        type string;
        description
          "Name of the ICMPv4 type set -- this is used as a label
           to reference the set in match conditions.";
      }
      list icmpv4-type {
        key "type";
        description
          "Includes a list of ICMPv4 types.";
        uses icmpv4-header-fields;
      }
    }
  }

  grouping icmpv6-type-sets {
    description
      "Data definitions for a list of ICMPv6 types types, which can be
       matched in policies.";
    list set {
      key "name";
      description
        "List of ICMP type set definitions.";
      leaf name {
        type string;
        description
          "Name of the ICMPv6 type set -- this is used as a label
           to reference the set in match conditions.";
      }
      list icmpv6-type {
        key "type";
        description
          "Includes a list of ICMPv6 types.";
        uses icmpv6-header-fields;
      }
    }
  }

  grouping aliases {
    description
      "Grpuing
      "Grouping for a set of aliases.";
    list alias {
      key "name";
      description
        "List of aliases.";
      leaf name {
        type string;
        description
          "The name of the alias.";
      }
      uses alias;
    }
  }

  grouping defined-sets {
    description
      "Predefined sets of attributes used in policy match
       statements.";
    container ipv4-prefix-sets {
      description
        "Data definitions for a list of IPv4 or IPv6
         prefixes
         prefixes, which are matched as part of a policy.";
      uses ipv4-prefix-sets;
    }
    container ipv6-prefix-sets {
      description
        "Data definitions for a list of IPv6 prefixes prefixes, which are
         matched as part of a policy.";
      uses ipv6-prefix-sets;
    }
    container port-sets {
      description
        "Data definitions for a list of ports ports, which can
         be matched in policies.";
      uses port-sets;
    }
    container protocol-sets {
      description
        "Data definitions for a list of protocols protocols, which can be
         matched in policies.";
      uses protocol-sets;
    }
    container icmpv4-type-sets {
      description
        "Data definitions for a list of ICMPv4 types types, which can be
         matched in policies.";
      uses icmpv4-type-sets;
    }
    container icmpv6-type-sets {
      description
        "Data definitions for a list of ICMPv6 types types, which can be
         matched in policies.";
      uses icmpv6-type-sets;
    }
    container aliases {
      description
        "Top-level container for aliases.";
      uses aliases;
    }
  }

  augment "/acl:acls" {
    description
      "predefined sets.";
    container defined-sets {
      description
        "Predefined sets of attributes used in policy match
         statements.";
      uses defined-sets;
      nacm:default-deny-write;
    }
  }

  augment "/acl:acls/acl:acl/acl:aces/acl:ace"
        + "/acl:matches" {
    description
      "Adds a match type based on the payload.";
    choice payload {
      description
        "Matches based upon a prefix pattern.";
      container pattern {
        if-feature "match-on-payload";
        description
          "Indicates the rule to perform the payload-based match.";
        uses payload-match;
      }
    }
    choice alias {
      description
        "Matches based upon aliases.";
      leaf-list alias-name {
        type alias-ref;
        description
          "Indicates one or more aliases.";
      }
    }
    choice mpls {
      description
        "Matches against MPLS headers, for example, label
         values";
         values.";
      container mpls-values {
        if-feature "match-on-mpls";
        description
          "Provides the rule set that matches MPLS headers.";
        uses mpls-match-parameters-config;
      }
    }
  }

  augment "/acl:acls/acl:acl/acl:aces"
        + "/acl:ace/acl:matches/acl:l2" {
    description
      "Adds a match type based on MAC VLAN and I-SID filters.";
    container vlan-filter {
      if-feature "match-on-vlan-filter";
      description
        "Indicates how to handle MAC VLANs.";
      leaf frame-type {
        type string;
        description
          "Entering the frame type allows the
           filter to match a specific type of frame format"; format.";
      }
      choice vlan-type {
        description
          "VLAN definition from range or operator.";
        case range {
          leaf lower-vlan {
            type uint16;
            must '. <= ../upper-vlan' {
              error-message
                "The lower-vlan must be less than or equal to
                 the upper-vlan.";
            }
            mandatory true;
            description
              "Lower boundary for a VLAN.";
          }
          leaf upper-vlan {
            type uint16;
            mandatory true;
            description
              "Upper boundary for a VLAN.";
          }
        }
        case operator {
          leaf operator {
            type packet-fields:operator;
            default "eq";
            description
              "Operator to be applied on the VLAN below.";
          }
          leaf-list vlan {
            type uint16;
            description
              "VLAN number along with the operator on which to
               match.";
            reference
              "IEEE Std 802.1Q: Bridges and Bridged Networks";
          }
        }
      }
    }
    container isid-filter {
      if-feature "match-on-isid-filter";
      description
        "Indicates how to handle I-SID filters.  The
         I-component is responsible for mapping customer
         Ethernet traffic to the appropriate I-SID.";
      choice isid-type {
        description
          "I-SID definition from range or operator.";
        case range {
          leaf lower-isid {
            type uint16;
            must '. <= ../upper-isid' {
              error-message
                "The lower-isid must be less than or equal to
                 the upper-isid.";
            }
            mandatory true;
            description
              "Lower boundary for an I-SID.";
          }
          leaf upper-isid {
            type uint16;
            mandatory true;
            description
              "Upper boundary for an I-SID.";
          }
        }
        case operator {
          leaf operator {
            type packet-fields:operator;
            default "eq";
            description
              "Operator to be applied on the I-SID below.";
          }
          leaf-list isid {
            type uint16;
            description
              "I-SID number along with the operator on which to
               match.";
            reference
              "IEEE 802.1ah: Provider Backbone Bridges";
          }
        }
      }
    }
  }

  augment "/acl:acls/acl:acl/acl:aces"
        + "/acl:ace/acl:matches/acl:l3/acl:ipv4/acl:ipv4" {
    description
      "Handle non-initial and initial fragments for IPv4 packets.";
    container ipv4-fragment {
      must 'not(../acl:flags)' {
        error-message
          "Either flags or fragment should be provided, but not
           both.";
      }
      description
        "Indicates how to handle IPv4 fragments.";
      uses fragment-fields;
    }
    leaf source-ipv4-prefix-list {
      type ipv4-prefix-set-ref;
      description
        "A reference to an IPv4 prefix list to match the source
         address.";
    }
    leaf destination-ipv4-prefix-list {
      type ipv4-prefix-set-ref;
      description
        "A reference to a prefix list to match the destination
         address.";
    }
    leaf protocol-set {
      type protocol-set-ref;
      description
        "A reference to a protocol set to match the protocol
         field.";
    }
  }

  augment "/acl:acls/acl:acl/acl:aces"
        + "/acl:ace/acl:matches/acl:l3/acl:ipv6/acl:ipv6" {
    description
      "Handles non-initial and initial fragments for IPv6 packets.";
    container ipv6-fragment {
      description
        "Indicates how to handle IPv6 fragments.";
      uses fragment-fields;
    }
    leaf source-ipv6-prefix-list {
      type ipv6-prefix-set-ref;
      description
        "A reference to a prefix list to match the source address.";
    }
    leaf destination-ipv6-prefix-list {
      type ipv6-prefix-set-ref;
      description
        "A reference to a prefix list to match the destination
         address.";
    }
    leaf protocol-set {
      type protocol-set-ref;
      description
        "A reference to a protocol set to match the next-header
         field.";
    }
    leaf extension-header {
      type iana-ipv6-ext-types:ipv6-extension-header-type;
      description
        "IPv6 extension header value.";
    }
  }

  augment "/acl:acls/acl:acl/acl:aces"
        + "/acl:ace/acl:matches/acl:l4/acl:tcp/acl:tcp" {
    description
      "Handles TCP flags and port sets.";
    container flags-bitmask {
      must 'not(../acl:flags)' {
        error-message
          "Either flags or flags-bitmask should be provided, but not
           both.";
      }
      description
        "Indicates how to handle TCP flags.";
      uses tcp-flags;
    }
    leaf source-tcp-port-set {
      type port-set-ref;
      description
        "A reference to a port set to match the source port.";
    }
    leaf destination-tcp-port-set {
      type port-set-ref;
      description
        "A reference to a port set to match the destination port.";
    }
  }

  augment "/acl:acls/acl:acl/acl:aces"
        + "/acl:ace/acl:matches/acl:l4/acl:udp/acl:udp" {
    description
      "Handle UDP port sets.";
    leaf source-udp-port-set {
      type port-set-ref;
      description
        "A reference to a port set to match the source port.";
    }
    leaf destination-udp-port-set {
      type port-set-ref;
      description
        "A reference to a port set to match the destination port.";
    }
  }

  augment "/acl:acls/acl:acl/acl:aces"
        + "/acl:ace/acl:matches/acl:l4/acl:icmp/acl:icmp" {
    description
      "Handle ICMP type sets.";
    leaf icmpv4-set {
      type icmpv4-type-set-ref;
      description
        "A reference to an ICMPv4 type set to match the ICMPv4 type
         field.";
    }
    leaf icmpv6-set {
      type icmpv6-type-set-ref;
      description
        "A reference to an ICMPv6 type set to match the ICMPv6 type
         field.";
    }
  }

  augment "/acl:acls/acl:acl/acl:aces"
        + "/acl:ace/acl:actions" {
    description
      "Complementary actions including Rate-limit rate-limit action.";
    uses acl-complementary-actions;
    leaf rate-limit {
      when "../acl:forwarding = 'acl:accept'" {
        description
          "Rate-limit valid only when the accept action is used.";
      }
      type decimal64 {
        fraction-digits 2;
      }
      units "bytes per second";
      description
        "Indicates a rate-limit for the matched traffic.";
    }
  }
}
]]></sourcecode>
    </section>

<!-- [rfced] Questions about the Security Considerations (Section 5)

  For reference:
    YANG security considerations template:
    <https://wiki.ietf.org/group/ops/yang-security-guidelines>

a) The "RPC/action operations section" does not appear in this
document.  The YANG security considerations template suggests
including the following text if this section does not apply;
should this text be added to this section?

Perhaps:

   "There are no particularly sensitive RPC or action operations."

b) The "Reusable groupings from other modules section" does not appear
in this document. Please review the template and confirm that this
paragraph does not apply.

c) Per the "No data nodes section" portion of the YANG security
considerations template, should it be included whether the
"ietf-acl-enh" YANG module defines a set of identities, types, and
groupings? Also, is it correct to include the three IANA modules in
this paragraph, or should the modules or this paragraph perhaps be
removed since the IANA modules were removed from the document itself?

Current:

   The YANG modules "iana-icmpv4-types", "iana-icmpv6-types", and "iana-
   ipv6-ext-types" define a set of identities, types, and groupings.
   These nodes are intended to be reused by other YANG modules.  Each
   module by itself does not expose any data nodes that are writable,
   data nodes that contain read-only state, or RPCs.

d) Per the "No data nodes section" portion of the YANG security
considerations template, should the following paragraph be added to
Section 5? If so, please review and let us know what we may replace
'node-example' with.

Perhaps:

   Modules that use the groupings that are defined in this document
   should identify the corresponding security considerations.  For
   example, reusing some of these groupings will expose privacy-related
   information (e.g., 'node-example').
-->

    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This section is modeled after the template described in <xref section="3.7" section="3.7.1" sectionFormat="of" target="I-D.ietf-netmod-rfc8407bis"/>.</t>

      <t>The "ietf-acl-enh" YANG module defines a data model that is designed
      to be accessed via YANG-based management protocols, such as NETCONF
      <xref target="RFC6241"/> and RESTCONF <xref target="RFC8040"/>.  These YANG-based management
      protocols (1) have to use a secure transport layer (e.g., SSH <xref
      target="RFC4252"/>, TLS <xref target="RFC8446"/>, and QUIC <xref
      target="RFC9000"/>) and (2) have to use mutual authentication.</t>

      <t>The Network Configuration Access Control Model (NACM) <xref
      target="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.</t>

      <t>There are a number of data nodes defined in this YANG module that are
      writable/creatable/deletable (i.e., "config true", which is the
      default). All writable data nodes are likely to be reasonably sensitive
      or vulnerable in some network environments. Write operations (e.g.,
      edit-config) and delete operations to these data nodes without proper
      protection or authentication can have a negative effect on network
      operations. The following subtrees and data nodes have particular
      sensitivities/vulnerabilities:</t>

      <dl>
        <dt>'defined-sets':</dt>
        <dd>
          <t>These lists specify a set of IP addresses, port numbers,
          protocols, ICMP types, and aliases. Similar to <xref
          target="RFC8519"/>, unauthorized write access to these lists can
          allow intruders to modify the entries so as to permit traffic that should
          not be permitted, permitted or deny traffic that should be permitted. The
          former may result in a DoS attack, attack or compromise a device. The latter
          may result in a DoS attack.</t>
        </dd>
        <dt/>
        <dd>
          <t>These sets are defined with "nacm:default-deny-write" tagging.</t>
        </dd>
      </dl>

<t>Some of the readable data nodes in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access (e.g., via get, get-config, or
notification) to these data nodes. Specifically, the following subtrees and data
nodes have particular sensitivities/vulnerabilities:</t>

      <dl>
        <dt>'defined-sets':</dt>
        <dd>
          <t>Unauthorized read access of these lists will allow
an attacker to identify the actual resources that are bound
to ACLs. Likewise, access to this information will help an attacker to
better scope its attacks to target resources that are specific to a given network instead
of performing random scans. Also, disclosing some of this information (e.g., IP addresses of core routers)
may nullify the effect of topology hiding topology-hiding strategies in some networks.</t>
        </dd>
      </dl>
      <t>The document defines a match policy based on a pattern that can be
      observed in a packet. For example, such a policy can be combined with
      header-based matches in the context of DDoS mitigation. Filtering based
      on a pattern match is deterministic for packets with unencrypted
      data. However, the efficiency for encrypted packets depend depends on the
      presence of an unvarying pattern. Readers may also refer to <xref
      section="11" sectionFormat="of" target="RFC8329"/> for security
      considerations related to Network Security Functions (NSFs) that apply
      packet content matching.</t>
      <t>The YANG modules "iana-icmpv4-types", "iana-icmpv6-types", and
      "iana-ipv6-ext-types" define a set of types. identities, types, and
      groupings. These nodes are intended to be reused by other YANG
      modules. Each of these modules module by itself does not expose any data nodes
      that are writable, data nodes that contain read-only state, or RPCs. As
      such, there are no additional security issues related to these YANG
      modules that need to be considered.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <section anchor="uri-registrations">
        <name>URI Registrations</name>
        <t>This

<!-- [rfced] We have included specific questions about the IANA
text below. In addition to responding to those questions, please
review all of the IANA-related updates carefully and let us know
if any further updates are needed.

a) We note that RFC 9890 is included as a reference for the "YANG Module
Names" registry <https://www.iana.org/assignments/yang-parameters/>.
Should RFC 9890 be added to the text below and to the Informative
References section?

Current:
   IANA has registered the following YANG modules in the "YANG Module
   Names" registry [RFC6020] within the "YANG Parameters" registry
   group.

Perhaps:
   IANA has registered the following YANG modules in the "YANG Module
   Names" registry [RFC6020] [RFC9890] within the "YANG Parameters"
   registry group.

b) FYI: Per the note from the authors, we replaced the [IANA_ICMPv4_YANG_URL],
[IANA_ICMPv6_YANG_URL], and [IANA_IPV6_YANG_URL] citations with the
[IANA-YANG-PARAMETERS] citation as shown below.

Original:

 (Section 1)
   Readers should refer to the IANA websites [IANA_ICMPv4_YANG_URL],
   [IANA_ICMPv6_YANG_URL], and [IANA_IPV6_YANG_URL] to retrieve the
   latest version of these IANA-maintained modules.

 (Section 6.3.1)
   When this registry is modified, the YANG module "iana-
   icmpv4-types" [IANA_ICMPv4_YANG_URL] must be updated as defined in
   RFC 9899.

 (Section 6.3.2)
   When this registry is modified, the YANG module "iana-
   icmpv6-types" [IANA_ICMPv6_YANG_URL] must be updated as defined in
   RFC 9899.

 (Section 6.3.3)
   When this registry is modified, the YANG module "iana-ipv6-ext-
   types" [IANA_IPV6_YANG_URL] must be updated as defined in RFC 9899.

Current:

 (Section 1)
   The latest version of these IANA-maintained modules can
   be retrieved from the "YANG Parameters" registry group
   [IANA-YANG-PARAMETERS].

 (Section 6.3.1)
   When this registry is modified, the YANG module "iana-
   icmpv4-types" [IANA-YANG-PARAMETERS] must be updated
   as defined in RFC 9899.

 (Section 6.3.2)
   When this registry is modified, the YANG module "iana-
   icmpv6-types" [IANA-YANG-PARAMETERS] must be updated
   as defined in RFC 9899.

 (Section 6.3.3)
   When this registry is modified, the YANG module "iana-
   ipv6-ext-types" [IANA-YANG-PARAMETERS] must be updated
   as defined in RFC 9899.

c) We note that the description of "enum" appears slightly different
in Sections 6.3.1, 6.3.2, and 6.3.3. Should these instances be made
consistent? If so, please let us know how to update.

In addition, should "striped" be "stripped"?

Original:

   "enum":  Replicates the name from the registry with all illegal
      characters (e.g., spaces) are striped.

   "enum":  Replicates the name from the registry with all illegal
      characters (e.g., spaces) striped.

   "enum":  Replicates the description from the registry with all spaces
      striped.

Perhaps:

    "enum":  Replicates the name from the registry with all illegal
      characters (e.g., spaces) stripped.

d) We note that this item appears slightly different in the following
sections. Please review and let us know if/how to update for
consistency.

Usage in Sections 6.3.1. and 6.3.2:

   "description":  Replicates the name from the registry.

Usage in Section 6.3.3:

   "description":  Replicates the description from the registry.

e) FYI: We typically note that a document requests has been added as an
additional reference to a registry within the running text (in
paragraph form). Thus, we updated the text in Sections 6.3.1, 6.3.2,
and 6.3.3 as shown below (i.e., removed "OLD/NEW" and removed RFCs
2780, 5237, and 7045 from the Informative References section as they
were only mentioned in the "OLD/NEW" text). Please let us know of
any objection.

One example (from Section 6.3.1)

Original:
   IANA is requested to add this note to "ICMP Type Numbers" [IANA-ICMPv4]:

      [...]

   IANA is requested to register update the "Reference" in the "ICMP Type Numbers"
   registry as follows:

   OLD: [RFC2780]

   NEW: [RFC2780][RFCXXXX]

Current:
   IANA has added this note to the "ICMP Type Numbers" registry [IANA-ICMPv4]
   and listed this document as an additional reference for the registry:

      [...]
-->

<t>IANA has registered the following URIs in the "ns"
   subregistry
   registry within the "IETF XML Registry" <xref target="RFC3688"/>:</t>
        <artwork><![CDATA[
URI: urn:ietf:params:xml:ns:yang:ietf-acl-enh
Registrant Contact: The IESG.
XML: N/A;
<dl spacing="compact" newline="false">
  <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-acl-enh</dd>
  <dt>Registrant Contact:</dt><dd>The IESG</dd>
  <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.

URI: urn:ietf:params:xml:ns:yang:iana-icmpv4-types
Registrant Contact: The IESG.
XML: N/A; namespace.</dd>
</dl>
<dl spacing="compact" newline="false">
  <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:iana-icmpv4-types</dd>
  <dt>Registrant Contact:</dt><dd>The IESG</dd>
  <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.

URI: urn:ietf:params:xml:ns:yang:iana-icmpv6-types
Registrant Contact: The IESG.
XML: N/A; namespace.</dd>
</dl>
<dl spacing="compact" newline="false">
  <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:iana-icmpv6-types</dd>
  <dt>Registrant Contact:</dt><dd>The IESG</dd>
  <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.

URI: urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types
Registrant Contact: The IESG.
XML: N/A; namespace.</dd>
</dl>
<dl spacing="compact" newline="false">
  <dt>URI:</dt><dd>urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types</dd>
  <dt>Registrant Contact:</dt><dd>The IESG</dd>
  <dt>XML:</dt><dd>N/A; the requested URI is an XML namespace.
]]></artwork> namespace.</dd>
</dl>
      </section>
      <section anchor="yang-module-name-registrations">
        <name>YANG Module Name Registrations</name>
        <t>This document requests IANA to register
        <t>IANA has registered the following YANG modules in
   the "YANG Module Names" subregistry registry <xref target="RFC6020"/> within the "YANG
   Parameters" registry.</t>
        <artwork><![CDATA[
name: ietf-acl-enh
namespace: urn:ietf:params:xml:ns:yang:ietf-acl-enh
maintained by IANA: N
prefix: acl-enh
reference: RFC XXXX

name: iana-icmpv4-types
namespace: urn:ietf:params:xml:ns:yang:iana-icmpv4-types
maintained by IANA: Y
prefix: iana-icmpv4-types
reference: RFC XXXX

name: iana-icmpv6-types
namespace: urn:ietf:params:xml:ns:yang:iana-icmpv6-types
maintained by IANA: Y
prefix: iana-icmpv6-types
reference: RFC XXXX

name: iana-ipv6-ext-types
namespace: urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types
maintained by IANA: Y
prefix: iana-ipv6-ext-types
reference: RFC XXXX
]]></artwork> registry group.</t>

<dl spacing="compact" newline="false">
  <dt>Name:</dt><dd>ietf-acl-enh</dd>
  <dt>Maintained by IANA:</dt><dd>N</dd>
  <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:ietf-acl-enh</dd>
  <dt>Prefix:</dt><dd>acl-enh</dd>
  <dt>Reference:</dt><dd>RFC 9899</dd>
</dl>
<dl spacing="compact" newline="false">
  <dt>Name:</dt><dd>iana-icmpv4-types</dd>
  <dt>Maintained by IANA:</dt><dd>Y</dd>
  <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:iana-icmpv4-types</dd>
  <dt>Prefix:</dt><dd>iana-icmpv4-types</dd>
  <dt>Reference:</dt><dd>RFC 9899</dd>
</dl>
<dl spacing="compact" newline="false">
  <dt>Name:</dt><dd>iana-icmpv6-types</dd>
  <dt>Maintained by IANA:</dt><dd>Y</dd>
  <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:iana-icmpv6-types</dd>
  <dt>Prefix:</dt><dd>iana-icmpv6-types</dd>
  <dt>Reference:</dt><dd>RFC 9899</dd>
</dl>
<dl spacing="compact" newline="false">
  <dt>Name:</dt><dd>iana-ipv6-ext-types</dd>
  <dt>Maintained by IANA:</dt><dd>Y</dd>
  <dt>Namespace:</dt><dd>urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types</dd>
  <dt>Prefix:</dt><dd>iana-ipv6-ext-types</dd>
  <dt>Reference:</dt><dd>RFC 9899</dd>
</dl>
      </section>
      <section anchor="considerations-for-iana-maintained-modules">
        <name>Considerations for IANA-Maintained Modules</name>
        <section anchor="icmpv4-types-iana-module">
          <name>ICMPv4 Types IANA Module</name>
          <t>This document defines the initial version of the IANA-maintained
"iana-icmpv4-types" YANG module.  The most recent version of the YANG module
is available from in the "YANG Parameters" registry group
<xref target="IANA-YANG-PARAMETERS"/>.</t>
          <t>IANA is requested to add has added this note to the registry <xref target="IANA-YANG-PARAMETERS"/>:</t>
          <ul empty="true">
            <li>
              <t>New registry:</t>

          <blockquote>New values must not be directly added to the
          "iana-icmpv4-types" YANG module.  They must instead be added to the
          "ICMP Type Numbers" registry <xref target="IANA-ICMPv4"/>.</t>
            </li>
          </ul>
          target="IANA-ICMPv4"/>.</blockquote>

          <t>When a value is added to the "ICMP Type Numbers" registry, a new
          "enum" statement must be added to the "iana-icmpv4-types" YANG
          module.  The "enum" statement, and sub-statements substatements thereof, should be defined:</t>
          defined as follows:</t>
          <dl>
            <dt>"enum":</dt>
            <dd>
              <t>Replicates the name from the registry with all illegal characters (e.g., spaces) are striped.</t>
            </dd>
            <dt>"value":</dt>
            <dd>
              <t>Contains the decimal value of the IANA-assigned value.</t>
            </dd>
            <dt>"status":</dt>
            <dd>
              <t>Is included
              <t>Included only if a registration has been deprecated
or obsoleted.  IANA "deprecated" maps to YANG status
"deprecated", and IANA "obsolete" maps to YANG status
"obsolete".</t>
            </dd>
            <dt>"description":</dt>
            <dd>
              <t>Replicates the name from the registry.</t>
            </dd>
            <dt>"reference":</dt>
            <dd>
              <t>Replicates the reference(s) from the registry with the
title of the document(s) added.</t>
            </dd>
          </dl>
          <t>Unassigned, reserved, or <xref target="RFC3692"/>-style values styled like those in <xref target="RFC3692"/> are not present in the module.</t>
          <t>When the "iana-icmpv4-types" YANG module is updated, a new "revision"
statement with a unique revision date must be added in front of the
existing revision statements.</t>
          <t>IANA is requested to add has added this note to "ICMP Type Numbers" registry <xref target="IANA-ICMPv4"/>:</t>
          <artwork><![CDATA[
When target="IANA-ICMPv4"/> and listed this document as an additional reference for the registry:</t>

	  <blockquote>When this registry is modified, the YANG module
	  "iana-icmpv4-types"
[IANA_ICMPv4_YANG_URL] <xref target="IANA-YANG-PARAMETERS"/> must be updated as
	  defined in RFC XXXX.
]]></artwork>
          <t>IANA is requested to update the "Reference" in the "ICMP Type Numbers" registry
as follows:</t>
          <dl>
            <dt>OLD:</dt>
            <dd>
              <t><xref target="RFC2780"/></t>
            </dd>
            <dt>NEW:</dt>
            <dd>
              <t><xref target="RFC2780"/>[RFCXXXX]</t>
            </dd>
          </dl> 9899.</blockquote>
        </section>
        <section anchor="icmpv6-types-iana-module">
          <name>ICMPv6 Types IANA Module</name>
          <t>This document defines the initial version of the IANA-maintained
          "iana-icmpv6-types" YANG module. The most recent version of the YANG
          module is available from in the "YANG Parameters" registry group <xref
          target="IANA-YANG-PARAMETERS"/>.</t>

          <t>IANA is requested to add has added this note to the registry <xref target="IANA-YANG-PARAMETERS"/>:</t>
          <ul empty="true">
            <li>
              <t>New registry:</t>

	  <blockquote>New values must not be directly added to the
	  "iana-icmpv6-types" YANG module. They must instead be added to the
	  "ICMPv6 "type" Numbers" registry <xref target="IANA-ICMPv6"/>.</t>
            </li>
          </ul>
	  target="IANA-ICMPv6"/>.</blockquote>

          <t>When a value is added to the "ICMPv6 "type" Numbers" registry, a
          new "enum" statement must be added to the "iana-icmpv6-types" YANG
          module.  The "enum" statement, and sub-statements substatements thereof, should be defined:</t>
          defined as follows:</t>
          <dl>
            <dt>"enum":</dt>
            <dd>
              <t>Replicates the name from the registry with all illegal characters (e.g., spaces) striped.</t>
            </dd>
            <dt>"value":</dt>
            <dd>
              <t>Contains the decimal value of the IANA-assigned value.</t>
            </dd>
            <dt>"status":</dt>
            <dd>
              <t>Is included
              <t>Included only if a registration has been deprecated
or obsoleted.  IANA "deprecated" maps to YANG status
"deprecated", and IANA "obsolete" maps to YANG status
"obsolete".</t>
            </dd>
            <dt>"description":</dt>
            <dd>
              <t>Replicates the name from the registry.</t>
            </dd>
            <dt>"reference":</dt>
            <dd>
              <t>Replicates the reference(s) from the registry with the
title of the document(s) added.</t>
            </dd>
          </dl>
          <t>Unassigned, reserved, or private experimentation values are not present in the module.</t>
          <t>When the "iana-icmpv6-types" YANG module is updated, a new
          "revision" statement with a unique revision date must be added in
          front of the existing revision statements.</t>

          <t>IANA is requested to add has added this note to the "ICMPv6 "type" Numbers" registry <xref target="IANA-ICMPv6"/>:</t>
          <artwork><![CDATA[
When target="IANA-ICMPv6"/> and listed this document as an additional reference for the registry:</t>

	  <blockquote>When this registry is modified, the YANG module
	  "iana-icmpv6-types"
[IANA_ICMPv6_YANG_URL] <xref target="IANA-YANG-PARAMETERS"/> must be updated as
	  defined in RFC XXXX.
]]></artwork>
          <t>IANA is requested to update the "Reference" in the "ICMPv6 "type" Numbers" registry
as follows:</t>
          <dl>
            <dt>OLD:</dt>
            <dd>
              <t><xref target="RFC4443"/></t>
            </dd>
            <dt>NEW:</dt>
            <dd>
              <t><xref target="RFC4443"/>[RFCXXXX]</t>
            </dd>
          </dl> 9899.</blockquote>
        </section>
        <section anchor="ipv6-extension-header-types-iana-module">
          <name>IPv6 Extension Header Types IANA Module</name>
          <t>This document defines the initial version of the IANA-maintained
          "iana-ipv6-ext-types" YANG module.  The most recent version of the
          YANG module is available from in the "YANG Parameters" registry group <xref
          target="IANA-YANG-PARAMETERS"/>.</t>

          <t>IANA is requested to add has added this note to the registry <xref target="IANA-YANG-PARAMETERS"/>:</t>
          <ul empty="true">
            <li>
              <t>New registry:</t>

	  <blockquote>New values must not be directly added to the
	  "iana-ipv6-ext-types" YANG module.  They must instead be added to
	  the "IPv6 Extension Header Types" registry <xref target="IANA-IPv6"/>.</t>
            </li>
          </ul>
	  target="IANA-IPv6"/>.</blockquote>

          <t>When a value is added to the "IPv6 Extension Header Types"
          registry, a new "enum" statement must be added to the
          "iana-ipv6-ext-types" YANG module.  The "enum" statement, and sub-statements
          substatements thereof, should be defined:</t> defined as follows</t>

          <dl>
            <dt>"enum":</dt>
            <dd>
              <t>Replicates the description from the registry with all spaces striped.</t>
            </dd>
            <dt>"value":</dt>
            <dd>
              <t>Contains the decimal value of the IANA-assigned value.</t>
            </dd>
            <dt>"status":</dt>
            <dd>
              <t>Is included
              <t>Included only if a registration has been deprecated or
              obsoleted.  IANA "deprecated" maps to YANG status "deprecated",
              and IANA "obsolete" maps to YANG status "obsolete".</t>
            </dd>
            <dt>"description":</dt>
            <dd>
              <t>Replicates the description from the registry.</t>
            </dd>
            <dt>"reference":</dt>
            <dd>
              <t>Replicates the reference(s) from the registry with the
title of the document(s) added.</t>
            </dd>
          </dl>
          <t>Unassigned or reserved values are not present in the module.</t>
          <t>When the "iana-ipv6-ext-types" YANG module is updated, a new "revision"
statement with a unique revision date must be added in front of the
existing revision statements.</t>

          <t>IANA is requested to add has added this note to the "IPv6 Extension Header Types" registry <xref target="IANA-IPv6"/>:</t>
          <artwork><![CDATA[
When target="IANA-IPv6"/> and listed this document as an additional reference for the registry:</t>

	  <blockquote>When this registry is modified, the YANG module
	  "iana-ipv6-ext-types"
[IANA_IPV6_YANG_URL] <xref target="IANA-YANG-PARAMETERS"/> must be updated as
	  defined in RFC XXXX.
]]></artwork>
          <t>IANA is requested to update the "Reference" in the "IPv6 Extension Header Types" registry
as follows:</t>
          <dl>
            <dt>OLD:</dt>
            <dd>
              <t><xref target="RFC2780"/><xref target="RFC5237"/><xref target="RFC7045"/></t>
            </dd>
            <dt>NEW:</dt>
            <dd>
              <t><xref target="RFC2780"/><xref target="RFC5237"/><xref target="RFC7045"/>[RFCXXXX]</t>
            </dd>
          </dl> 9899.</blockquote>
        </section>
      </section>
    </section>
  </middle>
  <back>

<displayreference target="I-D.ietf-netmod-rfc8407bis" to="YANG-GUIDELINES"/>

    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="IANA-ICMPv4" target="https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml"> target="https://www.iana.org/assignments/icmp-parameters">
          <front>
            <title>ICMP Type Numbers</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="IANA-ICMPv6" target="https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml"> target="https://www.iana.org/assignments/icmpv6-parameters">
          <front>
            <title>ICMPv6 type "type" Numbers</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="IANA-IPv6" target="https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml"> target="https://www.iana.org/assignments/ipv6-parameters">
          <front>
            <title>IPv6 Extension Header Types</title>
             <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="RFC8519">
          <front>
            <title>YANG Data Model for Network Access Control Lists (ACLs)</title>
            <author fullname="M. Jethanandani" initials="M." surname="Jethanandani"/>
            <author fullname="S. Agarwal" initials="S." surname="Agarwal"/>
            <author fullname="L. Huang" initials="L." surname="Huang"/>
            <author fullname="D. Blair" initials="D." surname="Blair"/>
            <date month="March" year="2019"/>
            <abstract>
              <t>This document defines a data model for Access Control Lists (ACLs). An ACL is a user-ordered set of rules used to configure the forwarding behavior in a device. Each rule is used to find a match on a packet and define actions that will be performed on the packet.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8519"/>
          <seriesInfo name="DOI" value="10.17487/RFC8519"/>
        </reference>
        <reference anchor="RFC8342">
          <front>
            <title>Network Management Datastore Architecture (NMDA)</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." surname="Schoenwaelder"/>
            <author fullname="P. Shafer" initials="P." surname="Shafer"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <author fullname="R. Wilton" initials="R." surname="Wilton"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8342"/>
          <seriesInfo name="DOI" value="10.17487/RFC8342"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC7950">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="August" year="2016"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
        <reference anchor="RFC0792">
          <front>
            <title>Internet Control Message Protocol</title>
            <author fullname="J. Postel" initials="J." surname="Postel"/>
            <date month="September" year="1981"/>
          </front>
          <seriesInfo name="STD" value="5"/>
          <seriesInfo name="RFC" value="792"/>
          <seriesInfo name="DOI" value="10.17487/RFC0792"/>
        </reference>
        <reference anchor="RFC4443">
          <front>
            <title>Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification</title>
            <author fullname="A. Conta" initials="A." surname="Conta"/>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="M. Gupta" initials="M." role="editor" surname="Gupta"/>
            <date month="March" year="2006"/>
            <abstract>
              <t>This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="89"/>
          <seriesInfo name="RFC" value="4443"/>
          <seriesInfo name="DOI" value="10.17487/RFC4443"/>
        </reference>
        <reference anchor="RFC8200">
          <front>
            <title>Internet Protocol, Version 6 (IPv6) Specification</title>
            <author fullname="S. Deering" initials="S." surname="Deering"/>
            <author fullname="R. Hinden" initials="R." surname="Hinden"/>
            <date month="July" year="2017"/>
            <abstract>
              <t>This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="86"/>
          <seriesInfo name="RFC" value="8200"/>
          <seriesInfo name="DOI" value="10.17487/RFC8200"/>
        </reference>
        <reference anchor="RFC9293">
          <front>
            <title>Transmission Control Protocol (TCP)</title>
            <author fullname="W. Eddy" initials="W." role="editor" surname="Eddy"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="7"/>
          <seriesInfo name="RFC" value="9293"/>
          <seriesInfo name="DOI" value="10.17487/RFC9293"/>
        </reference>
        <reference anchor="RFC3032">
          <front>
            <title>MPLS Label Stack Encoding</title>
            <author fullname="E. Rosen" initials="E." surname="Rosen"/>
            <author fullname="D. Tappan" initials="D." surname="Tappan"/>
            <author fullname="G. Fedorkow" initials="G." surname="Fedorkow"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <author fullname="D. Farinacci" initials="D." surname="Farinacci"/>
            <author fullname="T. Li" initials="T." surname="Li"/>
            <author fullname="A. Conta" initials="A." surname="Conta"/>
            <date month="January" year="2001"/>
            <abstract>
              <t>This document specifies the encoding to be used by an LSR in order to transmit labeled packets on Point-to-Point Protocol (PPP) data links, on LAN data links, and possibly on other data links as well. This document also specifies rules and procedures for processing the various fields of the label stack encoding. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3032"/>
          <seriesInfo name="DOI" value="10.17487/RFC3032"/>
        </reference>
        <reference anchor="RFC5462">
          <front>
            <title>Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic Class" Field</title>
            <author fullname="L. Andersson" initials="L." surname="Andersson"/>
            <author fullname="R. Asati" initials="R." surname="Asati"/>
            <date month="February" year="2009"/>
            <abstract>
              <t>The early Multiprotocol Label Switching (MPLS) documents defined the form of the MPLS label stack entry. This includes a three-bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use".</t>
              <t>Although the intended use of the EXP field was as a "Class of Service" (CoS) field, it was not named a CoS field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field.</t>
              <t>To avoid misunderstanding about how this field may be used, it has become increasingly necessary to rename this field. This document changes the name of the field to the "Traffic Class field" ("TC field"). In doing so, it also updates documents that define the current use of the EXP field. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5462"/>
          <seriesInfo name="DOI" value="10.17487/RFC5462"/>
        </reference>
        <reference anchor="RFC6991">
          <front>
            <title>Common YANG Data Types</title>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <date month="July" year="2013"/>
            <abstract>
              <t>This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6991"/>
          <seriesInfo name="DOI" value="10.17487/RFC6991"/>
        </reference>
        <reference anchor="RFC8294">
          <front>
            <title>Common YANG Data Types for the Routing Area</title>
            <author fullname="X. Liu" initials="X." surname="Liu"/>
            <author fullname="Y. Qu" initials="Y." surname="Qu"/>
            <author fullname="A. Lindem" initials="A." surname="Lindem"/>
            <author fullname="C. Hopps" initials="C." surname="Hopps"/>
            <author fullname="L. Berger" initials="L." surname="Berger"/>
            <date month="December" year="2017"/>
            <abstract>
              <t>This document defines a collection of common data types using the YANG data modeling language. These derived common types are designed to be imported by other modules defined in the routing area.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8294"/>
          <seriesInfo name="DOI" value="10.17487/RFC8294"/>
        </reference>
        <reference anchor="RFC8341">
          <front>
            <title>Network Configuration Access Control Model</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t>
              <t>This document obsoletes RFC 6536.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="91"/>
          <seriesInfo name="RFC" value="8341"/>
          <seriesInfo name="DOI" value="10.17487/RFC8341"/>
        </reference>
        <reference anchor="RFC3688">
          <front>
            <title>The IETF XML Registry</title>
            <author fullname="M. Mealling" initials="M." surname="Mealling"/>
            <date month="January" year="2004"/>
            <abstract>
              <t>This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="81"/>
          <seriesInfo name="RFC" value="3688"/>
          <seriesInfo name="DOI" value="10.17487/RFC3688"/>
        </reference>
        <reference anchor="RFC6020">
          <front>
            <title>YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="October" year="2010"/>
            <abstract>
              <t>YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6020"/>
          <seriesInfo name="DOI" value="10.17487/RFC6020"/>
        </reference>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8519.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0792.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4443.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5462.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8294.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="IANA-YANG-PARAMETERS" target="https://www.iana.org/assignments/yang-parameters">
          <front>
            <title>YANG Parameters</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="IANA-TCP-FLAGS" target="https://www.iana.org/assignments/tcp-parameters/"> target="https://www.iana.org/assignments/tcp-parameters">
          <front>
            <title>Transmission Control Protocol (TCP) Parameters</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
 <!--       <reference anchor="IANA_ICMPv4_YANG_URL" target="https://www.iana.org/assignments/icmpv6-parameters/iana-icmpv6-types.xhtml"> anchor="IANA_ICMPv6_YANG_URL" target="https://www.iana.org/assignments/yang-parameters/">
          <front>
            <title>iana-icmpv6-types YANG Module</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
   <reference anchor="IANA_ICMPv6_YANG_URL" target="https://www.iana.org/assignments/icmp-parameters/iana-ipv6-ext-types.xhtml"> anchor="IANA_ICMPv4_YANG_URL" target="https://www.iana.org/assignments/yang-parameters/">
          <front>
            <title>iana-icmpv4-types YANG Module</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="IANA_IPV6_YANG_URL" target="https://www.iana.org/assignments/ipv6-parameters/iana-icmpv6-types.xhtml"> target="https://www.iana.org/assignments/yang-parameters">
          <front>
            <title>iana-ipv6-ext-types YANG Module</title>
            <author>
              <organization/>
              <organization>IANA</organization>
            </author>
            <date>n.d.</date>
          </front>
          </reference>
-->

        <reference anchor="IEEE-802-1ah" target="https://standards.ieee.org/standard/802_1ah-2008.html"> >
          <front>
            <title>IEEE Standard for Local and metropolitan area networks -- Virtual Bridged Local Area Networks Amendment 7: Provider Backbone Bridges</title>
            <author initials="" surname="IEEE" fullname="IEEE">
              <organization/>
            </author>
            <date year="2008" month="August"/>
          </front>
          <seriesInfo name="IEEE Std" value="802.1ah-2008"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2008.4602826"/>
        </reference>

        <reference anchor="IEEE802.1Qcp" target="https://doi.org/10.1109/IEEESTD.2018.8467507"> anchor="IEEE802.1Qcp">
          <front>
            <title>IEEE Standard for Local and metropolitan area networks--Bridges and Bridged Networks--Amendment 30: YANG Data Model</title>
            <author initials="" surname="IEEE" fullname="IEEE">
              <organization/>
            <author>
              <organization>IEEE</organization>
            </author>
            <date year="2018" month="September"/>
          </front>
          <seriesInfo name="IEEE Std" value="802.1Qcp-2018"/>
          <seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8467507"/>
        </reference>
        <reference anchor="YANG-XSLT" target="https://github.com/llhotka/iana-yang">
          <front>
            <title>iana-yang</title>
            <author>
              <organization/>
            </author>
            <date>n.d.</date>
          </front>
        </reference>
        <reference anchor="RFC9132">
          <front>
            <title>Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification</title>
            <author fullname="M. Boucadair" initials="M." role="editor" surname="Boucadair"/>
            <author fullname="J. Shallow" initials="J." surname="Shallow"/>
            <author fullname="T. Reddy.K" initials="T." surname="Reddy.K"/>
            <date month="September" year="2021"/>
            <abstract>
              <t>This document specifies the Distributed Denial-of-Service Open Threat Signaling (DOTS) signal channel, a protocol for signaling the need for protection against Distributed Denial-of-Service (DDoS) attacks to a server capable of enabling network traffic mitigation on behalf of the requesting client.</t>
              <t>A companion document defines the DOTS data channel, a separate reliable communication layer for DOTS management and configuration purposes.</t>
              <t>This document obsoletes RFC 8782.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9132"/>
          <seriesInfo name="DOI" value="10.17487/RFC9132"/>
        </reference>
        <reference anchor="RFC8955">
          <front>
            <title>Dissemination of Flow Specification Rules</title>
            <author fullname="C. Loibl" initials="C." surname="Loibl"/>
            <author fullname="S. Hares" initials="S." surname="Hares"/>
            <author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
            <author fullname="D. McPherson" initials="D." surname="McPherson"/>
            <author fullname="M. Bacher" initials="M." surname="Bacher"/>
            <date month="December" year="2020"/>
            <abstract>
              <t>This document defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast and IPv4 BGP/MPLS VPN services. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.</t>
              <t>It also specifies BGP Extended Community encoding formats, which can be used to propagate Traffic Filtering Actions along with the Flow Specification NLRI. Those Traffic Filtering Actions encode actions a routing system can take if the packet matches the Flow Specification.</t>
              <t>This document obsoletes both RFC 5575 and RFC 7674.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8955"/>
          <seriesInfo name="DOI" value="10.17487/RFC8955"/>
        </reference>
        <reference anchor="RFC8956">
          <front>
            <title>Dissemination of Flow Specification Rules for IPv6</title>
            <author fullname="C. Loibl" initials="C." role="editor" surname="Loibl"/>
            <author fullname="R. Raszuk" initials="R." role="editor" surname="Raszuk"/>
            <author fullname="S. Hares" initials="S." role="editor" surname="Hares"/>
            <date month="December" year="2020"/>
            <abstract>
              <t>"Dissemination of Flow Specification Rules" (RFC 8955) provides a Border Gateway Protocol (BGP) extension for the propagation of traffic flow information for the purpose of rate limiting or filtering IPv4 protocol data packets.</t>
              <t>This document extends RFC 8955 with IPv6 functionality. It also updates RFC 8955 by changing the IANA Flow Spec Component Types registry.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8956"/>
          <seriesInfo name="DOI" value="10.17487/RFC8956"/>
        </reference>
        <reference anchor="I-D.ietf-netmod-rfc8407bis">
          <front>
            <title>Guidelines for Authors and Reviewers of Documents Containing YANG Data Models</title>
            <author fullname="Andy Bierman" initials="A." surname="Bierman">
              <organization>YumaWorks</organization>
            </author>
            <author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
              <organization>Orange</organization>
            </author>
            <author fullname="Qin Wu" initials="Q." surname="Wu">
              <organization>Huawei</organization>
            </author>
            <date day="14" month="January" year="2025"/>
            <abstract>
              <t>   This memo provides guidelines for authors and reviewers of
   specifications containing YANG modules, including IANA-maintained
   modules.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG modules.  This document obsoletes
   RFC 8407.

   Also, this document updates RFC 8126 by providing additional
   guidelines for writing the IANA considerations for RFCs that specify
   IANA-maintained modules.  The document also updates RFC 6020 by
   clarifying how modules and their revisions are handled by IANA.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-netmod-rfc8407bis-22"/>
        </reference>
        <reference anchor="RFC8340">
          <front>
            <title>YANG Tree Diagrams</title>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="L. Berger" initials="L." role="editor" surname="Berger"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="215"/>
          <seriesInfo name="RFC" value="8340"/>
          <seriesInfo name="DOI" value="10.17487/RFC8340"/>
        </reference>
        <reference anchor="RFC9000">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="RFC7209">
          <front>
            <title>Requirements for Ethernet VPN (EVPN)</title>
            <author fullname="A. Sajassi" initials="A." surname="Sajassi"/>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="A. Isaac" initials="A." surname="Isaac"/>
            <date month="May" year="2014"/>
            <abstract>
              <t>The widespread adoption of Ethernet L2VPN services and the advent of new applications for the technology (e.g., data center interconnect) have culminated in a new set of requirements that are not readily addressable by the current Virtual Private LAN Service (VPLS) solution. In particular, multihoming with all-active forwarding is not supported, and there's no existing solution to leverage Multipoint-to-Multipoint (MP2MP) Label Switched Paths (LSPs) for optimizing the delivery of multi-destination frames. Furthermore, the provisioning of VPLS, even in the context of BGP-based auto-discovery, requires network operators to specify various network parameters on top of the access configuration. This document specifies the requirements for an Ethernet VPN (EVPN) solution, which addresses the above issues.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7209"/>
          <seriesInfo name="DOI" value="10.17487/RFC7209"/>
        </reference>
        <reference anchor="RFC6241">
          <front>
            <title>Network Configuration Protocol (NETCONF)</title>
            <author fullname="R. Enns" initials="R." role="editor" surname="Enns"/>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <author fullname="J. Schoenwaelder" initials="J." role="editor" surname="Schoenwaelder"/>
            <author fullname="A. Bierman" initials="A." role="editor" surname="Bierman"/>
            <date month="June" year="2011"/>
            <abstract>
              <t>The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6241"/>
          <seriesInfo name="DOI" value="10.17487/RFC6241"/>
        </reference>
        <reference anchor="RFC8040">
          <front>
            <title>RESTCONF Protocol</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <author fullname="K. Watsen" initials="K." surname="Watsen"/>
            <date month="January" year="2017"/>
            <abstract>
              <t>This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8040"/>
          <seriesInfo name="DOI" value="10.17487/RFC8040"/>
        </reference>
        <reference anchor="RFC4252">
          <front>
            <title>The Secure Shell (SSH) Authentication Protocol</title>
            <author fullname="T. Ylonen" initials="T." surname="Ylonen"/>
            <author fullname="C. Lonvick" initials="C." role="editor" surname="Lonvick"/>
            <date month="January" year="2006"/>
            <abstract>
              <t>The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4252"/>
          <seriesInfo name="DOI" value="10.17487/RFC4252"/>
        </reference>
        <reference anchor="RFC8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <author fullname="E. Rescorla" initials="E." surname="Rescorla"/>
            <date month="August" year="2018"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8446"/>
          <seriesInfo name="DOI" value="10.17487/RFC8446"/>
        </reference>
        <reference anchor="RFC8329">
          <front>
            <title>Framework for Interface to Network Security Functions</title>
            <author fullname="D. Lopez" initials="D." surname="Lopez"/>
            <author fullname="E. Lopez" initials="E." surname="Lopez"/>
            <author fullname="L. Dunbar" initials="L." surname="Dunbar"/>
            <author fullname="J. Strassner" initials="J." surname="Strassner"/>
            <author fullname="R. Kumar" initials="R." surname="Kumar"/>
            <date month="February" year="2018"/>
            <abstract>
              <t>This document describes the framework for Interface to Network Security Functions (I2NSF) and defines a reference model (including major functional components) for I2NSF. Network Security Functions (NSFs) are packet-processing engines that inspect and optionally modify packets traversing networks, either directly or in the context of sessions to which the packet is associated.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8329"/>
          <seriesInfo name="DOI" value="10.17487/RFC8329"/>
        </reference>
        <reference anchor="RFC3692">
          <front>
            <title>Assigning Experimental and Testing Numbers Considered Useful</title>
            <author fullname="T. Narten" initials="T." surname="Narten"/>
            <date month="January" year="2004"/>
            <abstract>
              <t>When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="82"/>
          <seriesInfo name="RFC" value="3692"/>
          <seriesInfo name="DOI" value="10.17487/RFC3692"/>
          <refcontent>commit 3a6cb69</refcontent>
        </reference>
        <reference anchor="RFC2780">
          <front>
            <title>IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <author fullname="V. Paxson" initials="V." surname="Paxson"/>
            <date month="March" year="2000"/>
            <abstract>
              <t>This memo provides guidance for the IANA to use in assigning parameters for fields in the IPv4, IPv6, ICMP, UDP and TCP protocol headers. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="37"/>
          <seriesInfo name="RFC" value="2780"/>
          <seriesInfo name="DOI" value="10.17487/RFC2780"/>
        </reference>
        <reference anchor="RFC5237">
          <front>
            <title>IANA Allocation Guidelines for the Protocol Field</title>
            <author fullname="J. Arkko" initials="J." surname="Arkko"/>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="February" year="2008"/>
            <abstract>
              <t>This document revises the IANA guidelines for allocating new Protocol field values in IPv4 header. It modifies the rules specified in
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9132.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8956.xml"/>

<!-- [I-D.ietf-netmod-rfc8407bis]
draft-ietf-netmod-rfc8407bis-28
IESG State: RFC 2780 by removing the Expert Review option. The change will also affect the allocation of Next Header field values in IPv6. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="37"/>
          <seriesInfo name="RFC" value="5237"/>
          <seriesInfo name="DOI" value="10.17487/RFC5237"/>
        </reference>
        <reference anchor="RFC7045">
          <front>
            <title>Transmission and Processing Ed Queue (EDIT) as of IPv6 Extension Headers</title>
            <author fullname="B. Carpenter" initials="B." surname="Carpenter"/>
            <author fullname="S. Jiang" initials="S." surname="Jiang"/>
            <date month="December" year="2013"/>
            <abstract>
              <t>Various IPv6 extension headers have been standardised since the IPv6 standard was first published. This document updates RFC 2460 to clarify how intermediate nodes should deal with such extension headers and with any that are defined in the future. It also specifies how extension headers should be registered by IANA, with a corresponding minor update to RFC 2780.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7045"/>
          <seriesInfo name="DOI" value="10.17487/RFC7045"/>
        </reference> 11/10/25
-->
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-netmod-rfc8407bis.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7209.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4252.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8329.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3692.xml"/>

<!--    <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2780.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5237.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7045.xml"/>
-->

      </references>
    </references>
    <?line 2006?>

<section anchor="iana-icmp">
      <name>Initial Version of the ICMPv4 Types IANA-Maintained Module</name>
      <sourcecode markers="true" name="iana-icmpv4-types@2020-09-25.yang"><![CDATA[

module iana-icmpv4-types {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:iana-icmpv4-types";
  prefix iana-icmpv4-types;

  organization
    "Internet Assigned Numbers Authority (IANA)";

  contact
    "Internet Assigned Numbers Authority

     ICANN
     12025 Waterfront Drive, Suite 300
     Los Angeles, CA 90094

     Tel: +1 424 254 5300

     <mailto:iana@iana.org>";

  description
    "This YANG module translates IANA registry 'ICMP Type Numbers' to
     YANG derived types.

     Copyright (c) 2020 IETF Trust and the persons identified as
     authors of the code. 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 Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     The initial version of this YANG module is part of RFC XXXX;
     see the RFC itself for full legal notices.

     This version of this YANG module was generated from the
     corresponding IANA registry using an XSLT stylesheet from the
     'iana-yang' project (https://github.com/llhotka/iana-yang).";

  reference
    "Internet Control Message Protocol (ICMP) Parameters
     (https://www.iana.org/assignments/icmp-parameters/)";

  revision 2020-09-25 {
    description
      "Current revision as of the revision date specified in the XML
       representation of the registry page.";
    reference
      "https://www.iana.org/assignments/icmp-parameters/
       icmp-parameters.xml";
  }

  /* Typedefs */

  typedef icmpv4-type-name {
    type enumeration {
      enum EchoReply {
        value 0;
        description
          "Echo Reply";
        reference
          "RFC 792";
      }
      enum DestinationUnreachable {
        value 3;
        description
          "Destination Unreachable";
        reference
          "RFC 792";
      }
      enum SourceQuench {
        value 4;
        status deprecated;
        description
          "Source Quench (Deprecated)";
        reference
          "- RFC 792
           - RFC 6633";
      }
      enum Redirect {
        value 5;
        description
          "Redirect";
        reference
          "RFC 792";
      }
      enum AlternateHostAddress {
        value 6;
        status deprecated;
        description
          "Alternate Host Address (Deprecated)";
        reference
          "RFC 6918";
      }
      enum Echo {
        value 8;
        description
          "Echo";
        reference
          "RFC 792";
      }
      enum RouterAdvertisement {
        value 9;
        description
          "Router Advertisement";
        reference
          "RFC 1256";
      }
      enum RouterSolicitation {
        value 10;
        description
          "Router Solicitation";
        reference
          "RFC 1256";
      }
      enum TimeExceeded {
        value 11;
        description
          "Time Exceeded";
        reference
          "RFC 792";
      }
      enum ParameterProblem {
        value 12;
        description
          "Parameter Problem";
        reference
          "RFC 792";
      }
      enum Timestamp {
        value 13;
        description
          "Timestamp";
        reference
          "RFC 792";
      }
      enum TimestampReply {
        value 14;
        description
          "Timestamp Reply";
        reference
          "RFC 792";
      }
      enum InformationRequest {
        value 15;
        status deprecated;
        description
          "Information Request (Deprecated)";
        reference
          "- RFC 792
           - RFC 6918";
      }
      enum InformationReply {
        value 16;
        status deprecated;
        description
          "Information Reply (Deprecated)";
        reference
          "- RFC 792
           - RFC 6918";
      }
      enum AddressMaskRequest {
        value 17;
        status deprecated;
        description
          "Address Mask Request (Deprecated)";
        reference
          "- RFC 950
           - RFC 6918";
      }
      enum AddressMaskReply {
        value 18;
        status deprecated;
        description
          "Address Mask Reply (Deprecated)";
        reference
          "- RFC 950
           - RFC 6918";
      }
      enum Traceroute {
        value 30;
        status deprecated;
        description
          "Traceroute (Deprecated)";
        reference
          "- RFC 1393
           - RFC 6918";
      }
      enum DatagramConversionError {
        value 31;
        status deprecated;
        description
          "Datagram Conversion Error (Deprecated)";
        reference
          "- RFC 1475
           - RFC 6918";
      }
      enum MobileHostRedirect {
        value 32;
        status deprecated;
        description
          "Mobile Host Redirect (Deprecated)";
        reference
          "- David Johnson <>
           - RFC 6918";
      }
      enum IPv6Where-Are-You {
        value 33;
        status deprecated;
        description
          "IPv6 Where-Are-You (Deprecated)";
        reference
          "- Bill Simpson <mailto:Bill.Simpson&um.cc.umich.edu>
           - RFC 6918";
      }
      enum IPv6I-Am-Here {
        value 34;
        status deprecated;
        description
          "IPv6 I-Am-Here (Deprecated)";
        reference
          "- Bill Simpson <mailto:Bill.Simpson&um.cc.umich.edu>
           - RFC 6918";
      }
      enum MobileRegistrationRequest {
        value 35;
        status deprecated;
        description
          "Mobile Registration Request (Deprecated)";
        reference
          "- Bill Simpson <mailto:Bill.Simpson&um.cc.umich.edu>
           - RFC 6918";
      }
      enum MobileRegistrationReply {
        value 36;
        status deprecated;
        description
          "Mobile Registration Reply (Deprecated)";
        reference
          "- Bill Simpson <mailto:Bill.Simpson&um.cc.umich.edu>
           - RFC 6918";
      }
      enum DomainNameRequest {
        value 37;
        status deprecated;
        description
          "Domain Name Request (Deprecated)";
        reference
          "- RFC 1788
           - RFC 6918";
      }
      enum DomainNameReply {
        value 38;
        status deprecated;
        description
          "Domain Name Reply (Deprecated)";
        reference
          "- RFC 1788
           - RFC 6918";
      }
      enum SKIP {
        value 39;
        status deprecated;
        description
          "SKIP (Deprecated)";
        reference
          "- Tom Markson <mailto:markson&osmosys.incog.com>
           - RFC 6918";
      }
      enum Photuris {
        value 40;
        description
          "Photuris";
        reference
          "RFC 2521";
      }
      enum ICMPmessagesutilizedbyexperimentalmobilityprotocols {
        value 41;
        description
          "ICMP messages utilized by experimental mobility protocols
           such as Seamoby";
        reference
          "RFC 4065";
      }
      enum ExtendedEchoRequest {
        value 42;
        description
          "Extended Echo Request";
        reference
          "RFC 8335";
      }
      enum ExtendedEchoReply {
        value 43;
        description
          "Extended Echo Reply";
        reference
          "RFC 8335";
      }
    }
    description
      "This enumeration type defines mnemonic names and corresponding
       numeric values of ICMPv4 types.";
    reference
      "RFC 2708: IANA Allocation Guidelines For Values In the
       Internet Protocol and Related Headers";
  }

  typedef icmpv4-type {
    type union {
      type uint8;
      type icmpv4-type-name;
    }
    description
      "This type allows reference to an ICMPv4 type using either the
       assigned mnemonic name or numeric value.";
  }
}

]]></sourcecode>
    </section>
    <section anchor="iana-icmpv6">
      <name>Initial Version of the ICMPv6 Types IANA-Maintained Module</name>
      <sourcecode markers="true" name="iana-icmpv6-types@2023-04-28.yang"><![CDATA[

module iana-icmpv6-types {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:iana-icmpv6-types";
  prefix iana-icmpv6-types;

  organization
    "Internet Assigned Numbers Authority (IANA)";

  contact
    "Internet Assigned Numbers Authority

     ICANN
     12025 Waterfront Drive, Suite 300
     Los Angeles, CA 90094

     Tel: +1 424 254 5300

     <mailto:iana@iana.org>";

  description
    "This YANG module translates IANA registry 'ICMPv6 \"type\"
     Numbers' to YANG derived types.

     Copyright (c) 2023 IETF Trust and the persons identified as
     authors of the code. 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 Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     The initial version of this YANG module is part of RFC XXXX;
     see the RFC itself for full legal notices.

     This version of this YANG module was generated from the
     corresponding IANA registry using an XSLT stylesheet from the
     'iana-yang' project (https://github.com/llhotka/iana-yang).";

  reference
    "Internet Control Message Protocol version 6 (ICMPv6) Parameters
     (https://www.iana.org/assignments/icmpv6-parameters/)";

  revision 2023-04-28 {
    description
      "Current revision as of the revision date specified in the XML
       representation of the registry page.";
    reference
      "https://www.iana.org/assignments/icmpv6-parameters
       /icmpv6-parameters.xml";
  }

  /* Typedefs */

  typedef icmpv6-type-name {
    type enumeration {
      enum DestinationUnreachable {
        value 1;
        description
          "Destination Unreachable.";
        reference
          "RFC 4443";
      }
      enum PacketTooBig {
        value 2;
        description
          "Packet Too Big.";
        reference
          "RFC 4443";
      }
      enum TimeExceeded {
        value 3;
        description
          "Time Exceeded.";
        reference
          "RFC 4443";
      }
      enum ParameterProblem {
        value 4;
        description
          "Parameter Problem.";
        reference
          "RFC 4443";
      }
      enum EchoRequest {
        value 128;
        description
          "Echo Request.";
        reference
          "RFC 4443";
      }
      enum EchoReply {
        value 129;
        description
          "Echo Reply.";
        reference
          "RFC 4443";
      }
      enum MulticastListenerQuery {
        value 130;
        description
          "Multicast Listener Query.";
        reference
          "RFC 2710";
      }
      enum MulticastListenerReport {
        value 131;
        description
          "Multicast Listener Report.";
        reference
          "RFC 2710";
      }
      enum MulticastListenerDone {
        value 132;
        description
          "Multicast Listener Done.";
        reference
          "RFC 2710";
      }
      enum RouterSolicitation {
        value 133;
        description
          "Router Solicitation.";
        reference
          "RFC 4861";
      }
      enum RouterAdvertisement {
        value 134;
        description
          "Router Advertisement.";
        reference
          "RFC 4861";
      }
      enum NeighborSolicitation {
        value 135;
        description
          "Neighbor Solicitation.";
        reference
          "RFC 4861";
      }
      enum NeighborAdvertisement {
        value 136;
        description
          "Neighbor Advertisement.";
        reference
          "RFC 4861";
      }
      enum RedirectMessage {
        value 137;
        description
          "Redirect Message.";
        reference
          "RFC 4861";
      }
      enum RouterRenumbering {
        value 138;
        description
          "Router Renumbering.";
        reference
          "RFC 2894";
      }
      enum ICMPNodeInformationQuery {
        value 139;
        description
          "ICMP Node Information Query.";
        reference
          "RFC 4620";
      }
      enum ICMPNodeInformationResponse {
        value 140;
        description
          "ICMP Node Information Response.";
        reference
          "RFC 4620";
      }
      enum InverseNeighborDiscoverySolicitationMessage {
        value 141;
        description
          "Inverse Neighbor Discovery Solicitation Message.";
        reference
          "RFC 3122";
      }
      enum InverseNeighborDiscoveryAdvertisementMessage {
        value 142;
        description
          "Inverse Neighbor Discovery Advertisement Message.";
        reference
          "RFC 3122";
      }
      enum Version2MulticastListenerReport {
        value 143;
        description
          "Version 2 Multicast Listener Report.";
        reference
          "RFC 3810";
      }
      enum HomeAgentAddressDiscoveryRequestMessage {
        value 144;
        description
          "Home Agent Address Discovery Request Message.";
        reference
          "RFC 6275";
      }
      enum HomeAgentAddressDiscoveryReplyMessage {
        value 145;
        description
          "Home Agent Address Discovery Reply Message.";
        reference
          "RFC 6275";
      }
      enum MobilePrefixSolicitation {
        value 146;
        description
          "Mobile Prefix Solicitation.";
        reference
          "RFC 6275";
      }
      enum MobilePrefixAdvertisement {
        value 147;
        description
          "Mobile Prefix Advertisement.";
        reference
          "RFC 6275";
      }
      enum CertificationPathSolicitationMessage {
        value 148;
        description
          "Certification Path Solicitation Message.";
        reference
          "RFC 3971";
      }
      enum CertificationPathAdvertisementMessage {
        value 149;
        description
          "Certification Path Advertisement Message.";
        reference
          "RFC 3971";
      }
      enum ICMPmessagesutilizedbyexperimentalmobilityprotocols {
        value 150;
        description
          "ICMP messages utilized by experimental mobility protocols
           such as Seamoby.";
        reference
          "RFC 4065";
      }
      enum MulticastRouterAdvertisement {
        value 151;
        description
          "Multicast Router Advertisement.";
        reference
          "RFC 4286";
      }
      enum MulticastRouterSolicitation {
        value 152;
        description
          "Multicast Router Solicitation.";
        reference
          "RFC 4286";
      }
      enum MulticastRouterTermination {
        value 153;
        description
          "Multicast Router Termination.";
        reference
          "RFC 4286";
      }
      enum FMIPv6Messages {
        value 154;
        description
          "FMIPv6 Messages.";
        reference
          "RFC 5568";
      }
      enum RPLControlMessage {
        value 155;
        description
          "RPL Control Message.";
        reference
          "RFC 6550";
      }
      enum ILNPv6LocatorUpdateMessage {
        value 156;
        description
          "ILNPv6 Locator Update Message.";
        reference
          "RFC 6743";
      }
      enum DuplicateAddressRequest {
        value 157;
        description
          "Duplicate Address Request.";
        reference
          "RFC 6775";
      }
      enum DuplicateAddressConfirmation {
        value 158;
        description
          "Duplicate Address Confirmation.";
        reference
          "RFC 6775";
      }
      enum MPLControlMessage {
        value 159;
        description
          "MPL Control Message.";
        reference
          "RFC 7731";
      }
      enum ExtendedEchoRequest {
        value 160;
        description
          "Extended Echo Request.";
        reference
          "RFC 8335";
      }
      enum ExtendedEchoReply {
        value 161;
        description
          "Extended Echo Reply.";
        reference
          "RFC 8335";
      }
    }
    description
      "This enumeration type defines mnemonic names and corresponding
       numeric values of ICMPv6 types.";
    reference
      "RFC 2708: IANA Allocation Guidelines For Values In the
       Internet Protocol and Related Headers";
  }

  typedef icmpv6-type {
    type union {
      type uint8;
      type icmpv6-type-name;
    }
    description
      "This type allows reference to an ICMPv6 type using either the
       assigned mnemonic name or numeric value.";
  }
}

]]></sourcecode>
    </section>
    <section anchor="iana-ipv6-ext">
      <name>Initial Version of the IPv6 Extension Header Types IANA-Maintained Module</name>
      <sourcecode markers="true" name="iana-ipv6-ext-types@2023-09-29.yang"><![CDATA[

module iana-ipv6-ext-types {
  yang-version 1.1;
  namespace "urn:ietf:params:xml:ns:yang:iana-ipv6-ext-types";
  prefix iana-ipv6-ext-types;

  organization
    "Internet Assigned Numbers Authority (IANA)";

  contact
    "Internet Assigned Numbers Authority

     ICANN
     12025 Waterfront Drive, Suite 300
     Los Angeles, CA 90094

     Tel: +1 424 254 5300

     <mailto:iana@iana.org>";

  description
    "This YANG module translates IANA registry 'IPv6 Extension Header
     Types' to YANG derived types.

     Copyright (c) 2023 IETF Trust and the persons identified as
     authors of the code. 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 Revised BSD License set
     forth in Section 4.c of the IETF Trust's Legal Provisions
     Relating to IETF Documents
     (https://trustee.ietf.org/license-info).

     This version of this YANG module was generated from the
     corresponding IANA registry using an XSLT stylesheet from the
     'iana-yang' project (https://github.com/llhotka/iana-yang).";

  reference
    "Internet Protocol Version 6 (IPv6) Parameters
     (https://www.iana.org/assignments/ipv6-parameters/)";

  revision 2023-09-29 {
    description
      "Current revision as of the revision date specified in the XML
       representation of the registry page.";
    reference
      "https://www.iana.org/assignments/ipv6-parameters
       /ipv6-parameters.xml";
  }

  /* Typedefs */

  typedef ipv6-extension-header-type-name {
    type enumeration {
      enum IPv6Hop-by-HopOption {
        value 0;
        description
          "IPv6 Hop-by-Hop Option";
        reference
          "RFC 8200";
      }
      enum RoutingHeaderforIPv6 {
        value 43;
        description
          "Routing Header for IPv6";
        reference
          "- RFC 8200
           - RFC 5095";
      }
      enum FragmentHeaderforIPv6 {
        value 44;
        description
          "Fragment Header for IPv6";
        reference
          "RFC 8200";
      }
      enum EncapsulatingSecurityPayload {
        value 50;
        description
          "Encapsulating Security Payload";
        reference
          "RFC 4303";
      }
      enum AuthenticationHeader {
        value 51;
        description
          "Authentication Header";
        reference
          "RFC 4302";
      }
      enum DestinationOptionsforIPv6 {
        value 60;
        description
          "Destination Options for IPv6";
        reference
          "RFC 8200";
      }
      enum MobilityHeader {
        value 135;
        description
          "Mobility Header";
        reference
          "RFC 6275";
      }
      enum HostIdentityProtocol {
        value 139;
        description
          "Host Identity Protocol";
        reference
          "RFC 7401";
      }
      enum Shim6Protocol {
        value 140;
        description
          "Shim6 Protocol";
        reference
          "RFC 5533";
      }
    }
    description
      "This enumeration type defines mnemonic names and
       corresponding numeric values of IPv6 Extension header
       types.";
    reference
      "RFC 2708: IANA Allocation Guidelines For Values In the
       Internet Protocol and Related Headers";
  }

  typedef ipv6-extension-header-type {
    type union {
      type uint8;
      type ipv6-extension-header-type-name;
    }
    description
      "This type allows reference to an IPv6 Extension header
       type using either the assigned mnemonic name or the
       numeric protocol number value.";
  }
}

]]></sourcecode>
    </section>
    <section anchor="ps">
      <name>Problem Statement and Gap Analysis</name>
      <section anchor="ps-sets">
        <name>Suboptimal Configuration: Lack of Support for Lists of Prefixes</name>
        <t>IP prefix-related data nodes, e.g., nodes (e.g., "destination-ipv4-network" or
   "destination-ipv6-network",
   "destination-ipv6-network") do not support handling a list of IP
   prefixes, which may then lead to having to support large numbers of ACL entries in a configuration file.</t>
        <t>The same issue is encountered when ACLs have to be in place to
        mitigate DDoS attacks that involve a set of sources (e.g., <xref
        target="RFC9132"/>). The situation is even worse when both a list of
        sources and destination prefixes are involved in the filtering.</t>
        <t><xref target="example"/> shows an example of the required ACL configuration for filtering traffic from two prefixes.</t>
        <figure anchor="example">

<!--[rfced] We updated <artwork> to <sourcecode type="json"> for
Figure 3 in Appendix A.1. Please confirm that this is correct.

In addition, please confirm that the "type" attribute of all the
sourcecode elements are correct.

The current list of preferred values for "type" is available at
https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current
list does not contain an applicable type, feel free to suggest additions
for consideration. Note that it is also acceptable to leave the "type"
attribute not set.
-->

          <name>Example Illustrating Sub-optimal Suboptimal Use of the ACL Model with a Prefix List (Message Body)</name>
          <artwork><![CDATA[
          <sourcecode type="json"><![CDATA[
{
  "ietf-access-control-list:acls": {
    "acl": [
      {
        "name": "first-prefix",
        "type": "ipv6-acl-type",
        "aces": {
          "ace": [
            {
              "name": "my-test-ace",
              "matches": {
                "ipv6": {
                  "destination-ipv6-network":
                    "2001:db8:6401:1::/64",
                  "source-ipv6-network":
                    "2001:db8:1234::/96",
                  "protocol": 17,
                  "flow-label": 10000
                },
                "udp": {
                  "source-port": {
                    "operator": "lte",
                    "port": 80
                  },
                  "destination-port": {
                    "operator": "neq",
                    "port": 1010
                  }
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }
      },
      {
        "name": "second-prefix",
        "type": "ipv6-acl-type",
        "aces": {
          "ace": [
            {
              "name": "my-test-ace",
              "matches": {
                "ipv6": {
                  "destination-ipv6-network":
                    "2001:db8:6401:c::/64",
                  "source-ipv6-network":
                    "2001:db8:1234::/96",
                  "protocol": 17,
                  "flow-label": 10000
                },
                "udp": {
                  "source-port": {
                    "operator": "lte",
                    "port": 80
                  },
                  "destination-port": {
                    "operator": "neq",
                    "port": 1010
                  }
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }
      }
    ]
  }
}
]]></artwork>
]]></sourcecode>
        </figure>
        <t>Such a configuration is suboptimal for both:</t>
        <ul spacing="normal">
          <li>
            <t>Network
            <t>network controllers that need to manipulate large files. All files, as all or a
subset for this configuration will need to be passed to the
underlying network devices.</t> devices, and</t>
          </li>
          <li>
            <t>Devices
            <t>devices that may receive such a configuration and thus will need to
maintain it locally.</t>
          </li>
        </ul>
      </section>
      <section anchor="manageability-impossibility-to-use-aliases-or-defined-sets">
        <name>Manageability: Impossibility to Use of Using Aliases or Defined Sets</name>
        <t>The same approach as the one discussed for IP prefixes can be generalized by introducing the concept of "aliases" or "defined sets".</t>
        <t>The defined sets are reusable definitions across several ACLs. Each category is modeled in YANG as a list of parameters related to the class it represents. The following sets can be considered:</t>
        <dl>
          <dt>Prefix sets:</dt>
          <dd>
            <t>Used to create lists of IPv4 or IPv6 prefixes.</t>
          </dd>
          <dt>Protocol sets:</dt>
          <dd>
            <t>Used to create a list of protocols.</t>
          </dd>
          <dt>Port number sets:</dt>
          <dd>
            <t>Used to create lists of TCP or UDP port values
   (or any other transport protocol that makes uses of port numbers).
   The identity of the protocols is identified by the protocol set, if
   present.  Otherwise, a set applies to any protocol.</t>
          </dd>
          <dt>ICMP sets:</dt>
          <dd>
            <t>Uses
            <t>Used to create lists of ICMP-based filters. This applies only when the protocol is set to ICMP or ICMPv6.</t>
          </dd>
        </dl>
        <t>Aliases may also be considered to manage resources that are identified by a combination of various parameters (e.g., prefix, protocol, port number, FQDN, or VLAN IDs).
Note that some aliases can be provided by decomposing them into separate sets.</t>
      </section>
      <section anchor="bind-acls-to-devices-not-only-interfaces">
        <name>Bind ACLs to Devices, Not Only Interfaces</name>
        <t>In the context of network management, an ACL may be enforced in many
   network locations.  As such, the ACL module should allow for binding an
   ACL to multiple devices, not only (abstract) interfaces.</t>
        <t>The
        <t>Thus, the ACL name must, thus, must be unique at the scale of the network, but the same name may be used in many devices when enforcing node-specific ACLs.</t>
      </section>
      <section anchor="ps-frag">
        <name>Partial or Lack of IPv4/IPv6 Fragment Handling</name>
        <t><xref target="RFC8519"/> does not support fragment handling for IPv6 but
offers a partial support for IPv4  through the use of 'flags'.  Nevertheless,
the use of 'flags' is problematic since it does not allow a bitmask
to be defined.  For example, setting other bits not covered by the
'flags' filtering clause in a packet will allow that packet to get
through (because it won't match the ACE).</t>
        <t>Defining a new IPv4/IPv6 matching field called 'fragment' is thus required to efficiently handle fragment-related filtering rules.</t>
      </section>

<!-- [rfced] May we update as follows to avoid repetition of "defining" and "defined"?

Original:

   Defining this field to be defined as a flag bitmask together with a set of
   operations is meant to efficiently handle TCP flags filtering rules.

Perhaps:

   Defining this field as a flag bitmask together with a set of
   operations is meant to efficiently handle TCP flags filtering rules.
-->

<section anchor="ps-flags">
        <name>Suboptimal TCP Flags Handling</name>
        <t><xref target="RFC8519"/> supports including flags in the TCP match fields, however fields; however,
   that structure does not support matching operations as those
   supported in BGP Flow Spec.  Defining this field to be defined as a
   flag bitmask together with a set of operations is meant to
   efficiently handle TCP flags filtering rules.</t>
      </section>
      <section anchor="ps-rate">
        <name>Rate-Limit Action</name>
        <t><xref target="RFC8519"/> specifies that forwarding actions can be 'accept' (i.e., accept matching
   traffic), 'drop' (i.e., drop matching traffic without sending any
   ICMP error message), or 'reject' (i.e., drop matching traffic and send an ICMP error message to the source). However, there are situations where the matching traffic can be accepted, but with a rate-limit policy. This capability is not supported by <xref target="RFC8519"/>.</t>
      </section>
      <section anchor="ps-pf">
        <name>Payload-based
        <name>Payload-Based Filtering</name>
        <t>Some transport protocols use existing protocols (e.g., TCP or UDP) as substrate. The match criteria for such protocols may rely upon the 'protocol' under 'l3', TCP/UDP match criteria, part of the TCP/UDP payload, or a combination thereof. <xref target="RFC8519"/> does not support matching based on the payload.</t>
        <t>Likewise, the ACL model defined in <xref target="RFC8519"/> does not support filtering of encapsulated traffic.</t>
      </section>
      <section anchor="reuse-the-acls-content-across-several-devices">
        <name>Reuse the ACLs Content of ACLs Across Several Devices</name>
        <t>Having a global network view of the ACLs is highly valuable for service providers. An ACL could be defined and applied
based on the network topology hierarchy. So, Therefore, an ACL can be
defined at the network level and, then, level, and then that same ACL can be used in (or referenced to)
in
several devices (including termination points) within the same network.</t>
        <t>This network/device ACLs differentiation of ACLs introduces several new
requirements, e.g.:</t> for example:</t>
        <ul spacing="normal">
          <li>
            <t>An ACL name can be used at both network and device levels.</t>
          </li>
          <li>
            <t>An ACL content updated at the network level should imply
a transaction that updates the relevant content in all the nodes using this
ACL.</t>
          </li>
          <li>
            <t>ACLs defined at the device level have a local meaning for the specific node.</t>
          </li>
          <li>
            <t>A device can be associated with a router, a VRF, a
logical system, or a virtual node. ACLs can be applied in physical and
logical infrastructure.</t>
          </li>
        </ul>
      </section>
      <section anchor="match-mpls-headers">
        <name>Match MPLS Headers</name>
        <t>The ACLs can be used to create rules to match MPLS fields on a packet. <xref target="RFC8519"/> does not support such function.</t>
      </section>
    </section>
    <section anchor="sec-examples">
      <name>Examples</name>
      <t>This section provides a few examples to illustrate the use of the enhanced ACL module ("ietf-acl-enh").</t>
      <section anchor="tcp-flags-handling-1">
        <name>TCP Flags Handling</name>
        <t><xref target="example_4"/> shows an example of the message body of a request to install a filter to discard incoming TCP messages having all flags unset.</t>
        <figure anchor="example_4">
          <name>Example of an ACL to Deny TCP Null Attack Messages (Request Body)</name>
          <sourcecode type="json"><![CDATA[
{
  "ietf-access-control-list:acls": {
    "acl": [
      {
        "name": "tcp-flags-example",
        "aces": {
          "ace": [
            {
              "name": "null-attack",
              "matches": {
                "tcp": {
                  "ietf-acl-enh:flags-bitmask": {
                    "operator": "not any",
                    "bitmask": 4095
                  }
                }
              },
              "actions": {
                "forwarding": "drop"
              }
            }
          ]
        }
      }
    ]
  }
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="fragments-handling-1">
        <name>Fragments Handling</name>
        <t><xref target="example_2"/> shows the content of a POST request to allow the traffic destined to 198.51.100.0/24 and UDP port number 53, but to drop all fragmented
packets.  The following ACEs are defined (in this order):</t>
        <ul spacing="normal">
          <li>
            <t>"drop-all-fragments" ACE: discards
     <dl>
       <dt>"drop-all-fragments" ACE:</dt><dd>discards all fragments.</t>
          </li>
          <li>
            <t>"allow-dns-packets" ACE: accepts fragments.</dd>
       <dt>"allow-dns-packets" ACE:</dt><dd>accepts DNS packets destined to 198.51.100.0/24.</t>
          </li>
        </ul> 198.51.100.0/24.</dd>
     </dl>

        <figure anchor="example_2">
          <name>Example Illustrating Candidate Filtering of IPv4 Fragmented Packets (Message Body)</name>
          <sourcecode type="json"><![CDATA[
{
  "ietf-access-control-list:acls": {
    "acl": [
      {
        "name": "dns-fragments",
        "type": "ipv4-acl-type",
        "aces": {
          "ace": [
            {
              "name": "drop-all-fragments",
              "matches": {
                "ipv4": {
                  "ietf-acl-enh:ipv4-fragment": {
                    "operator": "match",
                    "type": "isf"
                  }
                }
              },
              "actions": {
                "forwarding": "drop"
              }
            },
            {
              "name": "allow-dns-packets",
              "matches": {
                "ipv4": {
                  "destination-ipv4-network": "198.51.100.0/24"
                },
                "udp": {
                  "destination-port": {
                    "operator": "eq",
                    "port": 53
                  }
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }
      }
    ]
  }
}
]]></sourcecode>
        </figure>
        <t><xref target="example_3"/> shows an example of the body of a POST request to allow the traffic destined to 2001:db8::/32 and UDP port number 53, but to drop all fragmented packets. The following ACEs are defined (in this order):</t>
        <ul spacing="normal">
          <li>
            <t>"drop-all-fragments" ACE: discards
	<dl>
	  <dt>"drop-all-fragments" ACE:</dt><dd>discards all fragments
	  (including atomic fragments). That is, IPv6 packets that include a
	  Fragment header (44) are dropped.</t>
          </li>
          <li>
            <t>"allow-dns-packets" ACE: accepts dropped.</dd>
	  <dt>"allow-dns-packets" ACE:</dt><dd>accepts DNS packets destined to 2001:db8::/32.</t>
          </li>
        </ul>
	  2001:db8::/32.</dd>
        </dl>

        <figure anchor="example_3">
          <name>An Example Illustrating Filtering of IPv6 Fragmented Packets (Message Body)</name>
          <sourcecode type="json"><![CDATA[
{
  "ietf-access-control-list:acls": {
    "acl": [
      {
        "name": "dns-fragments",
        "type": "ipv6-acl-type",
        "aces": {
          "ace": [
            {
              "name": "drop-all-fragments",
              "matches": {
                "ipv6": {
                  "ietf-acl-enh:ipv6-fragment": {
                    "operator": "match",
                    "type": "isf"
                  }
                }
              },
              "actions": {
                "forwarding": "drop"
              }
            },
            {
              "name": "allow-dns-packets",
              "matches": {
                "ipv6": {
                  "destination-ipv6-network": "2001:db8::/32"
                },
                "udp": {
                  "destination-port": {
                    "operator": "eq",
                    "port": 53
                  }
                }
              },
              "actions": {
                "forwarding": "accept"
              }
            }
          ]
        }
      }
    ]
  }
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="pattern-based-filtering">
        <name>Pattern-based
        <name>Pattern-Based Filtering</name>
        <t>Pattern-based filtering is useful to detect specific patterns, signatures, or encapsulated packets. <xref target="example_p"/> shows an example of the message body of a request to install a filter to discard IP-in-IP encapsulated messages with an inner destination IP address equal to "2001:db8::1". By using the offset at the end of layer Layer 3, the rule targets a specific portion of the payload that starts 20 bytes after the beginning of the data (that is, skipping the first 20 bytes of the inner IPv6 header).</t>
        <t>For the readers' reader's convenience, the textual representation of the pattern is used in the example instead of the binary form.</t>
        <figure anchor="example_p">
          <name>Example of an ACL to Deny Encapsulated Messages with a Specific Inner Destination Address (Request Body)</name>
          <sourcecode type="json"><![CDATA[
{
  "ietf-access-control-list:acls": {
    "acl": [
      {
        "name": "pattern-example",
        "aces": {
          "ace": [
            {
              "name": "pattern-1",
              "matches": {
                "ipv6": {
                  "protocol": 41
                },
                "ietf-acl-enh:pattern": {
                  "offset": "ietf-acl-enh:layer4",
                  "length": 20,
                  "operator": "match",
                  "pattern": "2001:db8::1"
                }
              },
              "actions": {
                "forwarding": "drop"
              }
            }
          ]
        }
      }
    ]
  }
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="vlan-filtering-1">
        <name>VLAN Filtering</name>
        <t><xref target="example_7"/> shows an ACL example to illustrate how to apply a VLAN range filter.</t>
        <figure anchor="example_7">
          <name>Example of VLAN Filter (Message Body)</name>
          <sourcecode type="json"><![CDATA[
{
  "ietf-access-control-list:acls": {
    "acl": [
      {
        "name": "VLAN_FILTER",
        "aces": {
          "ace": [
            {
              "name": "1",
              "matches": {
                "ietf-acl-enh:vlan-filter": {
                  "lower-vlan": 10,
                  "upper-vlan": 20
                }
              },
              "actions": {
                "forwarding": "ietf-access-control-list:accept"
              }
            }
          ]
        }
      }
    ]
  }
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="isid-filtering">
        <name>ISID Filtering</name>
        <t><xref target="example_6"/> shows an ACL example to illustrate the ISID range filtering.</t>
        <figure anchor="example_6">
          <name>Example ISID Filter (Message Body)</name>
          <sourcecode type="json"><![CDATA[
{
  "ietf-access-control-list:acls": {
    "acl": [
      {
        "name": "test",
        "aces": {
          "ace": [
            {
              "name": "1",
              "matches": {
                "ietf-acl-enh:isid-filter": {
                  "lower-isid": 100,
                  "upper-isid": 200
                }
              },
              "actions": {
                "forwarding": "ietf-access-control-list:accept"
              }
            }
          ]
        }
      }
    ]
  }
}
]]></sourcecode>
        </figure>
      </section>
      <section anchor="rate-limit">
        <name>Rate-Limit</name>
        <t><xref target="example_5"/> shows an ACL example to rate-limit incoming SYNs during a SYN flood attack.</t>
        <figure anchor="example_5">
          <name>An Example of Rate-Limit Rate-Limiting Incoming TCP SYNs (Message Body).</name> Body)</name>
          <sourcecode type="json"><![CDATA[
{
  "ietf-access-control-list:acls": {
    "acl": [
      {
        "name": "tcp-flags-example-with-rate-limit",
        "aces": {
          "ace": [
            {
              "name": "rate-limit-syn",
              "matches": {
                "tcp": {
                  "ietf-acl-enh:flags-bitmask": {
                    "operator": "match",
                    "bitmask": 2
                  }
                }
              },
              "actions": {
                "forwarding": "accept",
                "ietf-acl-enh:rate-limit": "20.00"
              }
            }
          ]
        }
      }
    ]
  }
}
]]></sourcecode>
        </figure>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgments">
      <name>Acknowledgments</name>
      <t>Many thanks to Jon Shallow and Miguel Cros <contact fullname="Jon Shallow"/> and <contact
      fullname="Miguel Cros"/> for the their review and comments to the document, including prior to publishing the on this document.</t>
      <t>Thanks to Qiufang Ma, Victor Lopez, Joe Clarke, and Mahesh Jethanandani <contact fullname="Qiufang Ma"/>, <contact fullname="Victor
      Lopez"/>, <contact fullname="Joe Clarke"/>, and <contact
      fullname="Mahesh Jethanandani"/> for the their comments and suggestions.</t>
      <t>Thanks to Lou Berger <contact fullname="Lou Berger"/> for Shepherding the shepherding this
      document.</t>
      <t>Thanks to David Black <contact fullname="David Black"/> for the tsvart review, Tim Wicinski
      <contact fullname="Tim Wicinski"/> for the intdir review, Per Andersson <contact
      fullname="Per Andersson"/> for the yangdoctors review, Russ Housley <contact
      fullname="Russ Housley"/> for the genart review, and Linda Dunbar and Sean Turner <contact
      fullname="Linda Dunbar"/> and <contact fullname="Sean Turner"/> for the
      secdir reviews.</t>
      <t>Thanks to Erik Kline, Mike Bishop, Éric Vyncke, Roman Danyliw, and Deb Cooley <contact fullname="Erik Kline"/>, <contact fullname="Mike
      Bishop"/>, <contact fullname="Éric Vyncke"/>, <contact fullname="Roman
      Danyliw"/>, and <contact fullname="Deb Cooley"/> for the IESG
      review.</t>
      <t>The IANA-maintained modules were generated using an XSLT stylesheet
      from the 'iana-yang' project <xref target="YANG-XSLT"/>.</t>

<t>This work is partially supported by the European Commission under Horizon 2020 Secured autonomic traffic management for a Tera of SDN
flows (Teraflow) project (grant agreement number 101015857).</t>
    </section>
  </back>
</rfc>

<!-- [rfced] Abbreviations

a) FYI - We have expanded the following abbreviations upon
first use. Please review each expansion in the document carefully to
ensure correctness.

 Datagram Congestion Control Protocol (DCCP)
 Explicit Congestion Notification (ECN)
 Media Access Control (MAC)
 Stream Control Transmission Protocol (SCTP)

b) How should "VRF" be expanded in Appendix A.8? Perhaps one of
these options:

 1) VPN Routing and Forwarding (VRF)
 2) Virtual Routing and Forwarding (VRF)
 3) Verifiable Random Function (VRF)
-->

<!-- [rfced] Terminology

a) Section 4: In this section's YANG module, we note mixed use of
abbreviation and expansion for the terms below. For consistency, may
we update to use the abbreviated form of these terms after their first
expansions?

 Traffic Class vs. TC
 Time-to-live vs. TTL

c) We note a few instances of "ISID" in Appendix B. Should these
instances be updated to "I-SID" for consistency?
-->

<!-- ##markdown-source:
H4sIAAAAAAAAA+29a1McR7Yo+r0izn/I3Y7YgIdu0TxaqD1jDwJksQ8gDMje
E3MmHNXd1U1tVVf11APE6DLf77+4v+WeP3bWK7OyXv0AJHn2MRG2oKoyc+XK
leudK9vttpP6aeD11fHH1AsTPwoTlUYqvfHUwXDoJYk6jMI0jgJ16idpotYP
Dk+TDfWXg/Mf1Vk08gLHHQxi7xY6CG/ccOiNFH7hjKJh6E6h31HsjtO276Xj
duil02jUdodB2zOjtbsvHcdJUjcc/eoGUQhN0jjzHH8W029Jur219Wpr23Fj
z+2r1ruZF7spwQlN1JkbuhNv6oVpy7mb9BWP4Xy466uTMPVi+Lt9hCA4Qzft
qyQdOUk2mPoJDp7ez2C4k+PrN44zjEZ+CB1kAOi+M/P76q9pNNxUSRSnsTdO
4Lf7Kf7yN8dxs/QmivuOajsKfsZZEPBk3yVDN1Y/RuE/3MD7hxp56siPEvoo
iidu6P+DQO+ray/wxlHoD1166U1dP+irCJt3JtJ85I2g8Z9T82lnGE2rY165
U9+L1Ws3nmR+UDPWefTBLwyTUIvOgFv8OvFjNxhFfw7xu/oxzqIb+HekXkfZ
0B25flwzzLvYDSeePc6UW3UGutWfI/qmfoyf/FD9ktV0/DZz7zzf7njgB0Hn
LvvzDb2h7pwwiqfQ4NbrO/jpycH5Qfvk8OzidrdPTfMfIfgWvlXXQALqPJsO
vDhplT8EBHlANDdpOkv6L17c3d11fKC3DsD3wgUKmoRIeMkLfzidtWduDPMA
kqv83fl4k06DEli9eWDd9lT6XIDd9sqgFZ5UgJsHGgJmGIV667kjoDxE4RNA
LANYD57jh+N8hTWwyIbaFweXB2fH18eXV01wE7e6MH0+GtZ7oF4Lthxp14cX
7TenBz82QnANhJ8I1zEc9SKOgMXAL+vQfuM5AEyHBTo0AP7KO+FXRMSv7y9P
m8DETttCIkiAiWH0WeA9JxWWxylRIcPbWwHe3WeGtwotwgpiqwHei5+XhbbQ
z/PAuwp2j4+P2/tb2+2ue9O4zeEbdYUS2Y1HCradOo2GbkDyFoaIo1kU+PBa
oUhGiXsXxR8S1W6rn/04zeDL17E/moC84HYH+Nm5/uwAgB4h4OplH7fArT8i
8TX8MADpL00rW2DkpgDaQTYBhUCBRrC/AFmJgJ90fM/zCGX60QuY/q8w/TZ2
0yHMFPsy4r3w0y79rRTLLcSWQS103en+NJw9L2rbbcEKfaeRe27e5ijd2eoz
SR25qcsKWj0mr7xZ6qFwAWR2FyFzFPmEwe5Wp9vdevUCZ3F1fdTBpp393d7L
va2Xz4NDYuj/eXV6PXcPIR9etFsmfnqTDVA3eBEEN1H6wX1h2jpOG4jVHSRp
7A5Tx7l8c6j297qvQGEb+yGimZE4QiROEYm0VHUKscMKcUdd3/iJAq03o3VI
Zt7QH/vUVeKlKhorz1Kwb9xUjf2PauqG9/DOQXU78Kew8qzZwuekgR+eyvBu
ovzQT303CO4FyhE8URryjnPFIw7xi03lp/AWoBxlQ4QhmyBU0rlW76HzgZt4
MgI89ViDh8YJ6GXhED93gRzviezc2SyA7kH3gicdx7mGPsx83SCJDPZIJIKm
BiMSnFNibwnhkJQuZn3YKWkUBjPqhjSKpMMLNPVHo8BznG9Qlae5IESO8+nT
v8G8cdoPD2bQedYKYM91ssSL21EM/QNIsiZjPwCOCXq/ihFCXEWDD6InXCsP
bINw7E8ytjv04uRtB96Ne+vD5OCNCwDd+kOvo95Gd96tF29SD9wn0BvMIYu9
TQTJWkZ7RmBoZOMxYEGN42ia049FHx2nSG3AQcOUyQ0GS4q0hGi2yDHUy0yG
mgWSowkGp7QMxax/+pR4wzav7sPDRsdh7IGKZhCVZMObhgEVzsBPhlmSMBJG
HtBLwOiYJQ8PQAW/3HghbhJ3gkDhYjJpJwr29RSGQJISLqkisgyjmOCdxFE2
c0BfxPEDMhBxC6lZ7LU14gGxsuSwwAkw3hHDDYiQDhR14CUO7KrojikYyIdx
hCgJSUHHmRIBbSqPUE3bFEYLkIgUWHVAxpqZd9TJeJN68j6601ng6SmFngcm
HwIP4MF+48GVO4FdBEKvu7XlnFwodzSKgdBhKdehC5gO8BEv2dhEQgGoAo8g
UXdgIhEhAS0qQMsNQAlsJ1RDECwpfAjLPfJB9qK4Lu2dY/gHaQV2zzHsHgLV
BUjy0a2xgfWdhGDuI0aSCOaCU7Jo5y7KghGsTQok+Q+PkAbrRLo88hrAHE0T
IQpoz94mapoFqT+TqSTmA2E6DeS03iInA3kXwpvWpiqRJ6KY2NTUc2HPIJrd
ITIzkIcE1tS4EpAlV6gK55mkwKCImYey97GhhRdESxSnQhcwI/gMBt1UGS6O
Ih4UkinNkx15QyCzgDeurE3OYnD6DnGBCnz0hAn4rQfY0EQ0i0AxHADqYH6x
N41uvRcAm4MA05rKVsbRgUZARmcpUjTuCD2ddVAl4fMNwi+CAHg/CXGKPgK3
yYQfaUDxK+Qx9q5yAJKJF+LcYdHhWcQyTwg9SoVLtoUxDZEfAqILjLCj2JVU
7hwQcQ881zyDfmWxYKpTmAeKdbQTgUGiFFIB8OGAugGtOYLdmfI2YxgSkd0g
3+IIyTwnC16V2MsSEXvKHcaAYEOghko0i+moN/bGNqxLyIS3DM9CuLv04BCQ
0OADjApo8twEvToApRakanAviz7MYoSFOBTKyvMKAzRtaCRYJDO2J9oHLDFM
LNCooP0dIZfYdLzOpLMJyAnv20ykMCMXOMQslb9NBxY6kZbgRQTSYcY6/QgB
dh3188W5AiafRlMvJm6beEL82IWlJpAO7Ib+LGOwoLmZq/cR5gab1nOnRjuq
7lBARUSbGeBD0qERMhQvQTTUPFlWXQ0yngTsi8mElAIYkFDgpFEUJCy7gC6P
jqIr0EVSf8Kb89OnH4BGX3V3tkH9ANy8/vFCvQHxoFAFk7f7r/b2Hh4c80cP
yRnmDmsQxWaz3rpB5uJmLdKCzAjHIptlBsyVGFaSzYi7IAdLeNkSH2Y1dWd6
Y5c0GpRst949CVhnChzKRSuiMGXWGGjKdQyW+WdF2GPHyMQNRxEidHKHLNkg
sO6A44MYGHjqCaM+Pzs62KhRf3Z2t0nqH+QqM+0jGgPkWUYbm5k1rKqmgzpw
cWENHdIICL3uj0b5nPorKRUjD010DaXuxB0hFRi0xR5qMmC+ibgkWK880nTV
bmdnq7ONPfxw0j7q2E70eDzc3916OfBxMuqSx1XJDUlboDLmHcR2YDbqzhsk
PjK0T5/q/EGoddpveoU3OFH91vZzAPmTlEHJcsvLgjsXJAvovUkuxxKvCaWw
DN98o45BsEQxKE2Ktu/6dYTsnaUXkShaOfzRht7iPLf8RZ+ZeCKY8wnBVi+z
GBV0eDbLBmjG4FdEBLYeDTSN8IEoCtyhdxMF6JnATaq5JqpopmP6SDgfEI6I
OvkcPkYAQeshOrVHZUhDnEaSTaduDO1QNQmMWM/AMvXTLM2NRaRn1g8B6PXu
hroIPNTE0ShjsTCOUEWljc+QkTwiZ/i36j/hR7Xb39OX7DoCUBF7osAiaacI
FtAZtdje2t5tb+21u7283ZB8O+g/0JBa0+JHFjYBzu0NbVAx6Vc2pfFUMQFa
jquc7gpeMyA5BpU4QCz8LfRRBYJVQeZaAArYN8yyo9HF1CA0CbiDfUeywOhY
tI7UBMDfMWjOZjTrCqJhm+HIjGbAWt3eIvwhGvD3pfZLZbdwj4LHTnmo3rMP
1asbyt75jxmoOXbALEoPCeb+tReDHhcF0eSe+fQH7x4MiXiUqNbZ+6trUO7p
X3X+jn6/PP7p/cnl8RH+fvX24PTU/OLIF1dv370/Pcp/y1sevjs7Oz4/4sbw
VBUeOa2zg7+0mBRb7y6uT96dH5y2kHgLtM6KBPEFHy0D0LVQg3ETB4TAMPYH
TPCvDy/+//+vuyvybrtLDgwRft2Xu/DHHRi8PFoUwsbmPwF99w5SqxtjL8gp
hu4MNFQ0LFzi+ncoe2LE3rd/Rcz8ra/+OBjOurvfywOccOGhxlnhIeGs+qTS
mJFY86hmGIPNwvMSpovwHvyl8LfGu/Xwjz8EQK6q3d3/4XuHaSTNiYZ4hGAe
Nyo58zQX8ms8Ly9f7W2hUkDcCpQrbKSZ8f10gNogLTlqix5Idt+dxKiJFvrS
2t7OLvVl20xaXiGMcxw/RZpiW8BSdHLOg/0AzznKraK+01fHlp/DtU0mVFjY
Mwi0Qoo7KMQTfALMMp6h0g4I0y6/TaP52u6GTduG2LStXPiroBjRFn53i8Zf
oK6MfS6TsNMEJPBBSsA1ItZ8jU4+0OvImkeUw9ZAKmeDDGPGvBBzNMCywgro
+uc//+nw331l+wqQeYvDS72AZ334L2EH9B/a7fhOo7JNpq34m+FNOyu/qfSi
f5F/Pf3Ao3/Fu2QPBcb3fRC5o40f6OH/Q8/78DTFZIYN/dB8Ly/UJ+qrHYVt
6eDhB+tbA6+8bNPX9rCgvbhJaVB6Ru6K6rj5u2+1x5+eAIHY3YK6rXtV0is+
arOWtGH58LmB9dKaEj59+KHo8Of50Pf8XR4Aa7O/9tHrQb8H2/ay3AZu2Gbb
yoLLevpgow4ajBEYir79YEAG8wXdXIXv1qkP/G7jhyKS++uULGGj3rQCNuDF
NDw+zkDmdHt134G9OO87GkWbzxsVeoEO9EuexMwdfvBSmLEXjJK+flfXDofU
hFEYmF/7iT+qotN6+mDTDKKJ3llosgjKQpOqQxM2LUFR+o7R1PhdDZpKZLs0
mkrtcMgaND2FbHcK49AzUJ53zS82VePfbaBUGs2iS9hY+qnMwmqURFk89NrU
luUBuYUMmdsvgC2WOAJI5RR0bJQztV3Mbz2TjAl89YOq/tjvpenz47Jnfinh
svcEXPaacNlbGpeVLua3fgQudVPj8Gizw6PImmvSHPr6z0IzevfEJdqtLlE6
nOl/7QUaB+4kaQ/8dOomH4oLhGkz9Lq6NJRRA7pOAUv6wZz1KLcrNXnmKWej
mf63X50DPH3UHMrtPu8c0O43vxR2Fuf3CBBWtk8N+JL1Yn/bK3+7ItwuKcW5
kgb0gnrjMDKBrvi+LR9ZkKCnsk1x2JrNNfKG/tQNerukk37qq29sZZeTHf7U
KqjKRf249WBryJN4VlCQOWIBSjCFCEDnsLxIlvHRoDqLpqxM63x/2MtSlHmF
n4LIg69BD4xGXkkP9D5iPoGfGoHK21Hp5209KgpIjnCn93q1dSeDDNQFPywp
kkp2eRE0I17NvEqM2cyuMLfKZGylzvQgrMx0PU8xzcdJYxcjtO1h4CbJDxac
++aTwB14AWzDhAxJ+aaMDvyQlRj+nFQi/DbWDJjgoZd5z6QdrdKAPh0E0fAD
af4EjKXU0ozSgPV3G/d6RgY7BTPEQvt4bLGoukkGXjhJb35QZZ2yRI2VNRMz
SXc9ABYX39sQkfWSQzJPfxUrWL+G3ZSCfBNBm3+EzJLQ+q36K6MaH/3Nkjwq
f2w6omYSPba+5MXFlz80fcmQscz+toaQxn8fWVOiLjg+SmuZk1Hs51/xZ/DI
RpVwYJHh5a1TNHmoj3KSZt/6w7QbAoeo7tcc/BgEUzsaa42jdhGF3z8Csp4N
We/5IWuUGH1rO07kYZFEJsaKLG8I6xN/xBCWduMwytAdafdbetPUd+kzbeib
/nOcFxV2a0L5Q9gB2MHf7J7xgYVSC3D5gP13M831qh8Ut6HehwaaEpC93xSQ
vRogtXplQyeP5sFWMya0ghb+yHwvL9i+bf4pdiWN1rG7jar3pb+es7h2FLcb
DGRVZof2t5VPVe6osm3oxtY58ixrpbC8+eNFC1y3eDk7zULeQWU2qJVLa9DH
EpPVI7THf0oLCHipY741LPC5oeotAVWvGSqSrpajkx/MBacCCOrd2Mru13a/
5p2XWVLR2Kt9K816c5tV39p7tPR98XGZFssfV16V6KEOoLq3pQVralZ+a5bE
S2owDg/LZgpYHLVWyo/a4EAD5ZtvlI5QXOFIFF4R66uaDRoOgwzYKdAphQ50
MN7jfE5OfsstG53YZHI7ycAZuiHG4NjUJBsHHuA4mP5233GOMc0JAyJ+ghv6
75mHOUE6e5YzlpgEMQQnvWHgBN6ZGHEMY95iCiF3SnHQPDRDgNmG1no5koGh
iBOM51rZYBi+OQhV6XGekOByxh5lcplPMHXtQLJEKd9zwJmsPuc4+zrwmmdt
skNAcXRM2/mY60WRcAx6hSbTl2a3wbm2OjpMCL030X+dUSa2JEDcoan16qdm
HtdPq/ebntYFaulmPhz/algiOzYmUeFMcpxTPAdG7/WWN5mZ65x3d314QcT3
/uhio5MPJXkaQpIuPySJSOl5OvfX/hZP0044PQVaaaEJ4/wd0zjSaBP4qOem
OjEY8xbNGy8ddjZw1hpKa+bWo9rZ6/ccxunYTQR8a8d5PqUm88ZjuAUR3Zcb
PDXaj/KQseJQsNEmLvm7lrI4eYIjrVsvX0nWniQ68OPd3d0dzGZCG2BTkiGJ
GKYV7kDnMmlqm5TVjEckJAUHDQVaO+YSicnTZbmIq7lsalnZUWPFhTFBTotT
mjzxaDsUTXCCtTGQnYBg3LqxH2WJyp0RGqUmrLtp1qkQ3qXo7s+nB+eYA2Yd
ccKMf0UJ+pSqoBkynuEyg+gxdMcbNDOgthFwVEpsCIssNW9J/Uk+m95Apd7w
m41Ccrsr2EBUFxJx9QtNgRpVsDs5hQpZA569GuJWHIDVw+90JuLb6+uLK/gj
vqX0visKkOs+iUnlIXaRZJJlZLe0k/d5Ki1Gfauv/tra3trq9keD/X5vF37p
d190t/dbm+XH2/T4bxuG0JBh2NseSFmt+x2Pe2dMYf+9v3EWS+50gKfwMXGZ
K1k9kfdlNGFDynaKGWc+S1Xm0WAAYcqpi+xC/Dp4SmSU56IioeokZXF5WYmq
qTe8IVnMMhzXjNIwcXJ0Aku8RcRcyCyAPTrw7iMA6r/wOGC+xZQ5JUx56pHe
vfebik5wEC2TA8vAwaBiqq1ORUceQkn2sXYbJcRFRRwINB3ceuywYp4gKxq4
93ioDlvzrzskbIh+CXMjzE2T6Wm3nmYUNF08pULTxO8x/UNnvBG6OWWyNpsq
aU7flfXUUIg2RTnShPQYWL8fe+aohTl1Up/gqvNWgDYpsVnS+11/uklpzHcN
jI75XF2Xwvjqzsi2Sik7ZW6IySOHmILtThL1FnkLGg41yqbAYDRNhtTomWqt
ECJaY9GNBCAci4ahb1Cp00m6O50uLh/i49X2qx1iiwc6xTJvUUp2F2Jq4QeS
C0cTaMFSTPAEwz0oqIQX+mq14+N5H3yKiZN381PqlJ50GPi54qwzywcRaAtl
PODu52drhYSlnFrY4lM60Yxzjoj9yRutSqEoR1oD4cgr90Yc6KutHK5b4Lnj
RK0VYtgCayEWW7OO+lUyHw11XX8mNBQZ5xvNGx3nKpp6NVoj54V5H31UdyfW
Y0uLhK2G6hJlCGYDzp2XE44Fvk2bklK+8m7wiE2MxlE2E915Tb9cE8JcC3bW
aKAXMEqpy00U5Eb90d8I59xktc5WUFCCe9GYcv9xbcegl9IxSbG91srZTTBy
mSnk2fySYW3xvNJ5O/zjp/cnh/ooxxayMUqBQ06bhaEXFLAqHQpUmlmSBUHn
QolhMvNmiYBckEMVnMzpikvYpGsRD0aMUSPNbPmQmGuOa46M1i4nCvIRmgQJ
dBxE0QfMP6csQJEkQhZJCstiktMHwCVCO9cRVEHhxogHQ3T8bIMp9YzAhpHO
Lk6vFgue6rmRoiSiI2/6oJ/BikYIjSF7hw7X8nQYG/RS4K2kVO5s0fEcTiHH
B3u7PXxgDIRiQqWOFThtdS2KwSHG5Po00g7yQtU6/jhr8ZfFQe5ufIAZCCT2
+GwfzKNV6IZbtdQ68Hv5faMAVwcGPsXwmvoZTQu0s7a3aFQeT7wbcSxnfHUy
PhkievkIIRSkw+6ur0+xm32rF410LyRT5RoPJ8Cfp3hWbh2+3+D+OnNYsL18
aGdYhiWupmwIW7XgFWXGZrhJjnmi6RDAQex/q9YKIdE1fFKMgK5pWk6jGWlz
UZpG0w38sBIB5eblMKfVaR7LpIcmeLlGpE5Gj8WLX3u0PeV0paSvYZKraKV5
kH0gJRpEbXS5K1Lj3NShs3dRlhK9Qk94cjxLmcC5pT656CcFRkpH6Vj6O8KE
WHYi3zpGJhrCXsev1o/h/xvC315ub73ig1Urw6qqsDoGVvrQOMlmyBuZ0965
8YjsO2QhdJiPeD6e9qY3TA2O0II+9Ubm173otyGefBt6YJjEeFxPnWgzHGzK
k/bVydGGvTKmjMhAlxGhWeFyrV+8fr2h7lw8xuhP/LBQQQGeSskSZ17JEjZ8
ddmUhwdHlxKxTvn7+eFgfTr0I46PSAJ7BaBwRhlVUNA8++zgUEwEWV59SpKT
R/ngvocWccpnQtED6bCHSqbLZLKJOxH2tDtL8OgkhQGE/W/v0vb3NToTRqfj
V9ApMk66Bg0girXigceBh3jkNr3z2GB3DKh68bQ1akCTF8JLTij6CQsDdpUc
G7QnLCdMkVG6dLaeTlHA7+jdcpD++CHPgtm/3SXxXhBWIZ99xu0wBbseG+kx
HLM/tOUnOfl07ncW4zFWRajoqBPs0ZniGgNjuy9yNtI0vLELi6zRqSx0+gWi
7jRwDVgwG/6rmn7QPtEah5QIOf75/KINlKQKBSl4xxzIUQM6zs/JSHgCgQpe
2GdH87wk2h2J51G5hTY+B/ms7TeOGBv9K2+1tsAaOwiwCgBZLYXz+FqACByJ
NUrCCNbR8VytBeSABD6NAM61PDy+xr6PO9Q1SY+kEDV8Uox2r20wnZTOIQkY
TTPI4SOvVsDVeYZSdsP5pnh+warepD59Yyk6crKQC2X4U+6RTVyKI7Ds7716
1eWTb/YpkFxn2d9+tUuMG8Mvfzx8d3SsXh//eHJ+9T3SUQnDf86P7HW4QI62
mqyP1Kf/4ShFdcw0Xrqd7nf4EKUg7HWgwlYWh31s1Sd3XNL/OA36YdLHZv3C
olJDcerLM3iED3nOPDYGvaXcFQ1vmuCL7/iJOUv3PyQA1cLTiYigPhi8VOsj
r2vEFeeo5UN5MOgSdweAOC2NFsKjuaPt7+x2c0fVYaHoS6lEBldWqoeAOVlb
BDVl45YgAVTNBwQooVLHibiaBo7B0Y2sn7r6N5sqP1DcbQC6EG8vgVt497UA
324AXIRDLX3pZLb5MMMma6Ix43q7FBGEekENIJUydCU6L7+fCxAe1l2xHmsN
PvMKrfPg7S2At/cbgrdYOK8O4sIXXwdm/McuX8qtWlhjVp0fX5+9O1K/wD5A
WqJYOTckq3SYyse//Kh+8QZ9+NUUYAOKxFplH7yYqgBQNba7yQsuBvBCQIN2
CDA0xDKpadTn13/WLRg6+Dng4mzwW6Wwa2WW0tW8Wq6VXoslaZu6XFSGttJt
fXXdpu6XKKbLyLdyuGQBtOwmg1c7DLgiHBXKYaWFXEp20eOOQfBhNLsHa+Mm
VevDDTxLv0dVhtU11jPOdWWQwFTzIQ8xuno6XD/P1DpBe72j0H6jbkndxZDS
KB/zEmaISTODjE++h2Tvo4Ij4XF8Im4oUsE3OTYc6TXX5YBg4lRIjoMoPhXm
AcUPTcBZFicZV09iPSXJBv/lacLNiwsNYVvp0652mJ0Vw0vv1kdvwOurIyBY
+lY6QMcWwAZQAdg57x8aB5VB4lqiTr2JG3AFSdrDBg9iAwE09P2RqHb6g3Xc
VbCpqLi05+UbSuBuYxBpI0csUUNBi/QT+0ixbaVr3vIdTEVPSheq8NPEC8ZE
NnSCNSD4sZASFiFqieIUezwduwKD8LoKoSJj4aqAplmn9fX4nrZWys7aefCf
Wd6hiB2W7CHFYh6sigORzx+mcDhzhaHIfyE5FGNK+eakgRWGLhxkXH7okC3N
fHACZdXBOfq8wrAc3F3QKyb+r9Cp5YUt9axTisVjTVJ5XsevsdKGaTSm8KsO
/Jowa8MQ5EfZ1r1TkUJr1O+aB0ULUbpf4BwnrfDUDz/wYGZbSHLHHLh2Pitc
xmk/D4TdZwGBRZo7TiUumccL1jk0B2AZvFBG1UzqmcYmcox1vFwpNidhY+iG
gNxU5Nk1PdQHuY34RMUA5yilXiSKun7wdsNi3qoQC8qTNKqoLIU7TPs884ii
XWCTHF5fsPQ7OsTAKzqvwoIDLkeiSoY3HpYAwuwPmGdeWQGkTPvkomHNSozz
WRfNC0eadMycy8RcTJ4hgRd7M9Q5OFRaJcMc3YcX7NO3x0X8UEgyp4dyJ6YD
fGFFCyvw4zsB07QpLjYxGikSSIEK9gfS8UMTWkKQJN2iMLQVaxUAYKVfyBon
WTwLsoSrM6/7Y3yY06teXNBdKE9N1laVFlefa1vIC09sXqhTfShLYIGUxzyE
vloiaSA3sHcsz0ABWjA6CmSooZ9DgwfDD2F0F3gjPmepcyDwVN4XBDy5D1cF
/Oo+HN7EYB78Az3lf8+oqpQkcn5ByMf+ypCfR+ywJ4o2mcqwXXO58CUgz+LJ
qpC/jydIJFTjEAtCfR1imSU3qwKOnPYig3a6bg7DjfqbP/UD1xTge3/5I78i
weUFQW6ycu7j0PNv2Uk/iyPSwzlpRIfqXHpwLzU76euR6cKKOw2obrSUG51+
QezFuYdzWexdeiiivtJqAw5Xhff48Lx9PLyJvhbIw7t4VZBhrAmmw0O3v/jh
KLpDF0GGzoqvAL+7MsbBJM2o3Ceg3tbnLtDUjbIEk5MSjuGeX6n184jCxdkU
oDEJGSCGctXGx1qk/rBB5aLzznRIwzJTCFapDkC5WfPg5ZzYPOfBwxiSzl4x
PNmylxoVdjvfYTWLCXr1b5ED5LkgJjeoYTjMo7CnWxx+HgPEBIyxlPwbUHl7
YFgNo3CaxuMGes1tlx5Ln5mda8bOwR2OgkFHHfZrGgUsiTaMVZyUHnsepUhY
EdtaqcFYCjYemYMqoG1nQdo0un1+9wnT1MHT+VO1TwEXZmtDMWfCBUVWD0md
yekYKq85Mk4Fs2cNMiQtrA5KHHvkjfM8JAGQMDPAuyw+6f4wFQKLj3/KBzDb
bOu7/GHNHHgeY0XJfbp4XuhNzAELU7PZMFWJYeiBeQp1Q3eXGFq8Lr5ObqT0
APjzzk90PmdeNTpPb7H7UGvrpB7+O2d5bag//Yl/W2sCGU2eOoC3lwD4ANqW
wJ3q1EHrsBUtEOi7umRHpwDxSao8KpKdcnbgGl4NuKbY8Cp3YVuh+MO5cdgp
aU6cNGnS7DeBvvGQxFwM/duf1FYNdh7mmBDmpo0bELjmeIkkjfDxnPJM12Ay
kl5MKFrjKU0xVoDkOmDgQa0EhuCGHgm/+k1QqEeyYCeMxo/eCEdRuJaawag3
yezfLS7gGc5B4AdkbFFFU8xO4nKmiRzRJE8Pu1GbaNFP6sFdZvOcUC6NQNs0
wLi+/2Vo/Y2PGvCiAYL6AXaWGODUndv/HHo88sek2lmrxaKxnGtbT0815dgK
VIVJ+NYzrH2X3qhWobQSZoX07ZPa5mH5KHbLmvQfuBf6Lv/EPELpofEwb/rm
Qiej4tKmrBy1bZx+uYLa806/9xWn31s4fbvg1zPO2xyNb5ywfPBc0zWndRum
Wap095xTtQ/2N69v/tHzTdk6JNlA3NVKas9J3KXyBE2Tf16q5rO+BP78efc+
67x7X2PevQXzNgV6n3G2ElJsmiS9fr5p8tnewuSqNermWUPW5dEgec3hPCNR
ERkVQ0IQpR8b4VsrrFtvWe0zZeCN4744ksx/eBNh3i/miebD1Xd8yJ+C0oua
ZX6oUB8EGll6wdCl02FcSM/WOnCCnJFYKbNnfyZTtopCFd/mnhFa2JI3h38e
7D8aFBt2mxhA9ZH9AsrycwhkLBab61If1tytkR8K+JBagWV0aH28Zv5c9+27
5SZyzaYIdaX9P+yvgEntsv6NTtr71FPdndI0KDeH3uzaCCjHufgHg3PDwMWL
kTihptz7dqnBMIo5PX5kwq5eHqiTcCEfEaKLRqK01IEcvDSVMsyNbKXv6s69
crTWj3ONt3gUtjIUh5YPzg/Wljn2Wmqen4JdK52CLZBIjctTlnE1x2dp9PzH
coiWvlnxEud5hP1QxwhLRS2XZ4dFA+GxPJEPRrSIQlqP4ZUFMMr8koCxbVsB
pGD3Lhg1N9Hv6B5WezxzfhLM2eLYZTTPK/A5D+c5gZqwbuV6UXLesnXG95IW
1qJwQq6EB6pMaHMyzjBqbXU6L2vM0noE0amJysFCfWyGhwXy3yCuY28BTCv0
4uBeYfw3lLiVOv7PC/qydi3rnd3z5U9B9tR6kRdO8aJUeIFPTdYBWDlUWIKx
pmDqAvpjV57loBdch5X4gIVaXJMMb28zGYjMr430p8YELK+51Zb71xeY5F57
9qEXBoF+bZhGkcfXNVo1Tfj0KNb4slpCj8UDr8j2r69PLaZbw3CJ2eIh2j5P
m0/AXiFY6lhGqSWa8pHO3/KaELBWKwb4edfE+t6szpdek9KB2tKScDm/Batw
WTRhedZcrmXGl5Ri8lLF1Vu8crZeZOiTvXX8cgFUeEy6nUagNt8KKciheu1g
xqosz4vTsrAp1EteXqLrDKYiiCzQWelbnd9W09AWMtuTYqmCQlKnxAeohJLe
N9bSrlQkp9SuOOsCrVJphhpSsJT9LESVuoUKdbJIjylOML8TmhqThjMJ6dpP
SsljJc2cb9Dg6soRmAbCFyQLujgfunk2X1A3WwyMuY+oAAsfO1i0z268xjIZ
OmtPI7DMhvkryXg0sXayhnJuPLi3Wq0xvtfUH4Qc1ubrewuTra/sO9ZtT4Vt
dVOS+Vy6q8cNn8ln+i/2Xc9w8Lw6MJiR4mptfcXH21kG6KPu+nx7zToytOIf
LjGJQr3zRTsD3XG65pN0VzsNPTYNa6r95kPjDYB26bIF416Y8ogdZRWpswqu
+7b6IqmtdC+vlehaV1bRQryli9AHFsvMMWWVabcsOetseZx51ovGCBAOU6jz
pqtV5jOtUfAtFXZlEDF0t9ZR3/9JdTov8mmuFR0lXhxHcVuuFrZfyI62BhfA
pxITtKtPFhvatShzHapdvwoFT1MT+t6TYrwi+mr2gxj/qysRpn4FywhgVBPP
6lBmZcFcyMDuka0oRZ26L+mv90cXdRyYIcVi/3X71qr4vwDgNz8dnZvyeTpd
hMFuHjaL/bpR4fGC0d5fniw1WJkr15XDnsekD6MgEM9MXhpUzjBIa6uQsAFQ
p+igypTNTCpDKWLd5JyYewHCAsRgOYXcnJYz5Urf5L2E2vnyFWidJyjFsfaF
Ob/OHRh3Vq0sHxa80suTOhVjzQYF/81nAbB488JjdI73IdX6ZM+mrtglPpmU
ZMAt6iPmtFPR8DAVW7lcNJ7RfK75Lqb63pOovvcFqb7mco3PTfVY0HcJLKt1
RkbdIUfFKS26C9PkZzkJ2oPGjU1FGRw2W6RP2VxLUtpvHwm/wQ2siPbsYrdA
gWsaZ6+j0f2a1YGvY6//2stRMXaarqtZnssUmlMOZzF7U1mFV/PaPguDoKYN
p7KO+SRhUMnWNSSmE3Krqm9TcLPoXi7l81oU3AilaL5shY8t4CTdVcz7QtTy
oQK0P7LBory5FuXueqM2Wrh4EwoeKF8n7Zyh3FStwtL/QbXW8plIvvLaRqs4
4eaY5jk68rSLPJpw1SGdrUsgMSoTLLOnu2/Szev8gPMxGFrDFzOVG5X1nKiK
1aAeSVj1+dFmneqysFcksJoU6kfQWBHOZemMlfa67O7FJGfDPY/s7N5Xpbw8
QMazgz+xjr2upcaESHCWGN6aDR1VLFsrwPE8JHpq7ntIuO6cBo4OuNp57ugE
LIAooBuxlJfP9amUej15V/TAUv7kPO5Mx9fL5UsarhUxoJqrMPhEjRvnd6u4
edELV5duNCph7jxqF7zM5MWx04CatuOplQmi86atO0XK+7BMuquto83lrMtX
8Mo4yV3XB410TKK0mlae0o1JNJclxaSLMu8oMnsLrMfPwbpox/5m/s4v+/eK
Hj5DWytshQIZle4+IYQU8DYPOU0E33s+gu/V0LeB73c6/03S+YFKvY9U+tju
rjgpXJYnEX7vUYTfm0v4qxO7SZN+ApVz4Umm7qHlZi1ekqUvPikRtoz/BLI2
tyRZEH5GmtajfQmK1hiyQSf8+KPWEnBf2HdEWTc1USRQB/SAsnnpSlCXQ86C
yaLF0ITJeVqXVWVZa/01d1o1aU+SzFrGyrwB86RWrnlvnL8FV30s9rhkL7ol
bY8vuZgHpG0X1N8lWQR4DsiFcK+5H4j2WWlIcqAlS91kWWj3UIPcuXzCPmPw
FF5hbn8w/ML2Bi7mFxYcT+EZ9v1iX4ZvmIk3MY/CsmpG8jRx2BRR0r7AsCQm
a32EzfNewn782U7xqzkusojuyic8nqKM5ec2Hkt9TyO60sGRL0N35UGbxVaB
/p5EeVRiLl+4ivTCh8vIr5P8EqW6RSywQmKDdZG65cms93xk1vvKZPY1iKz3
lYis93mIrDeXyHqPIDJ9790c2voxnmWUusX3bbLcL5ZUlKkXUoUeQSXlTp+F
Jsr+1HIWkVk9QiS9nRchsE+DzcPaBedtol2rb4h0U65S6yXGQmK7uuQhSFLQ
sfiarmrIoMn11YTbZdxfkqdkoe2R/i9NjSUYiwGwwlxqvRqPn8tcz8Zyvo18
Dr1l5lAxVh8JfJPButBk1dq2hqMR0Dpt+bHAzteY54sTDbANTyOFNKhaj6WQ
herWUqCXoZoLfY0Efwr0c6X48tD3FkNfEg2N2avRrB14t551cTnDXWHmOYP1
6lisXLtlHcFtzWOwsyKDrWGVday6MW/y8ey6lmHLbG0QzBu8j6MvScntkRfe
t+lKl6VQon+Rfz39wLMCUXIQuS+HMedi8WA0yivUcPaBlTFg7nw1yBVPR7FM
69zDJXitcH4HmpvfrUGZzvbZ3ZxVlXOplfLHbV2wuVUus72cRmVnquPhsmq+
uX0TZdXTJD4N6zxCrYJlcFRShpbHUK0S1M4VrEq8kvM49CH3lZCBN4ZhjVgs
oVkduHZedpnsRdMqXGcohZBLV1KWNXC+PL2OKuhME79eSBn47VLeSH3rl6EK
vrrUKmVXU+fbIoh5pyHnKeBL7OyaHQ2P7Z1Nvwfbj93geA8b5ddjDhDXZecU
tzpmWlNrvgH31peLFP+cEKVolNxTqyGrmAJ0QVx91sHSBsFxmJpioXLjnOyg
ILpLKtW0ZM75iYz8wmydhMCd8AXcNYaFbBzCSxn0Rh8VrkuuCvDRDqmaH+e3
o9r0SGf9S6cHDOI4kbx4CsNCXs2B/zwR/o+UCM/57NjDWrmLucnwNJ1rk8tO
IOhM+IBrvuJlmnnie7V5fsSTmlfczQ8luJvOGMxBOEHJZw0or04uC5HLEkoj
PlTQmwO3AnofCybn9K8E5kOJTOq9/w2nqqyJFH36tV5867yV9/fySs2b1jvr
PtUBXU8Y+LkmQhsCREV0t2gx6g4cLVqLeXDRyBKRWTVghT9VVQJ/GsowPPYI
UwUXtRGUgnFSvcGjgaFbXz6WoReliwUyMoYVL7S0Wi9/taWlUDA3pkkty40Z
/GdnxwjD09gx9vAkdkwgPJ4dY/Mvyo7DynpWRrQY8ooIfk6GvBDQf32WzLti
BZ682nLMjUTT0F+aKRNDdm/6yly7/Fpfuyw8ejV2/Py2wA79g/5X88tc6+At
s+cQubxcqOVSpQH+XZeISUyVU12bv8kzbYrKmGVmthVGKSbPIlBUHmmjwLUa
+VXr2EcWLyWVojgvWpPcRFkwomxfXozRphpkaaWG0yBKb6om7cryC6dusFH2
8pQqDxUdarSD+Sa6tu0Yt69H1WlY1aKjC+TtwdzynjSEMVwomEVwWAhyRyOQ
t/UlakZYRD+kUxOfH/JmmC0wlgS8PiGDuWWp5OXqUFpJGgUw9RsLRiKH2gMn
n2PL98wvS2z5ZPk935u/53s1e37lzdV7ns3Vm0+i5ZK2z0ai+qLJ5TfT14L0
X2QzhXibbek+str9JEB6+rK0+hN1Nbfk9vWfhXbLnNEkcjUN9XFSckx+7r3O
Uj0dzvS/S+30Yk1CnSxat53pq3alLuQzi/DCIF9WjlfrkQqXMVVUm/kLlSes
pAbzRrDqRa+8CXTybh1HwZcL2ckXBcwauAa6z0Xy2Wim/11Gn6Vr9Cp0bi8m
dPTbXMwvCtjXWUwMQJtfllnOQvZYaT0lFl9T06ta5Xt1ZbqUqFhAnvVyKRkl
cfcGSHvPAGlvHqS9JSB9lhWXI6NzF/awcEhan7E2d6mqS+DdoBpN8cKM4rlX
TiJoOqZtU0ac92HwzUc7tRSL4js3pvH+pNYY9KE3S9cKhzWbfIIWiCD7/REX
WqIBuBt9JlUSDuuEFy3XyBv6Uzfo7dqjgtZLrdsjf4L12Larje1CbRjJhnXH
9MTlXbSujSJ95FQnkIhHtUIfD84fD98dHavj86Or751//vOfjvMNFv3NsCoz
nu1P0DHCpfgch2rcJZ5BBNb7DjABy9xqmnqwjOinZWgHnGjx6VNeR/glhth+
OGkf0YXl7dBLoZd2PB7u7269HPjJw0MHB/JUi97L+dtW4abykSmtTkX0CAwO
8/qJAyNz8WbxctGV4PDnre9SJyYlIATVhjaGyX/a1HefOufH14fvzt8A5D9c
vjnsbe92Hx5I37o8vrLf7G/tbgHE6PhOvEXdq/XuBqgut7jLHSz2h/mXQ/TO
57e10g3C+rLeq6u3Ms7u9t72w8Omuj690iPv7vbwCQDl/PT+5FAev9raAoA2
CNb1bTMc1RacZnTizC1cOCzYlggELrlVxLd0nzrdla7Wzw8OzzZgvH9DMHYI
NTM78j71XL6SHetixP4wlUWQy7BjGDrDiyU1kuGpQSvAGSfG6tElhTGPJxuY
ZFWYw63rB3SAuq4TY4mYu6QSqYxBxTR4ypgjgf9ZlbSImsJolKf6cJVOIHWb
/HQldwcTfRCIF0OsAUa/4Yag39Q63cukWlJLGZ3QLetOP0CUI37cjY5SBzAp
3Z0NB4IY+B88vHyJ6BlGSqIQPrt3ErRZUizniSfKswB0fmoOMCfRFM0uXlMv
vPXjiMtyYx05TE9yLNQItXkjP5VcB6YfmotnI5EDMglD6DCE6KmNMiLzmSQm
6vIZcYnWKMGNKNKVS8duPccbj+F7dO9qePMBaWMB2WAsHxk7lmOKPQme5Vhy
qE+LsjRm8Bx68kKjxg/o777jqDU7lWut76i+bGG0sRN9iitPkD650Fa1B1zC
PqC1abMPo9okfLO2TsJRV/ldqrJv9rqvcPtmIaIoiv1/YCkKXBm9WTSuhdcz
YEMqygjYwIqWcTaSzQKEieByWWPYcoChhCq+cFYUSAQtonRkDUlYjDW5m4u/
S9Fio9IR4X3d19KP/b1eJCyaTfdV85V/VGRfHUVXmHrnDj9gt9IahX0cTX1i
gSPv1h963ElAqWJzOunkK0WJfbg99FalkEGrIR2vpVJ3MsGSm45zFeX547Cd
RuU9V7fn5R7uoUhEb/TY3XeS8u7PEsefIiG5Iel3ujoUAqRJQDYmSq4J1lSF
/8kGJWTCwplCOBvFvckz6eTFcoJALlkwm8lp2EzqOTbTe5us7Skx2s1Go4K5
RNBIGkjctMycoaMr6XEQeEjCC8iCzC/rPg2K1GFzaHJweAqzPgWGiTcKbhb2
Ep4WCTmtB3kRDX3jBbPSsA6RN9FhMoxQoUc6o/fcEdc8rAEkzyRC8TUB0sh5
mtxvjJ1jxjVnKiJLA8k/iqYwlIvsDqs2baqRnwyDKCGOZ2i1BL7Qhs2YuIIK
3q4M/Bg4wwaOhoQbZkFg+IOw2zGW646CaHKvbnzSmkFWg+Y28XkH2DSciJIw
ioYZqTS5AsZmiWTSmlw0Ny99mxdkUxFI8PhWrt8QN3SnWCGS9S/dn7QDdjHI
d7i49qzETr1lpVrWR5rdETINYFA+320J41C6Ak60Bkyeho9yP0W+FgJ1wkKy
wsLXV9PgWQhWWnw/w8JBuGU66m1059168aZGLiZph0MOG+ff6k5G3gxrf+t8
XKrQygeHYapZiEW+uFA2p9OqS85UpFV0TUUvFiNap+52SaUmZWwbhAoNnWgd
fljQ4aF9wCXdI6PyGXX/jdwADozn/OpNsiGUTTc/SpVq0aDym1OYMCxOCTZM
pVAk6D2tSh29FovIVo03tyUElstfPiglnD/XjLCsM1VN07oRpXYP7lVETkoE
yxGwOurYxWs7Nf/R0MLHsMG9YJxXpPc+ziIUTSABLbaIyHBwUK2mbZbfatcr
Mbw2GZCUS04C9fLiELbRQUIkTtQiCmgY4Q6mRBQ3yNfNTxJMjc3Xy0mNjWGA
p1FDzyAgF08dNOTw9pmKEffNNwrLlF7yrTL6qZIS/WaLx97fYXwgWeqElHls
IHZerpJBX2b7tcKkhT2BZDGX1uC20a9Pjq/fqP88O9WD37dEG9rp7e8/PIAs
QQsUeuyrLA77aAD2KQ836X+cBv0w6d+74aRvG4aOnkfIpehATPQ5Den46seO
A4P11fmLg+9E2NOcAF1UqJVKXCM4VNsIKNwDrC0evUzdXxOE3tcFobBrnxsI
9kZ8wxR/xmoYHQktke7j6Lawj/yQ9Aek0fJowIxscmZ67W1tg5VdoG3iNcq+
uallbm7qMGHj3PqqQL1muitQfH7nFDIvnCbg1eEYYV8XZHOMS7GvsGrjf8KP
oyGoUPCyYFQa1sHyFwNL9fuloOo9FqreilD1loWqSOcrwVVsugxkxRZ1sOmd
UWTtHOGHLttn+ShMycT2v9E+7ms6ckb7g1+X95BW75CwdSLBrdTm1OexcZx8
Nk6N0Le3WEfuN4gS3KFDHKTUofWxg+zAOHjMNQi8Nev2l/PpE8FD/reLg8uD
s+Pr48srciXSNCkPVTOclAQua9Qg7j2dZmrt8freQD59D1rTnZxqKdxsPfJh
WilIfOiaxyCQl8HKPXckFgL5LAt9kFMB10yds8uhVQGVF5bmS7cEuPpinmT5
vjbJKXOnWl6YTVv5KThH55OuPrNKX5sOqnzAT9v5ITtWhaLxphU8FoMSEM49
9B2gfg+vV8yvJ6FDGpo2CuoGeQjBuvMmQLfDGxed76hEi8lEWxe0WzLZ0tif
kbbUIozRSFJEM5GgGvnzizeJEdJdfUsgJwtAFzipLKE+6OdEB0E8iSfgje8a
VjbjblxQQT0PL7tHfyfqetq5jzmPgyRCH9wIHQdIyK38sxamUpNFSnjnsXVb
+zvWs7m57nB+Y/MVTsqKOyy/DtjQcC5BSKmheb0Oa9GwkOgkJbeVnwYG+ZpN
YTuiSdRXQr0am2iZk5lJajd7xXd6r7YfHoDo7gNP7165IlJfmqF1WKFf2UhL
kDpFhLiWrNlCsXfrI3NrOYbOhTIxzgOMSOkvFBXQLG4xnzLSQ11Rz/E+ojWK
vgLdyDqiuiyHq9v6Je7RJzNAycSpR1kMjvVgRa3RZplb1+GH+vkrdv4rd/4r
Nvj1/eXp38xcdf1dt+Bs1zKuaV5ScZTWxdyz1TIGyBz+5riJqH/otHp3eoRU
yeSx/XIf1DnHOT/+pfzwr/AbwvM3S4L2PrcE7dVy1P/LBWgjUpaRn7BmXK5l
gQztLSlD5/T3aDlaP8Hfvhz9XYb+N5ehs9i/RabrfZx5sW9uKHyKIK2j9X8l
QVqz/0ts5OnCtNcgTHtfUpjOYXRzBCreEVERqPywLFBxhGOTfvuW028/o3wt
OZp/t1GXxMtCKdu8kDWydklJu0yfj5K3C6ngM0pcu+LzHMHL4vV36fpk6ToX
319PyHI9YImIPlKUNpPxv4gwfSzreJp0LaLNlq8XP3856brMrBcarfz73vbO
S/37y63dvQZjtuljSyY77XZbDdzhB4ofimT9uSRZy27kqsNZffrGKDIPHP3g
RNPXxz+enF99z1fwVD0Hf97e2t5qb71qb+910InechxNz+VP1SdYOPymraV0
t9P9zlF5CEm1VgpmtLCxHLWqvPwOCS6KJ27o/4P4oiPpt3KH1YHe1aImqQPO
f0nv1TqiaKNFPQw5LrZ0YyZzwPjB+Tn/2gUM7alf8MpR3o5HeLHNprrKMHds
Z2uLPzuNoJdw4gWYinZ4oF5tbb3a5VfS57UX9NUfump3e1dt7+2qPWzLr/4I
alOQRoSiP+P/OjDz73kGFjflWVxX0iMxmTUg9kn7wmzNtYp3Zk3ybRR3IJf0
SLRfgDmMZvexP7lJ1fpwQyF9KIojX8e4O1FwUCoF9EZJ57r0O+5W7oAzkXTq
kbkeLVDUa2KYsB7w0hshvFgsDqkKR8DsWcqJ4YOB8ERueMZ8HEAwcVGd3qYT
IpkNcXrWJnIHkzGnZlmcZJz4xbIPFIv/wrQcjQ4EFGQQ8AbMqYYxzLEuZD3M
2C6R78Lfr6+O1Kl8m3iS6QeAAUgAs84S2e0Mzf416FtL1ClZ93QEPqF4quAA
FlDq1NPnRyLL5P36TZrOkv6LFyl243mUzI1U8kKgbmOu0oZG6XWTml4iHT+v
5Km563fcQ+IxJ8XHkq+B4a5xBuvIDgrMhhvmZENkOW+sO2CtEw9z2XBFtFzn
xsMo5rollBhVpOKM8rIwXH11eq3IpZzceLCLi12sEQtBTrOGGaK0ugZrEyCR
bNAZRtMXQXATpR/cF+bzjQ5vNKN2lJjF/Av3Nizjo7RUd3d3Hb2ZX7AWQiv6
AvmcVe/sxYYGQOR6zpOJ51Z5AB4ByQBjFH6XRm6Sp1jaSoUkyenUag+j/lqt
M3dWs+Zp2gvmZy5db+zwpzZ2AICVZ6kHLT3vgIygMR4QBy++JX4FUj9R377A
Jyn/WTiQxCX8WAFE7oaav0Rl5bGiZ+p4eBOhdnlvHkuJPLX1Xd0RFfuECrYl
1fS+lX9bRgN9Kdezms8ebBCO8kNi78PYc4c3ZMGW4dlZCI/VkbJ6ehJwV8Rg
f8qg0U0FpN28Z7YGLItkIbTcs5Ku149My41FALeVgGw9VPyw19vZqZ8IyhA0
tiuT2FsIqW76JEQeYK4jLI73NkrSA04QrcDSewpCzQgKh1B6jFUwSyh81d2v
nwLRexnk/aW2yZNQd0nJswcjkB0pyFcuhVAC49XiVaReVKGbZcDqbu/15sF1
RWWA0yJv0WB1F3MRgcvu5mlgXftT7/jj0PPQRqwA1F0IELZXuoMnLZwRfCAR
gRFNq9BsL4TG9KGkkydBhHODnTWdVUFZzF9N4+cBoV7sdHeXh+MZhM9JnsB+
yaZyFSKLQ67OlawBlB7huZh9I6cqzKoWy0/itMU5Yf+ffUbCzc/c5EPjOr18
kvQQcYEjPGGhXu1tPXpatQu1/4yTetxKrTil69gdenTeo6rCbT1lMlbHq0+i
u/NqZ5VZYKn8CXBesG3EZDvGAiTVKXWfMiU9isqHUTzOI2a4+3JvlRmeRQM/
IG2sUTXc2X7K5HgAVsbMEKvN68i99UfqP6KbMAHM/PH7lXjgxW3vFwyHtA/g
v79EWXV6O09igugtLQ6w2uRe43GvK386o7mJgwsfduThv2fTznDYyab+8Kbj
jbKVp3/SPpi23+KxjsrUn2S60NTzzn9L02ais/Pxm8TFzpPEuhC3PdAjpcaX
x0ednNl5kkJQj43Vxc3nxcVRhMF3PELRSBNPUiG4f30i5LEaRPfl/v5jZ1W7
sk/SIIpzepwCseqMrv7nyUV1Gq+eMg3qcjXIryPYPW78wSbFKf/971EyjZL7
pOOHw2iCTtOV6PDiJkqz2K+6P3YXW8u67TJGz/bedrdBOByeXUgptSRL/QAP
RQ/urWyqYBrReer7vFRIBdjFljRFV/Q4Sg+E50zsoZQeK69bYGNTCqCoK8+F
D5ey9na3ensNLpyPfDyT3Z71TGB3sVGuu1HiAqWOloFsf2dnKcjqNvLuYgu9
DNeS1nENVPz/Grc6RTFsd7LUGOLsp2noTaPQH3LIU0qcWJELPTK1h88ky6B6
yaVTBzBT9cut/T5HQA6CIJI6Hj9m/sgLCAY8vv0z93sS5uEPpUzAwgQoqH6O
nGflcHeSe9pr/Oq2S10ukpXOTZlpw20rRcIQJd8tgVz7spB5BcM47ONx9UNr
miado7AYmNxRwHpHZgpzram4NC/Q3ls60H7bWyrU3stD7Tvtrd329n5jqL33
3KH23rxQe+/3UPuzhtqBdP4XJW/+L85xsaPuqwTcd34PuP8ecP894F4JuOvJ
9jj0ftt7bPAdC0TPDb8Ln/5XD78X5qlHrb5ZKQTfWzEEv2T8e7G63RD/7iyl
Mu/uNgSOL6jOynUUvfYnFaCWiV9RmRZoD9b95ImwzA3tLRfAMpG9J6NlQWxv
cRyrEtp7IkjzjJru9nKBam3MPAsotQGN7cWh6tx6eSIYZ1mAlf6SFG8AR0b/
U+bFNTDtLDa8TVdK96Wos6Ug3H7Z3VoSQpg21vKrgrh4/9eAyL09N4xHeCNN
FcLFzKAGQuzrifAtk4ews5g71CQiLEd++70GN8syiRvdncWMoi5144mgnXug
+Q6iRVhbnBykO3pOvOk+F2Gutzx0z4k7HczS6lcVsJeLl1QHxKSTZ6G0S49L
gKJ2WgVqsQAQOrO6WW5n7r/abfYznoOxZSUMNHHgxVKBvInYm53esAIT3u1t
NzCQGjAv+ZLAmsVdwklbD6nu8qnAUqTY05R95CfDCJ7c2/uvkTKXcdpy/2YT
KjNCYYuvRLg73e3G/Jv62RT2a/N0FoucOdMpspfnmY/4y7aXlutLeHW1D25b
PU3C7+w3SdC30dQ7AEtYJ2YaHIk22LwAi4UX9q2oc5OSmS+BVldXQX5v+2WD
D33ONECXbJ7EYim3YBKo6D7PFDiSekGOyPmyeXex9JOwLPe2uoBeDsoFQnp3
sSwsgrm6pG6G8xB70g64Cze9WY5JLpaUhY4V9vwE5vjqZYNUr4C/JFdcLEtr
4H8CN2ycwHPEGbt7SwrcZw40LiemGyONhlUvZQTsrWLdPd4c2N5vyJkuQTuf
8+ytYug92qpaFtZrqo7cBOpi6VoB1erwiZC+OcNMqTNNl1XoFktP7kJvx2Qp
gPb2eg2ZB5cXp+I7bmQee0ucB7k4Lbugl+PTe3tNOu3pOczyFIO5UfyeTik3
A7hY7nF3SvpT3OFqoL5scikdZXIUX/SA5qzxxYLP9GWUilW8b72XTWKvDCNd
oaLNkCqgi8VdFVC7yydCe7YEUS6WaGePJMqXL3cahNcyuSLd3hLH5OqSRZaC
7SnZIt3eYpFSky7yWLi+Tr5I7zebL9J7Qr5I75nzRXpfMV9kQTGlOekjUhJj
YQJJoXSGpJC8am+/qk0hKXxMi/HkJJJi6Q5sXkgjKbz+PZHkORJJ6mhKoEEk
/55M8n9BMsl/08wOI2l+tjI5HpvHsVQWB7JKkUr/mlkcTTkcj8zgaLy1e/mE
Dlywt9GsPbhvwz/vZrVq9xJODeRzeT+KO1pKP9vemhMqBQpnngl7msYog7aE
S1r60QKd6vxDV4uA48x4BM96Kvnye1uvGpTdN7FL98UugHoJY1o6WhXs+Tg9
DofuLMmYwemriy7c+yByq0kqSzizCv3ldyFJj0t5JHa2GqzXg8Lth4KGCoyL
LYdiP4LPJUFbXAaEKT1pWuklbC47FUp6e6bVPhMfYgPulgmZ6y5WQNu8mEeS
npCSAkSnpUcVqsUGNJ3T1D0ZQbSUCb271WBCX934014zVEuEUqmHlaDZ26uU
QHk+41QPVtQhaqzToo56Y+mo6jdpszaKvdVN2PkS9MkWbR1mlY3aiqE7x8LF
t7qtXkVzV69cw7uE9atzAK9MFUvE+o/uDKwnN7hP8KzXN7Pkge7IucoGEcwZ
C6QW7jbuq1N3+AGp5yqbUbAYOdYp3UoJDzk85nFPdLEldHdyIdZmW1/Llt8A
t6m4KjpWI9XMEO3R3bZcotgSE6P8Qc98sKlGEZX/TASiG5hXQCoyXZfJpI59
zAQ6fZ8wXg+IIgKvSqfakzfurej/uq8Ar63Ul9ZiTweHp+ayWLqQcVi4+hmN
frndL8Hlo/voFG3gYZQh3eOFjDgm3rlp7pkekKk1C1wmIbmA0aPrGB1ziyZd
1R3eRsGtdcefvk9TysvLfdbdne2Hhw2+/SDx04yhQzjwek3AG9hNBMYgokqm
GlHSm8MXGefySaNO7g8kGIwaPdZ3RMLMP32SWykfHrC+7x1dUSaPcq3675mP
iEBklvCHyfLmykl9ky4bNneRAYOvBtM/Du52ffE53lzalmth2zitvjsMklZf
WEIL/oI//iobKmf3Ldxu8KY19uMkbfNIrc38PdXzhvdEfHhfGD2wPsDCw2ac
/Jk1WnnM0sjT+3YKOG9jo83yR3JnZ2kAeYkw1b6Zt3H6NV/D96BVdPujwX6/
ByKz3+33X/R2K+DQl0wsq3Xa3d7ZhS5f9eq71HwNJtN9WfvFGDhuO3AHHn2z
tVVU0+nnodqwlY1mTQiSaeB+b/gEPuLbtaMY1wnIsxZ6hJ872a8CVQtWaXmW
ByH0/r4AhO5WtxaIKrZKTypgAhGTclpPerBj79wYVQyEC/ffLG2Vu3Sa/vqb
U35qhq/ZmglebT/6fW/K3hz+vjfpo9/35pfam45+jkpmQQL31TdaylM19z+1
juXPkyDIuOAGegqyQVsrlu8ToxGgInAG+mCgK6tLnhUqlmpdh1xfR6P7jRZo
lFd833VRdfDxkmCjtaIigbpN33Ha5s5mUQsC1OUKlwBP3dCfoTfDE40P9biE
PebQkevQ7byocY1JIfeT0uB0Lbp1pfAM1HlzfQK0zkKwAAK6pVrfbT7ybvkg
YFsd8a+kkOIdGj4oeEndHNnznyWF8Ry8rpwjVMoHlTWie+s7pMefuSFgju+d
vwdrbTqLwM4Q0x6gwzU4CHyX7kGPARCu034Fmrulxboz2PsuZx7hcuHRCrxt
PaNJss8iVxHl/nF2bZskJx9RP8qGpNdRSCJEckQKaLkMAer6uOkYBrQeWvoK
desZqaB4ZzWdQKM3PjtP3GEMs4OPbnFgudWe7q/GtIBJZOrcewErr+SNdxNL
/82dscq685vgDWBJEb/GU8w3a1uX4xJ05vZ1fac0UKBQM77H4vLvhTSGsUcU
p62nEzw2Lw4gW9U1ZnJDBxb4OmcMW6H9Iuahbtg49PXhBY78/gjWEduxl0C2
/TpugVBfD05BL/rIGKG0l6buB8xrS9i5MMtHTzY60hGdr9XeG9n6eVKdX4hk
De4Lr3EKm8ofS0+yBB2l3iFQd37ibYpNhDevo3VGpnieRof3DWAGnoXDpHYR
4KM233XPhggtM16yIv3ShR93+koJAx+yHy+l2BEOg8tIcW0YV28wcx19gT6E
/yCDg0mJNcd3yMdeCSPID6YDbZQBtLdu7EdZYtOtGIJMP5sGwE17STbVm5+O
zumaqp9PD87VyREu0jldL4EjJ5hKLLtSU/QMw2UjhmMEihiyEtnMU9zdYDR7
CEZKEbmE+c9rPxyxqQvvhc1tKhhIvUM0kidojMoZrE6o+ULqfSRq1pySsUP3
yaA1icICUTnA8AYwnyFvZvjqHqlDt9IuKVg/ZV8gz+05BCc30JAbh0WGz94y
l5w9+CWuDmbfzYjZyATQ3UB0sO4OULYN0w1EgcxFmBa2Jh8OXoixSXx7k+7F
4FtDAM0ITQLc2shBgR0+y+QttudOeMZZks9Ww8PUyLggCQMcri3BriGzQVqM
Czem/Af02IgXB1nOC+I3edxBu0/IhzOGxw9o1uMF3vt73Vdg148iLyl4XMa6
rXG9aD82TsSJxmMkTJcOzSMAieU7IqYHc42jbEI3wlDgGUBbGwfuJFmD1TtH
hg5vQCQnm071E4ozs3cLVnyogCyHHrJqAygvsAvLm07d5IPDQlqkCoyArkpR
XzaReklXYXYHTbgPSqQ3jMnRY+feCpAQEjPHmdKJYhLTPDjtK3kMw0+81NGT
Xh94Q24KLaJwDXkpGBRCrMcYUSbBzD4tvJQmXzb6kjDue0DJKPoBxjW9IoQb
0hiM0wUG99Cr4sNroGBaMs8sofHR5fOK8SrsTtktiBLjDaKgTDD4rEwxsuD6
2iSCl9qKBwk74znTNGCf3ER3uOq4C5kjpXE2TLPYq1KfQQEr4awK4KyjhFzO
8h3vm9c/ItiwHlewP2DlDWJJqWMkFqiD9APsBgHWBASfwAIieYi+Ks44CwLU
NDxOd8DWNSjHSTMWqrhGZF/COrRP/SlQxQHnMxCCkcOiX7yIYAlti+TIFX8l
BoLm4mtsBaypdb/jgZjgPw0OCd/sddvYVGujOJqZT/GPHNnaN6czP0AcC+ck
LkxC0KMyoZLzvkHiZi32MBNhQaeUHgId6vSwYk9aJWNhudFRb5lYNvlqMb6i
Wjs9iTvGXJWjMo4ghZGAVx8h35UlRTy3A0L/DBPD70UPGLoz0aeVXyBE5g32
smi2S0FRUSremLWm1ZyN0Z5BcVvVq0ibUubGqPyxiPhcadtAKkULBe0sfekt
7adh7ONwLvFasinybtjcAILMZhHvwzX9co0tFrUW7KzRQC9QNSx2uWmKoMgW
pm9mPFta7KK6Ive+ddR8YWIWifElkEm3gNFT/4PH+p4lzMFytO6YWiCtzAoA
6J4JZCNrZLLgZbv0EPsyBiUTp3S0io2MKzEyRKdxnLccO3DVJIgGWOdF1JBb
H/h1buYSY7jxJzeAdlSy+SJEXBsvxp60moVq50EoHvLiLXm0O1gbHTkFJOkx
0wgoNpoAp/EByHh4A7R7FRnlianeMd2lhcYBzIwicoRgyrtC/os6SN6Y9ZB1
uoxNYl/INzcczBgT1GjtZD1n+ql1DmIWgcaUbNB2EzHA2g7D0ZHLK+XPF9wb
o3Dkj2lQUCbY9Bfb0suNP5CSjog8ysHhQBPYYt9qtJJWZc8GZknREI0IjoHQ
qIQT4Mvf5mvC1GDuOKvDoWiXPqgVyBNd3uLMkBmr3FxfmAetUGDovlGRCALu
F2NlEjNEQeWQbkrwED6KK2kDzSEml70CJJG0ekYI10oiDkDd6caaMyZJNPRp
ipot0gEUNLZ+vnyzSaIRSM3H3pP7JPWmsvNv/Rg4cMA9M5i6TyZdinjd3CfU
FHBtdeSHoI4Yia89Gch7zi5Or3SE2GjZSWEZc5uOhCmbV6Yt6xe4YbSStogf
EdMcZyEtG8KixLOFUc7EG7ZFcUSlhyg2kexD2cmo+I6BB+jPECBf+8Q8W+PF
X70QtIOhxMbESlnXsa2gDa9bG4yQqgJmRd9+3Z0Tf9NidBCNyAx39Q18BFqY
pEh2rvBJfIa+HlAnUHuLpkg/pK/pI0MSNcVGrM5kIahDHKJT/5VE4fPG59Lh
jJVMjfhn9fOHWRC0OeK6op8f4GryYtvL12fYRZFc0qOMJkx43+RVzvva3Xq1
V/PNZ3Ysow73rG5l2538627ZoYwUG2rb/MgDOxjJ8RxLrB3QwpmTaGpdn4kx
rmPYONrSrd8422bjGG8E397pqot3V9f2VtGGnWf0SQ4YMBPqvtrv7HU73a2t
ztaL7V0SJ8a/Jn65vR0x9SNWhGkPCXgg3JlBJXK5bu5oBKOQ3aCa8a/7cqFn
FANn3CAxR8vShh7busekhS37ejsnheFIurVoSu1RCIopjy1NWENO1NH5lbDN
ZN5kP9vmR8jy6dRHAHc/TwSwBp0rBwJ3l+IQNAc9ynIcggZu4g8GN8m4vE3x
5+tzh83lVqBKnM+3AI35RzBuibirOFwxqPm4sOLCqOLezpdf3M8QUyww/+25
0cRD4Kk+pfa/sW06cim+MWxUqgMmNYHEnO3vzNGXcj1pNQlgAuv9Fzvbj+D/
yvD/L8D+bTMNSG5KaVfyjhLJMPkMzCgOTglGJSWNrkIH9BgfsmQ8ru/ubjCg
AAtdx/4EEVPA5lcVMJ8pxeQ5BExjpklZwPR+FzB5f88oYB6R6mNl4CBp/y5e
vpx42dHi5SBUtRKmLFd6y8kV8vqmmOVe9vo6TvFF7oz0yd07zgKSBl6K5/WM
f2bGjYD/Ypa4i26RhBwtBf+lkRe5XJt9Dj/AyUXbD9snF8XRjUOAPUXolsPi
X3YaMTRxpTgDjOTSVC3q77Y66vW98XMhoGMK6afiGxkhmIF7D93usP83pnO4
mLODmSEWwoBorYN84j7WsSQXY1HbW2pwj943d5xKEv7AmwDQstzkSsNM9fVU
C7/kgz+baeAoUTjvRVrwpIlUWAqiu+aN+Nti9lytoV1564U++k15HhjzRoTU
n0OU5RcaMYnXej1xrTCFXesr+TndzyYnBaLP4oPRfXefkf1ayYu73aU4bEFi
CkhNvTOdkgi0WxGlNiRoBl44SW+gyfZW7fvlhG8rB6ywj766xH0CU54tdvgc
23znrMh3KLJLPOCEtqJ9zM7ct1zxCyHLplQYi1PnXPSlzUXpCIjOdSz4cm/Q
GIjIwY25OtRf7IYTfUTis+1GHOnXNyen18eXz7oTV96BNvXfBm7Y5ok37RtQ
t7y4jR9SVmwthWdgOZhvtmsyip+TsucsyOfVRF7WEL1Fj/U6xsnVyVE9wfaW
I1iqjICd2FTKB3k+k/Me76D6zVCon/ijpSgUP+SU9jkkKh9t12W9/7eg0V7F
GZPTXz2B5iksNnHuzSFOK+vCRJuu/nKeqFEWc3wd/lLjIIow3Ine/i8XaGqj
gGnnED4rIefdtpP78LcTe5pr+Oc9bdd88GWMw0Wqm7VepCR1trY+3xbZqzEo
8ZagPJXrxI6hEmUXd06Hto46GH4Io7vAG7EnCAZhl6E3+lNr7AaJh5+dYRIo
GCfhB4oq/wdoOFc3kusIttKZP8m8QB3GUWIi/lgRxbuTImZT9vxJOtVIyt1s
Wll6s9iPyPSbZQPYQzfa9tHfUpaGHv8nPxuDHFFn7qb62R9iWcNTIKV/bAJk
njoM3PiDx6V/zlwg5Rv1Hx4CDw/c0DcQGrC4RtBkgvobpvHaQ51GmXrtgdXH
BTKubrzZjccJb43g8UXNrwOMEOrB0uQWc5gYK5t4d4v6xR+CPfUhB8gP05Ef
m28usKwpJkcliRxYxY+wcA6MmkZ0coC/vMxA1XwbZUng3Tv44cQL7dFwgqc+
zF4dZeHAjenBlQdM8TqLQ5kapWl4wxyCIiKOY/+D+p944H4T1vsDEBGsUjTb
VP/7/8Vz4j/fh0NE+mU0hW6PgF4CX0Y+8gbqMIoANjPOyfHVjzKK5DBT/bNp
Xv+MMxJA1caUurx40cKSRLXViD59wgMYbWxDuXKUPUH5M3LBlo8HWYrpddjX
cQb2B6LpEEjFT+iMPaervY1i/x9cNmiLq5JgVkyWRiE5tLWTPk8op6m7WE7V
pUPtR+fOmI70r+Mj/HUjL540iTE9x53EHrcVJz6e5uru7e+9BEv//wBbF+JT
VJEBAA== [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.  Updates of this nature typically
result in more precise language, which is helpful for readers.

Note that our script did not flag any words in particular, but this should
still be reviewed as a best practice. -->

</rfc>