<?xml version="1.0" encoding="utf-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.14 (Ruby 2.6.10) --> version='1.0' encoding='utf-8'?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

<!ENTITY RFC2119 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3031 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3031.xml">
<!ENTITY RFC3032 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3032.xml">
<!ENTITY RFC4385 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4385.xml">
<!ENTITY RFC5920 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5920.xml">
<!ENTITY RFC7274 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7274.xml">
<!ENTITY RFC8174 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC9017 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9017.xml">
<!ENTITY RFC9613 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9613.xml">
<!ENTITY I-D.ietf-mpls-opportunistic-encrypt SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-opportunistic-encrypt.xml">
<!ENTITY I-D.ietf-mpls-1stnibble SYSTEM "https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-1stnibble.xml">
<!ENTITY RFC4928 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4928.xml">
<!ENTITY RFC5714 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5714.xml">
<!ENTITY RFC6790 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml">
<!ENTITY RFC8279 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml">
<!ENTITY RFC8296 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8296.xml">
<!ENTITY RFC8402 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml">
<!ENTITY RFC8491 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8491.xml">
<!ENTITY RFC8662 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8662.xml">
<!ENTITY RFC9088 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9088.xml">
<!ENTITY RFC9089 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9089.xml">
<!ENTITY RFC9522 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9522.xml">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-mpls-mna-fwk-15" number="9789" consensus="true" category="info" submissionType="IETF"> submissionType="IETF" version="3" updates="" obsoletes="" xml:lang="en" symRefs="true" tocInclude="true">

<!-- [rfced] Per use in RFCs 9613, we updated the expansion for MNA from "MPLS
Network Actions" (plural "Actions") to "MPLS Network Action" (singular
"Action"). Note that we also made this change in the abstract and
introduction. If you prefer to use the plural, perhaps we can update as
follows.

Original (document title):
  MPLS Network Actions (MNA) Framework

Current:
  MPLS Network Action (MNA) Framework

Perhaps:
  Framework for MPLS Network Actions (MNAs)
-->

  <front>
    <title abbrev="MNA Framework">MPLS Network Actions Action (MNA) Framework</title>
    <seriesInfo name="RFC" value="9789"/>
    <author initials="L." surname="Andersson" fullname="Loa Andersson">
      <organization>Huawei Technologies</organization>
      <address>
        <email>loa@pi.nu</email>
      </address>
    </author>
    <author initials="S." surname="Bryant" fullname="Stewart Bryant">
      <organization>University of Surrey 5GIC</organization>
      <address>
        <email>sb@stewartbryant.com</email>
      </address>
    </author>
    <author initials="M." surname="Bocci" fullname="Matthew Bocci">
      <organization>Nokia</organization>
      <address>
        <email>matthew.bocci@nokia.com</email>
      </address>
    </author>
    <author initials="T." surname="Li" fullname="Tony Li">
      <organization>Juniper Networks</organization>
      <address>
        <email>tony.li@tony.li</email>
      </address>
    </author>
    <date year="2024" month="December" day="27"/>

    <workgroup>MPLS Working Group</workgroup> year="2025" month="May"/>
    <area>RTG</area>
    <workgroup>mpls</workgroup>

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

<keyword>example</keyword>

    <abstract>
      <t>This document describes an architectural framework for the MPLS
      Network Actions Action (MNA) technologies.  MNA technologies are used to
      indicate actions that impact the forwarding or other processing (such as
      monitoring) of the packet along the Label Switched Path (LSP) of the
      packet and to transfer any additional data needed for these actions.</t>

<t>The
      <t>This document provides the foundation for the development of a common
      set of network actions and information elements supporting additional
      operational models and capabilities of MPLS networks.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction"><name>Introduction</name> anchor="introduction">
      <name>Introduction</name>
      <t>This document describes an architectural framework for the MPLS
Network Actions Action (MNA) technologies.  MNA technologies are used to
indicate actions for Label Switched Paths (LSPs) and/or MPLS packets
and to transfer data needed for these actions.</t>

<t>The
      <t>This document provides the foundation for the development of a common
set of network actions and information elements supporting additional
operational models and capabilities of MPLS networks.  MNA solutions
derived from this framework are intended to address the requirements
found in <xref target="RFC9613"/>. In addition, MNA may
support actions that overlap existing MPLS functionality. This may be
beneficial for numerous reasons, such as making it more efficient to
combine existing functionality and new functions in the same MPLS
packet.</t>

<!-- [rfced] Will readers understand which items are part of the series here?
Does one of the following accurately convey the intended meaning?

Original:
   These might include
   load-balancing a packet given its entropy, whether or not to perform
   fast-reroute on a failure, and whether or not a packet has metadata
   relevant to the forwarding actions along the path.

Perhaps (entropy, whether or not..., whether or not...):
   These might include
   load-balancing a packet given its entropy, whether or not
   fast-reroute is performed on a failure, and whether or not a packet has metadata
   relevant to the forwarding actions along the path.

Or (load-balancing, indicating, indicating):
   These might include
   load-balancing a packet given its entropy, indicating whether or not to perform
   Fast Reroute on a failure, and indicating whether or not a packet has metadata
   relevant to the forwarding actions along the path.
-->

<t>MPLS forwarding actions are instructions to MPLS routers to apply
additional actions when forwarding a packet. These might include
load-balancing a packet given its entropy, whether or not to perform
fast-reroute
Fast Reroute on a failure, and whether or not a packet has metadata
relevant to the forwarding actions along the path.</t>
      <t>This document generalizes the concept of MPLS "forwarding actions" into to
"network actions" to that include any action that an MPLS router is
requested to take on the packet. That includes Network actions include any MPLS forwarding
action,
actions but may also include other operations (such as security functions,
OAM
Operations, Administration, and Maintenance (OAM) procedures, etc.) that are not directly related to forwarding of
the packet. MPLS network actions are always triggered by an MNA
packet but may have implications for subsequent traffic, including
non-MNA packets, as discussed in <xref target="State"/>.</t>
      <t>MNA technologies may redefine the semantics of the Label, Traffic
Class (TC), and Time to Live (TTL) fields in an MPLS Label Stack Entry
(LSE) within a Network Action Sub-Stack (NAS).</t>
      <section anchor="REQ-lang"><name>Requirement anchor="REQ-lang">
        <name>Requirements Language</name>

<t>The

        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", "<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 "OPTIONAL" "<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.
These words may also appear in this document in
lower case as plain English words, absent their normative meanings.</t>
        </t>

        <t>Although this is an Informational document, these conventions are
applied to achieve clarity in the requirements that are presented.</t>
      </section>

        <section anchor="terminology"><name>Terminology</name>

<section anchor="normative-definitions"><name>Normative anchor="normative-definitions">
          <name>Normative Definitions</name>
<!-- [rfced] We have a few questions about the similar text below from
Sections 1.2 and 2.

a) Please confirm that NSI is the correct acronym for "Network Action
Sub-Stack Indicator". Should it be "NASI" rather than "NSI" to correspond with
"Network Action Indicator (NAI)" and "Network Action Sub-Stack (NAS)"?

b) Is the NSI the special-purpose label? If so, may we update the definition
below as follows?

c) The second definition below mentions "MNA label", but the first does
not. Also, one definition uses "special label", and the other uses
"special-purpose label". Are any updates needed?

Original:
   *  Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS
      contains a special label that indicates the start of the NAS.
   ...
   *  Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS
      contains a special purpose label, called the MNA label, which is
      used to indicate the start of a network action sub-stack.

Perhaps:
   Network Action Sub-Stack Indicator (NASI):  The special-purpose label contained
      in the first LSE in the NAS. The NSI, also called the MNA label, indicates
      the start of the NAS.
   ...
   *  Network Action Sub-Stack Indicator (NASI): The special-purpose label contained
      in the first LSE in the NAS. The NSI, also called the MNA label, indicates
      the start of the NAS.
-->
          <t>This document adopts the definitions of the following terms and
abbreviations from <xref target="RFC9613"/> as
normative: "Network Action", "Network Action Indication Indicator (NAI)",
"Ancillary Data (AD)", and "Scope".</t>
          <t>In addition, this document also defines the following terms:</t>

<t><list style="symbols">
  <t>Network
          <dl spacing="normal" newline="false">
            <dt>Network Action Sub-Stack (NAS): A (NAS):</dt><dd>A set of related,
            contiguous LSEs in the MPLS label stack for carrying information
            related to network actions. The Label, TC, and TTL values in the
            LSEs in the NAS may be redefined, but the meaning of the S bit is unchanged.</t>
  <t>Network
            unchanged.</dd>
            <dt>Network Action Sub-Stack Indicator (NSI): The (NSI):</dt><dd>The first
            LSE in the NAS contains a special label that indicates the start
            of the NAS.</t>
</list></t> NAS.</dd>
          </dl>
        </section>
        <section anchor="abbreviations"><name>Abbreviations</name>

<texttable title="Abbreviations" anchor="abbreviations">
          <name>Abbreviations</name>
          <table anchor="Tab-apprev">
      <ttcol align='left'>Abbreviation</ttcol>
      <ttcol align='left'>Meaning</ttcol>
      <ttcol align='left'>Reference</ttcol>
      <c>AD</c>
      <c>Ancillary Data</c>
      <c><xref target="RFC9613"/></c>
      <c>BIER</c>
      <c>Bit
            <name>Abbreviations</name>
            <thead>
              <tr>
                <th align="left">Abbreviation</th>
                <th align="left">Meaning</th>
                <th align="left">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="left">AD</td>
                <td align="left">Ancillary Data</td>
                <td align="left">
                  <xref target="RFC9613"/></td>
              </tr>
              <tr>
                <td align="left">BIER</td>
                <td align="left">Bit Index Explicit Replication</c>
      <c><xref target="RFC8279"/></c>
      <c>BoS</c>
      <c>Bottom of Stack</c>
      <c><xref target="RFC6790"/></c>
      <c>bSPL</c>
      <c>Base Special Purpose Label</c>
      <c><xref target="RFC9017"/></c>
      <c>ECMP</c>
      <c>Equal Cost Multipath</c>
      <c><xref target="RFC9522"/></c>
      <c>EL</c>
      <c>Entropy Label</c>
      <c><xref target="RFC6790"/></c>
      <c>ERLD</c>
      <c>Entropy Replication</td>
                <td align="left">
                  <xref target="RFC8279"/></td>
              </tr>
              <tr>
                <td align="left">BoS</td>
                <td align="left">Bottom of Stack</td>
                <td align="left">
                  <xref target="RFC6790"/></td>
              </tr>
              <tr>
                <td align="left">bSPL</td>
                <td align="left">Base Special-Purpose Label</td>
                <td align="left">
                  <xref target="RFC9017"/></td>
              </tr>
              <tr>
                <td align="left">ECMP</td>
                <td align="left">Equal-Cost Multipath</td>
                <td align="left">
                  <xref target="RFC9522"/></td>
              </tr>
              <tr>
                <td align="left">EL</td>
                <td align="left">Entropy Label</td>
                <td align="left">
                  <xref target="RFC6790"/></td>
              </tr>
              <tr>
                <td align="left">ERLD</td>
                <td align="left">Entropy Readable Label Depth</c>
      <c><xref target="RFC8662"/></c>
      <c>eSPL</c>
      <c>Extended Special Purpose Label</c>
      <c><xref target="RFC9017"/></c>
      <c>HBH</c>
      <c>Hop Depth</td>
                <td align="left">
                  <xref target="RFC8662"/></td>
              </tr>
              <tr>
                <td align="left">eSPL</td>
                <td align="left">Extended Special-Purpose Label</td>
                <td align="left">
                  <xref target="RFC9017"/></td>
              </tr>
              <tr>
                <td align="left">HbH</td>
                <td align="left">Hop by hop</c>
      <c>In Hop</td>
                <td align="left">In the MNA context, this document.</c>
      <c>I2E</c>
      <c>Ingress to Egress</c>
      <c>In document.</td>
              </tr>
              <tr>
                <td align="left">I2E</td>
                <td align="left">Ingress to Egress</td>
                <td align="left">In the MNA context, this document.</c>
      <c>IGP</c>
      <c>Interior document.</td>
              </tr>
              <tr>
                <td align="left">IGP</td>
                <td align="left">Interior Gateway Protocol</c>
      <c>&#160;</c>
      <c>ISD</c>
      <c>In-stack data</c>
      <c><xref target="RFC9613"/></c>
      <c>LSE</c>
      <c>Label Protocol</td>
                <td align="left"></td>
              </tr>
              <tr>
                <td align="left">ISD</td>
                <td align="left">In-Stack Data</td>
                <td align="left">
                  <xref target="RFC9613"/></td>
              </tr>
              <tr>
                <td align="left">LSE</td>
                <td align="left">Label Stack Entry</c>
      <c><xref target="RFC3032"/></c>
      <c>MNA</c>
      <c>MPLS Entry</td>
                <td align="left">
                  <xref target="RFC3032"/></td>
              </tr>
              <tr>
                <td align="left">MNA</td>
                <td align="left">MPLS Network Actions</c>
      <c><xref target="RFC9613"/></c>
      <c>MSD</c>
      <c>Maximum Action</td>
                <td align="left">
                  <xref target="RFC9613"/></td>
              </tr>
              <tr>
                <td align="left">MSD</td>
                <td align="left">Maximum SID Depth</c>
      <c><xref target="RFC8491"/></c>
      <c>NAI</c>
      <c>Network Depth</td>
                <td align="left">
                  <xref target="RFC8491"/></td>
              </tr>
              <tr>
                <td align="left">NAI</td>
                <td align="left">Network Action Indicator</c>
      <c><xref target="RFC9613"/></c>
      <c>NAS</c>
      <c>Network Indicator</td>
                <td align="left">
                  <xref target="RFC9613"/></td>
              </tr>
              <tr>
                <td align="left">NAS</td>
                <td align="left">Network Action Sub-Stack</c>
      <c>This document</c>
      <c>NSI</c>
      <c>Network Sub-Stack</td>
                <td align="left">This document</td>
              </tr>
              <tr>
                <td align="left">NSI</td>
                <td align="left">Network Action Sub-Stack Indicator</c>
      <c>This document</c>
      <c>PSD</c>
      <c>Post-stack data</c>
      <c><xref Indicator</td>
                <td align="left">This document</td>
              </tr>
              <tr>
                <td align="left">PSD</td>
                <td align="left">Post-Stack Data</td>
                <td align="left">
                  <xref target="RFC9613"/> and <xref target="PSD"/></c>
      <c>RLD</c>
      <c>Readable target="PSD"/></td>
              </tr>
              <tr>
                <td align="left">RLD</td>
                <td align="left">Readable Label Depth</c>
      <c>This document</c>
      <c>SID</c>
      <c>Segment Identifier</c>
      <c><xref target="RFC8402"/></c>
      <c>SPL</c>
      <c>Special Purpose Label</c>
      <c><xref target="RFC9017"/></c>
</texttable>

</section> Depth</td>
                <td align="left">This document</td>
              </tr>
              <tr>
                <td align="left">SID</td>
                <td align="left">Segment Identifier</td>
                <td align="left">
                  <xref target="RFC8402"/></td>
              </tr>
              <tr>
                <td align="left">SPL</td>
                <td align="left">Special-Purpose Label</td>
                <td align="left">
                  <xref target="RFC9017"/></td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>

    <section anchor="structure"><name>Structure</name> anchor="structure">
      <name>Structure</name>

<!-- [rfced] We see that "sub-stacks" (plural) is used early in the sentence
and "sub-stack" (singular) is used later. Is the current correct, or
should both instances be either plural or singular?

Original:
   A solution must specify where in the label stack the network
   actions sub-stacks occur, if and how frequently they should be
   replicated within the label stack, and how the network action sub-
   stack and post-stack data are encoded.
-->

      <t>An MNA solution specifies one or more network actions to apply to an
MPLS packet.  These network actions and their ancillary data may be carried in
sub-stacks within the MPLS label stack and/or post-stack
data.  A solution must specify where in the label stack the network
actions
action sub-stacks occur, occur in the label stack, if and how frequently they should be
replicated within the label stack, and how the network action
sub-stack and post-stack data are encoded.</t>
      <t>It seems highly likely that some ancillary data will be needed at many
points along an LSP.  Replication of ancillary data throughout the
label stack would be highly inefficient, as would a full rewrite of
the label stack at each hop, so hop; thus, MNA allows encoding of network actions
and ancillary data deeper in the label stack, requiring
implementations to look past the first LSE.  Processing of the label
stack past the top of stack top-of-stack LSE was first introduced with the Entropy
Label (EL) <xref target="RFC6790"/>.</t>
      <t>A network action sub-stack contains:</t>

<t><list style="symbols">
      <ul spacing="normal">
        <li>
          <t>Network Action Sub-Stack Indicator (NSI): The first LSE in the NAS
contains a special purpose special-purpose label, called the MNA label, which
is used to indicate the start of a network action sub-stack.</t>
        </li>
        <li>
          <t>Network Action Indicators (NAI): (NAIs): Optionally, a set of indicators that
describes the set of network actions. If the set of indicators is not
in the sub-stack, a solution could encode them in post-stack data. A
network action is said to be present if there is an indicator in the
packet that invokes the action.</t>
        </li>
        <li>

          <t>In-Stack Data (ISD): A set of zero or more LSEs that carry ancillary data
for the network actions that are present. Network action indicators
are not considered ancillary data.</t>
</list></t>
        </li>
      </ul>
      <t>Each network action present in the network action sub-stack may have
zero or more LSEs of in-stack data. The ordering of the in-stack data
LSEs corresponds to the ordering of the network action indicators. The
encoding of the in-stack data, if any, for a network action must be
specified in the document that defines the network action. In-stack
data may be referenced by multiple network actions.</t>
      <t>As an example, in-stack data might look like the following label stack with an
embedded NAS:</t>

<figure><artwork><![CDATA[

<figure>
  <name>A Label Stack with an Embedded Network Action Sub-Stack</name>
      <artwork><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |0|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |0|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |0|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Network Action Sub-Stack     |0|               |
   ~                                                               ~
   |         Network Action Sub-Stack continued  |0|               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |0|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |1|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Payload                             |

  Figure 1:  A label stack with an embedded Network Action Sub-Stack
]]></artwork></figure>
]]></artwork>
</figure>
      <t>Certain network actions may also specify that data is carried after
the label stack. This is called post-stack data. The encoding of the
post-stack data, if any, for a network action must be specified in the
document that defines the network action.  If multiple network actions
are present and have post-stack data, the ordering of their post-stack
data corresponds to the ordering of the network action indicators.</t>
<!-- [rfced] This sentence includes two instances of "post-stack data". Please
comfirm that this is correct.

Original:
   As an example, post-stack data might appear as a label stack followed
   by post-stack data, followed by the payload:

Perhaps:
   As an example, post-stack data might appear in a label stack, followed
   by the payload:
-->

<t>As an example, post-stack data might appear as a label stack followed by post-stack data, followed by the payload:</t>

<figure><artwork><![CDATA[

<figure>
  <name>A Label Stack Followed by Post-Stack Data</name>
      <artwork><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |0|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |1|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Post-stack data                       Post-Stack Data                         |
   ~                                                               ~
   |                  Post-stack data                  Post-Stack Data continued                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Payload                             |

         Figure 2:  A label stack followed by post-stack data
]]></artwork></figure>
]]></artwork>
</figure>
      <t>A solution must specify the order for network actions to be
applied to the packet for the actions to have consistent
semantics. Since there are many possible orderings, especially with
bit catalogs (<xref target="Catalogs"/>), the solution must provide an unambiguous
specification. The precise semantics of an action are dependent on the
contents of the packet, including any ancillary data, and the state of
the router.</t>
<!-- [rfced] Would updating "not more than one" to simply "one" or "a single"
improve readability of this sentence?

Original:
   This document assumes that the MPLS WG will select not more than one
   solution for the encoding of ISD and not more than one solution for
   the encoding of PSD.

Perhaps:
   This document assumes that the MPLS WG will select a single
   solution for the encoding of ISD and a single solution for
   the encoding of PSD.
-->

<t>This document assumes that the MPLS WG will select not more than one
solution for the encoding of ISD and not more than one solution for
the encoding of PSD.</t>
      <section anchor="scopes"><name>Scopes</name> anchor="scopes">
        <name>Scopes</name>
        <t>A network action may need to be processed by every node along the
path,
path or some subset of the nodes along its path. Some of the scopes
that an action may have are:</t>

<t><list style="symbols">
  <t>Hop-by-hop (HBH):
        <ul spacing="normal">
          <li>
            <t>Hop by Hop (HbH): Every node along the path will perform the action.</t>
  <t>Ingress-to-Egress
          </li>
          <li>
            <t>Ingress to Egress (I2E): Only the last node on the path will perform
the action.</t>
          </li>
          <li>
            <t>Select: Only specific nodes along the path will perform the action.</t>
</list></t>
          </li>
        </ul>
        <t>If a solution supports the select scope, it must describe how it
specifies the set of nodes to perform the actions.</t>

<t>This framework does not place any constraints on the scope of, or the
ancillary data for, a network action.  Any network action may appear
in any scope or combination of scopes, may have no ancillary data, and
may require in-stack data, data and/or post-stack data.  Some combinations
may be sub-optimal, but this framework does not restrict the combinations
in an MNA solution.  A specific MNA solution may define such
constraints.</t>
      </section>
      <section anchor="partial-processing"><name>Partial anchor="partial-processing">
        <name>Partial Processing</name>
        <t>As described in <xref target="RFC3031"/>, legacy devices that do not recognize the
MNA label will discard the packet if the top label is the MNA label.</t>
        <t>Devices that do recognize the MNA label might not implement all of the
network actions that are present. A solution must specify how
unrecognized network actions that are present should be handled.</t>
        <t>One alternative is that an implementation should stop processing
network actions when it encounters an unrecognized network
action. Subsequent present network actions would not be
applied. The result is dependent on the solution's order of
operations.</t>
        <t>Another alternative is that an implementation should drop any packet
that contains any unrecognized present network actions.</t>
        <t>A third alternative is that an implementation should perform all
recognized present network actions, actions but ignore all unrecognized
present network actions.</t>
        <t>Other alternatives may also be possible. The solution should specify the
alternative adopted.</t>
        <t>In some solutions, an indication may be provided in the packet or in
the action as to how the forwarder should proceed if it does not
recognize the action. Where an action needs to be processed at every hop,
it is recommended that care be taken not to construct an LSP that
traverses nodes that do not support that action. It is recognised that recognized that,
in some circumstances circumstances, it may not be possible to construct an LSP that
avoids such nodes, such as when a network is re-converging reconverging
following a failure or when IPFRR IP Fast Reroute (IPFRR) <xref target="RFC5714"/> is taking place.</t>
      </section>
      <section anchor="signaling"><name>Signaling</name> anchor="signaling">
        <name>Signaling</name>

	<t>A node that wishes to make use of MNA and apply network actions to a
packet must understand the nodes that the packet will transit, whether
or not the nodes support MNA, and the network actions that are to be
invoked. These capabilities are presumed to be signaled by protocols
that are out-of-scope out of scope for this document and are presumed to have
per-network action
per-network-action granularity. If a solution requires alternate
signaling, it must specify that explicitly.</t>
        <section anchor="readable-label-depth"><name>Readable anchor="readable-label-depth">
          <name>Readable Label Depth</name>
          <t>Readable Label Depth (RLD) is defined as the number of LSEs, starting
from the top of the stack, that a router can read in an incoming MPLS
packet with no performance impact.  <xref target="RFC8662"/> introduced Entropy
Readable Label Depth (ERLD). Readable Label Depth is the same concept,
but it is generalized and not specifically associated with the Entropy Label
(EL) or MNA.</t>
          <t>ERLD is not redundant with RLD because ERLD specifically
specifies a value of zero if a system does not support the Entropy
Label. Since a system could reasonably support MNA or other MPLS
functions and needs to advertise an RLD value but not support the
Entropy Label, another advertised value is required.</t>

<!-- [rfced] FYI - We updated the parenthetical as shown below.

Original:
   A node SHOULD use signaling
   (e.g., [RFC9088], [RFC9089]) to determine this.

Updated:
   A node SHOULD use signaling
   (e.g., the signaling described in [RFC9088] and [RFC9089]) to determine this.
-->

<t>A node that pushes an NAS onto the label stack is responsible for
ensuring that all nodes that are expected to process the NAS will have
the entire NAS within their RLD. A node SHOULD <bcp14>SHOULD</bcp14> use signaling (e.g., the signaling described in
<xref target="RFC9088"/>, target="RFC9088"/> and <xref target="RFC9089"/>) to determine this.  An exception might be,
for example, when the node has out-of-band knowledge that all nodes
along the path do not have RLD limitations and thus could avoid the
unnecessary overhead of using signaling.</t>
          <t>Per <xref target="RFC8662"/>, a node that does not support EL will advertise a
value of zero for its ERLD, so advertising ERLD alone does not suffice
in all cases. A node MAY <bcp14>MAY</bcp14> advertise both ERLD and RLD RLD, and SHOULD it <bcp14>SHOULD</bcp14> do so
if its ERLD and RLD values are different. Again, if a node has
out-of-band knowledge that all nodes do not have RLD limitations, then
signaling can be avoided. If a node's ERLD and RLD values are the
same, it MAY <bcp14>MAY</bcp14> only advertise ERLD for efficiency reasons. If a node
supports MNA but does not support EL, then it SHOULD <bcp14>SHOULD</bcp14> advertise RLD
unless it has out-of-band knowledge that no nodes in the domain have
RLD restrictions.</t>
          <t>RLD is advertised by an IGP MSD-Type value of (TBA) 3 and MAY <bcp14>MAY</bcp14> be
advertised as a Node Maximum Segment Identifier (SID) Depth (MSD), MSD,
Link MSD, or both.</t>

<t>An

<!-- [rfced] Should the text introducing the list indicate if the value is
"from one of the following" or "each of the following"? Or will readers
understand?

Original:
   An MNA node MUST use the RLD determined by selecting the first
   advertised non-zero value from:

   *  The RLD advertised for the link.

   *  The RLD advertised for the node.

   *  The non-zero ERLD for the node.

Perhaps:
   An MNA node MUST use the RLD determined by selecting the first
   advertised non-zero value from one of the following:

   *  The RLD advertised for the link

   *  The RLD advertised for the node

   *  The non-zero ERLD for the node

Or:
   An MNA node MUST use the RLD determined by selecting the first
   advertised non-zero value from each of the following:

   *  The RLD advertised for the link

   *  The RLD advertised for the node

   *  The non-zero ERLD for the node
-->

<t>An MNA node <bcp14>MUST</bcp14> use the RLD determined by selecting the first
advertised non-zero value from:</t>

<t><list style="symbols">
          <ul spacing="normal">
            <li>
              <t>The RLD advertised for the link.</t> link</t>
            </li>
            <li>
              <t>The RLD advertised for the node.</t> node</t>
            </li>
            <li>
              <t>The non-zero ERLD for the node.</t>
</list></t> node</t>
            </li>
          </ul>
          <t>A node's RLD is a function of its hardware capabilities and is not
expected to depend on the specifics of the MNA solution.</t>
        </section>
      </section>
      <section anchor="State"><name>State</name> anchor="State">
        <name>State</name>
        <t>A network action can affect the state stored in the network. This
implies that a packet may affect how subsequent packets are
handled. In particular, one packet may affect subsequent packets in
the same LSP.</t>
      </section>
    </section>
    <section anchor="carry"><name>Encoding</name> anchor="carry">
      <name>Encoding</name>
      <t>Several possible ways to encode NAIs have been proposed.  This
section summarizes the proposals and some considerations for
the various alternatives.</t>

<t>When network actions are carried in the MPLS label stack, then
regardless of their type, they are represented by a set of LSEs termed
a network action sub-stack Network Action Sub-Stack (NAS).  An NAS consists of a special label,
optionally followed by LSEs that specify which network actions are to
be performed on the packet and the in-stack ancillary data for each
indicated network action. Different network actions may be placed
together in one NAS or may be carried in different sub-stacks.</t>
      <t><xref target="RFC9613"/> requires that a solution not add unnecessary
      LSEs to the sub-stack (Section 3.1, (see requirement
9). 9 in <xref section="3.1" sectionFormat="of"
      target="RFC9613"/>). Accordingly, solutions should also
      make efficient use of the bits within the sub-stack (except the S-bit),
      as inefficient use of the bits could result in the addition of
      unnecessary LSEs.</t>
      <section anchor="NAI"><name>The anchor="NAI">
        <name>The MNA Label</name>
        <t>The first LSE in a network action sub-stack contains a special label
that indicates a network action sub-stack. A solution has several
choices for this special label.</t>
        <section anchor="existing-base-spl"><name>Existing anchor="existing-base-spl">
          <name>Existing Base SPL</name>
          <t>A solution may reuse an existing Base SPL (bSPL). If it elects to do
so, it must explain how the usage is backward compatible, including
in the case where there is ISD.</t>
          <t>If an existing inactive bSPL is selected that will not be
backward compatible, then it must first be retired per
<xref target="RFC7274"/> and then reallocated.</t>
        </section>
        <section anchor="new-base-spl"><name>New anchor="new-base-spl">
          <name>New Base SPL</name>
          <t>A solution may select a new bSPL.</t>
        </section>
        <section anchor="new-extended-spl"><name>New anchor="new-extended-spl">
          <name>New Extended SPL</name>
          <t>A solution may select a new Extended SPL (eSPL). If it elects to do so, it must
address the requirement for the minimal number of LSEs.</t>
        </section>
        <section anchor="user-defined-label"><name>User-Defined anchor="user-defined-label">
          <name>User-Defined Label</name>
          <t>A solution may allow the network operator to define the label that
indicates the network action sub-stack. This creates management
overhead for the network operator to coordinate the use of this label
across all nodes on the path using management or signaling
protocols. The user-defined label could be network-wide or
LSP-specific.  If a solution elects to use a user-defined label, the
solution should justify this overhead.</t>
        </section>
      </section>
      <section anchor="tc-and-ttl"><name>TC anchor="tc-and-ttl">
        <name>TC and TTL</name>

	<t>In the first LSE of the network action sub-stack, only the 20 bits of
the Label Value value and the Bottom of Stack bit are used by the NSI; the TC field
(3 bits) and the TTL (8 bits) are not used.  This could leave 11 bits
that could be used for MNA purposes.</t>
        <section anchor="tc-and-ttl-retained"><name>TC anchor="tc-and-ttl-retained">
          <name>TC and TTL retained</name> Retained</name>
          <t>If the solution elects to retain the TC and TTL fields, then the first
LSE of the network action sub-stack would appear as described in <xref target="RFC3032"/>:</t>

<figure><artwork><![CDATA[

<figure>
  <name>A Label Stack Entry</name>
          <artwork><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Label                   | TC  |S|      TTL      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>

<!-- [rfced] Each definition below includes a number of bits except for
TTL. Should the TTL definition also include a number of bits?

Original:
   Label:  Label value, 20 bits
   TC:  Traffic Class, 3 bits
   S:  Bottom of Stack, 1 bit
   TTL:  Time To Live

                    Figure 3: A

Perhaps:
   Label:  Label Stack Entry
]]></artwork></figure> value, 20 bits
   TC:  Traffic Class, 3 bits
   S:  Bottom of Stack, 1 bit
   TTL:  Time To Live, 8 bits
-->

<dl spacing="compact" newline="false">
  <dt>Label:</dt><dd>Label value, 20 bits</dd>
  <dt>TC:</dt><dd>Traffic Class, 3 bits</dd>
  <dt>S:</dt><dd>Bottom of Stack, 1 bit</dd>
  <dt>TTL:</dt><dd>Time To Live</dd>
</dl>

          <t>Further LSEs would be needed to encode NAIs.  If a solution elects to
retain these the TC and TTL fields, it must address the requirement for the minimal
number of LSEs.</t>
        </section>
        <section anchor="tc-and-ttl-repurposed"><name>TC anchor="tc-and-ttl-repurposed">
          <name>TC and TTL Repurposed</name>
          <t>If the solution elects to reuse the TC and TTL fields, then the first
LSE of the network action sub-stack would appear as:</t>

<figure><artwork><![CDATA[ as follows:</t>

<!-- [rfced] Figure 4 does not have a title; all the other figures do. What
title should we add for Figure 4? Also, would it be helpful to revise the
title of Figure 3 to be more descriptive?

Current:
  Figure 3: A Label Stack Entry
  Figure 4

Perhaps:
  Figure 3: A Label Stack Entry with TC and TTL Retained
  Figure 4: A Label Stack Entry with TC and TTL Repurposed
-->

<figure>
  <name></name>
          <artwork><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Label                  |x x x|S|x x x x x x x x|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Label:  Label
]]></artwork>
</figure>

<dl spacing="compact" newline="false">
  <dt>Label:</dt><dd>Label value, 20 bits
                 x:      Bit bits</dd>
  <dt>x:</dt><dd>Bit available for use in solution definition
                 S:      Bottom definition</dd>
  <dt>S:</dt><dd>Bottom of Stack, 1 bit
]]></artwork></figure> bit</dd>
</dl>
          <t>The solution may use more LSEs to contain NAIs.  If a solution elects
to use more LSEs LSEs, it must address the requirement for the minimal
number of LSEs.</t>
        </section>
      </section>
      <section anchor="length-of-the-nas"><name>Length anchor="length-of-the-nas">
        <name>Length of the NAS</name>
        <t>A solution must have a mechanism (such as an indication of the length
   of the NAS) to enable an implementation to find the end of the NAS.
   This must be easily processed even by implementations that do not
   understand the full contents of the NAS.  Two options are described
   below,
   below; other solutions may be possible.</t>
        <section anchor="lastcontinuation-bits"><name>Last/Continuation anchor="lastcontinuation-bits">
          <name>Last/Continuation Bits</name>
          <t>A solution may use a bit per LSE to indicate whether or not the NAS continues
into the next LSE or not. LSE. The bit may indicate continuation by being
set or by being clear. The overhead of this approach is one bit per
LSE and has the advantage that it can effectively encode an
arbitrarily sized NAS. This approach is efficient if the NAS is small.</t>
        </section>
        <section anchor="length-field"><name>Length anchor="length-field">
          <name>Length Field</name>
          <t>A solution may opt to have a fixed size length fixed-size Length field at a fixed
location within the NAS. The fixed size of the length Length field may not be
large enough to support all possible NAS contents. This approach may
be more efficient if the NAS is longer long, but not longer than can be
described by the length Length field.</t>

<t>Advice from one

<t>One hardware designer recommends a length Length field as this
minimizes branching in the logic.</t>
        </section>
      </section>
      <section anchor="encoding-of-scopes"><name>Encoding anchor="encoding-of-scopes">
        <name>Encoding of Scopes</name>
        <t>A solution may choose to explicitly encode the scope of each action
contained in a network action sub-stack. For example, a NAS might
contain Action A (HBH), (HbH), Action B (HBH), (HbH), and Action C (HBH). (HbH).  A
solution may alternately choose to have the scope encoded implicitly,
based on the actions present in the network action sub-stack. For
example, a NAS might contain HBH scope actions: the following actions with HbH scope: A, B, and C.  This choice
may have performance implications as an implementation might have to
parse the network actions that are present in a network action
sub-stack only to discover that there are no actions for it to
perform.</t>
        <t>For example, suppose that an NAS is embedded in a label stack at a
depth of 6 six LSEs and that the NAS contains 3 three actions, each with Select
scope. These actions are not applicable at the current node and should
be ignored. If the scope is encoded explicitly with each action, then
an implementation must parse each action. However, if the scope is
encoded as part of the NAS, then an implementation need only needs to parse the
start of the NAS and need not parse individual actions.</t>
        <t>Solutions need to consider the order of scoped NAIs and their
associated AD within individual sub-stacks and the order of per-scope
sub-stacks
sub-stacks, so that network actions and the AD can be most
readily found and need not be processed by nodes that are not required
to handle those actions.</t>
      </section>
      <section anchor="INDEX"><name>Encoding anchor="INDEX">
        <name>Encoding a Network Action</name>
        <t>Two options for encoding NAIs are described below, below; other solutions may
be possible. Any solution should allow the encoding of an arbitrary
number of NAIs.</t>
        <section anchor="Catalogs"><name>Bit anchor="Catalogs">
          <name>Bit Catalogs</name>
          <t>A solution may opt to encode the set of network actions as a list of
bits, sometimes known as a catalog. The solution must provide a
mechanism to determine how many LSEs are devoted to the catalog when
the NAIs are carried in-stack. A set bit in the catalog would indicate
that the corresponding network action is present.</t>
          <t>Catalogs are efficient if the number of present network actions is
relatively high and if the size of the necessary catalog is small. For
example, if the first 16 actions are all present, a catalog can encode
this in 16 bits. However, if the number of possible actions is large,
then a catalog can become inefficient. Selecting only one action that
is the 256th action would require a catalog of 256 bits, which would
require more than one LSE when the NAIs are carried in-stack.</t>
          <t>A solution may include a bit remapping bit-remapping mechanism so that a given
domain may optimize for its commonly used actions.</t>
        </section>
        <section anchor="operation-codes"><name>Operation anchor="operation-codes">
          <name>Operation Codes</name>
          <t>A solution may opt to encode the set of present network actions as a
list of operation codes (opcodes).  Each opcode is a fixed number of
bits. The size of the opcode bounds the number of network actions
that the solution can support.</t>
          <t>Opcodes are efficient if there are only one or two active network
actions. For example, if an opcode is 8 bits, then two active network
actions could be encoded in 16 bits. However, if 16
actions are required, then opcodes would consume 128 bits. Opcodes are
efficient at encoding a large number of possible actions. If only
the 256th action is to be selected, that still requires 8 bits.</t>
        </section>
      </section>
      <section anchor="PSD"><name>Encoding anchor="PSD">
        <name>Encoding of Post-Stack Data</name>

<!-- [rfced] Should "NAI" here be plural (i.e., "NAIs")?

Original:
   A solution may carry some NAI and AD as PSD.

Perhaps (change to "NAIs"):
   A solution may carry some NAIs and AD as PSD.

Or (remove "some"):
   A solution may carry NAI and AD as PSD.
-->

	<t>A solution may carry some NAI and AD as PSD. For ease of parsing, all
AD should be co-located with its NAI.</t>
        <t>If there are multiple instances of post-stack data, they should occur
in the same order as their relevant network action sub-stacks and then
in the same order as their relevant network actions occur within the
network action sub-stacks.</t>
        <section anchor="first-nibble-considerations"><name>First anchor="first-nibble-considerations">
          <name>First Nibble Considerations</name>
          <t>The first nibble after the label stack has been used to convey
   information in certain cases <xref target="RFC4385"/>. A consolidated view of the uses of the
   first nibble uses is provided in <xref target="I-D.ietf-mpls-1stnibble"/>.</t> target="RFC9790"/>.</t>
          <t>For example, in <xref target="RFC4928"/> target="RFC4928"/>, this nibble is investigated to find out
   if it has the value "4" or "6". If it is does not, it is assumed that
   the packet payload is not IPv4 or IPv6, and Equal Cost Equal-Cost Multipath
   (ECMP) is not performed.</t>
<!-- [rfced] "ECMP'ed" has not been used in published RFCs. Will readers
understand what this means? Perhaps rephrasing would be helpful.

Original:
   For example, an
   Ethernet Pseudowire without a control word might have "4" or "6" in
   the first nibble and thus will be ECMP'ed.
-->
   <t>It should be noted that this is an inexact method. For example, an Ethernet
   Pseudowire
   pseudowire without a control word might have "4" or "6" in the first
   nibble and thus will be ECMP'ed.</t>
          <t>Nevertheless, the method is implemented and deployed, deployed; it is used
   today and will be for the foreseeable future.</t>

<!-- [rfced] We are having trouble understanding the text starting with "to
determine...". Please clarify.

Original:
   However, the BIER approach meets
   the design goal of [RFC8296] to determine that the payload is IPv4,
   IPv6 or with the header of a pseudowire packet with a control word,
   rather than being a payload belonging to a BIER or some other type of
   packet.
-->

   <t>The use of the first nibble for Bit Index Explicit Replication
   (BIER) is specified in <xref target="RFC8296"/>. BIER sets the first nibble to
   5. The same is true for a BIER payload as for any use of the first
   nibble: it is not possible to conclude that the payload is BIER
   even if the first nibble is set to 5 because an Ethernet pseudowire
   without a control word might begin with a 5.  However, the BIER
   approach meets the design goal of <xref target="RFC8296"></xref> target="RFC8296"/> to determine that the
   payload is IPv4, IPv6 or with the header of a pseudowire packet
   with a control word, rather than being a payload belonging to a
   BIER or some other type of packet.</t>
          <t><xref target="RFC4385"/> allocates 0b0000 for the pseudowire control word and 0b0001
 as the control word for the pseudowire Associated Channel Header
 (ACH).</t>
          <t>A PSD solution should specify the contents of the first nibble, the
actions to be taken for the value, and the interaction with post-stack
data used concurrently by other MPLS applications.</t>
        </section>
      </section>
    </section>
    <section anchor="semantics"><name>Semantics</name> anchor="semantics">
      <name>Semantics</name>
      <t>For MNA to be consistent across implementations and predictable in
operational environments, its semantics need to be entirely
predictable. An MNA solution MUST <bcp14>MUST</bcp14> specify a deterministic order for
processing each of the Network Actions network actions in a packet. Each network
action must specify how it interacts with all other previously defined
network actions. Private network actions are network actions that are
not publicly documented. Private network actions MUST <bcp14>MUST</bcp14> be included in
the ordering of network actions, but the interactions of private
actions with other actions are outside of the scope of this document.</t>
    </section>
    <section anchor="definition-of-a-network-action"><name>Definition anchor="definition-of-a-network-action">
      <name>Definition of a Network Action</name>

<t>Network
<!-- [rfced] How may we update this sentence for clarity?

Original:
   Network actions should be defined in a document that must contain:</t>

<t><list style="symbols">
  <t>Name: contain:

Perhaps:
  The definition of a network action in a document must contain the following:

Or:
  Network actions should be defined in a document using the format below:
-->
<!-- [rfced] The "Scope", "State", and "Required/Optional" items below include
complete sentences starting with "The document should..."; the other
items in the list do not. How may we update these three items to create
parallel structure in this list?

Original:
   *  Name: The name of the network action.</t>
  <t>Network action.

   *  Network Action Indicator: The bit position or opcode that
      indicates that the network action is active.</t>
  <t>Scope: active.

   *  Scope: The document should specify which nodes should perform the
      network action as described in <xref target="scopes"/>.</t>
  <t>State: Section 2.1.

   *  State: The document should specify if the network action can
      modify state in the network, and if so, the state that may be
      modified and its side effects.</t>
  <t>Required/Optional: effects.

   *  Required/Optional: The document should specify whether a node is
      required to perform the network action.</t>
  <t>In-Stack action.

   *  In-Stack Data: The number of LSEs of in-stack data, if any, and
      its encoding.  If this is of a variable length, then the solution
      must specify how an implementation can determine this length
      without implementing the network action.</t>
  <t>Post-Stack action.

   *  Post-Stack Data: The encoding of post-stack data, if any.  If this
      is of a variable length, then the solution must specify how an
      implementation can determine this length without implementing the
      network action.</t>
</list></t> action.

Perhaps:
   Name:  The name of the network action.

   Network Action Indicator:  The bit position or opcode that indicates
      that the network action is active.

   Scope:  Description of which nodes should perform the
      network action as described in Section 2.1.

   State:  Indication of whether the network action can modify
      state in the network and, if so, the state that may be modified
      and its side effects.

   Required/Optional:  Indication of whether a node is
      required to perform the network action.

   In-Stack Data:  The number of LSEs of in-stack data, if any, and its
      encoding.  If this is of a variable length, then the solution must
      specify how an implementation can determine this length without
      implementing the network action.

   Post-Stack Data:  The encoding of post-stack data, if any.  If this
      is of a variable length, then the solution must specify how an
      implementation can determine this length without implementing the
      network action.
-->

<!-- [rfced] May we update this text to clarify "its" and "this"?

Original:
   In-Stack Data:  The number of LSEs of in-stack data, if any, and its
      encoding.  If this is of a variable length, then the solution must
      specify how an implementation can determine this length without
      implementing the network action.

   Post-Stack Data:  The encoding of post-stack data, if any.  If this
      is of a variable length, then the solution must specify how an
      implementation can determine this length without implementing the
      network action.

Perhaps:
   In-Stack Data:  The number of LSEs of in-stack data, if any, and the
      encoding of the in-stack data. If the in-stack data is of a variable
      length, then the solution must
      specify how an implementation can determine the length without
      implementing the network action.

   Post-Stack Data:  The encoding of post-stack data, if any.  If the post-stack data
      is of a variable length, then the solution must specify how an
      implementation can determine the length without implementing the
      network action.
-->
      <t>Network actions should be defined in a document that must contain:</t>
      <dl spacing="normal" newline="false">
        <dt>Name:</dt><dd>The name of the network action.</dd>
        <dt>Network Action Indicator:</dt><dd>The bit position or opcode that
        indicates that the network action is active.</dd>
        <dt>Scope:</dt><dd>The document should specify which nodes should
        perform the network action as described in <xref
        target="scopes"/>.</dd>
        <dt>State:</dt><dd>The document should specify if the network action
        can modify state in the network and, if so, the state that may be
        modified and its side effects.</dd>
        <dt>Required/Optional:</dt><dd>The document should specify whether a
        node is required to perform the network action.</dd>
        <dt>In-Stack Data:</dt><dd>The number of LSEs of in-stack data, if
        any, and its encoding. If this is of a variable length, then the
        solution must specify how an implementation can determine this length
        without implementing the network action.</dd>
        <dt>Post-Stack Data:</dt><dd>The encoding of post-stack data, if
        any. If this is of a variable length, then the solution must specify
        how an implementation can determine this length without implementing
        the network action.</dd>
      </dl>
      <t>A solution should create an IANA registry for network
actions.</t>
    </section>
    <section anchor="management-considerations"><name>Management anchor="management-considerations">
      <name>Management Considerations</name>
      <t>Network operators will need to be cognizant of which network actions
are supported by which nodes and will need to ensure that this is
signaled. Some solutions may require network-wide
configuration to synchronize the use of the labels that indicate the
start of an NAS. Solution documents must make clear clearly state what management
considerations apply to the solutions they are describing. Solutions Solution
documents must describe mechanisms for performing network diagnostics
in the presence of MNAs.</t>
    </section>
    <section anchor="security-considerations"><name>Security anchor="security-considerations">
      <name>Security Considerations</name>
      <t>An analysis of the security of MPLS systems is provided in
<xref target="RFC5920"/>, which also notes that the MPLS forwarding plane has no
built-in security mechanisms.</t>

<t>Central to the security of MPLS networks is operational security of
the network; network, something that operators of MPLS networks are well versed
in.  The deployment of link-level security (e.g., Media Access Control Security (MACsec) <xref target="MACsec"/>) prevents
link traffic observation covertly acquiring the label stack for an
attack.  This is particularly important in the case of a network
deploying MNA, because the MNA information may be sensitive.  Thus  Thus, the
confidentiality and authentication achieved through the use of
link-level security is particularly advantageous.</t>
      <t>Some additional proposals to add encryption to the MPLS forwarding
      plane have been suggested <xref
      target="I-D.ietf-mpls-opportunistic-encrypt"/>, but no mechanisms have
      been agreed upon at the time of publication of this document.  <xref
      target="I-D.ietf-mpls-opportunistic-encrypt"/> offers hop-by-
hop hop-by-hop
      security that encrypts the label stack and is functionally equivalent to
      that provided by MACsec <xref target="MACsec"/>.  Alternatively, it also offers
      end-to-end encryption of the MPLS payload with no cryptographic
      integrity protection of the MPLS label stack.</t>

      <t>Particular care would be is needed when introducing any end-to-end
security mechanism to allow an in-stack MNA solution that needed needs to
employ on-path modification of the MNA data, data or where post-stack
MNA data needed needs to be examined on-path.</t>
      <t>A cornerstone of MPLS security is to protect the network from
processing MPLS labels that originated outside the network.</t>
      <t>Operators have considerable experience in excluding MPLS-encoded
packets at the network boundaries boundaries, for example, by  excluding all MPLS
packets and all packets that are revealed to be carrying an MPLS
packet as the payload of IP tunnels.  Where such packets are accepted
into an MPLS network from an untrusted third party, non-MPLS packets
are immediately encapsulated in an MPLS label stack specified by the
MPLS network operator operator, and MPLS packets have additional label
stack entries imported as specified by the MPLS network operator.
Thus, it is difficult for an attacker to pass an MPLS-encoded
packet into a network or to present any instructions to the network
forwarding system.</t>
      <t>Within a single well-managed domain, an adjacent domain may be
considered to be trusted provided that it is sufficiently shielded
from third-party traffic ingress and third-party traffic observation.
In such a situation, no new security vulnerabilities are introduced by
MNA.</t>
      <t>In some inter-domain applications (including carrier's carrier) where
a first network's MPLS traffic is encapsulated directly over a second
MPLS network by simply pushing additional MPLS LSEs, the contents of
the first network's payload and label stack may be visible to the
forwarders in the second network.  Historically  Historically, this has been benign, benign
and indeed useful for ECMP.  However, if the first network's traffic
has MNA information information, this may be exposed to MNA-capable forwarders
causing and
cause unpredictable behavior or modification of the customer MPLS
label stack or MPLS payload.  This is an increased vulnerability
introduced by MNA that SHOULD <bcp14>SHOULD</bcp14> be addressed in any MNA solution.</t>
      <t>Several mitigations are available to an operator:</t>

<t>a) Reject
      <ol type="a">
	<li>Reject all incoming packets containing MNA information that do not
	come from a trusted network. Note that it may be acceptable to accept
	and process MNA information from a trusted network.</t>

<t>b) Fully network.</li>
	<li>Fully encapsulate the inbound packet in a new additional MPLS
	label stack such that the forwarder finds a Bottom of Stack (BoS) bit
	imposed by the carrier network and only finds MNA information added by
	the carrier network.</t> network.</li>
      </ol>
      <t>A mitigation that we reject as unsafe is having the ingress LSR Label Switching Router (LSR) push
sufficient additional labels such that any MNA information received in
packets entering the network from a third-party network is made
inaccessible due to it being below the RLD.  This is unsafe in the
presence of an overly conservative RLD value which and can result in the
third-party MNA information becoming visible to and acted on by an
MNA forwarder in the carrier network.</t>
    </section>
    <section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
      <name>IANA Considerations</name>

<t>This document requests that IANA allocate a
      <t>IANA has allocated the following code point from in the "IGP
MSD-Types" registry <xref target="MSD"/> in within the "Interior Gateway Protocol (IGP)
Parameters" namespace registry group:
      </t>

<table anchor="igp-msp-reg">
  <name>New IGP MSD-Type</name>
  <thead>
    <tr>
      <th>Value</th>
      <th>Name</th>
      <th>Data Plane</th>
      <th>Reference</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>3</td>
      <td>Readable Label Depth</td>
      <td>MPLS</td>
      <td>RFC 9789</td>
    </tr>
  </tbody>
</table>

    </section>
  </middle>
  <back>

    <displayreference target="I-D.ietf-mpls-opportunistic-encrypt" to="MPLS-OPP-SEC"/>

    <references>
      <name>References</name>
<!-- [rfced] Would you like the references to be alphabetized
or left in their current order?
-->

      <references>
        <name>Normative References</name>
        <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.3031.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.4385.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5920.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7274.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.9017.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9613.xml"/>
      </references>
      <references>
        <name>Informative References</name>
	<!-- [I-D.ietf-mpls-opportunistic-encrypt] Expired -->

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-opportunistic-encrypt.xml"/>

        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4928.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5714.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6790.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8279.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8296.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8402.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8491.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8662.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9088.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9089.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9522.xml"/>

		<!-- [I-D.ietf-mpls-1stnibble] RFC9790 - cluster 520 document -->

<reference anchor="RFC9790" target="https://www.rfc-editor.org/info/rfc9790">
<front>
            <title>IANA Registry and Processing Recommendations for "Readable the First Nibble Following a Label Depth", referencing this
document. Stack</title>
            <author fullname="Kireeti Kompella" initials="K." surname="Kompella">
              <organization>Juniper Networks</organization>
            </author>
            <author fullname="Stewart Bryant" initials="S." surname="Bryant">
              <organization>University of Surrey 5GIC</organization>
            </author>
            <author fullname="Matthew Bocci" initials="M." surname="Bocci">
              <organization>Nokia</organization>
            </author>
            <author fullname="Greg Mirsky" initials="G." surname="Mirsky" role="editor">
              <organization>Ericsson</organization>
            </author>
            <author fullname="Loa Andersson" initials="L." surname="Andersson">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Jie Dong" initials="J." surname="Dong">
              <organization>Huawei Technologies</organization>
            </author>

<date month='May' year='2025'/>
</front>
<seriesInfo name="RFC" value="9790"/>
<seriesInfo name="DOI" value="10.17487/RFC9790"/>
</reference>

<!-- [rfced] The "Data-Plane" value for following reference appears to point to IEEE Std 802.1AE with
a date of August 2006. However, that version has been superseded by a new
version dated December 2018. See https://ieeexplore.ieee.org/document/8585421.

We have updated this reference entry should be "MPLS".</t>

</section> to current version. Please let us know
if you have any objections.

Original:
   [MACsec]   IEEE Computer Society, "IEEE 802.1AE Media Access Control
              (MAC) Security", August 2006.

Updated:
   [MACsec]   IEEE, "IEEE Standard for Local and metropolitan area
              networks-Media Access Control (MAC) Security", IEEE Std
              802.1AE-2018, DOI 10.1109/ieeestd.2018.8585421, 26
              December 2018,
              <https://ieeexplore.ieee.org/document/8585421>.
-->

        <reference anchor="MACsec" target="https://ieeexplore.ieee.org/document/8585421">
          <front>
            <title>
              IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security
            </title>
            <author>
              <organization>IEEE</organization>
            </author>
            <date day="26" month="December" year="2018"/>
          </front>
          <seriesInfo name="IEEE Std" value="802.1AE-2018"/>
          <seriesInfo name="DOI" value="10.1109/ieeestd.2018.8585421"/>
        </reference>

        <reference anchor="MSD" target="https://www.iana.org/assignments/igp-parameters/">
          <front>
            <title>IGP MSD-Types</title>
            <author>
              <organization>IANA</organization>
            </author>
          </front>
        </reference>
      </references>
    </references>

    <section anchor="acknowledgements"><name>Acknowledgements</name> anchor="acknowledgements" numbered="false">
      <name>Acknowledgements</name>
      <t>This document is the result of work started in MPLS Open Design Team,
      with participation by the MPLS, PALS, and DETNET working groups.</t> Working Groups.</t>
      <t>The authors would like to thank Adrian Farrel <contact fullname="Adrian Farrel"/>
      for his contributions
and contributions. The authors would also like to John Drake, Toerless Eckert, and Jie Dong thank <contact fullname="John Drake"/>, <contact
      fullname="Toerless Eckert"/>, and <contact fullname="Jie Dong"/> for
      their comments.</t>
    </section>

  </middle>

  <back>

    <references title='Normative References'>

&RFC2119;
&RFC3031;
&RFC3032;
&RFC4385;
&RFC5920;
&RFC7274;
&RFC8174;
&RFC9017;
&RFC9613;

    </references>

    <references title='Informative References'>

&I-D.ietf-mpls-opportunistic-encrypt;
&I-D.ietf-mpls-1stnibble;
&RFC4928;
&RFC5714;
&RFC6790;
&RFC8279;
&RFC8296;
&RFC8402;
&RFC8491;
&RFC8662;
&RFC9088;
&RFC9089;
&RFC9522;
<reference anchor="MACsec" >
  <front>
    <title>IEEE 802.1AE

  </back>

<!-- [rfced] Terminology

a) If no objections, we will update instances of "sub-stack" (with hyphen) to
"substack" (no hyphen).

b) Please review use of "special label". Should instances of
"special label" be updated to "special-purpose label"?
-->

<!-- [rfced] Abbreviations

a) FYI - We have added expansions for the following abbreviations per Section
3.6 of RFC 7322 ("RFC Style Guide"). Please review each expansion in the
document carefully to ensure correctness.

Operations, Administration, and Maintenance (OAM)
IP Fast Reroute (IPFRR)
Fast Reroute (FRR)
Label Switching Router (LSR)
Media Access Control (MAC) Security</title>
    <author >
      <organization>IEEE Computer Society</organization>
    </author>
    <date year="2006" month="August"/>
  </front>
</reference>
<reference anchor="MSD" >
  <front>
    <title>IGP MSD-Types</title>
    <author >
      <organization></organization>
    </author>
    <date year="2024" month="December"/>
  </front>
  <format type="url" target="https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-msd-types"/>
</reference>

    </references>

  </back> Security (MACsec)

b) Is the abbreviation NAS read as "nass" or as "en-ay-ess"? We ask in order to
choose the appropriate indefinite article for it to follow. Currently, both
"an NAS" and "a NAS" are used in the document.

c) The following abbreviations appear in the text but do not appear in Table 1.
Would you like for them to be added to Table 1?

LSP
TC
TTL

d) Throughout the document, the expanded form of the following terms are often
used although the abbreviations are introduced in Section 1. Would you like to
use the abbreviations after the introduction in Section 1? Or do you prefer the
current?

network action sub-stack
post-stack data
ancillary data
Entropy Label
-->

<!-- ##markdown-source:
H4sIAP7UbmcAA+1963LbSJbm/3yKXPlHS7Mky5IvZWtiI1qW5LI6ZFtrqrZ2
YmN/gECKRJsEOLhIZtuuZ9ln2Sfb851zMpEASdu9Mz0xMdPq6DJFAXk5ee63
HI/HJi2zvJif2ra5G78wTd4s3al9e3M9te9c81BWH+1Z2uRlUdvDt+/Ojuzr
Klk5fG+S2axy9/Twu7Po26xMC/p8arMquWvGuaNxV+tlPV4Vyfju4eP4+Jl5
mOsUv9EbNLv9pSrbtUmTxs3LanNq8+KuNHU7W+V1TXM3mzUNeHV5+9rk6+rU
NlVbNyePH798fGJM0jaLsjo11o7p//yTF/WpvZ7YsyJzVV2Xhf+DrOy6TLb/
VFa0qDdt8uBye+vSRVEuy3nuav93t0ry5aldlskf1/mkaLfmm07sq2qTFE1/
smnjHpKqGfyNZ/u1yO9pEXmzseWdnbZV5Tb22S9X54M569kfaxllxoNM0nK1
Nf1bmr5M07w/+9ukaRbuof8nnvxd+TFPBhOt5OnJDE//scATO+e6ndjrwUS3
ZbGJvuQp/tQW+dpVHpGGoGzolcky/6P+a0xRVrQCggkO88Pr85Pj45f68cnj
J8fdxxP9+PTJi2f68dnLk8f68eeTn5/qxxfH4ePLx8c/+4/Pj5/gowGaRVNe
jS8mHb6W63VZNbSFusnTsSvSarNuth87rpsin82WftFPX5688Gv6+djP/vzn
l355L05+fhk+vnzuPz59fBI+vvR7ffH8+UlY/4sX3Uc/wstnJ/zA27Pz2qWn
DGGl4avLy0v74vHJ5Pjs0r51WU5In6auru05UVRVLomgz86P7NSlbUU4yO9m
RIKn9qydE4FZorDn/G1HYuFsefTzcrVuGzrhaZkSRDDE2+lFbxUHV7/c4Mvx
LdFwfRBNcuFSt5rRyyePT57y93IYfpq2Ihw5WDTNuj796aeHh4dJnhTJhGb/
KSGuMC9Wrmjqn/L5erxOwH5oIcNfJ58WzWr5CF+u6mzcyBrG47FNZnVTJWlj
zO0iry1xrRbj2czVaZXPXG2TwiZVusgblzZtlSztnedxWKglQmEeZnazySZi
IRPLPDL+ioZ2tq1dRlRAaJjl4H020SGaRdLYfLWm33kemo+oH3yagG9L+qqy
66rEYeK7w7pNFyap7aos8qas6LsjcBS8SmN8dI1NliU9iC+uk5lb2ulD3qQL
mv4maRb28Hp6gzdM/EaBtRGrTYr6juZLiL6TLMuxQgIGnWFiC+cyGkPBUTuj
G5gAqq4DKq31PifI6mbagt6m5wIcM3fvluWan6V1J5aYDu3F1I5/LxTCHjxY
WiBdGsYtHeOCrVumWcCkW6opiQcluuxVmbmljJAm62SWL+kpWhjNwgJJp8KR
GcaTVZ5lS2fMI3sFoslaXsO/S6zB+DtOt+bjrY+w6Z/oEd6nHHJthqe881jt
f6RjBUzrctnynIaUAGL+tNeqXNGa6Uy78wKw86JxRcYAx9wV2Ce2Vrl/bvNK
1md46/So/fxZpcvXrxPCl7DaEc+6SjZGt9Kn9JK0gGWytu4TZA3tktd81xap
bI+Y88QywtEQdubMzBXuLk9zoBfBuqDjIAWqplUlpNHUIwuGYMEQElav8oYg
RLtxd3gLx0H4Q4cxywvXzdqbkGFZkObgv62xQWy9JvgIDgsSEVbIejsmFU6U
IUiMtvXbLWVvtFqwZ4bqer3cmIiz+JcfFq7oDapIC1AAKVf5fEFcskiXbeYM
6WXZeJYskyKNH7ZzOt6CAFBbB/pdb0YYmDkoIFcCFJYwCWhn7pK6GVeOV2cJ
AxN7R5pKW7kRg2PwYphjAUi7JgHxmIrQ9j5hEA95dwBLYMZros/JkJnM6XSJ
c+R/UcpKyyJ16yYg88H2kAdA1NIcDEjqAItQCAkD5+8F64hTRWdh89oAqR1p
msISko8Mg04kAPBJgHjNAw5OXgXAyM7ahpHVTy4yK5BsLTILKFqr+tEh2si8
P3sr8i0j2BM6uyadHOmqCaUA/IyoL22WG8L5ZaJLjsVkLMsmPSbQw85k+ZBs
CMxVPp+7ioaZbRgw784Uu8NOFsm9g0xegukGfks2Sg2o4bzJ3iHyGumeAY2i
LMagfOW2I+w3y+u0rcHDmWFMG1o9sQsioiGzx6y0JKJ0olKmPFKcC1JGay/c
mduP7K3MbM6XpBjZw9vzI8HX25woleByTTRAX99eH9m73C0zJmV//CoxGlqi
vSQS2RgSF5dHlkTIAo8NzEAyU2Zjefrw3dn0iBb+6JH90LFDGrCYt8nc2c+P
Plz+9zFR5PyrCI6PZN7QUDT/wdtfp7cHI/nXvnvPn+npX68+XF7g8/TN2fV1
+GD0iemb979eX3SfujfP3799e/nuQl6mb23vK3Pw9uyfDgQoB+9vbq/evzu7
PhCGFlMeMILgNRO+X60rB8xKICZEvvOhvTq/+b//5/gpHd5/USPl61f9BfYG
/QLWJbOVBaGo/EoHRnxuvXZJxfBfLiGr8iZZCmLUi/KhsEQmbmKEwwmsgAb0
DHNKfbe/6rwg7vdA5JUmkNW1XS8TeuiymC/zeiGjjKDwMpYuXA72pWYP8a2k
IFSFbDdnS1Lz2/lCxs9ZmbnqBDK0Pp1zpIoBsSZir4GcsL1lrtKSlCCS/zZd
JkzeKj1iwdlRNEEaq3OZoNOtq1Y508EGvz8iY9Wv9wLkkIvwHvDNJCvXTa2a
R3jK08pduSQogTfQya5YV1APRu7pGTpAJMJx8J1JSmjVIwRGtD5pXIlGho9E
G1dHQLwzkkdLAsHGXkC1Ojy7OPKIOE2JHx7QjnuawgAjcfDCAupd2zg15h++
Q6FkzlnVuJRXjnBuTT5voTMQsYMfGK+Z2iUzhJoHAItLk6rasBYR6WYR11W2
GnR/iOfAmc6VE91e2/tkSdLF44FOy59plV6z8fwuExGCvyqG+nOc2hmpMwQj
EhcL4i2MM9+AgR4KbeTw3fSKoIHl3eUV2be0hmgJBkAhwiHUsPXasXYlsBBz
TNVtOQYCT9X4JdHLE8HTsxihiKK+9L6xX8gOl818IZZJ+rYjyW6/mC/j3s+X
HZ/oM0a7sN0P/dpHri897MXzr64uP0TPvyLIETzcJ3v5CYKMfv3ggkTz78NB
4d8vp/F8r8qmIRqBs4phqy/AuaEvzKY31/EL4EhTBeZNW63L2lugfrGPj3/W
dy/P397Q15f/3NLD5yUd0Nt22eTQkcLTz05O8LTF49d4WJS6/pjRei4/kJTo
HvvgSEmbLf0aLkitCmPD16JvOeyC3vqkyv++HWxt4c2rN/T1m3INPWJB/3yB
GcCkRdIdCOY+NQMan+DFq5NLfnYuFkZpL+XTD7//yw0/S0whJ1T/JYG/cGNv
qrIp0xJr5aemF/zUWKg72400IIsv23qBfxL+N30Si/qy21m8Pexbnvxt8ilf
tSs7vboYgP/py2N9kngnfbubudLmtocGA9l6oWMBX2xfUPAr0x1z7OIau16+
4a3cEIruhyTY3ufP9KSuURBxDwJuTwH40H/dnL+5yiBlSXmrOnA99qcgyPpj
VPb51D66TWZjEtTElsRJ998OemzrwH6FB848osOH4UYqOKkGRc9wFgZ5xyY2
KacEJrYvhxq2N+/4Q2EizwMZ4qLj7HICiI6SBObG0BUBwdIoZz0M8QEBf+2V
1Z0yTN0e63BaBuPRAqLtrODulD2xusZ2Kw8Xj4TfB9LORosoU7JkSP2/402Q
NkcahdgGgABpf1Dx2mUmck7YLu0kWns02SgMEs2qUOp2zg+tB3gIhYoES5mx
aLyijTlHCs+C7GVayDL/6Hg9JNPqcuWGcH6gXwBodQIlsH6KjVmXOTQ2MV1J
L7ye3hAIY+kBD09/qGZRQZ0sRZCbGJQPCgi/KhL53jfByrD8nezvllZTuQdS
IZ036nqH21hHmiZ47Yi2w0iaQEOqBQSqOAywjN1eg8VmziFWseskRGeFQQf7
j3XXJCD4siw/ElLX6qn1igUB56bz0KqiwKMaWXl4pSExQX+Xb8F7H2j/Mk6u
LkfFEn5cRZkR+o7kHZ312WCjHXZar9yQwjj+11CWrN2hLq2V9yxF+0vpJFwW
xJd++7DI0wW9DxVOXJlBt+qrVsne3Ux2bCIsvRbl+9S+X4vVstyMsEZRgfPu
MZCA6Ty3YmHv8kxO7NVd/OdoDNpEUTbGu8b8AnlCz1xSxmWhSDy2AhwHRDux
Z2awWxq6TvJMDVK1kMBdGuFPbJ6FpejZeK+Fqqz35UfdmQzKgCP5L6ctFgkp
BbGN8BdXlYGhs5bOY7EVMKAZ4x29W3x/YNdNwmH5vQUIGu/QIXSq84x9MP1Z
aM2XIPEBeAJAih1LiBDf+27M9sb4KHuHAHQnc9lVEdH2HjH8YlpWNPu6LLLa
u/mGbw0PM2yYJzExc9qaRGUIoS0AvEUGLKxIhngZnHkYBAWC4R9bjf0RJkEF
NLForbxFwl6wFevey63DBZth1HOfEnDDUX/t6pZlrghRMzBaezIALI3UAkQB
M8ga4ivEnn7//XeOAD622z/HO7472fHdEx3hmP76xD61z+xz+7N9YV/+Nd9h
jP86/hf+z7Ad1P8R1r39Q3rgOf33sT4Po1m+//tK/g1Xsl868ryPh8/zSn7f
sfS/5uf3/kr2LoEdN0VLxLJvJf/BT+c7Kzn+N8ST6Ocm2SAA9Y0nsBIa5XU+
J3vKHp/C/NjBDG3HDPegAPNHc+4qKF9bkjc4i70xI6IAjJkUBm88JXeNq4a6
tIYY+THW27ZUFEjHgeAyg4d+THTZoegyPy66oIvtk00m0jnEfkLQZmuJO+R1
vmUg/suE/JaQHBppIibVpZ9Aie77XSEwRRBvLT/+owS5GPn+Ljr/kzOioT9q
38/fQmDtXUQksPas5N8Pc9Yf5dEnWzz6G1QpXHmfRynwDknX2PaSzXqhsygL
y1tY0bPM09haqhvicyZEhSd2miOeIPYhWCE8N1hpncPl6LkXAupqsSM4SYLH
IKRCnCtZlnMynz9/PtfPX78eCbvs70sTf8Dg2iJZzSSU5A0S8QeJuCBmnOb1
IHSNHCnhmFhk5tbwsiNHSGQBu7nhbOqlsEVxdUll6BmJI+84xFF1riLJbdjK
sEjqmj6onRqchr/9Is6v2i1d2rBRyrYiPVXAzWkCEPypxMIQvnXOmRm+ZuPX
zPC1m+mFxDw5Gljbz49q/vB1hzcHwh1uueASYP+S4KO7dwSKAi6GkF5iEDoZ
weZlRx/nKoSgFR71/jykx3Aqip3iQX1CFmJ8ski0CEZBOjuOPr4p1+PZZoxo
x+GbV2+OTu3ljrXw+AJfzbbpuyX+wQc/xk051uDH4dXJJfw4hfhPiRbrRoYN
eSmDMYmIB6NO+TB1EI+gvc3/wOKu7mJ/juZweY8RIwvDasSJViAQ71ViB27e
mM5dHnuZeBFd+lFM6B5lu2y0rHTsa0J0P5VsHjCBpkrYMasQ4XXQ4HzqQIGB
l5PmGW2pZfCFF5td2Cb6ieF0kY0fvLKSOhbcvoIoow41inIXeRpJaOH4/9Dh
seWkV5VTEDKarzbqrYCHp1w3+SpZ+ljxbngRKjVVrpm0vZE0CyaKa0hUwGNJ
L+KBaTUXh9NtI+ALAd8kVcMBmOD2ZSWwlzriA2jHX7+O7NLNkxSD3uepZ0ZZ
qWtOy3mR/4WZuQnOU0FRZBAlVRaLCfEKsitZHszrvtuVlngxmKc3R/ekaqZY
RfB2c7KKKvzf9/Xtk4JEC6YtwrTZd92GXbyE0KrIlhzPeF+AqxBXLyQhJPfv
Fbbvnfdv14BKly29tQHOMyTCBVduC05LZLm2vVDjyWXaZX35pW6NynMDip1s
F5FIL5D5gnUPJV+A2x9qVRdIjHU5czAqCkmk+6sAkFUEANYEGFmEoXfee/pD
b7N7dsThBaIxQry/anbP3AiFzPdnEVLO50XJyXnL3tLM/qW9H4IlMoVnLuhA
cgIdJ1cM6dQ0E++NE4okiFaoCPWJw6PI+e65g4hkKEbBI6vkye5507F3GHzQ
5DS6p3mLtAEPM2ArRrkDYnpOZvoU65HxN1H3goCGhlBvqQgIlLFYRqTMSAYN
xlutNL9ZnfwOryH3s/DJscLo2rTRsJ/ETYj1oXaJV5YNuJdPchbE8C7nMCVt
odYZwYIZsGlekW5GnL8Ai8ol5VKop1Ng9y4muS/zrJasZ15OlwHN1N0JPF7C
mNPWqjm4QeeaDsm+OC5+7erm9YcPwrNRyvP1K2O7pFSzFFbNjdA1WQq/F/WE
N/6Q1wuR7yuk0rY1K1YcoET0kePiuwLmPoTDvLPlMrXGK7cRrCP0YqnAKfx5
E9KbjU9vDq/5Y6EldOryXh4sVomEkDKfc91LrvecmlRpr5LWDAq1kDT3xGuQ
AGzbjMu7segRokT31HLAZTAoh26Ih4wH2smctttKaiGH5yL9TFWMOrAD0tz9
EXUqWs9B5jQdarnRRK5deRrG7MzeOPxwfXEk7Jwz15i4AdmWq5vozBEzGklc
k1FOag1C5FetFkQNBVI+JTtNsJkk03Rdsn/KlS8PMOHsG+C8Z7OgH60cmthe
XlMUS/Yh5N3bQcrU0WR3poqqFVwCoGnpIwOO3eWsZ8EKCuYgzEwyuUqyOH3C
QxzKlhnM4eX1EUiP0BMhP+TL5F6Dy1BbUuhu8ZeZSxNQFD8WTxSp2omkHIag
Zs5YsiGredVphx2vGoTWvTUdXpEwrpRYEGA2MT11ZVl8Nl3NhFRRKENOMuI6
DcxhOk0sXNYH+A2WYnqgAbWq3PcjZPou8zNG92zSZz/rltkPzYTsKJL25VY+
C78MD6ewV5inrqhb9nAKJhJfiVgOJ5Z8Ivhq5qdKF58TIHyICVas3AaKvvzB
p7jkFTYOHZFXqmncOMlAovbQTeaTkdHEpRcvoCv7X15+/XqEqTOU960kMT6v
2YChpQEfWRqzCjtzI45QBx8sM3XPD7lqQxnSDMf0sSgfiHXN3WDvZmAmqpBj
QweHuMxXuc8HEa7a1oosLJf4PNuicIAVDCKU+yxA1oSYLaeHhL3TGd7QMUd0
y9ZaONQttL28FqhHqGX6WA8IwL4HpXCKjH8UEzP5YH8uHhqZOM6EHPUatWh6
YG/P/imaa0ZYqWPQxv2/eqgEp7o0rMLU/Yc0E5idP/kdB51hNsxJH5X4QTgg
8yMH9K0TYe9V0fF/5qkkqPhkINeu/HR/2L9IHCBYHgsPQICz+jsw8HuMaZrD
lG58KVY0gQl+AzAMEP2O05T1Yh6FYjcLTUJotATB5c33sLcoFTYhNWCFcBET
J1brjWJVn5XZRuxF6mDi4t2Omx7evjrjckIGBuyb7j0OZbxjVPGZnts5jIfT
KxKZKm9o/KORuc6Lj5iKHRfAq0lIOhTEQ6EI+AR2g+UGDsBrFTdMrnTKGUvx
qlCIw9Qge4AEZt/VrQ4WPep9e4QtHyffeQYrC8+EOQI6RI+ceRzzkA7lTpyF
QkixIAvgAdjW17FQWCjaf8x5xXIMZqPKv+Ax7bk0REdlr+jnR1JutMO3CLpI
iBbVTyJeVDKdq86Y0TckTsipcHmQDF4VZaNLhoF1E5VHaQ0Ul4l4ax7JzWto
RSlUuRF7S7cH2jGIWlOshyATEfW5l96r+vkRJyvRLqcweZCX5i0IKfYqfTLW
u7OrWtjGzDmkFJVIX8s4OZW2WDufTLRakabp6/HksUTrTcV80eSlrjKM13dP
b6HGIrZLJ9aY30Dju8rRuuzWzi3dS0Vkbla5OSELc4IQvURpu9QY8UCVCyU1
TMre5ygJXUQ4ZE3vz6/T0i6WqpDfGm0Q532/OGJkypBm1wuQdKljXV5tvpXG
pQy2NLDzRIV1Wb/sMJgqwWW47dPkJNBQET30LE3shRczOwPmmBvmXGaaci4l
nrm47ll1qrZzjzu5FSUAExbGCeDBDFEKCfYJ145mWU8nEGiJihYdw1Qx8Mnk
eBSXTpmXdDpnaVpytSMSHINnwvsQ2PXBlmdX9as2KCaZEc8xUepxNKnoUfzt
dEzPHXFGbpShG42DyFEdVGNxbMmAvqKJtZzBTrXKSzmVZrI+ImrUQsFexuk3
0HRfxY4ZVOx8I5M09lYuuByVWYZJFyV7S4OV2ptArcRLXzotdS4317YfA2R/
dyv6vtt69hDFMkesIcD9CAHGOJCVpi47QxW2Kctu9Ra1NYoraUUzWj/8RnBq
k2YKBhcXn+o5cFGgpLSHxNErDjpd3fXWlRcADnghFocd85K8b4jVTPVn7pzZ
Ky68aDlBTiqEFcBuQKEOdGfR8gh+gxQlYhpMtgrVd+hXo0DagqfGWxKuTcdK
wU/9W13BzvfejJ8kjN93EDY6CLOn/j+IelJGEI0YGP66qV9rV40v1EMgBu9w
gZy33nPKiO8Xw/siwMiGU/9ZXJW2H8s5mJQSrBv2jBaEQsxHgi0yTOWNp05L
5jM+QTtQPw0p5JakFUnYSCOP43Ni4nRzcjwyuMyCl0hcsy3A5B0pss/UxwB0
aeMHhJ5JwpLgH3vVR/KCIibbnSLT346BR6LXD3zBf6aTFrcQ7c5DR/nVua9l
ZIdw02NUuzOCooTw0kcxTx4z84VvXzjf/2Cd1Eu5YY0dQvOh7QfJ1XfTq3/k
B2k5XM1tDp/wgEdhCOScHL7wX2p+ddspNgrSpYPmc3wsskCjAgrr1qu5XL4u
af0elTs4gLoTQJSZSS9PoIO/POOX7N+UQnTlGp3O/gOg9LUhIXVqZ4SNTOe/
J0TZL9O/XRrSroWc+gWxnTXyuL7j8dvzU/lXehdY7l0wsk/2PT+Vx4fkMbKM
vrsmuL3mV7gJwq00QTA7ngv5Pk9QBLHdDQEo9LqtWCtkLe2h40dOO8NE5sR+
RmQ6QqhdwH8vMH9QuJidwiWiqw9OqfU7NOlN6b8JSf6noLx9pPflk6X/EeXx
v93//laU99cR3idPRxAr90m+TNT1y3KSw3GKLV0Phe1RvkONnAzXi7RCv8EE
UVVR6dX3b9GNUQHevfevQDD22hVz0ky68n1mDMO8BclysiuHPgN5vep61vRj
v764jwfFQN24R8IdGMbbEXK0rMlVZrM7J2onYFVU+4xpl9T5chMFdB36GpE+
sFWS2AViMcgggMj1lMMEO0xI0z2UVmx5dc16sYphCLXKh5HGODpb01vPPrwu
7Og6qZufziXxU3b6Crg41HdFMYN+sxbe2isF9M2WfHDBJ5IibUcN5cJ9UuWL
Q52iQc5y33lIB0rjhcywXuidtYTl/e82JW2o0gKwyD/PaiCKpUuUoOVS7qxL
Zs4oWeZaY5eh8VPifbCcU1nA/HZsWNHxqaBICpNUNEqVVDjUmsNmfAq3w/k6
ozsPh8XGGeG2N0MVnV+zNjiEcrluQtZoQvj2iabChIqvwvUteyj4j4aNMbwd
eQd0bS5+v4f2OkwXtTfLpJoDraWhTBl83DASgj/OHyywcbh5tEubuWHjsj4U
EJkhHPERNP2VMy/F0R917tFs+Xi9cMxmyIqS3i842+CGpRfJSKHRQpYEJ+n3
gFYzfhhmNewenFVJkS7EmpbZyjkZJ8x0LqOsT0n23DqrdFGifBY8IwSko8LR
kN0nNc9aDK5cVNTfb3k6XsexsES6riBQ5kfwpSZnksc58r+/8r8D1/W7c/kO
LkIzMGI15r6Mt8PY1+1Aq9O1nRZ2OTKzpO48f94794NFnrw3s2tvQcagM4dM
rmOTtjeyr0b2PBhF7PExIYlxEFHv+n6pAOjzcplN9lmadVKpfvXdHLcdhxbV
94vVWHLOH/hSyP3QDG9kWkbtH3Pu7KcrJ7TrHTlTYO2jZ4WnoVBxxCsZFNcn
REBrEZXPRf6KJNEEFE+/7IR70iVxMX5ysF7ybw2D3meRxK5fdoauGbosJDVN
E72QC032ZS87W+fgB5IblnU12XyoeR2QKiIdXkFEK+o/33F6nNXOhxY9PrFv
ygf4A0ee7fjJjJ8M3bb6nYBUf96egzO3+TwDdphhG6GQLyCZvvwcBNl9nrVd
a0Q62GkQwT4h3IcgeCifPSgLziTQEVprmCgZ4+zC8/lonqiphVccwojIxeFR
4/4bdalhx93dPDCLBl5XZY1EtiTLOV7QFll/z8O89kH6gaSDSMKDYcaCSBL9
vey1KY3Z7VYHu8+Prt5dXP5P+JojlYejCP4dgVesBH1DAzK9BENkUg+dSp1n
L07951axogVsIjWVtWER7FDSfSkGLTtUZewT8rGo2NNjlYVYXuOP7LsfcQCr
yVEOgRhyIY9oMcggX7Jf/GE6zbiXkQFHNVeeCL9gKN6Xvq0ku6R5cM7HMIL5
V8P4V+SeRxPGPMiA8DJD1mt5JrCkrmwPYN7uqeDTlI0JkE12aRjdgexL8eWO
mctEVTs0MpFwrbKKSEfqoh9+9UGD60sufVfcisfPB60ql34po+6ERMXkczfS
tq/AizjabfYV7clrYN1mLGtsIyPsqzf+DCqQi0NAE2XsjMrgadCdou6iRjPF
Tp49bzw71SPzFQDdFLQees4KOkqUkB81/tF+PQ33SPE+iv2os0UkoREqoxOZ
iyR32DUd0NizsUTaxhrNmlAKYx0v5NNIL+PlRlylMet5ZN/7nG17zhlEP0yu
+1ANNGmUbLsuqjZl5nhYrvkDtDHulCG/a5oBK+zh4I0gxu0AQfWNGfjxMHtx
WGMbKK1rcJKEohikYstqdlKVai0BY2CrP4gKc7/VW2mgsXJhcbS3F4ow4q7a
O0rn0w5a5x4KOX5uYnrzYkZnUCArEkPatkQSxycvdKRo26bbdtJ0LD8RCvsG
FbJSA+CYLdrJfUq3j8ppsmjd5NwhSWPNupotg4PLMqOuL58foTPZtgHCXV44
pQFN2FjhvwD2oUxNjiOR6A90E86nRV4/PdOVaqTlWON5on+BWGiwifdH+tpE
X8ONBtGS9i0Q2arVDn2zuMFW6LWD3A/RSsT8zmGqae/lfYZC0EiK/49htMNX
ZBcPW/b0cgHACF4zI3/H90Pg2oUoScSIi8cze7lDQirzoyCfgAIOBs5Q8Q2T
OIGdb2yIm3LSolLtC8BZexIMwSUZ6EfO/QPptPOMz+Y+dw9gCDRGbwUtXmQ5
2ZUyfP68584L7jpFI/QJVaMwuAnj61dxoejgLJ/uHSHtPDRthgesbNlZJfUO
3p0iuVoHTw/AJg6eH/gAreRDjfSj1HJqOYG1Nkoc0cJ4n0Z8dXP/FEPRv8/F
mN3VahJjHKIV5ZF/L+SlyF6v4rqkogwB8qhpLgnKT4QSaAq+KLOh5V3YS5AB
4Q6Gu6ldm5UPEHNALDRLk6pp3NCB3r2xadkBw6tD4qOncTwC+QxU38cNW/mD
X/s7MDt6DblDUtgrS+SD8eaKpnCT4bcsN2A02m+1FldgU2aJtIf3U3iXK/1L
4suJR7lF48BJwPIo9aSHbnj3221J+UDQyJQPpNc5QtuVvnwO/OZep7XTusze
JGQT0yDPVO6B4sFOq9Zplwp+1WNLIrYA10UNFt3B+bRDxGF9iigZUY1GQEJM
gyHYdZvvAAYnXbBq8CxkuEfoYtcBVzDMN9Fl5uZ5oV1FsPNO0nGQWVfSOduc
C62T4fey8zLhkr//pRD+38Osa9keBol2CBIbMYFxEY1P9Ic3VSReEu3B16Pp
Vgb7GFlilAvvzRMnbRLmgjVWzDnfEyUzCEXgDH2ps1hpyIkTWaX3FMQM0fq0
k9o+nj2mn4DG0Qp7gAXK86PHxtd49P6+4/2zztA+p20UxNHfMCyMPTw7f3PE
Siq6iX6jJG3LXR+jjCQx9DoJaPWWX40GhLokOjpCr48D6sO2JyxigMbigiFF
jazwrrbBO2uCukuGgJb2i7uJ29iXogj4HgVWE0SGsQruXkkqVp42zDTyoner
hyvu86qUe35GrEd0bQSiOngpNCClKRoKdni/fpcTiD1Yk4DKfLtT15zBRNfq
sCfI+2YG7W3ZV+Zbmcbt6Uzc6SaqfGV+obCvFd9RVNvIXT7uHomiS19inA2r
VCf2psrvEc7YlT+5z8lomD21MzowDK11VnCe7RuNocT975mNZT7TNu58s7Nk
c4BboszJJAE9eddayBKtnnhYzSk9sY/Nx15Cl2OgWtf8XXhJ/1RMuFQnNGcN
ctpn/vC59ZsN8UmpE1PaqcuFZjCCklVkw/dSSnf0HA8dKE9DIIqIS5dbecul
n5rIDQtUUmz7KsSikT4GgIoMHJY/4BWaXyu1fv3iW+XUwym2k2e0+cRXmbPh
i7q+NWe+MzEABuGKbI87qKiSSt734I+8pwT5dXzojWSXJY2PKfL7uegi6BYK
6geWSDit5gXqtRPZT77V5/cAJCFFrS/JAX1v5Q37MOw47l7fTEWQXnB5q6Fk
1w2Lt8vxeG8OqgNbdEbGZmSLMxuUIFOUiNFzwAGkEV/ZdjQD+v36KB+2Uo0B
4PSv+JKJHfsd2IynW/2/9vT+2toZzfeDexvsLF7oD+5ta2dmiPV9x5CiiKRG
csnLGUmNirSnGj3Po3490eVmj+zbLp1xaNZ5ruAzKFUVjwSWVHEncivWzqx4
bmSmLhXxg8fEHXRvPyZX7QWljAFvfCmu9nTpx+y9Yy1OqUQY8A6pUCE5od4U
6YIEsK84j9Rhtk7rPjPrRzQkwITZfT6JUqXmNHBqOkfdaW/SZdonpQ6qKUIL
8RhdavEMRD56pqkQFzGD6UJHluDtEzVfaT72FWd5Mi/KmlUaX8fPfrnUV3B7
xUdvLhpiwBnCP8lyU+dBZwu3HPlLnKSodGhpS4o07rJE5Z+cOSfyw84c9iuK
rjtaL5NCKhqL0szafNmMkcrjJ+32DLc3LsIi7coDdLgyf1caU2+kjUUPmohj
/KMEEBahaLTD+60RcVoPjhCXWwdkBF3pA6+2pr8oDqVX4yUuj+smlaJQklBy
0yXKQKE18f1reN5fv2TLWe2qe+8fhbmLWr1UO3hvuVbE1DNJI+GG0AOxK0ta
co4NEWJSREEIIYUQuTWyA67ORnm9t974sIihxG4a38DGoV4f8h2ztozQQoNc
KNfdwobbN/GNpmXoxTpQ5yu9rceTptkFueFmQpYKKZwTYw2zh+j+ta68Se68
s3r1qTKFXehnPP75Sqq6nc/lJrGh62jnrapAdlIiSV2NybMbLplX4HTtGtvX
rum5qGai3YZELNNXGu2Pzk/v3qHzy0KaWRl0swoQlBYB8mi9hUFaotfdnkcw
NuCvZHk5fw9c0nRkTty8Q2NkUHTVYajkyfXWH6NLckWGnlhIEItOwlf6yZUK
YhT7XgCGnyrnVbImDsJq+Zw3gmR7l26932sCagklbgK+SEuQYcqrtMzRhgK+
IVu3TrPNeBiXOArK7jHVGnoGmgaQNafWuBUIypbFmKsIRB3sZ9zhdVE8pGNH
Fff6NP6vUZ4ujMVPiRSN6sCsDaRlVSBLjkMSnkFH9CO17o0vjvSCAklDscHY
ARP9e/I5l0xkwb6JXgXdvQ98suvoByECLQm1nlXOEifnwnZtfIcZxhrHMKGi
sr8qDuKQuqXFS8HvSGgXjQTjM+ojIUoFhxj19xByB5flnh6qvPjroPwFcr4T
hbpEPDKiJd6NbVD6heIObVPDGZRRKShxMxSbsSzgS0L6V/VxWhZ3Y+Irv5np
oQMRGBqRCt+vF11nallvylcr3HbcaMJdsq5buawquvUuJuDOpSgpYqa3hFAI
w/XO8WSSUtcxzvh2B8hYnIBIDkkUGc5jd84zsQbSwHtdUWgIUmxUUlmRVI4L
c9a470+3NEALK/DshpcXQm/czdbFnBEOmYi3i6JCZPKbvxAQuL4UQT4WrS3T
+nJ2bifZn5MUk0TR05kLSl1AJH+igS/6pEl4QVsfQUN65ALZdrQzf0lrlY0Z
AYLMz/XeJHFybf890gkm3MuJ83hpI42khY64Xt49dER/3y7R0KTX6ybqoDLb
GGlT4htDsetjrDuOXWT2sGtbKSHq6g++EXN1JFzLJN6nJ+CnBxg1wvbqPh6H
uy85Iwy1vQTcrI+2qImHKbThRiD9q3P14kfuSjNwMJrIwRgWEzzjRdYjHFVk
7vPg/gb1hG5W3Y2xvL6ufty+yVFZrp1hWGKHCNfMFWS4jIxcBpyx2K/dXSs3
3SKYEfuy+070sGAFnMGoQ+2r6e7RBZstNaJGj4258n4Z9eOqDbQ4AK8tYj/l
zBHt454tvk5iWzClhNmEFdoNJgZZd/8ygzRSOKXBD9pGIDgXod/G9BBPHKwg
Fe0QMXM+F96zuM2wAYCvg1/lHHjrUkpCAYDwXs+DTo1JjuwH92cumCShEFoP
ed6n/jLVdwcA7hLQOW1EmHig94AG78qmy5TWExFxEJbEvxlxE0uvmeFsewY3
ZnZkX7fLvghQLyVLyNA6sdCS0CF9xOycGUawvrp+bQheIstiWLR3+KqcHnEp
BARA3bF8JfzO3vd3hMpIw90lmSiMZse7rLl0JyrLe4C8lmPDDYl1csdRJaCr
Gj+eV15PPzBrMB2v3RJmdbRxj1b9WyBTx9dnk+XqMcPxHXQDr5I/pYg3Rx3Z
VkmGdjM4bY2kZS2ff95o4IeT73hE7h4UiMbvUO++iax0YDOu1ZYuqcL9tT2M
xJXFuJYWW1HduonXONwv50FhPRHLY72Jy6SlvAD3nNFrHY4Ek3F4eo/E1zT0
HvRbFeudzKqP8Qs+cMUBsww6b466F99V7ODqlxvjm7bUB50vi4wOvo1OF3Sw
/7bAQxriCFZAsoKvjQaBJ7xeo/Es2PDBruZgB6Nwg4wcf945YSTyegA34vgG
tuKB78Tiy+sdXzHYOewPQIMHDKWzNDS3kfvWByDKfREQHyNcasArdkQJR2Ry
JnW7oIXCLWZuXbIaafiLTR1E/nM5P6+YjezNGf6L8724vH13ecvjYmtzsrvX
0qLXsXXOTj6pqeUrb9jiKz7as6zKCcFe09E7EWBSfQvlcKZ+KtZZSvunckHL
q5KPpKnfloS4oNFLKHqNrOFPubMXaESlgb2c2/AyQGgl/w8qGsldyocAAA== [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>